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

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X.
Informacje

W sierpniu i wrześniu 2015 r. przenosimy nasze routery i balanser obciążenia w chmurze Apigee Edge do usługi NGINX (wymawianej jako „Engine X”). NGINX, serwer WWW typu open source, zapewnia jeszcze lepszą wydajność i większą liczbę jednoczesnych operacji niż nasze dotychczasowe routery i równoważniki obciążenia.

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

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

Krok 1. Aktualizacja oprogramowania

Wszystkie routery zostaną zaktualizowane do nowego routera opartego na NGINX. W tym celu wykorzystamy model wdrażania w etapach, aby zapewnić, że te działania nie wpłyną na działanie usług.

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

Ponieważ nowy router NGINX obsługuje funkcję równoważenia obciążenia, zaczniemy od usunięcia istniejącego poziomu równoważenia obciążenia w środowiskach nieprodukcyjnych. Na tym etapie systemy równoważenia obciążenia w środowisku produkcyjnym pozostaną nienaruszone i niezmienione. Przed usunięciem dotychczasowych modułów równoważenia obciążenia zastosujemy wyczerpujące podejście, aby mieć pewność, że ruch będzie działał zgodnie z oczekiwaniami. Nie musisz niczego robić. Należy jednak zgłosić wszelkie problemy do Apigee, a my pomożemy Ci je rozwiązać, zanim przejdziesz do kroku 3.

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

Po zakończeniu kroku 2 określimy zestaw okien konserwacji, aby usunąć warstwę równoważenia obciążenia w środowiskach produkcyjnych, używając tego samego podejścia, które opisaliśmy w kroku 2. Celem jest zapewnienie, aby ruch w interfejsie API w czasie wykonywania nadal działał zgodnie z oczekiwaniami.

Zmiany w funkcjonalności produktu

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

Wycofano

Te właściwości nie są już obsługiwane w ProxyEndpoints:

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

Aby obejść to wycofanie, zapoznaj się z artykułem 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 z najczęstszych pytań dotyczących migracji do NGINX.

Czy może to spowodować zmianę publicznych adresów IP? Niektórzy sprzedawcy zezwalają na dostęp z znanych adresów IP, a gdy je zmieniają, przerywają proces.
W kroku 1 odpowiedź brzmi „Nie”, ponieważ nie zmieniamy istniejących równoważników obciążenia, co nie spowoduje bezpośredniej zmiany 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 (obecna funkcjonalność). Dlatego nie zalecamy stosowania konfiguracji listy dozwolonych adresów przychodzących w pakiecie produktów Apigee Edge. W krokach 2 i 3 usunięcie systemu równoważenia obciążenia i powiązanych z nim adresów IP powoduje konsekwencje związane z listą dozwolonych. Dlatego podczas tych czynności będziemy ściśle z Tobą współpracować, aby zapewnić Ci płynne przejście. W tym celu udostępnimy Ci nowy zestaw adresów IP, który umożliwi Ci dostęp.
Czy wpłynie to na ograniczenia adresów IP obowiązujące na naszych serwerach źródłowych?
Nie musisz wprowadzać żadnych zmian, jeśli serwery źródłowe to docelowe serwery końcowe (serwery wywoływane z pakietu proxy). Ta zmiana dotyczy strony północnej interfejsu Apigee lub punktu wejścia do Apigee.
Czy będzie trzeba zmienić obecne rekordy CNAME?
Nie. Istniejące wpisy CNAME będą działać zgodnie z oczekiwaniami.
Przeniesienie certyfikatu SSL będzie trudne. Jak zamierzasz to rozwiązać?
Jeśli używasz protokołu SSL, pierwszy krok nie wpłynie na istniejącą konfigurację SSL. Zanim przejdziesz do kroków 2 i 3, będziemy musieli ściśle współpracować, 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 nastąpi przerwa w działaniu usługi?
Nie przewidujemy żadnych przestojów. Zmiany zostaną wdrożone za pomocą naszego standardowego modelu wdrażania w ramach naszych dotychczasowych okien wydawniczych.