Migration zu NGINX-Router und -Load-Balancern

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation
weitere Informationen

Im August und September 2015 migrieren wir unsere Apigee Edge-Cloud-Router und -Load-Balancer zu NGINX (ausgesprochen „Engine X“). NGINX, ein Open-Source-Webserver, bietet noch bessere Leistung und eine höhere Nebenläufigkeit als unsere vorhandenen Load-Balancer und Router.

Was das für unsere Cloud-Kunden bedeutet

Entscheidend ist, dass diese Änderung für Sie transparent sein muss und keine weitere Aktion Ihrerseits erforderlich ist. Sie müssen lediglich prüfen, ob Ihre Systeme wie erwartet funktionieren. Im Folgenden finden Sie Beschreibungen der erforderlichen Schritte sowie Antworten auf einige häufig gestellte Fragen.

Schritt 1 – Softwareupdate

Wir werden alle Router auf den neuen NGINX-basierten Router aktualisieren. Dabei nutzen wir unser Modell zur stufenweisen Bereitstellung, damit Dienste durch diese Aktivität nicht beeinträchtigt werden.

Schritt 2: Load-Balancer-Stufe in Nicht-Produktionsumgebungen entfernen

Da der neue NGINX-Router die Load-Balancing-Funktion verarbeitet, beginnen wir damit, die vorhandene Load-Balancer-Stufe in Ihren Nicht-Produktionsumgebungen zu entfernen. Produktions-Load-Balancer bleiben während dieses Schritts intakt und unverändert. Bevor vorhandene Load-Balancer entfernt werden, verfolgen wir einen umfassenden Ansatz, um sicherzustellen, dass der Traffic wie erwartet funktioniert. Sie müssen nichts weiter tun. Sie sollten jedoch alle Probleme an Apigee melden. Wir arbeiten mit Ihnen zusammen, um sie zu beheben, bevor Sie mit Schritt 3 fortfahren.

Schritt 3: Load-Balancer-Stufe in Produktionsumgebungen entfernen

Nach erfolgreichem Abschluss von Schritt 2 legen wir eine Reihe von Wartungsfenstern fest, um die Load-Balancer-Stufe in Produktionsumgebungen zu entfernen. Dabei gehen wir mit dem in Schritt 2 beschriebenen Ansatz vor, um sicherzustellen, dass der API-Laufzeit-Traffic weiterhin wie erwartet funktioniert.

Änderungen an den Produktfunktionen

Im Folgenden sind einige Änderungen an den Produktfunktionen durch den Wechsel zu NGINX aufgeführt.

Eingestellte Funktionen

Die folgenden Attribute werden in ProxyEndpunkte nicht mehr unterstützt:

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

Informationen zum Umgehen dieser Einstellung finden Sie im folgenden Community-Artikel: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

Häufig gestellte Fragen

Nachfolgend finden Sie Antworten auf einige häufig gestellte Fragen zur NGINX-Migration.

Werden dadurch möglicherweise öffentliche IP-Adressen geändert? Einige unserer Händler erlauben speziell den Zugriff von den bekannten IP-Adressen und wenn diese die Flow-Unterbrechungen der Händler ändern.
In Schritt 1 lautet die Antwort „Nein“, da wir die vorhandenen Load-Balancer nicht bearbeiten. Das hat keine direkten Auswirkungen auf die IP-Adressen, die Traffic verarbeiten. Angesichts der Art des AWS-Load-Balancing-Dienstes (Amazon Web Services) gelten jedoch normale Skalierungsregeln. Das bedeutet, dass sich IP-Adressen im Rahmen der Skalierungslogik (bestehende Funktion) ändern können. Aus diesem Grund raten wir davon ab, mit der Apigee Edge-Produktsuite Northbound-Zulassungslistenkonfigurationen zu implementieren. In den Schritten 2 und 3 wirkt sich das Entfernen des Load-Balancers und der zugehörigen IP-Adressen auf die Zulassungsliste aus. Aus diesem Grund werden wir bei diesen Schritten eng mit Ihnen kooperieren, um einen reibungslosen Übergang zu gewährleisten. Dazu stellen wir neue IP-Adressen bereit, für die der Zugriff gewährt werden soll.
Wirkt sich das auf die IP-Einschränkungen für unsere Ursprungsserver aus?
Es sind keine Änderungen erforderlich, vorausgesetzt, die Ursprungsserver sind die Zielendpunktserver (Server, die über das Proxy-Bundle aufgerufen werden). Diese Änderung befindet sich auf der Nordseite von Apigee oder dem Eingangspunkt in Apigee.
Muss der bestehende CNAME geändert werden?
Nein. Vorhandene CNAME-Einträge funktionieren weiterhin wie gewohnt.
Die Migration der SSL-Zertifikate wird mühsam sein. Wie werden Sie damit umgehen?
Wenn Sie SSL verwenden, hat der erste Schritt keine Auswirkungen auf die vorhandene SSL-Konfiguration. Wir müssen jedoch eng mit Ihnen abstimmen, um sicherzustellen, dass SSL auf dem neuen Router ordnungsgemäß eingerichtet ist, bevor wir mit den Schritten 2 und 3 fortfahren.
Was ist, wenn meine App bzw. mein Client SNI nicht unterstützt?
Die Schritte 2 und 3 verzögern sich, bis die SNI-Unterstützung bestätigt wurde.
Gibt es Ausfallzeiten?
Ausfallzeiten sind nicht zu erwarten. Die Änderungen werden mithilfe unseres Standardbereitstellungsmodells während der bestehenden Release-Zeiträume implementiert.