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

Edge dla chmury prywatnej w wersji 4.18.05

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

W tabeli poniżej opisano te relacje:

Informacje o Planetach

Planeta reprezentuje całe środowisko sprzętowe i oprogramowanie Edge i może zawierać co najmniej 1 region. W Edge planeta to grupa logiczna regionów: nie tworzysz ani nie konfigurujesz planety w ramach instalacji Edge.

Informacje o regionach

Region to grupa składająca się z co najmniej 1 poda. Domyślnie podczas instalacji Edge instalator tworzy jeden region o nazwie „dc-1” zawierający 3 pody, jak pokazano w tabeli poniżej:

Ilustracja poniżej przedstawia regiony domyślne:

Ilustracja przedstawiająca system równoważenia obciążenia kierujący ruch do poda „gateway”. Pod „gateway” zawiera komponenty routera brzegowego i procesora komunikatów, które obsługują żądania do interfejsu API. Jeśli nie definiujesz wielu centrów danych, nie musisz tworzyć dodatkowych regionów.

W bardziej złożonej instalacji możesz utworzyć co najmniej 2 regiony. Jednym z powodów tworzenia wielu regionów jest organizowanie maszyn pod kątem geograficznym, co minimalizuje czas przesyłania danych przez sieć. W tym scenariuszu hostujesz punkty końcowe interfejsu API, aby znajdowały się geograficznie blisko użytkowników tych interfejsów API.

W Edge każdy region jest nazywany centrum danych. Centrum danych we wschodnich Stanach Zjednoczonych może obsługiwać żądania przychodzące z Bostonu w stanie Massachusetts, a centrum danych w Singapurze może obsługiwać żą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 składająca się z co najmniej 1 komponentu Edge i magazynu danych Cassandra. Komponenty Edge można zainstalować na tym samym węźle, ale częściej instaluje się je na różnych węzłach. Magazyn danych Cassandra to repozytorium danych używane przez komponenty Edge w podzie.

Domyślnie podczas instalacji Edge instalator tworzy 3 pody i powiązuje z każdym z nich te komponenty Edge i magazyny danych Cassandra:

Do przetwarzania interfejsu API wymagane są komponenty Edge i magazyny danych Cassandra w podzie „gateway”. Te komponenty i magazyny danych muszą działać, aby można było przetwarzać żądania do interfejsu API. Komponenty i magazyny danych w podach „central” i „analytics” nie są wymagane do przetwarzania interfejsów API, ale dodają do Edge dodatkowe funkcje.

Ilustracja poniżej przedstawia komponenty w każdym podzie:

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

Zwróć uwagę, że pod „gateway” zawiera komponenty routera brzegowego i procesora komunikatów. Routery wysyłają żądania tylko do procesorów komunikatów w tym samym podzie, a nie do procesorów komunikatów w innych podach.

Aby wyświetlić szczegóły rejestracji serwera po zakończeniu instalacji każdego poda, możesz użyć tego wywołania interfejsu API. To przydatne narzędzie do monitorowania.

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 jedna z tych wartości:

• gateway
• central
• analytics

Na przykład w przypadku poda „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 określa typ komponentu. Zwróć uwagę, że zawiera on listę magazynów danych Cassandra zarejestrowanych w podzie. Węzły Cassandra są zainstalowane w podzie „gateway”, ale magazyny danych Cassandra będą widoczne jako zarejestrowane we wszystkich podach.

Informacje o organizacjach

Organizacja to kontener na wszystkie obiekty na koncie Apigee, w tym interfejsy API, usługi interfejsów API, aplikacje i deweloperów. Organizacja jest powiązana z co najmniej 1 podem, a każdy pod musi zawierać co najmniej 1 procesor komunikatów.

W lokalnej instalacji Edge Private Cloud domyślnie nie ma organizacji. Podczas tworzenia organizacji podajesz 2 informacje:

1. Użytkownik, który pełni funkcję administratora organizacji. Ten użytkownik może następnie dodawać do organizacji kolejnych użytkowników i ustawiać ich role.
2. Pod „bramy”, czyli pod zawierający procesory komunikatów.

Organizacja może zawierać jedno lub więcej środowisk. Domyślna procedura instalacji Edge wyświetla prośbę o utworzenie 2 środowisk: „test” i „prod”. W razie potrzeby możesz jednak utworzyć więcej środowisk, np. „staging”, „eksperymenty” itp.

Organizacja zapewnia zakres dla niektórych funkcji Apigee. Na przykład dane mapy klucz-wartość (KVM) są dostępne na poziomie organizacji, czyli we wszystkich środowiskach. Inne funkcje, takie jak buforowanie, są ograniczone do konkretnego środowiska. Dane analityczne Apigee są podzielone na partycje według kombinacji organizacji i środowiska.

Poniżej przedstawiono główne obiekty organizacji, w tym te zdefiniowane globalnie w organizacji i te zdefiniowane specjalnie dla środowiska:

Informacje o środowiskach

Środowisko to kontekst wykonywania środowiska wykonawczego dla serwerów proxy interfejsu API w organizacji. Aby można było uzyskać dostęp do serwera proxy interfejsu API, musisz go wdrożyć w środowisku. Serwer proxy interfejsu API możesz wdrożyć w jednym środowisku lub w wielu środowiskach.

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

Podczas tworzenia środowiska powiązujesz je z co najmniej 1 procesorem komunikatów. Środowisko można traktować jako nazwany zestaw procesorów komunikatów, na których działają serwery proxy interfejsu API. Każde środowisko może być powiązane z tymi samymi lub różnymi procesorami komunikatów.

Aby utworzyć środowisko, podaj 2 informacje:

1. Organizacja zawierająca środowisko.
2. Procesory komunikatów, które obsługują żądania proxy interfejsu API do środowiska. Te procesory komunikatów muszą znajdować się w podzie powiązanym z organizacją nadrzędną środowiska.
   Domyślnie, gdy tworzysz środowisko, Edge kojarzy z nim wszystkie dostępne procesory komunikatów w podzie „brama”. Możesz też określić podzbiór dostępnych procesorów komunikatów, aby różne procesory komunikatów obsługiwały żądania do różnych środowisk.

Procesor komunikatów może być powiązany z wieloma środowiskami. Na przykład instalacja Edge zawiera 2 procesory komunikatów: A i B. Następnie tworzysz w organizacji 3 środowiska: „dev”, „test” i „prod”:

• W przypadku środowiska „dev” powiąż procesor komunikatów A, ponieważ nie spodziewasz się dużego natężenia ruchu.
• W przypadku środowiska „test” powiążesz procesor komunikatów B, ponieważ nie spodziewasz się dużego natężenia ruchu.
• W przypadku środowiska „prod” powiążesz procesory komunikatów A i B, aby obsługiwać wolumen na poziomie produkcyjnym.

Procesory komunikatów przypisane do środowiska mogą pochodzić z tego samego poda lub z wielu podów, obejmujących wiele regionów i centrów danych. Możesz na przykład zdefiniować w organizacji środowisko „globalne”, które obejmuje procesory komunikatów z 3 regionów, czyli 3 różnych centrów danych: w Stanach Zjednoczonych, Japonii i Niemczech.

Wdrożenie serwera proxy interfejsu API w środowisku „global” powoduje, że serwer proxy interfejsu API jest uruchamiany na procesorach komunikatów we wszystkich 3 centrach danych. Ruch interfejsu API docierający do routera w jednym z tych centrów danych będzie kierowany tylko do procesorów komunikatów w tym centrum danych, ponieważ routery kierują ruch tylko do procesorów komunikatów w tym samym podzie.

Informacje o hostach wirtualnych

Host wirtualny określa port routera Edge, na którym jest udostępniany serwer proxy interfejsu API, a także adres URL, którego aplikacje używają do uzyskiwania dostępu do serwera proxy interfejsu API. W każdym środowisku musi być zdefiniowany co najmniej 1 host wirtualny.

Upewnij się, że numer portu określony przez hosta wirtualnego jest otwarty w węźle routera. 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 do obsługi protokołu TLS/SSL, użyj protokołu HTTPS. Jeśli host wirtualny nie obsługuje protokołu 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 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 odpowiada nazwie domeny wpisu DNS. W przykładzie powyżej alias hosta to 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 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 Edge:

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

• wybranego przez Ciebie użytkownika, który będzie pełnił funkcję administratora organizacji;
• Organizacja o nazwie example
• środowisko w organizacji o nazwie prod, które jest powiązane ze wszystkimi procesorami komunikatów w podzie „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, używając 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 Wprowadzanie organizacji.