Wymagania dotyczące instalacji

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ą uzupełniające wymagania dotyczące ilości miejsca na dysku twardym wymaganej 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 250 GB pamięci lokalnej z dyskiem 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 rdzeni* 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* Od 500 GB do 1 TB** pamięci sieciowej***, najlepiej z backendem SSD, który obsługuje 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 60GB
OpenLDAP (samodzielna wersja) 4 GB 2-rdzeniowy 60GB

* Dostosuj wymagania dotyczące systemu Postgres na podstawie przepustowości:

  • Mniej niż 250 TPS: można rozważyć 8 GB i 4 rdzenie z zarządzanym magazynem sieciowym*** obsługującym co najmniej 1000 IOPS.
  • Powyżej 250 TPS: zarządzana pamięć sieciowa*** o pojemności 16 GB i 8 rdzeniach, obsługująca co najmniej 1000 IOPS
  • Ponad 1000 TPS: zarządzana pamięć sieciowa*** o pojemności 16 GB i 8 rdzeniach, obsługująca 2000 IOPS lub więcej
  • Więcej niż 2000 TPS: 32 GB, 16-rdzeniowy, zarządzana pamięć sieciowa*** obsługująca co najmniej 2000 IOPS
  • Ponad 4000 TPS: zarządzana pamięć sieciowa*** o pojemności 64 GB i 32 rdzenia, obsługująca 4000 IOPS lub więcej

** Wartość dysku twardego Postgresa jest określana na podstawie domyślnych statystyk rejestrowanych przez Edge. Jeśli dodasz do danych analitycznych wartości niestandardowe, należy je odpowiednio zwiększyć. Aby oszacować wymaganą ilość miejsca 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 of storage needed

*** Network Storage jest zalecany w przypadku bazy danych Postgresql, ponieważ:

  • Umożliwia to dynamiczne zwiększanie rozmiaru miejsca na dane w razie potrzeby.
  • IOPS sieci można dostosowywać w locie w większości współczesnych środowisk/systemów pamięci masowej/sieci.
  • Zrzuty stanu na poziomie magazynu mogą być włączone jako część rozwiązań do tworzenia kopii zapasowych i przywracania.

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 60GB
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 skorzystaj z reguły z tabeli powyżej.
Statystyki – serwer główny lub zapasowy serwer samodzielny Postgres 16 GB 8-rdzeniowy Od 500 GB do 1 TB pamięci sieciowej, najlepiej z backendem SSD, który obsługuje co najmniej 1000 IOPS, albo użyj reguły z powyższej tabeli.
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 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.

Java

Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja Java 1.8. Obsługiwane pakiety JDK są wymienione w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.

Upewnij się, że zmienna środowiskowa JAVA_HOME wskazuje katalog główny pakietu JDK u użytkownika wykonują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 podczas instalacji możesz wyłączyć SELinux lub ustawić tryb mniej rygorystyczny, a następnie włączyć go ponownie po instalacji. Więcej informacji znajdziesz w artykule Instalowanie narzędzia apige-setup w Edge.

Tworzenie użytkownika „apigee”

Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki brzegowe 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ć odnośnik symboliczny, aby mapować /opt/apigee do innego miejsca, zgodnie z opisem w sekcji Tworzenie odnośnika symbolicznego z katalogu /opt/apigee.

W instrukcjach w tym przewodniku katalog instalacyjny jest oznaczony jako /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.52.00.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 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.

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

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, do której można się odwoływać z innych maszyn.

W zależności od typu i wersji systemu operacyjnego może być konieczna zmiana /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta jest nieprawidłowa. Więcej informacji znajdziesz w dokumentacji używanego 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 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. W tych węzłach sprawdź /etc/hosts.allow i /etc/hosts.deny, aby mieć pewność, że na wymaganych portach OpenLDAP, Postgres i Cassandra nie ma żadnych ograniczeń portów.

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

W CentOS 7.x:

systemctl stop firewalld

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 dostępu do odczytu do /etc/rc.d/init.d/functions.

Jeśli proces bezpieczeństwa wymaga ustawienia uprawnień w /etc/rc.d/init.d/functions, nie ustawiaj ich na 700, ponieważ w przeciwnym razie router się nie uruchomi.

Aby przyznać uprawnienia do odczytu do /etc/rc.d/init.d/functions, możesz ustawić uprawnienia na 744.
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 skali replikacji i poziomie spójności w Cassandra.

Cassandra automatycznie dostosowuje rozmiar sterty Javy 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 system Cassandra jest prawidłowo skonfigurowany, przeglądając plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Sprawdź na przykład, czy skrypt instalacji 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 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:

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

Ograniczenia systemu

Sprawdź, czy w węzłach Cassandra i Message Processor ustawione są te limity systemu:

  • W węzłach Cassandra ustaw limity łagodnego i twardego memlocka, nofile oraz przestrzeni adresowej dla użytkownika instalacji (domyślnie jest to „apigee”) w /etc/security/limits.d/90-apigee-edge-limits.conf w następujący sposób: 
    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. Dzieje się tak, gdy na przykład jednocześnie masz otwartych wiele plików tymczasowych.

  • Jeśli w Routerze lub przetwarzaczu wiadomości system.log pojawi się ten komunikat o błędzie, limity 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łącz wyszukiwanie DNS w IPv6 podczas używania NSCD (demon pamięci podręcznej usługi nazw)

Jeśli masz zainstalowany i włączony NSCD (Name Service Cache Daemon), procesory wiadomości przeprowadzają 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 IPv6:

  1. W każdym węźle usługi Message Processor edytuj /etc/nscd.conf
  2. Ustaw tę właściwość: 
    enable-cache hosts no

Wyłączanie IPv6 w Google Cloud Platform w przypadku RedHat/CentOS 7

Jeśli instalujesz Edge na RedHat 7 lub CentOS 7 na Google Cloud Platform, musisz wyłączyć IPv6 na wszystkich węzłach Qpid.

Instrukcje wyłączania IPv6 znajdziesz w dokumentacji RedHat lub CentOS dotyczącej konkretnej wersji systemu operacyjnego. Możesz na przykład:

  1. Otwórz plik /etc/hosts w edytorze.
  2. Aby wyłączyć komentarz, wstaw znak „#” w pierwszej kolumnie tego wiersza: 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Zapisz plik.

AWS AMI,

Jeśli instalujesz Edge na obrazie AWS Amazon Machine Image (AMI) dla 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 tych narzędzi UNIX w wersji standardowej, jaką udostępnia EL5 lub EL6.

awk

expr

libxslt

obr./min

rozpakuj

nazwa_podstawowa

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    

ntpdate

Apigee zaleca zsynchronizowanie czasu na serwerach. Jeśli nie masz jeszcze skonfigurowanego narzędzia ntpdate, możesz użyć go do sprawdzenia, czy serwery są zsynchronizowane czasowo. Aby zainstalować to narzędzie, możesz użyć polecenia yum install ntp. Jest to szczególnie przydatne w przypadku replikowania konfiguracji OpenLDAP. Pamiętaj, że strefę czasową serwera konfigurujesz w UTC.

openldap 2.4

Instalacja lokalna wymaga OpenLDAP 2.4. Jeśli serwer ma połączenie z internetem, skrypt instalacyjny Edge pobiera i instaluje OpenLDAP. Jeśli Twój serwer nie ma połączenia z Internetem, przed uruchomieniem skryptu instalacji Edge musisz się upewnić, że OpenLDAP jest już zainstalowany. W przypadku RHEL/CentOS możesz uruchomić yum install openldap-clients openldap-servers, aby zainstalować OpenLDAP.

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

Dla przykładu: jeden serwer fizyczny A może używać 2 maszyn wirtualnych 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.

W każdej z 2 maszyn wirtualnych może działać router Apigee. 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 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 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ę 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 bazowa 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żysz interfejs API testmycompany z podstawowym adresem URL /salesdemo, użytkownicy będą uzyskiwać dostęp do tego interfejsu API za pomocą interfejsu 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, na przykład /tmp/license.txt.

Instalator skopiuje 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 wygaśnie, 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 zespołem sprzedaży Apigee.