Hardwareanforderungen
Für eine hoch verfügbare Infrastruktur in einer Produktionsumgebung müssen Sie die folgenden Mindestanforderungen an die Hardware erfüllen.
Im folgenden Video erhalten Sie allgemeine Informationen zur Dimensionierung Ihrer Installation:
In den folgenden Tabellen sind die Mindestanforderungen an die Hardware für die Installationskomponenten für alle in Installationstopologien beschriebenen Installationsszenarien aufgeführt.
In diesen Tabellen kommen die Anforderungen an die Festplatte zusätzlich zum vom Betriebssystem benötigten Festplattenspeicher hinzu. Je nach Ihren Anwendungen und dem Netzwerkverkehr benötigt Ihre Installation möglicherweise mehr oder weniger Ressourcen als unten aufgeführt.
Installationskomponente | RAM | CPU | Mindestens erforderliche Festplatte |
---|---|---|---|
Cassandra | 16 GB | 8-Kern | 250 GB lokaler Speicher mit SSD, die 2.000 IOPS unterstützt |
Nachrichtenprozessor/Router auf demselben Computer | 16 GB | 8-Kern | 100 GB |
Message Processor (eigenständig) | 16 GB | 8-Kern | 100 GB |
Router (eigenständig) | 16 GB | 8-Kern | 100 GB |
Analytics – Postgres/Qpid auf demselben Server | 16 GB* | 8 Kerne* | 500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Backend, mit einer Unterstützung von mindestens 1.000 IOPS* |
Analytics – Postgres-Master oder -Standby (eigenständig) | 16 GB* | 8-Core* | 500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Backend, mit einer Unterstützung von mindestens 1.000 IOPS* |
Analytics – Qpid-Standalone | 8 GB | 4-Kern | 30 GB bis 50 GB lokaler SSD-Speicher
Die Standardgröße der Qpid-Warteschlange beträgt 1 GB und kann auf 2 GB erhöht werden. Wenn Sie mehr Kapazität benötigen, fügen Sie zusätzliche Qpid-Knoten hinzu. |
OpenLDAP/UI/Management Server | 8 GB | 4-Kern | 60 GB |
Benutzeroberfläche/Verwaltungsserver | 4 GB | 2 Kerne | 60 GB |
OpenLDAP (eigenständig) | 4 GB | 2 Kerne | 60 GB |
* Passen Sie die Postgres-Systemanforderungen an den Durchsatz an:
** Der Wert für die Postgres-Festplatte basiert auf den standardmäßigen Analysen, die von Edge erfasst werden. Wenn Sie den Analysedaten benutzerdefinierte Werte hinzufügen, sollten diese Werte entsprechend erhöht werden. Mit der folgenden Formel können Sie den erforderlichen Speicherplatz schätzen:
Beispiel:
*** Netzwerkspeicher wird für PostgreSQL-Datenbanken empfohlen, da:
|
Außerdem findest du hier die Hardwareanforderungen, wenn du die Monetarisierungsdienste installieren möchtest (nicht bei der All-in-One-Installation unterstützt):
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-Backend, mit einer Unterstützung von mindestens 1.000 IOPS oder die Regel aus der Tabelle oben |
Analytics – Postgres-Master oder Standalone-Standby | 16 GB | 8-Kern | 500 GB bis 1 TB Netzwerkspeicher, vorzugsweise mit SSD-Backend, mit einer Unterstützung von mindestens 1.000 IOPS oder die Regel aus der Tabelle oben |
Analytics – Qpid-Standalone | 8 GB | 4-Kern | 40 GB bis 500 GB lokaler Speicher mit SSD oder schneller HDD
Für Installationen mit mehr als 250 TPS wird eine Festplatte mit lokalem Speicher mit 1.000 IOPS empfohlen. |
Cassandra-Netzwerkbandbreitenanforderungen
Cassandra verwendet das Gossip-Protokoll für den Austausch von Informationen mit anderen Knoten zur Netzwerktopologie. Die Verwendung von Gossip in Kombination mit der verteilten Natur von Cassandra, bei der für Lese- und Schreibvorgänge mit mehreren Knoten kommuniziert wird, führt zu einer erheblichen Datenübertragung über das Netzwerk.
Cassandra benötigt eine Mindestnetzwerkbandbreite von 1 Gbit/s pro Knoten. Für Produktionsinstallationen wird eine höhere Bandbreite empfohlen.
Die maximale Latenz bzw. die Latenz des 99. Perzentils für Cassandra sollte unter 100 Millisekunden liegen.
Anforderungen an das Betriebssystem und Drittanbietersoftware
Diese Installationsanleitung und die bereitgestellten Installationsdateien wurden auf den Betriebssystemen und mit der Drittanbietersoftware getestet, die unter Unterstützte Software und unterstützte Versionen aufgeführt sind.
Java
Auf jedem Computer muss vor der Installation eine unterstützte Version von Java 1.8 installiert sein. Unterstützte JDKs sind unter Unterstützte Software und unterstützte Versionen aufgeführt.
Die Umgebungsvariable JAVA_HOME
muss auf das Stammverzeichnis des JDK für den Nutzer verweisen, der die Installation durchführt.
SELinux
Je nach Ihren Einstellungen für SELinux kann es bei Edge zu Problemen bei der Installation und dem Starten von Edge-Komponenten kommen. Bei Bedarf können Sie SELinux während der Installation deaktivieren oder in den permissiven Modus versetzen und es nach der Installation wieder aktivieren. Weitere Informationen finden Sie unter Installieren Sie das Hilfsprogramm für das Edge-Apigee-Setup.
Nutzer „apigee“ erstellen
Bei der Installation wird ein Unix-Systemnutzer mit dem Namen „apigee“ erstellt. Die Eigentümer von Edge-Verzeichnissen und ‑Dateien sind „apigee“, ebenso wie die von Edge-Prozessen. Das bedeutet, dass Edge-Komponenten als Nutzer „apigee“ ausgeführt werden. Bei Bedarf können Sie Komponenten als anderer Nutzer ausführen.
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 unter Symlink von /opt/apigee erstellen beschrieben.
In der Anleitung in diesem Leitfaden wird das Installationsverzeichnis als /opt/apigee
bezeichnet.
Symlink von /opt/apigee erstellen
Bevor Sie den Symlink erstellen, müssen Sie zuerst einen Nutzer und eine Gruppe mit dem Namen „apigee“ erstellen. Dies ist dieselbe Gruppe und derselbe Nutzer, die bzw. der vom Edge-Installationsprogramm erstellt wurde.
Führen Sie die folgenden Schritte aus, um den Symlink zu erstellen, bevor Sie die Datei „bootstrap_4.52.02.sh“ herunterladen. Sie müssen alle diese Schritte als Root ausführen:
- Erstellen Sie den Nutzer und die Gruppe „apigee“:
groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
- Erstellen Sie einen Symlink von
/opt/apigee
zum gewünschten Installationsstammverzeichnis:ln -Ts /srv/myInstallDir /opt/apigee
Dabei ist /srv/myInstallDir der gewünschte Speicherort der Edge-Dateien.
- Ändern Sie die Eigentümerschaft des Installationsstammverzeichnisses und des Symlinks in „apigee“:
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Werbenetzwerkeinstellung
Apigee empfiehlt, die Netzwerkeinstellungen vor der Installation zu prüfen. Das Installationsprogramm erwartet, dass alle Maschinen feste IP-Adressen haben. Prüfen Sie die Einstellung mit den folgenden Befehlen:
hostname
gibt den Namen des Computers zurück.hostname -i
gibt die IP-Adresse für den Hostnamen zurück, die von anderen Maschinen aus 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.
Wenn ein Server mehrere Schnittstellenkarten hat, gibt der Befehl „hostname -i“ eine durch Leerzeichen getrennte Liste von IP-Adressen zurück. Standardmäßig verwendet das Edge-Installationsprogramm die erste zurückgegebene IP-Adresse, was nicht in allen Fällen korrekt sein kann. Alternativ können Sie die folgende Eigenschaft in der Installationskonfigurationsdatei festlegen:
ENABLE_DYNAMIC_HOSTIP=y
Wenn diese Eigenschaft auf „y“ festgelegt ist, werden Sie vom Installationsprogramm aufgefordert, die IP-Adresse auszuwählen, die bei der Installation verwendet werden soll. Der Standardwert ist „n“. Weitere Informationen finden Sie in der Referenz zur Edge-Konfigurationsdatei.
TCP-Wrapper
TCP-Wrapper können die Kommunikation einiger Ports blockieren und sich auf die Installation von OpenLDAP, Postgres und Cassandra auswirken. Prüfen Sie auf diesen Knoten unter /etc/hosts.allow
und /etc/hosts.deny
, ob es keine Portbeschränkungen für die erforderlichen OpenLDAP-, Postgres- und Cassandra-Ports gibt.
iptables
Prüfen Sie, ob es keine iptables-Richtlinien gibt, die die Verbindung zwischen Knoten an den erforderlichen Edge-Ports verhindern. Falls erforderlich, können Sie iptables während der Installation mit dem folgenden Befehl beenden:
sudo/etc/init.d/iptables stop
Auf CentOS 7.x:
systemctl stop firewalld
Verzeichniszugriff
In der folgenden Tabelle sind Verzeichnisse auf Edge-Knoten aufgeführt, für die Edge-Prozesse spezielle Anforderungen haben:
Dienst | Verzeichnis | Beschreibung |
---|---|---|
Router | /etc/rc.d/init.d/functions |
Der Edge-Router verwendet den Nginx-Router und benötigt Lesezugriff auf Wenn Sie aufgrund Ihres Sicherheitsprozesses Berechtigungen für Sie können die Berechtigungen auf 744 festlegen, um Lesezugriff auf |
Zookeeper | /dev/random |
Die Zookeeper-Clientbibliothek benötigt Lesezugriff auf den Zufallszahlengenerator /dev/random . Wenn /dev/random beim Lesen blockiert ist, kann der Zookeeper-Dienst möglicherweise nicht gestartet werden. |
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üsselbereich bestimmt die Cassandra-Knoten, an denen Replikate platziert werden. Weitere Informationen finden Sie unter Cassandra-Replikationsfaktor und Konsistenzgrad.
Cassandra passt die Größe des Java-Heaps automatisch an den verfügbaren Arbeitsspeicher an. Weitere Informationen finden Sie unter Java-Ressourcen optimieren, wenn die Leistung beeinträchtigt ist oder der Arbeitsspeicherverbrauch hoch ist.
Nach der Installation von Edge for Private Cloud können Sie prüfen, ob Cassandra richtig konfiguriert ist. Sehen Sie sich dazu die Datei /opt/apigee/apigee-cassandra/conf/cassandra.yaml
an. Achten Sie beispielsweise darauf, dass im Installationsskript für Edge für Private Cloud die folgenden Eigenschaften festgelegt sind:
cluster_name
initial_token
partitioner
seeds
listen_address
rpc_address
snitch
PostgreSQL-Datenbank
Nach der Installation von Edge können Sie die folgenden PostgreSQL-Datenbankeinstellungen entsprechend der auf Ihrem System verfügbaren RAM-Kapazität 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:
- Bearbeiten Sie die Datei postgresql.properties:
vi /opt/apigee/customer/application/postgresql.properties
Wenn die Datei nicht vorhanden ist, erstellen Sie sie.
- Legen Sie die oben aufgeführten Eigenschaften fest.
- Speichern Sie die Änderungen.
- Starten Sie die PostgreSQL-Datenbank neu:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
Systemlimits
Achten Sie darauf, dass Sie die folgenden Systemlimits auf Cassandra- und Message Processor-Knoten festgelegt haben:
- Legen Sie auf Cassandra-Knoten die Soft- und Hardlimits für „memlock“, „nofile“ und „address space“ (as) für den Installationsnutzer (Standard ist „apigee“) in
/etc/security/limits.d/90-apigee-edge-limits.conf
wie unten gezeigt fest:apigee soft memlock unlimited apigee hard memlock unlimited apigee soft nofile 32768 apigee hard nofile 65536 apigee soft as unlimited apigee hard as unlimited apigee soft nproc 32768 apigee hard nproc 65536
- Legen Sie auf Message Processor-Knoten in
/etc/security/limits.d/90-apigee-edge-limits.conf
die maximale Anzahl geöffneter Dateideskriptoren auf 64 K fest, wie unten dargestellt:apigee soft nofile 32768 apigee hard nofile 65536
Bei Bedarf können Sie dieses Limit erhöhen. Das kann beispielsweise der Fall sein, wenn Sie gleichzeitig viele temporäre Dateien geöffnet haben.
Wenn Sie in einem Router oder Message Processor
system.log
den folgenden Fehler sehen, sind die Limits für Dateideskriptoren möglicherweise zu niedrig:"java.io.IOException: Too many open files"
Sie können Ihre Nutzerlimits prüfen, indem Sie folgenden Befehl ausführen:
# su - apigee $ ulimit -n 100000
Wenn Sie die Limits für geöffnete Dateien immer noch erreichen, nachdem Sie die Limits für Dateideskriptoren auf
100000
festgelegt haben, öffnen Sie ein Ticket beim Apigee Edge-Support, um weitere Schritte zur Fehlerbehebung zu erhalten.
Netzwerksicherheitsdienste (NSS)
Network Security Services (NSS) ist eine Reihe von Bibliotheken, die die Entwicklung sicherheitskonformer Client- und Serveranwendungen unterstützen. Sie sollten NSS Version 3.19 oder höher installiert haben.
So prü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 bei IPv6 deaktivieren, wenn NSCD (Name Service Cache Daemon) verwendet wird
Wenn Sie NSCD (Name Service Cache Daemon) installiert und aktiviert haben, führen die Nachrichten-Prozessoren zwei DNS-Suchanfragen 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 die DNS-Suche unter IPv6:
- Bearbeiten Sie auf jedem Message Processor-Knoten
/etc/nscd.conf
- Legen Sie die folgende Property fest:
enable-cache hosts 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-Plattform installieren, müssen Sie IPv6 auf allen Qpid-Knoten deaktivieren.
Eine Anleitung zum Deaktivieren von IPv6 finden Sie in der RedHat- oder CentOS-Dokumentation Ihrer jeweiligen Betriebssystemversion. Beispiele:
- Öffnen Sie
/etc/hosts
in einem Editor. - Fügen Sie in Spalte 1 der folgenden Zeile das Zeichen „#“ ein, um sie zu kommentieren:
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- Speichern Sie 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, die von EL5 oder EL6 bereitgestellt werden.
awk |
expr |
libxslt |
U/min |
unzip |
basename |
grep |
lua-socket |
rpm2cpio |
useradd |
bash |
Hostname |
ls |
sed |
wc |
bc |
id |
net-tools |
sudo |
wget |
curl |
libaio |
perl (von procps) |
tar |
xerces-c |
cyrus-sasl | libdb4 | pgrep (aus procps) | tr | yum |
Datum |
libdb-cxx |
ps |
uuid |
chkconfig |
Verz.-name | libibverbs | pwd | uname | |
Echo | librdmacm | Python |
ntpdate
Apigee empfiehlt, dass Sie die Zeiten Ihrer Server synchronisieren. Falls noch nicht konfiguriert, kann das Dienstprogramm ntpdate
für diesen Zweck verwendet werden. Es prüft, ob die Server synchron sind. Sie können das Dienstprogramm mit yum install ntp
installieren. Dies ist besonders nützlich für die Replikation von OpenLDAP-Umgebungen. Die Serverzeitzone muss UTC sein.
openldap 2.4
Für die Installation vor Ort ist OpenLDAP 2.4 erforderlich. Wenn Ihr Server eine Internetverbindung hat, wird OpenLDAP über das Edge-Installationsskript heruntergeladen und installiert. Wenn Ihr Server keine Internetverbindung hat, müssen Sie OpenLDAP bereits installiert haben, 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.
Bei Installationen mit 13 Hosts und 12 Hosts mit zwei Rechenzentren ist eine OpenLDAP-Replikation erforderlich, da es mehrere Knoten gibt, auf denen OpenLDAP gehostet wird.
Firewalls und virtuelle Hosts
Der Begriff virtual
wird in der IT-Branche häufig überstrapaziert. Das gilt auch für eine Apigee Edge for Private Cloud-Bereitstellung und virtuelle Hosts. Zur Klarstellung: Es gibt zwei Hauptverwendungen des Begriffs virtual
:
- Virtuelle Maschinen (VM): Nicht erforderlich, aber bei einigen Bereitstellungen werden VM-Technologien verwendet, um isolierte Server für die Apigee-Komponenten zu erstellen. VM-Hosts können wie physische Hosts Netzwerkschnittstellen und Firewalls haben.
- Virtuelle Hosts: Webendpunkte, die einem Apache-virtuellen Host entsprechen.
Ein Router in einer VM kann mehrere virtuelle Hosts bereitstellen, solange sie sich durch ihren Hostalias oder ihren Schnittstellenport voneinander unterscheiden.
Als Beispiel für die Benennung: Auf einem einzelnen physischen Server A
werden zwei VMs mit den Namen „VM1“ und „VM2“ ausgeführt. Angenommen, „VM1“ stellt eine virtuelle Ethernet-Schnittstelle bereit, die innerhalb der VM „eth0“ genannt wird und der die IP-Adresse 111.111.111.111
von der Virtualisierungsmaschine oder einem Netzwerk-DHCP-Server zugewiesen wird. Angenommen, VM2 stellt eine virtuelle Ethernet-Schnittstelle bereit, die ebenfalls „eth0“ genannt wird und der die IP-Adresse 111.111.111.222
zugewiesen wird.
Möglicherweise wird auf jeder der beiden VMs ein Apigee-Router ausgeführt. Die Router stellen virtuelle Hostendpunkte bereit, wie in diesem hypothetischen Beispiel:
Der Apigee-Router in VM1 stellt drei virtuelle Hosts auf seiner eth0-Schnittstelle (mit einer bestimmten IP-Adresse) bereit: api.mycompany.com:80
, api.mycompany.com:443
und test.mycompany.com:80
.
Der Router in VM2 stellt api.mycompany.com:80
bereit (gleicher Name und Port wie von VM1 bereitgestellt).
Das Betriebssystem des physischen Hosts kann eine Netzwerk-Firewall haben. In diesem Fall muss diese Firewall so konfiguriert sein, dass 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 Verbindungen zu den 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 bereitgestellt haben. API-Proxy-Bundles können einen Endpunkt gemeinsam nutzen, wenn sie unterschiedliche Basispfade haben. Ein Basispfad kann beispielsweise 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 von 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 spezifisch für Ihre Installation und wird von Ihrer lokalen Netzwerkgruppe konfiguriert.
Der Basispfad wird festgelegt, wenn Sie eine API bereitstellen. 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 80
bereitstellen. Wenn Sie keinen Basispfad in der Bereitstellung angeben, weiß der Router nicht, an welche API eingehende Anfragen gesendet werden sollen.
Wenn Sie die API testmycompany
jedoch mit der Basis-URL /salesdemo
bereitstellen, greifen Nutzer über http://api.mycompany.com:80/salesdemo
auf diese API zu. Wenn Sie Ihre API „mycompany“ mit der Basis-URL /
bereitstellen, greifen Ihre Nutzer über die URL http://api.mycompany.com:80/
auf die API zu.
Lizenzierung
Für jede Installation von Edge ist eine eindeutige Lizenzdatei erforderlich, die Sie von Apigee erhalten. Sie müssen den Pfad zur Lizenzdatei angeben, wenn Sie den Verwaltungsserver installieren, z. B. /tmp/license.txt.
Das Installationsprogramm kopiert die Lizenzdatei in /opt/apigee/customer/conf/license.txt
.
Wenn die Lizenzdatei gültig ist, prüft der Verwaltungsserver das Ablaufdatum und die zulässige Anzahl von Nachrichtenprozessoren. Wenn eine der Lizenzeinstellungen abgelaufen ist, finden Sie die Protokolle unter /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 Apigee Sales.