Wymagania związane z portami

Konieczność zarządzania zaporą sieciową wykracza poza ograniczenia wirtualne. Zapora sieciowa zarówno maszyn wirtualnych, jak i fizycznych, musi zezwalać na komunikację między portami wymaganymi przez komponenty.

Diagramy portów

Na tych ilustracjach przedstawiono wymagania dotyczące portów w konfiguracji pojedynczego centrum danych i wielu centrów danych:

Jedno centrum danych

Poniższy obraz przedstawia wymagania dotyczące portów dla każdego komponentu Edge w pojedynczej konfiguracji centrum danych:

Wymagania dotyczące portów dla każdego komponentu Edge w pojedynczej konfiguracji centrum danych

Uwagi do diagramu:

  • Porty z prefiksem „M” to porty używane do zarządzania komponentem. Muszą być one otwarte w komponencie, aby mógł uzyskać do nich dostęp serwer zarządzania.
  • 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ć podania nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule o monitorowaniu.
  • Opcjonalnie możesz skonfigurować dostęp TLS/SSL dla określonych połączeń, które mogą korzystać z różnych portów. Więcej informacji znajdziesz w sekcji TLS/SSL.
  • Możesz skonfigurować serwer zarządzania i interfejs użytkownika Edge do wysyłania e-maili przez zewnętrzny serwer SMTP. Jeśli to zrobisz, musisz się upewnić, że serwer zarządzania i interfejs użytkownika mają dostęp do niezbędnego portu na serwerze SMTP (nie jest to pokazane). W przypadku serwera SMTP bez TLS numer portu to zwykle 25. W przypadku serwera SMTP z włączonym TLS jest to często 465, ale skontaktuj się z dostawcą SMTP.

Wiele centrów danych

Jeśli zainstalujesz grupową konfigurację z 12 węzłami i 2 centrami danych, upewnij się, że węzły w 2 centrach danych mogą komunikować się przez poniższe porty:

Wymagania dotyczące portów dla każdego węzła w konfiguracji klastra z 12 węzłami

Pamiętaj, że:

  • Wszystkie serwery zarządzania muszą mieć dostęp do wszystkich węzłów Cassandra we wszystkich innych centrach danych.
  • Wszystkie procesory wiadomości we wszystkich centrach danych muszą mieć dostęp do siebie przez port 4528.
  • Serwer zarządzania musi mieć dostęp do wszystkich procesorów wiadomości 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 inne porty inne niż wymienione powyżej i inne wymagane przez Twoje własne wymagania sieciowe nie powinny być otwarte między centrami danych.

Domyślnie komunikacja między komponentami nie jest szyfrowana. Aby dodać szyfrowanie, możesz zainstalować Apigee mTLS. Więcej informacji znajdziesz we wprowadzeniu do Apigee mTLS.

Szczegóły gniazda

W tabeli poniżej opisano porty, które należy otworzyć w zaporach sieciowych za pomocą komponentu Edge:

Komponent Port Opis
Standardowe porty HTTP 80 443 HTTP i wszystkie inne porty używane na potrzeby hostów wirtualnych.
Logowanie jednokrotne w Apigee 9099 Połączenia z zewnętrznych dostawców tożsamości, serwera zarządzania i przeglądarek na potrzeby uwierzytelniania.
Cassandra 7000, 9042, 9160 Porty Apache Cassandra do komunikacji między węzłami Cassandra i na potrzeby dostępu do innych komponentów Edge.
7199 Port JMX. Musi być otwarta dla serwera zarządzania.
LDAP 10389 OpenLDAP
Serwer zarządzania 1099 Port JMX
4526 Port na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania. Ten port można skonfigurować.
5636 Port na powiadomienia o zobowiązaniach do zarabiania.
8080 Port dla wywołań interfejsu API zarządzania urządzeniami brzegowymi. Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: Router, procesor wiadomości, interfejs użytkownika, Postgres, logowanie jednokrotne w Apigee (jeśli jest włączone) i Qpid.
Interfejs zarządzania 9000 Port dostępu przeglądarki do interfejsu zarządzania
procesor komunikatów 1101 Port JMX
4528 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania między procesorami wiadomości oraz na potrzeby komunikacji z routera i serwera zarządzania.

Jako port zarządzania podmiot przetwarzający wiadomości musi otworzyć port 4528. Jeśli masz kilka procesorów wiadomości, wszystkie muszą mieć dostęp do siebie przez port 4528 (co wskazuje strzałka pętli na diagramie powyżej dla portu 4528 procesora wiadomości). Jeśli masz wiele centrów danych, port musi być dostępny dla wszystkich procesorów wiadomości we wszystkich centrach danych.

8082

Domyślny port zarządzania na potrzeby podmiotu przetwarzającego wiadomości i musi być otwarty w komponencie, aby umożliwić dostęp przez serwer zarządzania.

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

Port 8082 procesora wiadomości musi być otwarty dla routera tylko podczas konfigurowania protokołu TLS/SSL między routerem a procesorem wiadomości. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem wiadomości, przy domyślnej konfiguracji port 8082 nadal musi być otwarty w tym procesorze wiadomości, aby możliwe było zarządzanie komponentem, ale router nie wymaga dostępu do niego.

8443 Gdy protokół TLS jest włączony między routerem a procesorem wiadomości, musisz otworzyć port 8443 procesora wiadomości, aby router mógł uzyskać dostęp.
8998 Port podmiotu przetwarzającego wiadomości na potrzeby komunikacji z routerem
Postgres 22 Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji w trybie gotowości, musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH.
1103 Port JMX
4530 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania
5432 Używany do komunikacji z serwera Qpid/serwera zarządzania z Postgres
8084 Domyślny port zarządzania na serwerze Postgres; musi być otwarty w komponencie, aby umożliwić dostęp przez serwer zarządzania.
Qpid 1102 Port JMX
4529 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania
5672
  • Pojedyncze centrum danych: używane do wysyłania statystyk z routera i procesora wiadomości do Qpid.
  • Wiele centrów danych: służy do komunikacji między węzłami Qpid w różnych centrach danych.

Służy też do komunikacji między serwerem Qpid a komponentami brokera w tym samym węźle. W topologii z wieloma węzłami Qpid serwer musi mieć możliwość połączenia się ze wszystkimi brokerami przez port 5672.

8083 Domyślny port zarządzania na serwerze Qpid. Musi on być otwarty w komponencie, aby umożliwić dostęp przez serwer zarządzania.
8090 Domyślny port dla brokera Qpid. Musi być otwarty, aby mieć dostęp do konsoli zarządzania brokera lub interfejsów API zarządzania na potrzeby monitorowania.
Router 4527 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania.

Jako port zarządzania router musi otworzyć port 4527. Jeśli masz kilka routerów, wszystkie muszą mieć dostęp do siebie przez port 4527 (wskazuje na to strzałka zapętlania na diagramie powyżej dla portu 4527 routera).

Możesz otworzyć port 4527 w routerze, aby mieć do niego dostęp dowolny podmiot przetwarzający wiadomości, choć nie jest to wymagane. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawić się komunikaty o błędach.

8081 Domyślny port zarządzania routerem, który musi być otwarty w komponencie, aby umożliwić dostęp przez serwer zarządzania.
15999

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

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

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

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

59001 Port używany do testowania instalacji Edge przez narzędzie apigee-validate. To narzędzie wymaga dostępu do portu 59001 w routerze. Więcej informacji znajdziesz w sekcji Testowanie instalacji na porcie 59001.
SmartDocs 59002 Port na routerze brzegowym, do którego wysyłane są żądania stron SmartDokumenty.
ZooKeeper 2181 Używana przez inne komponenty, takie jak serwer zarządzania, router czy procesor wiadomości.
2888, 3888 Używana wewnętrznie przez ZooKeeper na potrzeby komunikacji klastra ZooKeeper (znanego jako zespół ZooKeeper)

W następnej tabeli znajdziesz te same porty wymienione numerycznie z uwzględnieniem komponentów źródłowych i docelowych:

Numer portu Purpose Komponent źródłowy Komponent docelowy
virtual_host_port HTTP i wszystkie 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 zakoń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)
Message Processor (1101)
Qpid Server (1102)
Postgres Server (1103)
2181 Zookeeper – komunikacja z klientami Serwer zarządzania
Router
Procesor wiadomości
Serwer Qpid
Serwer Postgres
Opiekun zoo
2888 i 3888 Zarządzanie interwęzłem Zookeeper Opiekun zoo Opiekun zoo
4526 Port zarządzania RPC Serwer zarządzania Serwer zarządzania
4527 Port zarządzania RPC na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania oraz komunikacji między routerami Router
serwera zarządzania
Router
4528 Na potrzeby rozproszonych wywołań pamięci podręcznej między procesorami wiadomości oraz do komunikacji z routera Serwer zarządzania
Router
procesor wiadomości
procesor komunikatów
4529 Port zarządzania RPC na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania Serwer zarządzania Serwer Qpid
4530 Port zarządzania RPC na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania Serwer zarządzania Serwer Postgres
5432 Klient Postgres Serwer Qpid Postgres
5636 Generowanie przychodu Zewnętrzny komponent JMS Serwer zarządzania
5672
  • Pojedyncze centrum danych: używane do wysyłania statystyk z routera i procesora wiadomości do Qpid.
  • Wiele centrów danych: służy do komunikacji między węzłami Qpid w różnych centrach danych.

Służy też do komunikacji między serwerem Qpid a komponentami brokera w tym samym węźle. W topologii z wieloma węzłami Qpid serwer musi mieć możliwość połączenia się ze wszystkimi brokerami przez port 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 w węźle Cassandra przez serwer zarządzania. Klient JMX Cassandra
8080 Port interfejsu API zarządzania Klienty interfejsu Management API Serwer zarządzania
8081–8084

Porty interfejsu API komponentów służące do wysyłania żądań 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 na komponencie, aby serwer zarządzania mógł uzyskać dostęp

Klienty interfejsu Management API Router (8081)
Procesor wiadomości (8082)
Serwer Qpid (8083)
Serwer Postgres (8084)
8090 Domyślny port zarządzania dla brokera Qpid'a do zarządzania kolejkami i ich monitorowania. Przeglądarka lub klient interfejsu API Broker Qpid (apigee-qpidd)
8443 Komunikacja między routerem a procesorem wiadomości przy włączonym TLS Router procesor komunikatów
8998 Komunikacja między routerem a procesorem wiadomości Router procesor komunikatów
9000 Domyślny port interfejsu zarządzania brzegiem sieci Przeglądarka Serwer interfejsu zarządzania
9042 Transport natywny CQL Router
Message Processor
Server Management
Cassandra
9099 Uwierzytelnianie zewnętrznego dostawcy tożsamości Dostawca tożsamości, przeglądarka i serwer zarządzania Logowanie jednokrotne w Apigee
9160 Klient z branży handlowej Cassandra Router
Message Processor
Server Management
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 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, do którego wysyłane są żądania stron SmartDokumenty SmartDocs Router

Procesor wiadomości pozostawia dedykowaną pulę połączeń otwartą dla Cassandra, która jest skonfigurowana tak, aby nigdy nie przekraczać limitu czasu. Jeśli zapora sieciowa znajduje się między procesorem wiadomości a serwerem Cassandra, może ona przekroczyć limit czasu na nawiązanie połączenia. Procesor wiadomości nie służy jednak do ponownego nawiązywania połączeń z Cassandra.

Aby zapobiec takiej sytuacji, Apigee zaleca, aby serwer Cassandra, procesor wiadomości i routery znajdowały się w tej samej podsieci, dzięki czemu zapora sieciowa nie uczestniczy we wdrażaniu tych komponentów.

Jeśli zapora sieciowa znajduje się między routerem a procesorami wiadomości i ma ustawiony czas oczekiwania na bezczynności TCP, zalecamy wykonanie tych czynności:

  1. Ustaw wartość net.ipv4.tcp_keepalive_time = 1800 w ustawieniach sysctl w systemie operacyjnym Linux, gdzie wartość 1800 powinna być mniejsza niż limit czasu bezczynności tcp zapory sieciowej. To ustawienie powinno utrzymywać połączenie w stanie nawiązanym, aby zapora sieciowa nie rozłączała go.
  2. We wszystkich systemach przetwarzania wiadomości edytuj /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
  3. Ponownie uruchom procesor wiadomości:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  4. We wszystkich routerach edytuj /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
  5. Ponownie uruchom router:
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart