Edge for Private Cloud, wersja 4.18.01
Wymagania sprzętowe
Aby uzyskać wysoką dostępność infrastruktury w środowisku produkcyjnym, musisz spełnić te minimalne wymagania sprzętowe. W przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji w tabelach poniżej podano minimalne wymagania sprzętowe dotyczące komponentów instalacyjnych.
W tych tabelach oprócz miejsca na dysku twardym wymaganego przez system operacyjny wymagane są też wymagania dotyczące dysku twardego. W zależności od aplikacji i ruchu w sieci instalacja może wymagać większych lub mniejszej ilości zasobów niż wymieniona poniżej.
Komponent instalacyjny | RAM | CPU | Minimalny dysk twardy |
---|---|---|---|
Cassandra | 16 GB | 8-rdzeniowy | 250 GB pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HDD obsługującym 2000 IOPS |
Procesor wiadomości/router na tym samym komputerze | 16 GB | 8-rdzeniowy | 100GB |
Analytics – Postgres/Qpid na tym samym serwerze (niezalecane dla środowiska produkcyjnego) | 16GB* | 8-rdzeniowy* | 500 GB – 1 TB** miejsca na dane w sieci***, najlepiej przy użyciu backendu SSD, który obsługuje 1000 IOPS lub więcej* |
Analytics – samodzielna usługa Postgres | 16GB* | 8-rdzeniowy* | 500 GB – 1 TB** miejsca na dane w sieci***, najlepiej przy użyciu backendu SSD, który obsługuje 1000 IOPS lub więcej* |
Analytics – samodzielna usługa Qpid | 8 GB | 4-rdzeniowy | 30 GB – 50 GB pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HD
W przypadku instalacji większych niż 250 TPS zalecamy używanie dysku HDD z pamięcią lokalną 1000 IOPS. Domyślny rozmiar kolejki Qpid to 20 GB. Jeśli chcesz zwiększyć ilość miejsca, dodaj więcej węzłów Qpid. |
Inne (OpenLDAP, UI, serwer zarządzania) | 4 GB | 2-rdzeniowy | 60GB |
* Dostosuj wymagania systemowe Postgres na podstawie przepustowości:
- mniej niż 250 TPS: 8 GB, 4-rdzeniowy procesor z zarządzaną pamięcią sieciową*** obsługującą co najmniej 1000 IOPS
- Większy niż 250 TPS: 16 GB, 8-rdzeniowy, zarządzana pamięć masowa*** obsługująca co najmniej 1000 IOPS
- Większy niż 1000 TPS: 16 GB, 8-rdzeniowy, zarządzana pamięć masowa*** obsługująca 2000 IOPS lub więcej
- Większy niż 2000 TPS: 32 GB, 16-rdzeniowe, zarządzane miejsce na sieć*** obsługujące 2000 IOPS lub więcej
- Większy niż 4000 TPS: 64 GB, 32-rdzeniowy, zarządzany dysk sieciowy*** obsługujący co najmniej 4000 IOPS
** Wartość dysku twardego Postgres jest rejestrowana na podstawie analiz dostarczanych przez Edge. Jeśli dodasz wartości niestandardowe do danych analitycznych, musisz je odpowiednio zwiększyć. Aby oszacować wymagane miejsce na dane, użyj tej formuły:
bytes of storage needed =
(# bytes of analytics data/request) *
(requests/second) *
(seconds/hour) *
(hours of peak usage/day) *
(days/month) *
(months of data retention)
Na przykład:
(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)
= 1,194,393,600,000 bytes or 1194.4 GB
*** W przypadku bazy danych Postgresql zalecane jest przechowywanie danych w sieci, ponieważ:
- W razie potrzeby można dynamicznie skalować rozmiar miejsca na dane.
- IOPS sieci można dostosowywać w czasie rzeczywistym w większości współczesnych podsystemów/pamięci/sieci.
- Zrzuty na poziomie miejsca na dane można włączyć w ramach funkcji tworzenia kopii zapasowych i przywracania.
Jeśli chcesz zainstalować Usługi zarabiania, poniżej znajdziesz też wymagania sprzętowe:
Komponent z zarabianiem | RAM | CPU | Dysk twardy |
---|---|---|---|
Serwer zarządzania (z usługami zarabiania) | 8 GB | 4-rdzeniowy | 60GB |
Analytics – Postgres/Qpid na tym samym serwerze | 16 GB | 8-rdzeniowy | 500 GB – 1 TB miejsca na dane, najlepiej w przypadku backendu SSD lub obsługującego 1000 IOPS lub więcej. Możesz też skorzystać z reguły z tabeli powyżej. |
Analytics – samodzielna usługa Postgres | 16 GB | 8-rdzeniowy | 500 GB – 1 TB miejsca na dane, najlepiej w przypadku backendu SSD lub obsługującego 1000 IOPS lub więcej. Możesz też skorzystać z reguły z tabeli powyżej. |
Analytics – samodzielna usługa Qpid | 8 GB | 4-rdzeniowy | 40 GB – 500 GB pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HD
W przypadku instalacji większych niż 250 TPS zalecamy używanie dysku HDD z pamięcią lokalną 1000 IOPS. |
Jeśli chcesz zainstalować BaaS API, poniżej znajdziesz listę wymagań sprzętowych:
Komponent BaaS API | RAM | CPU | Dysk twardy |
---|---|---|---|
ElasticSearch* | 8 GB | 4-rdzeniowy | 60–80 GB |
Stos API BaaS* | 8 GB | 4-rdzeniowy | 60–80 GB |
Portal BaaS API | 1GB | 2-rdzeniowy | 20GB |
Kasandra** | 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 ElasticSearch i API BaaS. Jeśli to zrobisz, skonfiguruj ElasticSearch tak, aby korzystało z 4 GB pamięci (domyślnie). Jeśli aplikacja ElasticSearch jest zainstalowana w jej własnym węźle, skonfiguruj ją tak, aby wykorzystywała 6 GB pamięci.
** Opcjonalne. Zwykle używasz tego samego klastra Cassandra dla usług Edge i API BaaS.
Wymagania dotyczące systemu operacyjnego i oprogramowania innej firmy
Te instrukcje instalacji i dołączone pliki instalacyjne zostały przetestowane na systemach operacyjnych i w oprogramowaniu innej firmy z listy Obsługiwane oprogramowanie i obsługiwane wersje.
Tworzenie użytkownika Apigee
Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki Edge są własnością „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge uruchamiają się jako użytkownik „apigee”. W razie potrzeby możesz uruchomić komponenty jako inny użytkownik.
Katalog instalacji
Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee
. Nie możesz zmienić tej lokalizacji katalogu. Nie możesz zmienić tego katalogu, ale możesz utworzyć dowiązanie symboliczne, aby zmapować /opt/apigee
na inną lokalizację zgodnie z opisem poniżej.
W instrukcjach w tym przewodniku katalog instalacji będzie oznaczony jako /opt/apigee
.
Tworzenie dowiązania symbolicznego z /opt/apigee
Zanim utworzysz dowiązanie symboliczne, musisz najpierw utworzyć użytkownika i grupę o nazwie „apigee”. Jest to ta sama grupa i ten sam użytkownik, które utworzył instalator Edge.
Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku rozruchowego _4.18.01.sh. Wszystkie te czynności musisz wykonać jako root:
- Utwórz użytkownika i grupę „apigee”:
groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
- Utwórz dowiązanie symboliczne z elementu
/opt/apigee
do żądanego elementu głównego instalacji:ln -Ts /srv/myInstallDir /opt/apigee
gdzie /srv/myInstallDir to żądana lokalizacja plików Edge.
- Zmień właściciela głównego katalogu instalacji i linku symbolowego na użytkownika „apigee”:
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Java
Przed instalacją musisz mieć zainstalowaną obsługiwaną wersję środowiska Java 1.8. Obsługiwane pakiety JDK znajdziesz w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.
Upewnij się, że JAVA_HOME
wskazuje katalog główny pakietu JDK dla użytkownika wykonującego instalację.
SELinux
W zależności od ustawień SELinux Edge może mieć problemy z instalowaniem i uruchamianiem komponentów Edge. W razie potrzeby podczas instalacji możesz wyłączyć SELinux lub ustawić go w trybie mniej restrykcyjnym, a następnie ponownie włączyć go po instalacji. Więcej informacji znajdziesz w artykule Instalowanie narzędzia Edge apigee.
Ustawienia sieci
Zalecamy sprawdzenie ustawienia sieci przed instalacją. Instalator oczekuje, że wszystkie komputery mają stałe adresy IP. Aby sprawdzić ustawienie, użyj tych poleceń:
hostname
zwraca nazwę komputerahostname -i
zwraca adres IP nazwy hosta, do którego można uzyskać dostęp z innych komputerów.
W zależności od typu i wersji systemu operacyjnego konieczne może być edytowanie właściwości /etc/hosts
i /etc/sysconfig/network
, jeśli nazwa hosta nie jest prawidłowo skonfigurowana. Więcej informacji znajdziesz w dokumentacji konkretnego systemu operacyjnego.
Jeśli serwer ma wiele kart interfejsu, polecenie „nazwa-hosta -i” zwraca oddzieloną spacjami listę adresów IP. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, który może nie być prawidłowy w niektórych sytuacjach. Zamiast tego możesz ustawić w pliku konfiguracji instalacji tę właściwość:
ENABLE_DYNAMIC_HOSTIP=y
Gdy właściwość ma wartość „y”, instalator poprosi Cię o wybranie adresu IP, który zostanie użyty podczas instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji plików krańcowych.
Kody TCP
Paczki TCP mogą blokować komunikację między niektórymi portami oraz wpływać na instalację OpenLDAP, Postgres i Cassandra. W tych węzłach sprawdź /etc/hosts.allow
i /etc/hosts.deny
, aby upewnić się, że nie ma ograniczeń portów wymaganych przez porty OpenLDAP, Postgres i Cassandra.
iptablety
Sprawdź, czy nie ma zasad iptable, które blokują połączenia między węzłami na wymaganych portach brzegowych. W razie potrzeby możesz zatrzymać iptables podczas instalacji przy użyciu polecenia:
sudo/etc/init.d/iptables stop
W systemie CentOS 7.x:
systemctl stop firewalld
Upewnij się, że router graniczny ma dostęp do katalogu /etc/rc.d/init.d/functions
Węzły Edge Router i BaaS Portal używają routera Nginx i wymagają dostępu do odczytu do /etc/rc.d/init.d/functions
.
Jeśli proces zabezpieczeń wymaga ustawienia uprawnień w /etc/rc.d/init.d/functions
, nie ustawiaj wartości 700. W przeciwnym razie router nie uruchomi się. Można ustawić uprawnienia 744, aby umożliwić dostęp w trybie odczytu do /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łach, aby zapewnić niezawodność i odporność na awarie. Strategia replikacji dla każdej przestrzeni kluczy Edge określa węzły Cassandra, w których znajdują się repliki. Więcej informacji znajdziesz w sekcji Informacje o poziomie replikacji i spójności poziomu Cassandra.
Cassandra automatycznie dostosowuje rozmiar sterty środowiska Java na podstawie dostępnej pamięci. Więcej informacji znajdziesz w artykule na temat dostrajania zasobów Java. W przypadku pogorszenia wydajności lub dużego zużycia pamięci.
Po zainstalowaniu Edge dla Private Cloud możesz sprawdzić, czy Cassandra jest poprawnie skonfigurowana, analizując plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml
. Na przykład upewnij się, że skrypt instalacyjny Edge for Private Cloud ma ustawione te właściwości:
cluster_name
initial_token
partitioner
seeds
listen_address
rpc_address
snitch
Baza danych PostgreSQL
Po zainstalowaniu Edge możesz dostosować następujące ustawienia bazy danych PostgreSQL w zależności od ilości 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 plik postgresql.property:
vi /opt/apigee/customer/application/postgresql.properties
Jeśli plik nie istnieje, utwórz go.
- Ustaw właściwości wymienione powyżej.
- Zapisz zmiany.
- Ponowne uruchamianie bazy danych PostgreSQL:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
Ograniczenia systemu
Sprawdź, czy w węzłach Cassandra i Procesor wiadomości ustawiono następujące limity systemowe:
- W węzłach Cassandra ustaw miękkie i twarde memlock, nofile i przestrzeń adresową (as) dla użytkownika instalacji (domyślnie jest to „apigee”) w
/etc/security/limits.d/90-apigee-edge-limits.conf
:apigee soft memlock unlimited apigee hard memlock unlimited apigee soft nofile 32768 apigee hard nofile 65536 apigee soft as unlimited apigee hard as unlimited
- W węzłach procesora wiadomości ustaw maksymalną liczbę deskryptorów plików na 64 tys. w regionie
/etc/security/limits.d/90-apigee-edge-limits.conf
, jak 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 w danym momencie masz otwartych dużą liczbę plików tymczasowych.
JSV
„jsvc” jest warunkiem korzystania z interfejsu BaaS API. Podczas instalacji interfejsu API BaaS zostanie zainstalowana wersja 1.0.15-dev.
Usługi zabezpieczeń sieci
Network Security Services (NSS) to zbiór bibliotek, które obsługują aplikacje klienckie i serwerowe z włączoną obsługą zabezpieczeń. Pamiętaj, aby zainstalować NSS w wersji 3.19 lub nowszej.
Aby sprawdzić aktualną wersję:
yum info nss
Aby zaktualizować NSS:
yum update nss
Więcej informacji znajdziesz w tym artykule przygotowanym przez RedHat.
Wyłącz wyszukiwanie DNS w IPv6 podczas korzystania z NSCD (platforma Nazwa pamięci podręcznej usługi)
Jeśli zainstalowano i włączono NSCD (Name Service Cache Deemon), firmy obsługujące wiadomości przetwarzają dwa zapytania DNS: jedno dla IPv4 i jedno dla IPv6. Jeśli używasz NSCD, wyłącz wyszukiwanie DNS w IPv6.
Aby wyłączyć wyszukiwanie DNS w IPv6:
- W każdym węźle procesora wiadomości edytuj
/etc/nscd.conf
- Ustaw tę właściwość:
enable-cache hosts no
Wyłącz IPv6 w Google Cloud Platform dla RedHat/CentOS 7
Jeśli instalujesz Edge w RedHat 7 lub CentOS 7 w Google Cloud Platform, musisz wyłączyć IPv6 we wszystkich węzłach Qpid.
W dokumentacji odpowiedniej wersji systemu operacyjnego RedHat lub CentOS znajdziesz instrukcje dotyczące wyłączania protokołu IPv6. Na przykład możesz:
- Otwórz plik
/etc/hosts
w edytorze. - Wstaw znak „#” w kolumnie w jednym z tych wierszy, aby dodać komentarz:
#::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
- Zapisz plik.
AWS AMI,
Jeżeli instalujesz Edge na komputerze 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 poniższych narzędzi UNIX w wersji standardowej, które udostępnia EL5 lub EL6.
awk |
wystawca |
Biblioteka libxlst |
obr./min |
rozpakuj |
nazwa |
grep |
Lua-Socket |
rpm2cpio |
dodanie użytkownika |
bash |
nazwa hosta |
LS |
sed |
tydz. |
UDW |
id |
narzędzia netto |
Sudo |
Wget |
curl |
Libío |
perl (z procps) |
szarlotka |
Xerces-C |
Cyrus-Sasl | libdb4, | pgrep (z rekwizytów) | tr | mniam |
data |
libdb-cxx, |
ps |
UUID |
Konfiguracja Chrome |
dirname | liberbverbs, | Subskrybuj | Uname | |
Echo | librdmacm, | python |
Natywne
Zaleca się synchronizowanie godzin korzystania z serwerów. Jeśli nie masz jeszcze skonfigurowanego tego narzędzia, narzędzie ntpdate
może sprawdzić, czy serwery są synchronizowane. Do zainstalowania narzędzia możesz użyć polecenia yum install ntp
. Jest to szczególnie przydatne do replikowania konfiguracji OpenLDAP. Pamiętaj, że konfigurujesz strefę czasową serwera w strefie czasowej UTC.
openldap 2.4
Instalacja lokalna wymaga OpenLDAP w wersji 2.4. Jeśli serwer ma połączenie z internetem, skrypt instalacyjny Edge pobiera i instaluje OpenLDAP. Jeśli serwer nie ma połączenia z internetem, przed uruchomieniem skryptu instalacji Edge musisz się upewnić, że OpenLDAP jest już zainstalowany. W RHEL/CentOS możesz uruchomić yum install openldap-clients openldap-servers
, aby zainstalować OpenLDAP.
W przypadku instalacji z 13 hostów i 12 hostów z 2 centrami danych wymagasz replikacji OpenLDAP, ponieważ istnieje wiele węzłów hostujących OpenLDAP.
Zapory sieciowe i hosty wirtualne
Termin virtual
jest zwykle przeciążany w hali IT, więc wraz z Apigee Edge do wdrożenia chmury prywatnej i hostów wirtualnych. Aby rozwiać wątpliwości, termin virtual
występuje w 2 głównych zastosowaniach:
- Maszyny wirtualne: niewymagane, ale niektóre wdrożenia wykorzystują technologię maszyn wirtualnych do tworzenia izolowanych serwerów dla komponentów Apigee. Hosty maszyn wirtualnych, tak jak hosty fizyczne, mogą mieć interfejsy sieci i zapory sieciowe.
- Hosty wirtualne: internetowe punkty końcowe analogiczne do hosta wirtualnego Apache.
Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się od siebie za pomocą aliasu hosta lub portu interfejsu).
Tak jak w przypadku nazewnictwa, jeden fizyczny serwer A
może używać 2 maszyn wirtualnych o nazwie „VM1” i „VM2”. Załóżmy, że „VM1” udostępnia wirtualny interfejs Ethernet, który otrzymuje nazwę „eth0” w maszynie wirtualnej i przypisuje jej adres IP 111.111.111.111
maszynie wirtualnej lub serwerowi DHCP. Następnie załóżmy, że VM2 udostępnia wirtualny interfejs Ethernet o nazwie „eth0” i przypisuje mu adres IP 111.111.111.222
.
W każdej z tych maszyn wirtualnych może być uruchomiony router Apigee. Routery ujawniają punkty końcowe hosta wirtualnego w następujący sposób:
Router Apigee w VM1 udostępnia 3 hosty wirtualne w interfejsie eth0 (z określonym adresem IP), api.mycompany.com:80
, api.mycompany.com:443
i test.mycompany.com:80
.
Router w VM2 udostępnia api.mycompany.com:80
(tę samą nazwę i port co w VM1).
System operacyjny hosta fizycznego może mieć zaporę sieciową. W takim przypadku musisz skonfigurować zaporę sieciową tak, aby przekazywała ruch TCP dla portów widocznych w interfejsach wirtualnych (111.111.111.111:{80, 443}
i 111.111.111.222:80
). Ponadto system operacyjny każdej maszyny wirtualnej może mieć własną zaporę sieciową w interfejsie eth0. Muszą one też zezwalać na połączenia z portami 80 i 443.
Ścieżka bazowa to trzeci komponent kierowania wywołań interfejsu API do różnych wdrożonych serwerów proxy interfejsu API. Pakiety proxy serwera API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki podstawowe. Na przykład jedną ścieżkę podstawową można zdefiniować jako http://api.mycompany.com:80/
, a inną jako http://api.mycompany.com:80/salesdemo
.
W takim przypadku potrzebujesz systemu równoważenia obciążenia lub dyrektora ruchu, który podzieli ruch http://api.mycompany.com:80/ między 2 adresy IP (111.111.111.111
w VM1 i 111.111.111.222
w VM2). Ta funkcja jest charakterystyczna dla Twojej instalacji i jest konfigurowana przez lokalną grupę sieciową.
Ścieżka bazowa jest ustawiana podczas wdrażania interfejsu API. Z przykładu powyżej możesz wdrożyć 2 interfejsy API – mycompany
i testmycompany
– w organizacji mycompany-org
z hostem wirtualnym, który ma alias hosta api.mycompany.com
i port ustawiony na 80
. Jeśli nie zadeklarujesz ścieżki bazowej we wdrożeniu, router nie będzie wiedział, do którego interfejsu API wysłać żądania przychodzące.
Jeśli jednak wdrożysz interfejs testmycompany
za pomocą podstawowego adresu URL /salesdemo
, użytkownicy będą mieli do niego dostęp przez http://api.mycompany.com:80/salesdemo
. Jeśli wdrażasz interfejs API w interfejsie API firmy o podstawowym adresie URL /
, użytkownicy uzyskują dostęp do interfejsu API za pomocą adresu URL http://api.mycompany.com:80/
.
Wymagania dotyczące portu brzegowego
Potrzeba zarządzania zaporą sieciową wykracza poza sam host wirtualny. Zapory sieciowe maszyn wirtualnych i hostów fizycznych muszą zezwalać na ruch między portami wymaganymi przez komponenty.
Poniższa ilustracja przedstawia wymagania dotyczące portów każdego komponentu Edge:
Uwagi na tym schemacie:
- * Aby można było korzystać z routera obsługującego wiadomości, port 8082 musi być otwarty tylko podczas konfiguracji routera TLS/SSL między routerem a procesorem wiadomości. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem wiadomości, port domyślny 8082 będzie musiał być otwarty w edytorze wiadomości, aby zarządzać komponentem, ale router nie wymaga do niego dostępu.
- Porty poprzedzone symbolem „M” to porty używane do zarządzania komponentem. Muszą być otwarte w komponencie i muszą być otwarte w komponencie, aby miał dostęp do serwera zarządzania.
- Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor wiadomości, interfejs użytkownika, Postgres i Qpid.
- Podmiot przetwarzający wiadomości musi otworzyć port 4528 jako port zarządzania. Jeśli masz wiele podmiotów przetwarzających wiadomości, każdy z nich musi mieć dostęp do siebie przez port 4528 (wskazuje to pętla na diagramie powyżej portu 4528). Jeśli masz wiele centrów danych, port musi być dostępny dla wszystkich podmiotów przetwarzających wiadomości we wszystkich centrach danych.
- Nie jest to wymagane, ale możesz otworzyć port 4527 na routerze, aby uzyskać dostęp do dowolnego procesora wiadomości. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawić się komunikaty o błędach.
- Router musi mieć port 4527 jako port zarządzania. Jeśli masz wiele routerów, muszą one mieć dostęp do siebie przez port 4527 (wskazuje to pętla na schemacie powyżej dotyczący portu 4527 na routerze).
- Interfejs brzegowy wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API, aby można było obsługiwać przycisk Wyślij w narzędziu do śledzenia.
- Serwer zarządzania wymaga dostępu do portu JMX w węzłach Cassandra.
- Dostęp do portów JMX można skonfigurować tak, aby wymagały nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule Jak monitorować.
- Opcjonalnie możesz skonfigurować dostęp TLS/SSL do określonych połączeń, które mogą używać różnych portów. Więcej informacji znajdziesz na stronie TLS/SSL.
- Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji master-standby, musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH. Opcjonalnie możesz otworzyć porty w poszczególnych węzłach, aby umożliwić dostęp przez SSH.
- Możesz skonfigurować serwer zarządzania i interfejs użytkownika Edge do wysyłania e-maili przez zewnętrzny serwer SMTP. W takim przypadku musisz upewnić się, że serwer zarządzania i interfejs użytkownika mają dostęp do niezbędnego portu na serwerze SMTP. W przypadku protokołu SMTP innego niż Numer TLS numer portu to zwykle 25. W przypadku protokołu SMTP obsługującego protokół TLS jest często 465, ale skontaktuj się z dostawcą SMTP.
W tabeli poniżej widoczne są porty, które trzeba otworzyć w zaporach sieciowych według komponentu Edge:
Komponent | Port | Opis |
---|---|---|
Standardowe porty HTTP | 80 443 | HTTP oraz inne porty używane na potrzeby hostów wirtualnych |
Serwer zarządzania | 8080 | Port wywołań interfejsu API zarządzania Edge. Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor wiadomości, interfejs użytkownika, Postgres i Qpid. |
1099 | Port JMX | |
4526 | Rozproszona pamięć podręczna i wywołania zarządzania | |
Interfejs zarządzania | 9000 | Port dostępu do przeglądarki do interfejsu zarządzania |
procesor komunikatów | 8998 | Port procesora Wiadomości do komunikacji z routera |
8082 |
Domyślny port zarządzania procesorem wiadomości. Musi być otwarty w komponencie do uzyskania przez serwer zarządzania. Jeśli skonfigurujesz TLS/SSL między routerem a procesorem wiadomości, wykorzystywany przez router do kontroli stanu tego procesora. |
|
1101 | Port JMX | |
4528 | Rozproszona pamięć podręczna i wywołania zarządzania między podmiotami przetwarzającymi wiadomości oraz komunikacja z routera i serwera zarządzania | |
Router | 8081 | Domyślny port zarządzania routerem, który musi być otwarty w komponencie na potrzeby dostępu do serwera zarządzania. |
4527 | Rozproszona pamięć podręczna i wywołania zarządzania | |
15999 |
Port kontroli stanu. System równoważenia obciążenia wykorzystuje ten port do określania, czy router jest dostępny. Aby uzyskać stan routera, system równoważenia obciążenia wysyła żądanie do portu 15999: curl -v http://routerIP:15999/v1/servers/self/reachable Jeśli router jest osiągalny, żądanie zwraca protokół 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 znajdziesz na stronie Testowanie instalacji na porcie 59001. |
|
Prowadnica ogrodu zoologicznego | 2181 | Używany przez inne komponenty, takie jak serwer zarządzania, router, procesor wiadomości itd. |
2888, 3888 | Używany wewnętrznie przez ZooKeeper dla klastra ZooKeeper (znanego jako zespół ZooKeeper) | |
Cassandra | 7000, 9042, 9160 | Apache Cassandra porty do komunikacji między węzłami Cassandra i dostępu do innych komponentów Edge. |
7199 | Port JMX. Musi być otwarta dla serwera zarządzania. | |
Qpy | 5672 | Służy do komunikacji z routera i procesora wiadomości do serwera Qpid |
8083 | Domyślny port zarządzania na serwerze Qpid i musi być otwarty w komponencie dostępnym dla serwera zarządzania. | |
1102 | Port JMX | |
4529 | Rozproszona pamięć podręczna i wywołania zarządzania | |
Postgres | 5432 | Służy do komunikacji z serwera Qpid/Server Management API do Postgres |
8084 | Domyślny port zarządzania na serwerze Postgres, który musi być otwarty w komponencie na potrzeby dostępu przez serwer zarządzania. | |
1103 | Port JMX | |
4530 | Rozproszona pamięć podręczna i wywołania zarządzania | |
22 | Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji master-standby, musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH. | |
LDAP | 10389 | OpenLDAP |
Dokumenty inteligentne | 59002 | Port na routerze Edge, do którego wysyłane są żądania stron SmartDokumenty. |
Następna tabela zawiera te same porty (wyświetlone liczbowo) z komponentem źródłowym i docelowym:
Numer portu | Cel | Komponent źródłowy | Komponent Miejsce docelowe |
---|---|---|---|
virtual_host_port | HTTP oraz wszystkie inne porty, których używasz do wywoływania połączeń przez interfejs 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) | Odbiornik na routerze wiadomości |
1099 do 1103 | Zarządzanie JMX | Klient JMX | Serwer zarządzania (1099) Procesor wiadomości (1101) Serwer Qpid (1102) Serwer Postgres (1103) |
2181 | Kontakt z klientem Zookeeper | serwer zarządzania router procesor wiadomości serwer Qpid serwer Postgres |
Ogród zoologiczny |
2888 i 3888 | Zarządzanie węzłami Zookeeper | Ogród zoologiczny | Ogród zoologiczny |
4526 | Port zarządzania RPC | Serwer zarządzania | Serwer zarządzania |
4527 | Port zarządzania RPC na potrzeby rozproszonych połączeń pamięci podręcznej i zarządzania oraz na potrzeby komunikacji między routerami | Routing serwera zarządzania |
Router |
4528 | W przypadku rozproszonych wywołań pamięci podręcznej między podmiotami przetwarzającymi wiadomości oraz do komunikacji z routera | Serwer zarządzania router Procesor wiadomości |
procesor komunikatów |
4529 | Port zarządzania RPC do rozproszonych wywołań pamięci podręcznej i zarządzania | Serwer zarządzania | Serwer Qpid |
4530 | Port zarządzania RPC do rozproszonych wywołań pamięci podręcznej i 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 wiadomości |
Serwer Qpid |
7000 | Komunikacja między węzłami Cassandra | Cassandra | Inny węzeł Cassandra |
7199 | Zarządzanie JMX Musi być otwarty, aby serwer zarządzania mógł uzyskać dostęp do węzła Cassandra. | Klient JMX | Cassandra |
8080 | Port zarządzania interfejsami API | Klienty interfejsu API zarządzania | Serwer zarządzania |
8081 do 8084 |
Porty interfejsu Component API służące do wysyłania żądań bezpośrednio do poszczególnych komponentów. Każdy komponent otwiera inny port. Dokładny używany port zależy od konfiguracji, ale musi być otwarty w komponencie na potrzeby dostępu do serwera zarządzania |
Klienty interfejsu API zarządzania | Router (8081) Procesor wiadomości (8082) Serwer Qpid (8083) Postgres Server (8084) |
8998 | Komunikacja między routerem a firmą obsługującą wiadomości | Router | procesor komunikatów |
9000 | Domyślny port interfejsu zarządzania urządzeniami mobilnymi | Przeglądarka | Serwer interfejsu zarządzania |
9042 | Natywna transportowa CQL | Router Procesor wiadomości Serwer zarządzania |
Cassandra |
9160 | Klient używany Cassandra | Router Procesor wiadomości Serwer zarządzania |
Cassandra |
10389 | Port LDAP | Serwer zarządzania | OpenLDAP |
15999 | Port kontroli stanu. System równoważenia obciążenia wykorzystuje ten port do określania, 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 stron SmartDocuments | Dokumenty inteligentne | 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, zapora sieciowa może przekroczyć limit czasu połączenia. Procesor wiadomości nie jest jednak przeznaczony do ponownego nawiązania 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 będzie angażowana we wdrażanie tych komponentów.
Jeśli zapora sieciowa między routerem a podmiotami przetwarzającymi wiadomości ma ustawioną limit czasu oczekiwania TCP, zalecamy wykonanie tych czynności:
- Ustaw
net.ipv4.tcp_keepalive_time = 1800
w ustawieniach sysctl w systemie Linux, gdzie wartość 1800 powinna być niższa niż limit czasu bezczynności TCP zapory sieciowej. To ustawienie powinno utrzymywać połączenie w stanie ustalonym, aby zapora sieciowa nie rozłączała połączenia. - We wszystkich procesorach wiadomości zmień
/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
- Uruchom ponownie procesor wiadomości:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- We wszystkich routerach zmień właściwość
/opt/apigee/customer/application/router.properties
, by 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 zainstalujesz 12 konfiguracji klastrów z 2 centrami danych, upewnij się, że węzły w tych dwóch centrach danych mogą komunikować się przez porty podane poniżej:
Wymagania dotyczące portu BaaS API
Jeśli zdecydujesz się zainstalować BaaS API, musisz dodać komponenty BaaS Stack i API BaaS Portal. Te komponenty korzystają z portów widocznych na ilustracji poniżej:
Uwagi na tym schemacie:
- Interfejs API BaaS nigdy nie wysyła żądań bezpośrednio do węzła stosu BaaS. Gdy deweloper loguje się w portalu, aplikacja jest pobierana do przeglądarki. Aplikacja Portal uruchomiona w przeglądarce wysyła żądania do węzłów stosu BaaS.
- Instalacja produkcyjna BaaS API używa systemu równoważenia obciążenia między węzłami portalu BaaS Portal i węzłami BaaS Stack. Podczas konfigurowania portalu i przy wywoływaniu interfejsu BaaS API musisz podać adres IP lub nazwę DNS systemu równoważenia obciążenia, a nie węzłów stosu.
- Wszystkie węzły stosu muszą mieć port 2551, aby mieć dostęp z pozostałych węzłów stosu (wskazuje to pętla na diagramie powyżej dla portu 2551 w węzłach stosu). Jeśli masz wiele centrów danych, port musi być dostępny ze wszystkich węzłów stosu we wszystkich centrach danych.
- Musisz skonfigurować wszystkie węzły stosu Baas, aby wysyłały e-maile przez zewnętrzny serwer SMTP. W przypadku serwera SMTP innego niż TLS numer portu to zwykle 25. W przypadku protokołu SMTP obsługującego protokół TLS jest często 465, ale skontaktuj się z dostawcą SMTP.
- Węzły Cassandra mogą być używane do obsługi BaaS API lub mogą być udostępniane brzegowemu.
W tabeli poniżej znajdziesz domyślne porty, które trzeba otworzyć w zaporach sieciowych według komponentów:
Komponent | Port | Opis |
---|---|---|
Interfejs API BaaS | 9000 | Port interfejsu użytkownika BaaS API |
Stos BaaS API | 8080 | Port, na który trafiają żądania API |
2551 |
Port do komunikacji między wszystkimi węzłami stosu. Muszą być dostępne dla wszystkich innych węzłów Stack w kancie danych. Jeśli masz wiele centrów danych, port musi być dostępny ze wszystkich węzłów stosu we wszystkich centrach danych. |
|
Elastyczne wyszukiwanie | 9200–9400 | Do komunikacji ze stosem interfejsów BaaS API i do komunikacji między węzłami ElasticSearch |
Licencjonowanie
Każda instalacja Edge wymaga unikalnego pliku licencji uzyskanego od Apigee. Podczas instalacji serwera zarządzania musisz podać ścieżkę do pliku licencji, na przykład /tmp/license.txt.
Instalator kopiuje plik licencji do /opt/apigee/customer/conf/license.txt
.
Jeśli plik licencji jest prawidłowy, serwer zarządzania sprawdza datę ważności i dopuszczalną liczbę procesorów (MP). Jeśli dowolne z ustawień licencji wygasło, logi znajdziesz w tej lokalizacji: /opt/apigee/var/log/edge-management-server/logs
.
W takim przypadku skontaktuj się z zespołem pomocy Apigee Edge, aby uzyskać szczegółowe informacje na temat migracji.
Jeśli nie masz jeszcze licencji, skontaktuj się z działem sprzedaży Apigee.