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 dem Planeten, den Regionen, Pods, Organisationen, Umgebungen und virtuellen Hosts Edge-Instanz:

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 Mindestens eine Umgebung Mindestens ein Pod mit Message Processors und einem Nutzer, der als Organisationsadministrator fungiert keine
Umgebung Einen oder mehrere virtuelle Hosts Mindestens ein Message Processor in einem Pod, der mit der übergeordneten Organisation verknüpft ist keine
Virtueller Host Ein oder mehrere Host-Aliasse keine

Über Planets

Ein Planet repräsentiert eine gesamte Edge-Hardware- und -Softwareumgebung und kann eine oder mehrere Regionen. In Edge ist ein Planet eine logische Gruppierung von Regionen: explizit einen Planeten im Rahmen der Installation von Edge erstellen oder konfigurieren.

Regionen

Eine Region ist eine Gruppe aus einem oder mehreren Pods. Standardmäßig wird bei der Installation von Edge der das Installationsprogramm eine einzelne Region mit dem Namen "dc-1" erstellt. mit drei Pods, wie in der folgenden Tabelle Shows:

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

In der folgenden Abbildung sehen Sie die Standardregionen:

Dieses Bild zeigt, wie der Load-Balancer Traffic an das „Gateway“ weiterleitet Pod. Das „Gateway“ Pod enthält die Komponenten Edge Router und Message Processor, die API-Anfragen verarbeiten. Es sei denn, Sie mehrere Rechenzentren definieren, sollten Sie keine zusätzlichen Regionen erstellen müssen.

Bei einer komplexeren Installation können Sie zwei oder mehr Regionen erstellen. Ein Grund für das Erstellen in mehreren Regionen besteht darin, Maschinen geografisch zu organisieren, wodurch die Netzwerkübertragungszeit minimiert wird. In In diesem Szenario hosten Sie API-Endpunkte so, dass sie geografisch in der Nähe des die Nutzer dieser APIs nutzen.

In Edge wird jede Region als Rechenzentrum bezeichnet. Ein Rechenzentrum in der Anfragen aus Boston, Massachusetts, können dann bearbeitet werden, während ein Rechenzentrum Singapur kann Anfragen von Geräten oder Computern in Asien verarbeiten.

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

Informationen zu Pods

Ein Pod ist eine Gruppierung aus einer oder mehreren Edge-Komponenten und Cassandra-Datenspeichern. Der Rand 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 folgende Edge-Komponenten und Cassandra-Datenspeicher mit jedem Pod:

Pod Edge-Komponenten

Cassandra-Datenspeicher

"Gateway" Router, Message Processor Cache-Datenspeicher
Zähler-Datenspeicher
dc-datastore
keyvaluemap-datastore
kms-datastore
"Mitte" Verwaltungsserver, 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 "Gateway" Pods sind für die API erforderlich Datenverarbeitung. Diese Komponenten und Datenspeicher müssen aktiv sein, damit API-Anfragen verarbeitet werden können. Die Komponenten und Datenspeicher in der Mitte und „Analytics“ Pods sind zur Verarbeitung von APIs nicht erforderlich. sondern um Edge zusätzliche Funktionen.

In der folgenden Abbildung sehen Sie die Komponenten der einzelnen Pods:

Sie können zusätzliche Message Processor- und Router-Pods zu den drei Pods hinzufügen, die von Standardeinstellung. Alternativ können Sie einem vorhandenen Pod zusätzliche Edge-Komponenten hinzufügen. Beispiel: können Sie dem Gateway weitere Router und Message Processor hinzufügen. Pod zum Verarbeiten von erhöhten und die Anzahl der Zugriffe.

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

Mit dem folgenden API-Aufruf können Sie sich Details zur Serverregistrierung am Ende des Installation für die einzelnen Pods. 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 ist einer der folgenden Werte:

  • gateway
  • central
  • analytics

Für das Gateway Pod:

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

Die Ausgabe von Apigee sieht in etwa so 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"
} ]

Mit dem Attribut type wird der Komponententyp aufgelistet. Beachten Sie, dass die Cassandra- Datenspeichern, die im Pod registriert sind. Während Cassandra-Knoten im „Gateway“ installiert werden Pod, du sehen die 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-Produkte, Apps und Entwickler Eine Organisation ist mit einem oder mehreren Pods verknüpft. Dabei muss jeder Pod einen oder mehrere Message Processor enthalten.

In einer lokalen Installation von Edge Private Cloud sind standardmäßig keine Organisationen vorhanden. Beim Erstellen einer Organisation geben Sie zwei Informationen an:

  1. Ein Nutzer, der als Organisationsadministrator fungiert. Dieser Nutzer kann dann weitere Nutzer der Organisation zu und legen Sie die Rolle der einzelnen Nutzer fest.
  2. Das „Gateway“ -Pod, der die Message Processors enthält.

Eine Organisation kann eine oder mehrere Umgebungen enthalten. Das standardmäßige Edge-Installationsverfahren werden Sie aufgefordert, zwei Umgebungen zu erstellen: „test“. und "prod". Sie können jedoch weitere Umgebungen wie „Staging“, „Tests“ usw.

Die Organisation bietet einen Bereich für einige Apigee-Funktionen. Beispiel: Schlüsselwertzuordnung (KVM) Daten auf Organisationsebene, d. h. aus allen Umgebungen, verfügbar sind. Weitere Funktionen, wie Caching, auf eine bestimmte Umgebung beschränkt sind. Apigee-Analysedaten sind nach einem Kombination aus Organisation und Umgebung.

Im Folgenden sind die wichtigsten Objekte einer Organisation aufgeführt, einschließlich der global definierten in der Organisation, und solchen, die spezifisch für eine Umgebung definiert sind:

Informationen zu Umgebungen

Eine Umgebung ist ein Kontext zur 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 z. B. „dev“, "test" und "prod" in einem Unternehmen zu schaffen.

Wenn Sie eine Umgebung erstellen, verknüpfen Sie sie mit einem oder mehreren Message Processor. Sie können Stellen Sie sich eine Umgebung als benannten Satz von Message Processors vor, auf denen API-Proxys ausgeführt werden. Jeden -Umgebung kann mit denselben oder unterschiedlichen Message Processors verknüpft werden.

Geben Sie zum Erstellen einer Umgebung zwei Informationen an:

  1. Die Organisation, in der die Umgebung enthalten ist.
  2. Die Message Processor, die API-Proxyanfragen an die Umgebung verarbeiten. Diese Nachrichten Prozessoren 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 in das „Gateway“ Pod mit der Umgebung. Alternativ können Sie eine Teilmenge der Daten dass verschiedene Message Processor Anfragen an verschiedene Umgebungen.

Ein Message Processor kann mit mehreren Umgebungen verknüpft sein. Beispiel: Ihr Edge- die Installation zwei Message Processors: A und B. Dann erstellen Sie drei Umgebungen in Ihrem Organisation: "dev", "test" und "prod":

  • Für den Parameter „dev“ ordnen Sie den Nachrichtenprozessor A zu, ein hohes Traffic-Volumen.
  • Für den „Test“ ordnen Sie den Message Processor B zu, da Sie keinen ein hohes Traffic-Volumen.
  • Für das Feld "prod" ordnen Sie die Message Processor A und B zur Verarbeitung der auf Produktionsniveau.

Die einer Umgebung zugewiesenen Message Processor können alle aus demselben Pod stammen oder aus mehrere Pods, die sich über mehrere Regionen und Rechenzentren erstrecken. Beispielsweise definieren Sie die Umgebung „global“ mit Message Processor aus drei Regionen, also drei Rechenzentren: die USA, Japan und Deutschland.

API-Proxy für „global“ bereitstellen Umgebung führt dazu, dass der API-Proxy für Nachricht ausgeführt wird. Prozessoren in allen drei Rechenzentren. API-Traffic, der an einem Router in einem dieser Rechenzentren nur an Message Processor in diesem Rechenzentrum weitergeleitet werden, da Router Traffic wird nur an Message Processor im selben Pod weitergeleitet.

Informationen zu virtuellen Hosts

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

Achten Sie darauf, dass die vom virtuellen Host angegebene Portnummer auf dem Routerknoten geöffnet ist. Sie können Greifen Sie dann auf einen API-Proxy zu, indem Sie eine Anfrage an die folgenden URLs stellen:

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

Wobei:

  • http oder https: Wenn der virtuelle Host so konfiguriert ist, 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 definiert. den API-Proxy.

Normalerweise veröffentlichen Sie Ihre APIs nicht für Kunden mit einer IP-Adresse und 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 übereinstimmt. zu erstellen. Im obigen Beispiel würden Sie myAPI.myCo.com als Hostalias angeben. Wenn Sie keinen DNS-Eintrag haben, legen Sie als Host-Alias die IP-Adresse des Routers und den Port von den virtuellen Host als routerIP:port.

Weitere Informationen finden Sie unter Informationen zu virtuellen Hosts.

Wenn Sie Ihre erste Organisation erstellen, Umgebung und virtueller Host

Nach Abschluss der Edge-Installation besteht Ihre erste Aktion normalerweise darin, eine Organisation, Umgebung und virtuellem Host durch das Onboarding . Leistung führen Sie den folgenden Befehl auf dem Knoten des Edge-Verwaltungsservers aus:

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

Dieser Befehl akzeptiert als Eingabe eine Konfigurationsdatei, die einen Nutzer, eine Organisation, eine Umgebung und virtueller Host.

Sie erstellen zum Beispiel:

  • Einen Nutzer Ihrer Wahl, der als Organisationsadministrator fungiert
  • Eine Organisation namens example
  • Eine Umgebung in der Organisation namens prod, die mit allen Nachrichten verknüpft ist Prozessoren im „Gateway“ Pod
  • Ein virtueller Host in der Umgebung namens default, der HTTP-Zugriff auf den Port zulässt 9001
  • 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.