Installationsanforderungen

Hardwareanforderungen

Sie müssen die folgenden Mindestanforderungen an die Hardware für eine hochverfügbare Infrastruktur in einer Produktionsumgebung erfüllen.

Das folgende Video enthält allgemeine Informationen zur Dimensionierung Ihrer Installation:

In den folgenden Tabellen sind die Mindesthardwareanforderungen für die Installationskomponenten für alle in Installationstopologien beschriebenen Installationsszenarien aufgeführt.

In diesen Tabellen sind die Festplattenanforderungen zusätzlich zum vom Betriebssystem benötigten Festplattenspeicherplatz angegeben. Je nach Anwendungen und Netzwerkverkehr benötigt Ihre Installation möglicherweise mehr oder weniger Ressourcen als unten aufgeführt.

Installationskomponente RAM CPU Mindestanforderungen an die Festplatte
Cassandra (eigenständig) 16 GB 8‑Kern 250 GB lokaler Speicher mit SSD, die 2.000 IOPS unterstützt
Cassandra/Zookeeper auf demselben Computer 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 (allein) 8 GB 8‑Kern 100 GB
Analytics – Postgres/Qpid auf demselben Server 16 GB* 8‑Kern* 500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Backend, der 1.000 IOPS oder mehr unterstützt*
Analytics – eigenständiger Postgres-Master oder ‑Standby 16 GB* 8‑core* 500 GB bis 1 TB** Netzwerkspeicher***, vorzugsweise mit SSD-Backend, der 1.000 IOPS oder mehr unterstützt*
Analytics – Qpid (eigenständig) 8 GB 4-Kern 30–50 GB lokaler Speicherplatz mit SSD

Die Standardgröße der Qpid-Warteschlange beträgt 1 GB. Sie kann auf 2 GB erhöht werden. Wenn Sie mehr Kapazität benötigen, fügen Sie zusätzliche Qpid-Knoten hinzu.

SymasLDAP/UI/Management Server 8 GB 4-Kern 60 GB
UI-/Verwaltungsserver 4 GB 2-Kern 60 GB
SymasLDAP (eigenständig) 4 GB 2-Kern 60 GB

* Postgres-Systemanforderungen basierend auf dem Durchsatz anpassen:

  • Weniger als 250 TPS: 8 GB, 4 Cores können mit verwaltetem Netzwerkspeicher*** mit 1.000 IOPS oder höher in Betracht gezogen werden.
  • Mehr als 250 TPS: 16 GB, 8 Cores, verwalteter Netzwerkspeicher*** mit mindestens 1.000 IOPS
  • Mehr als 1.000 TPS: 16 GB, 8 Cores, verwalteter Netzwerkspeicher*** mit Unterstützung von mindestens 2.000 IOPS
  • Mehr als 2.000 TPS: 32 GB, 16 Prozessorkerne, verwalteter Netzwerkspeicher*** mit Unterstützung von 2.000 IOPS oder mehr
  • Mehr als 4.000 TPS: 64 GB, 32 Cores, verwalteter Netzwerkspeicher*** mit Unterstützung für 4.000 IOPS oder mehr

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

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 für die PostgreSQL-Datenbank empfohlen, weil:

  • Sie können die Speichergröße dynamisch hochskalieren, wenn dies erforderlich ist.
  • Die Netzwerk-IOPS können in den meisten aktuellen Umgebungs-/Speicher-/Netzwerk-Subsystemen im laufenden Betrieb angepasst werden.
  • Snapshots auf Speicherebene können als Teil von Sicherungs- und Wiederherstellungslösungen aktiviert werden.

Außerdem sind hier die Hardwareanforderungen aufgeführt, wenn Sie die Monetarisierungsdienste installieren möchten (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, der 1.000 IOPS oder mehr unterstützt, oder verwenden Sie die Regel aus der Tabelle oben.
Analytics – eigenständiger Postgres-Master oder ‑Standby 16 GB 8‑Kern 500 GB bis 1 TB Netzwerkspeicher, vorzugsweise mit SSD-Backend, der 1.000 IOPS oder mehr unterstützt, oder verwenden Sie die Regel aus der Tabelle oben.
Analytics – Qpid (eigenständig) 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 HDD mit lokalem Speicher empfohlen, die 1.000 IOPS unterstützt.

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, das mit mehreren Knoten für Lese- und Schreibvorgänge kommuniziert, führt zu einer erheblichen Datenübertragung über das Netzwerk.

Cassandra erfordert 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 Betriebssystem und Drittanbietersoftware

Diese Installationsanleitung und die mitgelieferten Installationsdateien wurden auf den Betriebssystemen und der Drittanbietersoftware getestet, die unter Unterstützte Software und unterstützte Versionen aufgeführt sind.

Voraussetzung: EPEL-Repository aktivieren

Bevor Sie mit der Installation fortfahren, muss das EPEL-Repository (Extra Packages for Enterprise Linux) aktiviert sein. Verwenden Sie die folgenden Befehle entsprechend Ihrer Betriebssystemversion:

  • Für Red Hat/CentOS/Oracle 8.X:
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
    sudo rpm -ivh epel-release-latest-8.noarch.rpm
  • Red Hat/CentOS/Oracle 9.X:
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
    sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

Vor der Installation muss auf jedem Computer 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 auf das Stammverzeichnis des JDK für den Nutzer verweist, der die Installation durchführt.

SELinux

Abhängig von Ihren SELinux-Einstellungen können bei der Installation und beim Starten von Edge-Komponenten Probleme auftreten. 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 Edge-Dienstprogramm „apigee-setup“ installieren.

Nutzer „apigee“ erstellen

Bei der Installation wird ein Unix-Systemnutzer mit dem Namen „apigee“ erstellt. Edge-Verzeichnisse und -Dateien gehören dem Nutzer „apigee“, ebenso wie Edge-Prozesse. Das bedeutet, dass Edge-Komponenten als Nutzer „apigee“ ausgeführt werden. Bei Bedarf können Sie Komponenten als anderen Nutzer ausführen.

Installationsverzeichnis

Standardmäßig schreibt das Installationsprogramm alle Dateien in das Verzeichnis /opt/apigee. Dieser Verzeichnispfad kann nicht geändert werden. Sie können dieses Verzeichnis zwar nicht ändern, aber einen Symlink erstellen, um /opt/apigee einem anderen Speicherort zuzuordnen. Weitere Informationen finden Sie unter Symlink von /opt/apigee erstellen.

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

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

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

  1. 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
  2. Erstellen Sie einen Symlink von /opt/apigee zu Ihrem gewünschten Installationsstammverzeichnis:
    ln -Ts /srv/myInstallDir /opt/apigee

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

  3. Ändern Sie den Eigentümer des Installationsstamms und des Symlinks in den Nutzer „apigee“:
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Werbenetzwerkeinstellung

Apigee empfiehlt, die Netzwerkeinstellungen vor der Installation zu prüfen. Das Installationsprogramm geht davon aus, dass alle Computer 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 für den Hostnamen zurück, der 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 zu Ihrem Betriebssystem.

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, die in bestimmten Situationen möglicherweise nicht korrekt ist. Alternativ können Sie die folgende Property in der Installationskonfigurationsdatei festlegen:

ENABLE_DYNAMIC_HOSTIP=y

Wenn diese Eigenschaft auf „y“ gesetzt ist, werden Sie vom Installationsprogramm aufgefordert, die IP-Adresse auszuwählen, die im Rahmen der Installation verwendet werden soll. Der Standardwert ist „n“. Weitere Informationen finden Sie in der Referenz zur Edge-Konfigurationsdatei.

TCP-Wrapper

TCP Wrappers können die Kommunikation einiger Ports blockieren und sich auf die Installation von SymasLDAP, Postgres und Cassandra auswirken. Prüfen Sie auf diesen Knoten /etc/hosts.allow und /etc/hosts.deny, um sicherzustellen, dass für die erforderlichen SymasLDAP-, Postgres- und Cassandra-Ports keine Portbeschränkungen gelten.

iptables

Prüfen Sie, ob iptables-Richtlinien 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

Verzeichniszugriff

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

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 Sie im Rahmen Ihres Sicherheitsverfahrens Berechtigungen für /etc/rc.d/init.d/functions festlegen müssen, legen Sie sie nicht auf 700 fest, da der Router sonst nicht gestartet werden kann.

Sie können die Berechtigungen auf 744 festlegen, um den Lesezugriff auf /etc/rc.d/init.d/functions zu ermöglichen.

Zookeeper /dev/random Die Zookeeper-Clientbibliothek benötigt Lesezugriff auf den Zufallszahlengenerator /dev/random. Wenn /dev/random für Lesezugriffe blockiert ist, kann der Zookeeper-Dienst möglicherweise nicht gestartet werden.

Cassandra

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

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 nachlässt oder der Arbeitsspeicherverbrauch hoch ist.

Nach der Installation von Edge for Private Cloud können Sie prüfen, ob Cassandra richtig konfiguriert ist, indem Sie die Datei /opt/apigee/apigee-cassandra/conf/cassandra.yaml untersuchen. Achten Sie beispielsweise darauf, dass im Installationsskript für Edge for Private Cloud die folgenden Eigenschaften festgelegt wurden:

  • 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 an die Menge an RAM anpassen, die auf Ihrem System verfügbar ist:

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 Attribute fest.
  3. Speichern Sie die Änderungen.
  4. Starten Sie die PostgreSQL-Datenbank neu:
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Sprachkonfiguration für Rocky 9.X

Wenn Sie Rocky 9.X verwenden, muss Ihr System mit LANG=en_US.utf8 in den systemweiten Gebietsschemaeinstellungen konfiguriert sein. Führen Sie dazu die folgenden Befehle aus:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

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 „soft“ und „hard“ 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 fest, 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
    apigee soft nproc 32768
    apigee hard nproc 65536
  • Legen Sie auf Message Processor-Knoten die maximale Anzahl offener Dateideskriptoren in /etc/security/limits.d/90-apigee-edge-limits.conf auf 64.000 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 viele temporäre Dateien gleichzeitig geöffnet haben.

  • Wenn Sie jemals den folgenden Fehler in einem Router oder Message Processor sehen: system.log, sind Ihre Dateideskriptorlimits möglicherweise zu niedrig festgelegt:

    "java.io.IOException: Too many open files"

    Sie können Ihre Nutzerlimits mit folgendem Befehl prüfen:

    # su - apigee
    $ ulimit -n
    100000
    

    Wenn Sie die Grenzwerte für offene Dateien weiterhin erreichen, nachdem Sie die Grenzwerte für Dateideskriptoren auf 100000 festgelegt haben, erstellen Sie ein Ticket beim Apigee Edge-Support, um das Problem weiter zu beheben.

Network Security Services (NSS)

Network Security Services (NSS) ist eine Reihe von Bibliotheken, die die Entwicklung von sicherheitsfähigen Client- und Serveranwendungen unterstützen. Sie sollten NSS v3.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 für IPv6 deaktivieren, wenn NSCD (Name Service Cache Daemon) verwendet wird

Wenn Sie NSCD (Name Service Cache Daemon) installiert und aktiviert haben, führen die Message Processors zwei DNS-Lookups durch: eines für IPv4 und eines für IPv6. Wenn Sie NSCD verwenden, sollten Sie die DNS-Suche für IPv6 deaktivieren.

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

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

IPv6 unter RHEL 8 und höher deaktivieren

Wenn Sie Edge auf RHEL 8 oder höher auf der Google Cloud Platform installieren, müssen Sie IPv6 auf allen Qpid-Knoten deaktivieren.

Eine Anleitung zum Deaktivieren von IPv6 finden Sie in der Dokumentation Ihres Betriebssystemanbieters. Relevante Informationen finden Sie beispielsweise in der Red Hat Enterprise Linux-Dokumentation.

Tools

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

awk

expr

libxslt

Atemzüge/Min.

unzip

basename

grep

lua-socket

rpm2cpio

useradd

bash

Hostname

ls

sed

wc

bc

id

net-tools

sudo

wget

curl

libaio

perl (aus 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    

Zeitsynchronisierung

Apigee empfiehlt, dass die Zeiten Ihrer Server synchronisiert werden. Wenn noch nicht konfiguriert, kann das ntpdate-Dienstprogramm oder ein entsprechendes Tool verwendet werden, um zu prüfen, ob die Server zeitsynchronisiert sind. Sie können das Dienstprogramm beispielsweise mit yum install ntp oder einem entsprechenden Befehl installieren. Das ist besonders nützlich, wenn Sie LDAP-Einrichtungen replizieren möchten. Die Serverzeitzone sollte auf UTC festgelegt sein.

Firewalls und virtuelle Hosts

Der Begriff virtual wird in der IT-Branche häufig überladen. Das gilt auch für die Bereitstellung von Apigee Edge for Private Cloud und virtuellen Hosts. Zur Verdeutlichung: Der Begriff virtual wird hauptsächlich in zwei Kontexten verwendet:

  • Virtuelle Maschinen (VMs): Nicht erforderlich, aber bei einigen Bereitstellungen wird VM-Technologie 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 virtuellen Apache-Host entsprechen.

Ein Router in einer VM kann mehrere virtuelle Hosts bereitstellen, sofern sich diese in ihrem Hostalias oder in ihrem Schnittstellenport voneinander unterscheiden.

Ein Beispiel: 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 in der VM „eth0“ genannt wird und der von der Virtualisierungssoftware oder einem Netzwerk-DHCP-Server die IP-Adresse 111.111.111.111 zugewiesen wird. Angenommen, VM2 stellt ebenfalls eine virtuelle Ethernet-Schnittstelle mit dem Namen „eth0“ bereit und ihr wird die IP-Adresse 111.111.111.222 zugewiesen.

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

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 macht api.mycompany.com:80 verfügbar (derselbe Name und Port wie von VM1).

Das Betriebssystem des physischen Hosts hat möglicherweise eine Netzwerk-Firewall. Wenn dies der Fall ist, muss diese Firewall so konfiguriert werden, dass TCP-Traffic, der für die Ports bestimmt ist, die auf den virtualisierten Schnittstellen (111.111.111.111:{80, 443} und 111.111.111.222:80) bereitgestellt werden, weitergeleitet wird. Außerdem 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 beim Weiterleiten von API-Aufrufen an verschiedene bereitgestellte API-Proxys verwendet wird. 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 bereitstellen, der den Hostalias api.mycompany.com und den auf 80 festgelegten Port hat. Wenn Sie in der Bereitstellung keinen Basispfad deklarieren, 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 bei der Installation des Verwaltungsservers angeben, z. B. /tmp/license.txt.

Das Installationsprogramm kopiert die Lizenzdatei nach /opt/apigee/customer/conf/license.txt.

Wenn die Lizenzdatei gültig ist, überprüft der Verwaltungsserver das Ablaufdatum und die zulässige Anzahl von Message Processors (MPs). Wenn eine der Lizenzeinstellungen abgelaufen ist, finden Sie die Logs unter /opt/apigee/var/log/edge-management-server/logs. In diesem Fall können Sie sich an den Apigee Edge-Support wenden, um weitere Informationen zur Migration zu erhalten.

Wenn Sie noch keine Lizenz haben, wenden Sie sich an Apigee Sales.