Wymagania dotyczące instalacji

Edge for Private Cloud w wersji 4.18.01

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:

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.

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, aby zmapować obiekt /opt/apigee na inną lokalizację, jak opisano poniżej.

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

Tworzenie dowiązania symbolicznego z /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.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 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

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.

Sprawdź, czy JAVA_HOME wskazuje katalog główny pakietu JDK użytkownika wykonują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ć funkcję SELinux lub ustawić ją w trybie mniej rygorystycznym podczas instalacji, a następnie włączyć ją ponownie po instalacji. Więcej informacji znajdziesz w artykule Instalowanie narzędzia Edge apigee-setup.

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ę 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 dokumentacji pliku konfiguracji brzegowej.

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

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

Węzły routera brzegowego i BaaS Portal używają routera Nginx i wymagają uprawnień do odczytu w usłudze /etc/rc.d/init.d/functions.

Jeśli Twój proces zabezpieczeń wymaga ustawienia uprawnień na urządzeniu /etc/rc.d/init.d/functions, nie ustawiaj ich na wartość 700, bo inaczej router się nie uruchomi. Aby możliwy był odczyt pliku /etc/rc.d/init.d/functions, uprawnienia można ustawić na wartość 744.

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 Cassandra i poziomie spójności.

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 instalacyjnego (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.

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 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 NSCD (Name Service Cache), procesory wiadomości będą przeprowadzać 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 Twojego 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.

nieaktualny

Zalecamy synchronizację czasów działania serwerów. Może to być narzędzie ntpdate, które sprawdza, czy serwery są synchronizowane pod względem 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/.

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 oraz muszą być otwarte w komponencie, aby umożliwić dostęp serwerowi 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 systemach przetwarzania wiadomości edytuj /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. Ponownie uruchom procesor wiadomości:

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

4. We wszystkich routerach edytuj /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

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:

• Interfejs API BaaS Portal nigdy nie wysyła żądań bezpośrednio do węzła stosu BaaS. Gdy deweloper loguje się w portalu, aplikacja Portal jest pobierana do przeglądarki. Uruchomiona w przeglądarce aplikacja Portal wysyła żądania do węzłów stosu BaaS.
• 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.
• Wszystkie węzły stosu muszą mieć otwarty port 2551, aby zapewnić dostęp do wszystkich innych węzłów stosu (wskazuje to strzałka zapętlenia na powyższym diagramie dla portu 2551 w węzłach stosu). Jeśli masz wiele centrów danych, port musi być dostępny we wszystkich węzłach stosu we wszystkich centrach danych.
• 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.
• Węzły Cassandra mogą być przeznaczone dla API BaaS lub mogą być udostępniane Edge.

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 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.