Wymagania dotyczące instalacji

Edge dla chmury prywatnej w wersji 4.17.01

Wymagania sprzętowe

Aby infrastruktura o wysokiej dostępności działała w środowisku produkcyjnym, musisz spełnić te minimalne wymagania sprzętowe. W tabelach poniżej znajdziesz minimalne wymagania sprzętowe dotyczące komponentów instalacji we wszystkich scenariuszach instalacji opisanych w sekcji Topologie 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ż wymienione poniżej.

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

Poniżej znajdziesz wymagania sprzętowe, które musisz spełnić, aby zainstalować API BaaS:

Uwaga:

• Jeśli główny system plików nie jest wystarczająco duży do instalacji, zalecamy umieszczenie danych na większym dysku.
• Jeśli na komputerze była zainstalowana starsza wersja Apigee Edge dla chmury prywatnej, przed nową instalacją usuń folder /tmp/java.
• Aby uruchomić system Cassandra, folder tymczasowy /tmp musi mieć uprawnienia do wykonywania.
• Jeśli użytkownik „apigee” został utworzony przed instalacją, upewnij się, że „/home/apigee” istnieje jako katalog domowy i należy do „apigee:apigee”.

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 tutaj: https://apigee.com/docs/api-services/reference/supported-software.

Tworzenie użytkownika Apigee

Procedura instalacji tworzy użytkownika systemu Unix o nazwie „apigee”. Katalogi i pliki Edge należą do „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. Przykład znajdziesz w sekcji „Powiązanie routera z chronionym portem” w artykule Instalowanie komponentów Edge w węźle.

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

W instrukcjach w tym przewodniku katalog instalacyjny jest oznaczony jako /<inst_root>/apigee, gdzie /<inst_root> to domyślnie /opt.

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 zostały utworzone przez instalator Edge.

Aby utworzyć dowiązanie symboliczne, wykonaj te czynności przed pobraniem pliku bootstrap_4.17.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 /opt/apigee do wybranego katalogu głównego instalacji:
   > ln -Ts /srv/myInstallDir /opt/apigee
   gdzie /srv/myInstallDir to wybrana lokalizacja plików Edge.
3. Zmień właściciela katalogu głównego instalacji i dowiązania 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 Java 1.8. Obsługiwane pakiety JDK są wymienione tutaj:

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

Upewnij się, że zmienna JAVA_HOME wskazuje katalog główny JDK użytkownika, który przeprowadza instalację.

SELinux

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

Ustawienie sieci

Zalecamy 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 nazwy hosta, który może być adresowany z innych maszyn.

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

TCP Wrappers

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

iptables

Sprawdź, czy nie ma zasad iptables uniemożliwiających 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 /etc/rc.d/init.d/functions

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

Jeśli proces zabezpieczeń wymaga ustawienia uprawnień w pliku /etc/rc.d/init.d/functions, nie ustawiaj ich na 700, ponieważ router nie będzie mógł się uruchomić. Możesz ustawić uprawnienia na 744, aby zezwolić na dostęp do 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 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 na temat współczynnika replikacji i poziomu spójności Cassandra.

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 dużego zużycia pamięci.

Po zainstalowaniu Edge dla chmury prywatnej możesz sprawdzić, czy Cassandra jest prawidłowo skonfigurowana, sprawdzając plik /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. Upewnij się na przykład, że skrypt instalacyjny Edge dla chmury prywatnej ustawia te właściwości:

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

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. Otwórz do edycji plik postgresql.properties:
   > vi /<inst_root>/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:
   > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Ograniczenia systemu

Upewnij się, że w węzłach Cassandra i procesora komunikatów ustawiono te limity systemowe:

• W węzłach Cassandra ustaw miękkie i twarde limity memlock, nofile i przestrzeni adresowej (as) dla użytkownika instalacji (domyślnie „apigee”) w pliku /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 K w pliku /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. Może się tak zdarzyć, jeśli na przykład masz otwartą dużą liczbę plików tymczasowych.

jsvc

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

Network Security Services (NSS)

Network Security Services (NSS) to zestaw bibliotek, które ułatwiają tworzenie aplikacji klienckich i serwerowych z obsługą zabezpieczeń. Upewnij się, że masz zainstalowaną wersję NSS 3.19 lub nowszą.

Aby sprawdzić bieżącą wersję:

> yum info nss

Aby zaktualizować NSS:

> yum update nss

Więcej informacji znajdziesz w tym artykule firmy RedHat.

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

Jeśli masz zainstalowany i włączony demon NSCD (Name Service Cache Daemon), procesory komunikatów wykonują 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. Na każdym węźle procesora komunikatów zmodyfikuj plik /etc/nscd.conf.
2. Ustaw tę właściwość:
   enable-cache hosts no

Wyłączanie protokołu IPv6 na Google Cloud Platform w przypadku RedHat/CentOS 7

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

Instrukcje wyłączania protokołu IPv6 znajdziesz w dokumentacji RedHat lub CentOS dotyczącej konkretnej wersji systemu operacyjnego.

AWS AMI

Jeśli instalujesz Edge na obrazie Amazon Machine Image (AMI) AWS 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 tych narzędzi UNIX w wersji standardowej, które są dostarczane przez EL5 lub EL6.

Uwaga:

• Plik wykonywalny narzędzia „useradd” znajduje się w /usr/sbin, a narzędzia chkconfig – w /sbin.
• Dzięki dostępowi do sudo możesz uzyskać dostęp do środowiska wywołującego użytkownika, na przykład zwykle wywołujesz „sudo <polecenie>” lub „sudo PATH=$PATH:/usr/sbin:/sbin <polecenie>”.
• Przed instalacją pakietu poprawek (poprawki) upewnij się, że masz zainstalowane narzędzie „patch”.

ntpdate – zalecamy synchronizację czasu serwerów. Jeśli nie jest jeszcze skonfigurowane, do tego celu można użyć narzędzia „ntpdate”, które sprawdza, czy serwery są zsynchronizowane czasowo. Aby zainstalować to narzędzie, możesz użyć polecenia „yum install ntp”. Jest to szczególnie przydatne w przypadku replikowania konfiguracji OpenLDAP. Pamiętaj, że strefa czasowa serwera jest ustawiona na 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 systemie RHEL/CentOS możesz uruchomić polecenie „yum install openldap-clients openldap-servers”, aby zainstalować OpenLDAP.

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

Zapory sieciowe i hosty wirtualne

Termin „wirtualny” jest często nadużywany w branży IT, podobnie jak w przypadku wdrożenia Apigee Edge dla chmury prywatnej i hostów wirtualnych. Dla wyjaśnienia: termin „wirtualny” ma 2 główne zastosowania:

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

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

Przykładowo na jednym serwerze fizycznym „A” mogą działać 2 maszyny wirtualne o nazwach „VM1” i „VM2”. Załóżmy, że maszyna VM1 udostępnia wirtualny interfejs Ethernet, który w maszynie wirtualnej ma nazwę eth0 i któremu maszyna wirtualna lub serwer DHCP sieci przypisuje adres IP 111.111.111.111. Załóżmy też, że maszyna VM2 udostępnia wirtualny interfejs Ethernet, który również ma nazwę eth0 i któremu przypisany jest adres IP 111.111.111.222.

W 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 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 udostępnia api.mycompany.com:80 (ta sama nazwa i port co w maszynie wirtualnej 1).

System operacyjny hosta fizycznego może mieć zaporę sieciową. Jeśli tak jest, musi ona być skonfigurowana tak, aby przepuszczać ruch TCP kierowany do portów udostępnianych w interfejsach zwirtualizowanych (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ą na interfejsie eth0, która również musi zezwalać na ruch 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 przez Ciebie proxy interfejsów API. Pakiety serwerów proxy interfejsu API mogą współdzielić punkt końcowy, jeśli mają różne ścieżki podstawowe. Na przykład jedna ścieżka podstawowa 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 systemu kierowania ruchem, który będzie 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 danej instalacji i jest konfigurowana przez lokalną grupę sieciową.

Ścieżka podstawowa jest ustawiana podczas wdrażania interfejsu API. W powyższym przykładzie możesz wdrożyć 2 interfejsy API, mycompany i testmycompany, dla 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 podstawowej we wdrożeniu, router nie będzie wiedział, do którego interfejsu API 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ą adresu http://api.mycompany.com:80/salesdemo. Jeśli wdrożysz interfejs API mycompany 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 portów brzegowych

Konieczność zarządzania zaporą sieciową wykracza poza same hosty wirtualne. Zapory sieciowe maszyn wirtualnych i hostów fizycznych muszą zezwalać na ruch na portach wymaganych do komunikacji między komponentami.

Poniższy obraz przedstawia wymagania dotyczące portów dla każdego komponentu Edge:

Uwagi do tego diagramu:

• *Port 8082 procesora komunikatów musi być otwarty tylko na potrzeby dostępu routera, gdy konfigurujesz TLS/SSL między routerem a procesorem komunikatów. Jeśli nie skonfigurujesz TLS/SSL między routerem a procesorem komunikatów, domyślna konfiguracja, port 8082, musi być nadal otwarty na procesorze komunikatów, aby można było zarządzać komponentem, ale router nie wymaga do niego dostępu.
• Porty z prefiksem „M” są używane do zarządzania komponentem i muszą być otwarte na komponencie, aby serwer zarządzania miał do nich dostęp.
• Te komponenty wymagają dostępu do portu 8080 na serwerze zarządzania: router, procesor komunikatów, interfejs użytkownika, Postgres i Qpid.
• Procesor komunikatów musi otworzyć port 4528 jako port zarządzania. Jeśli masz wiele procesorów komunikatów, wszystkie muszą mieć dostęp do siebie nawzajem przez port 4528 (wskazuje to strzałka pętli na powyższym diagramie dla portu 4528 procesora komunikatów). Jeśli masz kilka centrów danych, port musi być dostępny ze wszystkich procesorów komunikatów we wszystkich centrach danych.
• Nie jest to wymagane, ale możesz otworzyć port 4527 na routerze, aby umożliwić dostęp dowolnemu procesorowi komunikatów. 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ć dostęp do siebie nawzajem przez port 4527 (wskazuje to strzałka pętli na powyższym diagramie dla portu 4527 na routerze).
• 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 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ł nazwy użytkownika i hasła. Więcej informacji znajdziesz w sekcji Jak monitorować.
• Możesz opcjonalnie skonfigurować dostęp TLS/SSL dla niektórych połączeń, które mogą używać różnych portów. Więcej informacji znajdziesz w artykule o TLS/SSL.
• Jeśli konfigurujesz 2 węzły Postgres do korzystania z replikacji 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ądzania i interfejs Edge, aby wysyłać e-maile przez zewnętrzny serwer SMTP. Jeśli tak, musisz upewnić się, że serwer zarządzania 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 protokołu SMTP z obsługą TLS jest to często 465, ale sprawdź to u dostawcy SMTP.

Tabela poniżej zawiera porty, które muszą być otwarte w zaporach sieciowych, według komponentu Edge:

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

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

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

Aby zapobiec takiej sytuacji, Apigee zaleca, aby serwer Cassandra, procesor komunikatów 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 komunikatów znajduje się zapora sieciowa i ma ustawiony limit czasu bezczynności TCP, zalecamy:

1. W ustawieniach sysctl w systemie operacyjnym Linux ustaw net.ipv4.tcp_keepalive_time = 1800, gdzie 1800 powinno być mniejsze niż limit czasu bezczynności TCP zapory sieciowej. To ustawienie powinno utrzymywać połączenie w stanie nawiązanym, aby zapora sieciowa go nie rozłączała.
2. Na wszystkich procesorach komunikatów zmodyfikuj plik /<inst_root>/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. Na wszystkich routerach zmodyfikuj plik /<inst_root>/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. Uruchom ponownie 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 obu centrach danych mogą komunikować się przez porty wymienione poniżej:

Wymagania związane z portami 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 poniższym rysunku:

Uwagi do 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.
• Instalacja produkcyjna API BaaS używa systemu równoważenia obciążenia między węzłem portalu API BaaS a węzłami stosu API BaaS. Podczas konfigurowania portalu i wywoływania 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 Stack muszą mieć otwarty port 2551, aby umożliwić dostęp ze wszystkich innych węzłów Stack (wskazuje to strzałka pętli na powyższym diagramie 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, aby wysyłały e-maile przez zewnętrzny serwer SMTP. W przypadku SMTP bez TLS numer portu to zwykle 25. W przypadku protokołu SMTP z obsługą TLS jest to często 465, ale sprawdź to u dostawcy SMTP.
• Węzły Cassandra mogą być przeznaczone dla API BaaS lub udostępniane Edge.

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

Licencjonowanie

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

Instalator kopiuje plik licencji do /<inst_root>/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 komunikatów. Jeśli którekolwiek 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.

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