Voraussetzungen für die Installation

Edge for Private Cloud Version 4.17.05

Hardware Requirements

Für eine hochverfügbare Infrastruktur in einer produktionstauglichen Umgebung müssen Sie die folgenden Mindesthardwareanforderungen erfüllen. Für alle unter Installationstopologien beschriebenen Installationsszenarien werden in den folgenden Tabellen die Mindesthardwareanforderungen für die Installationskomponenten aufgeführt.

In diesen Tabellen gelten die Festplattenanforderungen zusätzlich zum Festplattenspeicher, der vom Betriebssystem benötigt wird. Je nach Ihren Anwendungen und Ihrem Netzwerkverkehr benötigt Ihre Installation möglicherweise 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 mit 2.000 IOPS

Message Processor/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, Unterstützung für mindestens 1.000 IOPS*.

Analytics – Postgres eigenständig

16GB*

8-Kern*

500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Back-End, Unterstützung für mindestens 1.000 IOPS*.

Analytics – eigenständiges Qpid-Protokoll

8 GB

4-Kern

Lokaler Speicher von 30 bis 50 GB mit SSD oder schnellem HDD

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

Die Standardgröße der Qpid-Warteschlange beträgt 20 GB. Wenn Sie mehr Kapazität hinzufügen möchten, fügen Sie zusätzliche Qpid-Knoten hinzu.

Sonstiges (OpenLDAP, UI, Management Server)

4 GB

2-Kern

60 GB

*Passen Sie die Systemanforderungen von Postgres basierend auf dem Durchsatz an:

  • Weniger als 250 TPS: 8 GB, 4 Kerne eignen sich für einen verwalteten Netzwerkspeicher***, der 1.000 IOPS oder mehr unterstützt.
  • Mehr als 250 TPS: 16 GB, verwalteter Netzwerkspeicher mit 8 Kernen***, der mindestens 1.000 IOPS unterstützt
  • Mehr als 1.000 TPS: Verwalteter Netzwerkspeicher mit 16 GB und 8 Kernen*** unterstützt mindestens 2.000 IOPS
  • Mehr als 2.000 TPS: 32 GB verwalteter Netzwerkspeicher mit 16 Kernen*** mit Unterstützung von mindestens 2.000 IOPS
  • Mehr als 4.000 TPS: 64 GB, verwalteter Netzwerkspeicher mit 32 Kernen***, unterstützt mindestens 4.000 IOPS

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

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

Beispiel:

(2.000 Byte Analysedaten pro Anfrage × 0,0 Byte Analysedaten pro Anfrage × 0,0 Byte Analysedaten pro Anfrage × 0,0 Byte der Analysedaten pro Anfrage × 0,0 Byte der Analysedaten pro Anfrage × 0,0 Byte der Analysedaten pro Anfrage × 0,0 Byte der Analysedaten pro Anfrage × 0,0 Byte der Analysedaten pro Anfrage × 0,0 Byte der Anfragen pro Sekunde × 0,0 Byte der Analysedaten × 100 Byte pro Anfrage × 3 Sek. / 60 Stunden × 3 Sek. Aufbewahrung pro Sekunde × 3 Sek./60 Stunden × 30 Byte der Analysedaten pro Tag mit der folgenden Formel.

*** Netzwerkspeicher wird aus folgenden Gründen für eine Postgresql-Datenbank empfohlen:

  • Er bietet die Möglichkeit, die Speichergröße bei Bedarf dynamisch zu skalieren.
  • Netzwerk-IOPS können in den meisten modernen Umgebungs-/Speicher-/Netzwerk-Subsystemen spontan angepasst werden.
  • Snapshots auf Speicherebene können im Rahmen von Sicherungs- und Wiederherstellungslösungen aktiviert werden.

Außerdem finden Sie hier die Hardwareanforderungen für die Installation der 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

Netzwerkspeicher mit 500 GB bis 1 TB, vorzugsweise mit SSD-Back-End, der mindestens 1.000 IOPS unterstützt, oder verwenden Sie die Regel aus der obigen Tabelle.

Analytics – Postgres eigenständig

16 GB

8-Kern

Netzwerkspeicher mit 500 GB bis 1 TB, vorzugsweise mit SSD-Back-End, der mindestens 1.000 IOPS unterstützt, oder verwenden Sie die Regel aus der obigen Tabelle.

Analytics – eigenständiges Qpid-Protokoll

8 GB

4-Kern

Lokaler Speicher von 40 bis 500 GB mit SSD oder schnellem HDD

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

Im Folgenden sind die Hardwareanforderungen für die Installation von API-BaaS aufgeführt:

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 sowohl für Edge- als auch für API-BaaS-Dienste)

16 GB

8-Kern

250 GB lokaler Speicher mit SSD oder schnellem HDD mit 2.000 IOPS

* Sie können ElasticSearch und den API-BaaS-Stack auf demselben Knoten installieren. Konfigurieren Sie in diesem Fall ElasticSearch für die Verwendung von 4 GB Arbeitsspeicher (Standardeinstellung). Wenn ElasticSearch auf einem eigenen Knoten installiert ist, konfigurieren Sie ihn für die Verwendung von 6 GB Arbeitsspeicher.

Hinweise:

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

Anforderungen an Betriebssysteme und Software von Drittanbietern

Diese Installationsanleitung und die bereitgestellten Installationsdateien wurden auf den hier aufgeführten Betriebssystemen und der hier aufgeführten Drittanbieter-Software getestet: https://apigee.com/docs/api-services/reference/supported-software.

Apigee-Nutzer erstellen

Das Installationsverfahren erstellt einen Unix-Systembenutzer mit dem Namen „apigee“. Edge-Verzeichnisse und -Dateien gehören zu Apigee, ebenso wie Edge-Prozesse. Dies bedeutet, dass Edge-Komponenten als der Apigee-Benutzer ausgeführt werden. Bei Bedarf können Sie Komponenten als ein anderer Benutzer ausführen. Ein Beispiel finden Sie unter Edge-Komponenten auf einem Knoten installieren unter "Router an einen geschützten Port binden".

Installationsverzeichnis

Standardmäßig schreibt das Installationsprogramm alle Dateien in das Verzeichnis /opt/apigee. Sie können diesen Verzeichnisspeicherort nicht ändern. Sie können dieses Verzeichnis zwar nicht ändern, aber einen Symlink erstellen, um /opt/apigee einem anderen Speicherort zuzuordnen, wie unten beschrieben.

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

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 derselbe Nutzer, die vom Edge-Installationsprogramm erstellt wurden.

Führen Sie diese Schritte aus, bevor Sie die Datei bootstrap_4.17.01.sh herunterladen, um den Symlink zu erstellen. Sie müssen alle diese Schritte als Root ausführen:

  1. Erstellen Sie den Benutzer „apigee“ und die Gruppe:
    > groupadd -r apigee
    > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c „Apigee Plattformnutzer“ apigee
  2. Erstellen Sie einen Symlink von /opt/apigee zum gewünschten Installationsstammverzeichnis:
    > ln -Ts /srv/myInstallDir /opt/apigee
    , wobei /srv/myInstallDir der gewünschte Speicherort der Edge-Dateien ist.
  3. Ändern Sie die Inhaberschaft des Installationsstamms und von Symlink zum Benutzer „apigee“:
    > chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Auf jedem Computer muss vor der Installation eine unterstützte Version von Java 1.8 installiert sein. Unterstützte JDKs sind hier aufgeführt:

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

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

SELinux

Abhängig von Ihren Einstellungen für SELinux können in Edge Probleme beim Installieren und Starten von Edge-Komponenten auftreten. Bei Bedarf können Sie SELinux während der Installation deaktivieren oder auf den mäßigen Modus einstellen und nach der Installation wieder aktivieren. Weitere Informationen finden Sie unter Edge-Dienstprogramm für Apigee-Einrichtung installieren.

Netzwerkeinstellung

Es wird empfohlen, die Netzwerkeinstellung vor der Installation zu überprüfen. Das Installationsprogramm erwartet, dass alle Maschinen feste IP-Adressen haben. Verwenden Sie die folgenden Befehle, um die Einstellung zu validieren:

  • hostname gibt den Namen des Computers zurück.
  • hostname -i gibt die IP-Adresse des Hostnamens zurück, der von anderen Rechnern angesprochen werden kann.

Je nach Betriebssystemtyp und -version müssen Sie möglicherweise /etc/hosts und /etc/sysconfig/network bearbeiten, wenn der Hostname nicht richtig festgelegt ist. Weitere Informationen finden Sie in der Dokumentation Ihres Betriebssystems.

TCP-Wrapper

TCP-Wrapper können die Kommunikation einiger Ports blockieren und die Installation von OpenLDAP, Postgres und Cassandra beeinträchtigen. Prüfen Sie auf diesen Knoten /etc/hosts.allow und /etc/hosts.deny, damit für die erforderlichen OpenLDAP-, Postgres- und Cassandra-Ports keine Porteinschränkungen gelten.

iptables

Prüfen Sie, ob es keine iptables-Richtlinien gibt, die die Verbindung zwischen Knoten an den erforderlichen Edge-Ports verhindern. Bei Bedarf können Sie iptables während der Installation mit dem folgenden Befehl beenden:

> sudo/etc/init.d/iptables stop

Unter CentOS 7.x:

> systemctl stop firewalld

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

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

Wenn Ihr Sicherheitsprozess es erfordert, Berechtigungen für /etc/rc.d/init.d/functions festzulegen, setzen Sie diese nicht auf 700, da der Router sonst nicht gestartet werden kann. Berechtigungen können auf 744 gesetzt werden, um den Lesezugriff auf /etc/rc.d/init.d/functions zuzulassen.

Cassandra

Alle Cassandra-Knoten müssen mit einem Ring verbunden sein. Cassandra speichert Datenreplikate auf mehreren Knoten, um Zuverlässigkeit und Fehlertoleranz zu gewährleisten. Die Replikationsstrategie für jeden Edge-Schlüsselraum bestimmt die Cassandra-Knoten, an denen Replikate platziert werden. Weitere Informationen finden Sie unter Cassandra-Replikationsfaktor und Konsistenzstufe.

Cassandra passt seine Java-Heap-Größe automatisch anhand des verfügbaren Speichers an. Weitere Informationen finden Sie unter Java-Ressourcen optimieren. Im Falle einer Leistungsbeeinträchtigung oder eines hohen Arbeitsspeicherverbrauchs.

Nach der Installation von Edge for Private Cloud können Sie überprüfen, ob Cassandra richtig konfiguriert ist, indem Sie die Datei /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml untersuchen. Achten Sie beispielsweise darauf, dass das Edge for Private Cloud-Installationsskript die folgenden Attribute festgelegt hat:

  • cluster_name
  • initial_token
  • Partitioner
  • samen
  • listen_address
  • rpc_address
  • Snitch

Warnung: Bearbeiten Sie diese Datei nicht.

PostgreSQL-Datenbank

Nachdem Sie Edge installiert haben, können Sie die folgenden PostgreSQL-Datenbankeinstellungen anhand des auf Ihrem System verfügbaren Arbeitsspeichers anpassen:

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 postgresql.properties:
    > vi /<inst_root>/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:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql-Neustart

Systemlimits

Achten Sie darauf, dass Sie die folgenden Systemlimits für Cassandra- und Message Processor-Knoten festgelegt haben:

  • Legen Sie auf Cassandra-Knoten die Grenzwerte für weiche und harte Memlock, Nofile und Adressraum (als) für den Installationsnutzer (Standard ist „apigee“) in /etc/security/limits.d/90-apigee-edge-limits.conf wie unten fest:
    apigee soft memlock unbegrenzt
    apigeefest apigee apigee unbegrenzt
    apigee Soft nofile 32768 ohne fest
    6 unbegrenzt


  • Legen Sie auf Message Processor-Knoten die maximale Anzahl geöffneter Dateideskriptoren in /etc/security/limits.d/90-apigee-edge-limits.conf wie unten gezeigt auf 64.000 fest:
    /etc/security/limits.d/90-apigee-edge-limits.conf

    Bei Bedarf können Sie dieses Limit erhöhen. Dies ist beispielsweise der Fall, wenn gleichzeitig eine große Anzahl temporärer Dateien geöffnet ist.

JVCC

„jsvc“ ist eine Voraussetzung für die Verwendung der API BaaS. Version 1.0.15-dev wird installiert, wenn Sie die API BaaS installieren.

Netzwerksicherheitsdienste (NSS)

Network Security Services (NSS) besteht aus einer Reihe von Bibliotheken, die die Entwicklung von sicherheitsfähigen Client- und Serveranwendungen unterstützen. Sie müssen NSS v3.19 oder höher installiert haben.

So überprüfen Sie Ihre aktuelle Version:

> yum info nss

So aktualisieren Sie NSS:

> yum update nss

Weitere Informationen finden Sie in diesem Artikel von RedHat.

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

Wenn Sie NSCD (Name Service Cache Daemon) installiert und aktiviert haben, führen die Nachrichtenprozessoren zwei DNS-Lookups durch: eine für IPv4 und eine für IPv6. Wenn Sie NSCD verwenden, sollten Sie den DNS-Lookup für IPv6 deaktivieren.

So deaktivieren Sie den DNS-Lookup für IPv6:

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

IPv6 auf der Google Cloud Platform für RedHat/CentOS 7 deaktivieren

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

Anweisungen zum Deaktivieren von IPv6 finden Sie in der RedHat- oder CentOS-Dokumentation für Ihre spezifische Betriebssystemversion. Sie können z. B.

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

AWS-AMI

Wenn Sie Edge auf einem AWS Amazon Machine Image (AMI) für Red Hat Enterprise Linux 7.x installieren, 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

Lua-Socket

AZ/min

unzip

basename

grep

ls

rpm2cpio

Nutzer hinzufügen

bash

Hostname

net-tools

sed

wc

bc

id

perl (von procps)

sudo

wget

curl

Libaio

pgrep (von procps)

tar

Xerces-C

Cyrus-Sasl
libdb-cxx
ps tr Mmmhh, lecker

date

Liibverbien

pwd

uuid

Chkconfig

dirname
Librdmacm
python Uname
echo
libxslt

Hinweis:

  • Die ausführbare Datei für das Tool „useradd“ befindet sich in /usr/sbin und für „chkconfig“ in /sbin.
  • Mit sudo-Zugriff erhalten Sie Zugriff über die Umgebung des aufrufenden Nutzers. Zum Beispiel würden Sie normalerweise „sudo <command>“ oder „sudo PATH=$PATH:/usr/sbin:/sbin <command>“ aufrufen.
  • Vor der Installation eines Service Packs (Patches) muss das Patchtool installiert sein.

ntpdate: Es wird empfohlen, die Zeit der Server zu synchronisieren. Wenn es nicht bereits konfiguriert ist, kann das Dienstprogramm „ntpdate“ diesen Zweck erfüllen, das prüft, ob Server zeitsynchron sind. Mit yum install ntp können Sie das Dienstprogramm installieren. Dies ist besonders nützlich, um OpenLDAP-Konfigurationen zu replizieren. Sie haben die Serverzeitzone in UTC eingerichtet.

openldap 2.4: Die lokale Installation erfordert OpenLDAP 2.4. Wenn Ihr Server eine Internetverbindung hat, lädt das Edge-Installationsskript OpenLDAP herunter und installiert es. Wenn Ihr Server keine Internetverbindung hat, müssen Sie sicherstellen, dass OpenLDAP bereits installiert ist, bevor Sie das Edge-Installationsskript ausführen. Unter RHEL/CentOS können Sie yum install openldap-clients openldap-servers ausführen, um OpenLDAP zu installieren.

Für Installationen mit 13 Hosts und 12 Hosts mit zwei Rechenzentren benötigen Sie die OpenLDAP-Replikation, da OpenLDAP auf mehreren Knoten gehostet wird.

Firewalls und virtuelle Hosts

Der Begriff „virtuell“ wird im IT-Bereich häufig überlastet, daher wird er mit einem Apigee Edge für die Bereitstellung einer privaten Cloud und virtuelle Hosts verwendet. Zur Klarstellung: Der Begriff „virtuell“ wird hauptsächlich auf zwei Arten verwendet:

  • Virtuelle Maschinen (VM): nicht erforderlich, aber bei einigen Bereitstellungen werden mithilfe von VM-Technologie isolierte Server für ihre Apigee-Komponenten erstellt. VM-Hosts können wie physische Hosts Netzwerkschnittstellen und Firewalls haben.
  • 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 ihrem Hostalias oder ihrem Schnittstellenport voneinander unterscheiden.

Beispiel: Ein einzelner physischer Server A kann zwei VMs mit den Namen „VM1“ und „VM2“ ausführen. Angenommen, VM1 stellt eine virtuelle Ethernet-Schnittstelle zur Verfügung, die innerhalb der VM die IP-Adresse 111.111.111.111 erhält und der dann von der Virtualisierungsmaschine mit IP1.1.1 eine Schnittstelle 1.1.1 und einem Netzwerk mit dem Namen „Ethernet1.1“ eine Schnittstelle 1.1 und DHCP2 erhält und dann eine virtuelle Schnittstelle 1.1 und DHCP2-Server mit dem Namen „Ethernet1.1“ und dem Netzwerk „Ethernet1.1.2“ ausgibt und außerdem eine virtuelle Ethernet-Schnittstelle und DHCP2-Server mit dem Namen eth0 erhält.

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

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

Der Router in VM2 macht api.mycompany.com:80 verfügbar (derselbe Name und derselbe Port wie von VM1 bereitgestellt).

Das Betriebssystem des physischen Hosts hat möglicherweise eine Netzwerkfirewall. In diesem Fall muss diese Firewall so konfiguriert sein, dass der TCP-Traffic an die Ports weitergeleitet wird, die auf den virtualisierten Schnittstellen (111.111.111.111:{80, 443} und 111.111.111.222:80) freigegeben werden. Darüber hinaus kann das Betriebssystem jeder VM eine eigene Firewall auf der eth0-Schnittstelle bereitstellen. Auch diese muss die Verbindung von Traffic über die Ports 80 und 443 zulassen.

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

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

Der Basispfad wird beim Bereitstellen einer API festgelegt. Im obigen Beispiel können Sie zwei APIs, mycompany und testmycompany, für die Organisation mycompany-org mit dem virtuellen Host mit dem Hostalias api.mycompany.com und dem Port auf 80 bereitstellen. Wenn Sie in der Bereitstellung keinen Basispfad angeben, weiß der Router nicht, an welche API eingehende Anfragen gesendet werden sollen.

Wenn Sie jedoch die API testmycompany mit der Basis-URL /salesdemo bereitstellen, greifen Nutzer über http://api.mycompany.com:80/salesdemo auf diese API zu. Wenn Sie die API „mycompany“ mit der Basis-URL / bereitstellen, greifen Ihre Nutzer über die URL http://api.mycompany.com:80/ auf die API zu.

Edge-Port-Anforderungen

Die Notwendigkeit, die Firewall zu verwalten, geht über die virtuellen Hosts hinaus. Sowohl VM- als auch physische Host-Firewalls müssen Traffic für die Ports zulassen, die von den Komponenten zur Kommunikation untereinander benötigt werden.

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

Hinweise zu diesem Diagramm:

  • *Port 8082 auf dem Message Processor muss nur für den Zugriff durch den Router offen sein, wenn Sie TLS/SSL zwischen dem Router und dem Message Processor konfigurieren. Wenn Sie TLS/SSL nicht zwischen dem Router und dem Message Processor konfigurieren, muss Port 8082 zur Verwaltung der Komponente weiterhin auf dem Message Processor als Standardkonfiguration geöffnet sein, der Router benötigt jedoch keinen Zugriff darauf.
  • Die Ports mit dem Präfix „M“ sind Ports, die zur Verwaltung der Komponente verwendet werden. Sie müssen in der Komponente und in der Komponente für den Zugriff durch den Verwaltungsserver geöffnet sein.
  • Die folgenden Komponenten benötigen Zugriff auf Port 8080 auf dem Management Server: Router, Message Processor, UI, Postgres und Qpid.
  • Ein Message Processor muss Port 4528 als Verwaltungsport öffnen. Wenn Sie mehrere Message Processor haben, müssen alle über Port 4528 aufeinander zugreifen können (wird im obigen Diagramm durch den Schleifenpfeil für Port 4528 auf dem Message Processor angegeben). Wenn Sie mehrere Rechenzentren haben, muss der Port von allen Message Processorn in allen Rechenzentren zugänglich sein.
  • Sie können Port 4527 auf dem Router für den Zugriff durch jeden Message Processor öffnen, obwohl dies nicht erforderlich ist. Andernfalls werden möglicherweise Fehlermeldungen in den Protokolldateien des Nachrichtenverarbeiters angezeigt.
  • Ein Router muss Port 4527 als Verwaltungsport öffnen. Wenn Sie mehrere Router haben, müssen alle über Port 4527 aufeinander zugreifen können. In der obigen Abbildung ist dies durch den Schleifenpfeil für Port 4527 auf dem Router gekennzeichnet.
  • Die Edge-Benutzeroberfläche benötigt Zugriff auf den Router auf den von API-Proxys freigegebenen Ports, um die Schaltfläche Senden im Trace-Tool zu unterstützen.
  • Der Management Server benötigt Zugriff auf den JMX-Port auf den Cassandra-Knoten.
  • Der Zugriff auf JMX-Ports kann so konfiguriert werden, dass ein Nutzername und ein Passwort erforderlich sind. Weitere Informationen finden Sie unter Monitoring.
  • Sie können optional den TLS/SSL-Zugriff für bestimmte Verbindungen konfigurieren, die unterschiedliche Ports verwenden können. Weitere Informationen finden Sie unter TLS/SSL.
  • Wenn Sie zwei Postgres-Knoten für die Verwendung der Master-Standby-Replikation konfigurieren, müssen Sie Port 22 auf jedem Knoten für den SSH-Zugriff öffnen. Sie können optional Ports auf einzelnen Knoten öffnen, um den SSH-Zugriff zuzulassen.
  • Sie können den Management Server und die Edge-UI so konfigurieren, dass E-Mails über einen externen SMTP-Server gesendet werden. Achten Sie in diesem Fall darauf, dass der Verwaltungsserver und die UI auf den erforderlichen Port auf dem SMTP-Server zugreifen können. Für Nicht-TLS-SMTP lautet die Portnummer normalerweise 25. Bei TLS-fähigem SMTP ist es häufig 465. Wenden Sie sich an Ihren SMTP-Anbieter.

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

Komponente

Port

Beschreibung

Standard-HTTP-Ports

80, 443

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

Verwaltungsserver

8080

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

1099

JMX-Port

4526

Für verteilten Cache und Verwaltungsaufrufe

Verwaltungs-UI

9000

Port für den Browserzugriff auf die Verwaltungsoberfläche

Nachrichtenverarbeiter

8998

Port des Message Processor für die Kommunikation vom Router

8082

Standardverwaltungsport für den Message Processor. Er muss für den Zugriff durch den Verwaltungsserver in der Komponente geöffnet sein.

Wenn Sie TLS/SSL zwischen dem Router und dem Message Processor konfigurieren, das vom Router für Systemdiagnosen des Message Processor verwendet wird.

1101

JMX-Port

4528

Für verteilten Cache und Verwaltungsaufrufe zwischen Message Processorn und für die Kommunikation vom Router

Router

8081

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

4527

Für verteilten Cache und Verwaltungsaufrufe

15999

Port für Systemdiagnose. Ein Load-Balancer verwendet diesen Port, um festzustellen, ob der Router verfügbar ist.

Um den Status eines Routers abzurufen, sendet der Load-Balancer eine Anfrage an Port 15999 des Routers:

> 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 vom Dienstprogramm apigee-validate verwendet wird. Dieses Dienstprogramm benötigt Zugriff auf Port 59001 auf dem Router. Weitere Informationen zu Port 59001 finden Sie unter Installation testen.

ZooKeeper

2181

Wird von anderen Komponenten wie Verwaltungsserver, Router, Message Processor usw. verwendet

2.888, 3.888

Wird intern von ZooKeeper für die ZooKeeper-Clusterkommunikation (bekannt als ZooKeeper-Ensemble) verwendet

Cassandra

7.000, 9.042, 9.160

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

7199

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

Qpid

5672

Wird für die Kommunikation zwischen dem Router und dem Message Processor zum Qpid-Server verwendet

8083

Standardverwaltungsport auf dem Qpid-Server. Er muss für den Zugriff durch den Verwaltungsserver in der Komponente geöffnet sein.

1102

JMX-Port

4529

Für verteilten Cache und Verwaltungsaufrufe

Postgres

5432

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

8084

Standardverwaltungsport auf dem Postgres-Server. Er muss in der Komponente für den Zugriff durch den Verwaltungsserver geöffnet sein.

1103

JMX-Port

4530

Für verteilten 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 den SSH-Zugriff öffnen.

LDAP

10389

OpenLDAP

SmartDocs

59002

Der Port im Edge-Router, an den SmartDocs-Seitenanfragen gesendet werden.

Die nächste Tabelle enthält dieselben Ports, numerisch aufgelistet mit den Quell- und Zielkomponenten:

Portnummer

Zweck

Quellkomponente

Zielkomponente

<Port-Nr. des virtuellen Hosts>

HTTP sowie alle anderen Ports, die Sie für den Aufruftraffic der virtuellen Host-API verwenden. Die Ports 80 und 443 werden am häufigsten verwendet. Der Message Router kann 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)

2.181

Zookeeper-Clientkommunikation

Verwaltungsserver

Router

Message Processor

Qpid-Server

Postgres-Server

Zookeeper

2.888 und 3.888

Internode-Verwaltung für Zookeeper

Zookeeper

Zookeeper

4.526

RPC-Verwaltungsport

Verwaltungsserver

Verwaltungsserver

4.527 RPC-Verwaltungsport für verteilte Cache- und Verwaltungsaufrufe sowie für die Kommunikation zwischen Routern

Verwaltungsserver

Router

Router

4.528

Für verteilte Cache-Aufrufe zwischen Nachrichtenprozessoren und für die Kommunikation vom Router

Verwaltungsserver

Router

Message Processor

Message Processor

4.529 RPC-Verwaltungsport für verteilten Cache und Verwaltungsaufrufe Verwaltungsserver Qpid-Server
4.530 RPC-Verwaltungsport für verteilten Cache und Verwaltungsaufrufe Verwaltungsserver Postgres-Server

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

7000

Knotenübergreifende Cassandra-Kommunikation

Cassandra

Anderer Cassandra-Knoten

7.199

JMX-Verwaltung. Muss vom Verwaltungsserver für den Zugriff auf dem Cassandra-Knoten geöffnet sein.

JMX-Client

Cassandra

8080

Verwaltungs-API-Port

Management API-Clients

Verwaltungsserver

8081 bis 8084

Component API-Ports, mit denen API-Anfragen direkt an einzelne Komponenten gesendet werden Jede Komponente öffnet einen anderen Port. Der genaue Port, der verwendet wird, hängt von der Konfiguration ab, muss aber auf der Komponente für den Zugriff durch den Verwaltungsserver offen sein

Management 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

Standardmäßiger Port der Edge-Management-Benutzeroberfläche

Browser

Management-UI-Server

9.042

Nativer CQL-Transport

Router

Message Processor

Verwaltungsserver

Cassandra

9.160

Cassandra-Secondhand-Client

Router

Message Processor

Verwaltungsserver

Cassandra

10.389

LDAP-Port

Verwaltungsserver

OpenLDAP

15.999

Port für Systemdiagnose. Ein Load-Balancer verwendet diesen Port, um festzustellen, ob der Router verfügbar ist.

Load-Balancer Router
59.001 Port, der vom Dienstprogramm apigee-validate zum Testen der Edge-Installation verwendet wird apigee-validate Router

59.002

Routerport, an den SmartDocs-Seitenanfragen gesendet werden

SmartDocs

Router

Ein Nachrichtenprozessor hält einen dedizierten Verbindungspool für Cassandra offen, die so konfiguriert ist, dass es nie zu einer Zeitüberschreitung kommt. Wenn sich eine Firewall zwischen einem Nachrichtenprozessor und einem Cassandra-Server befindet, kann es zu einer Zeitüberschreitung bei der Verbindung kommen. Der Nachrichtenprozessor ist jedoch nicht dafür ausgelegt, Verbindungen zu Cassandra wiederherzustellen.

Um diese Situation zu verhindern, empfiehlt Apigee, dass sich der Cassandra-Server, der Nachrichtenprozessor und die Router im selben Subnetz befinden, damit keine Firewall an der Bereitstellung dieser Komponenten beteiligt ist.

Wenn sich zwischen dem Router und den Nachrichtenprozessoren eine Firewall befindet und ein Zeitlimit für inaktive TCP-Verbindungen festgelegt ist, empfehlen wir Folgendes:

  1. Legen Sie unter Linux in den sysctl-Einstellungen net.ipv4.tcp_keepalive_time = 1800 fest, wobei 1.800 niedriger als das TCP-Zeitlimit bei Inaktivität der Firewall sein sollte. Mit dieser Einstellung sollte die Verbindung in einem bestehenden Zustand bleiben, damit die Firewall sie nicht unterbricht.
  2. Bearbeiten Sie auf allen Message Processorn /<inst_root>/apigee/customer/application/message-processor.properties zum Hinzufügen der folgenden Eigenschaft. Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  3. Starten Sie den Meldungsprozessor neu:
    > /opt/apigee/apigee-service/bin/apigee-service-Edge-Message-processor-Neustart
  4. Bearbeiten Sie auf allen Routern /<inst_root>/apigee/customer/application/router.properties, 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-Neustart

Wenn Sie die Konfiguration mit 12 Hostclustern mit zwei Rechenzentren installieren, müssen die Knoten in den beiden Rechenzentren über die unten dargestellten Ports kommunizieren können:

Anforderungen an den API-BaaS-Port

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

Hinweise zu diesem Diagramm:

  • Das API-BaaS-Portal stellt niemals Anfragen direkt an einen BaaS-Stackknoten. Wenn sich ein Entwickler im Portal anmeldet, wird die Portal-App in den Browser heruntergeladen. Die im Browser ausgeführte Portal-App sendet dann Anfragen an die BaaS-Stack-Knoten.
  • Bei einer Produktionsinstallation von API BaaS wird ein Load-Balancer zwischen dem API-BaaS-Portalknoten und den API-BaaS-Stack-Knoten verwendet. Bei der Konfiguration des Portals und bei BaaS API-Aufrufen geben Sie die IP-Adresse oder den DNS-Namen des Load-Balancers an und nicht der Stack-Knoten.
  • Alle Stack-Knoten müssen für den Zugriff von allen anderen Stack-Knoten Port 2551 öffnen. Dies wird im obigen Diagramm durch den Schleifenpfeil für Port 2551 auf den Stack-Knoten gekennzeichnet. Wenn Sie mehrere Rechenzentren haben, muss der Port von allen Stack-Knoten in allen Rechenzentren 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-SMTP lautet die Portnummer in der Regel 25. Bei TLS-fähigem SMTP ist dies häufig 465. Wenden Sie sich jedoch an Ihren SMTP-Anbieter.
  • Die Cassandra-Knoten kann für API BaaS reserviert oder mit Edge gemeinsam genutzt werden.

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

Komponente

Port

Beschreibung

API-BaaS-Portal

9000

Port für die API-BaaS-UI

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 Stack-Knoten im Daten-Canter zugänglich sein.

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

ElasticSearch

9.200 bis 9.400

Für die Kommunikation mit dem API-BaaS-Stack und zwischen ElasticSearch-Knoten

Lizenzierung

Jede Installation von Edge erfordert eine eindeutige Lizenzdatei, die Sie von Apigee erhalten. Bei der Installation des Verwaltungsservers müssen Sie den Pfad zur Lizenzdatei angeben, z. B. /tmp/license.txt.

Das Installationsprogramm kopiert die Lizenzdatei in /<inst_root>/apigee/customer/conf/license.txt.

Wenn die Lizenzdatei gültig ist, validiert der Verwaltungsserver das Ablaufdatum und die Anzahl der zulässigen MP (Message Processor). Wenn eine der Lizenzeinstellungen abgelaufen ist, finden Sie die Logs an folgendem Speicherort: /<inst_root>/apigee/var/log/edge-management-server/logs. Informationen zur Migration erhalten Sie vom Apigee-Support.

Wenn Sie noch keine Lizenz haben, kontaktieren Sie den Vertrieb hier.