Wymagania dotyczące instalacji

Edge for Private Cloud w wersji 4.16.05

Wymagania sprzętowe

Aby uzyskać wysoką dostępność, musisz spełniać te minimalne wymagania sprzętowe w środowisku klasy produkcyjnej. W przypadku wszystkich scenariuszy instalacji opisanych w topologiach instalacji w tabelach poniżej znajdziesz minimalne wymagania sprzętowe dotyczące komponentów instalacji.

W tych tabelach wymagania dotyczące dysku twardego są uzupełniające wymagania dotyczące miejsca na dysku twardym wymaganej przez oraz system operacyjny. W zależności od aplikacji i ruchu w sieci instalacja może wymagają mniejszych lub większych zasobów niż wymienione poniżej.

Element instalacyjny

RAM

CPU

Minimalny rozmiar dysku twardego

Cassandra

16 GB

8-rdzeniowy

250 GB miejsca na dysku SSD lub szybkim dysku twardym obsługującym 2000 IOPS

Procesor/trafiker wiadomości na tym samym komputerze

8/16GB

4-rdzeniowy

100GB

Analytics – Postgres/Qpid na tym samym serwerze (niezalecane w środowisku produkcyjnym)

16GB*

8-rdzeniowy*

Sieciowa pamięć masowa od 500 GB do 1 TB*****, najlepiej z backendem SSD (obsługa 1000 GBP) IOPS lub więcej*.

Analytics – samodzielna wersja Postgres

16GB*

8-rdzeniowy*

od 500 GB do 1 TB** pamięci sieciowej***, najlepiej z backendem SSD, obsługujące 1000 IOPS lub więcej*.

Analytics – samodzielny Qpid

8 GB

4-rdzeniowy

30–50 GB pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HDD

W przypadku instalacji o wydajności przekraczającej 250 TPS zalecamy dysk twardy z lokalnym miejscem na dane obsługującym 1000 IOPS.

Inny (OpenLDAP, UI, serwer zarządzania)

4 GB

2-rdzeniowy

60 GB

† Dostosuj wymagania systemowe procesora wiadomości na podstawie przepustowości:

W przypadku systemu o dużej przepustowości zalecane są co najmniej 4 rdzenie i 8 rdzeni. Aby określić optymalny rozmiar dla swoich interfejsów API, możesz przeprowadzić testy wydajności.

*Dostosuj wymagania systemowe Postgres na podstawie przepustowości:

  • Mniej niż 250 TPS: 8 GB, 4-rdzeniowy system zarządzania pamięcią sieciową*** obsługa co najmniej 1000 IOPS
  • Powyżej 250 TPS: zarządzana pamięć sieciowa o pojemności 16 GB i 8 rdzeniach, obsługująca 1000 IOPS lub więcej
  • Ponad 1000 TPS: 16 GB, 8-rdzeniowy, zarządzana pamięć sieciowa*** obsługująca 2000 pikseli IOPS lub więcej
  • Więcej niż 2000 TPS: 32 GB, 16-rdzeniowy, zarządzana pamięć sieciowa*** z 2000 r. IOPS lub więcej
  • Powyżej 4000 TPS: zarządzana pamięć sieciowa o pojemności 64 GB i 32 rdzeniach*** obsługująca 4000 IOPS lub więcej

**Wartość dysku twardego Postgresa jest określana na podstawie domyślnych statystyk rejestrowanych przez Edge. Jeśli dodasz do danych analitycznych wartości niestandardowe, odpowiednio zwiększono. Aby oszacować wymaganą ilość miejsca na dane, użyj tej formuły:

(# bajtów/żądanie) * (żądania na sekundę) * (sekundy na godzinę) * (godziny szczytowego wykorzystania na dzień) * (dni w miesiącu) * (miesiące przechowywania danych) = potrzebne bajty miejsca na dane

Przykład:

(2 tys. bajtów danych analitycznych na żądanie) * 100 żądań/s * 3600 s/h * 18 godzin (szczyt) wykorzystanie dziennie * 30 dni/miesiąc * 3 miesiące przechowywania = 1 194 393 600 000 bajtów lub 1194,4 GB.

*** W przypadku bazy danych Postgresql zalecamy użycie usługi Network Storage, ponieważ:

  • Zapewnia możliwość dynamicznego skalowania rozmiaru pamięci masowej, jeśli i kiedy
  • W większości współczesnych IOPS sieci można dostosowywać na bieżąco środowisko/pamięć masowa/podsystemy sieci.
  • W ramach tworzenia i przywracania kopii zapasowych można włączyć zrzuty poziomu miejsca na dane i rozwiązania.

Poniżej znajdziesz też wymagania sprzętowe, jeśli chcesz zainstalować usługi zarabiania:

Komponent z zarabianiem

RAM

CPU

Dysk twardy

Serwer zarządzania (z usługami do zarabiania)

8 GB

4-rdzeniowy

60GB

Analytics – Postgres/Qpid na tym samym serwerze

16 GB

8-rdzeniowy

500 GB–1 TB pamięci sieciowej, najlepiej z backendem SSD, obsługującą 1000 IOPS lub wyżej lub użyj reguły z tabeli powyżej.

Analytics – samodzielna usługa Postgres

16 GB

8-rdzeniowy

500 GB–1 TB pamięci sieciowej, najlepiej z backendem SSD, obsługującą 1000 IOPS lub wyżej lub użyj reguły z tabeli powyżej.

Analytics – samodzielny Qpid

8 GB

4-rdzeniowy

40GB

Poniżej znajdziesz wymagania sprzętowe, jeśli chcesz zainstalować BaaS API:

Komponent BaaS API

RAM

CPU

Dysk twardy

ElasticSearch*

8 GB

4-rdzeniowy

60–80 GB

Stos BaaS API *

8 GB

4-rdzeniowy

60–80 GB

Portal API BaaS

1 GB

2-rdzeniowy

20GB

Cassandra (opcjonalnie – zwykle używasz tego samego klastra Cassandra na potrzeby obu serwerów Edge i usługi BaaS API).

16 GB

8-rdzeniowy

250 GB miejsca na dysku SSD lub szybkim dysku twardym obsługującym 2000 IOPS

* Możesz zainstalować ElasticSearch i usługę BaaS API na tym samym węźle. W takim przypadku skonfiguruj ElasticSearch tak, aby używał 4 GB pamięci (domyślnie). Jeśli ElasticSearch jest zainstalowany na własnego węzła, a następnie skonfigurować korzystanie z 6 GB pamięci.

Uwaga:

  • Jeśli główny system plików nie jest wystarczająco duży na instalację, zalecamy umieszczenie danych na większym dysku.
  • Jeśli na maszynie zainstalowano starszą wersję Apigee Edge dla Private Cloud, sprawdź, usuń folder /tmp/java przed nową instalacją.
  • Cały systemowy folder tymczasowy /tmp wymaga uprawnień do wykonywania, aby uruchomić Cassandra.
  • Jeśli użytkownik „apigee” został utworzony przed instalacją, upewnij się, że Plik „/home/apigee” istnieje jako katalog główny i należy do „apigee:apigee”.

System operacyjny i inne firmy wymagania oprogramowania

Te instrukcje instalacji i dołączone pliki instalacyjne zostały przetestowane w systemach operacyjnych i oprogramowaniu innych firm wymienionych tutaj: https://apigee.com/docs/api-services/reference/supported-software.

Tworzę użytkownika Apigee

Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi brzegowe pliki są własnością „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge działają jako „apigee” użytkownika. w razie potrzeby możesz uruchomić te komponenty jako inny użytkownik. Patrz sekcja „Wiązanie routera” do chronionego portu” w artykule Instalowanie komponentów Edge na węzłów.

Katalog instalacji

Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee. Nie możesz tego zmienić lokalizację katalogu.

W instrukcjach w tym przewodniku katalog instalacji jest podany jako /<inst_root>/apigee, gdzie /<inst_root>/apigee domyślnie jest ustawiony na /<inst_root>/apigee.

Java

Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja Java1.8. Obsługiwane pakiety JDK są wymienione tutaj:

https://apigee.com/docs/api-services/reference/supported-software

Upewnij się, że zmienna JAVA_HOME wskazuje na katalog główny JDK dla użytkownika przeprowadzającego instalację.

Ustawienie sieci

Zalecamy sprawdzenie ustawień sieci przed instalacją. Instalator wymaga, aby wszystkie maszyny mają stałe adresy IP. Za pomocą tych poleceń możesz sprawdzić poprawność ustawienie:

  • hostname zwraca nazwę, maszyny
  • hostname -i zwraca adres IP nazwy hosta, do której można się odwoływać z innych maszyn.

W zależności od typu i wersji systemu operacyjnego może być konieczna edycja plików /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta nie jest być ustawione prawidłowo. Więcej informacji znajdziesz w dokumentacji używanego systemu operacyjnego.

Cassandra

Wszystkie węzły Cassandra muszą być połączone z pierścieniem.

Cassandra automatycznie dostosowuje rozmiar sterty Javy na podstawie dostępnej pamięci. Aby zobaczyć więcej, Więcej informacji: Dostrajanie Javy . W przypadku spadku wydajności lub dużego zużycia pamięci.

Po zainstalowaniu Edge for Private Cloud możesz sprawdzić, czy skonfigurowano Cassandra poprawnie, sprawdzając plik /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml . Sprawdź na przykład, czy skrypt instalacji Edge for Private Cloud ustawił właściwości:

  • cluster_name
  • initial_token
  • partycjoner
  • nasiona
  • listen_address
  • rpc_address
  • snicz

Ostrzeżenie: nie edytuj tego pliku.

Baza danych PostgreSQL

Po zainstalowaniu Edge możesz dostosować poniższe ustawienia bazy danych PostgreSQL na podstawie ilość pamięci RAM dostępnej w systemie:

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

Aby ustawić te wartości:

  1. Edytuj plik postgresql.properties:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    Jeśli plik nie istnieje, utwórz go.
  2. Ustaw wymienione powyżej właściwości.
  3. Zapisz zmiany.
  4. Uruchom ponownie bazę danych PostgreSQL:
    &gt; /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql Uruchom ponownie

jsvc

„jsvc” jest wymaganym wstępem do korzystania z interfejsu API BaaS. Podczas instalacji instalowana jest wersja 1.0.15-dev z baaS API.

Usługi bezpieczeństwa sieci (NSS)

Usługi zabezpieczeń sieci (NSS) to zestaw bibliotek, które ułatwiają tworzenie aplikacji klienckich i serwerowych z zabezpieczeniami. Musisz się upewnić, że zainstalowano NSS. wersji 3.19 lub nowszej.

Aby sprawdzić bieżącą wersję:

> yum info nss

Aby zaktualizować NSS:

> yum update nss

Więcej informacji znajdziesz w tym artykule firmy RedHat.

AWS AMI,

Jeśli instalujesz Edge w obrazie AWS Amazon Machine Image (AMI) dla systemu Red Hat Enterprise Linux 7.x, musisz najpierw uruchomić to polecenie:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Narzędzia

Instalator używa w wersji standardowej narzędzi systemu UNIX (zgodnie z danymi EL5 lub EL5). EL6.

awk

dirname

ls

obr./min

rozpakować

nazwa_podstawowa

echo

perl

rpm2cpio

useradd

Bash

expr

pgrep (z procps)

sed

wc

bc

grep

ps

tar

mniam

curl

nazwa hosta

pwd

tr

chkconfig

data

id

python

Uname

sudo

Uwaga:

  • Plik wykonywalny narzędzia „useradd” znajduje się w katalogu /usr/sbin, a plik chkconfig w katalogu /sbin.
  • Za pomocą sudo możesz uzyskać dostęp do środowiska rozmówcy, na przykład zwykle nazywa się „sudo <command>” lub “sudo PATH=$PATH:/usr/sbin:/sbin <command>”.
  • Sprawdź, czy przed zainstalowaniem dodatku Service Pack (poprawka) masz zainstalowane narzędzie „poprawka” instalacji.

ntpdate – zalecamy synchronizację czasu serwerów. Jeśli nie skonfigurowano jeszcze, ale narzędzie „ntpdate” może służyć do tego celu, który sprawdza, czy serwery są synchronizowane czasowo. Możesz użyć polecenia „yum install ntp”, aby zainstalować za media. Jest to szczególnie przydatne w przypadku replikacji konfiguracji OpenLDAP. Pamiętaj, że konfigurujesz serwer strefa czasowa UTC.

openldap 2.4 – instalacja lokalna wymaga OpenLDAP 2.4. Jeśli Twój serwer ma połączenie z internetem, a następnie skrypt instalacji Edge pobierze i zainstaluje. OpenLDAP. Jeśli serwer nie ma połączenia z internetem, upewnij się, że OpenLDAP jest już zainstalowany. W RHEL/CentOS można yum install openldap-clients openldap-servers&quot; aby zainstalować OpenLDAP.

W przypadku instalacji z 13 hostami i instalacji z 12 hostami z 2 centrami danych wymagana jest replikacja OpenLDAP, ponieważ istnieje wiele węzłów hostujących OpenLDAP.

Zapory sieciowe i hosty wirtualne

Termin „wirtualny” jest często przeciążony w sektorze IT, dlatego Apigee Edge na potrzeby wdrożenia w chmurze prywatnej i hostów wirtualnych. Aby doprecyzować, terminu „wirtualny”:

  • Maszyny wirtualne: nie jest wymagane, ale niektóre wdrożenia korzystają z technologii maszyn wirtualnych aby utworzyć izolowane serwery dla komponentów Apigee. Hosty maszyn wirtualnych, podobnie jak hostów fizycznych, mogą mieć interfejsy sieciowe i zapory sieciowe. Te instrukcje instalacji nie dotyczą konkretnie Instalacje maszyn wirtualnych.
  • Hosty wirtualne: internetowe punkty końcowe podobne do hosta wirtualnego Apache.

Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się one od siebie aliasem hosta lub portem interfejsu).

Na przykład pojedynczy serwer fizyczny „A” może mieć 2 maszyny wirtualne. o nazwach „VM1” i „VM2”. Załóżmy, że maszyna wirtualna maszyna wirtualna udostępnia wirtualną sieć Ethernet o nazwie eth0 wewnątrz maszyny wirtualnej i przypisanym przez wirtualizację adres IP 111.111.111.111 maszyny lub serwer DHCP sieci; Zakładam, że VM2 udostępnia też interfejs wirtualnej sieci Ethernet zostanie mu przypisany adres IP 111.111.111.222.

W każdej z 2 maszyn wirtualnych może działać router Apigee. Routery ujawniają hosta wirtualnego punktów końcowych jak w tym hipotetycznym przykładzie:

Router Apigee w VM1 udostępnia 3 hosty wirtualnych na interfejsie eth0 (który ma konkretny adres IP): api.mycompany.com:80, api.mycompany.com:443test.mycompany.com:80.

Router w maszynie wirtualnej 2 udostępnia adres api.mojafirma.com:80 (ta sama nazwa i port co w maszynie wirtualnej 1).

System operacyjny fizycznego hosta może mieć zaporę sieciową. W takim przypadku musi ona przepuszczać ruch TCP do portów udostępnionych na interfejsach wirtualnych (111.111.111.111:{80, 443} i 111.111.111.222:80). Dodatkowo każda maszyna wirtualna może mieć własną zaporę sieciową na interfejsie eth0, która również musi zezwalać na ruch na portach 80 i 443.

Ścieżka bazowa to trzeci komponent zaangażowany w kierowanie wywołań interfejsu API do różnych serwerów proxy interfejsu API wdrożone przez użytkownika. Pakiety zastępcze interfejsu API mogą korzystać z tego samego punktu końcowego, jeśli mają różne ścieżki podstawowe. Na przykład jedną ścieżkę bazową można zdefiniować jako http://api.mycompany.com:80/ zdefiniowaną jako http://api.mycompany.com:80/salesdemo.

W tym przypadku potrzebny jest system równoważenia obciążenia lub dyrektor ruchu, który dzieli ruch http://api.mycompany.com:80/ między 2 adresami IP (111.111.111.111 w maszynie wirtualnej 1 i 111.111.111.222 w maszynie wirtualnej 2). Ta funkcja jest specyficzna dla Twojej instalacji i jest konfigurowana przez lokalną grupę sieci.

Ścieżka bazowa jest ustawiana podczas wdrażania interfejsu API. Korzystając z powyższego przykładu, możesz wdrożyć 2 interfejsy API: mojafirma i firma testowa dla organizacji mycompany-org host z aliasem hosta api.mycompany.com i portem ustawionym na 80 Jeśli nie zadeklarujesz basepath we wdrożeniu, router nie wie, który interfejs API ma wysyłać żądania przychodzące; do.

Jeśli jednak wdrożysz interfejs API testmycompany z podstawowym adresem URL /salesdemo, użytkownicy mają dostęp ten interfejs API za pomocą strony http://api.mycompany.com:80/salesdemo. Jeśli wdrożesz interfejs API mycompany z adresem URL podstawowym /, użytkownicy będą uzyskiwać dostęp do interfejsu API za pomocą adresu URL http://api.mycompany.com:80/.

Wymagania dotyczące portu brzegowego

Konieczność zarządzania zaporą sieciową wykracza poza tylko hosty wirtualne. zarówno maszyna wirtualna, jak i host fizyczny zapory sieciowe muszą zezwalać na ruch przez porty wymagane przez komponenty do komunikacji z danym inne.

Poniższa ilustracja przedstawia wymagania dotyczące portów w każdym komponencie Edge:

Uwagi do tego diagramu:

  • *Port 8082 w procesorze wiadomości musi być otwarty dla routera tylko wtedy, gdy skonfigurować TLS/SSL między routerem a procesorem wiadomości. Jeśli nie skonfigurujesz TLS/SSL pomiędzy Routerem a Przetwarzaczem wiadomości, w konfiguracji domyślnej port 8082 musi być nadal otwarty na Przetwarzaczu wiadomości, aby można było zarządzać tym komponentem, ale Router nie wymaga dostępu do tego portu.
  • porty z przedrostkiem „M”. to porty używane do zarządzania komponentem i muszą być otwarte na do dostępu dla serwera zarządzania.
  • Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, Procesor komunikatów, UI, Postgres i Qpid.
  • Procesor wiadomości musi otworzyć port 4528 jako port zarządzania. Jeśli masz kilka podmiotów przetwarzających wiadomości, wszystkie muszą mieć możliwość kontaktowania się ze sobą przez port 4528 (co jest wskazywane przez strzałka pętli na schemacie powyżej dla portu 4528 procesora wiadomości). Jeśli masz kilka Centra danych, port musi być dostępny dla wszystkich procesorów wiadomości we wszystkich centrach danych.
  • Chociaż nie jest to wymagane, możesz otworzyć port 4527 w routerze, aby uzyskać dostęp do dowolnej wiadomości Procesor. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawić się komunikaty o błędach.
  • Router musi otworzyć jako port zarządzania port 4527. Jeśli masz kilka routerów, muszą mieć możliwość dostępu do siebie przez port 4527 (co wskazuje strzałka pętli na powyższego schematu dla portu 4527 routera).
  • Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsów API, aby obsługiwać klikając przycisk Wyślij w narzędziu do śledzenia.
  • Serwer zarządzający wymaga dostępu do portu JMX na węzłach Cassandra.
  • Dostęp do portów JMX można skonfigurować tak, aby wymagał podania nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule Jak korzystać z funkcji monitorowania.
  • Opcjonalnie możesz skonfigurować dostęp TLS/SSL dla określonych połączeń, które mogą używać przez różne porty. Zobacz TLS/SSL: i innych.
  • Jeśli konfigurujesz 2 węzły Postgres do użycia replikacji w trybie gotowości mastera, musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH. Możesz opcjonalnie otworzyć porty w poszczególnych węzłach, aby zezwolić na dostępu przez SSH.
  • Możesz skonfigurować serwer zarządzania i interfejs użytkownika brzegowego do wysyłania e-maili przy użyciu zewnętrznego serwera SMTP serwera. Jeśli tak, upewnij się, że serwer zarządzania i interfejs użytkownika mają dostęp do niezbędnych na serwerze SMTP. W przypadku serwera SMTP bez szyfrowania TLS numer portu to zwykle 25. Z włączonym protokołem TLS SMTP, często jest to kod 465, ale skontaktuj się z dostawcą SMTP.

Tabela poniżej pokazuje, które porty muszą być otwarte w zaporach sieciowych przez komponent Edge:

Składnik

Port

Opis

Standardowe porty HTTP

80 443

HTTP oraz wszystkie porty używane dla hostów wirtualnych

Serwer zarządzania

8080

Port do wywołań interfejsu API do zarządzania Edge. Te komponenty wymagają dostępu do portu 8080 serwer zarządzania: router, procesor wiadomości, interfejs użytkownika, Postgres i Qpid.

1099

Port JMX

4526

Do rozproszonej pamięci podręcznej i wywołań zarządzania

Interfejs zarządzania

9000

Port umożliwiający dostęp przeglądarki do interfejsu zarządzania

Procesor wiadomości

8998

Port procesora wiadomości na potrzeby komunikacji z routera

8082

Domyślny port zarządzania dla procesora wiadomości i musi być otwarty w komponencie dla dostęp przez serwer zarządzania.

Jeśli skonfigurujesz protokół TLS/SSL między routerem a procesorem wiadomości, będzie używany przez router do przeprowadzania kontroli stanu w procesorze wiadomości.

1101

Port JMX

4528

Do rozproszonej pamięci podręcznej i wywołań zarządzania między procesorami wiadomości oraz dla komunikacja z routera

Router

8081

Domyślny port zarządzania dla routera musi być otwarty w komponencie, aby umożliwić dostęp serwerowi zarządzania.

4527

Do wywołań zarządzania i rozproszonej pamięci podręcznej

15999

Port kontroli stanu. System równoważenia obciążenia używa tego portu do sprawdzania, czy router jest dostępny.

Aby uzyskać stan routera, system równoważenia obciążenia wysyła żądanie do portu 15999 Router:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

Jeśli router jest osiągalny, żądanie zwraca kod HTTP 200.

ZooKeeper

2181

są używane przez inne komponenty, takie jak serwer zarządzania, router czy procesor wiadomości. włączono

2888, 3888

Używany wewnętrznie przez ZooKeeper do gromady ZooKeeper (znanej jako zestaw ZooKeeper) komunikacja

Cassandra

7000, 9042, 9160

Porty Apache Cassandra służące do komunikacji między węzłami Cassandra i do dostępu z innymi komponentami Edge.

7199

Port JMX. Musi być dostępny dla serwera zarządzania.

Qpid

5672

Służy do komunikacji między routerem i procesorem wiadomości z serwerem Qpid

8083

Domyślny port zarządzania na serwerze Qpid musi być otwarty w komponencie, aby umożliwić dostęp serwerowi zarządzania.

1102

Port JMX

4529

Do wywołań zarządzania i rozproszonej pamięci podręcznej

Postgres

5432

Służy do komunikacji między serwerem Qpid/serwerem zarządzania a Postgres

8084

Domyślny port zarządzania na serwerze Postgres musi być otwarty w komponencie, aby umożliwić dostęp serwerowi zarządzania.

1103

Port JMX

4530

Do rozproszonej pamięci podręcznej i wywołań zarządzania

22

W przypadku konfigurowania 2 węzłów Postgres pod kątem użycia replikacji w trybie gotowości mastera musisz otworzyć przez port 22 w każdym węźle, aby umożliwić dostęp przez SSH.

LDAP

10389

OpenLDAP

SmartDocs

59002

Port na routerze brzegowym, do którego wysyłane są żądania stron SmartDocuments.

Uwaga: na potrzeby testowania może być konieczne otwarcie portów w zaporach sieciowych. Dla: na przykład 59001 itd.

Następna tabela zawiera te same porty, wymienione numerycznie, ze źródłem i miejscem docelowym. komponenty:

Numer portu

Cel

Komponent źródła

Komponent miejsca docelowego

<numer portu hosta wirtualnego>

HTTP i wszystkie inne porty używane do obsługi ruchu wywołanego interfejsem API hosta wirtualnego. Porty 80 i 443 są najczęściej używane. Router wiadomości może kończyć połączenia TLS/SSL.

Zewnętrzny klient (lub system równoważenia obciążenia)

Detektor w routerze wiadomości

1099–1103

Zarządzanie JMX

Klient JMX

Serwer zarządzania (1099)

Message Processor (1101)

Serwer Qpid (1102)

Serwer Postgres (1103)

2181

Komunikacja z klientem Zookeeper

Serwer zarządzania

Router

procesor komunikatów

Serwer Qpid

Serwer Postgres

Miłośnik zoo

2888 i 3888

Zarządzanie międzywęzłami w zookeeper

Miłośnik zoo

Miłośnik zoo

4526–4530

Porty zarządzania RPC używane do rozproszonej pamięci podręcznej i wywołań z serwerów zarządzania do innych komponentów

Serwer zarządzania

Serwer zarządzania (4526)

Router (4527)

Procesor komunikatów (4528)

Serwer Qpid (4529)

Serwer Postgres (4530)

4528

Do wywołań rozproszonej pamięci podręcznej między procesorami wiadomości oraz na potrzeby komunikacji z routera

Router

procesor komunikatów

procesor komunikatów

5432

Klient Postgres

Qpid Server

Postgres

5672,

Służy do wysyłania statystyk z routera i procesora wiadomości do Qpid

Router

procesor komunikatów

Serwer Qpid

7000

Komunikacja między węzłami Cassandra

Cassandra

Inny węzeł Cassandra

7199

Zarządzanie JMX. Musi być otwarty dla dostępu do węzła Cassandra przez zarządzanie Serwer

Klient JMX

Cassandra

8080,

Port interfejsu API zarządzania

Klienty interfejsu API zarządzania

Serwer zarządzania

8081–8084

Porty interfejsu API komponentów używane do wysyłania żądań do interfejsu API bezpośrednio do poszczególnych komponentów. Każdy komponent otwiera inny port. Dokładny użyty port zależy od konfiguracji ale musi być otwarty w komponencie, aby serwer zarządzania miał dostęp

Klienty interfejsu API zarządzania

Router (8081)

Procesor komunikatów (8082)

Serwer Qpid (8083)

Serwer Postgres (8084)

8998

Komunikacja między routerem procesora wiadomości

Router

procesor komunikatów

9000

Domyślny port interfejsu zarządzania Edge

Przeglądarka

Serwer interfejsu użytkownika zarządzania

9042,

Transport natywny CQL

Router

procesor komunikatów

Serwer zarządzania

Cassandra

9160

klient korzystający z używanych usług Cassandra

Router

procesor komunikatów

Serwer zarządzania

Cassandra

10389

Port LDAP

Serwer zarządzania

OpenLDAP

15999 Port kontroli stanu. System równoważenia obciążenia używa tego portu do określenia, czy router i dostępności informacji. System równoważenia obciążenia Router

59002

Port routera, na który są wysyłane żądania strony dotyczące SmartDocuments

SmartDocs

Router

Procesor wiadomości pozostawia otwartą dedykowaną pulę połączeń dla Cassandra, która została skonfigurowana aby nigdy nie wygasły. Gdy zapora sieciowa znajduje się między procesorem wiadomości a serwerem Cassandra, zapora sieciowa może przekroczyć limit czasu połączenia. Przetwarzanie wiadomości nie jest jednak przeznaczone odzyskać połączenia z Cassandra.

Aby zapobiec tej sytuacji, Apigee zaleca serwer Cassandra, procesor wiadomości routery są w tej samej podsieci, więc zapora sieciowa nie bierze udziału we wdrażaniu tych

Jeśli zapora sieciowa znajduje się między routerem a procesorami wiadomości i ma ustawiony limit czasu bezczynności serwera tcp, nasze zalecenia to:

  1. W ustawieniach sysctl w systemie Linux ustaw net.ipv4.tcp_keepalive_time = 1800, gdzie 1800 powinno być mniejsze niż czas oczekiwania TCP zapory sieciowej w trybie bezczynności. To ustawienie powinno utrzymywać połączenie w stanie ustanowienia, dzięki czemu zapora sieciowa nie odłącza połączenia.
  2. We wszystkich procesorach wiadomości edytuj plik /&lt;inst_root&gt;/apigee/customer/application/message-processor.properties aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. Uruchom ponownie procesor wiadomości:
    &gt; /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. We wszystkich routerach edytuj /&lt;inst_root&gt;/apigee/customer/application/router.properties aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.
    conf_system_cassandra.maxconnecttimeinmillis=-1
  5. Uruchom ponownie router:
    &gt; /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

Jeśli zainstalujesz konfigurację z 12 hostami w klastrze z 2 centrami danych, upewnij się, że węzły w tych 2 centrach danych mogą się komunikować przez porty wymienione poniżej:

Wymagania dotyczące portów BaaS interfejsu API

Jeśli zdecydujesz się zainstalować BaaS API, dodaj komponenty BaaS API Stack i BaaS API Portal. Te komponenty korzystają z portów pokazanych na ilustracji poniżej:

Uwagi do tego diagramu:

  • Węzły Cassandra mogą być przeznaczone do BaaS API lub udostępnione urządzeniu Edge.
  • Instalacja produkcyjna interfejsu API BaaS korzysta z systemu równoważenia obciążenia między węzłem portalu BaaS API i węzłów stosu BaaS API. Podczas konfigurowania portalu i wykonywania wywołań interfejsu BaaS API podaj adres IP lub nazwę DNS systemu równoważenia obciążenia, a nie węzłów stosu.
  • Musisz skonfigurować wszystkie węzły Baas Stack, aby wysyłały e-maile przez zewnętrzny serwer SMTP. Dla: SMTP bez szyfrowania TLS, numer portu to zwykle 25. W przypadku SMTP z włączonym protokołem TLS często jest to 465, ale sprawdź u dostawcy SMTP.

Tabela poniżej przedstawia domyślne porty, które muszą być otwarte w zaporach sieciowych według komponentu:

Komponent

Port

Opis

Portal API BaaS

9000

Portowanie interfejsu API BaaS

Stos BaaS API

8080

Port, w którym są odbierane żądania API

ElasticSearch

9200–9400

Do komunikacji ze stosem BaaS API i między ElasticSearch nodes

Licencjonowanie

Każda instalacja Edge wymaga unikalnego pliku licencji uzyskanego z Apigee. Ty musisz podać ścieżkę do pliku licencji podczas instalowania serwera zarządzania, na przykład /tmp/license.txt.

Instalator skopiuje plik licencji do pliku /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

Jeśli plik licencji jest prawidłowy, serwer zarządzania sprawdza datę ważności i dozwoloną wiadomość Liczba procesorów (MP). Jeśli któreś z ustawień licencji wygaśnie, dzienniki znajdziesz w ta lokalizacja: /&lt;inst_root&gt;/apigee/var/log/edge-management-server/logs. W takim przypadku możesz skontaktować się z zespołem pomocy Apigee w sprawie szczegóły migracji.