Migration – Übersicht

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 zur Migration Ihrer vorhandenen klassischen Application Load Balancer-Ressourcen zum globalen externen Application Load Balancer.

Wenn Sie die erweiterten Funktionen zur Trafficverwaltung des globalen externen Application Load Balancers nutzen möchten, empfehlen wir, Ihre Ressourcen des klassischen Application Load Balancers zur Infrastruktur des globalen externen Application Load Balancers 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.

Aufgrund architektonischer Unterschiede kann es bei der Migration zum globalen externen Application Load Balancer zu einer Zunahme der Anzahl der Verbindungen zu Ihren Back-Ends kommen, insbesondere bei Verwendung des HTTP/1.1-Protokolls. Dies kann zu einem erhöhten Arbeitsspeicherverbrauch auf den Backend-Instanzen führen. Überwachen Sie die Nutzung Ihrer Backend-Ressourcen während und nach der Migration.

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

Um zu einem globalen externen Application Load Balancer zu migrieren, ä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 Netzwerk-Traffics 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 Infrastruktur des klassischen Application Load Balancers oder an die Infrastruktur des globalen externen Application Load Balancers gesendet wird.

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

Migrationsprozess für Ressourcen des klassischen Application Load Balancer.
Migrationsprozess für klassische Application Load Balancer-Ressourcen (zum Vergrößern klicken).

Beachten Sie im vorherigen Diagramm Folgendes:

  • Vor der Migration von Ressourcen werden alle Anfragen über die Infrastruktur des klassischen Application Load Balancers weitergeleitet.
  • Während der Migration der Ressourcen werden einige Anfragen an die Infrastruktur des globalen externen Application Load Balancers und die verbleibenden Anfragen an die Infrastruktur des klassischen Application Load Balancers gesendet.
  • Nach der Migration der Ressourcen werden alle Anfragen über die Infrastruktur des globalen externen Application Load Balancers weitergeleitet.

Um einen reibungslosen Übergang zu gewährleisten, migrieren Sie die folgenden Ressourcen des klassischen Application Load Balancers in der angegebenen Reihenfolge:

  1. Migrieren Sie alle Backend-Dienste, die an die Weiterleitungsregeln des Load-Balancers angehängt sind.

  2. Migrieren Sie alle Back-End-Buckets, die an die Weiterleitungsregeln des Load-Balancers angehängt sind. Das erfolgt auf der Ebene der Weiterleitungsregel, da Backend-Buckets keine Load-Balancing-Schemata haben.

  3. Weiterleitungsregeln des Load-Balancers migrieren.

    Sie können eine Weiterleitungsregel erst migrieren, wenn alle Backend-Dienste und Backend-Buckets, die an die Weiterleitungsregel angehängt sind, bereits migriert wurden.

Migrationsstatus

Sie migrieren Ressourcen, indem Sie sie in verschiedene Status versetzen, bevor Sie ihr Load-Balancing-Schema in EXTERNAL_MANAGED ändern.

  1. PREPARE: Wenn Sie eine Ressource in diesen Status versetzen, bereiten Sie sie für die Migration vor.
  2. TEST_BY_PERCENTAGE: Wenn Sie eine vorbereitete Ressource testen möchten, legen Sie die Ressource auf diesen Status fest, um einen bestimmten Prozentsatz des Netzwerkverkehrs zu senden. Diese Phase ist optional.
  3. TEST_ALL_TRAFFIC: Wenn Sie eine Ressource in diesen Status versetzen, wird der gesamte Netzwerkverkehr zur Ressource über die Infrastruktur des globalen externen Application Load Balancers anstelle der Infrastruktur des klassischen Application Load Balancers gesendet.

Migrationsprozess

Um Ausfallzeiten zu vermeiden, migrieren Sie Ressourcen in einer bestimmten Reihenfolge von der Infrastruktur des klassischen Application Load Balancer zur Infrastruktur des globalen externen Application Load Balancer und ändern dann das Load-Balancing-Schema von EXTERNAL zu EXTERNAL_MANAGED, 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 Infrastruktur des globalen externen Application Load Balancers gesendet werden kann, müssen Sie den Status des Backend-Dienstes auf PREPARE festlegen. Dadurch wird der Backend-Dienst für die Verarbeitung des Infrastrukturnetzwerk-Traffics globaler externer Application Load Balancer vorbereitet. Es dauert einige Zeit (ca. sechs Minuten), bis ein Backend-Dienst bereit ist, Traffic über die Infrastruktur des globalen externen Application Load Balancers zu senden.

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

      Nachdem sich der Backend-Dienst im Status PREPARE befindet, stellen Sie seinen Status auf TEST_BY_PERCENTAGE ein und legen Sie einen Prozentsatz des Netzwerk-Traffics des klassischen Application Load Balancers auf die Infrastruktur des globalen externen Application Load Balancers fest.

      Diese Phase ist zwar optional, wir empfehlen jedoch, den Traffic zu testen, bevor Sie einen Backend-Dienst migrieren. Beginnen Sie mit einem kleinen Prozentwert und beobachten Sie die Logs der Ressourcen. Wenn sich der Backend-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 Infrastruktur des globalen externen Application Load Balancers nicht nutzen.

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

      Nachdem der Backend-Dienst erfolgreich getestet wurde, legen Sie seinen Status auf TEST_ALL_TRAFFIC fest und leiten Sie den gesamten Netzwerk-Traffic des klassischen Application Load Balancers an den vorbereiteten Backend-Dienst weiter. Es dauert einige Zeit (etwa sechs Minuten), bis ein Backend-Dienst bereit ist, den Netzwerk-Traffic zu verarbeiten.

      Im Status TEST_ALL_TRAFFIC können Sie die zusätzlichen Funktionen der Infrastruktur des globalen externen Application Load Balancers nicht nutzen.

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

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

  2. Migrieren Sie die Backend-Buckets des Load-Balancers. Dies erfolgt auf der 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 Infrastruktur des globalen externen Application Load Balancers gesendet werden kann, müssen Sie den Status des Backend-Buckets auf PREPARE festlegen und einige Zeit (ca. sechs Minuten) warten.

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

      Nachdem sich der Backend-Bucket im Status PREPARE befindet, stellen Sie seinen Status auf TEST_BY_PERCENTAGE ein und legen Sie einen Prozentsatz des Netzwerkverkehrs des klassischen Application Load Balancers auf die Infrastruktur des globalen externen Application Load Balancers fest.

    3. Senden Sie den gesamten Netzwerk-Traffic 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 Netzwerk-Traffic des klassischen Application Load Balancers dorthin weiter. Es dauert einige Zeit (etwa sechs Minuten), bis ein Backend-Bucket bereit ist, um den Netzwerkverkehr zu verarbeiten.

      Im Status TEST_ALL_TRAFFIC können Sie die zusätzlichen Funktionen der Infrastruktur des globalen externen Application Load Balancers nicht nutzen.

  3. Migrieren Sie die Weiterleitungsregeln.

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

Eine detaillierte Schritt-für-Schritt-Anleitung finden Sie unter Ressourcen vom klassischen Application Load Balancer migrieren.

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

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

Wenn Sie eine migrierte Ressource innerhalb von 90 Tagen nach der Migration auf den klassischen Application Load Balancer zurücksetzen möchten, ändern Sie das Load-Balancing-Schema. Nach Ablauf des 90‑Tage-Zeitraums können Sie für eine Ressource kein Rollback mehr durchführen.

Sitzungsaffinität verwenden

Beachten Sie die folgenden Einschränkungen, wenn Sie Backend-Dienste für klassische Application Load Balancer 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 von Client-IP-Adressen (in diesem Beispiel 10 %) unterbrochen, bis die Affinität 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, ihn nicht festlegen oder den Backend-Dienst auf den Status PREPARE setzen, werden alle vorhandenen Cookies, die an den globalen externen Application Load Balancer gerichtet sind, ungültig.

  • Wenn Sie das Load-Balancing-Schema des Backend-Dienstes in EXTERNAL_MANAGED ändern, werden alle Cookies ungültig, die von der Flotte klassischer Application Load Balancer generiert wurden. So können Sie den Traffic zurücksetzen, wenn es ein Problem mit Ihrer Anwendung gibt, die den globalen externen Application Load Balancer verwendet. Wenn ein Client beispielsweise ein Cookie aus der Flotte des klassischen Application Load Balancer präsentiert, 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 zurücksetzen

Wenn Sie eine migrierte Ressource nach der Migration von der Infrastruktur des globalen externen Application Load Balancers zur Infrastruktur des klassischen Application Load Balancers zurücksetzen 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üssen Sie auch die Weiterleitungsregel zurücksetzen. Wenn Sie eine Weiterleitungsregel auf das EXTERNAL-Schema zurücksetzen, müssen Sie die Backend-Dienste nicht zurücksetzen.

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

  1. Entfernen Sie alle neuen erweiterten Traffic-Verwaltungsfunktionen des globalen externen Application Load Balancer, die für die Ressource konfiguriert sind.

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

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

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

    1. Legen Sie den Migrationsstatus der Backend-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 von Backend-Buckets auf TEST_BY_PERCENTAGE fest und geben Sie einen Prozentsatz des Traffics an.
    3. Legen Sie den Migrationsstatus von Backend-Buckets auf PREPARE fest.
    4. Backend-Buckets in den Zustand vor der Migration zurücksetzen.

  4. Machen Sie die Änderungen an den Backend-Diensten rückgängig.

    1. Legen Sie den Migrationsstatus von Back-End-Diensten 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 von Back-End-Diensten auf TEST_BY_PERCENTAGE fest und geben Sie einen Prozentsatz des Traffics an.
    3. Legen Sie den Migrationsstatus von Backend-Diensten auf PREPARE fest.
    4. Backend-Dienste in den Zustand vor der Migration zurücksetzen

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 so prüfen:

  • Die Dashboards für Logging und Monitoring 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 seinem Wert weiter. Wenn der Headerwert EXTERNAL ist, wird die Anfrage an die Infrastruktur des klassischen Application Load Balancer weitergeleitet. Wenn der Wert EXTERNAL_MANAGED ist, wird die Anfrage über die Infrastruktur des globalen externen Application Load Balancers weitergeleitet.

      Mit diesem Header können Sie eine Anfrage an eine bestimmte Load-Balancer-Flotte weiterleiten.

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

      Wenn die Anfrage über die Infrastruktur des klassischen Application Load Balancer weitergeleitet wird, ist der Wert EXTERNAL. Wenn die Anfrage über die Infrastruktur des globalen externen Application Load Balancers weitergeleitet wird, ist der Wert EXTERNAL_MANAGED.

Nächste Schritte