Übersicht über die Migration

Auf dieser Seite finden Sie eine Übersicht über die Unterschiede zwischen dem globalen externen Application Load Balancer und dem klassischen Application Load Balancer sowie eine detaillierte Anleitung zum Migrieren Ihrer vorhandenen Ressourcen für den klassischen Application Load Balancer zum globalen externen Application Load Balancer.

Wenn Sie die erweiterten Funktionen zur Trafficverwaltung des globalen externen Application Load Balancers nutzen möchten, empfehlen wir Ihnen, Ihre Ressourcen für den klassischen Application Load Balancer zur globalen externen Application Load Balancer-Infrastruktur zu migrieren.

Klassische Application Load Balancer und globale externe Application Load Balancer vergleichen

Bevor Sie Ressourcen migrieren, sollten Sie sich mit den Unterschieden zwischen klassischen Application Load Balancern und globalen externen Application Load Balancern vertraut machen.

Funktionsunterschiede

Die folgenden Features werden vom globalen externen Application Load Balancer nicht unterstützt. Sie sind nur mit dem klassischen Application Load Balancer verfügbar:

Unterschiede der Datenebene

In der folgenden Tabelle werden die Unterschiede in der Datenebene zwischen dem klassischen Application Load Balancerr und dem globalen externen Application Load Balancer hervorgehoben. Diese Unterschiede wirken sich darauf aus, wie die Load-Balancer auf einige häufige Ereignisse reagieren.

Ereignis Antwort des klassischen Application Load Balancers Antwort des globalen externen Application Load Balancers
Status/Fehlercodes
Alle Back-Ends sind fehlerhaft Gibt HTTP 502 zurück Gibt HTTP 503 zurück
Anfrage verwendet eine gesperrte SSL-Chiffre Gibt HTTP 502 zurück Gibt HTTP 503 zurück
Frühe Upstream-Verbindung wurde vom Backend zurückgesetzt Gibt HTTP 502 zurück Gibt HTTP 503 zurück
Fehler beim Verbindungsupgrade (z. B. beim Upgrade auf WebSockets) Gibt HTTP 400 zurück Gibt HTTP 403 zurück
Header ist zu groß Gibt HTTP 413 zurück Gibt HTTP 431 zurück
Kontingente und Limits
Konfiguration der URL-Zuordnung Die Konfigurationslimits für die URL-Zuordnung unterscheiden sich erheblich zwischen den beiden Load Balancern. Weitere Informationen finden Sie in der Dokumentation Kontingente: URL-Zuordnungen.
Header-Verarbeitung
Anfrage verwendet eine benutzerdefinierte HTTP-Methode ohne Text Fügt den Header Transfer Encoding: Chunked der Anfrage hinzu, die an das Backend gesendet wird Fügt den Header Content-Length: 0 der Anfrage hinzu, die an das Backend gesendet wird
Format des X-Forwarded-For-Headers, wird der Anfrage hinzugefügt, die an das Backend gesendet wird Verwendet das Trennzeichen „, “ zwischen IP-Adressen Verwendet das Trennzeichen „,“ zwischen IP-Adressen (kein Leerzeichen nach dem Komma)
Beibehaltung der Header-Schreibweise Header-Schreibweise wird beibehalten Alle Headerschlüssel werden in Kleinbuchstaben umgewandelt.
Wiederkehrende Header mit demselben Namen Zugelassen Wiederkehrende Header können wie in RFC 7230 zugelassen in einem einzigen Header kombiniert werden, in dem die Werte in der richtigen Reihenfolge angehängt und durch Kommas getrennt sind.
(Nur HTTP/1.1) Ungültiger Header-Name (z. B. nicht unterstützte Zeichen im Header) Zulässig (für HTTP/1.1) Gibt HTTP 502 zurück (für HTTP/1.1)
(Nur HTTP/1.1) Wiederholter (aber derselbe) Content-Length-Header in der Anfrage Zulässig (für HTTP/1.1) Gibt HTTP 502 zurück (für HTTP/1.1)
(Nur HTTP/1.1) Mehrere Hosts im Header Wenn zwei oder mehr Hosts hinzugefügt werden und der erste gültig ist, wird der Header akzeptiert Wenn zwei oder mehr Hosts hinzugefügt werden und einige sind ungültig sind, gibt der Load-Balancer HTTP 502 zurück
(Nur HTTP/1.1) Connection: Keep-Alive-Header Fügt Keep-Alive header den Anfragen hinzu, die standardmäßig an das Backend gesendet werden Fügt diesen Header nicht standardmäßig hinzu
Anfragen verarbeiten
Rückschrägstriche in der Anfrage URL bleibt unverändert Umwandlung in Schrägstriche
Doppelte Schrägstriche in Anfrage zusammenführen Schrägstriche werden nicht zusammengeführt Schrägstriche werden zusammengeführt
„#“ im Anfragepfad Zulässig Gibt HTTP 400 zurück
(Nur HTTP/1.1) Unzulässige Zeichen im Anfragepfad (z. B. „\\x7f\\x7f“) Zulässig (für HTTP/1.1) Gibt HTTP 502 zurück (für HTTP/1.1)
Traffic-Verteilung (URL-Zuordnungskonfiguration)
Clientanfrage enthält eine Portnummer Die Portnummer wird auch dann ignoriert, wenn Sie Hosts mit Ports in der URL-Zuordnung konfiguriert haben. Es wird nur der Hostname berücksichtigt. Beispiel: Anfragen für example.com:5000 werden dem Backend-Dienst für example.com zugeordnet. Sowohl der Hostname als auch die Portnummer werden berücksichtigt. Beispiel: Anfragen für example.com:5000 werden dem Backend-Dienst für example.com:5000 zugeordnet. Wenn es keine Übereinstimmung gibt, wird der Standard-Backend-Dienst verwendet.

Weitere Informationen zu den Unterschieden und unterstützten Funktionen finden Sie unter Load Balancer-Features im Vergleich und Application Load Balancer.

Von klassischen zu globalen externen Application Load Balancern migrieren

Wenn Sie zu einem globalen externen Application Load Balancer migrieren möchten, ändern Sie das Load Balancing-Schema Ihrer Load Balancing-Ressourcen, insbesondere der Backend-Dienste und Weiterleitungsregeln, von EXTERNAL zu EXTERNAL_MANAGED. Dazu führen Sie eine Reihe von Migrationsschritten aus, bei denen Sie Teile Ihres Netzwerktraffics mit dem neuen Load Balancing-Schema testen können, bevor Sie die Migration abschließen. Während der Ressourcenmigration können Sie festlegen, welcher Prozentsatz der Anfragen an die klassische Application Load Balancer-Infrastruktur oder an die globale externe Application Load Balancer-Infrastruktur gesendet wird.

Das folgende Diagramm zeigt die Load Balancing-Schemas Ihrer Load Balancing-Ressourcen vor und nach der Migration.

Migrationsprozess für Ressourcen klassischer Application Load Balancer
Migrationsprozess für klassische Application Load Balancer-Ressourcen (zum Vergrößern anklicken)

Beachten Sie im vorherigen Diagramm Folgendes:

  • Bevor Ressourcen migriert werden, wird für alle Anfragen die klassische Application Load Balancer-Infrastruktur verwendet.
  • Während der Migration werden einige Anfragen an die globale externe Application Load Balancer-Infrastruktur und die verbleibenden Anfragen an die klassische Application Load Balancer-Infrastruktur gesendet.
  • Nach der Migration der Ressourcen werden für alle Anfragen die globalen externen Application Load Balancer-Infrastrukturen verwendet.

Für einen reibungslosen Übergang sollten Sie die folgenden Ressourcen des klassischen Application Load Balancers in der angegebenen Reihenfolge migrieren:

  1. Migrieren Sie alle Back-End-Dienste, die mit den Weiterleitungsregeln des Load Balancers verknüpft sind.

  2. Migrieren Sie alle Back-End-Buckets, die mit den Weiterleitungsregeln des Load Balancers verknüpft sind. Sie tun dies auf Ebene der Weiterleitungsregel, da Back-End-Buckets keine Load Balancing-Schemata haben.

  3. Migrieren Sie die Weiterleitungsregeln des Load Balancers.

    Sie können eine Weiterleitungsregel erst migrieren, nachdem alle mit der Weiterleitungsregel verknüpften Back-End-Dienste und Back-End-Buckets migriert wurden.

Migrationsstatus

Sie migrieren Ressourcen, indem Sie ihnen einen anderen Status zuweisen, bevor Sie das Load Balancing-Schema in EXTERNAL_MANAGED ändern.

  1. PREPARE: Sie können eine Ressource in diesen Status setzen, um sie für die Migration vorzubereiten.
  2. TEST_BY_PERCENTAGE: Wenn Sie eine vorbereitete Ressource testen möchten, legen Sie diesen Status für die Ressource fest, um einen Prozentsatz des Netzwerktraffics zu senden. Diese Phase ist optional.
  3. TEST_ALL_TRAFFIC: Legen Sie für eine Ressource diesen Status fest, um den gesamten Netzwerkverkehr über die globale externe Application Load Balancer-Infrastruktur an die Ressource zu senden, anstatt über die klassische Application Load Balancer-Infrastruktur.

Migrationsprozess

Um Ausfallzeiten zu vermeiden, sollten Sie die Ressourcen in einer bestimmten Reihenfolge von der Infrastruktur des klassischen Application Load Balancers zur Infrastruktur des globalen externen Application Load Balancers migrieren und dann das Load Balancing-Schema von EXTERNAL in EXTERNAL_MANAGED ändern, um die Migration abzuschließen.

  1. Migrieren Sie die Backend-Dienste des Load Balancers.

    Wiederholen Sie die folgenden Schritte für jeden Back-End-Dienst.

    1. Bereiten Sie den Backend-Dienst für die Migration vor.

      Bevor Traffic über die globale externe Application Load Balancer-Infrastruktur gesendet werden kann, müssen Sie den Status des Backend-Dienstes auf PREPARE festlegen. Dadurch wird der Backend-Dienst für die Verarbeitung des Netzwerkverkehrs der globalen externen Application Load Balancer-Infrastruktur vorbereitet. Es dauert einige Zeit (ungefähr sechs Minuten), bis ein Backend-Dienst Traffic über die globale externe Application Load Balancer-Infrastruktur senden kann.

    2. Optional: Testen Sie den vorbereiteten Backend-Dienst.

      Nachdem der Backend-Dienst den Status PREPARE hat, legen Sie den Status auf TEST_BY_PERCENTAGE fest und legen Sie einen Prozentsatz des Netzwerktraffics des klassischen Application Load Balancers auf die globale externe Application Load Balancer-Infrastruktur fest.

      Diese Phase ist optional. Wir empfehlen jedoch, den Traffic zu testen, bevor Sie einen Backend-Dienst migrieren. Beginnen Sie mit einem kleinen Prozentsatz und überwachen Sie die Protokolle der Ressourcen. Wenn sich der Back-End-Dienst wie erwartet verhält, erhöhen Sie den Prozentsatz schrittweise auf 100%.

      Im Status TEST_BY_PERCENTAGE können Sie die zusätzlichen Funktionen der globalen externen Application Load Balancer-Infrastruktur nicht verwenden.

    3. Senden Sie den gesamten Netzwerkverkehr des klassischen Application Load Balancers an den vorbereiteten Backend-Dienst.

      Nachdem der Test des Backend-Dienstes erfolgreich war, setzen Sie seinen Status auf TEST_ALL_TRAFFIC und senden Sie den gesamten Netzwerkverkehr des klassischen Anwendungs-Load Balancers an den vorbereiteten Backend-Dienst. Es dauert einige Zeit (ungefähr sechs Minuten), bis ein Backend-Dienst für die Verarbeitung des Netzwerktraffics bereit ist.

      Im Status TEST_ALL_TRAFFIC können Sie die zusätzlichen Funktionen der globalen externen Application Load Balancer-Infrastruktur nicht verwenden.

    4. Ändern Sie das Load Balancing-Schema des migrierten Backend-Dienstes in EXTERNAL_MANAGED.

      Nachdem Sie Ihren vorbereiteten Backend-Dienst in der globalen externen Application Load Balancer-Infrastruktur getestet haben, ändern Sie das Load Balancing-Schema in EXTERNAL_MANAGED. Die vollständige Migration eines Backend-Dienstes dauert einige Zeit (ungefähr sechs Minuten). Nachdem das Load Balancing-Schema des Backend-Dienstes in EXTERNAL_MANAGED geändert wurde, können Sie die erweiterten Funktionen der globalen externen Application Load Balancer-Infrastruktur verwenden.

  2. Migrieren Sie die Back-End-Buckets des Load Balancers. Sie tun dies auf Ebene der Weiterleitungsregel, da Backend-Buckets keine Load Balancing-Schemas haben.

    Wiederholen Sie die folgenden Schritte für jeden Bucket.

    1. Bereiten Sie den Backend-Bucket für die Migration vor.

      Bevor Traffic über die globale externe Application Load Balancer-Infrastruktur gesendet werden kann, müssen Sie den Status des Back-End-Buckets auf PREPARE setzen und einige Zeit warten (ca. sechs Minuten).

    2. Optional: Testen Sie den vorbereiteten Backend-Dienst.

      Nachdem der Backend-Bucket den Status PREPARE hat, ändern Sie den Status in TEST_BY_PERCENTAGE und legen Sie einen Prozentsatz des Netzwerktraffics des klassischen Application Load Balancers auf die globale externe Application Load Balancer-Infrastruktur fest.

    3. Senden Sie den gesamten Netzwerkverkehr des klassischen Application Load Balancers an den vorbereiteten Backend-Bucket.

      Legen Sie den Status des Backend-Buckets auf TEST_ALL_TRAFFIC fest und leiten Sie den gesamten Netzwerkverkehr des klassischen Application Load Balancers an ihn weiter. Es dauert einige Zeit (ungefähr sechs Minuten), bis ein Backend-Bucket für den Netzwerkverkehr bereit ist.

      Im Status TEST_ALL_TRAFFIC können Sie die zusätzlichen Funktionen der globalen externen Application Load Balancer-Infrastruktur nicht verwenden.

  3. Migrieren Sie die Weiterleitungsregeln.

    Ändern Sie für jede Weiterleitungsregel das Load Balancing-Schema in EXTERNAL_MANAGED und warten Sie einige Zeit (ca. sechs Minuten). Nachdem das Load Balancing-Schema der Weiterleitungsregel in EXTERNAL_MANAGED geändert wurde, können Sie die erweiterten Funktionen der globalen externen Application Load Balancer-Infrastruktur verwenden.

Eine detaillierte Anleitung finden Sie unter Ressourcen vom klassischen Application Load Balancer migrieren.

Das folgende Diagramm zeigt die Ressourcen des klassischen Application Load Balancers in den verschiedenen Migrationsstatus.

Migrationsstatus von Ressourcen des klassischen Application Load Balancers.
Migrationsstatus von klassischen Application Load Balancer-Ressourcen (zum Vergrößern anklicken)

Wenn Sie eine Ressource nach der Migration auf den klassischen Application Load Balancer zurücksetzen möchten, ändern Sie das Load Balancing-Schema innerhalb von 90 Tagen nach der Migration. Nach Ablauf der 90 Tage ist kein Rollback mehr möglich.

Sitzungsaffinität verwenden

Beachten Sie die folgenden Einschränkungen, wenn Sie klassische Application Load Balancer-Backend-Dienste mit Sitzungsaffinität migrieren:

  • Wenn Sie einen Wert für TEST_BY_PERCENTAGE festlegen, wird ein Teil des Traffics, der auf den klassischen Application Load Balancer ausgerichtet ist, an den globalen externen Application Load Balancer weitergeleitet. Dadurch wird die Client-IP-Affinität aufgehoben. Wenn Sie den Migrationsprozentsatz ändern (z. B. um 10%) wird die Sitzungsaffinität für denselben Prozentsatz der Client-IP-Adressen (in diesem Beispiel 10 %) aufgehoben, bis sie bei der nächsten Anfrage wiederhergestellt wird.

  • Wenn Sie einen Wert für TEST_BY_PERCENTAGE festlegen, wird dieser Prozentsatz des Traffics ohne Sitzungscookie an den globalen externen Application Load Balancer weitergeleitet. Außerdem wird der gesamte Traffic mit einem Sitzungscookie an die Load Balancer-Flotte weitergeleitet, die das Cookie generiert hat.

  • Wenn Sie für TEST_BY_PERCENTAGE den Wert „0 %“ festlegen oder ihn nicht festlegen oder den Backend-Dienst in den Status PREPARE setzen, werden alle vorhandenen Cookies ungültig, die an den globalen externen Application Load Balancer weitergeleitet werden.

  • Wenn Sie das Load Balancing-Schema des Backend-Dienstes in EXTERNAL_MANAGED ändern, werden alle Cookies ungültig, die von der klassischen Application Load Balancer-Flotte generiert wurden. So können Sie den Traffic rückgängig machen, wenn ein Problem mit Ihrer Anwendung auftritt, die den globalen externen Application Load Balancer verwendet. Wenn ein Client beispielsweise ein Cookie aus der klassischen Application Load Balancer-Flotte vorlegt, das Backend-Dienstschema aber EXTERNAL_MANAGED ist, wird das Cookie des Clients nicht berücksichtigt. Der globale externe Application Load Balancer ignoriert das Cookie und erstellt ein neues.

Migrierte Ressourcen rückgängig machen

Wenn Sie eine Ressource nach der Migration von der Infrastruktur des globalen externen Application Load Balancers zur Infrastruktur des klassischen Application Load Balancers zurückverschieben möchten, können Sie dies innerhalb von 90 Tagen nach der Änderung des Load Balancing-Schemas tun.

Wenn Sie einen Backend-Dienst auf das EXTERNAL-Schema zurücksetzen möchten, müssen Sie auch die Weiterleitungsregel rückgängig machen. Wenn Sie eine Weiterleitungsregel auf das EXTERNAL-Schema zurücksetzen, müssen die Backend-Dienste nicht rückgängig gemacht werden.

So machen Sie Änderungen an Ressourcen rückgängig:

  1. Entfernen Sie alle neuen erweiterten Funktionen zur Traffic-Verwaltung des globalen externen Application Load Balancers, die für die Ressource konfiguriert wurden.

  2. Machen Sie die Weiterleitungsregeln rückgängig.

    Ändern Sie das Load Balancing-Schema der Weiterleitungsregeln von EXTERNAL_MANAGED in EXTERNAL.

  3. Führen Sie ein Rollback der Back-End-Buckets durch.

    1. Legen Sie den Migrationsstatus der Back-End-Buckets auf TEST_ALL_TRAFFIC fest und warten Sie einige Zeit (ca. sechs Minuten).
    2. Optional: Wenn Sie den Traffic verringern möchten, legen Sie den Migrationsstatus der Backend-Buckets auf TEST_BY_PERCENTAGE fest und geben Sie einen Prozentsatz des Traffics an.
    3. Legen Sie den Migrationsstatus der Back-End-Buckets auf PREPARE fest.
    4. Stellen Sie die Backend-Buckets in den Zustand vor der Migration zurück.

  4. Führen Sie ein Rollback der Back-End-Dienste durch.

    1. Legen Sie den Migrationsstatus der Back-End-Dienste auf TEST_ALL_TRAFFIC fest und warten Sie einige Zeit (ungefähr sechs Minuten).
    2. Optional: Wenn Sie den Traffic verringern möchten, legen Sie den Migrationsstatus der Back-End-Dienste auf TEST_BY_PERCENTAGE fest und legen Sie einen Prozentsatz des Traffics fest.
    3. Legen Sie den Migrationsstatus der Back-End-Dienste auf PREPARE fest.
    4. Setzen Sie die Backend-Dienste auf den Zustand vor der Migration zurück.

Eine detaillierte Schritt-für-Schritt-Anleitung finden Sie unter Migrierte Ressourcen auf den klassischen Application Load Balancer zurücksetzen.

Migrationsprozess verfolgen

Während der Migration Ihrer Ressourcen können Sie die Load Balancing-Schemata prüfen. Rufen Sie dazu Folgendes auf:

  • Die Logging- und Monitoring-Dashboards des globalen externen Application Load Balancers. Weitere Informationen finden Sie unter Logging und Monitoring für globale externe Application Load Balancer.

  • Die Werte der folgenden HTTP-Anfrage- und -Antwortheader:

    • X-External-Managed-Migration-Scheme-Override: Dieser Anfrageheader leitet die Anfrage basierend auf ihrem Wert weiter. Wenn der Headerwert EXTERNAL ist, wird die Anfrage an die klassische Application Load Balancer-Infrastruktur weitergeleitet. Wenn der Wert EXTERNAL_MANAGED ist, wird die Anfrage über die globale externe Application Load Balancer-Infrastruktur weitergeleitet.

      Verwenden Sie diesen Header, um eine Anfrage an eine bestimmte Load Balancer-Flotte zu senden.

    • X-External-Managed-Migration-Selected-Scheme: Dieser Anfrage- und Antwortheader informiert das Backend und den Client über das Load Balancing-Schema, das für die Weiterleitung der Anfrage verwendet wird. Der Header wird an den Client zurückgegeben und an das Backend des Kunden übergeben.

      Wenn die Anfrage über die klassische Application Load Balancer-Infrastruktur weitergeleitet wird, ist der Wert EXTERNAL. Wenn die Anfrage über die globale externe Application Load Balancer-Infrastruktur weitergeleitet wird, lautet der Wert EXTERNAL_MANAGED.

Nächste Schritte