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:
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:
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 |
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 |
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:
- 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. - 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
- Ponownie uruchom procesor wiadomości:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- 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
- Ponownie uruchom router:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart