Edge for Private Cloud w wersji 4.17.05
Wymagania sprzętowe
Aby uzyskać wysoką dostępność, musisz spełniać te minimalne wymagania sprzętowe w środowisku klasy produkcyjnej. Dla wszystkich scenariuszy instalacji opisanych w Topologie instalacji w tabelach poniżej minimalne wymagania sprzętowe dotyczące komponentów instalacyjnych.
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 pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HDD obsługującym 2000 IOPS. |
Procesor/trafiker wiadomości na tym samym komputerze |
16 GB |
8-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 większych niż 250 TPS wymagany jest dysk HDD z pamięcią lokalną obsługującą 1000 IOPS zalecane. Domyślny rozmiar kolejki Qpid to 20 GB. Jeśli chcesz zwiększyć pojemność, dodaj więcej Węzły Qpid. |
Inny (OpenLDAP, UI, serwer zarządzania) |
4 GB |
2-rdzeniowy |
60GB |
*Dostosuj wymagania systemowe Postgres na podstawie przepustowości:
|
|||
**Wartość dysku twardego Postgres jest określana na podstawie gotowych analiz przechwyconych przez
Edge. Jeśli dodasz do danych analitycznych wartości niestandardowe, powinny one być
odpowiednio zwiększono. Aby oszacować wymaganą ilość miejsca na dane, użyj tej formuły: |
|||
*** W przypadku bazy danych Postgresql zalecamy korzystanie z Network Storage, ponieważ:
|
Poza tym poniżej znajdziesz listę wymagań sprzętowych, które pozwolą Ci zainstalować Usługi służące do generowania przychodu:
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 wersja 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 |
40–500 GB pamięci lokalnej na dysku SSD lub szybkim HDD W przypadku instalacji większych niż 250 TPS wymagany jest dysk HDD z pamięcią lokalną obsługującą 1000 IOPS zalecane. |
Jeśli chcesz zainstalować interfejs API BaaS, poniżej znajdziesz wymagania sprzętowe:
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 pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HDD obsługującym 2000 IOPS. |
* W tym samym węźle możesz zainstalować stos BaaS ElasticSearch i stos interfejsu API. Jeśli to zrobisz, 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 dostarczone pliki instalacyjne zostały przetestowane na systemów operacyjnych i oprogramowania innych firm wymienionych na stronie 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. Nie możesz zmienić tego katalogu, ale możesz utworzyć dowiązanie symboliczne do mapy /opt/apigee na innej lokalizacji, jak opisano poniżej.
W instrukcjach w tym przewodniku katalog instalacji jest podany jako /<inst_root>/apigee, gdzie /<inst_root> domyślnie jest ustawiony na /opt.
Tworzenie dowiązania symbolicznego z: /opt/apigee
Przed utworzeniem dowiązania symbolicznego musisz utworzyć użytkownika i grupę o nazwie „apigee”. To jest tę samą grupę i użytkownika utworzone przez instalator Edge.
Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku Bostrap_4.17.01.sh. Musisz wykonać wszystkie te czynności jako użytkownik root:
- Tworzenie „apigee” użytkownik i grupa:
> groupadd -r Apigee
> useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Użytkownik platformy Apigee" Apigee - Utwórz dowiązanie symboliczne z /opt/apigee do wybranej instalacji
pierwiastek:
> ln -Ts /srv/myInstallDir /opt/apigee
gdzie /srv/myInstallDir to żądana lokalizacja Edge . - Zmień prawa własności do katalogu głównego instalacji i dowiązania symbolicznego do „apigee” użytkownik:
> chown -h apigee:apigee /srv/myInstallDir /opt/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 JAVA_HOME zawiera do katalogu głównego pakietu JDK użytkownika wykonującego instalację.
SELinux
W zależności od ustawień SELinux Edge mogą napotkać problemy z instalacją i uruchamianiem Komponenty brzegowe. W razie potrzeby możesz wyłączyć SELinux lub ustawić tryb mniej rygorystyczny podczas instalacji, a następnie ponownie włączyć program po instalacji. Więcej informacji znajdziesz w artykule Instalowanie narzędzia Edge apigee-setup.
Ustawienie sieci
Zalecamy sprawdzenie ustawień sieci przed instalacją. Instalator oczekuje, że 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. dla nazwy hosta, który może być adresowany z innych komputerów.
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.
Kody TCP
Kody TCP mogą blokować komunikację między niektórymi portami i mieć wpływ na OpenLDAP, Postgres Montaż systemu Cassandra. W tych węzłach sprawdź foldery /etc/hosts.allow i /etc/hosts.deny, aby upewnij się, że nie ma ograniczeń portów w wymaganych usługach OpenLDAP, Postgres i Cassandra. porty.
iptables
Sprawdź, czy nie ma zasad IPtables, które uniemożliwiają połączenie między węzłami wymagane porty brzegowe. W razie potrzeby możesz podczas instalacji zatrzymać IPtable, używając polecenie:
> sudo/etc/init.d/iptables stop
W systemie CentOS 7.x:
> systemctl stop firewalld
Sprawdź, czy router brzegowy może dostęp do pliku /etc/rc.d/init.d/functions
Węzły routera brzegowego i portalu BaaS używają routera Nginx i wymagają uprawnień do odczytu do pliku /etc/rc.d/init.d/functions.
Jeśli proces zabezpieczeń wymaga ustawienia uprawnień do pliku /etc/rc.d/init.d/functions, wykonaj nie ustawiaj ich na wartość 700, bo inaczej router się nie uruchomi. Aby umożliwić, można ustawić uprawnienie 744. uprawnienia do odczytu pliku /etc/rc.d/init.d/functions.
Cassandra
Wszystkie węzły Cassandra muszą być połączone z pierścieniem. Cassandra przechowuje repliki danych w wielu węzłów, aby zapewnić niezawodność i odporność na awarie. Strategia replikacji poszczególnych danych Przestrzeń klawiszy brzegowa określa węzły Cassandra, w których są umieszczone repliki. Więcej informacji: Informacje o Cassandra Współczynnik replikacji i poziom spójności.
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 . Upewnij się na przykład, że 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:
- Edytuj postgresql.properties:
> vi /<inst_root>/apigee/customer/application/postgresql.properties
Jeśli plik nie istnieje, utwórz go. - Ustaw wymienione powyżej właściwości.
- Zapisz zmiany.
- Uruchom ponownie bazę danych PostgreSQL:
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql Uruchom ponownie
Ograniczenia systemu
Sprawdź, czy na urządzeniu Cassandra i procesorze wiadomości masz ustawione poniższe limity systemu węzłów:
- W węzłach Cassandra ustaw limity łagodnego i twardego memlocka, nofile oraz przestrzeni adresowej dla
użytkownik instalacji (domyślnie „apigee”) w pliku /etc/security/limits.d/90-apigee-edge-limits.conf
pokazano poniżej:
apigee soft memlock bez ograniczeń
apigee Hard memlock bez ograniczeń
apigee soft nofile 32768
apigee Hard nofile 65536
apigee soft as nieograniczony
apigee twardy jak nieograniczony
- W węzłach procesora wiadomości ustaw maksymalną liczbę deskryptorów otwartych plików na 64 tys.
w pliku /etc/security/limits.d/90-apigee-edge-limits.conf
pokazano poniżej:
apigee soft nofile 32768
apigee Hard nofile 65536
W razie potrzeby możesz zwiększyć ten limit. Na przykład, jeśli masz dużą liczbę tymczasowych można otworzyć w dowolnej chwili.
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)
Network Security Services (NSS) to zbiór bibliotek, które obsługują tworzenie aplikacje klienckie i serwerowe z włączoną 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
Przeczytaj ten artykuł na stronie RedHat .
Wyłącz wyszukiwanie DNS w IPv6 w przypadku używania NSCD (demona pamięci podręcznej usługi nazw)
Jeśli zainstalowano i włączono NSCD (demon pamięci podręcznej usługi nazw), procesory wiadomości wykonuje dwa wyszukiwania DNS – jedno dla IPv4 i drugie dla IPv6. Wyłącz wyszukiwanie DNS na IPv6 w przypadku korzystania z NSCD.
Aby wyłączyć wyszukiwanie DNS w IPv6:
- W każdym węźle procesora wiadomości zmodyfikuj plik /etc/nscd.conf.
- Ustaw tę właściwość:
enable-cache hosts nie
Wyłącz IPv6 w Google Cloud Platforma dla RedHat/CentOS 7
Jeśli instalujesz Edge na RedHat 7 lub CentOS 7 w Google Cloud Platform, musi wyłączyć protokół IPv6 we wszystkich węzłach Qpid.
Instrukcje znajdziesz w dokumentacji RedHat lub CentOS dla używanej wersji systemu operacyjnego wyłączenie protokołu IPv6. Możesz na przykład:
- Otwórz plik /etc/hosts w redaktorem.
- Wstaw znak „#” znak w kolumnie pierwszego z wierszy, aby go skomentować:
Nr::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 - Zapisz plik.
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 |
wyrażenie |
lua-socket |
obr./min |
rozpakować |
nazwa_podstawowa |
grep |
ls |
rpm2cpio |
dodawanie użytkownika |
Bash |
nazwa hosta |
narzędzia sieciowe |
Sed |
wc |
bc |
id |
perl (z procps) |
sudo |
wget |
curl |
Libaio |
pgrep (z procps) |
smoła |
Xerces-C |
Cyrus-Sasl
|
libdb-cxx
|
ps | tr | mniam |
data |
libibverbs
|
pwd |
UUID |
chkconfig |
dirname |
librdmacm
|
python | Uname | |
echo |
libxslt
|
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" aby zainstalować OpenLDAP.
W przypadku instalacji z 13 hostami i 12 hostów z 2 centrami danych wymagane 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, takie jak hosty fizyczne, mogą mieć dla interfejsów sieciowych i zapór sieciowych.
- Hosty wirtualne: internetowe punkty końcowe podobne do hosta wirtualnego Apache.
Router maszyny wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się one od siebie alias hosta lub port 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 w obrębie maszyny wirtualnej i którym przez wirtualizację przypisano adres IP 111.111.111.111 maszyny lub serwer DHCP sieci; Zakładam, że VM2 udostępnia też interfejs wirtualnej sieci Ethernet zostanie 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 maszynie wirtualnej VM1 ujawnia 3 hosty wirtualne w swoim interfejsie eth0 (który ma pewne adresu IP), api.mojafirma.com:80, api.mycompany.com:443 i api.mycompany.com:443.
Router w maszynie VM2 udostępnia adres api.mycompany.com:80 (ta sama nazwa i port co ujawnione przez maszynę wirtualną 1).
System operacyjny fizycznego hosta może mieć zaporę sieciową. jeśli tak, ta zapora sieciowa musi być skonfigurowana tak, aby przekazywać ruch TCP powiązany z portami udostępnianymi w zwirtualizowanym środowisku interfejsów (111.111.111.111:{80, 443} i 111.111.111.222:80). Dodatkowo każda System operacyjny maszyny wirtualnej może mieć własną zaporę sieciową w interfejsie eth0, która także musi zezwól na połączenie przez porty 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 serwerów proxy interfejsów API mogą współdzielić punkt końcowy, jeśli ma on różne ścieżek bazowych. 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 właściwy dla Twojej instalacji i jest konfigurowane 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żysz interfejs API mycompany z podstawowym adresem URL /, 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 między routerem a procesorem wiadomości, domyślna konfiguracja to port 8082, musi być otwarty w procesorze wiadomości w celu zarządzania komponentem, ale router nie wymaga dostęp do niej.
- porty z przedrostkiem „M”. to porty używane do zarządzania komponentem i muszą być otwarte na i musi być otwarty w komponencie, aby serwer zarządzania miał dostęp do niego.
- 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ądzania wymaga dostępu do portu JMX w systemie Cassandra węzłów.
- 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 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:
Komponent |
Port |
Opis |
---|---|---|
Standardowe porty HTTP |
80 443 |
HTTP i wszelkie inne porty używane dla hostów wirtualnych |
Serwer zarządzania |
8080 |
Port dla wywołań interfejsu Edge Management API. 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 routera i musi być otwarty w komponencie, aby mieć do niego dostęp przez serwer zarządzania. |
4527 |
Do rozproszonej pamięci podręcznej i wywołań zarządzania |
|
15999 |
Port kontroli stanu. System równoważenia obciążenia używa tego portu do określenia, czy router i dostępności informacji. 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. |
|
59001 |
Port używany do testowania instalacji Edge przy użyciu narzędzia apigee-validate. To narzędzie wymaga dostępu do portu 59001 w routerze. Więcej informacji znajdziesz w artykule Testowanie instalacji na porcie 59001. |
|
ZooKeeper |
2181 |
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ć otwarty dla dostępu 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 i musi być otwarty w komponencie przez dostęp przez serwer zarządzania. |
|
1102 |
Port JMX |
|
4529 |
Do rozproszonej pamięci podręcznej i wywołań zarządzania |
|
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 i musi być otwarty w komponencie, aby mieć do niego dostęp przez serwer 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. |
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) 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 |
Miłośnik zoo |
2888 i 3888 |
Zarządzanie międzywęzłami w zookeeper |
Miłośnik zoo |
Miłośnik zoo |
4526 |
Port zarządzania RPC |
Serwer zarządzania |
Serwer zarządzania |
4527 | Port zarządzania RPC do rozproszonej pamięci podręcznej i wywołań 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 wiadomości oraz na potrzeby komunikacji z routera |
Serwer zarządzania Router procesor komunikatów |
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 |
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 a procesorem wiadomości |
Router |
procesor komunikatów |
9000 |
Domyślny port interfejsu zarządzania krawędziami |
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 |
59001 | Port używany przez narzędzie apigee-validate do testowania instalacja Edge | apigee-validate | 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:
- Ustaw parametr net.ipv4.tcp_keepalive_time = 1800 w ustawieniach sysctl w systemie Linux, gdzie wartość 1800 powinna być mniejsza niż zapora bezczynna. Upłynął limit czasu tcp. To ustawienie powinno utrzymywać połączenie w stanie ustanowienia, dzięki czemu zapora sieciowa nie odłącza połączenia.
- We wszystkich procesorach wiadomości edytuj plik /<inst_root>/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 - Uruchom ponownie procesor wiadomości:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart - We wszystkich routerach edytuj /<inst_root>/apigee/customer/application/router.properties
aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.
conf_system_cassandra.maxconnecttimeinmillis=-1 - Uruchom ponownie router:
> /opt/apigee/apigee-service/bin/apigee-service Edge-router restart
Jeśli instalujesz konfigurację klastra z 12 hostami i 2 centrami danych, upewnij się, że Węzły w dwóch centrach danych mogą komunikować się przez porty wymienione poniżej:
Wymagania dotyczące portu BaaS interfejsu API
Jeśli zdecydujesz się na zainstalowanie funkcji BaaS API, musisz dodać komponenty BaaS stosu i portalu BaaS API. Te komponenty korzystają z portów pokazanych na ilustracji poniżej:
Uwagi do tego diagramu:
- Portal BaaS API nigdy nie wysyła żądań bezpośrednio do węzła stosu BaaS. Gdy deweloper loguje się w portalu, aplikacja Portal jest pobierana do przeglądarki. Aplikacja portalu działająca w przeglądarka następnie wysyła żądania do węzłów stosu BaaS.
- 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.
- Wszystkie węzły stosu muszą otworzyć port 2551 dla dostępu z wszystkich pozostałych węzłów stosu (wskazanych przez strzałka pętli na diagramie powyżej dla portu 2551 w węzłach stosu). Jeśli masz wiele danych Centra danych, port musi być dostępny ze wszystkich węzłów stosu we wszystkich centrach danych.
- Musisz skonfigurować wszystkie węzły stosu Baas tak, aby wysyłały e-maile przez zewnętrzny serwer SMTP. Dla: SMTP bez szyfrowania TLS, numer portu to zwykle 25. W przypadku serwera SMTP z włączonym protokołem TLS często jest to kod 465, ale sprawdź, czy u swojego dostawcy SMTP.
- Węzły Cassandra mogą być dedykowane dla API BaaS lub można je udostępnić Edge.
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 |
Port dla interfejsu API BaaS |
Stos BaaS API |
8080 |
Port, na który odbierane są żądania do interfejsu API |
2551 |
Port do komunikacji między wszystkimi węzłami stosu. Musi być dostępny dla wszystkich pozostałych stosów w węzłach kolby danych. Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich węzłów stosu do wszystkich centrów danych. |
|
ElasticSearch |
9200–9400 |
Do komunikacji ze stosem BaaS API i między ElasticSearch węzłów |
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 /<inst_root>/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: /<inst_root>/apigee/var/log/edge-management-server/logs. W takim przypadku możesz skontaktować się z zespołem pomocy Apigee w sprawie szczegóły migracji.
Jeśli nie masz jeszcze licencji, skontaktuj się z zespołem sprzedaży tutaj.