Planety, regiony, pody, organizacje, środowiska i hosty wirtualne

Edge for Private Cloud w wersji 4.18.01

Lokalna instalacja Edge Private Cloud (instancji brzegowej) składa się z wielu komponentów brzegowych zainstalowanych w zestawie węzłów serwera. Poniższy obraz przedstawia relację między planetą, regionami, podami, organizacjami, środowiskami i hostami wirtualnymi, które składają się na instancję brzegową:

Poniższa tabela opisuje te relacje:

Zawiera Powiązano Domyślnie
Planeta Co najmniej jeden region Nie dotyczy
Region Co najmniej jeden pod „dc-1”
Blok reklamowy Co najmniej jeden komponent Edge "central"
"gateway"
"analytics"
Organizacja Co najmniej jedno środowisko Co najmniej jeden pod zawierający procesory wiadomości oraz użytkownik pełniący rolę administratora organizacji brak
Środowisko Co najmniej jeden host wirtualny Co najmniej jeden podmiot przetwarzający wiadomości w podzie powiązanym z organizacją nadrzędną brak
Host wirtualny Co najmniej jeden alias hosta brak

Informacje o planetach

Planeta reprezentuje całe środowisko sprzętu i oprogramowania Edge i może zawierać 1 lub więcej regionów. W przeglądarce Edge planeta to logiczna grupa regionów – nie musisz jej specjalnie tworzyć ani konfigurować podczas instalowania Edge.

Regiony

Region to grupa obejmująca co najmniej 1 pod. Domyślnie podczas instalowania Edge instalator tworzy pojedynczy region o nazwie „dc-1” z 3 podami, jak pokazuje poniższa tabela:

Region Pody w regionie
„dc-1” „gateway”, „central”, „analytics”;

Ta ilustracja przedstawia regiony domyślne:

Ten obraz przedstawia system równoważenia obciążenia kierujący ruch do poda „brama”. Pod „brama” zawiera komponenty routera brzegowego i procesora wiadomości, które obsługują żądania do interfejsu API. Jeśli nie zdefiniujesz kilku centrów danych, nie musisz tworzyć dodatkowych regionów.

W bardziej złożonej instalacji możesz utworzyć 2 lub więcej regionów. Jednym z powodów utworzenia wielu regionów jest uporządkowanie komputerów według położenia geograficznego, co minimalizuje czas przewozu sieci. W tym scenariuszu hostujesz punkty końcowe API w taki sposób, aby były zbliżone do konsumentów tych interfejsów API pod względem geograficznym.

W Edge każdy region jest określany jako centrum danych. Centrum danych we wschodnich Stanach Zjednoczonych będzie w stanie obsługiwać żądania napływające z Bostonu w stanie Massachusetts, a centrum danych w Singapurze – z urządzeń i komputerów w Azji.

Na przykład na ilustracji widać 2 regiony odpowiadające 2 centrom danych:

Informacje o podach

Pod to grupa obejmująca co najmniej 1 komponent Edge i magazyn danych Cassandra. Komponenty Edge można zainstalować w tym samym węźle, ale częściej w różnych węzłach. Magazyn danych Cassandra to repozytorium danych używane przez komponenty Edge w podzie.

Domyślnie podczas instalowania Edge instalator tworzy 3 pody i wiąże z każdym podem te komponenty Edge i magazyny danych Cassandra:

Blok reklamowy Komponenty Edge

Magazyny danych Cassandra
"gateway" Router, procesor wiadomości cache-datastore
counter-datastore
dc-datastore 		baza-danych-map-kluczy
kms-datastore
"central" Serwer zarządzania, 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

Do przetwarzania interfejsu API są wymagane komponenty brzegowe i magazyny danych Cassandra w podzie „bramy”. Te komponenty i magazyny danych muszą być uruchomione, aby przetwarzać żądania do interfejsu API. Komponenty i magazyny danych w podach „central” i „analytics” nie są wymagane do przetwarzania interfejsów API, ale dodają dodatkowe funkcje do Edge.

Poniższa ilustracja przedstawia komponenty w każdym bloku reklamowym:

Do tych 3 utworzonych domyślnie możesz dodać pody procesora wiadomości i routera. Do istniejącego poda możesz też dodać dodatkowe komponenty Edge. Możesz na przykład dodać do poda „brama” dodatkowe routery i procesory wiadomości, aby obsłużyć zwiększone obciążenie.

Zwróć uwagę, że pod „gateway” (brama) zawiera komponenty Router brzegowy i procesor wiadomości. Routery wysyłają żądania tylko do procesorów wiadomości w tym samym podzie, a nie do procesorów wiadomości w innych podach.

Możesz użyć poniższego wywołania interfejsu API, aby wyświetlić szczegóły rejestracji serwera na koniec instalacji dla każdego poda. Jest to przydatne narzędzie monitorujące.

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

gdzie ms_IP to adres IP lub nazwa DNS serwera zarządzania, a podName to:

  • gateway
  • central
  • analytics

Na przykład w przypadku poda „gateway”:

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

Dane wyjściowe zobaczysz w tym formacie:

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

Atrybut type podaje typ komponentu. Pamiętaj, że zawiera ona listę magazynów danych Cassandra zarejestrowanych w podzie. Podczas gdy węzły Cassandra są instalowane w podzie „bramy”, zobaczysz magazyny danych Cassandra zarejestrowane we wszystkich podach.

Informacje o organizacjach

Organizacja to kontener na wszystkie obiekty na koncie Apigee, w tym interfejsy API, usługi API, aplikacje i programistów. Organizacja jest powiązana z co najmniej jednym podem, w którym każdy pod musi zawierać co najmniej 1 procesor wiadomości.

W lokalnej instalacji Edge Private Cloud domyślnie nie ma żadnych organizacji. Podczas tworzenia organizacji należy podać 2 rodzaje informacji:

  1. Użytkownik, który pełni funkcję administratora organizacji. Ten użytkownik może następnie dodawać kolejnych użytkowników do organizacji i określać rolę każdego z nich.
  2. Pod „bramy”, czyli pod zawierający procesory wiadomości.

Organizacja może zawierać 1 lub więcej środowisk. Domyślna procedura instalacji brzegowej prosi o utworzenie 2 środowisk: „test” i „prod”. W razie potrzeby możesz jednak utworzyć więcej środowisk, na przykład „etap przejściowy”, „eksperymenty” itp.

Organizacja określa zakres niektórych funkcji Apigee. Na przykład dane mapy klucz-wartość (KVM) są dostępne na poziomie organizacji, czyli ze wszystkich środowisk. Inne możliwości, takie jak zapisywanie w pamięci podręcznej, są ograniczone do określonego środowiska. Dane analizy Apigee są partycjonowane według kombinacji organizacji i środowiska.

Poniżej znajdują się główne obiekty organizacji, w tym te zdefiniowane globalnie w organizacji oraz te zdefiniowane konkretnie dla środowiska:

Środowiska

Środowisko to kontekst wykonywania w czasie działania serwerów proxy interfejsów API w organizacji. Aby uzyskać dostęp do środowiska, musisz wdrożyć w środowisku serwer proxy interfejsu API. Serwer proxy interfejsu API możesz wdrożyć w jednym lub w wielu środowiskach.

Organizacja może zawierać wiele środowisk. Możesz na przykład zdefiniować środowisko „dev”, „testowe” i „produkcyjne” w organizacji.

Podczas tworzenia środowiska musisz je powiązać z co najmniej jednym procesorem wiadomości. Środowisko można wyobrazić sobie jako nazwany zestaw procesorów wiadomości, na których działają serwery proxy API. Każde środowisko może być powiązane z tymi samymi procesorami wiadomości lub z różnymi.

Aby utworzyć środowisko, podaj 2 informacje:

  1. Organizacja zawierająca środowisko.
  2. Procesory wiadomości obsługujące do środowiska żądania serwera proxy interfejsu API. Te procesory wiadomości muszą być w podze powiązanym z organizacją nadrzędną środowiska.
    Podczas tworzenia środowiska Edge domyślnie łączy ze środowiskiem wszystkie dostępne procesory wiadomości w podzie „brama”. Możesz też określić podzbiór dostępnych procesorów wiadomości, aby różne procesory wiadomości obsługiwały żądania wysyłane do różnych środowisk.

Procesor wiadomości można powiązać z wieloma środowiskami. Na przykład Twoja instalacja Edge zawiera 2 procesory wiadomości: A i B. Następnie tworzysz w swojej organizacji 3 środowiska: „dev”, „test” i „prod”:

  • W środowisku „deweloperskim” musisz powiązać podmiot przetwarzający wiadomości A, ponieważ nie spodziewasz się dużego natężenia ruchu.
  • W środowisku „testowym” powiązano podmiot przetwarzający wiadomości B, ponieważ nie spodziewasz się dużego natężenia ruchu.
  • W środowisku „prod” musisz powiązać procesory wiadomości A i B do obsługi woluminu na poziomie produkcyjnym.

Procesory wiadomości przypisane do środowiska mogą pochodzić z tego samego poda lub z wielu podów obejmujących wiele regionów i centrów danych. Definiujesz na przykład środowisko „globalne” w organizacji, które obejmuje firmy obsługujące wiadomości z 3 regionów, czyli 3 centra danych: Stany Zjednoczone, Japonia i Niemcy.

Wdrożenie serwera proxy interfejsu API w środowisku „globalnym” powoduje, że serwer proxy interfejsu API działa w procesorach wiadomości we wszystkich 3 centrach danych. Ruch API trafiający do routera w dowolnym z tych centrów danych będzie kierowany tylko do procesorów wiadomości w tym centrum danych, ponieważ routery kierują ruch wyłącznie do procesorów wiadomości w tym samym podzie.

Informacje o hostach wirtualnych

Host wirtualny określa port w routerze brzegowym, w którym dostępny jest serwer proxy interfejsu API, a także adres URL, którego aplikacje używają, aby uzyskać dostęp do serwera proxy interfejsu API. W każdym środowisku musi być zdefiniowany co najmniej 1 host wirtualny.

Sprawdź, czy numer portu określony przez hosta wirtualnego jest otwarty w węźle routera. Aby uzyskać dostęp do serwera proxy interfejsu API, wyślij żądanie do:

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

gdzie:

  • http lub https: jeśli host wirtualny jest skonfigurowany do obsługi TLS/SSL, użyj HTTPS. Jeśli host wirtualny nie obsługuje TLS/SSL, użyj protokołu HTTP.
  • routerIP:port to adres IP i numer portu hosta wirtualnego.
  • proxy-base-path i resource-name są definiowane podczas tworzenia serwera proxy interfejsu API.

Zwykle nie publikujesz interfejsów API dla klientów z adresem IP i numerem portu. Zamiast tego możesz zdefiniować wpis DNS dla routera i portu. Na przykład:

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

Musisz też utworzyć alias hosta dla hosta wirtualnego zgodny z nazwą domeny we wpisie DNS. Z przykładu powyżej określ alias hosta myAPI.myCo.com. Jeśli nie masz wpisu DNS, ustaw alias hosta na adres IP routera i port hosta wirtualnego na routerIP:port.

Aby dowiedzieć się więcej, przeczytaj Informacje o hostach wirtualnych.

Tworzę pierwszą organizację, środowisko i hosta wirtualnego

Po zakończeniu procesu instalacji Edge Twoim pierwszym działaniem jest zwykle utworzenie organizacji, środowiska i hosta wirtualnego w ramach procesu wprowadzenia. Aby przeprowadzić wprowadzenie, uruchom to polecenie w węźle serwera zarządzania brzegowym:

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

To polecenie przyjmuje jako wejściowy plik konfiguracyjny definiujący użytkownika, organizację, środowisko i hosta wirtualnego.

Możesz na przykład utworzyć:

  • wybrany przez Ciebie użytkownik, który ma pełnić funkcję administratora organizacji;
  • Organizacja o nazwie example
  • Środowisko w organizacji o nazwie prod, które jest powiązane ze wszystkimi procesorami wiadomości w podzie „bramy”
  • Host wirtualny w środowisku o nazwie default, który zezwala na dostęp HTTP na porcie 9001
  • Alias hosta dla hosta wirtualnego

Po uruchomieniu tego skryptu możesz uzyskać dostęp do swoich interfejsów API za pomocą adresu URL w postaci:

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

Później możesz dodać dowolną liczbę organizacji, środowisk i hostów wirtualnych.

Więcej informacji znajdziesz w artykule Rejestrowanie organizacji.