Diese Seite wurde von der Cloud Translation API übersetzt.

Application Load Balancer in IPv6 konvertieren

In diesem Dokument wird gezeigt, wie Sie Application Load Balancer-Ressourcen und -Backends von nur IPv4 (Single-Stack) zu IPv4 und IPv6 (Dual-Stack) konvertieren. Der Hauptvorteil von IPv6 besteht darin, dass ein viel größerer Pool von IP-Adressen zugewiesen werden kann. 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 für Application Load Balancer und Proxy-Network Load Balancer.

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.

Hinweise

Beachten Sie die folgenden Bedingungen, bevor Sie mit der Umwandlung beginnen:

Sie müssen einen der folgenden Application Load Balancer-Typen verwenden:
- Globaler externer Application Load Balancer
- Regionaler externer Application Load Balancer
- Regionsübergreifender interner Application Load Balancer
- Regionaler interner Application Load Balancer
Klassische Application Load Balancer unterstützen keine Dual-Stack-Backends oder ‑Subnetze. Weitere Informationen zur IPv6-Unterstützung finden Sie unter IPv6 für Application Load Balancer und Proxy-Network Load Balancer.
Ihr Load Balancer muss entweder VM-Instanzgruppen-Back-Ends oder zonale NEG-Back-Ends (Network End Point Group) mit GCE_VM_IP_PORT-Endpunkten haben. Andere Backend-Typen unterstützen keinen Dual-Stack.

Außerdem hängt der Umwandlungsprozess vom Typ des Load Balancers ab.

Bei globalen externen Application Load Balancern konvertieren Sie die Back-Ends in Dual-Stack und erstellen Sie eine IPv6-Weiterleitungsregel, die eingehenden IPv6-Traffic verarbeiten kann.
Bei regionenübergreifenden internen Application Load Balancern, regionalen externen Application Load Balancern und regionalen internen Application Load Balancern müssen Sie nur die Back-Ends in Dual-Stack konvertieren. IPv6-Weiterleitungsregeln werden für diese Load Balancer nicht unterstützt.

Informationen zum Einrichten von Application Load Balancern finden Sie in der folgenden Dokumentation:

Globalen externen Application Load Balancer einrichten: VM-Instanzgruppen-Backends, zonal NEG-Backends
Regionalen externen Application Load Balancer einrichten: VM-Instanzgruppen-Back-Ends, zonale NEG-Back-Ends
Regionenübergreifenden internen Application Load Balancer einrichten: VM-Instanzgruppen-Back-Ends, zonale NEG-Back-Ends
Regionalen internen Application Load Balancer einrichten: VM-Instanzgruppen-Back-Ends, zonale NEG-Back-Ends

Zu konvertierende Ressourcen identifizieren

Notieren Sie sich die Namen der Ressourcen, die mit Ihrem Load Balancer verknüpft sind. Sie müssen diese Namen später angeben.

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, das zu Dual-Stack migriert werden soll. Diese wird später als SUBNET bezeichnet. Das VPC-Netzwerk wird später als NETWORK bezeichnet.
Verwenden Sie den Befehl gcloud compute backend-services list, um alle Backend-Dienste aufzulisten:
```
gcloud 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.
Verwenden Sie den Befehl gcloud compute url-maps list, um alle URL-Zuordnungen aufzulisten:
```
gcloud 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.

Wenn Sie bereits einen Load Balancer haben, verwenden Sie den Befehl gcloud compute instances list, um den IP-Stacktyp Ihrer Backends 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)"

Verwenden Sie den Befehl gcloud compute instances list und den Befehl gcloud compute instance-templates list, um alle VM-Instanzen und Instanzvorlagen aufzulisten:
```
gcloud compute instances list
```
```
gcloud compute instance-templates list
```
Notieren Sie sich die Namen der Instanzen und Instanzvorlagen, die zu Dual-Stack migriert werden sollen. Dieser wird später als VM_INSTANCE und INSTANCE_TEMPLATES bezeichnet.
Verwenden Sie den gcloud compute instance-groups list-Befehl, um alle Instanzgruppen aufzulisten:
```
gcloud compute instance-groups list
```
Notieren Sie sich den Namen der Netzwerk-Endpunktgruppen, die zu Dual-Stack migriert werden sollen. Diese wird später als INSTANCE_GROUP bezeichnet.
Verwenden Sie den Befehl gcloud compute network-endpoint-groups list, um alle zonalen Netzwerk-Endpunktgruppen aufzulisten:
```
gcloud compute network-endpoint-groups list
```
Notieren Sie sich die Namen der zonalen NEG-Back-Ends, die zu Dual-Stack konvertiert werden sollen. Diese wird später als ZONAL_NEG bezeichnet.
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-Backends konvertieren

In diesem Abschnitt erfahren Sie, wie Sie Ihre Load Balancer-Ressourcen und Backends, 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:

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

Wenn Sie das default-Netzwerk verwenden, müssen Sie es in ein VPC-Netzwerk im benutzerdefinierten Modus konvertieren.
Informationen zum Aktivieren von IPv6 finden Sie unter Stack-Typ eines Subnetzes in Dual-Stack ändern.

Der IPv6-Zugriffstyp des Subnetzes muss auf External festgelegt sein.

Hinweis: Nachdem Sie den Stacktyp eines Subnetzes auf Dual-Stack aktualisiert haben, können Sie ihn nicht mehr auf „nur IPv4“ zurücksetzen.
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.

Nur-Proxy-Subnetz aktualisieren

Wenn Sie einen Envoy-basierten Load Balancer verwenden, empfehlen wir, den Nur-Proxy-Subnetz-Stacktyp in Dual-Stack zu ändern. Informationen zu Load Balancern, die Nur-Proxy-Subnetze unterstützen, finden Sie unter Unterstützte Load Balancer.

So ändern Sie den Stacktyp des Nur-Proxy-Subnetzes in Dual-Stack:

Console

Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

Zur Seite VPC-Netzwerke
Klicken Sie auf den Namen eines Netzwerks, um die Seite VPC-Netzwerkdetails aufzurufen.
Klicken Sie auf den Tab Subnetze.
Klicken Sie im Abschnitt Reservierte Nur-Proxy-Subnetze für das Load Balancing auf den Namen des Nur-Proxy-Subnetzes, das Sie ändern möchten.
Klicken Sie auf der Seite Subnetzdetails auf Bearbeiten.
Wählen Sie für IP-Stack-Typ IPv4 und IPv6 (Dual-Stack) aus. Legen Sie als IPv6-Zugriffstyp Intern fest.
Klicken Sie auf Speichern.

gcloud

Führen Sie den Befehl subnets update aus.

gcloud compute networks subnets update PROXY_ONLY_SUBNET \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=INTERNAL \
    --region=REGION

Ersetzen Sie Folgendes:

PROXY_ONLY_SUBNET: die Region des Nur-Proxy-Subnetzes.
REGION: die Region des Subnetzes.
IPv6_ACCESS_TYPE: der IPv6-Zugriffstyp des Subnetzes ist INTERNAL.

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 Backends 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:

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:

Console

Rufen Sie in der Google Cloud Console die Seite Instanzvorlagen auf.

Zu Instanzvorlagen
1. Klicken Sie auf die Instanzvorlage, die Sie kopieren und aktualisieren möchten.
2. Klicken Sie auf Ähnliche erstellen.
3. Maximieren Sie den Bereich Erweiterte Optionen.
4. Geben Sie bei Netzwerk-Tags den Wert allow-health-check-ipv6 ein.
5. Klicken Sie im Bereich Netzwerkschnittstellen auf Netzwerkschnittstelle hinzufügen.
6. Wählen Sie in der Liste Netzwerk das VPC-Netzwerk im benutzerdefinierten Modus aus.
7. Wählen Sie in der Liste Subnetzwerk die Option SUBNET aus.
8. Wählen Sie für IP-Stack-Typ IPv4 und IPv6 (Dual-Stack) aus.
9. Klicken Sie auf Erstellen.
Grundlegendes Rolling Update starten in der verwalteten InstanzgruppeMIG mit dem Load Balancer verknüpft.

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

Console

Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

Zu Seite „VM-Instanzen“
Klicken Sie auf Instanz erstellen.
Legen Sie als Name vm-a1 fest.
Wählen Sie als Region REGION_A und dann einen beliebigen Wert für das Feld Zone aus. In diesem Verfahren wird die Zone als GCP_NEG_ZONE bezeichnet.
Achten Sie darauf, dass im Abschnitt Bootlaufwerk Debian GNU/Linux 12 (bookworm) als Bootlaufwerk-Optionen ausgewählt ist. Klicken Sie auf Auswählen, um das Image bei Bedarf zu ändern.
Maximieren Sie den Bereich Erweiterte Optionen und nehmen Sie folgende Änderungen vor:
- Maximieren Sie den Bereich Netzwerk.
- Geben in dem Feld Netzwerk allow-health-check ein.
- Nehmen Sie im Bereich Netzwerkschnittstellen folgende Änderungen vor:
  - Netzwerk: NETWORK
  - Subnetz: SUBNET
  - IP-Stack-Typ: IPv4 und IPv6 (Dual-Stack)
- Klicken Sie auf Fertig.
- Klicken Sie auf Verwaltung. Kopieren Sie den folgenden Skriptinhalt und fügen Sie ihn im Feld Startskript ein.
```
#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2
```
Klicken Sie auf Erstellen.
Wiederholen Sie die folgenden Schritte, um eine zweite VM zu erstellen. Verwenden Sie dabei die folgende Kombination aus Name und Zone:
- Name: vm-a2, Zone: GCP_NEG_ZONE

gcloud

Erstellen Sie die VMs. Führen Sie dazu den folgenden Befehl zweimal aus und verwenden Sie diese Kombinationen für den Namen der VM und ihrer Zone. Der Skriptinhalt ist für beide VMs identisch.

VM_NAME von vm-a1 und einer GCP_NEG_ZONE-Zone Ihrer Wahl

VM_NAME von vm-a2 und derselben GCP_NEG_ZONE-Zone

gcloud compute instances create VM_NAME \
    --zone=GCP_NEG_ZONE \
    --stack-type=IPV4_IPV6 \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-health-check \
    --subnet=SUBNET \
    --metadata=startup-script='#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      vm_hostname="$(curl -H "Metadata-Flavor:Google" \
      http://metadata.google.internal/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'

Fügen Sie der zonalen NEG Endpunkte hinzu

Console

Fügen Sie der zonalen NEG Endpunkte hinzu:

Rufen Sie in der Google Cloud Console die Seite Netzwerk-Endpunktgruppen auf.

Zu den Netzwerk-Endpunktgruppen
Klicken Sie in der Liste Name auf den Namen der Netzwerk-Endpunktgruppe (ZONAL_NEG). Die Seite Netzwerk-Endpunktgruppendetails wird angezeigt.
Wählen Sie im Bereich Netzwerkendpunkte in dieser Gruppe den zuvor erstellten NEG-Endpunkt aus. Klicken Sie auf Endpunkt entfernen.
Klicken Sie im Bereich Netzwerkendpunkte in dieser Gruppe auf Netzwerkendpunkt hinzufügen.
Wählen Sie die VM-Instanz aus.
Im Abschnitt Netzwerkschnittstelle werden der Name, die Zone und das Subnetz der VM angezeigt.
Geben Sie im Feld IPv4-Adresse die IPv4-Adresse des neuen Netzwerkendpunkts ein.
Geben Sie im Feld IPv6-Adresse die IPv6-Adresse des neuen Netzwerkendpunkts ein.
Hinweis: Ein Backend-Dienst mit mehreren Endpunkten muss eindeutige IPv6-Adressen haben. Die Endpunkte können sich in verschiedenen Subnetzen befinden, aber dieselbe IPv6-Adresse kann nicht für mehrere Endpunkte verwendet werden.
Wählen Sie den Porttyp aus.
1. Wenn Sie Standard auswählen, wird für den Endpunkt der Standardport 80 für alle Endpunkte in der Netzwerk-Endpunktgruppe verwendet. Dies ist für unser Beispiel ausreichend, da der Apache-Server Anfragen an Port 80 verarbeitet.
2. Wenn Sie Benutzerdefiniert auswählen, geben Sie die Portnummer für den zu verwendenden Endpunkt ein.
Klicken Sie zum Hinzufügen weiterer Endpunkte auf Netzwerkendpunkt hinzufügen und wiederholen Sie die vorherigen Schritte.
Nachdem Sie alle Endpunkte hinzugefügt haben, klicken Sie auf Erstellen.

gcloud

Fügen Sie Endpunkte (GCE_VM_IP_PORT-Endpunkte) zu ZONAL_NEG hinzu.
Hinweis: Ein Backend-Dienst mit mehreren Endpunkten muss eindeutige IPv6-Adressen haben. Die Endpunkte können sich in verschiedenen Subnetzen befinden, aber dieselbe IPv6-Adresse kann nicht für mehrere Endpunkte verwendet werden.
```
gcloud compute network-endpoint-groups update ZONAL_NEG \
    --zone=GCP_NEG_ZONE \
    --add-endpoint='instance=vm-a1,ip=IPv4_ADDRESS, \
      ipv6=IPv6_ADDRESS,port=80' \
    --add-endpoint='instance=vm-a2,ip=IPv4_ADDRESS, \
      ipv6=IPv6_ADDRESS,port=80'
```

Ersetzen Sie Folgendes:

IPv4_ADDRESS: IPv4-Adresse des Netzwerkendpunkts Die IPv4-Adresse muss zu einer VM in Compute Engine gehören (entweder die primäre IP-Adresse oder als Teil eines Alias-IP-Bereichs). Wenn die IP-Adresse nicht angegeben ist, wird die primäre IP-Adresse für die VM-Instanz in dem Netzwerk verwendet, zu dem die Netzwerk-Endpunktgruppe gehört.

IPv6_ADDRESS: IPv6-Adresse des Netzwerkendpunkts. Die IPv6-Adresse muss zu einer VM-Instanz in dem Netzwerk gehören, zu dem die Netzwerk-Endpunktgruppe gehört (externe IPv6-Adresse).

Firewallregel für IPv6-Systemdiagnoseprüfungen erstellen

Sie müssen eine Firewallregel erstellen, um Systemdiagnosen aus den IP-Bereichen von Google Cloud-Prüfsystemen zuzulassen. Weitere Informationen finden Sie unter IP-Bereiche von Prüfsystemen.

Die Ingress-Regel muss für die Instanzen mit Load Balancing gelten und Traffic von den Systemdiagnosen von Google Cloud zulassen. In diesem Beispiel wird das Ziel-Tag allow-health-check-ipv6 verwendet, um die VM-Instanzen zu identifizieren, auf die sie angewendet werden soll.

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

Console

Rufen Sie in der Google Cloud Console die Seite der Firewall-Richtlinien auf.

Zu den Firewall-Richtlinien
Klicken Sie noch einmal auf Firewallregel erstellen und geben Sie die folgenden Informationen ein, um IPv6-Subnetz-Traffic zuzulassen:
- Name: fw-allow-lb-access-ipv6
- Netzwerk: NETWORK
- Priorität: 1000
- Trafficrichtung: Eingehend
- Ziele: Specified target tags
- Zieltags: allow-health-check-ipv6
- Quellfilter: IPv6-Bereiche
- Quell-IPv6-Bereiche
  - Geben Sie für einen globalen externen Application Load Balancer und einen globalen externen Proxy-Network Load Balancer 2600:2d00:1:b029::/64,2600:2d00:1:1::/64 ein
  - Geben Sie für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer, regionale interne Application Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer, regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer 2600:2d00:1:b029::/64 ein.
- Protokolle und Ports: Alle zulassen
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie die Firewallregel fw-allow-lb-access-ipv6, um die Kommunikation mit dem Subnetz zuzulassen:

Verwenden Sie für globale externe Application Load Balancer und globale externe Proxy-Network Load Balancer den folgenden Befehl:
```
gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64,2600:2d00:1:1::/64 \
    --rules=all
```
Verwenden Sie für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer, regionale interne Application Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer, regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer den folgenden Befehl:
```
gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64 \
    --rules=all
```

Firewallregel für das Nur-Proxy-Subnetz erstellen

Wenn Sie einen regionalen externen Application Load Balancer oder einen internen Application Load Balancer verwenden, müssen Sie die Firewallregel für eingehenden Traffic fw-allow-lb-access-ipv6 aktualisieren, um Traffic vom Nur-Proxy-Subnetz zu den Backends zuzulassen.

Führen Sie den folgenden Befehl aus, um den IPv6-Adressbereich des Nur-Proxy-Subnetzes abzurufen:

gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
    --region=REGION \
    --format="value(internalIpv6Prefix)"

Notieren Sie sich den internen IPv6-Adressbereich. Dieser Bereich wird später als IPV6_PROXY_ONLY_SUBNET_RANGE bezeichnet.

So aktualisieren Sie die Firewallregel fw-allow-lb-access-ipv6 für das Nur-Proxy-Subnetz:

Console

Rufen Sie in der Google Cloud Console die Seite der Firewall-Richtlinien auf.

Zu den Firewall-Richtlinien
Klicken Sie im Bereich VPC-Firewallregeln auf fw-allow-lb-access-ipv6.
- Quell-IPv6-Bereiche: 2600:2d00:1:b029::/64,IPV6_PROXY_ONLY_SUBNET_RANGE
Klicken Sie auf Speichern.

gcloud

Aktualisieren Sie die Firewallregel fw-allow-lb-access-ipv6, um die Kommunikation mit dem Nur-Proxy-Subnetz zuzulassen:

gcloud compute firewall-rules update fw-allow-lb-access-ipv6 \
    --source-ranges=2600:2d00:1:b029::/64,IPV6_PROXY_ONLY_SUBNET_RANGE

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. Die IPv6-Weiterleitungsregel kann nur für globale externe Application Load Balancer erstellt werden. IPv6-Weiterleitungsregeln werden für regionenübergreifende interne Application Load Balancer, regionale externe Application Load Balancer und regionale interne Application Load Balancer nicht unterstützt.

An diesem Punkt im Prozess können sowohl BACKEND_SERVICE als auch BACKEND_SERVICE_IPV6 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.

Console

Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

Load-Balancing aufrufen
Klicken Sie auf den Namen des Load-Balancers.
Klicken Sie auf Bearbeiten.

Backend-Dienst konfigurieren

Klicken Sie auf Backend-Konfiguration.
Wählen Sie im Feld Backend-Dienst die Option Backend-Dienst erstellen aus.
Legen Sie als Name BACKEND_SERVICE_IPV6 fest.
Wählen Sie als Backend-Typ die Option Internetnetzwerk-Endpunktgruppe aus.
Wählen Sie in der Liste Richtlinie zur IP-Adressauswahl die Option IPv6 bevorzugen aus.
Wählen Sie im Feld Protokoll die Option HTTP aus.
Führen Sie im Bereich Neues Backend folgende Schritte aus:
1. Wählen Sie in der Liste Netzwerk-Endpunktgruppe ZONAL_NEG aus.
2. Geben Sie für Maximale Anzahl der Anfragen pro Sekunde den Wert 10 ein.
Wählen Sie in der Liste Systemdiagnose eine HTTP-Systemdiagnose aus.
Klicken Sie auf Fertig.

Konfigurieren Sie das IPv6-Frontend:

Weiterleitungsregeln mit IPv6 werden nicht für regionsübergreifende interne Application Load Balancer, regionale externe Application Load Balancer und regionale interne Application Load Balancer unterstützt.

Klicken Sie auf Frontend-Konfiguration.
Klicken Sie auf Front-End-IP und Port hinzufügen.
Geben Sie im Feld Name einen Namen für die Weiterleitungsregel ein.
Wählen Sie im Feld Protokoll die Option HTTP aus.
Legen Sie IPv6 als IP-Version fest.
Klicken Sie auf Fertig.
Klicken Sie auf Aktualisieren.

Routingregeln konfigurieren

Klicken Sie auf Routingregeln.
Klicken Sie auf Erweiterte Host- und Pfadregel.
Klicken Sie auf Aktualisieren.

gcloud

Erstellen Sie eine Systemdiagnose.

 gcloud compute health-checks create http HEALTH_CHECK \
     --port 80

Erstellen Sie den Back-End-Dienst für HTTP-Traffic:

global

Verwenden Sie für den globalen externen Application Load Balancer den Befehl:

gcloud compute backend-services create BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=PREFER_IPV6 \
    --health-checks=HEALTH_CHECK \
    --global

Regionenübergreifend

Verwenden Sie für den regionenübergreifenden internen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services create BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=PREFER_IPV6 \
    --health-checks=HEALTH_CHECK \
    --global

regional

Verwenden Sie für den regionalen externen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services create BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=PREFER_IPV6 \
    --health-checks=HEALTH_CHECK \
    --region=REGION

Verwenden Sie für den regionalen internen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services create BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=PREFER_IPV6 \
    --health-checks=HEALTH_CHECK \
    --region=REGION

Fügen Sie dem Backend-Dienst die zonalen NEGs mit Dual-Stack als Backend hinzu.

global

Verwenden Sie für den globalen externen Application Load Balancer den Befehl:

 gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \
     --network-endpoint-group=ZONAL_NEG \
     --network-endpoint-group-zone=ZONE \
     --max-rate-per-endpoint=10 \
     --global

Regionenübergreifend

Verwenden Sie für den regionenübergreifenden internen Application Load Balancer den folgenden Befehl:

 gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \
     --network-endpoint-group=ZONAL_NEG \
     --network-endpoint-group-zone=ZONE \
     --max-rate-per-endpoint=10 \
     --global

regional

Verwenden Sie für den regionalen externen und internen Application Load Balancer den folgenden Befehl:

 gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \
     --network-endpoint-group=ZONAL_NEG \
     --network-endpoint-group-zone=ZONE \
     --max-rate-per-endpoint=10 \
     --region=REGION

Fügen Sie dem Backend-Dienst die Dual-Stack-Instanzgruppen als Backend hinzu.
global

Verwenden Sie für den globalen externen Application Load Balancer den Befehl:
gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \ --instance-group=INSTANCE_GROUP \ --global
Regionenübergreifend

Verwenden Sie für den regionenübergreifenden internen Application Load Balancer den folgenden Befehl:
gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \ --instance-group=INSTANCE_GROUP \ --global
regional

Verwenden Sie für den regionalen externen und den regionalen internen Application Load Balancer den folgenden Befehl:
gcloud compute backend-services add-backend BACKEND_SERVICE_IPV6 \ --instance-group=INSTANCE_GROUP \ --region=REGION

Nur für globale externe Application Load Balancer. Erstellen Sie die IPv6-Weiterleitungsregel für den globalen externen Application Load Balancer. Führen Sie den Befehl aus:

 gcloud compute forwarding-rules create FORWARDING_RULE_IPV6 \
     --load-balancing-scheme=EXTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --global \
     --target-http-proxy=TARGET_PROXY \
     --ports=443

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.

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

Verwenden Sie für den globalen externen Application Load Balancer den Befehl:
gcloud compute url-maps edit URL_MAP \ --global
Regionenübergreifend

Verwenden Sie für den regionenübergreifenden internen Application Load Balancer den folgenden Befehl:
gcloud compute url-maps edit URL_MAP \ --global
regional

Verwenden Sie für den regionalen externen und internen Application Load Balancer den folgenden Befehl:
gcloud compute url-maps edit URL_MAP \ --region=REGION

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

Nachdem Sie Ihre Ressourcen und Backends zu Dual-Stack konvertiert haben, können Sie mit der Richtlinie zur IP-Adressauswahl den Traffictyp angeben, der vom Backend-Dienst an Ihre Backends 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.

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 nur IPv4-Back-Ends haben und `Only IPv6` als Richtlinie zur IP-Adressauswahl auswählen, führt die Konfiguration zu fehlerhaften Back-Ends, da der Traffic diese Back-Ends nicht erreicht und der HTTP-Antwortcode `503` an die Clients zurückgegeben wird.

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 nur IPv4-Back-Ends haben und Only IPv6 als Richtlinie zur IP-Adressauswahl auswählen, führt die Konfiguration zu fehlerhaften Back-Ends, da der Traffic diese Back-Ends nicht erreicht und der HTTP-Antwortcode 503 an die Clients zurückgegeben wird.

Console

Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

Load-Balancing aufrufen
Klicken Sie auf den Namen des Load-Balancers.
Klicken Sie auf Bearbeiten.
Klicken Sie auf Backend-Konfiguration.
Wählen Sie im Feld Backend-Dienst die Option BACKEND_SERVICE_IPV6 aus.
Der Backend-Typ muss Zonale Netzwerk-Endpunktgruppe oder Instanzgruppe sein.
Wählen Sie in der Liste Richtlinie zur IP-Adressauswahl die Option IP_ADDRESS_SELECTION_POLICY aus.
Klicken Sie auf Fertig.

gcloud

Aktualisieren Sie die Richtlinie zur IP-Adressauswahl für den Backend-Dienst:

global

Verwenden Sie für den globalen externen Application Load Balancer den Befehl:

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --global

Regionenübergreifend

Verwenden Sie für den regionenübergreifenden internen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --global

regional

Verwenden Sie für den regionalen externen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --region=REGION

Verwenden Sie für den regionalen internen Application Load Balancer den folgenden Befehl:

gcloud compute backend-services update BACKEND_SERVICE_IPV6 \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --ip-address-selection-policy=IP_ADDRESS_SELECTION_POLICY \
    --region=REGION

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 Backends 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.

IP-Adressen des Load Balancers ermitteln

Console

Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

Load-Balancing aufrufen
Klicken Sie auf den Namen des Load-Balancers.
Im Abschnitt Frontend werden zwei Load Balancer-IP-Adressen angezeigt. In diesem Verfahren wird die IPv4-Adresse als IP_ADDRESS_IPV4 und die IPv6-Adresse als IP_ADDRESS_IPV6 bezeichnet.
Wenn die Richtlinie zur IP-Adressauswahl im Bereich Backends den Wert Prefer IPv6 hat, werden zwei Systemdiagnosestatus für die Backends angezeigt.
Hinweis: Ein Backend-Dienst mit mehreren Endpunkten muss eindeutige IPv6-Adressen haben. Die Endpunkte können sich in verschiedenen Subnetzen befinden, aber dieselbe IPv6-Adresse kann nicht für mehrere Endpunkte verwendet werden.

Traffic an den Load-Balancer senden

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

Für externe Load Balancer

Wiederholen Sie den folgenden Befehl einige Male, bis alle Backend-VMs antworten.
```
curl -m1 IP_ADDRESS_IPV4:PORT
```
```
curl -m1 IP_ADDRESS_IPV6:PORT
```
Wenn die IPv6-Adresse beispielsweise [fd20:1db0:b882:802:0:46:0:0]:80 lautet, sieht der Befehl in etwa so aus:
```
curl -m1 [fd20:1db0:b882:802:0:46:0:0]:80
```

Für interne Load Balancer

Erstellen Sie eine Test-Client-VM im selben VPC-Netzwerk und in derselben Region wie der Load Balancer. Sie muss sich nicht im selben Subnetz oder in derselben Zone befinden.
```
gcloud compute instances create client-vm \
    --zone=ZONE \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=SUBNET
```
Verwenden Sie SSH, um eine Verbindung zur Clientinstanz herzustellen.
```
gcloud compute ssh client-vm \
    --zone=ZONE
```
Wiederholen Sie den folgenden Befehl einige Male, bis alle Backend-VMs antworten.
```
curl -m1 IP_ADDRESS_IPV4:PORT
```
```
curl -m1 IP_ADDRESS_IPV6:PORT
```
Wenn die IPv6-Adresse beispielsweise [fd20:1db0:b882:802:0:46:0:0]:80 lautet, sieht der Befehl in etwa so aus:
```
curl -m1 [fd20:1db0:b882:802:0:46:0:0]:80
```

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.