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

Edge for Private Cloud v4.18.05

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

In der folgenden Tabelle werden diese Beziehungen beschrieben:

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

Informationen zu Regionen

Eine Region ist eine Gruppierung von 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:

In der folgenden Abbildung sind die Standardregionen zu sehen:

In diesem Bild leitet der Load Balancer Traffic an den „Gateway“-Pod weiter. Der „Gateway“-Pod enthält die Edge Router- und Message Processor-Komponenten, die API-Anfragen verarbeiten. Sofern Sie nicht mehrere Rechenzentren definieren, müssen Sie keine zusätzlichen Regionen erstellen.

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

Die Edge-Komponenten und Cassandra-Datenspeicher im „Gateway“-Pod sind für die API-Verarbeitung erforderlich. Diese Komponenten und Datenspeicher müssen aktiv sein, um API-Anfragen zu verarbeiten. Die Komponenten und Datenspeicher in den Pods „central“ und „analytics“ sind nicht für die Verarbeitung von APIs erforderlich, fügen Edge jedoch zusätzliche Funktionen hinzu.

Die folgende Abbildung zeigt die Komponenten in jedem Pod:

Sie können den drei standardmäßig erstellten Message Processor- und Router-Pods zusätzliche Pods hinzufügen. Alternativ können Sie einem vorhandenen Pod zusätzliche Edge-Komponenten hinzufügen. Sie können beispielsweise zusätzliche Router und Message Processor zum Pod „Gateway“ hinzufügen, um höhere Trafficlasten zu bewältigen.

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

Mit dem folgenden API-Aufruf können Sie die Serverregistrierungsdetails 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 Management Servers und podName einer der folgenden Werte:

• 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 Attribut type wird der Komponententyp aufgeführt. Beachten Sie, dass die im Pod registrierten Cassandra-Datenspeicher aufgelistet werden. Während Cassandra-Knoten im „Gateway“-Pod installiert sind, werden Cassandra-Datenspeicher bei allen Pods registriert.

Informationen zu Organisationen

Eine Organisation ist ein Container für alle Objekte in einem Apigee-Konto, einschließlich APIs, API-Produkte, Anwendungen und Entwickler. Eine Organisation ist einem oder mehreren Pods zugeordnet, wobei jeder Pod einen oder mehrere Message Processors enthalten muss.

In einer lokalen 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 dann der Organisation weitere Nutzer hinzufügen und die Rolle jedes Nutzers festlegen.
2. Der „Gateway“-Pod, der die Message Processor enthält.

Eine Organisation kann eine oder mehrere Umgebungen enthalten. Bei der Standardinstallation von Edge werden Sie aufgefordert, zwei Umgebungen zu erstellen: „test“ und „prod“. Sie können jedoch bei Bedarf weitere Umgebungen erstellen, z. B. „Staging“, „Tests“ usw.

Die Organisation bietet einen Bereich für einige Apigee-Funktionen. Beispielsweise sind Daten der Schlüsselwertzuordnung (KVM) auf Organisationsebene verfügbar, d. h. aus allen Umgebungen. Andere Funktionen wie 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 der Objekte, die global in der Organisation definiert sind, und der Objekte, die speziell für eine Umgebung definiert sind:

Informationen zu 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, verknüpfen Sie sie mit einem oder mehreren Message Processors. Sie können sich eine Umgebung als benannten Satz von Message Processors vorstellen, auf denen API-Proxys ausgeführt werden. Jede Umgebung kann mit denselben oder mit unterschiedlichen Message Processors verknüpft werden.

Zum Erstellen einer Umgebung müssen Sie zwei Informationen angeben:

1. Die Organisation, die die Umgebung enthält.
2. Die Message Processors, die API-Proxy-Anfragen an die Umgebung verarbeiten. Diese Message Processor müssen sich in einem Pod befinden, der mit der übergeordneten Organisation der Umgebung verknüpft ist.
   Wenn Sie eine Umgebung erstellen, verknüpft Edge standardmäßig alle verfügbaren Message Processor im „Gateway“-Pod mit der Umgebung. Alternativ können Sie eine Teilmenge der verfügbaren Message Processors angeben, sodass verschiedene Message Processors Anfragen an verschiedene Umgebungen verarbeiten.

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

• Für die „dev“-Umgebung verknüpfen Sie den Message Processor A, da Sie kein großes Traffic-Volumen erwarten.
• Für die „Test“-Umgebung verknüpfen Sie Message Processor B, da Sie kein großes Trafficvolumen erwarten.
• Für die „prod“-Umgebung verknüpfen Sie sowohl Message Processor A als auch Message Processor B, um das Produktionsvolumen zu verarbeiten.

Die einer Umgebung zugewiesenen Message Processors können alle aus demselben Pod oder aus 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, d. h. drei verschiedenen Rechenzentren, enthält: USA, Japan und Deutschland.

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

Virtuelle Hosts

Ein virtueller Host definiert den Port auf dem Edge-Router, über den ein API-Proxy verfügbar gemacht wird, und damit die URL, über die Anwendungen auf den API-Proxy zugreifen. In jeder Umgebung muss mindestens ein virtueller Host definiert sein.

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

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.

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

Weitere Informationen finden Sie unter Virtuelle Hosts.

Erste Organisation, Umgebung und virtuellen Host erstellen

Nach Abschluss der Edge-Installation besteht Ihre erste Aktion in der Regel darin, eine Organisation, eine Umgebung und einen virtuellen Host über den Onboarding-Prozess zu erstellen. Führen Sie das Onboarding auf dem Edge Management Server-Knoten mit dem folgenden Befehl aus:

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

• Ein Nutzer Ihrer Wahl, der als Administrator der Organisation fungiert
• Eine Organisation mit dem Namen example
• Eine Umgebung in der Organisation mit dem Namen prod, die mit allen Message Processors im Pod „gateway“ verknüpft ist
• Ein virtueller Host in der Umgebung mit dem Namen default, der HTTP-Zugriff auf Port 9001 ermöglicht
• Host-Alias für den virtuellen Host

Nachdem Sie dieses 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 beliebig viele Organisationen, Umgebungen und virtuelle Hosts hinzufügen.

Weitere Informationen finden Sie unter Organisation einrichten.