Informacje o planetach, regionach, podach, organizacjach, środowiskach i hostach wirtualnych

Edge for Private Cloud w wersji 4.18.05

Instalacja Edge Private Cloud na urządzeniu lokalnym lub instancja Edge składa się z wielu komponentów Edge zainstalowanych na zestawie węzłów serwera. Ilustracja poniżej przedstawia relacje między planetą, regionami, podami, organizacjami, środowiskami i wirtualnymi hostami, które tworzą instancję Edge:

W tabeli poniżej opisano te relacje:

Komponent Zawiera Powiązano z Domyślny
Planeta co najmniej 1 region, nie dotyczy
Region co najmniej 1 pod, „dc-1”
Pod Co najmniej 1 komponent Edge „central”
“gateway”
“analytics”
Organizacja co najmniej 1 środowisko, co najmniej 1 pod zawierający procesory wiadomości oraz użytkownika pełniącego rolę administratora organizacji; brak
Środowisko co najmniej 1 wirtualny host. co najmniej 1 serwer Message Processor w podze powiązanym z organizacją nadrzędną. brak
Prowadzący wirtualny Co najmniej 1 alias hosta brak

Informacje o Planetach

Planeta reprezentuje cały sprzęt i oprogramowanie Edge i może zawierać co najmniej 1 region. W Edge planeta to logiczna grupa regionów. Nie musisz tworzyć ani konfigurować planety w ramach instalacji Edge.

Informacje o regionach

Region to grupa co najmniej 1 poda. Podczas instalacji Edge domyślnie tworzy pojedynczy region o nazwie „dc-1”, który zawiera 3 pody, jak pokazano w tabeli poniżej:

Region Pods w regionie
„dc-1” „gateway”, „central”, „analytics”.

Ilustracja poniżej przedstawia regiony domyślne:

Ilustracja przedstawiająca system równoważenia obciążenia kierujący ruch do modułu „gateway”. Pod „bramą” kryją się komponenty Edge Router i Message Processor, które obsługują żądania interfejsu API. Jeśli nie zdefiniujesz wielu centrów danych, nie musisz tworzyć dodatkowych regionów.

W przypadku bardziej złożonej instalacji możesz utworzyć co najmniej 2 regiony. Jednym z powodów, dla których warto utworzyć kilka regionów, jest możliwość grupowania maszyn według położenia geograficznego, co minimalizuje czas przesyłania danych przez sieć. W tym scenariuszu hostujesz punkty końcowe interfejsu API tak, aby były one blisko użytkowników tych interfejsów.

W Edge każdy region jest nazywany centrum danych. Centrum danych w wschodnich Stanach Zjednoczonych może obsługiwać żądania pochodzące z Bostonu w Massachusetts, a centrum danych w Singapurze – żądania pochodzące z urządzeń lub komputerów w Azji.

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

Informacje o podach

pod to grupa co najmniej 1 komponentu Edge i co najmniej 1 bazy danych Cassandra. Komponenty Edge można instalować na tym samym węźle, ale częściej instaluje się je na różnych węzłach. Datastore Cassandra to repozytorium danych używane przez komponenty Edge w podzie.

Podczas instalacji Edge domyślnie tworzy 3 pody i powiązane z nimi te komponenty i bazy danych Cassandra:

Pod Komponenty Edge

Dane magazynu Cassandra
„gateway” Router, procesor komunikatów 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

Komponenty Edge i bazy danych Cassandra w podzbiorze „gateway” są wymagane do przetwarzania interfejsu API. Te komponenty i bazy danych muszą być uruchomione, aby przetwarzać żądania interfejsu API. Komponenty i magazyny danych w podsieciach „central” i „analytics” nie są wymagane do przetwarzania interfejsów API, ale zapewniają dodatkowe funkcje w Edge.

Ilustracja poniżej przedstawia komponenty w każdej podgrupie:

Do trzech domyślnych modułów przetwarzania wiadomości i przesyłania możesz dodać kolejne. Możesz też dodać dodatkowe komponenty Edge do istniejącego modułu. Możesz na przykład dodać do modułu „gateway” dodatkowe routery i procesory wiadomości, aby obsłużyć zwiększony ruch.

Zwróć uwagę, że moduł „gateway” zawiera komponenty Edge Router i Message Processor. Routery wysyłają żądania tylko do procesorów wiadomości w tym samym module, a nie do procesorów wiadomości w innych modułach.

Aby wyświetlić szczegóły rejestracji serwera na końcu instalacji każdego modułu, możesz użyć tego wywołania interfejsu API. 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ądzającego, a podName to jeden z tych elementów:

  • gateway
  • central
  • analytics

Na przykład w przypadku modułu „gateway”:

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

Apigee zwraca dane wyjściowe podobne do tych:

[ {
  "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 zawiera listę typów komponentów. Pamiętaj, że zawiera on listę baz danych Cassandra zarejestrowanych w podzie. Węzły Cassandra są instalowane w kontenerze „gateway”, ale bazy danych Cassandra są rejestrowane we wszystkich kontenerach.

Organizacje

Organizacja to kontener na wszystkie obiekty na koncie Apigee, w tym interfejsy API, produkty API, aplikacje i deweloperzy. Organizacja jest powiązana z co najmniej 1 podem, przy czym każdy pod musi zawierać co najmniej 1 przetwarzacz wiadomości.

W przypadku instalacji Edge Private Cloud w środowisku lokalnym domyślnie nie ma żadnych organizacji. Podczas tworzenia organizacji musisz podać 2 informacje:

  1. Użytkownik pełniący rolę administratora organizacji. Ten użytkownik może następnie dodawać kolejnych użytkowników do organizacji i przypisywać im role.
  2. Pod „bramą” – pod zawierającym procesory wiadomości.

Organizacja może zawierać co najmniej 1 środowisko. Podczas domyślnej procedury instalacji Edge pojawi się monit o utworzenie 2 środowisk: „test” i „prod”. W razie potrzeby możesz jednak utworzyć więcej środowisk, np. środowisko testowe, środowisko eksperymentalne itp.

Organizacja określa zakres niektórych funkcji Apigee. Na przykład dane mapy klucz-wartość są dostępne na poziomie organizacji, czyli ze wszystkich środowisk. Inne funkcje, takie jak buforowanie, są ograniczone do określonego środowiska. Dane analityczne Apigee są dzielone na podstawie kombinacji organizacji i środowiska.

Poniżej znajdziesz najważniejsze obiekty organizacji, w tym zdefiniowane globalnie w organizacji oraz zdefiniowane specjalnie dla środowiska:

Środowiska

Środowisko to środowisko wykonawcze proxy interfejsu API w organizacji. Zanim będzie można uzyskać dostęp do serwera proxy API, musisz go wdrożyć w środowisku. Możesz wdrożyć serwer proxy interfejsu API w jednym środowisku lub w kilku środowiskach.

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

Podczas tworzenia środowiska zostaje ono powiązane z co najmniej 1 procesorem wiadomości. Środowisko to nazwany zbiór procesorów wiadomości, na których działają proxy interfejsu API. Każde środowisko może być powiązane z tymi samymi lub innymi procesorami wiadomości.

Aby utworzyć środowisko, podaj 2 informacje:

  1. Organizacja zawierająca środowisko.
  2. Przetwarzacze wiadomości, które obsługują żądania proxy interfejsu API w środowisku. Te procesy przetwarzania wiadomości muszą znajdować się w podzbiorze powiązanym z organizacją nadrzędną środowiska.
    Domyślnie, gdy tworzysz środowisko, Edge łączy ze środowiskiem wszystkie dostępne procesory wiadomości w kontenerze „bramy”. Możesz też określić podzbiór dostępnych procesorów wiadomości, aby różne procesory wiadomości obsługiwały żądania dotyczące różnych środowisk.

Przetwarzacz wiadomości może być powiązany z wieloma środowiskami. Na przykład instalacja przeglądarki Edge zawiera 2 procesory wiadomości: A i B. Następnie w organizacji utworzysz 3 środowiska: „dev”, „test” i „prod”:

  • W środowisku „dev” skojarzysz procesor wiadomości A, ponieważ nie spodziewasz się dużej ilości ruchu.
  • W środowisku „test” skojarzysz procesor wiadomości B, ponieważ nie spodziewasz się dużej ilości ruchu.
  • W przypadku środowiska „prod” obie usługi przetwarzania wiadomości A i B są powiązane z obsługą ruchu na poziomie produkcyjnym.

Procesory wiadomości przypisane do środowiska mogą pochodzić z tego samego poda lub z wielu takich podach, obejmujących wiele regionów i centrów danych. Załóżmy na przykład, że w swojej organizacji definiujesz środowisko „globalne”, które obejmuje procesory wiadomości z 3 regionów, czyli 3 różnych centrów danych: w Stanach Zjednoczonych, Japonii i Niemczech.

Wdrożenie proxy interfejsu API w środowisku „globalnym” powoduje, że proxy interfejsu API działa na procesorach wiadomości we wszystkich 3 centrach danych. Ruch API docierający do routera w dowolnym z tych centrów danych jest kierowany tylko do procesorów wiadomości w tym samym centrum danych, ponieważ routery kierują ruch tylko do procesorów wiadomości w tym samym podzbiorze.

Wirtualni gospodarze

Host wirtualny definiuje port na routerze brzegowym, na którym jest udostępniony serwer proxy API, a także (w rozszerzeniu) adres URL, którego aplikacje używają do uzyskiwania dostępu do serwera proxy API. Każde środowisko musi zawierać co najmniej 1 host wirtualny.

Upewnij się, że port określony przez hosta wirtualnego jest otwarty w węźle Router. Następnie możesz uzyskać dostęp do serwera proxy interfejsu API, wysyłając żądanie do tych adresów URL:

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 tak, aby obsługiwał TLS/SSL, użyj protokołu HTTPS. Jeśli host wirtualny nie obsługuje TLS/SSL, użyj HTTP.
  • routerIP:port to adres IP i numer portu hosta wirtualnego.
  • Parametry proxy-base-path i resource-name są definiowane podczas tworzenia proxy interfejsu API.

Zwykle nie publikujesz interfejsów API dla klientów z adresem IP i numerem portu. Zamiast tego definiujesz 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, który pasuje do nazwy domeny wpisu DNS. W przykładzie powyżej należy podać alias hosta myAPI.myCo.com. Jeśli nie masz wpisu DNS, ustaw alias hosta na adres IP routera i port hosta wirtualnego, np. routerIP:port.

Więcej informacji znajdziesz w artykule Informacje o hostach wirtualnych.

Tworzenie pierwszej organizacji, środowiska i hosta wirtualnego

Po zakończeniu procesu instalacji Edge pierwszym krokiem jest zazwyczaj utworzenie organizacji, środowiska i hosta wirtualnego w ramach procesu „wprowadzania”. Aby przeprowadzić proces wdrożenia, uruchom to polecenie na węźle serwera Edge Management:

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

To polecenie przyjmuje jako dane wejściowe plik konfiguracji, który definiuje użytkownika, organizację, środowisko i hosta wirtualnego.

Możesz na przykład utworzyć:

  • Użytkownik wybrany przez Ciebie do pełnienia funkcji administratora organizacji
  • organizacja o nazwie example,
  • Środowisko w organizacji o nazwie prod powiązane ze wszystkimi procesorami wiadomości w podzbiorze „gateway”.
  • host wirtualny w środowisku o nazwie default, który umożliwia dostęp HTTP na porcie 9001.
  • Alias hosta dla hosta wirtualnego

Po uruchomieniu tego skryptu możesz uzyskać dostęp do interfejsów API, korzystając z adresu URL w formacie:

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 Włączanie organizacji.