Wymagania dotyczące instalacji

Edge for Private Cloud wer. 4.16.05

Wymagania sprzętowe

Aby zapewnić wysoką dostępność infrastruktury w środowisku produkcyjnym, musisz spełniać poniższe minimalne wymagania sprzętowe. W przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji tabele poniżej zawierają minimalne wymagania sprzętowe dotyczące komponentów 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.

Poniżej znajdziesz też wymagania sprzętowe, które musisz spełnić, jeśli chcesz zainstalować usługi zarabiania:

Poniżej znajdziesz listę wymagań sprzętowych, które należy spełnić, aby zainstalować API BaaS:

Uwaga:

• Jeśli główny system plików nie jest wystarczająco duży, by przeprowadzić instalację, zalecamy umieszczenie danych na większym dysku.
• Jeśli na komputerze była zainstalowana starsza wersja Apigee Edge for Private Cloud, przed nową instalacją usuń folder /tmp/java.
• Aby uruchomić Cassandra, folder tymczasowy /tmp obejmujący cały system wymaga uprawnień do wykonywania.
• Jeśli przed instalacją został utworzony użytkownik „apigee”, sprawdź, czy „/home/apigee” istnieje jako katalog główny i czy należy on do „apigee:apigee”.

Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm

Te instrukcje instalacji i dołączone pliki instalacyjne zostały przetestowane pod kątem systemów operacyjnych i oprogramowania innej firmy wymienionych na stronie https://apigee.com/docs/api-services/reference/supported-software.

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. Przykład znajdziesz w sekcji „Wiązanie routera z zabezpieczonym portem” artykułu Instalowanie komponentów Edge w węźle.

Katalog instalacji

Domyślnie instalator zapisuje wszystkie pliki w katalogu /opt/apigee. Nie możesz zmienić tej lokalizacji w katalogu.

W instrukcjach w tym przewodniku katalog instalacji jest oznaczony jako /<inst_root>/apigee, gdzie /<inst_root> domyślnie ma wartość /opt.

Java

Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja środowiska Java1.8. Listę obsługiwanych pakietów JDK znajdziesz:

https://apigee.com/docs/api-services/reference/supported-software

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

Ustawienia sieci

Zalecamy sprawdzenie ustawień sieci przed rozpoczęciem instalacji. Instalator oczekuje, że wszystkie maszyny mają stałe adresy IP. Aby sprawdzić ustawienie, użyj tych poleceń:

• hostname zwraca nazwę komputera
• nazwa_hosta -i zwraca adres IP nazwy hosta, którą można zaadresować z innych komputerów.

W zależności od typu i wersji systemu operacyjnego być może trzeba będzie edytować pliki /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta jest nieprawidłowo ustawiona. Więcej informacji znajdziesz w dokumentacji używanego systemu operacyjnego.

Cassandra

Wszystkie węzły Cassandra muszą być połączone z pierścieniem.

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 /<inst_root>/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
• parter
• nasiona
• listen_address
• rpc_address
• szpieg

Ostrzeżenie: nie edytuj tego pliku.

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 postgresql.properties:
   > vi /<inst_root>/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:
   > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

jsvc

Element „jsvc” jest wymagany do korzystania z interfejsu API BaaS. Podczas instalacji interfejsu API BaaS instalowana jest wersja 1.0.15-dev.

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 na kanale RedHat.

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.

Uwaga:

• Plik wykonywalny narzędzia „useradd” znajduje się w katalogu /usr/sbin, a plik chkconfig w pliku /sbin.
• Dostęp do sudo pozwala uzyskać dostęp do środowiska użytkownika wywołującego. Zazwyczaj możesz użyć polecenia „sudo <command>” lub „sudo PATH=$PATH:/usr/sbin:/sbin <command>”.
• Sprawdź, czy przed instalacją pakietu Service Pack (poprawki) jest zainstalowane narzędzie „Popraw”.

ntpdate – zaleca się synchronizację czasu serwerów. Może to być narzędzie „ntpdate”, które sprawdza, czy serwery są synchronizowane pod względem czasu. Aby zainstalować to narzędzie, możesz użyć polecenia „yuminstall 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ć polecenie „yum apply 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

Pojęcie „wirtualne” jest często przeciążone w branży IT, dlatego odnosi się do wdrożenia Apigee Edge dla Private Cloud i hostów wirtualnych. Uściślijmy, że termin „wirtualny” 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. Te instrukcje instalacji nie dotyczą konkretnie instalacji maszyn wirtualnych.
• 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).

Podobnie jak w przypadku nazwy, pojedynczy serwer fizyczny „A” może uruchomić 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że maszyna wirtualna VM1 ujawnia wirtualny interfejs Ethernetu, który otrzymuje w maszynie wirtualnej eth0 i który ma przypisany adres IP 111.111.111.111 przez interfejs wirtualizacji, a maszyna wirtualna DH1.

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 (z określonym adresem IP), api.mojafirma.com:80, api.mycompany.com:443 i api.mycompany.com:443.

Router w maszynie wirtualnej 2 udostępnia adres api.mycompany.com:80 (ta sama nazwa i port co w przypadku VM1).

System operacyjny fizycznego hosta może mieć zaporę sieciową. W takim przypadku zapora sieciowa musi być skonfigurowana w taki sposób, 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/ i drugą jako http://api.mycompany.com:80/.

W tym przypadku potrzebny jest system równoważenia obciążenia lub dyrektor ruchu rozdzielający ruch http://api.mojafirma.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ć dwa interfejsy API – mojafirma i testmojafirma dla organizacji moja-firma-organizacja z hostem wirtualnym o aliasie hosta api.mojafirma.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 przy użyciu podstawowego adresu URL /salesdemo, użytkownicy będą mieli dostęp do tego interfejsu API, korzystając z adresu http://api.mycompany.com:80/salesdemo. Jeśli wdrożysz interfejs API mojafirma z podstawowym adresem URL /, użytkownicy będą uzyskiwać dostęp do interfejsu API za pomocą adresu URL http://api.mycompany.com:80/.

Wymagania dotyczące portu brzegowego

Konieczność zarządzania zaporą sieciową wykracza poza hosty wirtualne. Zarówno maszyny wirtualne, jak i fizyczne zapory sieciowe muszą zezwalać na ruch na portach wymaganych przez komponenty do komunikacji ze sobą.

Poniższa ilustracja przedstawia wymagania dotyczące portów w przypadku każdego komponentu Edge:

Uwagi do tego diagramu:

• *Port 8082 w procesorze wiadomości musi być otwarty na dostęp dla routera tylko podczas konfigurowania protokołu TLS/SSL między routerem i procesorem wiadomości. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem wiadomości, domyślna konfiguracja, port 8082 nadal musi być otwarty w procesorze wiadomości, aby można było zarządzać komponentem, ale router nie wymaga do niego dostępu.
• Porty z prefiksem „M” to porty używane do zarządzania komponentem. Muszą one być otwarte w komponencie, aby mógł uzyskać do niego dostęp serwer zarządzania.
• Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: Router, procesor wiadomości, interfejs użytkownika, Postgres i Qpid.
• Jako port zarządzania komponent przetwarzający wiadomości musi otworzyć port 4528. Jeśli masz kilka procesorów wiadomości, wszystkie muszą mieć dostęp do siebie przez port 4528 (co wskazuje strzałka zapętlenia na diagramie powyżej dla portu 4528 takiego procesora). Jeśli masz kilka centrów danych, port musi być dostępny dla wszystkich podmiotów przetwarzających wiadomości we wszystkich centrach danych.
• Nie jest to wymagane, ale możesz otworzyć port 4527 w routerze, aby uzyskać dostęp dla dowolnego procesora wiadomości. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawiać się komunikaty o błędach.
• Router musi mieć otwarty port 4527 jako port zarządzania. Jeśli masz kilka routerów, wszystkie muszą mieć dostęp do siebie przez port 4527 (na co wskazuje strzałka w pętli na diagramie powyżej 4527 w routerze).
• Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API w celu obsługi przycisku Wyślij w narzędziu do śledzenia.
• Serwer zarządzania wymaga dostępu do portu JMX w węzłach Cassandra.
• Dostęp do portów JMX można skonfigurować tak, aby wymagać podania nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule Jak monitorować.
• Opcjonalnie możesz skonfigurować dostęp TLS/SSL dla niektórych połączeń, które mogą używać różnych portów. Więcej informacji znajdziesz w sekcji TLS/SSL.
• W przypadku konfigurowania 2 węzłów Postgres do używania replikacji gotowości mastera w każdym węźle musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH. Aby umożliwić dostęp przez SSH, możesz opcjonalnie otworzyć porty w poszczególnych węzłach.
• Serwer zarządzania i interfejs użytkownika Edge możesz skonfigurować tak, aby wysyłać e-maile przez zewnętrzny serwer SMTP. Jeśli to zrobisz, musisz się upewnić, że serwer zarządzania i interfejs użytkownika mają dostęp do potrzebnego portu na serwerze SMTP. W przypadku serwera SMTP bez szyfrowania TLS numer portu to zwykle 25. W przypadku SMTP z włączonym protokołem TLS jest to często wartość 465, ale skontaktuj się z dostawcą SMTP.

W tabeli poniżej znajdziesz porty, które należy otworzyć w zaporach sieciowych za pomocą komponentu Edge:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

W następnej tabeli znajdziesz te same porty wymienione liczbowo z komponentami źródłowymi i docelowymi:

Procesor wiadomości utrzymuje dedykowaną pulę połączeń otwartą dla systemu Cassandra, która jest skonfigurowana tak, aby nigdy nie przekraczać limitu czasu. Jeśli zapora sieciowa znajduje się między procesorem wiadomości a serwerem Cassandra, może ona przekroczyć limit czasu na połączenie. Procesor wiadomości nie służy jednak do przywracania połączeń z Cassandra.

Aby zapobiec takiej sytuacji, Apigee zaleca, aby serwer Cassandra, procesor wiadomości i routery były w tej samej podsieci, dzięki czemu zapora sieciowa nie uczestniczy we wdrożeniu tych komponentów.

Jeśli zapora sieciowa znajduje się między routerem a procesorami wiadomości i ma ustawiony czas oczekiwania na bezczynności tcp, zalecamy wykonanie tych czynności:

1. Ustaw wartość net.ipv4.tcp_keepalive_time = 1800 w ustawieniach sysctl w systemie operacyjnym Linux, gdzie wartość 1800 powinna być mniejsza niż limit czasu bezczynności tcp zapory sieciowej. To ustawienie powinno utrzymać połączenie w stanie ugruntowanym, aby zapora sieciowa nie rozłączała go.
2. We wszystkich procesorach wiadomości edytuj /<inst_root>/apigee/customer/application/message-processor.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.
   conf_system_casssandra.maxconnecttimeinmillis=-1
3. Ponownie uruchom procesor wiadomości:
   > /opt/apigee/apigee-service/bin/apigee-service Edge-message-processor restart
4. We wszystkich routerach edytuj /<inst_root>/apigee/customer/application/router.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.
   conf_system_casssandra.maxconnecttimeinmillis=-1
5. Ponownie uruchom router:
   > /opt/apigee/apigee-service/bin/apigee-service Edge-router restart

W przypadku zainstalowania klastrowanej konfiguracji 12 hostów z 2 centrami danych upewnij się, że węzły w obu centrach danych mogą komunikować się przez porty wymienione poniżej:

Wymagania dotyczące portu API BaaS

Jeśli zdecydujesz się zainstalować interfejs API BaaS, musisz dodać komponenty stosu API BaaS i API BaaS Portal. Porty te korzystają z portów wymienionych na ilustracji poniżej:

Uwagi do tego diagramu:

• Węzły Cassandra mogą być przeznaczone dla API BaaS lub mogą być udostępniane Edge.
• Instalacja produkcyjna API BaaS używa systemu równoważenia obciążenia między węzłem API BaaS Portal i węzłami stosu API BaaS. Podczas konfigurowania portalu i wykonywania wywołań interfejsu BaaS API podajesz adres IP lub nazwę DNS systemu równoważenia obciążenia, a nie węzłów stosu.
• Musisz skonfigurować wszystkie węzły stosu Baas do wysyłania e-maili przez zewnętrzny serwer SMTP. W przypadku serwera SMTP bez szyfrowania TLS numer portu to zwykle 25. W przypadku SMTP z włączonym protokołem TLS jest to często wartość 465, ale skontaktuj się z dostawcą SMTP.

Poniższa tabela przedstawia domyślne porty, które należy otworzyć w zaporze sieciowej, według komponentu:

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 katalogu /<inst_root>/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, logi znajdziesz w tej lokalizacji: /<inst_root>/apigee/var/log/edge-management-server/logs. W takim przypadku możesz skontaktować się z zespołem pomocy Apigee, aby uzyskać szczegółowe informacje o migracji.