Über Planeten, Regionen, Pods, Organisationen, Umgebungen und virtuelle Hosts

Edge for Private Cloud Version 4.18.01

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

In der folgenden Tabelle werden diese Beziehungen beschrieben:

Enthält Verknüpft mit Standardeinstellung
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 Mindestens ein Pod mit Message Processors und einem Nutzer, der als Organisationsadministrator fungiert keine
Environment Ein oder mehrere virtuelle Hosts Mindestens ein Message Processor in einem Pod, der der übergeordneten Organisation zugeordnet ist keine
Virtueller Host Mindestens ein Hostalias keine

Über Planets

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 Planeten nicht explizit im Rahmen der Installation von Edge.

Regionen

Eine Region besteht aus einem oder mehreren Pods. Wenn Sie Edge installieren, erstellt das Installationsprogramm standardmäßig eine einzelne Region mit dem Namen "dc-1", die drei Pods enthält, wie in der folgenden Tabelle gezeigt:

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

In der folgenden Abbildung sehen Sie die Standardregionen:

Diese Abbildung zeigt den Load-Balancer, der Traffic zum 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.

In einer komplexeren Installation können Sie zwei oder mehr Regionen erstellen. Ein Grund für die Erstellung mehrerer Regionen ist die geografische Organisation von Maschinen, wodurch die Netzwerkübertragungszeit minimiert wird. In diesem Szenario hosten Sie API-Endpunkte so, dass sie sich geografisch in der Nähe der Nutzer dieser APIs befinden.

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

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

Pods

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

Wenn Sie Edge installieren, erstellt das Installationsprogramm standardmäßig drei Pods und verknüpft die folgenden Edge-Komponenten und Cassandra-Datenspeicher mit jedem Pod:

Pod Edge-Komponenten

Cassandra-Datenspeicher
"gateway" Router, Nachrichtenprozessor Cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" Management Server, Zookeeper, LDAP, UI, 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 aktiv sein, damit API-Anfragen verarbeitet werden können. Die Komponenten und Datenspeicher in den Pods „central“ und „analytics“ sind für die Verarbeitung von APIs nicht erforderlich, fügen jedoch zusätzliche Funktionen zu Edge hinzu.

In der folgenden Abbildung sind die Komponenten in jedem Pod dargestellt:

Sie können den drei standardmäßig erstellten Pods weitere Message Processor- und Router-Pods hinzufügen. Alternativ können Sie einem vorhandenen Pod zusätzliche Edge-Komponenten hinzufügen. Beispielsweise können Sie dem Pod "Gateway" zusätzliche Router und Nachrichtenprozessoren hinzufügen, um erhöhten Traffic zu bewältigen.

Beachten Sie, dass der Pod „Gateway“ die Edge Router- und den Message Processor-Komponenten enthält. Router senden Anfragen nur an Message Processorn im selben Pod und nicht an Message Processorn in anderen Pods.

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

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

  • gateway
  • central
  • analytics

Hier ein Beispiel für den Pod "gateway":

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

Die Ausgabe sieht im folgenden Format aus:

[ {
  "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"
} ]

Das Attribut type gibt den Komponententyp an. Die im Pod registrierten Cassandra-Datenspeicher werden aufgelistet. Während Cassandra-Knoten im Pod "Gateway" installiert sind, sehen Sie Cassandra-Datenspeicher, die mit 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, wobei jeder Pod einen oder mehrere Message Processor enthalten muss.

In einer lokalen Installation von Edge Private Cloud sind standardmäßig keine Organisationen vorhanden. 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 Message Processors.

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“, „Experimente“ usw.

Organisation bietet Umfang für einige Apigee-Funktionen. So sind beispielsweise KVM-Daten (Schlüssel/Wert-Paare) auf Organisationsebene verfügbar, d. h. aus allen Umgebungen. Andere Funktionen, wie etwa das Caching, sind auf eine bestimmte Umgebung beschränkt. Apigee-Analysedaten werden nach einer Kombination aus Organisation und Umgebung partitioniert.

Im Folgenden sind die wichtigsten Objekte einer Organisation aufgeführt, einschließlich jener, die global in der Organisation oder speziell für eine Umgebung definiert sind:

Umgebungen

Eine Umgebung ist ein Kontext der Laufzeitausführung 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 eine „dev“-, „test“- und „prod“-Umgebung in einer Organisation definieren.

Wenn Sie eine Umgebung erstellen, verknüpfen Sie sie mit einem oder mehreren Message Processorn. Sie können sich eine Umgebung als eine benannte Gruppe von Message Processorn vorstellen, auf denen API-Proxys ausgeführt werden. Jede Umgebung kann mit denselben oder verschiedenen Message Processorn verknüpft werden.

Um eine Umgebung zu erstellen, geben Sie 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 Processorn müssen sich in einem Pod befinden, der der übergeordneten Organisation der Umgebung zugeordnet ist.
    Beim Erstellen einer Umgebung ordnet Edge standardmäßig alle verfügbaren Nachrichtenprozessoren im Pod "Gateway" der Umgebung zu. Alternativ können Sie eine Teilmenge der verfügbaren Message Processor angeben, sodass verschiedene Message Processor Anfragen an verschiedene Umgebungen verarbeiten können.

Ein Message Processor kann mehreren Umgebungen zugeordnet werden. Ihre Edge-Installation enthält beispielsweise zwei Nachrichtenprozessoren: A und B. Anschließend erstellen Sie drei Umgebungen in Ihrer Organisation: "dev", "test" und "prod":

  • Für die „dev“-Umgebung ordnen Sie Message Processor A zu, da Sie kein hohes Traffic-Volumen erwarten.
  • Für die "Test"-Umgebung ordnen Sie Message Processor B zu, da Sie kein hohes Traffic-Volumen erwarten.
  • Für die Produktionsumgebung ordnen Sie die Message Processor A und B für die Verarbeitung des Volumens auf Produktionsebene zu.

Die einer Umgebung zugewiesenen Message Processors können alle aus demselben Pod stammen oder von mehreren Pods stammen, die sich über mehrere Regionen und Rechenzentren erstrecken. Sie definieren beispielsweise die Umgebung „global“ in Ihrer Organisation, die Message Processors aus drei Regionen enthält, d. h. aus drei verschiedenen Rechenzentren: USA, Japan und Deutschland.

Durch die Bereitstellung eines API-Proxys in der "globalen" Umgebung wird der API-Proxy auf Message Processorn in allen drei Rechenzentren ausgeführt. API-Traffic, der bei einem Router in einem dieser Rechenzentren ankommt, wird nur an Message Processor in diesem Rechenzentrum weitergeleitet, da Router nur Traffic an Message Processorn im selben Pod weiterleiten.

Virtuelle Hosts

Ein virtueller Host definiert den Port am Edge Router, auf dem ein API-Proxy verfügbar gemacht wird, und folglich die URL, mit der Apps auf den API-Proxy zugreifen. Jede Umgebung muss mindestens einen virtuellen Host definieren.

Achten Sie darauf, dass die vom virtuellen Host angegebene Portnummer auf dem Routerknoten offen ist. Sie können dann auf einen API-Proxy zugreifen, indem Sie folgende Anfrage stellen:

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

Dabei gilt:

  • http oder https: Wenn der virtuelle Host so konfiguriert ist, dass er TLS/SSL unterstützt, 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.

In der Regel werden APIs nicht mit einer IP-Adresse und Portnummer für Kunden veröffentlicht. 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 Hostalias für den virtuellen Host erstellen, der mit dem Domainnamen des DNS-Eintrags übereinstimmt. Im obigen Beispiel würden Sie den Hostalias myAPI.myCo.com angeben. Wenn Sie keinen DNS-Eintrag haben, legen Sie den Hostalias auf die IP-Adresse des Routers und den Port des virtuellen Hosts als routerIP:port fest.

Weitere Informationen finden Sie unter Informationen zu virtuellen Hosts.

Erste Organisation, Umgebung und ersten virtuellen Host erstellen

Nachdem Sie die Edge-Installation abgeschlossen haben, besteht Ihre erste Aktion in der Regel darin, im Rahmen des Onboarding-Prozesses eine Organisation, eine Umgebung und einen virtuellen Host zu erstellen. Führen Sie den folgenden Befehl auf dem Edge Management Server-Knoten aus, um das Onboarding durchzuführen:

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

Dieser Befehl verwendet als Eingabe eine Konfigurationsdatei, die einen Nutzer, eine Organisation, eine Umgebung und einen virtuellen Host definiert.

Sie erstellen beispielsweise:

  • Ein Nutzer Ihrer Wahl, der als Organisationsadministrator fungiert.
  • Eine Organisation mit dem Namen example
  • Eine Umgebung in der Organisation mit dem Namen prod, die allen Nachrichtenprozessoren im Pod "Gateway" zugeordnet ist
  • Ein virtueller Host in der Umgebung mit dem Namen default, der HTTP-Zugriff auf Port 9001 zulässt
  • Hostalias für den virtuellen Host

Nachdem Sie das Skript ausgeführt haben, können Sie über eine URL im folgenden Format auf Ihre APIs zugreifen:

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

Sie können später eine beliebige Anzahl von Organisationen, Umgebungen und virtuellen Hosts hinzufügen.

Weitere Informationen finden Sie unter Organisation aufnehmen.