Wymagania dotyczące instalacji

Wymagania sprzętowe

Aby infrastruktura o wysokiej dostępności działała w środowisku produkcyjnym, musisz spełnić te minimalne wymagania sprzętowe.

Ten film zawiera ogólne wskazówki dotyczące określania rozmiaru instalacji:

W tabelach poniżej znajdziesz minimalne wymagania sprzętowe dotyczące komponentów instalacji we wszystkich scenariuszach 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.

bytes of storage needed =
  (# bytes of analytics data/request) *
  (requests/second) *
  (seconds/hour) *
  (hours of peak usage/day) *
  (days/month) *
  (months of data retention)

(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 of storage needed

Poniżej znajdziesz wymagania sprzętowe, które musisz spełnić, jeśli chcesz zainstalować usługi zarabiania (nieobsługiwane w przypadku instalacji All-in-One):

Wymagania dotyczące przepustowości sieci Cassandra

Cassandra używa protokołu Gossip do wymiany informacji o topologii sieci z innymi węzłami. Użycie protokołu Gossip w połączeniu z rozproszonym charakterem bazy danych Cassandra, który obejmuje komunikację z wieloma węzłami w celu wykonywania operacji odczytu i zapisu, powoduje znaczne przesyłanie danych przez sieć.

Cassandra wymaga minimalnej przepustowości sieci wynoszącej 1 Gb/s na węzeł. W przypadku instalacji produkcyjnych zalecana jest większa przepustowość.

Maksymalne opóźnienie lub opóźnienie na poziomie 99 percentyla w przypadku systemu Cassandra powinno wynosić poniżej 100 milisekund.

Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm

Te instrukcje instalacji i dostarczone pliki instalacyjne zostały przetestowane w systemach operacyjnych i oprogramowaniu innych firm wymienionych w artykule Obsługiwane oprogramowanie i obsługiwane wersje.

Wymaganie wstępne: włącz repozytorium EPEL

Zanim przejdziesz do instalacji, upewnij się, że repozytorium EPEL (Extra Packages for Enterprise Linux) jest włączone. W przypadku systemów Red Hat, CentOS lub Oracle Linux 9.x użyj tych poleceń:

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ą musisz zainstalować na każdym komputerze obsługiwane wersje Java 17 i Java 21. Obsługiwane pakiety JDK są wymienione w artykule Obsługiwane oprogramowanie i obsługiwane wersje.

Upewnij się, że zmienna środowiskowa JAVA_HOME wskazuje katalog główny JDK użytkownika, który przeprowadza instalację.

SELinux

W zależności od ustawień SELinux Edge może napotkać problemy z instalacją i uruchamianiem komponentów Edge. W razie potrzeby możesz wyłączyć SELinux lub ustawić go w trybie permissive podczas instalacji, a po jej zakończeniu ponownie go włączyć. Więcej informacji znajdziesz w artykule Instalowanie narzędzia apigee-setup w Edge.

Tworzenie użytkownika „apigee”

Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki Edge należą do „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ć dowiązanie symboliczne, aby zmapować /opt/apigee na inną lokalizację, jak opisano w sekcji Tworzenie dowiązania symbolicznego z /opt/apigee.

W instrukcjach w tym przewodniku katalog instalacyjny jest 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 zostały utworzone przez instalator Edge.

Aby utworzyć dowiązanie symboliczne, przed pobraniem pliku bootstrap_4.54.00.sh wykonaj te czynności. Wszystkie te czynności musisz wykonać jako użytkownik root:

1. 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

2. Utwórz dowiązanie symboliczne z /opt/apigee do wybranego katalogu głównego instalacji:

   ln -Ts /srv/myInstallDir /opt/apigee

   /srv/myInstallDir to lokalizacja, w której chcesz zapisać pliki Edge.

3. Zmień własność katalogu głównego instalacji i dowiązania symbolicznego na użytkownika „apigee”:

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Ustawienie Sieć

Apigee zaleca sprawdzenie ustawień sieci przed instalacją. Instalator oczekuje, że wszystkie maszyny mają stałe adresy IP. Aby sprawdzić ustawienie, użyj tych poleceń:

• 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 plików /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta nie jest prawidłowo ustawiona. Więcej informacji znajdziesz w dokumentacji konkretnego systemu operacyjnego.

Jeśli serwer ma kilka kart interfejsu, polecenie „hostname -i” zwraca rozdzielaną spacjami listę adresów IP. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, który może nie być prawidłowy we wszystkich sytuacjach. Możesz też ustawić tę właściwość w pliku konfiguracji instalacji:

ENABLE_DYNAMIC_HOSTIP=y

Jeśli ta właściwość jest ustawiona na „y”, instalator prosi o wybranie adresu IP, który ma być używany w ramach instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w artykule Plik konfiguracji Edge.

TCP Wrappers

Otoki 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 ograniczeń dotyczących wymaganych portów OpenLDAP, Postgres i Cassandra.

iptables

Sprawdź, czy nie ma zasad iptables uniemożliwiających połączenie między węzłami na wymaganych portach Edge. W razie potrzeby możesz zatrzymać iptables podczas instalacji za pomocą polecenia:

sudo/etc/init.d/iptables stop

Dostęp do katalogu

W tabeli poniżej wymieniono katalogi w węzłach Edge, które mają specjalne wymagania dotyczące procesów Edge:

Cassandra

Wszystkie węzły Cassandra muszą być połączone z pierścieniem. Cassandra przechowuje repliki danych na wielu węzłach, aby zapewnić niezawodność i odporność na błędy. Strategia replikacji dla każdej przestrzeni kluczy Edge określa węzły Cassandra, w których umieszczane są repliki. Więcej informacji znajdziesz w artykule na temat współczynnika replikacji i poziomu spójności Cassandra.

Cassandra automatycznie dostosowuje rozmiar sterty Javy na podstawie dostępnej pamięci. Więcej informacji znajdziesz w artykule o dostrajaniu zasobów Javy w przypadku pogorszenia wydajności lub dużego zużycia pamięci.

Po zainstalowaniu Edge dla chmury prywatnej 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 instalacyjny Edge dla chmury prywatnej ustawia 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ć te ustawienia bazy danych PostgreSQL na podstawie 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:

1. Edytuj plik postgresql.properties:

   vi /opt/apigee/customer/application/postgresql.properties

   Jeśli plik nie istnieje, utwórz go.

2. Ustaw właściwości wymienione powyżej.
3. Zapisz zmiany.
4. Uruchom ponownie 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 regionalnych systemu jest skonfigurowany język 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

Upewnij się, że w węzłach Cassandra i procesora komunikatów ustawiono te limity systemowe:

• Na węzłach Cassandra ustaw miękkie i twarde limity memlock, nofile i przestrzeni adresowej (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

• W węzłach procesora komunikatów ustaw maksymalną liczbę otwartych deskryptorów plików na 64 K w pliku /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. Może się tak zdarzyć, jeśli na przykład masz otwartą dużą liczbę plików tymczasowych.

• Jeśli w routerze lub procesorze komunikatów system.log pojawi się ten błąd, limity deskryptorów plików mogą być ustawione zbyt nisko:

  "java.io.IOException: Too many open files"

  Limity użytkowników możesz sprawdzić, uruchamiając:

  # su - apigee
  $ ulimit -n
  100000
  

  Jeśli po ustawieniu limitów deskryptorów plików na 100000 nadal osiągasz limity otwartych plików, prześlij zgłoszenie do zespołu pomocy Apigee Edge, aby uzyskać dalszą pomoc.

Network Security Services (NSS)

Network Security Services (NSS) to zestaw bibliotek, które ułatwiają tworzenie aplikacji klienckich i serwerowych z obsługą zabezpieczeń. Upewnij się, że masz zainstalowaną wersję NSS 3.19 lub nowszą.

Aby sprawdzić bieżącą wersję:

yum info nss

Aby zaktualizować NSS:

yum update nss

Wyłączanie wyszukiwania DNS w IPv6 podczas korzystania z NSCD (Name Service Cache Daemon)

Jeśli masz zainstalowany i włączony demon NSCD (Name Service Cache Daemon), procesory komunikatów wykonują 2 wyszukiwania 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:

1. Na każdym węźle procesora komunikatów zmodyfikuj plik /etc/nscd.conf
2. 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 protokołu IPv6 znajdziesz w dokumentacji dostarczonej przez dostawcę systemu operacyjnego. Odpowiednie informacje znajdziesz na przykład w dokumentacji Red Hat Enterprise Linux.

Wymagania wstępne dotyczące systemu Amazon Linux

Przed wykonaniem nowej instalacji w systemie Amazon Linux 2023.9/2023.10/2023.11 lub uaktualnieniem z wersji 4.53.01 do 4.54.00 (w systemie Amazon Linux 2023.9/2023.10/2023.11) zmodyfikuj plik /etc/yum.repos.d/amazonlinux.repo. Sekcja zawierająca [amazonlinux] musi zawierać te elementy, aby pakiety były pobierane z apigee-thirdparty, a nie z Amazon:exclude=postgresql18,luajit*.

Narzędzia

Instalator używa tych narzędzi UNIX w wersji standardowej, które są dostarczane przez EL5 lub EL6.

Synchronizacja czasu

Apigee zaleca synchronizację czasu na serwerach. Jeśli nie jest jeszcze skonfigurowane, 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 jego odpowiednika. Jest to szczególnie przydatne w przypadku replikowania konfiguracji LDAP. Pamiętaj, że strefę czasową serwera należy ustawić na UTC.

Zapory sieciowe i hosty wirtualne

Termin virtual jest często nadużywany w branży IT, podobnie jak w przypadku wdrożenia Apigee Edge dla chmury prywatnej i hostów wirtualnych. Dla wyjaśnienia: termin virtual ma 2 główne zastosowania:

• Maszyny wirtualne: nie są wymagane, ale niektóre wdrożenia wykorzystują technologię maszyn wirtualnych do tworzenia odizolowanych serwerów dla komponentów Apigee. Hosty maszyn wirtualnych, podobnie jak hosty fizyczne, mogą mieć interfejsy sieciowe i zapory sieciowe.
• Hosty wirtualne: punkty końcowe sieci, analogiczne do hosta wirtualnego Apache.

Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się one 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 „VM1” udostępnia wirtualny interfejs Ethernet, który w maszynie wirtualnej ma nazwę „eth0” i któremu maszyna wirtualna lub sieciowy serwer DHCP przypisuje adres IP 111.111.111.111. Załóżmy też, że VM2 udostępnia wirtualny interfejs Ethernet, który również ma nazwę „eth0” i któremu przypisany jest adres IP 111.111.111.222.

W każdej z tych 2 maszyn wirtualnych może działać router Apigee. Routery udostępniają punkty końcowe hosta wirtualnego, jak w tym hipotetycznym przykładzie:

Router Apigee w maszynie wirtualnej VM1 udostępnia 3 hosty wirtualne w interfejsie eth0 (który ma określony adres IP): api.mycompany.com:80, api.mycompany.com:443 i test.mycompany.com:80.

Router w maszynie wirtualnej VM2 udostępnia api.mycompany.com:80 (ta sama nazwa i port co w przypadku maszyny wirtualnej VM1).

System operacyjny hosta fizycznego może mieć zaporę sieciową. Jeśli tak jest, musi ona być skonfigurowana tak, aby przepuszczać ruch TCP kierowany do portów udostępnianych w interfejsach zwirtualizowanych (111.111.111.111:{80, 443} i 111.111.111.222:80). Dodatkowo system operacyjny każdej maszyny wirtualnej może mieć własną zaporę sieciową w interfejsie eth0, która również musi zezwalać na ruch na portach 80 i 443.

Ścieżka podstawowa to trzeci komponent, który bierze udział w kierowaniu wywołań interfejsu API do różnych wdrożonych przez Ciebie proxy interfejsów API. Pakiety serwerów proxy interfejsu API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki podstawowe. Na przykład jedna ś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 Traffic Director, która rozdzieli ruch http://api.mycompany.com:80/ między 2 adresy IP (111.111.111.111 na maszynie wirtualnej VM1 i 111.111.111.222 na maszynie wirtualnej VM2). Ta funkcja jest specyficzna dla danej instalacji i jest konfigurowana przez lokalną grupę sieciową.

Ścieżka podstawowa jest ustawiana podczas wdrażania interfejsu API. W powyższym przykładzie możesz wdrożyć 2 interfejsy API, mycompany i testmycompany, dla 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 podstawowej we wdrożeniu, router nie będzie wiedział, do którego interfejsu API wysyłać przychodzące żądania.

Jeśli jednak wdrożysz 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ż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/.

Licencjonowanie

Każda instalacja Edge wymaga unikalnego pliku licencji, który można uzyskać od Apigee. Podczas instalowania 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 dozwoloną liczbę procesorów komunikatów. Jeśli którekolwiek z ustawień licencji wygasło, logi znajdziesz w tej lokalizacji: /opt/apigee/var/log/edge-management-server/logs. W takim przypadku możesz skontaktować się z zespołem pomocy Apigee Edge, aby uzyskać szczegółowe informacje o migracji.

Jeśli nie masz jeszcze licencji, skontaktuj się z zespołem sprzedaży Apigee.