Wymagania dotyczące instalacji

Edge for Private Cloud, wersja 4.18.01

Wymagania sprzętowe

Aby uzyskać wysoką dostępność infrastruktury w środowisku produkcyjnym, musisz spełnić te minimalne wymagania sprzętowe. W przypadku wszystkich scenariuszy instalacji opisanych w sekcji Topologie instalacji w tabelach poniżej podano minimalne wymagania sprzętowe dotyczące komponentów instalacyjnych.

W tych tabelach oprócz miejsca na dysku twardym wymaganego przez system operacyjny wymagane są też wymagania dotyczące dysku twardego. W zależności od aplikacji i ruchu w sieci instalacja może wymagać większych lub mniejszej ilości zasobów niż wymieniona poniżej.

Jeśli chcesz zainstalować Usługi zarabiania, poniżej znajdziesz też wymagania sprzętowe:

Jeśli chcesz zainstalować BaaS API, poniżej znajdziesz listę wymagań sprzętowych:

Wymagania dotyczące systemu operacyjnego i oprogramowania innej firmy

Te instrukcje instalacji i dołączone pliki instalacyjne zostały przetestowane na systemach operacyjnych i w oprogramowaniu innej firmy z listy Obsługiwane oprogramowanie i obsługiwane wersje.

Tworzenie użytkownika Apigee

Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki Edge są własnością „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge uruchamiają się 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 katalogu. Nie możesz zmienić tego katalogu, ale możesz utworzyć dowiązanie symboliczne, aby zmapować /opt/apigee na inną lokalizację zgodnie z opisem poniżej.

W instrukcjach w tym przewodniku katalog instalacji będzie oznaczony jako /opt/apigee.

Tworzenie dowiązania symbolicznego z /opt/apigee

Zanim utworzysz dowiązanie symboliczne, musisz najpierw utworzyć użytkownika i grupę o nazwie „apigee”. Jest to ta sama grupa i ten sam użytkownik, które utworzył instalator Edge.

Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku rozruchowego _4.18.01.sh. Wszystkie te czynności musisz wykonać jako 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 żądanego elementu głównego instalacji:

   ln -Ts /srv/myInstallDir /opt/apigee

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

3. Zmień właściciela głównego katalogu instalacji i linku symbolowego na użytkownika „apigee”:

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Java

Przed instalacją musisz mieć zainstalowaną obsługiwaną wersję środowiska Java 1.8. Obsługiwane pakiety JDK znajdziesz w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.

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

SELinux

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

Ustawienia sieci

Zalecamy sprawdzenie ustawienia sieci przed instalacją. Instalator oczekuje, że wszystkie komputery mają stałe adresy IP. Aby sprawdzić ustawienie, użyj tych poleceń:

• hostname zwraca nazwę komputera
• hostname -i zwraca adres IP nazwy hosta, do którego można uzyskać dostęp z innych komputerów.

W zależności od typu i wersji systemu operacyjnego konieczne może być edytowanie właściwości /etc/hosts i /etc/sysconfig/network, jeśli nazwa hosta nie jest prawidłowo skonfigurowana. Więcej informacji znajdziesz w dokumentacji konkretnego systemu operacyjnego.

Jeśli serwer ma wiele kart interfejsu, polecenie „nazwa-hosta -i” zwraca oddzieloną spacjami listę adresów IP. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, który może nie być prawidłowy w niektórych sytuacjach. Zamiast tego możesz ustawić w pliku konfiguracji instalacji tę właściwość:

ENABLE_DYNAMIC_HOSTIP=y

Gdy właściwość ma wartość „y”, instalator poprosi Cię o wybranie adresu IP, który zostanie użyty podczas instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji plików krańcowych.

Kody TCP

Paczki TCP mogą blokować komunikację między niektórymi portami oraz 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ń portów wymaganych przez porty OpenLDAP, Postgres i Cassandra.

iptablety

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

Upewnij się, że router graniczny ma dostęp do katalogu /etc/rc.d/init.d/functions

Węzły Edge Router i BaaS Portal używają routera Nginx i wymagają dostępu do odczytu do /etc/rc.d/init.d/functions.

Jeśli proces zabezpieczeń wymaga ustawienia uprawnień w /etc/rc.d/init.d/functions, nie ustawiaj wartości 700. W przeciwnym razie router nie uruchomi się. Można ustawić uprawnienia 744, aby umożliwić dostęp w trybie odczytu do /etc/rc.d/init.d/functions.

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 sekcji Informacje o poziomie replikacji i spójności poziomu Cassandra.

Cassandra automatycznie dostosowuje rozmiar sterty środowiska Java na podstawie dostępnej pamięci. Więcej informacji znajdziesz w artykule na temat dostrajania zasobów Java. W przypadku pogorszenia wydajności lub dużego zużycia pamięci.

Po zainstalowaniu Edge dla Private Cloud możesz sprawdzić, czy Cassandra jest poprawnie skonfigurowana, analizując plik /opt/apigee/apigee-cassandra/conf/cassandra.yaml. Na przykład upewnij się, że skrypt instalacyjny 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ć następujące 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.property:

   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. Ponowne uruchamianie bazy danych PostgreSQL:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Ograniczenia systemu

Sprawdź, czy w węzłach Cassandra i Procesor wiadomości ustawiono następujące limity systemowe:

• W węzłach Cassandra ustaw miękkie i twarde memlock, nofile i przestrzeń adresową (as) dla użytkownika instalacji (domyślnie jest to „apigee”) w /etc/security/limits.d/90-apigee-edge-limits.conf:

  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 regionie /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. na przykład jeśli w danym momencie masz otwartych dużą liczbę plików tymczasowych.

JSV

„jsvc” jest warunkiem korzystania z interfejsu BaaS API. Podczas instalacji interfejsu API BaaS zostanie zainstalowana wersja 1.0.15-dev.

Usługi zabezpieczeń sieci

Network Security Services (NSS) to zbiór bibliotek, które obsługują aplikacje klienckie i serwerowe z włączoną obsługą zabezpieczeń. Pamiętaj, aby zainstalować 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 (platforma Nazwa pamięci podręcznej usługi)

Jeśli zainstalowano i włączono NSCD (Name Service Cache Deemon), firmy obsługujące wiadomości przetwarzają dwa zapytania 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 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.

W dokumentacji odpowiedniej wersji systemu operacyjnego RedHat lub CentOS znajdziesz instrukcje dotyczące wyłączania protokołu IPv6. Na przykład możesz:

1. Otwórz plik /etc/hosts w edytorze.
2. Wstaw znak „#” w kolumnie w jednym z tych wierszy, aby dodać komentarz:

   #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

3. Zapisz plik.

AWS AMI,

Jeżeli instalujesz Edge na komputerze 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 poniższych narzędzi UNIX w wersji standardowej, które udostępnia EL5 lub EL6.

Natywne

Zaleca się synchronizowanie godzin korzystania z serwerów. Jeśli nie masz jeszcze skonfigurowanego tego narzędzia, narzędzie ntpdate może sprawdzić, czy serwery są synchronizowane. Do zainstalowania narzędzia możesz użyć polecenia yum install ntp. Jest to szczególnie przydatne do replikowania konfiguracji OpenLDAP. Pamiętaj, że konfigurujesz strefę czasową serwera w strefie czasowej UTC.

openldap 2.4

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

W przypadku instalacji z 13 hostów i 12 hostów z 2 centrami danych wymagasz replikacji OpenLDAP, ponieważ istnieje wiele węzłów hostujących OpenLDAP.

Zapory sieciowe i hosty wirtualne

Termin virtual jest zwykle przeciążany w hali IT, więc wraz z Apigee Edge do wdrożenia chmury prywatnej i hostów wirtualnych. Aby rozwiać wątpliwości, termin virtual występuje w 2 głównych zastosowaniach:

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

Router w maszynie wirtualnej może udostępniać wiele hostów wirtualnych (o ile różnią się od siebie za pomocą aliasu hosta lub portu interfejsu).

Tak jak w przypadku nazewnictwa, jeden fizyczny serwer A może używać 2 maszyn wirtualnych o nazwie „VM1” i „VM2”. Załóżmy, że „VM1” udostępnia wirtualny interfejs Ethernet, który otrzymuje nazwę „eth0” w maszynie wirtualnej i przypisuje jej adres IP 111.111.111.111 maszynie wirtualnej lub serwerowi DHCP. Następnie załóżmy, że VM2 udostępnia wirtualny interfejs Ethernet o nazwie „eth0” i przypisuje mu adres IP 111.111.111.222.

W każdej z tych maszyn wirtualnych może być uruchomiony router Apigee. Routery ujawniają punkty końcowe hosta wirtualnego w następujący sposób:

Router Apigee w VM1 udostępnia 3 hosty wirtualne w interfejsie eth0 (z określonym adresem IP), api.mycompany.com:80, api.mycompany.com:443 i test.mycompany.com:80.

Router w VM2 udostępnia api.mycompany.com:80 (tę samą nazwę i port co w VM1).

System operacyjny hosta fizycznego może mieć zaporę sieciową. W takim przypadku musisz skonfigurować zaporę sieciową tak, aby przekazywała ruch TCP dla portów widocznych w 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ę sieciową w interfejsie eth0. Muszą one też zezwalać na połączenia z portami 80 i 443.

Ścieżka bazowa to trzeci komponent kierowania wywołań interfejsu API do różnych wdrożonych serwerów proxy interfejsu API. Pakiety proxy serwera API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki podstawowe. Na przykład jedną ścieżkę podstawową można zdefiniować jako http://api.mycompany.com:80/, a inną jako http://api.mycompany.com:80/salesdemo.

W takim przypadku potrzebujesz systemu równoważenia obciążenia lub dyrektora ruchu, który podzieli ruch http://api.mycompany.com:80/ między 2 adresy IP (111.111.111.111 w VM1 i 111.111.111.222 w VM2). Ta funkcja jest charakterystyczna dla Twojej instalacji i jest konfigurowana przez lokalną grupę sieciową.

Ścieżka bazowa jest ustawiana podczas wdrażania interfejsu API. Z przykładu powyżej możesz wdrożyć 2 interfejsy API – mycompany i testmycompany – w organizacji mycompany-org z hostem 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 wiedział, do którego interfejsu API wysłać żądania przychodzące.

Jeśli jednak wdrożysz interfejs testmycompany za pomocą podstawowego adresu URL /salesdemo, użytkownicy będą mieli do niego dostęp przez http://api.mycompany.com:80/salesdemo. Jeśli wdrażasz interfejs API w interfejsie API firmy o podstawowym adresie URL /, użytkownicy uzyskują dostęp do interfejsu API za pomocą adresu URL http://api.mycompany.com:80/.

Wymagania dotyczące portu brzegowego

Potrzeba zarządzania zaporą sieciową wykracza poza sam host wirtualny. Zapory sieciowe maszyn wirtualnych i hostów fizycznych muszą zezwalać na ruch między portami wymaganymi przez komponenty.

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

Uwagi na tym schemacie:

• * Aby można było korzystać z routera obsługującego wiadomości, port 8082 musi być otwarty tylko podczas konfiguracji routera TLS/SSL między routerem a procesorem wiadomości. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem wiadomości, port domyślny 8082 będzie musiał być otwarty w edytorze wiadomości, aby zarządzać komponentem, ale router nie wymaga do niego dostępu.
• Porty poprzedzone symbolem „M” to porty używane do zarządzania komponentem. Muszą być otwarte w komponencie i muszą być otwarte w komponencie, aby miał dostęp do serwera zarządzania.
• Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor wiadomości, interfejs użytkownika, Postgres i Qpid.
• Podmiot przetwarzający wiadomości musi otworzyć port 4528 jako port zarządzania. Jeśli masz wiele podmiotów przetwarzających wiadomości, każdy z nich musi mieć dostęp do siebie przez port 4528 (wskazuje to pętla na diagramie powyżej portu 4528). Jeśli masz wiele 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 na routerze, aby uzyskać dostęp do dowolnego procesora wiadomości. W przeciwnym razie w plikach dziennika procesora wiadomości mogą pojawić się komunikaty o błędach.
• Router musi mieć port 4527 jako port zarządzania. Jeśli masz wiele routerów, muszą one mieć dostęp do siebie przez port 4527 (wskazuje to pętla na schemacie powyżej dotyczący portu 4527 na routerze).
• Interfejs brzegowy wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API, aby można było obsługiwać przycisk 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ły nazwy użytkownika i hasła. Więcej informacji znajdziesz w artykule Jak monitorować.
• Opcjonalnie możesz skonfigurować dostęp TLS/SSL do określonych połączeń, które mogą używać różnych portów. Więcej informacji znajdziesz na stronie TLS/SSL.
• Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji master-standby, musisz otworzyć port 22 w każdym węźle, aby uzyskać dostęp przez SSH. Opcjonalnie możesz otworzyć porty w poszczególnych węzłach, aby umożliwić dostęp przez SSH.
• Możesz skonfigurować serwer zarządzania i interfejs użytkownika Edge do wysyłania e-maili przez zewnętrzny serwer SMTP. W takim przypadku musisz upewnić się, że serwer zarządzania i interfejs użytkownika mają dostęp do niezbędnego portu na serwerze SMTP. W przypadku protokołu SMTP innego niż Numer TLS numer portu to zwykle 25. W przypadku protokołu SMTP obsługującego protokół TLS jest często 465, ale skontaktuj się z dostawcą SMTP.

W tabeli poniżej widoczne są porty, które trzeba otworzyć w zaporach sieciowych według komponentu Edge:

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

Następna tabela zawiera te same porty (wyświetlone liczbowo) z komponentem źródłowym i docelowym:

Procesor wiadomości utrzymuje dedykowaną pulę połączeń otwartą dla 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, zapora sieciowa może przekroczyć limit czasu połączenia. Procesor wiadomości nie jest jednak przeznaczony do ponownego nawiązania połączeń z Cassandra.

Aby zapobiec takiej sytuacji, Apigee zaleca, aby serwer Cassandra, procesor wiadomości i routery znajdowały się w tej samej podsieci, dzięki czemu zapora sieciowa nie będzie angażowana we wdrażanie tych komponentów.

Jeśli zapora sieciowa między routerem a podmiotami przetwarzającymi wiadomości ma ustawioną limit czasu oczekiwania TCP, zalecamy wykonanie tych czynności:

1. Ustaw net.ipv4.tcp_keepalive_time = 1800 w ustawieniach sysctl w systemie Linux, gdzie wartość 1800 powinna być niższa niż limit czasu bezczynności TCP zapory sieciowej. To ustawienie powinno utrzymywać połączenie w stanie ustalonym, aby zapora sieciowa nie rozłączała połączenia.
2. We wszystkich procesorach wiadomości zmień /opt/apigee/customer/application/message-processor.properties, aby dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.

   conf_system_cassandra.maxconnecttimeinmillis=-1

3. Uruchom ponownie procesor wiadomości:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

4. We wszystkich routerach zmień właściwość /opt/apigee/customer/application/router.properties, by dodać tę właściwość. Jeśli plik nie istnieje, utwórz go.

   conf_system_cassandra.maxconnecttimeinmillis=-1

5. Uruchom ponownie router:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

Jeśli zainstalujesz 12 konfiguracji klastrów z 2 centrami danych, upewnij się, że węzły w tych dwóch centrach danych mogą komunikować się przez porty podane poniżej:

Wymagania dotyczące portu BaaS API

Jeśli zdecydujesz się zainstalować BaaS API, musisz dodać komponenty BaaS Stack i API BaaS Portal. Te komponenty korzystają z portów widocznych na ilustracji poniżej:

Uwagi na tym schemacie:

• Interfejs API BaaS nigdy nie wysyła żądań bezpośrednio do węzła stosu BaaS. Gdy deweloper loguje się w portalu, aplikacja jest pobierana do przeglądarki. Aplikacja Portal uruchomiona w przeglądarce wysyła żądania do węzłów stosu BaaS.
• Instalacja produkcyjna BaaS API używa systemu równoważenia obciążenia między węzłami portalu BaaS Portal i węzłami BaaS Stack. Podczas konfigurowania portalu i przy wywoływaniu interfejsu BaaS API musisz podać adres IP lub nazwę DNS systemu równoważenia obciążenia, a nie węzłów stosu.
• Wszystkie węzły stosu muszą mieć port 2551, aby mieć dostęp z pozostałych węzłów stosu (wskazuje to pętla na diagramie powyżej dla portu 2551 w węzłach stosu). Jeśli masz wiele centrów danych, port musi być dostępny ze wszystkich węzłów stosu we wszystkich centrach danych.
• Musisz skonfigurować wszystkie węzły stosu Baas, aby wysyłały e-maile przez zewnętrzny serwer SMTP. W przypadku serwera SMTP innego niż TLS numer portu to zwykle 25. W przypadku protokołu SMTP obsługującego protokół TLS jest często 465, ale skontaktuj się z dostawcą SMTP.
• Węzły Cassandra mogą być używane do obsługi BaaS API lub mogą być udostępniane brzegowemu.

W tabeli poniżej znajdziesz domyślne porty, które trzeba otworzyć w zaporach sieciowych według komponentów:

Licencjonowanie

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

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

Jeśli plik licencji jest prawidłowy, serwer zarządzania sprawdza datę ważności i dopuszczalną liczbę procesorów (MP). Jeśli dowolne 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 na temat migracji.

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