Informationen zu Planeten, Regionen, Pods, Organisationen, Umgebungen und virtuellen Hosts

Edge for Private Cloud v4.18.05

Eine On-Premises-Installation von Edge Private Cloud oder eine Edge-Instanz besteht aus mehreren Edge-Komponenten, die auf mehreren Serverknoten installiert sind. Die folgende Abbildung zeigt die Beziehung zwischen dem Planeten, den Regionen, Pods, Organisationen, Umgebungen und virtuellen Hosts, aus denen eine Edge-Instanz besteht:

In der folgenden Tabelle werden diese Beziehungen beschrieben:

Komponente Enthält Verknüpft mit Standard
Planet Eine oder mehrere Regionen –
Region Ein oder mehrere Pods „dc-1“
Pod Eine oder mehrere Edge-Komponenten „central“
„gateway“
„analytics“
Organisation Eine oder mehrere Umgebungen Einen oder mehrere Pods mit Nachrichten-Prozessoren und einen Nutzer, der als Organisationsadministrator fungiert keine
Umgebung Einen oder mehrere virtuelle Hosts Ein oder mehrere Nachrichten-Prozessoren in einem Pod, der mit der übergeordneten Organisation verknüpft ist keine
Virtueller Host Einen oder mehrere Host-Aliasse keine

Planeten

Ein Planet stellt eine gesamte Edge-Hardware- und -Softwareumgebung dar und kann eine oder mehrere Regionen enthalten. In Edge ist ein Planet eine logische Gruppierung von Regionen. Sie erstellen oder konfigurieren einen Planet nicht explizit im Rahmen der Installation von Edge.

Regionen

Eine Region ist eine Gruppierung von einem oder mehreren Pods. Wenn Sie Edge installieren, wird standardmäßig eine einzelne Region mit dem Namen „dc-1“ mit drei Pods erstellt, wie in der folgenden Tabelle dargestellt:

Region Pods in der Region
„dc-1“ „gateway“, „central“, „analytics“

Die folgende Abbildung zeigt die Standardregionen:

Auf diesem Bild ist zu sehen, wie der Load Balancer den Traffic an den Pod „gateway“ weiterleitet. Der Pod „gateway“ enthält die Edge-Router- und Message-Processor-Komponenten, die API-Anfragen verarbeiten. Sofern Sie nicht mehrere Rechenzentren definieren, sollten Sie keine zusätzlichen Regionen erstellen müssen.

Bei einer komplexeren Installation können Sie zwei oder mehr Regionen erstellen. Eine Möglichkeit, mehrere Regionen zu erstellen, besteht darin, Maschinen geografisch zu organisieren, um die Netzwerkübertragungszeit zu minimieren. In diesem Szenario hosten Sie API-Endpunkte so, dass sie geografisch in der Nähe der Nutzer dieser APIs sind.

In Edge wird jede Region als Rechenzentrum bezeichnet. Ein Rechenzentrum im Osten der USA kann dann Anfragen bearbeiten, die aus Boston, Massachusetts, eingehen, während ein Rechenzentrum in Singapur Anfragen von Geräten oder Computern in Asien bearbeiten kann.

Die folgende Abbildung zeigt beispielsweise zwei Regionen, die zwei Rechenzentren entsprechen:

Pods

Ein pod ist eine Gruppe von einer oder mehreren Edge-Komponenten und Cassandra-Datenspeichern. Die Edge-Komponenten können auf demselben Knoten installiert werden, werden aber häufiger auf verschiedenen Knoten installiert. Ein Cassandra-Datenspeicher ist ein Datenrepository, das von den Edge-Komponenten im Pod verwendet wird.

Wenn Sie Edge installieren, werden standardmäßig drei Pods erstellt und die folgenden Edge-Komponenten und Cassandra-Datenspeicher werden jedem Pod zugeordnet:

Pod Edge-Komponenten

Cassandra-Datenspeicher
„gateway“ Router, Message Processor cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
„central“ Verwaltungsserver, Zookeeper, LDAP, Benutzeroberfläche, Qpid application-datastore
apimodel-datastore
audit-datastore
auth-datastore		 identityzone-datastore
edgenotification-datastore
management-server
scheduler-datastore
user-settings-datastore
„analytics“ Postgres analytics-datastore reportcrud-datastore

Die Edge-Komponenten und Cassandra-Datenspeicher im Pod „gateway“ sind für die API-Verarbeitung erforderlich. Diese Komponenten und Datenspeicher müssen für die Verarbeitung von API-Anfragen aktiv sein. Die Komponenten und Datenspeicher in den Pods „central“ und „analytics“ sind nicht zur Verarbeitung von APIs erforderlich, sondern bieten Edge zusätzliche Funktionen.

Die folgende Abbildung zeigt die Komponenten in den einzelnen Pods:

Sie können den drei standardmäßig erstellten Message Processor- und Router-Pods weitere hinzufügen. Alternativ können Sie einem vorhandenen Pod zusätzliche Edge-Komponenten hinzufügen. So können Sie dem „Gateway“-Pod beispielsweise zusätzliche Router und Message Processors hinzufügen, um eine erhöhte Verkehrslast zu bewältigen.

Der Pod „gateway“ enthält die Komponenten „Edge Router“ und „Message Processor“. Router senden nur Anfragen an Nachrichtenprozessoren im selben Pod und nicht an Nachrichtenprozessoren in anderen Pods.

Mit dem folgenden API-Aufruf können Sie die Details zur Serverregistrierung am Ende der Installation für jeden Pod aufrufen. Dies ist ein nützliches Monitoring-Tool.

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=podName

Dabei ist ms_IP die IP-Adresse oder der DNS-Name des Verwaltungsservers und podName eine der folgenden Optionen:

  • gateway
  • central
  • analytics

Beispiel für den Pod „gateway“:

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=gateway

Apigee gibt in etwa folgende Ausgabe zurück:

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
},
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

Im type-Attribut wird der Komponententyp aufgeführt. Beachten Sie, dass die im Pod registrierten Cassandra-Datenspeicher aufgeführt sind. Cassandra-Knoten werden im Pod „gateway“ installiert. Sie sehen jedoch Cassandra-Datenspeicher, die bei allen Pods registriert sind.

Organisationen

Eine Organisation ist ein Container für alle Objekte in einem Apigee-Konto, einschließlich APIs, API-Produkten, Anwendungen und Entwicklern. Eine Organisation ist mit einem oder mehreren Pods verknüpft. Jeder Pod muss einen oder mehrere Nachrichten-Prozessoren enthalten.

Bei einer On-Premises-Installation von Edge Private Cloud gibt es standardmäßig keine Organisationen. Wenn Sie eine Organisation erstellen, geben Sie zwei Informationen an:

  1. Ein Nutzer, der als Administrator der Organisation fungiert. Dieser Nutzer kann der Organisation dann weitere Nutzer hinzufügen und die Rolle jedes Nutzers festlegen.
  2. Der „Gateway“-Pod, der Pod mit den Nachrichtenprozessoren.

Eine Organisation kann eine oder mehrere Umgebungen enthalten. Beim standardmäßigen Edge-Installationsverfahren werden Sie aufgefordert, zwei Umgebungen zu erstellen: „test“ und „prod“. Sie können jedoch bei Bedarf weitere Umgebungen erstellen, z. B. „Staging“ oder „Tests“.

Die Organisation bietet einen Bereich für einige Apigee-Funktionen. Beispielsweise sind Daten für die Schlüssel/Wert-Paar-Zuordnung (KVM) auf Organisationsebene verfügbar, also in allen Umgebungen. Andere Funktionen wie das Caching sind auf eine bestimmte Umgebung beschränkt. Apigee-Analysedaten werden durch eine Kombination aus Organisation und Umgebung partitioniert.

Unten sind die wichtigsten Objekte einer Organisation aufgeführt, einschließlich der Objekte, die global in der Organisation und speziell für eine Umgebung definiert sind:

Umgebungen

Eine Umgebung ist ein Laufzeitausführungskontext für die API-Proxys in einer Organisation. Bevor Sie auf einen API-Proxy zugreifen können, müssen Sie ihn in einer Umgebung bereitstellen. Sie können einen API-Proxy in einer einzelnen Umgebung oder in mehreren Umgebungen bereitstellen.

Eine Organisation kann mehrere Umgebungen enthalten. Sie können beispielsweise die Umgebungen „dev“, „test“ und „prod“ in einer Organisation definieren.

Wenn Sie eine Umgebung erstellen, ordnen Sie ihr einen oder mehrere Message Processors zu. Eine Umgebung ist eine benannte Gruppe von Message Processors, auf denen API-Proxys ausgeführt werden. Jede Umgebung kann denselben oder verschiedenen Nachrichtenprozessoren zugeordnet werden.

Geben Sie zum Erstellen einer Umgebung zwei Informationen an:

  1. Die Organisation, die die Umgebung enthält.
  2. Die Message Processors, die API-Proxy-Anfragen an die Umgebung verarbeiten. Diese Message Processors müssen sich in einem Pod befinden, der mit der übergeordneten Organisation der Umgebung verknüpft ist.
    Wenn Sie eine Umgebung erstellen, werden standardmäßig alle verfügbaren Nachrichtenprozessoren im Pod „gateway“ mit der Umgebung verknüpft. Alternativ können Sie einen Teil der verfügbaren Nachrichtenabarbeiter angeben, damit unterschiedliche Nachrichtenabarbeiter Anfragen an unterschiedliche Umgebungen bearbeiten.

Ein Nachrichtenprozessor kann mit mehreren Umgebungen verknüpft sein. Ihre Edge-Installation enthält beispielsweise zwei Message Processors: A und B. Sie erstellen dann drei Umgebungen in Ihrer Organisation: „dev“, „test“ und „prod“:

  • Sie ordnen der Umgebung „dev“ Message Processor A zu, da Sie nicht mit einem großen Trafficvolumen rechnen.
  • Für die Testumgebung ordnen Sie Message Processor B zu, da Sie nicht mit einem großen Trafficvolumen rechnen.
  • Sie ordnen der Produktionsumgebung „prod“ sowohl Message Processor A als auch Message Processor B zu, um das Volumen auf Produktionsebene zu verarbeiten.

Die einer Umgebung zugewiesenen Nachrichtenverarbeiter können alle aus demselben Pod stammen oder aus mehreren Pods, die mehrere Regionen und Rechenzentren umfassen. Angenommen, Sie definieren in Ihrer Organisation die Umgebung „global“, die Nachrichtenprozessoren aus drei Regionen umfasst, also drei verschiedene Rechenzentren: USA, Japan und Deutschland.

Wenn Sie einen API-Proxy in der globalen Umgebung bereitstellen, wird er auf Message Processorn in allen drei Rechenzentren ausgeführt. API-Traffic, der in einem dieser Rechenzentren an einen Router gelangt, wird nur an Nachrichtenprozessoren in diesem Rechenzentrum weitergeleitet, da Router Traffic nur an Nachrichtenprozessoren im selben Pod weiterleiten.

Virtuelle Hosts

Ein virtueller Host definiert den Port am Edge-Router, über den ein API-Proxy verfügbar gemacht wird, und damit auch die URL, über die Apps auf den API-Proxy zugreifen. Für jede Umgebung muss mindestens ein virtueller Host definiert sein.

Achten Sie darauf, dass die vom virtuellen Host angegebene Portnummer am Routerknoten geöffnet ist. Anschließend können Sie über eine Anfrage an die folgenden URLs auf einen API-Proxy zugreifen:

http://routerIP:port/proxy-base-path/resource-name
https://routerIP:port/proxy-base-path/resource-name

Wobei:

  • http oder https: Wenn der virtuelle Host für die Unterstützung von TLS/SSL konfiguriert ist, verwenden Sie HTTPS. Wenn der virtuelle Host TLS/SSL nicht unterstützt, verwenden Sie HTTP.
  • routerIP:port ist die IP-Adresse und Portnummer des virtuellen Hosts.
  • proxy-base-path und resource-name werden beim Erstellen des API-Proxys definiert.

Normalerweise veröffentlichen Sie Ihre APIs nicht für Kunden mit einer IP-Adresse und einer Portnummer. Stattdessen definieren Sie einen DNS-Eintrag für den Router und den Port. Beispiel:

http://myAPI.myCo.com/proxy-base-path/resource-name
https://myAPI.myCo.com/proxy-base-path/resource-name

Außerdem müssen Sie einen Host-Alias für den virtuellen Host erstellen, der mit dem Domainnamen des DNS-Eintrags übereinstimmt. Im Beispiel oben würden Sie einen Host-Alias von myAPI.myCo.com angeben. Wenn Sie keinen DNS-Eintrag haben, setzen Sie den Host-Alias auf die IP-Adresse des Routers und den Port des virtuellen Hosts, z. B. routerIP:port.

Weitere Informationen finden Sie unter Informationen zu virtuellen Hosts.

Erste Organisation, Umgebung und virtueller Host erstellen

Nachdem Sie die Edge-Installation abgeschlossen haben, erstellen Sie in der Regel als Erstes eine Organisation, eine Umgebung und einen virtuellen Host über den Onboarding-Prozess. Führen Sie zum Onboarding den folgenden Befehl auf dem Edge Management Server-Knoten aus:

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

Dieser Befehl nimmt eine Konfigurationsdatei als Eingabe, in der ein Nutzer, eine Organisation, eine Umgebung und ein virtueller Host definiert werden.

Sie können beispielsweise Folgendes erstellen:

  • Einen Nutzer Ihrer Wahl, der als Organisationsadministrator fungieren soll
  • Eine Organisation mit dem Namen example
  • Eine Umgebung in der Organisation mit dem Namen prod, die mit allen Nachrichten-Prozessoren im Pod „gateway“ verknüpft ist
  • Ein virtueller Host in der Umgebung mit dem Namen default, der HTTP-Zugriff auf Port 9001 zulässt
  • Host-Alias für den virtuellen Host

Nachdem Sie dieses Script ausgeführt haben, können Sie mit einer URL im folgenden Format auf Ihre APIs zugreifen:

http://routerIP:9001/proxy-base-path/resource-name

Sie können später beliebig viele Organisationen, Umgebungen und virtuelle Hosts hinzufügen.

Weitere Informationen finden Sie unter Organisationen einrichten.