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

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info

W sierpniu i wrześniu 2015 r. przenosimy routery i usługi równoważenia obciążenia w chmurze Apigee Edge na NGINX (czytane jako „Engine X”). NGINX, serwer WWW typu open source, zapewnia jeszcze lepszą wydajność i większą współbieżność niż nasze obecne moduły równoważenia obciążenia i routery.

Co to oznacza dla naszych klientów korzystających z usług w chmurze

Podsumowując, ta zmiana powinna być dla Ciebie niezauważalna i nie wymaga żadnych działań z Twojej strony poza sprawdzeniem, czy Twoje systemy działają zgodnie z oczekiwaniami. Poniżej znajdziesz opis kroków, które podejmiemy, oraz odpowiedzi na niektóre z najczęstszych pytań.

Krok 1. Aktualizacja oprogramowania

Uaktualnimy wszystkie routery do nowej wersji opartej na NGINX, korzystając z naszego modelu wdrażania etapowego, aby zapewnić, że ta zmiana nie wpłynie na usługi.

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

Nowy router NGINX będzie obsługiwać funkcję równoważenia obciążenia, więc najpierw rozpoczniemy proces usuwania istniejącej warstwy modułu równoważenia obciążenia w środowiskach innych niż produkcyjne. Systemy równoważenia obciążenia w środowisku produkcyjnym pozostaną nienaruszone i niezmienione na tym etapie. Zanim usuniemy obecne systemy równoważenia obciążenia, dokładnie sprawdzimy, czy ruch działa zgodnie z oczekiwaniami. Aby wykonać ten krok, nie musisz nic robić. Wszelkie problemy należy jednak zgłaszać zespołowi Apigee. Wspólnie z Tobą rozwiążemy je, zanim przejdziesz do kroku 3.

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

Po pomyślnym wykonaniu kroku 2 określimy zestaw okien serwisowych, aby usunąć warstwę modułu równoważenia obciążenia w środowiskach produkcyjnych, stosując tę samą metodę, która została opisana w kroku 2. Dzięki temu ruch API w czasie działania będzie nadal działać zgodnie z oczekiwaniami.

Zmiany w funkcjonalności produktu

Oto niektóre zmiany w funkcjach usługi po przejściu na NGINX:

Wycofano

Te właściwości nie są już obsługiwane w usługach ProxyEndpoint:

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

Aby obejść ten problem, zapoznaj się z tym artykułem na forum: Właściwości metody HTTP zezwalającej na punkty końcowe serwera proxy nie działają.

Najczęstsze pytania

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

Czy może to spowodować zmianę publicznych adresów IP? Niektórzy sprzedawcy zezwalają na dostęp tylko z znanych adresów IP, a gdy je zmienią, proces sprzedawcy ulega przerwaniu.
W kroku 1 odpowiedź brzmi „Nie”, ponieważ nie dotykamy istniejących modułów równoważenia obciążenia, które nie zmienią bezpośrednio żadnych adresów IP obsługujących ruch. Jednak ze względu na charakter usługi równoważenia obciążenia Amazon Web Services (AWS) obowiązują normalne reguły skalowania, co oznacza, że adresy IP mogą się zmieniać w ramach logiki skalowania (istniejąca funkcjonalność). Dlatego nie zalecamy wdrażania konfiguracji list dozwolonych dla ruchu wychodzącego w pakiecie produktów Apigee Edge. Podczas kroków 2 i 3 usunięcie systemu równoważenia obciążenia i powiązanych z nim adresów IP ma wpływ na listę dozwolonych. Dlatego będziemy ściśle współpracować z Tobą podczas tych kroków, aby zapewnić płynne przejście, udostępniając nowy zestaw adresów IP, do których należy zezwolić na dostęp.
Czy wpłynie to na ograniczenia adresów IP, które mamy na serwerach źródłowych?
Nie musisz wprowadzać żadnych zmian, jeśli serwery pochodzenia są serwerami punktu końcowego (serwerami wywoływanymi z pakietu proxy). Ta zmiana dotyczy strony północnej Apigee lub punktu wejścia do Apigee.
Czy nasze dotychczasowe rekordy CNAME będą wymagać zmiany?
Nie. Dotychczasowe wpisy CNAME będą nadal działać zgodnie z oczekiwaniami.
Migracja certyfikatu SSL będzie trudna. Jak sobie z tym poradzisz?
Jeśli używasz protokołu SSL, pierwszy krok nie wpłynie na istniejącą konfigurację SSL. Zanim przejdziemy do kroków 2 i 3, musimy ściśle współpracować z Tobą, aby upewnić się, że protokół SSL jest prawidłowo skonfigurowany na nowym routerze.
Co zrobić, jeśli moja aplikacja lub klient nie obsługuje SNI?
Kroki 2 i 3 zostaną opóźnione do czasu potwierdzenia obsługi SNI.
Czy wystąpią jakieś przestoje?
Nie przewidujemy żadnych przestojów. Zmiany zostaną wdrożone w ramach naszych standardowych okien publikacji.