Voraussetzungen für die Installation

Edge for Private Cloud v4.18.01

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 16 GB 8-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, mit mindestens 1.000 IOPS*
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.

Die Standardgröße der Qpid-Warteschlange beträgt 20 GB. Wenn Sie mehr Kapazität benötigen, fügen Sie Qpid-Knoten

Sonstiges (OpenLDAP, UI, Management Server) 4 GB 2-Kern 60 GB

* Postgres-Systemanforderungen basierend auf dem Durchsatz anpassen:

  • Weniger als 250 TPS: 8 GB, 4 Kerne können für ein verwaltetes Netzwerk in Betracht gezogen werden Speicher*** mit mindestens 1.000 IOPS
  • Über 250 TPS: 16 GB, 8-Kern, verwalteter Netzwerkspeicher*** mit mindestens 1.000 IOPS
  • Über 1.000 TPS: 16 GB, 8-Kern, verwalteter Netzwerkspeicher*** mit mindestens 2.000 IOPS
  • Über 2.000 TPS: 32 GB, 16-Kern, verwalteter Netzwerkspeicher*** mit mindestens 2.000 IOPS
  • Über 4.000 TPS: 64 GB, verwalteter Netzwerkspeicher mit 32 Kernen*** mit mindestens 4.000 IOPS

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

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

Beispiel:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.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 können 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 mit 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 bis 500 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.

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** 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.

** Optional; In der Regel verwenden Sie denselben Cassandra-Cluster sowohl für Edge als auch für API BaaS. Dienste.

Betriebssystem und Drittanbieter Softwareanforderungen

Diese Installationsanweisungen und die mitgelieferten Installationsdateien wurden auf dem Betriebssysteme und Software von Drittanbietern, die in Unterstützte Software und unterstützte Versionen

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.

Installationsverzeichnis

Standardmäßig schreibt das Installationsprogramm alle Dateien in das Verzeichnis /opt/apigee. Ich kann diesen Verzeichnisspeicherort nicht ändern. Sie können dieses Verzeichnis zwar nicht ändern, aber Sie können ein symlink verwenden, um /opt/apigee einem anderen Standort zuzuordnen, wie unten beschrieben.

In den Anweisungen dieses Handbuchs wird das Installationsverzeichnis wie folgt gekennzeichnet: /opt/apigee

Einen Symlink aus /opt/apigee erstellen

Bevor Sie den Symlink erstellen, müssen Sie zuerst einen Benutzer und eine Gruppe mit dem Namen „apigee“ erstellen. Dies ist dieselbe Gruppe und denselben Nutzer, die vom Edge-Installationsprogramm erstellt wurden.

Führen Sie zum Erstellen des Symlink die folgenden Schritte aus, bevor Sie die Datei bootstrap_4.18.01.sh herunterladen. Sie müssen alle folgenden Schritte als Root ausführen:

  1. Apigee erstellen Nutzer und Gruppe:
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. Erstellen Sie einen Symlink von /opt/apigee zum gewünschten Installationsstamm:
    ln -Ts /srv/myInstallDir /opt/apigee

    Dabei ist /srv/myInstallDir der gewünschte Speicherort der Edge-Dateien.

  3. Ändern Sie die Inhaberschaft von Installationsstamm und Symlink in „apigee“. Nutzer:
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Auf jedem Rechner muss vor der Installation eine unterstützte Version von Java 1.8 installiert sein. Unterstützte JDKs sind aufgeführt in Unterstützte Software und unterstützte Versionen

Achten Sie darauf, dass JAVA_HOME auf das Stammverzeichnis des JDK für den Nutzer verweist, der die Installation.

SELinux

Abhängig von Ihren Einstellungen für SELinux können bei Edge Probleme beim Installieren und Starten Edge-Komponenten Falls nötig, können Sie SELinux deaktivieren oder während der und nach der Installation wieder aktivieren. Weitere Informationen finden Sie unter Edge-Apigee-Setup-Dienstprogramm installieren.

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 der Maschine zurück.
  • hostname -i gibt die IP-Adresse für den Hostnamen zurück, der von auf anderen Geräten.

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

Wenn ein Server mehrere Schnittstellenkarten hat, gibt der „hostname -i“ gibt den Befehl eine Liste der IP-Adressen. Standardmäßig verwendet das Edge-Installationsprogramm die erste zurückgegebene IP-Adresse, die ist möglicherweise nicht in allen Situationen korrekt. Alternativ können Sie die folgende Eigenschaft in der Konfigurationsdatei für die Installation:

ENABLE_DYNAMIC_HOSTIP=y

Wenn dieses Attribut auf „y“ gesetzt ist, werden Sie vom Installationsprogramm aufgefordert, die IP-Adresse auszuwählen, die als ein Teil der Installation ist. Der Standardwert ist „n“. Weitere Informationen finden Sie unter Referenz zu Edge-Konfigurationsdateien.

TCP-Wrapper

TCP-Wrapper können die Kommunikation einiger Ports blockieren und sich auf OpenLDAP, Postgres und Cassandra-Installation. Prüfen Sie auf diesen Knoten /etc/hosts.allow und /etc/hosts.deny, um sicherzustellen, dass für den erforderlichen OpenLDAP-, Postgres- und Cassandra-Ports

iptables

Stellen Sie sicher, dass es keine iptables-Richtlinien gibt, die die Konnektivität zwischen Knoten auf der erforderlichen Edge-Ports. Bei Bedarf können Sie iptables während der Installation mit der Methode Befehl:

sudo/etc/init.d/iptables stop

Unter CentOS 7.x:

systemctl stop firewalld

Achten Sie darauf, dass Edge Router Zugriff auf /etc/rc.d/init.d/functions

Die Edge-Router- und BaaS-Portal-Knoten verwenden den Nginx-Router und benötigen Lesezugriff an /etc/rc.d/init.d/functions.

Wenn Sie im Rahmen Ihres Sicherheitsprozesses /etc/rc.d/init.d/functions, setzen Sie sie nicht auf 700, da sonst der Router beginnen. Berechtigungen können auf 744 gesetzt werden, um Lesezugriff auf /etc/rc.d/init.d/functions

Cassandra

Alle Cassandra-Knoten müssen mit einem Ring verbunden sein. Cassandra speichert Datenreplikate um für Zuverlässigkeit und Fehlertoleranz zu sorgen. Die Replikationsstrategie der einzelnen Der Edge-Schlüsselraum bestimmt die Cassandra-Knoten, in denen Replikate platziert werden. Weitere Informationen finden Sie unter Über Cassandra Replikationsfaktor und Konsistenzebene.

Cassandra passt die Größe des Java-Heaps basierend auf dem verfügbaren Arbeitsspeicher automatisch an. Weitere Informationen finden Sie unter Feinabstimmung Java-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 richtig, indem Sie sich die /opt/apigee/apigee-cassandra/conf/cassandra.yaml ansehen -Datei. Achten Sie beispielsweise darauf, dass das Edge-Installationsskript für die Private Cloud Folgendes festlegt: Eigenschaften:

  • cluster_name
  • initial_token
  • partitioner
  • seeds
  • listen_address
  • rpc_address
  • snitch

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. Bearbeiten Sie die Datei postgresql.properties:
    vi /opt/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:
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Systemlimits

Stellen Sie sicher, dass Sie die folgenden Systemlimits für Cassandra und Message Processor festgelegt haben. Knoten:

  • Legen Sie auf Cassandra-Knoten Soft- und Hard-Memlock-, Nofile- und Adressbereichs-Limits für Installationsnutzer (Standard ist „apigee“) in /etc/security/limits.d/90-apigee-edge-limits.conf wie unten dargestellt:
    apigee soft memlock unlimited
    apigee hard memlock unlimited
    apigee soft nofile 32768
    apigee hard nofile 65536
    apigee soft as unlimited
    apigee hard as unlimited
  • Legen Sie für Message Processor-Knoten die maximale Anzahl geöffneter Dateideskriptoren auf 64.000 fest. in /etc/security/limits.d/90-apigee-edge-limits.conf als (siehe unten):
    apigee soft nofile 32768
    apigee hard nofile 65536

    Bei Bedarf können Sie dieses Limit erhöhen. Wenn Sie z. B. viele vorübergehende die Dateien gleichzeitig geöffnet sind.

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 erhalten Sie weitere Informationen.

DNS-Lookup für IPv6 deaktivieren bei Verwendung von NSCD (Name Service Cache Daemon)

Wenn Sie NSCD (Name Service Cache Daemon) installiert und aktiviert haben, sind die Message Processors führt zwei DNS-Lookups durch: eine für IPv4 und eine für IPv6. Deaktivieren Sie den DNS-Lookup für IPv6 bei Verwendung von NSCD.

So deaktivieren Sie den DNS-Lookup unter IPv6:

  1. Bearbeiten Sie /etc/nscd.conf auf jedem Message Processor-Knoten.
  2. Legen Sie die folgende Eigenschaft fest:
    enable-cache hosts no

IPv6 in Google Cloud deaktivieren Plattform für RedHat/CentOS 7

Wenn Sie Edge unter RedHat 7 oder CentOS 7 auf der Google Cloud Platform installieren, muss IPv6 auf allen Qpid-Knoten deaktivieren.

In der RedHat- oder CentOS-Dokumentation für Ihre spezifische Betriebssystemversion finden Sie eine Anleitung zum Deaktivieren von IPv6 Beispiele:

  1. Öffnen Sie /etc/hosts in einem Editor.
  2. „#“ einfügen in Spalte 1 der folgenden Zeile ein, um es auszukommentieren:
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Speichern Sie die Datei.

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

Expr

libxslt

U/min

unzip

Basisname

grep

lua-socket

rpm2cpio

Nutzer hinzufügen

bash

Hostname

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

Libaio

Perl (von Anbietern)

tar

Xerces-C

Cyrus-Sasl libdb4 pgrep (von procps) tr yum

Datum

libdb-cxx

ps

uuid

chkconfig

Verz.-name Libibverbs pwd Uname  
Echo librdmacm Python    

ntpdate

Es wird empfohlen, die Mal synchronisiert. Falls noch nicht konfiguriert, Das ntpdate-Dienstprogramm eignet sich für diesen Zweck, das überprüft, ob die Server zeitsynchron sind. Sie können yum install ntp verwenden, um die Dienstprogramm. Dies ist besonders nützlich, um OpenLDAP-Konfigurationen zu replizieren. Beachten Sie, dass Sie Server Zeitzone in UTC.

openldap 2.4

Die lokale Installation erfordert OpenLDAP 2.4. 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, 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 virtual 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 Verwendung des Begriffs virtual:

  • 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.
  • 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 beispielsweise zwei VMs ausführen, mit dem Namen „VM1“ und „VM2“. Nehmen wir an, „VM1“ eine virtuelle Ethernet-Schnittstelle bereitstellt, die benannt wird, „eth0“ innerhalb der VM, die die IP-Adresse 111.111.111.111 durch Virtualisierungsmaschinen oder ein Netzwerk-DHCP-Server; und gehen dann davon aus, dass VM2 eine virtuelle Ethernet-Schnittstelle auch mit dem Namen „eth0“ und ihr wird eine IP-Adresse 111.111.111.222.

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 (gleicher 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 (111.111.111.111:{80, 443} und 111.111.111.222:80). Darüber hinaus enthält jedes Das Betriebssystem der VM kann auf seiner eth0-Schnittstelle eine eigene Firewall bereitstellen, die ebenfalls 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 eine weitere ist als http://api.mycompany.com:80/salesdemo definiert.

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 durch den virtuellen Host mit dem Host-Alias von api.mycompany.com und der Port auf 80 festgelegt. 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 /salesdemo, dann greifen Nutzer über http://api.mycompany.com:80/salesdemo Wenn Sie die API mycompany mit dem Basis-URL von / eingeben, greifen die 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 und muss für den Zugriff durch den Management Server auf der Komponente geöffnet sein.
  • 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 Weitere Informationen finden Sie unter How to Monitor.
  • 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
Verwaltungsoberfläche 9000 Port für den Browserzugriff auf die Verwaltungsbenutzeroberfläche
Message Processor 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 und dem Verwaltungsserver
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.

59001 Port, der zum Testen der Edge-Installation durch das Dienstprogramm apigee-validate verwendet wird. Dieses Dienstprogramm benötigt Zugriff auf Port 59001 des Routers. Weitere Informationen finden Sie unter Testen Sie die Installation, um mehr über Port 59001 zu erfahren.
ZooKeeper 2181 Wird von anderen Komponenten wie Management Server, Router, Message Processor usw. verwendet
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 für den Zugriff auf der Komponente geöffnet sein durch den Verwaltungsserver.
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.

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

Portnummer Zweck Quellkomponente Zielkomponente
virtual_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
1099 bis 1103 JMX-Verwaltung JMX-Client Verwaltungsserver (1099)
Message Processor (1101)
QPID-Server (1102)
Postgres-Server (1103)
2181 Zookeeper-Clientkommunikation Verwaltungsserver
Router
Message Processor
QPID-Server
Postgres-Server
Zookeeper
2888 und 3888 Zookeeper-Interknotenverwaltung Zookeeper Zookeeper
4526 Port für die RPC-Verwaltung Verwaltungsserver Verwaltungsserver
4527 Port für die RPC-Verwaltung für verteilte Cache- und Verwaltungsaufrufe sowie für die Kommunikation zwischen Routern Verwaltungsserver
Router
Router
4528 Für verteilte Cache-Aufrufe zwischen Message Processor und zur Kommunikation vom Router Verwaltungsserver
Router
Message Processor
Message Processor
4529 RPC-Verwaltungsport für verteilten Cache und Verwaltungsaufrufe Verwaltungsserver QPID-Server
4530 RPC-Verwaltungsport für verteilten Cache und Verwaltungsaufrufe Verwaltungsserver Postgres-Server
5432 Postgres-Client QPID-Server Postgres
5672

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

Router
Message Processor
QPID-Server
7000 Cassandra-Kommunikation zwischen Knoten Cassandra Anderer Cassandra-Knoten
7199 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)
8998 Kommunikation zwischen Router und Message Processor Router Message Processor
9000 Standard-Port für Edge-Verwaltungs-Benutzeroberfläche Browser Verwaltungs-UI-Server
9042 Nativer CQL-Transport Router
Message Processor
Verwaltungsserver
Cassandra
9160 Cassandra-Secondhandkäufe Router
Message Processor
Verwaltungsserver
Cassandra
10389 LDAP-Port Verwaltungsserver OpenLDAP
15999 Port für Systemdiagnose Ein Load-Balancer ermittelt anhand dieses Ports, ob der Router verfügbar. Load-Balancer Router
59001 Port, der vom Dienstprogramm apigee-validate zum Testen der Edge-Installation verwendet wird apigee-validate Router
59002 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 = 1800 in den sysctl-Einstellungen unter Linux fest, wobei 1.800 sollte niedriger sein als das TCP-Timeout für die Inaktivität der Firewall. Mit dieser Einstellung sollte das Verbindung hergestellt wird, damit die Firewall die Verbindung nicht trennt.
  2. Bearbeiten Sie in allen Message Processors /opt/apigee/customer/application/message-processor.properties um die folgende Eigenschaft hinzuzufügen. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. Starten Sie den Message Processor neu:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. Auf allen Routern /opt/apigee/customer/application/router.properties bearbeiten um die folgende Eigenschaft hinzuzufügen. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. Starten Sie den Router neu:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart

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:

  • Das BaaS-Portal der API sendet niemals direkte Anfragen an einen BaaS-Stackknoten. Wenn ein Entwickler sich im Portal anmeldet, wird die Portal-App in den Browser heruntergeladen. Die Portal-App wird ausgeführt in sendet der Browser dann Anfragen an die BaaS-Stack-Knoten.
  • 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.
  • Alle Stack-Knoten müssen für den Zugriff von allen anderen Stack-Knoten Port 2551 öffnen (gekennzeichnet durch die Schleifenpfeil im obigen Diagramm für Port 2551 auf den Stack-Knoten). Wenn Sie mehrere Daten In den Rechenzentren muss der Port von allen Stackknoten in allen Rechenzentren aus zugänglich sein.
  • 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 Cassandra-Knoten können für API BaaS dediziert oder für Edge freigegeben werden.

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
2551

Port für die Kommunikation zwischen allen Stackknoten. Muss für alle anderen Stacks zugänglich sein Knoten im Data Canter.

Wenn Sie mehrere Rechenzentren haben, muss der Port von allen Stack-Knoten in in allen Rechenzentren.

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 /opt/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 folgende Position: /opt/apigee/var/log/edge-management-server/logs. In diesem Fall können Sie sich an den Apigee Edge-Support wenden, um Details zur Migration zu erhalten.

Wenn Sie noch keine Lizenz haben, wenden Sie sich an den Apigee-Vertrieb.