Migracja do routerów i systemów równoważenia obciążenia NGINX

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

W sierpniu i we wrześniu 2015 roku będziemy przenosić routery i systemy równoważenia obciążenia Apigee Edge do NGINX (wymowa „Engine X”). NGINX, czyli serwer WWW typu open source, zapewnia jeszcze lepszą wydajność i wyższą równoczesność niż nasze istniejące systemy równoważenia obciążenia i routery.

Co to oznacza dla naszych klientów korzystających z chmury

Co ważne, ta zmiana powinna być widoczna dla Ciebie i nie wymaga żadnych działań z Twojej strony poza zweryfikowaniem, czy Twoje systemy działają zgodnie z oczekiwaniami. Poniżej znajdziesz opisy wykonanych czynności, a także odpowiedzi na niektóre z najczęstszych pytań.

Krok 1. Aktualizacja oprogramowania

Zaktualizujemy wszystkie routery do nowego routera opartego na NGINX, wykorzystując nasz model stopniowego wdrażania, aby zapewnić, że to działanie nie będzie miało wpływu na usługi.

Krok 2. Usuń typ systemu równoważenia obciążenia w środowiskach nieprodukcyjnych

Gdy nowy router NGINX obsługuje funkcję równoważenia obciążenia, zaczniemy najpierw usuwać istniejący typ systemu równoważenia obciążenia w środowiskach nieprodukcyjnych. Podczas tego kroku produkcyjne systemy równoważenia obciążenia pozostaną niezmienione. Przed usunięciem istniejących systemów równoważenia obciążenia zastosujemy szczegółowe podejście do tego, aby zapewnić działanie ruchu zgodnie z oczekiwaniami. Aby ukończyć ten krok, nie musisz nic robić. Jednak zgłoś wszystkie problemy do Apigee. Pomożemy Ci je rozwiązać przed przejściem do kroku 3.

Krok 3. Usuń typ systemu równoważenia obciążenia w środowiskach produkcyjnych

Po pomyślnym ukończeniu kroku 2 określimy zestaw okresów konserwacji w celu usunięcia poziomu systemu równoważenia obciążenia w środowiskach produkcyjnych przy użyciu metody opisanej w kroku 2, aby zapewnić dalsze działanie ruchu API w środowisku wykonawczym.

Zmiany w funkcjach usługi

Oto kilka zmian w funkcjach usługi po przejściu na NGINX.

Wycofano

Poniższe właściwości nie są już obsługiwane w punkcie ProxyEndpoints:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

Informacje o tym, jak obejść ten problem, znajdziesz w artykule na temat społeczności: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

Najczęstsze pytania

Poniżej znajdziesz odpowiedzi na niektóre najczęstsze pytania dotyczące migracji do NGINX.

Czy spowoduje to zmianę publicznych adresów IP? Niektórzy z naszych sprzedawców wyraźnie zezwalają na dostęp ze znanych adresów IP oraz wtedy, gdy zmienią przerwy w działaniu sprzedawcy.
W kroku 1 odpowiedź brzmi „Nie”, ponieważ nie dotykamy istniejących systemów równoważenia obciążenia, co nie zmienia bezpośrednio żadnego z adresów IP obsługujących ruch. Ze względu na charakter usługi równoważenia obciążenia Amazon Web Services (AWS) obowiązują jednak normalne reguły skalowania, co oznacza, że adresy IP mogą się zmieniać w ramach logiki skalowania (obecnej funkcji). Dlatego nie zalecamy wdrażania konfiguracji listy dozwolonych w kierunku północnym w przypadku pakietu usług Apigee Edge. Etapy 2 i 3 mają wpływ na usunięcie systemu równoważenia obciążenia i powiązanych z nim adresów IP. Dlatego podczas tych etapów będziemy ściśle z Tobą koordynować działania, by zapewnić płynne przejście na nowy zestaw adresów IP, za pomocą których umożliwimy Ci dostęp.
Czy ta zmiana wpłynie na ograniczenia adresów IP, które stosujemy na naszych serwerach źródłowych?
Nie musisz wprowadzać żadnych zmian, jeśli serwery źródłowe są docelowymi serwerami punktów końcowych (serwerami wywoływanymi z pakietu proxy). Ta zmiana znajduje się po północnej stronie Apigee lub punktu wejścia do Apigee.
Czy dotychczasowy rekord CNAME będzie wymagać zmiany?
Nie. Istniejące wpisy CNAME będą nadal działać zgodnie z oczekiwaniami.
Migracja certyfikatu SSL będzie kłopotliwa. Jak sobie z tym poradzisz?
Jeśli używasz SSL, pierwszy krok nie będzie miał wpływu na istniejącą konfigurację SSL. Jednak zanim wykonasz kroki 2 i 3, będziemy musieli się z Tobą skontaktować, aby upewnić się, że protokół SSL jest prawidłowo skonfigurowany na nowym routerze.
Co zrobić, jeśli moja aplikacja/klient nie obsługuje SNI?
Kroki 2 i 3 zostaną opóźnione do czasu potwierdzenia obsługi SNI.
Czy będą występować przerwy?
Nie przewidujemy przerw w działaniu usługi. Zmiany zostaną wprowadzone za pomocą naszego standardowego modelu wdrożenia w aktualnych okresach udostępniania.