Edge dla chmury prywatnej w wersji 4.18.05
Konieczność zarządzania zaporą sieciową wykracza poza same hosty wirtualne. Zapory sieciowe maszyn wirtualnych i hostów fizycznych muszą zezwalać na ruch na portach wymaganych do komunikacji między komponentami.
Schematy portów
Poniższe obrazy przedstawiają wymagania dotyczące portów w przypadku konfiguracji z jednym centrum danych i z wieloma centrami danych:
Pojedyncze centrum danych
Poniższy obraz przedstawia wymagania dotyczące portów dla każdego komponentu Edge w konfiguracji z jednym centrum danych:

Uwagi do tego diagramu:
- Porty z prefiksem „M” są używane do zarządzania komponentem i muszą być otwarte na komponencie, aby serwer zarządzania miał do nich dostęp.
- Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API, aby obsługiwać przycisk Wyślij w narzędziu do śledzenia.
- Dostęp do portów JMX można skonfigurować tak, aby wymagał nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule Jak monitorować.
- Możesz opcjonalnie skonfigurować dostęp TLS/SSL dla niektórych połączeń, które mogą używać różnych portów. Więcej informacji znajdziesz w sekcji TLS/SSL.
- Możesz skonfigurować serwer zarządzania i interfejs Edge, aby wysyłać e-maile przez zewnętrzny serwer SMTP. Jeśli to zrobisz, musisz upewnić się, że serwer zarządzania i interfejs użytkownika mają dostęp do niezbędnego portu na serwerze SMTP (niewidoczny). W przypadku SMTP bez TLS numer portu to zwykle 25. W przypadku protokołu SMTP z obsługą TLS jest to często 465, ale sprawdź to u dostawcy SMTP.
Wiele centrów danych
Jeśli instalujesz konfigurację klastra z 12 węzłami i 2 centrami danych, upewnij się, że węzły w obu centrach danych mogą komunikować się przez porty wymienione poniżej:

Uwaga:
- Wszystkie serwery zarządzania muszą mieć dostęp do wszystkich węzłów Cassandra we wszystkich innych centrach danych.
- Wszystkie procesory komunikatów we wszystkich centrach danych muszą mieć dostęp do siebie nawzajem przez port 4528.
- Serwer zarządzania musi mieć dostęp do wszystkich procesorów komunikatów przez port 8082.
- Wszystkie serwery zarządzania i wszystkie węzły Qpid muszą mieć dostęp do Postgres we wszystkich innych centrach danych.
- Ze względów bezpieczeństwa między centrami danych nie powinny być otwarte żadne inne porty oprócz tych wymienionych powyżej i wymaganych przez Twoją sieć.
Szczegóły przeniesienia
W tabeli poniżej znajdziesz porty, które należy otworzyć w zaporach sieciowych, według komponentu Edge:
| Komponent | Port | Opis |
|---|---|---|
| Standardowe porty HTTP | 80, 443 | HTTP i inne porty używane przez hosty wirtualne |
| Cassandra | 7000, 9042, 9160 | Porty Apache Cassandra do komunikacji między węzłami Cassandra i dostępu przez inne komponenty Edge. |
| 7199 | Port JMX. Musi być otwarty dla dostępu przez serwer zarządzania. | |
| LDAP | 10389 | OpenLDAP |
| Serwer zarządzania | 1099 | Port JMX |
| 4526 | Port dla rozproszonej pamięci podręcznej i wywołań zarządzania. Ten port można skonfigurować. | |
| 8080 | Port do wywołań interfejsu API zarządzania Edge. Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor komunikatów, interfejs użytkownika, Postgres i Qpid. | |
| Interfejs zarządzania | 9000 | Port dostępu przeglądarki do interfejsu zarządzania |
| procesor komunikatów | 1101 | Port JMX |
| 4528 | Do wywołań rozproszonej pamięci podręcznej i zarządzania między procesorami komunikatów oraz do komunikacji z routera i serwera zarządzania.
Procesor komunikatów musi otworzyć port 4528 jako port zarządzania. Jeśli masz wiele procesorów komunikatów, wszystkie muszą mieć dostęp do siebie nawzajem przez port 4528 (wskazuje to strzałka pętli na powyższym diagramie dla portu 4528 procesora komunikatów). Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich procesorów komunikatów we wszystkich centrach danych. |
|
| 8082 |
Domyślny port zarządzania procesora komunikatów, który musi być otwarty w komponencie, aby serwer zarządzania miał do niego dostęp. Jeśli skonfigurujesz TLS/SSL między routerem a procesorem komunikatów, router będzie używać tego portu do sprawdzania stanu procesora komunikatów. Port 8082 procesora komunikatów musi być otwarty tylko na potrzeby dostępu routera, gdy konfigurujesz TLS/SSL między routerem a procesorem komunikatów. Jeśli nie skonfigurujesz TLS/SSL między routerem a procesorem komunikatów, domyślna konfiguracja (port 8082) musi być nadal otwarta na procesorze komunikatów, aby można było zarządzać komponentem, ale router nie wymaga do niego dostępu. |
|
| 8443 | Gdy protokół TLS jest włączony między routerem a procesorem komunikatów, musisz otworzyć port 8443 na procesorze komunikatów, aby router mógł uzyskać do niego dostęp. | |
| 8998 | Port procesora komunikatów do komunikacji z routerem | |
| Postgres | 22 | Jeśli konfigurujesz 2 węzły Postgres do używania replikacji master-standby, musisz otworzyć port 22 na każdym węźle, aby umożliwić dostęp SSH. |
| 1103 | Port JMX | |
| 4530 | Do wywołań rozproszonej pamięci podręcznej i zarządzania | |
| 5432 | Używany do komunikacji między Qpid/serwerem zarządzania a Postgres | |
| 8084 | Domyślny port zarządzania na serwerze Postgres, który musi być otwarty na komponencie, aby serwer zarządzający miał do niego dostęp. | |
| Qpid | 1102 | Port JMX |
| 4529 | Do wywołań rozproszonej pamięci podręcznej i zarządzania | |
| 5672 |
|
|
| 8083 | Domyślny port zarządzania na serwerze Qpid, który musi być otwarty na komponencie, aby serwer zarządzania miał do niego dostęp. | |
| Router | 4527 | Do wywołań rozproszonej pamięci podręcznej i zarządzania.
Router musi otworzyć port 4527 jako port zarządzania. Jeśli masz kilka routerów, wszystkie muszą mieć dostęp do siebie nawzajem przez port 4527 (wskazany przez strzałkę pętli na powyższym diagramie dla portu 4527 na routerze). Nie jest to wymagane, ale możesz otworzyć port 4527 na routerze, aby umożliwić dostęp dowolnemu procesorowi komunikatów. W przeciwnym razie w plikach dziennika procesora komunikatów mogą pojawić się komunikaty o błędach. |
| 8081 | Domyślny port zarządzania routera, który musi być otwarty na komponencie, aby serwer zarządzania miał do niego dostęp. | |
| 15999 |
Port kontroli stanu. System równoważenia obciążenia używa tego portu, aby określić, czy router jest dostępny. Aby uzyskać stan routera, system równoważenia obciążenia wysyła żądanie do portu 15999 na routerze: curl -v http://routerIP:15999/v1/servers/self/reachable Jeśli router jest osiągalny, żądanie zwraca kod HTTP 200. |
|
| 59001 | Port używany do testowania instalacji Edge przez narzędzie apigee-validate.
To narzędzie wymaga dostępu do portu 59001 na routerze. Więcej informacji o porcie 59001 znajdziesz w sekcji Testowanie instalacji. |
|
| SmartDocs | 59002 | Port na routerze Edge, na który są wysyłane żądania strony SmartDocs. |
| ZooKeeper | 2181 | Używane przez inne komponenty, takie jak serwer zarządzania, router, procesor komunikatów itp. |
| 2888, 3888 | Używany wewnętrznie przez ZooKeeper do komunikacji w klastrze ZooKeeper (znanym jako zespół ZooKeeper) |
W poniższej tabeli przedstawiono te same porty w kolejności numerycznej wraz z komponentami źródłowymi i docelowymi:
| Numer portu | Cel | Komponent źródłowy | Komponent docelowy |
|---|---|---|---|
| virtual_host_port | HTTP oraz inne porty używane do obsługi ruchu wywołań interfejsu API hosta wirtualnego. Najczęściej używane są porty 80 i 443. Router wiadomości może kończyć połączenia TLS/SSL. | Klient zewnętrzny (lub system równoważenia obciążenia) | Detektor w routerze wiadomości |
| 1099–1103 | Zarządzanie JMX | Klient JMX | Management Server (1099) Procesor komunikatów (1101) Serwer Qpid (1102) Serwer Postgres (1103) |
| 2181 | Komunikacja z klientem Zookeeper | Serwer zarządzania Router Procesor komunikatów Serwer Qpid Serwer Postgres |
Dozorca w zoo |
| 2888 i 3888 | Zarządzanie węzłami wewnętrznymi Zookeeper | Dozorca w zoo | Dozorca w zoo |
| 4526 | Port zarządzania RPC | Serwer zarządzania | Serwer zarządzania |
| 4527 | Port zarządzania RPC do wywołań rozproszonej pamięci podręcznej i zarządzania oraz do komunikacji między routerami | Serwer zarządzania Router |
Router |
| 4528 | Do wywołań rozproszonej pamięci podręcznej między procesorami komunikatów i do komunikacji z routera | Serwer zarządzania Router Procesor komunikatów |
procesor komunikatów |
| 4529 | Port zarządzania RPC dla rozproszonej pamięci podręcznej i wywołań zarządzania | Serwer zarządzania | Serwer Qpid |
| 4530 | Port zarządzania RPC dla rozproszonej pamięci podręcznej i wywołań zarządzania | Serwer zarządzania | Serwer Postgres |
| 5432 | Klient Postgres | Serwer Qpid | Postgres |
| 5672 |
|
Serwer Qpid | 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 na węźle Cassandra przez serwer zarządzania. | Klient JMX | Cassandra |
| 8080 | Port interfejsu API zarządzania Google Analytics | Klienty interfejsu API zarządzania Google Analytics | 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 port zależy od konfiguracji, ale musi być otwarty na komponencie, aby serwer zarządzania miał do niego dostęp. |
Klienty interfejsu API zarządzania Google Analytics | Router (8081) Procesor komunikatów (8082) Serwer Qpid (8083) Serwer Postgres (8084) |
| 8443 | Komunikacja między routerem a procesorem komunikatów, gdy protokół TLS jest włączony | Router | procesor komunikatów |
| 8998 | Komunikacja między routerem a procesorem komunikatów | Router | procesor komunikatów |
| 9000 | Domyślny port interfejsu zarządzania Edge | Przeglądarka | Serwer interfejsu zarządzania |
| 9042 | Transport natywny CQL | Router Procesor komunikatów Serwer zarządzania |
Cassandra |
| 9160 | Klient Cassandra Thrift | 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, aby określić, czy router jest dostępny. | System równoważenia obciążenia | Router |
| 59001 | Port używany przez narzędzie apigee-validate do testowania instalacji Edge |
apigee-validate | Router |
| 59002 | Port routera, na który są wysyłane żądania strony SmartDocs. | SmartDocs | Router |
Procesor komunikatów utrzymuje otwartą dedykowaną pulę połączeń z Cassandrą, która jest skonfigurowana tak, aby nigdy nie przekraczała limitu czasu. Gdy między procesorem komunikatów a serwerem Cassandra znajduje się zapora sieciowa, może ona spowodować przekroczenie limitu czasu połączenia. Procesor komunikatów nie jest jednak przeznaczony do ponownego nawiązywania połączeń z Cassandra.
Aby zapobiec takiej sytuacji, Apigee zaleca, aby serwer Cassandra, procesor komunikatów i routery znajdowały się w tej samej podsieci, dzięki czemu zapora sieciowa nie będzie zaangażowana we wdrażanie tych komponentów.
Jeśli między routerem a procesorami komunikatów znajduje się zapora sieciowa i ma ustawiony limit czasu bezczynności TCP, zalecamy wykonanie tych czynności:
- Ustaw
net.ipv4.tcp_keepalive_time = 1800w ustawieniach sysctl w systemie operacyjnym Linux, gdzie 1800 powinno być mniejsze niż limit czasu bezczynności TCP zapory sieciowej. To ustawienie powinno utrzymywać połączenie w stanie nawiązanym, aby zapora sieciowa go nie rozłączała. - We wszystkich procesorach komunikatów zmodyfikuj plik
/opt/apigee/customer/application/message-processor.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.conf_system_cassandra.maxconnecttimeinmillis=-1
- Ponownie uruchom procesor komunikatów:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Na wszystkich routerach zmodyfikuj plik
/opt/apigee/customer/application/router.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.conf_system_cassandra.maxconnecttimeinmillis=-1
- Ponowne uruchamianie routera:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart