Globalen externen Application Load Balancer von Single Stack in Dual Stack umwandeln

In diesem Dokument wird gezeigt, wie Sie globale externe Application Load Balancer-Ressourcen und -Backends von nur IPv4 (single-stack) zu IPv4 und IPv6 (dual-stack) konvertieren. In diesem Dokument bezieht sich nur IPv4 (Einzelstack) auf die Ressourcen, die nur IPv4-Adressen verwenden, und IPv4 und IPv6 (Dual-Stack) bezieht sich auf die Ressourcen, die sowohl IPv4- als auch IPv6-Adressen verwenden.

Vorteile

Das Umwandeln Ihrer Load-Balancer in Dual Stack bietet mehrere Vorteile:

• Der Hauptvorteil von IPv6 besteht darin, dass ein viel größerer Pool von IP-Adressen zugewiesen werden kann.

• Viele Kunden, die bereits reine IPv4-Load-Balancer verwenden, können mithilfe von cloud-spezifischen Methoden von reinen IPv4-Ressourcen in IPv4- und IPv6-Ressourcen (Dual-Stack) konvertieren.

• Sie können den Load-Balancer so konfigurieren, dass eingehender IPv6-Traffic beendet wird und dieser Traffic per Proxy über eine IPv4- oder IPv6-Verbindung (je nach Ihren Wünschen) an Ihre Back-Ends weitergeleitet wird. Weitere Informationen finden Sie unter IPv6.

Beschränkungen

• Hinweis: Sie können den IP-Stacktyp des Subnetzes nicht von IPv4 und IPv6 (Dual-Stack) auf nur IPv4 aktualisieren.

• Wenn Sie die Richtlinie zur IP-Adressauswahl für den Backend-Dienst als "nur IPv6" konfigurieren, können Sie dennoch "nur IPv4"-Backends konfigurieren. Eine solche Konfiguration führt zu fehlerhaften Back-Ends. Clients erhalten den Antwortcode 503. und der Traffic fließt nicht upstream. Die Protokolle enthalten failed_to_pick_backend in den statusDetails HTTP-Fehlermeldungen.

• Sie können die Richtlinie zur IP-Adressauswahl des Backend-Dienstes auf "nur IPv6" konfigurieren. Der IP-Stack-Typ der Backends ist jedoch immer IPv4 und IPv6 (Dual-Stack).

• Nur VM-Instanzgruppen-Back-Ends und zonale Netzwerk-Endpunktgruppe (NEG) mit GCE_VM_IP_PORT-Endpunkten unterstützen IPv4 und IPv6 (Dual-Stack).

Hinweise

Sie müssen bereits einen globalen externen SSL-Proxy- oder TCP-Proxy-Application Load Balancer mit "nur IPv4"-Stack mit einer Instanzgruppe oder zonalen NEG-Back-Ends eingerichtet haben.

Weitere Informationen zum Einrichten globaler externer Application Load Balancer finden Sie in der folgenden Dokumentation:

• Globalen externen Application Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten
• Globalen externen Application Load Balancer mit zonalen NEGs einrichten

Zu konvertierende Ressourcen identifizieren

Notieren Sie die Namen der Ressourcen, denen Ihr Load-Balancer zugeordnet ist. Sie müssen diese Namen später angeben.

1. Verwenden Sie den Befehl gcloud compute networks subnets list, um alle Subnetze aufzulisten:

   gcloud compute networks subnets list
   

   Notieren Sie sich den Namen des Subnetzes mit reinen IPv4-Adressen, die zu Dual-Stack migriert werden sollen. Diese wird später als SUBNET bezeichnet. Das VPC-Netzwerk wird später als NETWORK bezeichnet.

2. Um alle Backend-Dienste aufzulisten, verwenden Sie die gcloud beta compute backend-services list-Befehl:

   gcloud beta compute backend-services list
   

   Notieren Sie sich den Namen des Backend-Dienstes, der zu Dual-Stack konvertiert werden soll. Diese wird später als BACKEND_SERVICE bezeichnet.

3. Verwenden Sie den Befehl gcloud beta compute url-maps list, um alle URL-Zuordnungen aufzulisten:

   gcloud beta compute url-maps list
   

   Notieren Sie sich den Namen der URL-Zuordnung, die Ihrem Load-Balancer zugeordnet ist. Diese wird später als URL_MAP bezeichnet.

4. Wenn Sie bereits einen Load-Balancer haben, verwenden Sie den Befehl gcloud compute instances list, um den IP-Stacktyp Ihrer Back-Ends aufzurufen:

   gcloud compute instances list \
       --format= \
       "table(
       name,
       zone.basename(),
       networkInterfaces[].stackType.notnull().list(),
       networkInterfaces[].ipv6AccessConfigs[0].externalIpv6.notnull().list():label=EXTERNAL_IPV6,
       networkInterfaces[].ipv6Address.notnull().list():label=INTERNAL_IPV6)"
   

5. Verwenden Sie zum Auflisten aller VM-Instanzen und Instanzvorlagen den Befehl gcloud compute instances list und den Befehl gcloud compute instance-templates list:

   gcloud compute instances list
   

   gcloud compute instance-templates list
   

   Notieren Sie sich die Namen der Instanzen und Instanzvorlagen, die in Dual-Stack konvertiert werden sollen. Dieser wird später als VM_INSTANCE und INSTANCE_TEMPLATES bezeichnet.

6. Mit dem Befehl gcloud compute network-endpoint-groups list können Sie alle zonalen Netzwerk-Endpunktgruppen (NEGs) auflisten:

   gcloud compute network-endpoint-groups list
   

   Notieren Sie sich die Namen der zonalen NEG-Back-Ends, die in Dual-Stack konvertiert werden sollen. Diese wird später als ZONAL_NEG bezeichnet.

7. Verwenden Sie den Befehl gcloud compute target-http-proxies list, um alle Zielproxys aufzulisten:

   gcloud compute target-http-proxies list
   

   Notieren Sie sich den Namen des mit Ihrem Load Balancer verknüpften Zielproxys. Diese wird später als TARGET_PROXY bezeichnet.

Von Single-Stack- in Dual-Stack-Back-Ends konvertieren

In diesem Abschnitt erfahren Sie, wie Sie Ihre Ressourcen und Back-Ends, die nur IPv4-Adressen (Single-Stack) verwenden, in IPv4- und IPv6-Adressen (Dual-Stack) konvertieren.

Subnetz aktualisieren

Dual-Stack-Subnetze werden nur in VPC-Netzwerken im benutzerdefinierten Modus unterstützt. Dual-Stack-Subnetze werden in VPC-Netzwerken im Legacy-Modus oder Legacy-Netzwerken nicht unterstützt. Während Netzwerke im automatischen Modus für eine erste Erkundung hilfreich sein können, sind für die meisten Produktionsumgebungen VPC-Netzwerke im benutzerdefinierten Modus besser geeignet. Wir empfehlen, VPCs im benutzerdefinierten Modus zu verwenden.

So aktualisieren Sie das VPC auf die Dual-Stack-Einstellung:

1. Wenn Sie ein VPC-Netzwerk im automatischen Modus verwenden, müssen Sie zuerst das VPC-Netzwerk im automatischen Modus in den benutzerdefinierten Modus umwandeln.

2. Informationen zum Aktivieren von IPv6 finden Sie unter Stack-Typ eines Subnetzes in Dual-Stack ändern.

3. Optional: Führen Sie die folgenden Schritte aus, um interne IPv6-Adressbereiche in Subnetzen in diesem Netzwerk zu konfigurieren:

   1. Wählen Sie für Interner VPC-Netzwerk-IPv6-ULA-Bereich den Wert Aktiviert aus.

   2. Wählen Sie unter Internen IPv6-Bereich zuweisen die Option Automatisch oder Manuell aus.

      Geben Sie einen /48-Bereich aus dem Bereich fd20::/20 ein, wenn Sie Manuell auswählen. Wenn der Bereich verwendet wird, werden Sie aufgefordert, einen anderen Bereich anzugeben.

VM-Instanz oder Vorlagen aktualisieren

Sie können IPv6-Adressen auf einer VM-Instanz konfigurieren, wenn in dem Subnetz, mit dem die VM verbunden ist, ein IPv6-Bereich konfiguriert ist. Nur die folgenden Back-Ends können IPv6-Adressen unterstützen:

• Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends
• zonalen NEGs: eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT

VM-Instanzen aktualisieren

VM-Instanzen, die Teil einer verwalteten oder nicht verwalteten Instanzgruppe sind, können nicht bearbeitet werden. So aktualisieren Sie die VM-Instanzen auf Dual-Stack:

1. Bestimmte Instanzen aus einer Gruppe löschen
2. Dual-Stack-VM erstellen
3. Instanzen mit bestimmten Namen in MIGs erstellen

VM-Instanzvorlagen aktualisieren

Sie können eine vorhandene Instanzvorlage nicht aktualisieren. Wenn Sie Änderungen vornehmen müssen, können Sie eine weitere Vorlage mit ähnlichen Attributen erstellen. So aktualisieren Sie die VM-Instanzvorlagen auf Dual-Stack:

Zonale NEG aktualisieren

Zonale NEG-Endpunkte können nicht bearbeitet werden. Sie müssen die IPv4-Endpunkte löschen und einen neuen Dual-Stack-Endpunkt mit IPv4- und IPv6-Adressen erstellen.

Erstellen Sie zuerst die VMs in der Zone GCP_NEG_ZONE, um eine zonale NEG (mit Endpunkten des Typs GCE_VM_IP_PORT) in der Region REGION_A einzurichten. Fügen Sie dann der zonalen NEG die VM-Netzwerkendpunkte hinzu.

VMs erstellen

Fügen Sie der zonalen NEG Endpunkte hinzu

Firewallregel für die IPv6-Systemdiagnose erstellen

Sie benötigen eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und Traffic von den Systemdiagnosen von Google Cloud zulässt (2600:2d00:1:b029::/64, 2600:2d00:1:1::/64). In diesem Beispiel wird das Ziel-Tag allow-health-check-ipv6 verwendet, um die VM-Instanzen zu identifizieren, auf die sie angewendet wird.

Ohne diese Firewallregeln blockiert die Standardregel zum Ablehnen von eingehendem Traffic den eingehenden Traffic zu den Backend-Instanzen.

Neuen Backend-Dienst und neue Weiterleitungsregel für IPv6 erstellen

In diesem Abschnitt wird beschrieben, wie Sie einen neuen Backend-Dienst und eine Weiterleitungsregel für IPv6 erstellen.

Sowohl BACKEND_SERVICE als auch BACKEND_SERVICE_IPV6 können Traffic bereitstellen. Erstellen Sie einen neuen Back-End-Dienst mit der IP-Adress-Auswahlrichtlinie auf „Prefer IPv6“ festgelegt, um Traffic-Unterbrechungen zu vermeiden. Nachdem Sie den neuen Backend-Dienst erstellt haben, können Sie Traffic an den neuen IPv6-Backend-Dienst weiterleiten.

Traffic an den neuen IPv6-Backend-Dienst weiterleiten

Aktualisieren Sie die URL-Zuordnung, um einen Teil des Clienttraffics an den neuen IPv6-Backend-Dienst BACKEND_SERVICE_IPV6 weiterzuleiten.

1. Verwenden Sie den folgenden Befehl, um die URL-Zuordnungen zu bearbeiten:

   gcloud compute url-maps edit URL_MAP \
       --global
   

2. Fügen Sie im angezeigten Texteditor ein routeRule mit der Aktion weightedBackendServices hinzu, die einen Prozentsatz des IPv6-Traffics an BACKEND_SERVICE_IPV6 weiterleitet.

   defaultService: global/backendServices/BACKEND_SERVICE
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP
   pathMatchers:
   - defaultService: global/backendServices/BACKEND_SERVICE
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: ''
       priority: 1
       routeAction:
         weightedBackendServices:
         - backendService: global/backendServices/BACKEND_SERVICE
           weight: 95
         - backendService: global/backendServices/BACKEND_SERVICE_IPV6
           weight: 5
   

Erhöhen Sie für die Implementierung einer graduellen Migration zu IPv6 den Gewichtungsprozentsatz für den neuen Backend-Dienst BACKEND_SERVICE_IPV6 schrittweise auf 100 %. Dazu bearbeiten Sie die URL-Zuordnung mehrmals.

Richtlinie zur IP-Adressauswahl konfigurieren

Dieser Schritt ist optional. Nachdem Sie Ihre Ressourcen und Back-Ends in Dual-Stack konvertiert haben, können Sie mithilfe der Richtlinie zur IP-Adressauswahl den Traffictyp angeben, der vom Google Front End (GFE) an Ihre Back-Ends gesendet wird.

Ersetzen Sie IP_ADDRESS_SELECTION_POLICY durch einen der folgenden Werte:

Richtlinie zur IP-Adressauswahl	Beschreibung
Nur IPv4	Senden Sie nur IPv4-Traffic an die Backends des Backend-Dienstes, unabhängig vom Traffic vom Client zum GFE. Es werden nur IPv4-Systemdiagnosen verwendet, um den Status der Backends zu prüfen.
IPv6 bevorzugen	Priorisieren Sie die IPv6-Verbindung des Backends gegenüber der IPv4-Verbindung (sofern ein fehlerfreies Backend mit IPv6-Adressen vorhanden ist). Die Systemdiagnosen überwachen regelmäßig die IPv6- und IPv4-Verbindungen der Backends. Das GFE versucht zuerst die IPv6-Verbindung. Wenn die IPv6-Verbindung unterbrochen oder langsam ist, verwendet das GFE glückliche Augen, um ein Fallback auszuführen und eine Verbindung zu IPv4 herzustellen. Selbst wenn eine der IPv6- oder IPv4-Verbindungen fehlerhaft ist, wird das Backend weiterhin als fehlerfrei behandelt. Beide Verbindungen können vom GFE getestet werden, wobei letztendlich die Augenmerk sich entscheiden, welche sie verwenden möchten.
Nur IPv6	Senden Sie nur IPv6-Traffic an die Backends des Backend-Dienstes, unabhängig vom Traffic vom Client zum Proxy. Nur IPv6-Systemdiagnosen werden verwendet, um den Status der Backends zu prüfen. Es gibt keine Validierung, um zu prüfen, ob der Backend-Traffictyp mit der Richtlinie zur IP-Adressauswahl übereinstimmt. Wenn Sie beispielsweise IPv4-Back-Ends haben und Only IPv6 als Richtlinie zur IP-Adressauswahl auswählen, werden keine Konfigurationsfehler angezeigt, aber der Traffic fließt nicht zu Ihren Backends.

Load-Balancer testen

Sie müssen prüfen, ob alle erforderlichen Ressourcen auf Dual Stack aktualisiert wurden. Nachdem Sie alle Ressourcen aktualisiert haben, muss der Traffic automatisch zu den Back-Ends fließen. Sie können die Logs prüfen und prüfen, ob die Konvertierung abgeschlossen ist.

Testen Sie den Load Balancer, um zu prüfen, ob die Migration erfolgreich ist und der eingehende Traffic die Backends wie erwartet erreicht.

Externe IP-Adresse des Load Balancers ermitteln

Traffic an Instanzen senden

In diesem Beispiel werden Anfragen vom Befehl curl nach dem Zufallsprinzip auf die Backends verteilt.

1. Wiederholen Sie den folgenden Befehl einige Male, bis alle Backend-VMs antworten.

   curl http://IP_ADDRESS_IPV4
   

   curl http://IP_ADDRESS_IPV6
   

   Wenn die IPv6-Adresse beispielsweise [fd20:1db0:b882:802:0:46:0:0]:80 lautet, sieht der Befehl in etwa so aus:

   curl http://[fd20:1db0:b882:802:0:46:0:0]
   

Log prüfen

Jeder Logeintrag erfasst die IPv4- und IPv6-Zieladresse für das Backend. Da wir Dual-Stack unterstützen, ist es wichtig, die vom Backend verwendete IP-Adresse zu beobachten.

Rufen Sie die Logs auf, um zu prüfen, ob der Traffic an IPv6 gesendet wird oder auf IPv4 zurückfällt.

Die HttpRequest enthält die backend_ip-Adresse, die dem Backend zugeordnet ist. Anhand der Logs und dem Vergleich der IPv4- und IPv6-Zieladresse von backend_ip können Sie feststellen, welche IP-Adresse verwendet wird.