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.

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

W przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji tabele poniżej zawierają minimalne wymagania sprzętowe związane z komponentami instalacji.

W tych tabelach wymagania dotyczące dysku twardego obowiązują oprócz ilości 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.

Komponent 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** pamięci masowej***, najlepiej z backendem SSD, obsługującą co najmniej 1000 IOPS*
Analytics – główna usługa Postgres lub gotowości (samodzielna) 16GB* 8-rdzeniowy* 500 GB – 1 TB** pamięci masowej***, najlepiej z backendem SSD, obsługującą co najmniej 1000 IOPS*
Analytics – wersja samodzielna Qpid 16 GB 8-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/Management Server. 8 GB 4-rdzeniowy 60GB
UI/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 uwzględnić 8 GB, 4-rdzeniowy i zarządzaną pamięć masową sieciową*** obsługującą co najmniej 1000 IOPS
  • Ponad 250 TPS: 16 GB, 8-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 1000 IOPS
  • Ponad 1000 TPS: 16 GB, 8-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 2000 IOPS
  • Ponad 2000 TPS: 32 GB, 16-rdzeniowa, zarządzana pamięć sieciowa*** obsługująca co najmniej 2000 IOPS
  • Ponad 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 do użycia statystyk przechwyconych przez Edge. Jeśli dodasz do danych Analytics wartości niestandardowe, musisz 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

*** W przypadku bazy danych Postgresql zalecane jest użycie Network Storage, ponieważ:

  • Daje możliwość dynamicznego skalowania rozmiaru pamięci masowej w górę, jeśli jest to wymagane.
  • IOPS sieci można dostosowywać na bieżąco w większości obecnych podsystemów środowiska, pamięci masowej i sieci.
  • Zrzuty poziomu miejsca na dane można włączyć w ramach rozwiązań do tworzenia kopii zapasowych i przywracania.

Dodatkowo poniżej znajdziesz listę wymagań sprzętowych, które musisz spełnić, aby zainstalować Usługi zarabiania (nieobsługiwane w przypadku instalacji All-in-One):

Komponent z generowaniem przychodu RAM CPU Dysk twardy
Serwer zarządzania (z usługami zarabiania) 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 – witryna główna Postgres lub samodzielny 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 HDD

W przypadku instalacji większych niż 250 TPS zalecany jest dysk HDD z pamięcią lokalną obsługującą 1000 IOPS.

Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm

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

Java

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

Upewnij się, że zmienna środowiskowa JAVA_HOME wskazuje katalog główny pakietu JDK użytkownika przeprowadzającego instalację.

SELinux

W zależności od ustawień SELinux przeglądarka Edge może napotkać problemy z instalowaniem i uruchamianiem komponentów Edge. W razie potrzeby możesz wyłączyć SELinux lub ustawić go w trybie mniej rygorystycznym na czas 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 należą do „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 instalacji

Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee. Nie możesz zmienić tej lokalizacji w katalogu. Nie możesz zmienić tego katalogu, ale możesz utworzyć dowiązanie symboliczne do zmapowania obiektu /opt/apigee na inną lokalizację zgodnie z opisem w sekcji Tworzenie dowiązania symbolicznego z /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”. Jest to ta sama grupa i użytkownik utworzone w instalatorze Edge.

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

    Gdzie /srv/myInstallDir to żądana lokalizacja plików Edge.

  3. Zmień własność katalogu głównego i dowiązania symbolicznego do instalacji 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órą można zaadresować z innych maszyn.

W zależności od typu i wersji systemu operacyjnego może być konieczna edycja /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 interfejsów, 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ć prawidłowe. Możesz też ustawić tę właściwość w pliku konfiguracji instalacji:

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 artykule z informacjami o pliku konfiguracji brzegu.

Otoki TCP

Otoki TCP mogą blokować komunikację w niektórych portach i wpływać 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ń na temat wymaganych portów OpenLDAP, Postgres i Cassandra.

IPtables

Sprawdź, czy nie ma zasad iptables, które blokują połączenia 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

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 dotyczące procesów brzegowych:

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

Router brzegowy używa routera Nginx i wymaga uprawnień do odczytu w domenie /etc/rc.d/init.d/functions.

Jeśli Twój proces zabezpieczeń wymaga skonfigurowania uprawnień w klastrze /etc/rc.d/init.d/functions, nie ustawiaj ich na wartość 700, ponieważ inaczej router się nie uruchomi.

Aby zezwolić na odczyt pliku /etc/rc.d/init.d/functions, możesz ustawić uprawnienia na 744.
opiekun zoologiczny /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 każdego obszaru kluczy Edge określa węzły Cassandra, w których umieszczane są repliki. Więcej informacji znajdziesz w artykule Informacje o współczynniku replikacji i poziomie spójności Cassandra.

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

Po zainstalowaniu Edge dla Private Cloud możesz sprawdzić, czy Cassandra jest prawidłowo skonfigurowana, sprawdzając plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Sprawdź na przykład, czy skrypt instalacji Edge for Private Cloud ma ustawione 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 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 procesorach wiadomości ustawiono te limity systemu:

  • W węzłach Cassandra ustaw limity memlock i twardych (memlock), nofile oraz przestrzeni adresowej (jako) 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
  • W węzłach procesora wiadomości ustaw maksymalną liczbę 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. Stanie się tak, jeśli na przykład masz otwartych w tym samym czasie dużą liczbę plików tymczasowych.

Usługi zabezpieczeń sieci (NSS)

Network Security Services (NSS) to zestaw bibliotek, które ułatwiają tworzenie z włączonymi zabezpieczeniami aplikacji klienckich i serwerowych. Sprawdź, czy masz zainstalowaną wersję 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 przygotowanym przez RedHat.

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

Jeśli zainstalowano i włączono demon pamięci podręcznej usługi NSCD (NSCD), procesory wiadomości 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. W każdym węźle procesora wiadomości edytuj /etc/nscd.conf
  2. Ustaw tę właściwość: 
    enable-cache hosts no

Wyłącz protokół 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 dotyczące wyłączania protokołu IPv6 znajdziesz w dokumentacji systemu RedHat lub CentOS dotyczącego 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, musisz najpierw uruchomić to polecenie:

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

Narzędzia,

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

awk

expr

libxlst

obr./min

unzip

basename

grep

Lua-Socket

rpm2cpio

dodanie użytkownika

powłoka bash

 nazwa hosta

ls

sed

wc

bc

id

net-tools

sudo

Wget

curl

Libaio

perl (z usługi Procps)

smoła

Xerces-C
Cyrus-Sasl libdb4 pgrep (z procps) tr mniam

data

 libdb-cxx

ps

uuid

konfiguracja chkconfig
dirname libibverbs pwd uname  
echo librdmacm python    

nieaktualny

Apigee zaleca synchronizację czasów działania serwerów. Może to służyć narzędzie ntpdate, które sprawdza, czy serwery są synchronizowane pod kątem czasu. Możesz zainstalować narzędzie za pomocą yum install ntp. Jest to szczególnie przydatne w przypadku 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 instalacji Edge pobiera i instaluje OpenLDAP. Jeśli serwer nie ma połączenia z internetem, przed uruchomieniem skryptu instalacji Edge musisz upewnić się, że interfejs OpenLDAP jest już zainstalowany. W systemie RHEL/CentOS możesz uruchomić yum install openldap-clients openldap-servers, aby zainstalować OpenLDAP.

W przypadku instalacji 13-hostowych i 12-hostowych 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 IT, dlatego dotyczy wdrożenia Apigee Edge na potrzeby wdrożenia chmury prywatnej i hostów wirtualnych. Uściślijmy, że termin virtual ma 2 główne zastosowania:

  • Maszyny wirtualne: niewymagane, 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 sieci – analogicznie do hosta wirtualnego Apache.

Router w maszynie wirtualnej może ujawniać 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ą być uruchomione 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że maszyna „VM1” ujawnia interfejs wirtualnej sieci Ethernet, który otrzymuje w maszynie wirtualnej adres „eth0” i który ma przypisany adres IP 111.111.111.111 przez maszynę wirtualizacji lub serwer DHCP sieci. Załóżmy, że VM2 ujawnia interfejs wirtualnej sieci Ethernet również 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 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 2 ujawnia łącze api.mycompany.com:80 (ta sama nazwa i port, które są dostępne dla maszyny wirtualnej VM1).

Fizyczny system operacyjny 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 również musi zezwalać na łączenie się ruchu przez porty 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ć przez Ciebie 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 rozdzielający 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. Powyższy przykład pozwala wdrożyć 2 interfejsy API (mycompany i testmycompany) w organizacji mycompany-org z hostem wirtualnym o aliasie hosta api.mycompany.com i portem ustawionym 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ć przychodzące żądania.

Jeśli jednak wdrożysz interfejs API testmycompany pod podstawowym adresem URL /salesdemo, użytkownicy będą mieli dostęp do tego interfejsu API za pomocą: http://api.mycompany.com:80/salesdemo. Jeśli wdrożysz interfejs API mycompany przy użyciu podstawowego adresu 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 uzyskanego z Apigee. Podczas instalowania serwera zarządzania musisz podać ścieżkę do pliku licencji, na przykład /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 sprawdza datę wygaśnięcia i liczbę dozwolonych procesorów wiadomości (MP). Jeśli któreś z ustawień licencji wygasło, możesz znaleźć dzienniki 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 działem sprzedaży Apigee.