Wymagania sprzętowe
Aby zapewnić wysoką dostępność infrastruktury w środowisku produkcyjnym, musisz spełnić te minimalne wymagania sprzętowe.
W tym filmie znajdziesz ogólne wskazówki dotyczące rozmiarów instalacji:
W tabelach poniżej znajdziesz minimalne wymagania sprzętowe dotyczące komponentów instalacji w przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji.
W tych tabelach wymagania dotyczące dysku twardego są podane dodatkowo do miejsca na dysku twardym wymaganego przez system operacyjny. W zależności od aplikacji i ruchu w sieci instalacja może wymagać więcej lub mniej zasobów niż wymienione poniżej.
Element instalacji | Pamięć RAM | CPU | Minimalny dysk twardy |
---|---|---|---|
Cassandra | 16 GB | 8-rdzeniowy | Miejsce na dane o pojemności 250 GB na dysku SSD obsługującym 2000 IOPS |
Przetwarzanie wiadomości/Router na tym samym komputerze | 16 GB | 8-rdzeniowy | 100 GB |
Message Processor (samodzielny) | 16 GB | 8-rdzeniowy | 100 GB |
Router (samodzielny) | 16 GB | 8-rdzeniowy | 100 GB |
Analytics – Postgres/Qpid na tym samym serwerze | 16 GB* | 8-rdzeniowy* | 500 GB–1 TB** pamięci sieciowej***, najlepiej z SSD w podstawie, obsługująca 1000 IOPS lub więcej* |
Statystyki – serwer główny lub zapasowy Postgres (samodzielny) | 16 GB* | 8-rdzeniowy* | 500 GB–1 TB** pamięci sieciowej***, najlepiej z SSD w podstawie, obsługująca 1000 IOPS lub więcej* |
Analytics – samodzielny Qpid | 8 GB | 4-rdzeniowy | 30–50 GB miejsca na dane na dysku SSD
Domyślny rozmiar kolejki Qpid to 1 GB, ale można go zwiększyć do 2 GB. Jeśli potrzebujesz więcej mocy obliczeniowej, dodaj kolejne węzły Qpid. |
OpenLDAP/UI/Management Server | 8 GB | 4-rdzeniowy | 60 GB |
Serwer interfejsu użytkownika lub serwer zarządzania | 4 GB | 2-rdzeniowy | 60 GB |
OpenLDAP (samodzielny) | 4 GB | 2-rdzeniowy | 60 GB |
* Dostosuj wymagania dotyczące systemu Postgres na podstawie przepustowości:
** Wartość dysku twardego Postgresa jest określana na podstawie domyślnych statystyk rejestrowanych przez Edge. Jeśli do danych analitycznych dodasz wartości niestandardowe, należy je odpowiednio zwiększyć. Aby oszacować wymaganą ilość miejsca na dane, użyj tej formuły:
Na przykład:
*** Network Storage jest zalecany w przypadku bazy danych Postgres, ponieważ:
|
Poniżej znajdziesz listę wymagań sprzętowych, jeśli chcesz zainstalować usługi zarabiania (nieobsługiwane w przypadku instalacji All-in-One):
Komponent z zarabianiem | Pamięć RAM | CPU | Dysk twardy |
---|---|---|---|
Serwer zarządzający (z usługami umożliwiającymi generowanie przychodu) | 8 GB | 4-rdzeniowy | 60 GB |
Analytics – Postgres/Qpid na tym samym serwerze | 16 GB | 8-rdzeniowy | 500 GB – 1 TB pamięci sieciowej, najlepiej z dyskiem SSD w tle, obsługującym 1000 IOPS lub więcej, albo zastosuj regułę z tabeli powyżej. |
Statystyki – serwer główny lub zapasowy serwer samodzielny Postgres | 16 GB | 8-rdzeniowy | 500 GB – 1 TB pamięci sieciowej, najlepiej z dyskiem SSD w tle, obsługującym 1000 IOPS lub więcej, albo zastosuj regułę z tabeli powyżej. |
Analytics – samodzielny Qpid | 8 GB | 4-rdzeniowy | 40–500 GB miejsca na dysku lokalnym (SSD lub szybki dysk twardy)
W przypadku instalacji o wydajności przekraczającej 250 TPS zalecamy dysk twardy z lokalnym miejscem na dane obsługującym 1000 IOPS. |
Wymagania dotyczące przepustowości sieci Cassandra
Cassandra używa protokołu szepta do wymiany informacji z innymi węzłami na temat topologii sieci. Wykorzystanie protokołu Gossip w połączeniu z rozproszoną naturą Cassandra (która wymaga komunikacji z wiele węzłami w celu wykonywania operacji odczytu i zapisu) powoduje znaczny transfer danych w sieci.
Cassandra wymaga minimalnej przepustowości sieci 1 Gb/s na węzeł. W przypadku instalacji produkcyjnych zalecamy większą przepustowość.
Maksymalne opóźnienie lub opóźnienie w 99. percentylu w usłudze Cassandra powinno być mniejsze niż 100 ms.
Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm
Te instrukcje instalacji i dołączone pliki instalacyjne zostały przetestowane w systemach operacyjnych i oprogramowaniu innych firm wymienionych w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.
Warunek wstępny: włącz repozytorium EPEL
Przed rozpoczęciem instalacji upewnij się, że repozytorium EPEL (Extra Packages for Enterprise Linux) jest włączone. W zależności od wersji systemu operacyjnego użyj tych poleceń:
- W przypadku Red Hat/CentOS/Oracle 8.X:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo rpm -ivh epel-release-latest-8.noarch.rpm
- W przypadku Red Hat/CentOS/Oracle 9.X:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo rpm -ivh epel-release-latest-9.noarch.rpm
Java
Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja Java 1.8. Obsługiwane wersje JDK są wymienione w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.
Upewnij się, że zmienna środowiskowa JAVA_HOME
wskazuje na katalog główny JDK dla użytkownika przeprowadzającego instalację.
SELinux
W zależności od ustawień SELinux przeglądarka Edge może mieć problemy z instalowaniem i uruchamianiem komponentów Edge. W razie potrzeby możesz wyłączyć SELinux lub ustawić go w trybie permisywnym podczas instalacji, a następnie ponownie go włączyć. Więcej informacji znajdziesz w artykule Instalowanie narzędzia apige-setup w Edge.
Tworzenie konta użytkownika „apigee”
Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki Edge są własnością konta „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge działają jako użytkownik „apigee”. W razie potrzeby możesz uruchamiać komponenty jako inny użytkownik.
Katalog instalacji
Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee
. Nie możesz zmienić lokalizacji tego katalogu. Nie możesz zmienić tego katalogu, ale możesz utworzyć symboliczny link do mapy /opt/apigee
do innego miejsca, jak opisano w sekcji Tworzenie symbolicznego linku z katalogu /opt/apigee.
W instrukcjach w tym przewodniku katalog instalacyjny jest oznaczony jako /opt/apigee
.
Tworzenie symbolicznego linku z katalogu /opt/apigee
Zanim utworzysz symboliczny link, musisz najpierw utworzyć użytkownika i grupę o nazwie „apigee”. Jest to ta sama grupa i ten sam użytkownik, którzy zostali utworzeni przez instalator Edge.
Aby utworzyć symboliczny link, wykonaj te czynności przed pobraniem pliku bootstrap_4.53.00.sh. Wszystkie te czynności musisz wykonać jako użytkownik 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 symboliczny link z katalogu
/opt/apigee
do wybranego katalogu źródeł:ln -Ts /srv/myInstallDir /opt/apigee
gdzie /srv/myInstallDir to żądana lokalizacja plików Edge.
- Zmień właściciela katalogu / root i skrótu do katalogu / root na użytkownika „apigee”:
chown -h apigee:apigee /srv/myInstallDir /opt/apigee
Ustawienie Sieć
Firma Apigee zaleca sprawdzenie ustawień sieci przed instalacją. Instalator zakłada, że wszystkie maszyny mają stałe adresy IP. Aby sprawdzić ustawienie
hostname
zwraca nazwę komputera.hostname -i
zwraca adres IP nazwy hosta, który może być adresowany z innych maszyn.
W zależności od typu i wersji systemu operacyjnego może być konieczne zmodyfikowanie wartości parametru /etc/hosts
i /etc/sysconfig/network
, jeśli nazwa hosta nie jest prawidłowo skonfigurowana. Więcej informacji znajdziesz w dokumentacji do konkretnego systemu operacyjnego.
Jeśli serwer ma kilka kart interfejsu, polecenie „hostname -i” zwraca listę adresów IP rozdzielonych spacjami. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, który może nie być poprawny w każdej sytuacji. Możesz też ustawić tę właściwość w pliku konfiguracji instalacji:
ENABLE_DYNAMIC_HOSTIP=y
Gdy ta właściwość ma wartość „y”, program instalacyjny wyświetli prompt z prośbą o wybranie adresu IP, którego chcesz użyć w ramach instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji pliku konfiguracyjnego Edge.
Opakowania TCP
Opakowania TCP mogą blokować komunikację niektórych portów i wpływać na instalację OpenLDAP, Postgres i Cassandra. Na tych węzłach sprawdź /etc/hosts.allow
i /etc/hosts.deny
, aby upewnić się, że nie ma żadnych ograniczeń portów w wymaganych portach OpenLDAP, Postgres i Cassandra.
iptables
Sprawdź, czy nie ma zasad iptables, które uniemożliwiają połączenie między węzłami na wymaganych portach usługi Edge. W razie potrzeby możesz zatrzymać iptables podczas instalacji za pomocą tego polecenia:
sudo/etc/init.d/iptables stop
Dostęp do katalogu
Tabela poniżej zawiera katalogi na węzłach Edge, które mają specjalne wymagania dotyczące procesów Edge:
Usługa | Katalog | Opis |
---|---|---|
Router | /etc/rc.d/init.d/functions |
Router Edge Router korzysta z routera Nginx i wymaga uprawnień do odczytu do usługi Jeśli Twój proces bezpieczeństwa wymaga ustawienia uprawnień w Aby przyznać uprawnienia do odczytu do |
Zookeeper | /dev/random |
Biblioteka klienta Zookeeper wymaga dostępu tylko do odczytu do generatora liczb losowych.
/dev/random Jeśli usługa /dev/random jest zablokowana na odczyt, usługa Zookeeper może się nie uruchomić. |
Cassandra
Wszystkie węzły Cassandra muszą być połączone z pierścieniem. Cassandra przechowuje kopie danych na wielu węzłach, aby zapewnić niezawodność i odporność na błędy. Strategia replikowania dla każdego klucza przestrzeni Edge określa węzły Cassandra, na których znajdują się kopie. Więcej informacji znajdziesz w artykule Informacje o skalowaniu replikacji i poziomie spójności w Cassandra.
Cassandra automatycznie dostosowuje rozmiar stosu Java na podstawie dostępnej pamięci. W przypadku spadku wydajności lub dużego zużycia pamięci zapoznaj się z artykułem Dostosowanie zasobów Java.
Po zainstalowaniu Edge for Private Cloud możesz sprawdzić, czy Cassandra jest prawidłowo skonfigurowana, sprawdzając plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml
. Upewnij się na przykład, że skrypt instalacji Edge for Private Cloud ustawia te właściwości:
cluster_name
initial_token
partitioner
seeds
listen_address
rpc_address
snitch
Baza danych PostgreSQL
Po zainstalowaniu przeglądarki Edge możesz dostosować te ustawienia bazy danych PostgreSQL na podstawie ilości dostępnej pamięci RAM 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:
- Zmodyfikuj plik postgresql.properties:
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.
- Zrestartuj bazę danych PostgreSQL:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
Konfiguracja języka w Rocky 9.X
Jeśli używasz Rocky 9.X, upewnij się, że w ustawieniach języka w całym systemie masz LANG=en_US.utf8
. Aby to skonfigurować, uruchom te polecenia:
dnf -y -q install langpacks-en localectl set-locale LANG=en_US.utf8 reboot
Ograniczenia systemu
Sprawdź, czy w węzłach Cassandra i Message Processor ustawione są te limity systemu:
- W węzłach Cassandra ustaw miękkie i twarde limity memlock, nofile i adresu przestrzeni (as) dla użytkownika instalacji (domyślnie „apigee”) w
/etc/security/limits.d/90-apigee-edge-limits.conf
, jak pokazano poniżej:apigee soft memlock unlimited apigee hard memlock unlimited apigee soft nofile 32768 apigee hard nofile 65536 apigee soft as unlimited apigee hard as unlimited apigee soft nproc 32768 apigee hard nproc 65536
- Na węzłach procesora wiadomości ustaw maksymalną liczbę otwartych deskryptorów plików na 64 K w
/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. Jeśli na przykład masz otwartą dużą liczbę plików tymczasowych.
Jeśli w Routerze lub przetwarzaczu wiadomości pojawi się ten komunikat o błędzie:
system.log
, limity dotyczące opisu pliku mogą być ustawione zbyt nisko:"java.io.IOException: Too many open files"
Aby sprawdzić limity użytkowników, uruchom:
# su - apigee $ ulimit -n 100000
Jeśli po ustawieniu limitów opisu pliku na
100000
nadal dochodzi do przekroczenia limitu otwartych plików, prześlij zgłoszenie do zespołu pomocy Apigee Edge, aby uzyskać dalszą pomoc.
Usługi zabezpieczeń sieciowych (NSS)
Network Security Services (NSS) to zestaw bibliotek, które ułatwiają tworzenie aplikacji klienckich i serwerowych z zabezpieczeniami. Upewnij się, że masz zainstalowaną bibliotekę 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 na stronie RedHat.
Wyłączanie wyszukiwania DNS w IPv6 podczas korzystania z NSCD (Name Service Cache Daemon)
Jeśli masz zainstalowany i włączony NSCD (Name Service Cache Daemon), procesory wiadomości przeprowadzają 2 wyszukiwania DNS: jedno dla IPv4 i drugie dla IPv6. Jeśli używasz NSCD, wyłącz wyszukiwanie DNS w protokole IPv6.
Aby wyłączyć wyszukiwanie DNS w IPv6:
- W każdym węźle usługi Message Processor edytuj element
/etc/nscd.conf
- Ustaw tę właściwość:
enable-cache hosts no
Wyłączanie IPv6 w RHEL 8 i nowszych
Jeśli instalujesz Edge na RHEL 8 lub nowszej wersji na Google Cloud Platform, musisz wyłączyć IPv6 na wszystkich węzłach Qpid.
Instrukcje dotyczące wyłączania IPv6 znajdziesz w dokumentacji dostarczonej przez producenta systemu operacyjnego. Odpowiednie informacje znajdziesz na przykład w dokumentacji Red Hat Enterprise Linux.
Narzędzia
Instalator używa tych narzędzi UNIX w wersji standardowej, jaką udostępnia EL5 lub EL6.
awk |
expr |
libxslt |
obr./min |
rozpakuj |
basename |
grep |
lua-socket |
rpm2cpio |
useradd |
bash |
nazwa hosta |
ls |
sed |
wc |
bc |
id |
net-tools |
sudo |
wget |
curl |
libaio |
perl (z procps) |
smoła |
xerces-c |
cyrus-sasl | libdb4 | pgrep (z procps) | tr | mniam |
data |
libdb-cxx |
ps |
identyfikator UUID |
chkconfig |
dirname | libibverbs | pwd | uname | |
echo | librdmacm | python |
Synchronizacja czasu
Apigee zaleca zsynchronizowanie czasu na serwerach. Jeśli nie masz jeszcze skonfigurowanego serwera, możesz użyć narzędzia ntpdate
lub podobnego, aby sprawdzić, czy serwery są zsynchronizowane czasowo. Aby zainstalować narzędzie, możesz na przykład użyć polecenia yum install ntp
lub podobnego. Jest to szczególnie przydatne w przypadku replikowania konfiguracji OpenLDAP. Pamiętaj, że strefa czasowa serwera powinna być ustawiona na UTC.
openldap 2.4
Instalacja lokalna wymaga wersji OpenLDAP 2.4, która jest zawarta w repozytorium apigee-thirdparty-opdk
. Aby ułatwić instalację, usuń bibliotekę openldap-compat
.
W przypadku instalacji z 13 hostami i instalacji z 12 hostami z 2 centrami danych wymagana jest replikacja OpenLDAP, ponieważ istnieje wiele węzłów hostujących OpenLDAP.
Zapory sieciowe i hosty wirtualnych
Termin virtual
jest często nadużywany w branży IT, tak jak w przypadku wdrożenia Apigee Edge for Private Cloud i hostów wirtualnych. Termin virtual
ma 2 podstawowe zastosowania:
- Maszyny wirtualne: nie jest to wymagane, ale niektóre wdrożenia korzystają z technologii maszyn wirtualnych do tworzenia odizolowanych serwerów dla swoich komponentów Apigee. Hosty maszyn wirtualnych, podobnie jak hostów fizycznych, mogą mieć interfejsy sieciowe i zapory sieciowe.
- Hosty wirtualne: punkty końcowe internetowe, analogiczne do hosta wirtualnego Apache.
Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się one od siebie aliasem hosta lub portem interfejsu).
Na przykład na jednym serwerze fizycznym A
mogą działać 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że maszyna wirtualna „VM1” udostępnia wirtualny interfejs Ethernet o nazwie „eth0” wewnątrz maszyny wirtualnej i przypisuje jej adres IP 111.111.111.111
za pomocą mechanizmu wirtualizacji lub serwera DHCP sieci. Załóżmy też, że maszyna wirtualna „VM2” udostępnia wirtualny interfejs Ethernet o nazwie „eth0” i przypisuje jej adres IP 111.111.111.222
.
Router Apigee może być uruchomiony na obu maszynach wirtualnych. Routery udostępniają punkty końcowe hosta wirtualnego w taki sposób:
Router Apigee w VM1 udostępnia 3 hosty wirtualnych na interfejsie eth0 (który ma konkretny adres IP): api.mycompany.com:80
, api.mycompany.com:443
i test.mycompany.com:80
.
Router w maszynie wirtualnej 2 udostępnia adres api.mycompany.com:80
(ta sama nazwa i port co maszyna wirtualna 1).
System operacyjny fizycznego hosta może mieć zaporę sieciową. W takim przypadku musi ona przepuszczać ruch TCP na porty udostępnione na wirtualnych interfejsach (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ę na interfejsie eth0, która również musi zezwalać na połączenia na porty 80 i 443.
Ścieżka podstawowa to trzeci element biorący udział w przekierowywaniu wywołań interfejsu API do różnych zaimplementowanych przez Ciebie serwerów proxy interfejsu API. Pakiety zastępcze interfejsu API mogą korzystać z tego samego punktu końcowego, jeśli mają różne ścieżki podstawowe. Na przykład jeden ścieżka podstawowa może być zdefiniowana jako http://api.mycompany.com:80/
, a druga jako http://api.mycompany.com:80/salesdemo
.
W takim przypadku potrzebujesz systemu równoważenia obciążenia lub usługi kierowania ruchem, która rozdziela ruch http://api.mojafirma.com:80/ między 2 adresami IP (111.111.111.111
na VM1 i 111.111.111.222
na VM2). Ta funkcja jest specyficzna dla Twojej instalacji i jest konfigurowana przez lokalną grupę sieci.
Ścieżka podstawowa jest ustawiana podczas wdrażania interfejsu API. Z powyższego przykładu wynika, że możesz wdrożyć 2 interfejsy API, mycompany
i testmycompany
, dla organizacji mycompany-org
z hostem wirtualnym o aliasie hosta api.mycompany.com
i portem 80
. Jeśli nie zadeklarujesz ścieżki podstawowej w wdrożeniu, router nie będzie wiedzieć, do którego interfejsu API ma wysyłać przychodzące żądania.
Jeśli jednak wdrożesz interfejs API testmycompany
z podstawowym adresem URL /salesdemo
, użytkownicy będą uzyskiwać dostęp do tego interfejsu API za pomocą adresu http://api.mycompany.com:80/salesdemo
. Jeśli wdrożesz 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/
.
Licencjonowanie
Każda instalacja Edge wymaga unikalnego pliku licencji, który należy uzyskać od Apigee. Podczas instalowania serwera zarządzania musisz podać ścieżkę do pliku licencji, np. /tmp/license.txt.
Instalator kopiuje plik licencji do folderu /opt/apigee/customer/conf/license.txt
.
Jeśli plik licencji jest prawidłowy, serwer zarządzania weryfikuje datę ważności i dozwoloną liczbę procesorów wiadomości. Jeśli któreś z ustawień licencji wygasło, dzienniki znajdziesz w tym miejscu: /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 zespołem sprzedaży Apigee.