Wymagania związane z portami

Konieczność zarządzania zaporą sieciową wykracza poza hosty wirtualne. Zarówno maszyny wirtualne, jak i fizyczne zapory sieciowe muszą zezwalać na ruch na portach wymaganych przez komponenty do komunikacji ze sobą.

Schematy portów

Poniższe obrazy przedstawiają wymagania dotyczące portu w konfiguracji pojedynczego centrum danych i wielu centrów danych:

Jedno centrum danych

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

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

Uwagi do tego diagramu:

  • Porty z prefiksem „M” to porty używane do zarządzania komponentem. Muszą one być otwarte w komponencie, aby mógł uzyskać do niego dostęp serwer zarządzania.
  • Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API w celu obsługi przycisku 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 Jak monitorować.
  • Opcjonalnie możesz 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.
  • Serwer zarządzania i interfejs użytkownika Edge możesz skonfigurować tak, 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 serwera SMTP bez szyfrowania TLS numer portu to zwykle 25. W przypadku 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 obu centrach danych mogą komunikować się przez wymienione poniżej 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 nawzajem 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 poza portami wymienionymi powyżej i innymi wymaganymi przez Twoje własne sieci, żaden inny port między centrami danych nie powinien być otwarty.

Domyślnie komunikacja między komponentami nie jest szyfrowana. Możesz dodać szyfrowanie, instalując Apigee mTLS. Więcej informacji znajdziesz we wprowadzeniu do mTLS w Apigee.

Szczegóły przeniesienia

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

Komponent Port Opis
Standardowe porty HTTP 80 443 HTTP oraz wszelkie inne porty używane na potrzeby hostów wirtualnych.
Logowanie jednokrotne Apigee 9099 Połączenia od 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 umożliwiające dostęp do innych komponentów Edge.
7199 Port JMX. Musi być otwarty, aby mógł uzyskać do niego dostęp przez serwer 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 potrzeby powiadomień o zatwierdzeniu do zarabiania.
8080 Port wywołań interfejsu Edge Management API. Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: routera, procesora wiadomości, UI, Postgres, logowania jednokrotnego 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 do komunikacji z routera i serwera zarządzania.

Jako port zarządzania komponent 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 zapętlenia na powyższym schemacie dla portu 4528 w tym procesorze). 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 procesora wiadomości, który musi być otwarty w komponencie, aby umożliwić dostęp serwerowi zarządzania.

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

Port 8082 w procesorze wiadomości musi być otwarty na dostęp 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, domyślna konfiguracja, port 8082 nadal musi być otwarty w procesorze wiadomości, 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 wiadomości, musisz otworzyć port 8443 w procesorze wiadomości, aby umożliwić dostęp do routera.
8998 Port procesora wiadomości do komunikacji z routerem
Postgres 22 W przypadku konfigurowania 2 węzłów Postgres do używania replikacji gotowości mastera w każdym węźle 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 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 był dostępny dla serwera zarządzania.
Qpid 1102 Port JMX
4529 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania
5672
  • Pojedyncze centrum danych: służy do wysyłania analiz 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, który musi być otwarty w komponencie, aby umożliwić dostęp serwerowi zarządzania.
Router 4527 Na potrzeby rozproszonej pamięci podręcznej i wywołań zarządzania.

Router musi mieć otwarty port 4527 jako port zarządzania. Jeśli masz kilka routerów, wszystkie muszą mieć dostęp do siebie przez port 4527 (na co wskazuje strzałka w pętli na diagramie powyżej 4527 w routerze).

Nie jest to wymagane, ale możesz otworzyć port 4527 w routerze, aby uzyskać dostęp dowolny podmiot przetwarzający wiadomości. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawiać się komunikaty o błędach.

8081 Domyślny port zarządzania dla routera, który musi być otwarty w komponencie, aby uzyskać 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 do niego żą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 na temat portu 59001 znajdziesz w sekcji Testowanie instalacji.
SmartDocs 59002 Port na routerze brzegowym, do którego wysyłane są żądania stron SmartDokumentacja.
ZooKeeper 2181 używane przez inne komponenty, takie jak serwer zarządzania, router czy procesor wiadomości.
2888, 3888 Używany wewnętrznie przez komunikację dotyczącą klastra ZooKeeper (znanego jako zespół ZooKeeper)

W następnej tabeli znajdziesz te same porty wymienione liczbowo z komponentami źródłowymi i docelowymi:

Numer portu Purpose Komponent źródłowy Komponent docelowy
virtual_host_port HTTP oraz wszelkie inne porty używane do ruchu związanego z wywołaniami 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 Komunikacja z klientem Zookeeper Serwer zarządzania
Router
Procesor wiadomości
Serwer Qpid
Serwer Postgres
opiekun zoologiczny
2888 i 3888 Zarządzanie węzłem zoologicznym opiekun zoologiczny opiekun zoologiczny
4526 Port zarządzania RPC Serwer zarządzania Serwer zarządzania
4527 Port zarządzania RPC na potrzeby wywołań zarządzania rozproszoną pamięcią podręczną i zarządzania oraz do komunikacji między routerami Serwer zarządzania
routerem
Router
4528 Do wywołań rozproszonej pamięci podręcznej między procesorami wiadomości oraz komunikacji z routera Serwer zarządzania
router
przetwarzający 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 Zarabianie Zewnętrzny komponent JMS Serwer zarządzania
5672
  • Pojedyncze centrum danych: służy do wysyłania analiz 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, aby mógł uzyskać dostęp do węzła 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 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 mógł uzyskać dostęp do tego portu

Klienty interfejsu Management API Router (8081)
Przetwarzający wiadomości (8082)
Serwer Qpid (8083)
Serwer Postgres (8084)
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
Serwer wiadomości
Serwer zarządzania
Cassandra
9099 Uwierzytelnianie zewnętrznego dostawcy tożsamości Dostawca tożsamości, przeglądarka i serwer zarządzania Logowanie jednokrotne Apigee
9160 klient hazardowy Cassandra Router
Serwer wiadomości
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 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 SmartDokumentacja SmartDocs Router

Procesor wiadomości utrzymuje 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 połączenie. Procesor wiadomości nie służy jednak do ponownego nawiązywania połączeń z Cassandra.

W celu uniknięcia takiej sytuacji Apigee zaleca, aby serwer Cassandra, procesor wiadomości i routery były w tej samej podsieci, dzięki czemu zapora sieciowa nie uczestniczy we wdrożeniu tych komponentów.

Jeśli zapora sieciowa znajduje się między routerem a procesorami wiadomości i ma ustawiony limit czasu 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 utrzymać połączenie w stanie ugruntowanym, 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