Wymagania dotyczące instalacji

Wymagania sprzętowe

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

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

Dla 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 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ż wymieniono poniżej.

Element instalacyjny Pamięć 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* Od 500 GB do 1 TB** pamięci sieciowej***, najlepiej z backendem SSD, który obsługuje 1000 IOPS lub więcej*
Analytics – instancja główna lub gotowości Postgres (samodzielna) 16GB* 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 pamięci lokalnej z dyskiem SSD

Domyślny rozmiar kolejki Qpid to 1 GB, który można zwiększyć do 2 GB. Jeśli potrzebujesz więcej miejsca, dodaj dodatkowe węzły Qpid.
Serwer OpenLDAP/UI/zarządzania 8 GB 4-rdzeniowy 60GB
Interfejs użytkownika/serwer zarządzania 4 GB 2-rdzeniowy 60GB
OpenLDAP (samodzielny) 4 GB 2-rdzeniowy 60GB

* Dostosuj wymagania systemowe Postgres na podstawie przepustowości:

  • Mniej niż 250 TPS: 8 GB, 4-rdzeniowy procesor lub zarządzane miejsce na dane*** obsługujące 1000 IOPS lub więcej
  • Więcej niż 250 TPS: 16 GB, 8-rdzeniowy, zarządzana pamięć sieciowa*** z obsługą co najmniej 1000 IOPS
  • Więcej niż 1000 TPS: 16 GB, 8-rdzeniowy, zarządzana pamięć sieciowa*** z obsługą co najmniej 2000 IOPS
  • Więcej niż 2000 TPS: 32 GB, 16-rdzeniowy, zarządzana pamięć sieciowa*** z obsługą co najmniej 2000 IOPS
  • Więcej niż 4000 TPS: 64 GB, 32-rdzeniowy, zarządzana pamięć sieciowa*** z obsługą co najmniej 4000 IOPS

** Wartość dysku twardego Postgres jest określana na podstawie gotowych statystyk przechwyconych 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

*** W przypadku bazy danych Postgresql zalecamy korzystanie z Network Storage, ponieważ:

  • Umożliwia dynamiczne skalowanie rozmiaru pamięci masowej, jeśli jest to konieczne.
  • IOPS sieci można dostosowywać na bieżąco w większości współczesnych podsystemów środowiska, pamięci masowej i sieci.
  • Zrzuty miejsca na dane można włączyć w ramach rozwiązań do tworzenia kopii zapasowych i przywracania.

Oprócz tego poniżej znajdziesz wymagania dotyczące sprzętu, które muszą być spełnione, aby można było zainstalować usługi zarabiania (nie są one obsługiwane w przypadku instalacji wielofunkcyjnej):

Komponent z zarabianiem Pamięć RAM CPU Dysk twardy
Serwer zarządzania (z usługami do zarabiania) 8 GB 4-rdzeniowy 60GB
Analytics – Postgres/Qpid na tym samym serwerze 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 – instancja główna lub tryb gotowości Postgres niezależnie 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 pamięci lokalnej na dysku SSD lub szybkim HDD

W przypadku instalacji większych niż 250 TPS zalecamy dysk HDD z pamięcią lokalną obsługującą 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 oraz oprogramowaniu innych firm wymienionych na liście 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 Edge mogą napotkać 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 Edge apigee-setup.

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 uruchomić 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ę 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 utworzyć użytkownika i grupę o nazwie „apigee”. To ta sama grupa i użytkownik utworzone przez instalator Edge.

Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku Bostrap_4.52.02.sh. Musisz wykonać wszystkie te czynności 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 adresu /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ń prawo własności do 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 dla nazwy hosta, który można zaadresować z innych komputerów.

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 kilka kart interfejsu, polecenie „nazwa hosta -i” zwraca listę adresów IP oddzielonych spacjami. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, co może nie zawsze być poprawne. Możesz też ustawić tę właściwość w pliku konfiguracji instalacji:

ENABLE_DYNAMIC_HOSTIP=y

Gdy właściwość ma wartość „y”, instalator prosi o wybranie adresu IP, którego chcesz użyć podczas instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji pliku konfiguracji brzegowej.

Kody TCP

Opakowania TCP mogą blokować komunikację niektórych portów i mogą 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 brzegowych. W razie potrzeby możesz zatrzymać iptables podczas instalacji przy użyciu polecenia:

sudo/etc/init.d/iptables stop

W systemie CentOS 7.x:

systemctl stop firewalld

Dostęp do katalogu

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

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

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

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

Aby zezwolić na dostęp z możliwością odczytu do instancji /etc/rc.d/init.d/functions, możesz ustawić uprawnienia na poziomie 744.
Miłośnik zoo /dev/random Biblioteka klienta Zookeeper wymaga uprawnień do odczytu generatora liczb losowych /dev/random. Jeśli /dev/random jest zablokowany 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żdej przestrzeni kluczy Edge określa węzły Cassandra, w których są umieszczone repliki. Więcej informacji znajdziesz w artykule Informacje o współczynniku replikacji Cassandra i poziomie spójności.

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

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. Upewnij się na przykład, że skrypt instalacji Edge for Private Cloud 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 wymienione powyżej właściwości.
  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 procesora ustawiono następujące 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
  • W węzłach procesora wiadomości ustaw maksymalną liczbę otwartych deskryptorów plików w /etc/security/limits.d/90-apigee-edge-limits.conf na 64 tys., 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 procesorze wiadomości system.log kiedykolwiek zobaczysz ten błąd, być może masz ustawione zbyt niskie limity deskryptora plików:

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

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

    # su - apigee
$ ulimit -n
100000

    Jeśli po ustawieniu limitów deskryptora plików na 100000 nadal osiągasz limity otwartych plików, prześlij zgłoszenie do zespołu pomocy Apigee Edge, aby uzyskać dalsze sposoby rozwiązywania problemów.

Usługi bezpieczeństwa sieci (NSS)

Usługi Network Security Services (NSS) to zbiór bibliotek, które obsługują tworzenie aplikacji klienckich i serwerowych z włączonym zabezpieczeniami. Sprawdź, czy masz zainstalowany NSS w wersji 3.19 lub nowszej.

Aby sprawdzić bieżącą 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 demon pamięci podręcznej usługi nazw (NSCD), procesory komunikatów wykonują dwa wyszukiwania DNS: jedno dla IPv4 i jedno dla IPv6. Gdy używasz NSCD, wyłącz wyszukiwanie DNS w IPv6.

Aby wyłączyć wyszukiwanie DNS w IPv6:

  1. Edytuj /etc/nscd.conf w każdym węźle procesora wiadomości.
  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 na RedHat 7 lub CentOS 7 w Google Cloud Platform, musisz wyłączyć protokół IPv6 we wszystkich węzłach Qpid.

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

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

AWS AMI,

Jeśli instalujesz Edge na obrazie AWS Amazon Machine Image (AMI) dla systemu 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 wersji standardowej narzędzi systemu UNIX (zgodnie z danymi EL5 lub EL6).

awk

expr

libxlst

obr./min

unzip

basename

grep

Lua-Socket

rpm2cpio

dodawanie 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    

ntpdate

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

openldap 2.4

Lokalna instalacja wymaga OpenLDAP 2.4. Jeśli serwer ma połączenie z internetem, skrypt instalacji 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 protokół 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 12 hostów 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 obszarach IT, dlatego dotyczy go Apigee Edge dla wdrożenia w chmurze prywatnej i hostów wirtualnych. Aby wyjaśnić, że termin virtual ma 2 główne zastosowania:

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

Router maszyny 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: pojedynczy serwer fizyczny A może używać 2 maszyn wirtualnych o nazwach „VM1” i „VM2”. Załóżmy, że maszyna wirtualna „VM1” ujawnia interfejs wirtualnej sieci Ethernet o nazwie „eth0” w maszynie wirtualnej i ma przypisany adres IP 111.111.111.111 przez maszynę wirtualizację lub serwer DHCP sieci. Następnie załóżmy, że VM2 udostępnia interfejs wirtualnej sieci Ethernet również o nazwie „eth0”, do którego przypisywany jest adres IP 111.111.111.222.

W każdej z 2 maszyn wirtualnych może działać router Apigee. 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 konkretny 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 udostępnione przez maszynę wirtualną1).

System operacyjny fizycznego hosta może mieć zaporę sieciową. W takim przypadku zapora sieciowa musi być skonfigurowana tak, aby przekazywać ruch TCP do portów udostępnianych w zwirtualizowanych interfejsach (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 także musi zezwalać na połączenie przez porty 80 i 443.

Ścieżka bazowa to trzeci komponent zaangażowany w kierowanie wywołań interfejsu API do różnych serwerów proxy interfejsu API, które mogły zostać wdrożone. Pakiety serwerów proxy interfejsów API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki bazowe. Na przykład jedna ścieżka bazowa może być zdefiniowana jako http://api.mycompany.com:80/, a druga jako http://api.mycompany.com:80/salesdemo.

W tym przypadku potrzebujesz systemu równoważenia obciążenia lub dyrektora ruchu, który rozdziela 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 dotyczy konkretnej 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, dla organizacji mycompany-org z hostem wirtualnym, którego alias hosta to api.mycompany.com, a port ustawiony na 80. Jeśli nie zadeklarujesz ścieżki podstawowej we wdrożeniu, router nie wie, 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 wdrażasz interfejs API w swojej firmie za pomocą 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 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 komunikatów (MP). 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 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.