Edge for Private Cloud Version 4.17.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:
Enthält |
Verknüpft mit |
Standard |
|
---|---|---|---|
Planet |
Eine oder mehrere Regionen |
– |
|
Region |
Ein oder mehrere Pods |
„dc-1“ |
|
Pod |
Eine oder mehrere Edge-Komponenten |
"Mitte" |
|
Organisation |
Eine oder mehrere Umgebungen |
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 diese geografisch "nahe" am 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 |
keyvaluemap-datastore |
"Mitte" |
Verwaltungsserver, Zookeeper, LDAP, UI, Qpid |
application-datastore |
identityzone-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 entweder:
- Gateway
- Zentral
- Analytics
Für das Gateway Pod:
> curl -u adminEmail:pword http://<ms_IP>:8080/v1/servers?pod=gateway
Die Ausgabe sieht 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" } ]
Das type-Attribut gibt den Komponententyp an. 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:
- Ein Nutzer, der als Organisationsadministrator fungiert. Dieser Nutzer kann dann weitere Nutzer der Organisation zu und legen Sie die Rolle der einzelnen Nutzer fest.
- 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:
- Die Organisation, in der die Umgebung enthalten ist.
- 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.
Über virtuelle 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:
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, 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. Adresse und Portnummer des virtuellen Hosts.
- {proxy-base-path} und {resource-name} sind definiert wenn Sie den API-Proxy erstellen.
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}
Sie müssen auch 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 http://apigee.com/docs/api-services/content/virtual-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 mit dem Namen beispiel
- 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://<router-ip>: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 Onboarding eines Organisation.