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

Edge for Private Cloud w wersji 4.19.01

Lokalna instalacja Edge Private Cloud (instancji Edge) składa się z wielu Komponenty brzegowe zainstalowane w zbiorze węzłów serwera. Poniższa grafika pokazuje relację z planety, regionów, podów, organizacji, środowisk i hostów wirtualnych, z których składa się Instancja Edge:

Te relacje są opisane w tabeli poniżej:

Komponent Zawiera Powiązano z Domyślny
Planeta Co najmniej jeden region nie dotyczy
Region Co najmniej 1 pod „dc-1”
Blok reklamowy Co najmniej 1 komponent Edge "central"
"gateway"
"analytics"
Organizacja Co najmniej 1 środowisko Co najmniej jeden pod zawierający procesory wiadomości oraz użytkownik działający jako administrator organizacji brak
Środowisko Co najmniej 1 host wirtualny Co najmniej jeden procesor wiadomości w podzie powiązanym z organizacją nadrzędną brak
Host wirtualny Co najmniej 1 alias hosta brak

Informacje o planetach

Planeta reprezentuje całe środowisko sprzętowe i oprogramowania Edge i może zawierać co najmniej jednego regionu. W Edge planeta stanowi logiczną grupę regionów. bezpośrednio utworzyć lub skonfigurować planetę podczas instalowania Edge.

Informacje o regionach

Region to grupa co najmniej 1 poda. Domyślnie po zainstalowaniu przeglądarki Edge instalator tworzy pojedynczy region o nazwie „dc-1” zawierającej 3 pody, jak pokazano w tabeli poniżej programy:

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

Poniższa grafika przedstawia domyślne regiony:

Ten obraz przedstawia system równoważenia obciążenia kierujący ruch do „bramy” pod. „Brama” grupa zawiera komponenty routera brzegowego i procesora wiadomości obsługujące żądania do interfejsu API. Chyba że: zdefiniujesz wiele centrów danych, nie musisz tworzyć dodatkowych regionów.

W przypadku bardziej złożonej instalacji możesz utworzyć 2 lub więcej regionów. Jeden powód, dla którego warto utworzyć w wielu regionach polega na zorganizowaniu komputerów pod względem geograficznym, co minimalizuje czas przesyłania danych w sieci. W W tym scenariuszu hostujesz punkty końcowe interfejsu API, aby znajdować się blisko użytkowników tych interfejsów API.

W Edge każdy region jest nazywany centrum danych. Centrum danych w Wschodnie Stany Zjednoczone mogą przetwarzać żądania napływające z Bostonu w stanie Massachusetts, natomiast centrum danych w Singapur obsługuje żądania pochodzące z urządzeń i komputerów w Azji.

Na przykład ten obraz przedstawia 2 regiony odpowiadające 2 centmom danych:

Informacje o podach

Pod to grupa co najmniej 1 komponentu Edge i magazynów danych Cassandra. Brzeg Komponenty mogą być zainstalowane w tym samym węźle, ale częściej są one instalowane 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 tymi komponentami Edge i magazynami danych Cassandra z każdym podem:

Blok reklamowy Komponenty Edge

Bazy danych Cassandra
„brama” Router, procesor wiadomości Cache-datastore
magazyn danych licznika
dc-datastore 		keyvaluemap-datastore
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
„analityka” Postgres analytics-datastore reportcrud-datastore

Komponenty Edge i magazyny danych Cassandra w „bramie” pody są wymagane dla interfejsu API o przetwarzaniu danych. Te komponenty i magazyny danych muszą być aktywne, aby przetwarzać żądania do interfejsu API. komponentów i magazynów danych w „centralnej” i „analityka” pody nie są wymagane do przetwarzania interfejsów API, ale wzbogaciliśmy ją o dodatkowe funkcje.

Poniższa ilustracja przedstawia komponenty każdego bloku reklamowego:

Do trzech utworzonych przez wartość domyślną. Możesz też dodać do istniejącego poda dodatkowe komponenty Edge. Przykład: do „bramy” możesz dodać kolejne routery i procesory wiadomości. zwiększono liczbę podów do obsługi ruchu.

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

Możesz użyć poniższego wywołania interfejsu API, aby wyświetlić szczegóły rejestracji serwera na końcu dla każdego poda. Jest 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, i podName to jeden z tych:

  • gateway
  • central
  • analytics

Na przykład w atrybucie „brama” grupa:

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 podaje typ komponentu. Zwróć uwagę, że znajduje się w niej model Cassandra. magazynów danych zarejestrowanych w podzie. Węzły Cassandra są instalowane w „bramie” pod, Ty zobaczysz magazyny danych Cassandra zarejestrowane we wszystkich podach.

Informacje o organizacjach

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

W lokalnej instalacji Edge Private Cloud domyślnie nie ma żadnych organizacji. Podczas tworzenia organizacji musisz określić 2 rodzaje informacji:

  1. Użytkownik, który pełni funkcję administratora organizacji. Może on następnie dodać użytkowników w organizacji i ustawić rolę każdego z nich.
  2. „Brama” pod, który zawiera procesory wiadomości.

Organizacja może zawierać jedno lub więcej środowisk. Domyślna procedura instalacji Edge wyświetla monit o utworzenie 2 środowisk: „test” i „prod”. Możesz jednak utworzyć więcej w razie potrzeby, np. „testowanie”, „eksperymenty” itd.

Organizacja udostępnia zakres niektórych możliwości Apigee. Na przykład klucz-wartość mapy (KVM). dane są dostępne na poziomie organizacji, czyli ze wszystkich środowisk. Inne możliwości, takich jak buforowanie, są ograniczone do konkretnego środowiska. Dane analityczne Apigee są partycjonowane przez na połączenie organizacji i środowiska.

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

Informacje o środowiskach

Środowisko to kontekst wykonywania w czasie działania serwerów proxy interfejsów API w organizacji. Musisz wdrożyć w środowisku serwer proxy interfejsu API, aby można było uzyskać do niego dostęp. Możesz wdrożyć interfejs API, z jednym środowiskiem do kilku środowisk lub z wieloma środowiskami.

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

Podczas tworzenia środowiska należy je powiązać z co najmniej jednym procesorem wiadomości. Dostępne opcje to nazwane środowisko przetwarzania wiadomości, na których działają serwery proxy interfejsu API. Co środowisko może być powiązane z tymi samymi procesorami wiadomości lub z innymi.

Aby utworzyć środowisko, podaj 2 informacje:

  1. Organizacja zawierająca środowisko.
  2. Procesory wiadomości obsługujące żądania do serwera proxy interfejsu API kierowane do środowiska. Te komunikaty Procesory muszą znajdować się w podzie powiązanym z organizacją nadrzędną środowiska.
    Domyślnie, gdy tworzysz środowisko, Edge łączy wszystkie dostępne procesory wiadomości w „brama” pod ze środowiskiem. Możesz też określić podzbiór wartości z dostępnymi procesorami wiadomości, tak aby różne procesory wiadomości obsługiwały żądania wysyłane do w różnych środowiskach.

Procesor wiadomości może być powiązany z wieloma środowiskami. Na przykład urządzenie Edge Instalacja zawiera dwa procesory wiadomości: A i B. Następnie tworzysz 3 środowiska w Organization: "dev", "test" i "prod":

  • Dla „deweloperów” musisz powiązać procesor wiadomości A, ponieważ nie oczekujesz, generują duże natężenie ruchu.
  • Okno „test” musisz powiązać procesor wiadomości B, ponieważ nie oczekujesz, generują duże natężenie ruchu.
  • Środowisko produkcyjne musisz powiązać procesory komunikatów A i B w celu obsługi na poziomie produkcji.

Wszystkie procesory wiadomości przypisane do środowiska mogą być z tego samego poda lub pody obejmujących wiele regionów i centrów danych. Na przykład definiujesz środowisko „globalne” w Twojej organizacji, która obejmuje procesory wiadomości z 3 regionów: czyli 3 różne centra danych: USA, Japonia i Niemcy.

Wdrażanie serwera proxy interfejsu API w środowisku globalnym sprawia, że serwer proxy interfejsu API uruchamia się w wiadomości Procesory we wszystkich 3 centrach danych. Ruch API przychodzący do routera w dowolnym z tych będą kierowane wyłącznie do podmiotów przetwarzających wiadomości w danym centrum danych, ponieważ routery tylko bezpośredni ruch do procesorów wiadomości w tym samym podzie.

Informacje o hostach wirtualnych

Host wirtualny definiuje port w routerze brzegowym, na którym jest udostępniany serwer proxy interfejsu API. oraz adres URL, za pomocą którego aplikacje uzyskują dostęp do serwera proxy API. Każde środowisko musi zdefiniować z co najmniej jednym hostem wirtualnym.

Upewnij się, że numer portu określony przez hosta wirtualnego jest otwarty w węźle routera. Dostępne opcje dostęp do serwera proxy API, wysyłając żądanie na te adresy 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 jako (obsługuje 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 serwer proxy API.

Zwykle nie publikujesz interfejsów API klientom z adresem IP i numerem portu. Zamiast tego zdefiniuj 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 zgodnego z nazwą domeny DNS. wpisu. Według przykładu powyżej musisz określić alias hosta myAPI.myCo.com. Jeśli nie masz wpisu DNS, jako alias hosta ustaw adres IP routera i port hosta wirtualnego jako routerIP:port.

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

Tworzę pierwszą organizację, oraz host wirtualny

Po zakończeniu procesu instalacji Edge pierwszym działaniem jest zwykle utworzenie organizacji, środowiska i hosta wirtualnego za pomocą procesu rejestracji. proces tworzenia konta. Do wykonania wprowadzenie, uruchom następujące polecenie w węźle serwera zarządzania brzegiem:

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

Jako dane wejściowe tego polecenia przyjmuje się plik konfiguracyjny, który definiuje użytkownika, organizację, środowisko hosta wirtualnego.

Na przykład tworzysz:

  • wybranym przez Ciebie użytkownikiem pełniącym funkcję administratora organizacji.
  • Organizacja o nazwie example
  • Środowisko w organizacji o nazwie prod, które jest powiązane ze wszystkimi wiadomościami Procesory w „bramie” grupa
  • Host wirtualny w środowisku o nazwie default, który zezwala na dostęp HTTP na porcie 9001,
  • Alias hosta wirtualnego

Po uruchomieniu tego skryptu możesz uzyskać dostęp do interfejsów API, używając 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.