Voraussetzungen für die Installation

Edge for Private Cloud Version 4.16.05

Hardware Requirements

Sie müssen die folgenden Mindestanforderungen an die Hardware für ein hochverfügbares in einer produktionstauglichen Umgebung arbeiten. Für alle Installationsszenarien, die unter Installationstopologien aufgeführt sind, werden in den folgenden Tabellen die Mindestanforderungen an die Hardware für die Installationskomponenten.

Diese Tabellen enthalten die Anforderungen an den Festplattenspeicher zusätzlich zum des Betriebssystems. Je nach Ihren Anwendungen und Ihrem Netzwerkverkehr kann Ihre Installation benötigen mehr oder weniger Ressourcen als unten aufgeführt.

Installationskomponente

RAM

CPU

Mindestgröße der Festplatte

Cassandra

16 GB

8-Kern

250 GB lokaler Speicher mit SSD oder schnellem HDD, der 2.000 IOPS unterstützt

Nachrichtenprozessor/Router auf demselben Computer

8/16GB

4‐Kern

100GB

Analytics – Postgres/Qpid auf demselben Server (nicht für die Produktion empfohlen)

16GB*

8-Kern*

500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Back-End, Unterstützung von 1.000 IOPS oder höher*

Analytics – eigenständige Postgres

16GB*

8-Kern*

500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Back-End, mit mindestens 1.000 IOPS*.

Analytics – Qpid (eigenständig)

8 GB

4-Kern

30 GB bis 50 GB lokaler Speicher mit SSD oder schnellem HDD

Bei Installationen mit mehr als 250 TPS wird HDD mit lokalem Speicher, der 1.000 IOPS unterstützt, wird empfohlen.

Sonstiges (OpenLDAP, UI, Management Server)

4 GB

2-Kern

60 GB

† Systemanforderungen für Message Processor je nach Durchsatz anpassen:

Die Mindestempfehlung sind 4 Kerne und 8 Kerne für ein System mit hohem Durchsatz. Sie können Leistungstests durchführen, um die optimale Größe für Ihre APIs zu ermitteln.

*Postgres-Systemanforderungen basierend auf dem Durchsatz anpassen:

  • Weniger als 250 TPS: 8 GB, 4 Kerne können mit verwaltetem Netzwerkspeicher in Betracht gezogen werden.*** mit mindestens 1.000 IOPS
  • Über 250 TPS: 16 GB, 8-Kern, verwalteter Netzwerkspeicher*** mit Unterstützung für 1.000 IOPS oder höher
  • Über 1.000 TPS: 16 GB, 8-Kern, verwalteter Netzwerkspeicher*** mit Unterstützung für 2.000 IOPS oder höher
  • Über 2.000 TPS: 32 GB, 16-Kern, verwalteter Netzwerkspeicher*** mit Unterstützung für 2.000 IOPS oder höher
  • Über 4.000 TPS: 64 GB, 32-Kern, verwalteter Netzwerkspeicher*** mit Unterstützung für 4.000 IOPS oder höher

**Der Wert der Postgres-Festplatte basiert auf den vorkonfigurierten Analysen, die von Edge Wenn Sie den Analysedaten benutzerdefinierte Werte hinzufügen, sollten diese Werte entsprechend erhöht. Verwenden Sie die folgende Formel, um den erforderlichen Speicherplatz zu schätzen:

(# Byte/Anfrage) × (Anfragen pro Sekunde) × (Sekunden pro Stunde) × (Stunden mit Spitzennutzung pro Tag) × (Tage pro Monat) × (Monate der Datenaufbewahrung) = benötigte Byte an Speicherplatz

Beispiel:

(2.000 Byte Analysedaten pro Anfrage) * 100 Anfragen/Sek. * 3.600 Sek./Std. * 18-Stunden-Spitzenwert Nutzung pro Tag × 30 Tage/Monat × 3 Monate Aufbewahrung = 1.194.393.600.000 Byte oder 1.194,4 GB.

*** Für die Postgresql-Datenbank wird Netzwerkspeicher aus folgenden Gründen empfohlen:

  • Die Speichergröße lässt sich dynamisch skalieren, erforderlich.
  • Die Netzwerk-IOPS lassen sich in den meisten Umgebung/Speicher/Netzwerk-Subsysteme.
  • Snapshots auf Speicherebene können im Rahmen der Sicherung und Wiederherstellung aktiviert werden Lösungen zu finden.

Außerdem sind im Folgenden die Hardwareanforderungen aufgeführt, die für die Installation des Monetarisierungsdienste:

Komponente bei Monetarisierung

RAM

CPU

Festplatte

Verwaltungsserver (mit Monetarisierungsdiensten)

8 GB

4-Kern

60 GB

Analytics – Postgres/Qpid auf demselben Server

16 GB

8-Kern

500 GB bis 1 TB Netzwerkspeicher, vorzugsweise mit SSD-Back-End, Unterstützung für 1.000 IOPS oder oder die Regel aus der Tabelle oben verwenden.

Analytics – eigenständige Postgres

16 GB

8-Kern

500 GB bis 1 TB Netzwerkspeicher, vorzugsweise mit SSD-Back-End, Unterstützung für 1.000 IOPS oder oder die Regel aus der Tabelle oben verwenden.

Analytics – Qpid (eigenständig)

8 GB

4-Kern

40 GB

Im Folgenden sind die Hardwareanforderungen aufgeführt, wenn Sie API BaaS installieren möchten:

API BaaS-Komponente

RAM

CPU

Festplatte

ElasticSearch*

8 GB

4-Kern

60–80 GB

API-BaaS-Stack *

8 GB

4-Kern

60–80 GB

API-BaaS-Portal

1 GB

2-Kern

20GB

Cassandra (optional – in der Regel verwenden Sie denselben Cassandra-Cluster für beide Edge- und API BaaS-Dienste)

16 GB

8-Kern

250 GB lokaler Speicher mit SSD oder schnellem HDD, der 2.000 IOPS unterstützt

* Sie können ElasticSearch und API-BaaS-Stack auf demselben Knoten installieren. Wenn ja, ElasticSearch zur Verwendung von 4 GB Arbeitsspeicher konfigurieren (Standardeinstellung). Wenn ElasticSearch installiert ist auf einen eigenen Knoten erstellen und dann so konfigurieren, dass 6 GB Arbeitsspeicher verwendet werden.

Hinweis:

  • Ist das Root-Dateisystem nicht groß genug für die Installation, empfiehlt es sich, und legen Sie die Daten auf einem größeren Laufwerk ab.
  • Wenn eine ältere Version von Apigee Edge for Private Cloud auf dem Computer installiert ist, prüfen Sie, Löschen Sie vor einer Neuinstallation den Ordner /tmp/java.
  • Der systemweite temporäre Ordner /tmp benötigt Ausführungsberechtigungen, um starten Sie Cassandra.
  • Wenn der Benutzer „Apigee“ vor der Installation erstellt wurde, stellen Sie sicher, dass „/home/apigee“ existiert als Basisverzeichnis und gehört zu „Apigee:Apigee“.

Betriebssystem und Drittanbieter Softwareanforderungen

Diese Installationsanweisungen und die mitgelieferten Installationsdateien wurden auf dem Betriebssysteme und Software von Drittanbietern, die hier aufgeführt sind: https://apigee.com/docs/api-services/reference/supported-software.

Apigee-Benutzer erstellen

Bei der Installation wird ein Unix-Systemnutzer namens „apigee“ erstellt. Edge-Verzeichnisse und Dateien gehören zu „Apigee“, ebenso wie Edge-Prozessen. Das bedeutet, dass Edge-Komponenten als Apigee Nutzer. können Sie Komponenten bei Bedarf als ein anderer Nutzer ausführen. Siehe "Router binden" an einen geschützten Port“ im Abschnitt Edge-Komponenten auf einem Knoten.

Installationsverzeichnis

Standardmäßig schreibt das Installationsprogramm alle Dateien in das Verzeichnis /opt/apigee. Sie können dies nicht ändern Speicherort des Verzeichnisses.

In den Anweisungen in diesem Handbuch wird das Installationsverzeichnis als /<inst_root>/apigee bezeichnet, wobei /<inst_root> standardmäßig /opt ist.

Java

Auf jedem Rechner muss vor der Installation eine unterstützte Version von Java1.8 installiert sein. Unterstützte JDKs sind hier aufgeführt:

https://apigee.com/docs/api-services/reference/supported-software

JAVA_HOME-Punkte müssen vorhanden sein in das JDK-Stammverzeichnis für den Nutzer, der die Installation durchführt.

Netzwerkeinstellung

Es wird empfohlen, die Netzwerkeinstellungen vor der Installation zu überprüfen. Der Installateur erwartet, dass alle Maschinen feste IP-Adressen haben. Überprüfen Sie mit den folgenden Befehlen die Einstellung:

  • hostname gibt den Namen zurück. der Maschine
  • hostname -i gibt die IP-Adresse zurück. Adresse für den Hostnamen, der von anderen Computern adressiert werden kann.

Je nach Typ und Version Ihres Betriebssystems müssen Sie möglicherweise /etc/hosts und /etc/sysconfig/network bearbeiten, wenn der Hostname nicht richtig eingestellt ist. Weitere Informationen finden Sie in der Dokumentation zu Ihrem Betriebssystem.

Cassandra

Alle Cassandra-Knoten müssen mit einem Ring verbunden sein.

Cassandra passt die Größe des Java-Heaps basierend auf dem verfügbaren Arbeitsspeicher automatisch an. Weitere Informationen Siehe Java abstimmen Ressourcen Bei Leistungseinbußen oder hohem Arbeitsspeicherverbrauch.

Nach der Installation von Edge für Private Cloud können Sie prüfen, ob Cassandra konfiguriert ist korrekt, indem Sie /&lt;inst_root&gt;/apigee/apigee-cassandra/conf/cassandra.yaml -Datei. Achten Sie beispielsweise darauf, dass das Edge-Installationsskript für die Private Cloud Folgendes festlegt: Eigenschaften:

  • cluster_name
  • initial_token
  • Partitioner
  • Saatgut
  • listen_address
  • rpc_address
  • schnatz

Achtung: Bearbeiten Sie diese Datei nicht.

PostgreSQL-Datenbank

Nachdem Sie Edge installiert haben, können Sie die folgenden PostgreSQL-Datenbankeinstellungen basierend auf dem Verfügbarer RAM auf Ihrem System:

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

So legen Sie diese Werte fest:

  1. postgresql.properties bearbeiten:
    &gt; Vi /&lt;inst_root&gt;/apigee/customer/application/postgresql.properties

    Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
  2. Legen Sie die oben aufgeführten Eigenschaften fest.
  3. Speichern Sie die Änderungen.
  4. Starten Sie die PostgreSQL-Datenbank neu:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql neu starten

jsvc

„jsvc“ ist eine Voraussetzung für die Verwendung von API BaaS. Version 1.0.15-dev wird bei der Installation installiert das API BaaS.

Netzwerksicherheitsdienste (Network Security Services, NSS)

Network Security Services (NSS) besteht aus einer Reihe von Bibliotheken, die die Entwicklung von Client- und Serveranwendungen. Prüfen Sie, ob NSS installiert ist v3.19 oder höher.

So prüfen Sie Ihre aktuelle Version:

> yum info nss

So aktualisieren Sie NSS:

> yum update nss

Lesen Sie diesen Artikel von RedHat. .

AWS AMI

Wenn Sie Edge auf einem AWS Amazon Machine Image (AMI) für Red Hat Enterprise Linux installieren 7.x verwenden, müssen Sie zuerst den folgenden Befehl ausführen:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Tools

Das Installationsprogramm verwendet die folgenden UNIX-Tools in der Standardversion von EL5 oder EL6.

awk

Verz.-name

ls

U/min

unzip

Basisname

Echo

perl

rpm2cpio

Nutzer hinzufügen

bash

Expr

pgrep (von procps)

sed

wc

bc

grep

ps

tar

yum

curl

Hostname

pwd

tr

chkconfig

Datum

id

Python

Uname

sudo

Hinweis:

  • Die ausführbare Datei für das Tool „useradd“ befindet sich unter /usr/sbin und für chkconfig im Verzeichnis /sbin.
  • Mit dem sudo-Zugriff können Sie Zugriff auf die Umgebung des aufrufenden Benutzers erhalten, z. B. Normalerweise rufen Sie sudo <command> auf. „sudo PATH=$PATH:/usr/sbin:/sbin <Befehl>“.
  • Achten Sie darauf, dass das Patch-Tool vor einem Service Pack (Patch) installiert wurde. Installation.

ntpdate: Es wird empfohlen, die Serverzeit zu synchronisieren. Wenn noch nicht konfiguriert ist, könnte das Dienstprogramm "ntpdate" für diesen Zweck dienen. ob die Server zeitsynchron sind. Sie können yum install ntp verwenden, Dienstprogramm. Dies ist besonders nützlich, um OpenLDAP-Konfigurationen zu replizieren. Beachten Sie, dass Sie Server Zeitzone in UTC.

openldap 2.4: Für die lokale Installation ist OpenLDAP 2.4 erforderlich. Wenn hat Ihr Server eine Internetverbindung, dann wird das Edge-Installationsskript heruntergeladen und installiert. OpenLDAP. Wenn Ihr Server nicht über eine Internetverbindung verfügt, müssen Sie sicherstellen, dass OpenLDAP aktiviert ist. bereits installiert ist, bevor Sie das Edge-Installationsskript ausführen. Unter RHEL/CentOS können Sie „yum install openldap-clients openldap-servers&quot; um OpenLDAP zu installieren.

Bei Installationen mit 13 Hosts und 12 Hosts mit zwei Rechenzentren benötigen Sie OpenLDAP-Replikation, da OpenLDAP von mehreren Knoten gehostet wird.

Firewalls und virtuelle Hosts

Der Begriff „virtuell“ wird im IT-Bereich häufig überlastet, Apigee Edge für die Bereitstellung der privaten Cloud und virtuelle Hosts Zur Klarstellung: Es gibt zwei primäre des Begriffs „virtuell“:

  • Virtuelle Maschinen (VM): Nicht erforderlich, aber einige Bereitstellungen verwenden VM-Technologie um isolierte Server für die Apigee-Komponenten zu erstellen. VM-Hosts wie physische Hosts können Netzwerkschnittstellen und Firewalls. Diese Installationsanweisungen unterstützen VM-Installationen
  • Virtuelle Hosts: Webendpunkte, analog zu einem virtuellen Apache-Host.

Ein Router in einer VM kann mehrere virtuelle Hosts verfügbar machen (solange sie sich in in ihrem Host-Alias oder in ihrem Schnittstellenport).

Ein einzelner physischer Server A könnte z. B. zwei VMs ausführen, mit den Namen "VM1" und "VM2". Angenommen, VM1 stellt ein virtuelles Ethernet bereit. Schnittstelle mit dem Namen eth0. innerhalb der VM, der durch die Virtualisierung die IP-Adresse 111.111.111.111 zugewiesen wird. oder einem Netzwerk-DHCP-Server; Dann wird davon ausgegangen, dass VM2 eine virtuelle Ethernet-Schnittstelle bereitstellt. namens „eth0“, dem die IP-Adresse 111.111.111.222 zugewiesen wird.

In jeder der beiden VMs wird möglicherweise ein Apigee-Router ausgeführt. Die Router stellen virtuelle Hosts bereit wie in diesem hypothetischen Beispiel:

Der Apigee-Router in VM1 stellt drei virtuelle Hosts auf seiner eth0-Schnittstelle bereit (mit einigen bestimmte IP-Adresse), api.mycompany.com:80, api.mycompany.com:443 und test.mycompany.com:80.

Der Router in VM2 gibt api.mycompany.com:80 frei (derselbe Name und Port wie durch VM1 bereitgestellt werden.

Das Betriebssystem des physischen Hosts hat möglicherweise eine Netzwerkfirewall. Wenn ja, kann diese Firewall muss so konfiguriert sein, dass der TCP-Traffic an die Ports übergeben wird, die auf dem virtualisierten Schnittstellen (111.111.111.111:{80, 443} und 111.111.111.222:80). Darüber hinaus enthält jedes Das Betriebssystem der VM verfügt möglicherweise über eine eigene Firewall auf seiner eth0-Schnittstelle, und auch diese müssen Traffic über die Ports 80 und 443 zulassen.

Der Basispfad ist die dritte Komponente, die beim Weiterleiten von API-Aufrufen an verschiedene API-Proxys beteiligt ist die Sie möglicherweise eingesetzt haben. API-Proxy-Bundles können einen Endpunkt gemeinsam nutzen, wenn sie unterschiedliche Basispfade zu schaffen. Ein Basispfad kann beispielsweise als http://api.mycompany.com:80/ definiert werden und ein anderer definiert als http://api.mycompany.com:80/salesdemo.

In diesem Fall benötigen Sie einen Load-Balancer oder Traffic Director, der die http://api.mycompany.com:80/ Traffic zwischen den beiden IP-Adressen (111.111.111.111 auf VM1 und 111.111.111.222 auf VM2). Diese Funktion ist und wird von Ihrer lokalen Netzwerkgruppe konfiguriert.

Der Basispfad wird festgelegt, wenn Sie eine API bereitstellen. Im obigen Beispiel können Sie zwei APIs bereitstellen, mycompany und testmycompany für die Organisation mycompany-org mit dem virtuellen mit dem Host-Alias api.mycompany.com und dem Port auf 80 Wenn Sie kein Basispfad in der Bereitstellung befindet, weiß der Router nicht, welche API eingehende Anfragen senden soll. an.

Wenn Sie jedoch die API testmycompany mit der Basis-URL von /salesdemo: Nutzerzugriff für diese API mit http://api.mycompany.com:80/salesdemo verwenden. Wenn Sie Stellen Sie Ihre API „meinunternehmen“ mit der Basis-URL bereit / dann greifen Ihre Nutzer über die URL auf die API zu http://api.mycompany.com:80/.

Anforderungen an Edge-Ports

Die Verwaltung der Firewall geht über die virtuellen Hosts hinaus. sowohl VM als auch physischer Host Firewalls müssen Traffic für die Ports zulassen, die von den Komponenten benötigt werden, um mit den einzelnen Ports zu kommunizieren. Sonstiges.

Die folgende Abbildung zeigt die Portanforderungen für jede Edge-Komponente:

Hinweise zu diesem Diagramm:

  • *Port 8082 des Message Processor muss für den Router nur dann für den Zugriff geöffnet sein, wenn Sie TLS/SSL zwischen dem Router und dem Message Processor konfigurieren. Wenn Sie TLS/SSL nicht konfigurieren zwischen dem Router und dem Message Processor, der Standardkonfiguration, muss Port 8082 trotzdem im Message Processor geöffnet sein müssen, um die Komponente zu verwalten, aber der Router benötigt keine darauf zugreifen können.
  • Die Ports mit dem Präfix „M“ sind Ports, über die die Komponente verwaltet wird, und müssen auf dem Komponente für den Zugriff durch den Verwaltungsserver.
  • Die folgenden Komponenten erfordern Zugriff auf Port 8080 des Verwaltungsservers: Router, Message Processor, UI, Postgres und Qpid.
  • Ein Message Processor muss Port 4528 als Verwaltungsport öffnen. Wenn Sie mehrere Message Processors müssen alle über Port 4528 aufeinander zugreifen können (gekennzeichnet durch die Schleifenpfeil im obigen Diagramm für Port 4528 auf dem Message Processor). Wenn Sie mehrere Rechenzentren: Der Port muss von allen Message Processor in allen Rechenzentren zugänglich sein.
  • Port 4527 ist zwar nicht erforderlich, aber Sie können Port 4527 auf dem Router für eine beliebige Nachricht öffnen. Prozessor. Andernfalls werden möglicherweise Fehlermeldungen in den Message Processor-Protokolldateien angezeigt.
  • Ein Router muss Port 4527 als Verwaltungsport öffnen. Wenn Sie mehrere Router haben, müssen alle über Port 4527 aufeinander zugreifen können (gekennzeichnet durch einen Schleifenpfeil im Diagramm oben für Port 4527 am Router).
  • Die Edge-Benutzeroberfläche erfordert Zugriff auf den Router auf den Ports, die von API-Proxys zur Verfügung gestellt werden, um im Trace-Tool auf die Schaltfläche Senden.
  • Der Verwaltungsserver benötigt Zugriff auf den JMX-Port der Cassandra-Instanz Knoten.
  • Der Zugriff auf JMX-Ports kann so konfiguriert werden, dass ein Nutzername/Passwort erforderlich ist. Weitere Informationen finden Sie unter Monitoring.
  • Für bestimmte Verbindungen können Sie optional TLS/SSL-Zugriff konfigurieren, wobei unterschiedliche Ports. Weitere Informationen finden Sie unter TLS/SSL für mehr.
  • Wenn Sie zwei Postgres-Knoten für die Verwendung der Master-Stand-by-Replikation konfigurieren, müssen Sie Port 22 öffnen auf jedem Knoten für SSH-Zugriff. Sie können optional Ports auf einzelnen Knoten öffnen, SSH-Zugriff.
  • Sie können den Verwaltungsserver und die Edge-Benutzeroberfläche so konfigurieren, dass E-Mails über ein externes SMTP gesendet werden. Server. In diesem Fall müssen Sie sicherstellen, dass der Verwaltungsserver und die Benutzeroberfläche auf die erforderlichen auf dem SMTP-Server. Für Nicht-TLS-SMTP lautet die Portnummer normalerweise 25. Für TLS-fähiges SMTP ist er häufig 465. Wenden Sie sich an Ihren SMTP-Anbieter.

Die folgende Tabelle zeigt die Ports, die in Firewalls geöffnet werden müssen, nach Edge-Komponente:

Komponente

Port

Beschreibung

Standard-HTTP-Ports

80, 443

HTTP und alle anderen Ports, die Sie für virtuelle Hosts verwenden

Verwaltungsserver

8080

Port für Edge-Verwaltungs-API-Aufrufe. Diese Komponenten benötigen Zugriff auf Port 8080 auf Verwaltungsserver: Router, Message Processor, UI, Postgres und Qpid.

1099

JMX-Port

4526

Für verteilte Cache- und Verwaltungsaufrufe

Verwaltungs-UI

9000

Port für den Browserzugriff auf die Verwaltungsbenutzeroberfläche

Nachrichtenverarbeiter

8998

Message Processor-Port für die Kommunikation vom Router

8082

Standardverwaltungsport für Message Processor, der für die Komponente -Zugriff durch den Management-Server.

Wenn Sie TLS/SSL zwischen dem Router und dem vom Router verwendeten Message Processor konfigurieren um Systemdiagnosen für den Message Processor durchzuführen.

1101

JMX-Port

4528

Für verteilte Cache- und Verwaltungsaufrufe zwischen Message Processor und für Kommunikation vom Router

Router

8081

Standardverwaltungsport für Router, der für den Zugriff auf der Komponente geöffnet sein muss durch den Verwaltungsserver.

4527

Für verteilte Cache- und Verwaltungsaufrufe

15999

Port für Systemdiagnose Ein Load-Balancer ermittelt anhand dieses Ports, ob der Router verfügbar.

Um den Status eines Routers abzurufen, stellt der Load-Balancer eine Anfrage an Port 15999 auf der Router:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

Wenn der Router erreichbar ist, gibt die Anfrage HTTP 200 zurück.

ZooKeeper

2181

Wird von anderen Komponenten wie Management Server, Router, Message Processor usw. verwendet am

2888, 3888

Wird intern von ZooKeeper für ZooKeeper-Cluster verwendet (bekannt als ZooKeeper-Ensemble). Kommunikation

Cassandra

7.000, 9.042, 9.160

Apache Cassandra-Ports für die Kommunikation zwischen Cassandra-Knoten und für den Zugriff durch anderen Edge-Komponenten.

7199

JMX-Port. Muss für den Zugriff durch den Verwaltungsserver geöffnet sein.

Qpid

5672

Wird für die Kommunikation vom Router und dem Message Processor mit dem Qpid-Server verwendet

8083

Standardverwaltungsport auf dem Qpid-Server. Dieser Port muss für die Komponente -Zugriff durch den Management-Server.

1102

JMX-Port

4529

Für verteilte Cache- und Verwaltungsaufrufe

Postgres

5432

Wird für die Kommunikation vom Qpid/Management Server zu Postgres verwendet

8084

Standardverwaltungsport auf dem Postgres-Server und muss auf der Komponente für -Zugriff durch den Management-Server.

1103

JMX-Port

4530

Für verteilte Cache- und Verwaltungsaufrufe

22

Wenn Sie zwei Postgres-Knoten für die Verwendung der Master-Standby-Replikation konfigurieren, müssen Sie Port 22 auf jedem Knoten für SSH-Zugriff.

LDAP

10389

OpenLDAP

SmartDocs

59002

Der Port des Edge-Routers, an den SmartDocs-Seitenanfragen gesendet werden.

Hinweis: Möglicherweise müssen Sie zu Testzwecken auch Ports in den Firewalls öffnen. Für z. B. 59001 usw.

Die nächste Tabelle zeigt dieselben Ports, numerisch aufgelistet, mit der Quelle und dem Ziel Komponenten:

Portnummer

Zweck

Quellkomponente

Zielkomponente

<virtueller Host-Port#>

HTTP sowie alle anderen Ports, die Sie für den Traffic der virtuellen Host-API nutzen. Ports 80 und 443 werden am häufigsten verwendet. kann der Message Router TLS/SSL-Verbindungen beenden.

Externer Client (oder Load-Balancer)

Listener auf Message Router

1.099 bis 1.103

JMX-Verwaltung

JMX-Client

Verwaltungsserver (1099)

Message Processor (1101)

QPID-Server (1102)

Postgres-Server (1103)

2.181

Zookeeper-Clientkommunikation

Verwaltungsserver

Router

Message Processor

QPID-Server

Postgres-Server

Zookeeper

2888 und 3888

Zookeeper-Interknotenverwaltung

Zookeeper

Zookeeper

4526 bis 4530

RPC-Verwaltungsports, die für den verteilten Cache und Aufrufe von den Verwaltungsservern verwendet werden zu den anderen Komponenten,

Verwaltungsserver

Verwaltungsserver (4526)

Router (4527)

Message Processor (4528)

QPID-Server (4529)

Postgres-Server (4530)

4.528

Für verteilte Cache-Aufrufe zwischen Message Processor und zur Kommunikation vom Router

Router

Message Processor

Message Processor

5.432

Postgres-Client

QPID-Server

Postgres

5.672

Wird zum Senden von Analysen vom Router und Message Processor an Qpid verwendet

Router

Message Processor

QPID-Server

7.000

Cassandra-Kommunikation zwischen Knoten

Cassandra

Anderer Cassandra-Knoten

7.199

JMX-Verwaltung. Muss für den Zugriff auf dem Cassandra-Knoten durch das Management offen sein Server.

JMX-Client

Cassandra

8080

Management API-Port

Verwaltungs-API-Clients

Verwaltungsserver

8081 bis 8084

Component API-Ports, die verwendet werden, um API-Anfragen direkt an einzelne Komponenten zu senden. Jede Komponente öffnet einen anderen Port. der genaue verwendete Port hängt von der Konfiguration ab muss aber für den Zugriff durch den Management Server für die Komponente geöffnet sein.

Verwaltungs-API-Clients

Router (8081)

Message Processor (8082)

Qpid-Server (8083)

Postgres-Server (8084)

8.998

Kommunikation zwischen Router und Message Processor

Router

Message Processor

9.000

Standard-Port für Edge-Verwaltungs-Benutzeroberfläche

Browser

Verwaltungs-UI-Server

9.042

Nativer CQL-Transport

Router

Message Processor

Verwaltungsserver

Cassandra

9.160

Cassandra-Secondhandkäufe

Router

Message Processor

Verwaltungsserver

Cassandra

10.389

LDAP-Port

Verwaltungsserver

OpenLDAP

15.999 Port für Systemdiagnose Ein Load-Balancer ermittelt anhand dieses Ports, ob der Router verfügbar. Load-Balancer Router

59.002

Der Routerport, an den SmartDocs-Seitenanfragen gesendet werden

SmartDocs

Router

Ein Nachrichtenprozessor hält einen dedizierten Verbindungspool für Cassandra offen, der konfiguriert wird dass keine Zeitüberschreitung auftritt. Wenn sich eine Firewall zwischen einem Nachrichtenprozessor und dem Cassandra-Server befindet, eine Zeitüberschreitung durch die Firewall. Der Message Processor ist jedoch nicht darauf ausgelegt, Verbindungen zu Cassandra wiederherstellen.

Um diese Situation zu vermeiden, empfiehlt Apigee, den Cassandra-Server, den Message Processor und die sich im selben Subnetz befinden, damit keine Firewall an der Bereitstellung beteiligt ist. Komponenten.

Wenn sich zwischen dem Router und dem Nachrichtenprozessor eine Firewall befindet und für die ein inaktives TCP-Zeitlimit festgelegt ist, unsere Empfehlungen:

  1. Legen Sie net.ipv4.tcp_keepalive_time = 1.800 in den sysctl-Einstellungen unter Linux-Betriebssystem, wobei 1.800 niedriger sein sollte als der Wert für die Inaktivität der Firewall TCP-Zeitlimit. Mit dieser Einstellung sollte die Verbindung in einem bestehenden Status gehalten werden, damit der trennt die Firewall die Verbindung nicht.
  2. Bearbeiten Sie bei allen Message Processors /&lt;inst_root&gt;/apigee/customer/application/message-processor.properties um die folgende Eigenschaft hinzuzufügen. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. Starten Sie den Message Processor neu:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor neustart
  4. Bearbeiten Sie auf allen Routern /&lt;inst_root&gt;/apigee/customer/application/router.properties. um die folgende Eigenschaft hinzuzufügen. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. Starten Sie den Router neu:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-Router-Neustart

Wenn Sie die Konfiguration mit 12 Host-Clustern mit zwei Rechenzentren installieren, achten Sie darauf, dass die Knoten in den beiden Rechenzentren können über die unten gezeigten Ports kommunizieren:

Anforderungen an API-BaaS-Ports

Wenn Sie sich für die Installation von API BaaS entscheiden, fügen Sie die Komponenten API BaaS Stack und API BaaS Portal hinzu. Diese Komponenten verwenden die in der folgenden Abbildung dargestellten Ports:

Hinweise zu diesem Diagramm:

  • Die Cassandra-Knoten können für API BaaS dediziert oder für Edge freigegeben werden.
  • Bei einer Produktionsinstallation von API BaaS wird ein Load-Balancer zwischen dem API-BaaS-Portalknoten verwendet und API-BaaS-Stack-Knoten. Wenn Sie das Portal konfigurieren und BaaS API-Aufrufe ausführen, geben Sie die IP-Adresse oder den DNS-Namen des Load-Balancers an, nicht der Stackknoten.
  • Sie müssen alle Baas-Stack-Knoten so konfigurieren, dass E-Mails über einen externen SMTP-Server gesendet werden. Für nicht TLS, lautet die Portnummer normalerweise 25. Für TLS-fähiges SMTP ist der Wert oft 465, aber prüfen Sie mit Ihrem SMTP-Anbieter.

Die folgende Tabelle zeigt die Standardports, die in Firewalls geöffnet werden müssen, nach Komponente:

Komponente

Port

Beschreibung

API BaaS-Portal

9000

Port für die BaaS-UI der API

API-BaaS-Stack

8080

Port, an dem die API-Anfrage empfangen wird

ElasticSearch

9.200 bis 9.400

Zur Kommunikation mit dem API-BaaS-Stack und zwischen ElasticSearch Knoten

Lizenzierung

Für jede Edge-Installation ist eine eindeutige Lizenzdatei erforderlich, die Sie von Apigee erhalten. Sie werden müssen bei der Installation des Verwaltungsservers den Pfad zur Lizenzdatei angeben, z. B. /tmp/license.txt.

Das Installationsprogramm kopiert die Lizenzdatei nach /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

Wenn die Lizenzdatei gültig ist, validiert der Verwaltungsserver den Ablauf und die zulässige Nachricht Anzahl der Prozessoren (MP). Sollte eine der Lizenzeinstellungen abgelaufen sein, finden Sie die Protokolle in der Speicherort: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. In diesem Fall können Sie sich an den Apigee-Support wenden: Migrationsdetails.