Wymagania dotyczące instalacji

Edge dla chmury prywatnej w wersji 4.18.01

Wymagania sprzętowe

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

W tych tabelach wymagania dotyczące dysku twardego są podane dodatkowo do 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ż podano poniżej.

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

Jeśli chcesz zainstalować API BaaS, musisz spełnić te wymagania sprzętowe:

Wymagania dotyczące systemu operacyjnego i oprogramowania innych firm

Te instrukcje instalacji i dostarczone pliki instalacyjne zostały przetestowane w systemach operacyjnych i oprogramowaniu innych firm wymienionych w sekcji Obsługiwane oprogramowanie i obsługiwane wersje.

Tworzenie użytkownika Apigee

Podczas instalacji tworzony jest użytkownik systemu Unix o nazwie „apigee”. Katalogi i pliki Edge należą do użytkownika „apigee”, podobnie jak procesy Edge. Oznacza to, że komponenty Edge działają jako użytkownik „apigee”. W razie potrzeby możesz uruchamiać komponenty jako inny użytkownik.

Katalog instalacyjny

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ę, jak opisano poniżej.

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

Tworzenie linku symbolicznego z /opt/apigee

Zanim utworzysz link symboliczny, musisz najpierw utworzyć użytkownika i grupę o nazwie „apigee”. Jest to ta sama grupa i ten sam użytkownik utworzony przez instalator Edge.

Aby utworzyć link symboliczny, wykonaj te czynności przed pobraniem pliku bootstrap_4.18.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 link symboliczny z /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łaściciela katalogu głównego instalacji i linku symbolicznego na użytkownika „apigee”:

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

Java

Przed instalacją na każdym komputerze musi być zainstalowana obsługiwana wersja Javy 1.8. Obsługiwane wersje JDK znajdziesz w artykule Obsługiwane oprogramowanie i obsługiwane wersje.

Sprawdź, czy JAVA_HOME wskazuje katalog główny JDK użytkownika, który przeprowadza instalację.

SELinux

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

Ustawienia sieci

Przed instalacją zalecamy sprawdzenie ustawień sieci. Instalator oczekuje, że wszystkie maszyny mają stałe adresy IP. Aby sprawdzić ustawienie, użyj tych poleceń:

• hostname zwraca nazwę urządzenia.
• hostname -i zwraca adres IP nazwy hosta, do którego można się odwoływać z innych maszyn.

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

Jeśli serwer ma wiele kart interfejsu, polecenie „hostname -i” zwraca listę adresów IP rozdzielonych spacjami. Domyślnie instalator Edge używa pierwszego zwróconego adresu IP, który nie zawsze jest prawidłowy. 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 wyświetla prośbę o wybranie adresu IP, który ma być używany podczas instalacji. Wartość domyślna to „n”. Więcej informacji znajdziesz w dokumentacji pliku konfiguracji Edge.

TCP Wrappers

TCP Wrappers mogą blokować komunikację na niektórych portach i wpływać na instalację OpenLDAP, Postgres i Cassandry. Na tych węzłach sprawdź /etc/hosts.allow i /etc/hosts.deny, aby upewnić się, że nie ma ograniczeń portów w przypadku wymaganych portów OpenLDAP, Postgres i Cassandra.

iptables

Sprawdź, czy nie ma zasad iptables, które uniemożliwiają połączenie między węzłami na wymaganych portach Edge. W razie potrzeby możesz zatrzymać iptables podczas instalacji za pomocą polecenia:

sudo/etc/init.d/iptables stop

W systemie CentOS 7.x:

systemctl stop firewalld

Sprawdź, czy router brzegowy ma dostęp do pliku /etc/rc.d/init.d/functions

Węzły routera brzegowego i portalu BaaS korzystają z routera Nginx i wymagają dostępu do odczytu do /etc/rc.d/init.d/functions.

Jeśli proces zabezpieczeń wymaga ustawienia uprawnień do /etc/rc.d/init.d/functions, nie ustawiaj ich na 700, ponieważ router nie uruchomi się. Uprawnienia można ustawić na 744, aby zezwolić na dostęp do odczytu w przypadku /etc/rc.d/init.d/functions.

Cassandra

Wszystkie węzły Cassandry muszą być połączone z pierścieniem. Cassandra przechowuje repliki danych na wielu węzłach, aby zapewnić niezawodność i odporność na błędy. Strategia replikacji dla każdej przestrzeni kluczy Edge określa węzły Cassandra, w których umieszczane są repliki. Więcej informacji znajdziesz w artykule About Cassandra Replication Factor and Consistency Level (w języku angielskim).

Cassandra automatycznie dostosowuje rozmiar sterty Javy na podstawie dostępnej pamięci. Więcej informacji znajdziesz w artykule o dostrajaniu zasobów Javy. W przypadku pogorszenia wydajności lub wysokiego zużycia pamięci.

Po zainstalowaniu Edge for 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 instalacyjny Edge dla chmury prywatnej 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. Otwórz do edycji plik postgresql.properties:

   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. Uruchom ponownie bazę danych PostgreSQL:

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

Ograniczenia systemu

Sprawdź, czy na węzłach Cassandra i procesora komunikatów ustawione są te limity systemowe:

• Na węzłach Cassandra ustaw limity miękkie i twarde memlock, nofile i przestrzeni adresowej (as) dla użytkownika instalacji (domyślnie „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 komunikatów ustaw maksymalną liczbę otwartych 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. Na przykład, jeśli masz otwartych wiele plików tymczasowych.

jsvc

„jsvc” jest wymagany do korzystania z interfejsu API BaaS. Wersja 1.0.15-dev jest instalowana podczas instalacji interfejsu API BaaS.

Network Security Services (NSS)

Network Security Services (NSS) to zestaw bibliotek, które obsługują tworzenie aplikacji klienckich i serwerowych z włączonymi funkcjami zabezpieczeń. Upewnij się, że masz zainstalowaną bibliotekę NSS w wersji 3.19 lub nowszej.

Aby sprawdzić obecną wersję:

yum info nss

Aby zaktualizować NSS:

yum update nss

Więcej informacji znajdziesz w tym artykule firmy RedHat.

Wyłączanie wyszukiwania DNS w protokole IPv6 podczas korzystania z NSCD (Name Service Cache Daemon)

Jeśli masz zainstalowany i włączony NSCD (Name Service Cache Daemon), procesory wiadomości wykonują 2 wyszukiwania DNS: jedno dla IPv4 i jedno dla IPv6. Jeśli używasz NSCD, wyłącz wyszukiwanie DNS w przypadku IPv6.

Aby wyłączyć wyszukiwanie DNS w przypadku IPv6:

1. Na każdym węźle procesora komunikatów edytuj /etc/nscd.conf
2. Ustaw tę właściwość:

   enable-cache hosts no

Wyłączanie protokołu IPv6 na platformie Google Cloud w systemie RedHat/CentOS 7

Jeśli instalujesz Edge na platformie RedHat 7 lub CentOS 7 na platformie Google Cloud Platform, musisz wyłączyć IPv6 na wszystkich węzłach Qpid.

Instrukcje wyłączania IPv6 znajdziesz w dokumentacji RedHat lub CentOS dla konkretnej wersji systemu operacyjnego. Możesz na przykład:

1. Otwórz plik /etc/hosts w edytorze.
2. Wstaw znak „#” w pierwszej kolumnie następującego wiersza, aby dodać go do komentarzy:

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

3. Zapisz plik.

AWS AMI

Jeśli instalujesz Edge na obrazie Amazon Machine Image (AMI) AWS 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 standardowej wersji następujących narzędzi systemu UNIX dostarczanych przez EL5 lub EL6.

ntpdate

Zalecamy synchronizację czasu na serwerach. Jeśli nie jest jeszcze skonfigurowane, narzędzie ntpdate może służyć do weryfikacji, czy serwery są zsynchronizowane czasowo. Za pomocą yum install ntp możesz zainstalować narzędzie. Jest to szczególnie przydatne w przypadku replikowania konfiguracji OpenLDAP. Pamiętaj, że strefę czasową serwera ustawiasz w formacie UTC.

openldap 2.4

Instalacja lokalna wymaga OpenLDAP 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 instalacyjnego Edge musisz się upewnić, że OpenLDAP jest już zainstalowany. W systemach RHEL/CentOS możesz uruchomić polecenie yum install openldap-clients openldap-servers, aby zainstalować OpenLDAP.

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

Zapory sieciowe i wirtualni hostowie

Termin virtual jest często nadużywany w branży IT, podobnie jak w przypadku wdrożenia Apigee Edge for Private Cloud i hostów wirtualnych. Termin virtual ma 2 główne zastosowania:

• Maszyny wirtualne: nie są wymagane, ale w niektórych wdrożeniach używa się technologii maszyn wirtualnych do tworzenia odizolowanych serwerów dla komponentów Apigee. Hosty maszyn wirtualnych, podobnie jak hosty fizyczne, mogą mieć interfejsy sieciowe i zapory.
• Wirtualne hosty: punkty końcowe sieci, analogiczne do wirtualnego hosta Apache.

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

Na przykład na jednym serwerze fizycznymA mogą działać 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że „VM1” udostępnia wirtualny interfejs Ethernet, który w maszynie wirtualnej ma nazwę „eth0” i któremu mechanizm wirtualizacji lub serwer DHCP sieci przypisuje adres IP 111.111.111.111. Załóżmy też, że VM2 udostępnia wirtualny interfejs Ethernet o nazwie „eth0”, któremu przypisany jest adres IP 111.111.111.222.

Na każdej z tych 2 maszyn wirtualnych może działać router Apigee. Routery udostępniają punkty końcowe hosta wirtualnego, jak w tym hipotetycznym przykładzie:

Router Apigee na maszynie wirtualnej VM1 udostępnia 3 wirtualne hosty na interfejsie eth0 (który ma określony adres IP): api.mycompany.com:80, api.mycompany.com:443 i test.mycompany.com:80.

Router na maszynie wirtualnej VM2 udostępnia api.mycompany.com:80 (o tej samej nazwie i porcie co router udostępniany przez maszynę wirtualną VM1).

System operacyjny hosta fizycznego może mieć zaporę sieciową. Jeśli tak jest, musi być ona skonfigurowana tak, aby przepuszczała ruch TCP przeznaczony dla portów udostępnianych na interfejsach wirtualnych (111.111.111.111:{80, 443} i 111.111.111.222:80). Dodatkowo system operacyjny każdej maszyny wirtualnej może udostępniać własną zaporę sieciową na interfejsie eth0, która również musi zezwalać na połączenia na portach 80 i 443.

Ścieżka podstawowa to trzeci komponent, który bierze udział w kierowaniu wywołań interfejsu API do różnych wdrożonych proxy interfejsów API. Pakiety serwera proxy interfejsu 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 tym przypadku potrzebujesz systemu równoważenia obciążenia lub usługi Traffic Director, które będą rozdzielać ruch http://api.mycompany.com:80/ między 2 adresy IP (111.111.111.111 na maszynie wirtualnej 1 i 111.111.111.222 na maszynie wirtualnej 2). Ta funkcja jest specyficzna dla Twojej instalacji i jest konfigurowana przez lokalną grupę sieciową.

Ścieżka podstawowa jest ustawiana podczas wdrażania interfejsu API. Na podstawie powyższego przykładu możesz wdrożyć 2 interfejsy API, mycompany i testmycompany, w organizacji mycompany-org z wirtualnym hostem, który ma alias hosta api.mycompany.com i port ustawiony na 80. Jeśli w przypadku wdrożenia nie zadeklarujesz ścieżki podstawowej, router nie będzie wiedzieć, 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ć do niego dostęp za pomocą adresu http://api.mycompany.com:80/salesdemo. Jeśli wdrożysz interfejs API mycompany z adresem URL /, użytkownicy będą uzyskiwać do niego dostęp za pomocą adresu URL http://api.mycompany.com:80/.

Wymagania dotyczące portu brzegowego

Zarządzanie zaporą sieciową nie ogranicza się tylko do hostów wirtualnych. Zarówno zapory sieciowe maszyn wirtualnych, jak i hostów fizycznych muszą zezwalać na ruch na portach wymaganych przez komponenty do komunikacji ze sobą.

Ilustracja poniżej przedstawia wymagania dotyczące portów dla każdego komponentu Edge:

Uwagi dotyczące tego diagramu:

• * Port 8082 na procesorze komunikatów musi być otwarty tylko w przypadku dostępu przez router, gdy skonfigurujesz protokół TLS/SSL między routerem a procesorem komunikatów. Jeśli nie skonfigurujesz protokołu TLS/SSL między routerem a procesorem komunikatów, domyślna konfiguracja, port 8082, musi być nadal otwarta na procesorze komunikatów, aby zarządzać komponentem, ale router nie wymaga do niego dostępu.
• Porty z prefixem „M” służą do zarządzania komponentem i muszą być otwarte na tym komponencie, aby serwer zarządzania miał do niego dostęp.
• Dostęp do portu 8080 na serwerze zarządzania jest wymagany w przypadku tych komponentów: router, procesor komunikatów, interfejs, Postgres i Qpid.
• Procesor komunikatów musi otworzyć port 4528 jako port zarządzania. Jeśli masz kilka procesorów komunikatów, wszystkie muszą mieć możliwość wzajemnego dostępu przez port 4528 (wskazuje to strzałka pętli na diagramie powyżej dla portu 4528 na procesorze komunikatów). Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich procesorów wiadomości we wszystkich centrach danych.
• Nie jest to wymagane, ale możesz otworzyć port 4527 na routerze, aby umożliwić dostęp dowolnemu procesorowi wiadomości. W przeciwnym razie w plikach dziennika procesora komunikatów mogą pojawić się komunikaty o błędach.
• Router musi otworzyć port 4527 jako port zarządzania. Jeśli masz kilka routerów, wszystkie muszą mieć możliwość komunikowania się ze sobą przez port 4527 (wskazuje to strzałka w kształcie pętli na powyższym diagramie).
• Interfejs Edge wymaga dostępu do routera na portach udostępnianych przez serwery proxy interfejsu API, aby obsługiwać przycisk Wyślij w narzędziu śledzenia.
• Serwer zarządzający wymaga dostępu do portu JMX na 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 sekcji Jak monitorować.
• Opcjonalnie możesz skonfigurować dostęp TLS/SSL dla niektórych połączeń, które mogą korzystać z różnych portów. Więcej informacji znajdziesz w sekcji TLS/SSL.
• Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji typu master-standby, musisz otworzyć port 22 na każdym węźle, aby umożliwić dostęp przez SSH. Opcjonalnie możesz otworzyć porty na poszczególnych węzłach, aby umożliwić dostęp przez SSH.
• Możesz skonfigurować serwer zarządzający i interfejs Edge tak, aby wysyłać e-maile przez zewnętrzny serwer SMTP. Jeśli tak, musisz się upewnić, że serwer zarządzający i interfejs użytkownika mają dostęp do odpowiedniego portu na serwerze SMTP. W przypadku SMTP bez TLS numer portu to zwykle 25. W przypadku SMTP z włączonym TLS jest to często 465, ale sprawdź to u dostawcy SMTP.

Tabela poniżej zawiera porty, które należy otworzyć w zaporach ogniowych, według komponentu Edge:

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

W tabeli poniżej te same porty są wymienione w kolejności numerycznej wraz z komponentami źródłowymi i docelowymi:

Procesor wiadomości utrzymuje otwartą pulę połączeń z Cassandrą, która jest skonfigurowana tak, aby nigdy nie przekraczać limitu czasu. Jeśli między procesorem wiadomości a serwerem Cassandra znajduje się zapora sieciowa, może ona spowodować przekroczenie limitu czasu połączenia. Procesor wiadomości nie jest jednak przeznaczony do ponownego nawiązywania połączeń z Cassandrą.

Aby temu zapobiec, 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 zaangażowana we wdrażanie tych komponentów.

Jeśli między routerem a procesorami wiadomości znajduje się zapora sieciowa z ustawionym czasem oczekiwania na nieaktywne połączenie TCP, zalecamy:

1. Ustaw wartość net.ipv4.tcp_keepalive_time = 1800 w ustawieniach sysctl w systemie Linux, gdzie 1800 powinno być mniejsze niż czas oczekiwania zapory sieciowej na nieaktywne połączenie TCP. To ustawienie powinno utrzymywać połączenie w stanie nawiązanym, aby zapora sieciowa nie rozłączała połączenia.
2. Na 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 komunikatów:

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

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

   conf_system_cassandra.maxconnecttimeinmillis=-1

5. Ponownie uruchom router:

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

Jeśli instalujesz konfigurację klastra z 12 hostami i 2 centrami danych, upewnij się, że węzły w tych centrach mogą się komunikować za pomocą portów podanych poniżej:

Wymagania dotyczące portów interfejsu API BaaS

Jeśli zdecydujesz się zainstalować API BaaS, dodasz komponenty API BaaS Stack i API BaaS Portal. Te komponenty używają portów pokazanych na ilustracji poniżej:

Uwagi dotyczące tego diagramu:

• Portal API BaaS nigdy nie wysyła żądań bezpośrednio do węzła BaaS Stack. Gdy deweloper loguje się w Portalu, aplikacja Portalu jest pobierana do przeglądarki. Aplikacja Portal działająca w przeglądarce wysyła żądania do węzłów BaaS Stack.
• W produkcyjnej instalacji API BaaS używa się modułu równoważenia obciążenia między węzłem portalu API BaaS a węzłami stosu API BaaS. Podczas konfigurowania portalu i wykonywania wywołań interfejsu BaaS API podajesz adres IP lub nazwę DNS modułu równoważenia obciążenia, a nie węzłów stosu.
• Wszystkie węzły Stack muszą otwierać port 2551, aby umożliwić dostęp z innych węzłów Stack (wskazuje to strzałka pętli na diagramie powyżej dla portu 2551 na węzłach Stack). Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich węzłów Stack we wszystkich centrach danych.
• Musisz skonfigurować wszystkie węzły BaaS Stack tak, aby wysyłały e-maile przez zewnętrzny serwer SMTP. W przypadku protokołu SMTP bez TLS numer portu to zwykle 25. W przypadku SMTP z obsługą TLS jest to zwykle 465, ale sprawdź to u dostawcy SMTP.
• Węzły Cassandra mogą być przeznaczone wyłącznie dla API BaaS lub mogą być współdzielone z Edge.

W tabeli poniżej znajdziesz domyślne porty, które należy otworzyć w zaporach sieciowych, w podziale na komponenty:

Licencjonowanie

Każda instalacja Edge wymaga unikalnego pliku licencji, który uzyskasz od Apigee. Podczas instalowania serwera zarządzającego musisz podać ścieżkę do pliku licencji, np. /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ę ważności i dozwoloną liczbę procesorów wiadomości. Jeśli któreś z ustawień licencji wygasło, logi znajdziesz w tym miejscu: /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.