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

Edge for Private Cloud w wersji 4.17.09

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:

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:

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:

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:

• brama
• centralna
• Analytics

Na przykład w atrybucie „brama” grupa:

> 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. 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, przez serwer proxy do jednego lub wielu środowisk.

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:

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, (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 Zdefiniowano zasób {resource-name} podczas tworzenia serwera proxy interfejsu 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.

Aby dowiedzieć się więcej, zobacz Informacje o hostach wirtualnych (beta).

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 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://<router-ip>:9001/{proxy-base-path}/{resource-name}

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

Więcej informacji na ten temat znajdziesz w sekcji Rejestracja organizacji.