Diese Seite wurde von der Cloud Translation API übersetzt.

Installationsanforderungen

Hardwareanforderungen

Für eine hochverfügbare Infrastruktur in einer produktionstauglichen Umgebung müssen Sie die folgenden Mindesthardwareanforderungen erfüllen.

Das folgende Video gibt dir eine grobe Größenberatung für deine Installation:

In den folgenden Tabellen sind für alle unter Installationstopologien beschriebenen Installationsszenarien 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	Minimale Festplatte
Cassandra	16 GB	8-Kern	250 GB lokaler Speicher mit SSD-Unterstützung für 2.000 IOPS
Message Processor/Router auf demselben Rechner	16 GB	8-Kern	100GB
Nachrichtenprozessor (eigenständig)	16 GB	8-Kern	100GB
Router (eigenständig)	16 GB	8-Kern	100GB
Analytics – Postgres/Qpid auf demselben Server	16GB^*	8-Kern^*	500 GB–1 TB^ Netzwerkspeicher^, vorzugsweise mit SSD-Back-End, Unterstützung für mindestens 1.000 IOPS^
Analytics – Postgres-Master oder -Standby (eigenständig)	16GB^*	8 Kerne^*	500 GB–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	30 GB bis 50 GB lokaler Speicher mit SSD 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
UI/Verwaltungsserver	4 GB	2-Kern	60 GB
OpenLDAP (eigenständig)	4 GB	2-Kern	60 GB
^{* Passen Sie die Systemanforderungen von Postgres basierend auf dem Durchsatz an: Weniger als 250 TPS: 8 GB mit 4 Kernen kommen für einen verwalteten Netzwerkspeicher infrage^*, der 1.000 IOPS oder mehr unterstützt. Mehr als 250 TPS: Verwalteter Netzwerkspeicher mit 16 GB und 8 Kernen^* mit Unterstützung von mindestens 1.000 IOPS Mehr als 1.000 TPS: Verwalteter Netzwerkspeicher mit 16 GB und 8 Kernen^* mit Unterstützung von mindestens 2.000 IOPS Mehr als 2.000 TPS: Verwalteter Netzwerkspeicher mit 32 GB und 16 Kernen^* mit Unterstützung von 2.000 IOPS oder höher Mehr als 4.000 TPS: 64 GB, verwalteter Netzwerkspeicher mit 32 Kernen^* mit Unterstützung für 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 Werte entsprechend erhöht werden. 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 of storage needed} ^{*** 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 sind im Folgenden die Hardwareanforderungen aufgeführt, wenn Sie die Monetarisierungsdienste installieren möchten. Diese werden bei All-in-One-Installationen nicht 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	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 Master oder Standalone	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	16 GB	8-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.

Anforderungen an Betriebssysteme und Drittanbietersoftware

Diese Installationsanleitung und die mitgelieferten Installationsdateien wurden mit Betriebssystemen und Drittanbieter-Software 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.

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

Hinweis: Das Edge-Installationsprogramm kann Java 1.8 installieren und im Rahmen des Installationsvorgangs für apigee-setup JAVA_HOME für Sie festlegen. Weitere Informationen finden Sie unter Edge-Dienstprogramm für Apigee-Einrichtung installieren.

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 moderaten Modus setzen und dann nach der Installation wieder aktivieren. Weitere Informationen finden Sie unter Edge-Dienstprogramm für Apigee-Einrichtung installieren.

Erstellen des Benutzers „apigee“

Das Installationsverfahren erstellt einen Unix-Systembenutzer mit dem Namen „apigee“. Edge-Verzeichnisse und -Dateien gehören zu Apigee, ebenso wie Edge-Prozesse. Das bedeutet, dass Edge-Komponenten als der Apigee-Benutzer ausgeführt werden. Bei Bedarf können Sie Komponenten als ein 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 Sie können einen Symlink erstellen, um /opt/apigee einem anderen Speicherort zuzuordnen, wie unter Symlink aus /opt/apigee erstellen beschrieben.

In der Anleitung in diesem Handbuch wird das Installationsverzeichnis als /opt/apigee angegeben.

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.51.00.sh herunterladen, um den Symlink zu erstellen. 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 Inhaberschaft des Installationsstamms und von Symlink zum Nutzer „apigee“:
```
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
```

Werbenetzwerkeinstellung

Apigee empfiehlt, dass Sie die Netzwerkeinstellung vor der Installation prü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 der Maschine zurück.
hostname -i gibt die IP-Adresse für den Hostnamen zurück, die von anderen Rechnern adressiert 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 über mehrere Schnittstellenkarten verfügt, 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, die möglicherweise nicht in allen Situationen korrekt ist. Alternativ können Sie das folgende Attribut in der Konfigurationsdatei der Installation festlegen:

ENABLE_DYNAMIC_HOSTIP=y

Wenn dieses Attribut 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.

Warnung:Wenn du ENABLE_DYNAMIC_HOSTIP=y festlegst, darf in deiner Property-Datei nicht HOSTIP festgelegt sein.

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

Verzeichniszugriff

In der folgenden Tabelle sind Verzeichnisse auf Edge-Knoten aufgeführt, die besondere Anforderungen von Edge-Prozessen haben:

Dienst Verzeichnis Beschreibung

Router

Dienst	Verzeichnis	Beschreibung
Router	`/etc/rc.d/init.d/functions`	Der Edge Router verwendet den NGINX-Router und benötigt 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 sie nicht auf 700, da der Router sonst nicht gestartet wird. Sie können Berechtigungen auf 744 setzen, um Lesezugriff auf `/etc/rc.d/init.d/functions` zu gewähren.
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.

/etc/rc.d/init.d/functions

Der Edge Router verwendet den NGINX-Router und benötigt 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 sie nicht auf 700, da der Router sonst nicht gestartet wird.

Sie können Berechtigungen auf 744 setzen, um Lesezugriff auf /etc/rc.d/init.d/functions zu gewähren.

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üsselraum bestimmt die Cassandra-Knoten, an denen Replikate platziert werden. Weitere Informationen finden Sie unter Cassandra-Replikationsfaktor und Konsistenzebene.

Cassandra passt seine Java-Heap-Größe automatisch anhand des verfügbaren Speichers an. Weitere Informationen finden Sie unter Java-Ressourcen optimieren bei Leistungsverschlechterungen oder hohem Arbeitsspeicherverbrauch.

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

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 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:

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 für Cassandra- und Message Processor-Knoten festgelegt haben:

Legen Sie auf Cassandra-Knoten die Limits 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 fest, wie unten gezeigt:
```
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
```
Weitere Informationen finden Sie unter Empfohlene Produktionseinstellungen in der Apache Cassandra-Dokumentation.
Legen Sie auf Message Processor-Knoten die maximale Anzahl geöffneter Dateideskriptoren in /etc/security/limits.d/90-apigee-edge-limits.conf auf 64 K fest, wie unten gezeigt:
```
apigee soft nofile 32768
apigee hard nofile 65536
```
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.
Wenn in einem Router oder Message Processor system.log der folgende Fehler auftritt, sind die Dateideskriptor-Limits möglicherweise zu niedrig:
```
"java.io.IOException: Too many open files"
```
Sie können die Nutzerlimits prüfen, indem Sie folgenden Befehl ausführen:
```
# su - apigee
$ ulimit -n
100000
```
Wenn Sie die Limits für geöffnete Dateien nach dem Festlegen der Dateideskriptor-Limits auf 100000 noch erreichen, öffnen Sie zur weiteren Fehlerbehebung ein Ticket beim Apigee Edge-Support.

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 RedHat-Artikel.

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. Sie sollten DNS-Lookup für IPv6 deaktivieren, wenn Sie NSCD verwenden.

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

Bearbeiten Sie auf jedem Message Processor-Knoten /etc/nscd.conf.
Lege 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 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 Betriebssystemversion. Sie können z. B.

Öffnen Sie /etc/hosts in einem Editor.
Fügen Sie in die erste Spalte der folgenden Zeile ein #-Zeichen ein, um es auskommentieren zu lassen:
```
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
```
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	libxslt	AZ/min	unzip
basename	grep	Lua-Socket	rpm2cpio	Nutzer hinzufügen
bash	Hostname	ls	sed	wc
bc	id	net-tools	sudo	wget
curl	Libaio	perl (von procps)	tar	Xerces-C
Cyrus-Sasl	libdb4	pgrep (von procps)	tr	Mmmhh, lecker
date	libdb-cxx	ps	uuid	Chkconfig
dirname	Liibverbien	pwd	Uname
echo	Librdmacm	python

ntpdate

Apigee empfiehlt, dass die Zeiten Ihrer Server synchronisiert werden. Wenn es nicht bereits konfiguriert ist, kann das ntpdate-Dienstprogramm diesen Zweck erfüllen, das prüft, ob Server zeitsynchron sind. Sie können das Dienstprogramm mit yum install ntp 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.

Bei Installationen mit 13 Hosts und Installationen mit 12 Hosts mit zwei Rechenzentren ist eine OpenLDAP-Replikation erforderlich, da OpenLDAP auf mehreren Knoten gehostet wird.

Firewalls und virtuelle Hosts

Der Begriff virtual wird im IT-Bereich häufig überlastet, daher wird er mit Apigee Edge für die Bereitstellung einer privaten Cloud und virtuelle Hosts verwendet. Zur Klarstellung: Der Begriff virtual wird hauptsächlich in zweierlei Hinsicht 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.

Ein Beispiel für einen Namen: Ein einzelner physischer Server A könnte zwei VMs mit den Namen „VM1“ und „VM2“ ausführen. Angenommen, „VM1“ stellt eine virtuelle Ethernet-Schnittstelle bereit, die innerhalb der VM „eth0“ genannt wird und der von der Virtualisierungsmaschine oder einem DHCP-Netzwerkserver die IP-Adresse 111.111.111.111 zugewiesen wird. Nehmen wir dann an, dass VM2 eine virtuelle Ethernet-Schnittstelle mit dem Namen „eth0“ bereitstellt und ihr die IP-Adresse 111.111.111.222 zugewiesen wird.

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 macht drei virtuelle Hosts auf seiner eth0-Schnittstelle (die eine bestimmte IP-Adresse hat) api.mycompany.com:80, api.mycompany.com:443 und test.mycompany.com:80 verfügbar.

Der Router in VM2 macht api.mycompany.com:80 verfügbar (derselbe Name und 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) verfügbar gemacht werden. Darüber hinaus kann das Betriebssystem jeder VM eine eigene Firewall auf der eth0-Schnittstelle bereitstellen. Auch diese müssen Verbindungen ü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 http://api.mycompany.com:80/ Traffic 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 bereitstellen, der den Hostalias api.mycompany.com und den Port auf 80 hat. 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 mit 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.

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 nach /opt/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 Protokolle unter /opt/apigee/var/log/edge-management-server/logs. Informationen zur Migration erhalten Sie vom Apigee Edge-Support.

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