Wymagania dotyczące instalacji

Wymagania sprzętowe

Musisz spełniać te minimalne wymagania sprzętowe dotyczące infrastruktury o wysokiej dostępności w środowisku produkcyjnym.

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

W przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji w tabelach poniżej znajdziesz minimalne wymagania sprzętowe dotyczące komponentów instalacji.

Wymagania dotyczące dysku twardego podane w tych tabelach są dodatkowe w stosunku 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.

Poniżej znajdziesz też wymagania sprzętowe, które musisz spełnić, jeśli chcesz zainstalować usługi zarabiania (nie są one obsługiwane w przypadku instalacji typu „wszystko w jednym”):

Wymagania dotyczące przepustowości sieci Cassandra

Cassandra używa protokołu Gossip do wymiany informacji z innymi węzłami o topologii sieci. Użycie protokołu Gossip w połączeniu z rozproszoną naturą Cassandry, która wymaga komunikacji z wieloma węzłami w przypadku 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 zalecana jest większa przepustowość.

Maksymalne opóźnienie lub opóźnienie na poziomie 99 percentyla w przypadku systemu Cassandra powinno być mniejsze niż 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 sekcji Obsługiwane oprogramowanie i obsługiwane wersje.

Wymaganie wstępne: włącz repozytorium EPEL

Przed rozpoczęciem instalacji upewnij się, że repozytorium EPEL (Extra Packages for Enterprise Linux) jest włączone. Użyj tych poleceń w zależności od wersji systemu operacyjnego:

• W przypadku systemów Red Hat/CentOS/Oracle w wersji 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 systemów 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 Javy 1.8. Obsługiwane wersje JDK znajdziesz 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 mieć problemy z instalacją i uruchamianiem komponentów. W razie potrzeby możesz wyłączyć SELinux lub ustawić go w trybie zezwalającym podczas instalacji, a następnie ponownie włączyć po instalacji. Więcej informacji znajdziesz w artykule Instalowanie narzędzia Edge apigee-setup.

Tworzenie użytkownika „apigee”

Podczas instalacji tworzony jest użytkownik systemu Unix o nazwie „apigee”. Katalogi i pliki Edge należą do użytkownika „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge działają jako użytkownik „apigee”. W razie potrzeby możesz uruchomić komponenty jako inny użytkownik.

Katalog instalacyjny

Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee. Nie można zmienić lokalizacji tego katalogu. Nie możesz zmienić tego katalogu, ale możesz utworzyć dowiązanie symboliczne, aby zmapować /opt/apigee na inną lokalizację, zgodnie z opisem w sekcji Tworzenie dowiązania symbolicznego z katalogu /opt/apigee.

W instrukcjach w tym przewodniku katalog instalacyjny jest oznaczony jako /opt/apigee.

Tworzenie linku symbolicznego z /opt/apigee

Zanim utworzysz link symboliczny, 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ć link symboliczny, wykonaj te czynności przed pobraniem pliku bootstrap_4.53.01.sh. 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 link symboliczny z /opt/apigee do wybranego katalogu głównego instalacji:

   ln -Ts /srv/myInstallDir /opt/apigee

   gdzie /srv/myInstallDir to miejsce, w którym mają się znajdować pliki Edge.

3. Zmień właściciela katalogu głównego instalacji i linku 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, do którego można się odwoływać z innych maszyn.

W zależności od typu i wersji systemu operacyjnego może być konieczne edytowanie /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta nie jest prawidłowo ustawiona. Więcej informacji znajdziesz w dokumentacji systemu operacyjnego.

Jeśli serwer ma wiele 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 w niektórych sytuacjach może być nieprawidłowy. Możesz też ustawić w pliku konfiguracji instalacji tę właściwość:

ENABLE_DYNAMIC_HOSTIP=y

Gdy ta właściwość ma wartość „y”, instalator wyświetla prośbę o wybranie adresu IP, który ma być używany w ramach instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji pliku konfiguracyjnego Edge.

TCP Wrappers

TCP Wrappers mogą blokować komunikację na niektórych portach i mieć wpływ na instalację SymasLDAP, Postgres i Cassandra. Na tych węzłach sprawdź /etc/hosts.allow i /etc/hosts.deny, aby upewnić się, że nie ma ograniczeń portów w przypadku wymaganych portów SymasLDAP, Postgres i Cassandra.

iptables

Sprawdź, czy nie ma zasad iptables, które uniemożliwiają połączenie między węzłami na wymaganych portach brzegowych. 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 znajdziesz listę katalogów na węzłach brzegowych, które mają specjalne wymagania dotyczące procesów brzegowych:

Cassandra

Wszystkie węzły Cassandry muszą być połączone z pierścieniem. Cassandra przechowuje repliki danych na 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 umieszczane są repliki. Więcej informacji znajdziesz w artykule Współczynnik replikacji i poziom spójności w usłudze Cassandra.

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

Po zainstalowaniu Edge for Private Cloud możesz sprawdzić, czy Cassandra jest prawidłowo skonfigurowana, przeglądając plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Sprawdź na przykład, czy skrypt instalacyjny Edge for Private Cloud ustawił 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 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:

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. Ponownie uruchom bazę danych PostgreSQL:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Konfiguracja ustawień regionalnych w systemie Rocky 9.X

Jeśli używasz systemu Rocky w wersji 9.X, upewnij się, że w ustawieniach regionalnych całego systemu jest skonfigurowany znak 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 na węzłach Cassandra i Message Processor ustawione są te limity systemowe:

• Na węzłach Cassandra ustaw limity miękkie i twarde 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 wiadomości ustaw maksymalną liczbę otwartych deskryptorów plików na 64 tys. 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. Na przykład jeśli masz otwartych wiele plików tymczasowych.

• Jeśli w routerze lub procesorze wiadomości pojawi się ten błąd:system.log, 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 to polecenie:

  # su - apigee
  $ ulimit -n
  100000
  

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

Network Security Services (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ć obecną wersję:

yum info nss

Aby zaktualizować NSS:

yum update nss

Więcej informacji znajdziesz w tym artykule firmy 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 wykonują 2 wyszukiwania DNS: jedno dla IPv4 i jedno dla IPv6. Jeśli używasz NSCD, wyłącz wyszukiwanie DNS w protokole IPv6.

Aby wyłączyć wyszukiwanie DNS w przypadku IPv6:

1. Na każdym węźle procesora wiadomości edytuj /etc/nscd.conf.
2. Ustaw tę właściwość:

   enable-cache hosts no

Wyłączanie protokołu IPv6 w systemie RHEL 8 i nowszym

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

Narzędzia

Instalator używa tych narzędzi UNIX w wersji standardowej dostarczanej przez EL5 lub EL6.

Synchronizacja czasu

Apigee zaleca synchronizację czasu na serwerach. Jeśli nie jest jeszcze skonfigurowane, narzędzie ntpdate lub równoważne narzędzie może służyć do weryfikacji, 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, aby ustawić strefę czasową serwera 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 Private Cloud i hostów wirtualnych. Termin virtual ma 2 główne zastosowania:

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

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

Na 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 na maszynie wirtualnej VM1 udostępnia 3 wirtualne hosty na interfejsie eth0 (który ma określony adres IP): api.mycompany.com:80, api.mycompany.com:443 i test.mycompany.com:80.

Router na maszynie wirtualnej VM2 udostępnia api.mycompany.com:80 (o tej samej nazwie i porcie co router udostępniany przez maszynę wirtualną VM1).

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

Ścieżka podstawowa to trzeci komponent biorący udział w kierowaniu wywołań interfejsu API do różnych serwerów proxy interfejsu API, które mogły zostać wdrożone. Pakiety 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 inna jako http://api.mycompany.com:80/salesdemo.

W tym przypadku potrzebujesz systemu równoważenia obciążenia lub usługi Traffic Director, które będą rozdzielać 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 Twojej instalacji i jest konfigurowana przez lokalną grupę sieciową.

Ścieżka podstawowa jest ustawiana podczas wdrażania interfejsu API. Na podstawie powyższego przykładu możesz wdrożyć 2 interfejsy API, mycompany i testmycompany, w organizacji mycompany-org z wirtualnym hostem, który ma alias hosta api.mycompany.com i port ustawiony na 80. Jeśli w przypadku wdrożenia nie zadeklarujesz ścieżki podstawowej, router nie będzie wiedzieć, do którego interfejsu API ma wysyłać przychodzące żądania.

Jeśli jednak wdrożysz interfejs API testmycompany z podstawowym adresem URL /salesdemo, użytkownicy będą uzyskiwać do niego dostęp za pomocą adresu http://api.mycompany.com:80/salesdemo. Jeśli wdrożysz interfejs API mycompany z adresem URL /, użytkownicy będą uzyskiwać do niego dostęp za pomocą adresu URL http://api.mycompany.com:80/.

Licencjonowanie

Każda instalacja Edge wymaga unikalnego pliku licencji, który uzyskujesz od Apigee. Podczas instalacji serwera zarządzającego 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ądzający sprawdza datę ważności i dozwoloną liczbę procesorów wiadomości. Jeśli którekolwiek z ustawień licencji wygasło, dzienniki znajdziesz w tym miejscu: /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.