Edge for Private Cloud wer. 4.17.09
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" |
|
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 geograficznie „zbliżone” do konsumentów tych interfejsów.
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 |
keyvaluemap-datastore |
"central" |
Serwer zarządzania, Zookeeper, LDAP, UI, Qpid |
application-datastore
apimodel-datastore
magazyn danych kontroli
auth-datastore
|
identityzone-datastore
edgenotification-datastore
serwer-zarządzania
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:
- brama
- centralne
- 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:
- 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.
- 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:
- Organizacja zawierająca środowisko.
- 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.
- Podczas tworzenia serwera proxy interfejsu API definiuje się wartości {proxy-base-path} i {resource-name}.
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 jako <routerIP>:port.
Więcej informacji znajdziesz w artykule Informacje o hostach wirtualnych (beta).
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 „gateway” (brama).
- 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://<router-ip>: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 o włączaniu organizacji.