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.
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.
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.
Nein. Vorhandene CNAME-Einträge funktionieren weiterhin wie gewohnt.
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.
Die Schritte 2 und 3 verzögern sich, bis die SNI-Unterstützung bestätigt wurde.
Ausfallzeiten sind nicht zu erwarten. Die Änderungen werden mithilfe unseres Standardbereitstellungsmodells während der bestehenden Release-Zeiträume implementiert.