Wymagania dotyczące instalacji

Wymagania sprzętowe

Aby zapewnić wysoką dostępność infrastruktury w środowisku produkcyjnym, musisz spełniać poniższe minimalne wymagania sprzętowe.

W tym filmie znajdziesz ogólne wskazówki dotyczące rozmiarów przy instalacji:

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

W tych tabelach wymagania dotyczące dysku twardego uzupełniają ilość miejsca na dysku twardym wymaganą przez system operacyjny. W zależności od aplikacji i ruchu sieciowego instalacja może wymagać mniej lub więcej zasobów niż wymienione poniżej.

Element instalacyjny RAM CPU Minimalny dysk twardy
Cassandra 16 GB 8-rdzeniowy 250 GB pamięci lokalnej z dyskiem SSD obsługującym 2000 IOPS
Procesor/router wiadomości na tym samym komputerze 16 GB 8-rdzeniowy 100GB
Procesor wiadomości (samodzielny) 16 GB 8-rdzeniowy 100GB
Router (samodzielny) 16 GB 8-rdzeniowy 100GB
Analytics – Postgres/Qpid na tym samym serwerze 16GB* 8-rdzeniowy* 500 GB – 1 TB** w sieci***, najlepiej z backendem SSD, obsługującym co najmniej 1000 IOPS*
Analytics – główna usługa Postgres lub w trybie gotowości (samodzielna) 16GB* 8-rdzeniowy* 500 GB – 1 TB** w sieci***, najlepiej z backendem SSD, obsługującym co najmniej 1000 IOPS*
Analytics – wersja samodzielna Qpid 8 GB 4-rdzeniowy 30–50 GB pamięci lokalnej z dyskiem SSD

Domyślny rozmiar kolejki Qpid to 1 GB, ale można go zwiększyć do 2 GB. Jeśli potrzebujesz większej pojemności, dodaj kolejne węzły Qpid.
OpenLDAP/UI/serwer zarządzania 8 GB 4-rdzeniowy 60GB
Interfejs użytkownika/serwer zarządzania 4 GB 2-rdzeniowy 60GB
OpenLDAP (samodzielna wersja) 4 GB 2-rdzeniowy 60GB

* Dostosuj wymagania systemowe Postgres na podstawie przepustowości:

  • Mniej niż 250 TPS: możesz korzystać z 8 GB, 4-rdzeniowego pamięci masowej z zarządzaną pamięcią sieciową*** obsługującą co najmniej 1000 IOPS
  • Więcej niż 250 TPS: 16 GB, 8-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 1000 IOPS
  • Więcej niż 1000 TPS: 16 GB, 8-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 2000 IOPS
  • Więcej niż 2000 TPS: 32 GB, 16-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 2000 IOPS
  • Więcej niż 4000 TPS: 64 GB, 32-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 4000 IOPS

** Wartość dysku twardego Postgres jest określana na podstawie gotowych statystyk przechwyconych przez Edge. Jeśli dodasz do danych Analytics wartości niestandardowe, należy je odpowiednio zwiększyć. Aby oszacować ilość potrzebnego 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 dla bazy danych Postgresql, ponieważ:

  • Umożliwia dynamiczne skalowanie rozmiaru pamięci masowej w razie potrzeby.
  • IOPS sieci można regulować na bieżąco w większości współczesnych podsystemów środowisk, pamięci masowej i sieci.
  • Zrzuty na poziomie miejsca na dane można włączyć w ramach rozwiązań do tworzenia kopii zapasowych i przywracania.

Poniżej znajdziesz też wymagania sprzętowe, które musisz spełnić, aby zainstalować Usługi zarabiania (które nie są obsługiwane w przypadku instalacji all-in-One):

Komponent generujący przychody RAM CPU Dysk twardy
Serwer zarządzania (z usługami generowania 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 backendem SSD, obsługujące co najmniej 1000 IOPS lub skorzystaj z reguły z tabeli powyżej.
Analytics – samodzielny plik Postgres lub tryb gotowości 16 GB 8-rdzeniowy 500 GB – 1 TB pamięci sieciowej, najlepiej z backendem SSD, obsługujące co najmniej 1000 IOPS lub skorzystaj z reguły z tabeli powyżej.
Analytics – wersja samodzielna Qpid 8 GB 4-rdzeniowy 40–500 GB pamięci lokalnej z dyskiem SSD lub szybkim dyskiem HDD

W przypadku instalacji większych niż 250 TPS zalecamy użycie dysku HDD z pamięcią lokalną obsługującą 1000 IOPS.

Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm

Te instrukcje instalacji oraz dołączone pliki instalacyjne zostały przetestowane pod kątem systemów operacyjnych i oprogramowania innych firm wymienionych w sekcji Obsługiwane i obsługiwane wersje.

Java

Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja środowiska Java 1.8. Listę obsługiwanych pakietów JDK znajdziesz na stronie Obsługiwane oprogramowanie i wersje.

W przypadku użytkownika wykonującego instalację upewnij się, że zmienna środowiskowa JAVA_HOME wskazuje katalog główny pakietu JDK.

SELinux

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

Tworzenie użytkownika „apigee”

Procedura instalacji powoduje utworzenie użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki brzegowe są własnością „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge są uruchamiane 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 w katalogu. Chociaż nie możesz zmienić tego katalogu, możesz utworzyć dowiązanie symboliczne do zmapowania obiektu /opt/apigee na inną lokalizację zgodnie z opisem w sekcji Tworzenie dowiązania symbolicznego z pliku /opt/apigee.

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

Przed utworzeniem dowiązania symbolicznego musisz najpierw utworzyć użytkownika i grupę o nazwie „apigee”. To jest ta sama grupa i użytkownik utworzone w instalatorze Edge.

Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku bootstrap_4.52.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 dowiązanie symboliczne z dyrektywy /opt/apigee do żądanego katalogu głównego instalacyjnego: 
    ln -Ts /srv/myInstallDir /opt/apigee

    Gdzie /srv/myInstallDir to wymagana lokalizacja plików Edge.

  3. Zmień właściciela 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ę maszyny
  • hostname -i zwraca adres IP nazwy hosta, który można zaadresować z innych komputerów.

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 jest ustawiona nieprawidłowo. Więcej informacji można znaleźć w dokumentacji konkretnego systemu operacyjnego.

Jeśli serwer ma wiele kart interfejsu, polecenie „nazwa hosta -i” zwraca listę adresów IP rozdzielonych spacjami. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, co w niektórych sytuacjach może nie być poprawne. 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 prosi o wybranie adresu IP, którego chcesz użyć podczas instalacji. Wartością domyślną jest „n”. Więcej informacji znajdziesz w dokumentacji pliku konfiguracji brzegowej.

Otoki TCP

Otoki TCP mogą blokować komunikację z niektórymi portami i mieć wpływ 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 w wymaganych portach OpenLDAP, Postgres i Cassandra.

IPtables

Sprawdź, czy nie ma żadnych zasad iptables, które uniemożliwiają połączenie między węzłami w wymaganych portach brzegowych. Jeśli to konieczne, możesz zatrzymać iptables podczas instalacji, korzystając z polecenia:

sudo/etc/init.d/iptables stop

W CentOS 7.x:

systemctl stop firewalld

Dostęp do katalogu

W poniższej tabeli znajdziesz listę katalogów w węzłach brzegowych, które mają specjalne wymagania wobec procesów Edge:

Usługa Katalog Opis
Router /etc/rc.d/init.d/functions

Router brzegowy korzysta z routera Nginx i wymaga uprawnień do odczytu domeny /etc/rc.d/init.d/functions.

Jeśli Twój proces zabezpieczeń wymaga ustawienia uprawnień dla instancji /etc/rc.d/init.d/functions, nie ustawiaj ich na wartość 700, bo inaczej router się nie uruchomi.

Aby zezwolić na odczyt elementu /etc/rc.d/init.d/functions, możesz ustawić uprawnienia na 744.
Opiekun zoo /dev/random Biblioteka klienta Zookeeper wymaga uprawnień do odczytu generatora liczb losowych /dev/random. Jeśli zasada /dev/random jest zablokowana podczas odczytu, usługa Zookeeper może się nie uruchomić.

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 artykule Informacje o współczynniku replikacji i poziomie spójności Cassandra.

Cassandra automatycznie dostosowuje rozmiar stosu w Javie na podstawie dostępnej pamięci. Więcej informacji znajdziesz w sekcji o dostosowywaniu zasobów Java w przypadku spadku 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 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 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 wymienione powyżej właściwości.
  3. Zapisz zmiany.
  4. Ponownie uruchom bazę danych PostgreSQL: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Ograniczenia systemu

Sprawdź, czy w węzłach Cassandra i procesora wiadomości ustawiono te limity systemowe:

  • W węzłach Cassandra ustaw limity memlock, memlock i nofile oraz przestrzeni adresowej dla użytkownika instalacji (domyślnie jest to „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ę deskryptorów otwartych 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. Dzieje się tak, jeśli na przykład masz otwartych jednocześnie wiele plików tymczasowych.

  • Jeśli kiedykolwiek zobaczysz poniższy błąd w routerze lub procesorze wiadomości system.log, może to oznaczać, że limity deskryptorów plików są zbyt niskie:

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

    Limity użytkowników możesz sprawdzić, uruchamiając 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, prześlij zgłoszenie do pomocy Apigee Edge, aby uzyskać dalsze informacje o rozwiązywaniu problemów.

Usługi bezpieczeństwa sieci (NSS)

Network Security Services (NSS) to zestaw bibliotek, które ułatwiają tworzenie aplikacji klienckich i serwerowych z włączonymi zabezpieczeniami. Sprawdź, czy masz zainstalowaną wersję NSS w wersji 3.19 lub nowszej.

Aby sprawdzić używaną wersję:

yum info nss

Aby zaktualizować NSS:

yum update nss

Więcej informacji znajdziesz w tym artykule na kanale RedHat.

Wyłącz wyszukiwanie DNS w IPv6 podczas używania NSCD (demonsu pamięci podręcznej usługi nazw)

Jeśli zainstalujesz i włączysz demon pamięci podręcznej NSCD (NSCD), procesory wiadomości przeprowadzają 2 wyszukiwania DNS: jedno dla IPv4 i jedno dla IPv6. Jeśli używasz NSCD, musisz wyłączyć wyszukiwanie DNS w IPv6.

Aby wyłączyć wyszukiwanie DNS w IPv6:

  1. W każdym węźle procesora wiadomości edytuj /etc/nscd.conf
  2. 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.

Instrukcje wyłączania protokołu IPv6 znajdziesz w dokumentacji systemu RedHat lub CentOS konkretnej wersji systemu operacyjnego. Na przykład możesz:

  1. Otwórz plik /etc/hosts w edytorze.
  2. Wstaw znak „#” w kolumnie 1 z tych wierszy, aby dodać komentarz: 
    #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
  3. Zapisz plik.

AWS AMI

Jeśli instalujesz Edge w obrazie AWS Amazon Machine Image (AMI) dla Red Hat Enterprise Linux 7.x, najpierw uruchom to polecenie:

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Narzędzia,

Instalator korzysta z poniższych narzędzi systemu UNIX w wersji standardowej udostępnianej przez EL5 lub EL6.

awk

expr

libxlst

obr./min

unzip

basename

grep

Lua-Socket

rpm2cpio

dodanie użytkownika

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

date

 libdb-cxx

ps

uuid

konfiguracja chkconfig
dirname libibverbs pwd Uname  
echo librdmacm python    

nietpdate

Apigee zaleca synchronizację czasów serwerów. Jeśli narzędzie ntpdate nie zostało jeszcze skonfigurowane, może służyć do tego, które sprawdza, czy serwery są synchronizowane pod kątem czasu. Aby zainstalować narzędzie, możesz użyć yum install ntp. Jest to szczególnie przydatne do replikowania konfiguracji OpenLDAP. Pamiętaj, że ustawiasz strefę czasową serwera w strefie czasowej UTC.

Openldap 2.4

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

W przypadku instalacji z 13 hostami i 12 hostami z 2 centrami danych wymagana jest replikacja OpenLDAP, ponieważ istnieje wiele węzłów hostujących OpenLDAP.

Zapory sieciowe i hosty wirtualne

Termin virtual jest często przeciążony w branży IT, dlatego odnosi się do Apigee Edge do wdrażania w chmurze prywatnej i hostów wirtualnych. Uściślając, termin virtual ma 2 główne zastosowania:

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

Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (pod warunkiem, że różnią się od siebie aliasem hosta lub portem interfejsu).

Na przykład na pojedynczym serwerze fizycznym A może działać 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że „VM1” udostępnia interfejs wirtualnej sieci Ethernet, który w maszynie wirtualnej otrzymuje nazwę „eth0” i który ma przypisany adres IP 111.111.111.111 przez maszynę wirtualizacyjną lub serwer DHCP sieci. Następnie załóżmy, że VM2 udostępnia interfejs wirtualnego Ethernetu o nazwie „eth0” i otrzymuje adres IP 111.111.111.222.

Możemy mieć router Apigee uruchomiony w każdej z tych 2 maszyn wirtualnych. Routery ujawniają wirtualne punkty końcowe hosta, jak w tym hipotetycznym przykładzie:

Router Apigee w maszynie wirtualnej VM1 udostępnia 3 hosty wirtualne w swoim interfejsie eth0 (mającym określony adres IP), api.mycompany.com:80, api.mycompany.com:443 i test.mycompany.com:80.

Router w VM2 udostępnia interfejs api.mycompany.com:80 (ta sama nazwa i port, które są udostępniane przez VM1).

System operacyjny fizycznego hosta może mieć zaporę sieciową. W takim przypadku zapora sieciowa musi być skonfigurowana tak, aby przekazywał ruch TCP powiązany z portami udostępnianymi w zwirtualizowanych interfejsach (111.111.111.111:{80, 443} i 111.111.111.222:80). Ponadto system operacyjny każdej maszyny wirtualnej może udostępniać własną zaporę sieciową w interfejsie eth0, która musi zezwalać na łączenie się z portami 80 i 443.

Ścieżka bazowa to trzeci komponent odpowiedzialny za kierowanie wywołań interfejsu API do różnych serwerów proxy interfejsu API, które mogły zostać wdrożone. Pakiety proxy interfejsów API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki bazowe. Na przykład jedną ścieżkę bazową można zdefiniować jako http://api.mycompany.com:80/, a drugą jako http://api.mycompany.com:80/salesdemo.

W tym przypadku potrzebny jest system równoważenia obciążenia lub dyrektor ruchu, który dzieli ruch http://api.mycompany.com:80/ między 2 adresy IP (111.111.111.111 w maszynie wirtualnej 1 i 111.111.111.222 w maszynie wirtualnej 2). 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 możesz wdrożyć 2 interfejsy API (mycompany i testmycompany) dla organizacji mycompany-org na hoście 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 wiedzieć, do którego interfejsu API ma wysyłać żądania przychodzące.

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ą http://api.mycompany.com:80/salesdemo. Jeśli wdrażasz swój interfejs API w firmie działającej z użyciem podstawowego adresu URL /, użytkownicy uzyskują dostęp do interfejsu API za pomocą adresu URL http://api.mycompany.com:80/.

Licencjonowanie

Każda instalacja Edge wymaga unikalnego pliku licencji uzyskanego z Apigee. Podczas instalowania serwera zarządzania musisz podać ścieżkę do pliku licencji, na przykład /tmp/license.txt.

Instalator skopiuje plik licencji do /opt/apigee/customer/conf/license.txt.

Jeśli plik licencji jest prawidłowy, serwer zarządzania sprawdza wygaśnięcie ważności i dozwoloną liczbę procesorów wiadomości (MP). Jeśli któreś 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 o migracji.

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