Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Regionenübergreifenden internen Proxy-Network Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten

Dieses Dokument enthält Anleitungen zum Konfigurieren eines regionenübergreifenden internen Proxy-Network Load Balancers mit Compute Engine-VM-Instanzgruppen-Back-Ends.

Bevor Sie diese Anleitung durcharbeiten, sollten Sie sich mit der Übersicht über interne Proxy-Network-Load-Balancer vertraut machen.

In diesem Beispiel konfigurieren Sie die im folgenden Diagramm dargestellte Bereitstellung.

Dadurch wird ein regionenübergreifender interner Proxy-Network Load Balancer in einem VPC-Netzwerk mit einem Backend-Dienst und zwei verwalteten Back-End-Instanzgruppen in den Regionen REGION_A und REGION_B erstellt.

Für regionsübergreifende interne Proxy-Network Load Balancer sind die folgenden Ressourcen erforderlich:

Ein VPC-Netzwerk mit den folgenden Subnetzen:
- Subnetz SUBNET_A und ein Nur-Proxy-Subnetz in REGION_A.
- Subnetz SUBNET_B und ein Nur-Proxy-Subnetz in REGION_B.
Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie regionenübergreifende interne Proxy-Network Load Balancer verwenden, Nur-Proxy-Subnetze erstellen. Das Nur-Proxy-Subnetz der Region wird von allen regionenübergreifenden internen Proxy-Network Load Balancern in der Region gemeinsam genutzt. Quelladressen von Paketen, die der Load-Balancer an die Back-Ends Ihres Dienstes sendet, werden vom Nur-Proxy-Subnetz zugewiesen. In diesem Beispiel hat das Nur-Proxy-Subnetz für die Region REGION_B den primären IP-Adressbereich 10.129.0.0/23 und für REGION_A den primären IP-Adressbereich 10.130.0.0/23. Dies ist die empfohlene Subnetzgröße.
Bei der Einrichtung für Hochverfügbarkeit werden verwaltete Instanzgruppen-Back-Ends für Compute Engine-VM-Bereitstellungen in den Regionen REGION_A und REGION_B verwendet. Wenn Back-Ends in einer Region ausfallen, wird der Traffic auf die andere Region umgeleitet.
Ein globaler Backend-Dienst, der die Nutzung und die Integrität von Backends überwacht.
Ein globaler TCP-Zielproxy, der eine Anfrage vom Nutzer empfängt und an den Backend-Dienst weiterleitet.
Globale Weiterleitungsregeln mit der regionalen internen IP-Adresse Ihres Load-Balancers, die jede eingehende Anfrage an den Zielproxy weiterleiten können.

Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus einem Subnetz im selben Netzwerk und in derselben Region wie die Back-Ends stammen. Beachten Sie folgende Bedingungen:
- Die IP-Adresse kann (nicht erforderlich) aus demselben Subnetz wie die Backend-Instanzgruppen stammen.
- Die IP-Adresse darf nicht aus dem reservierten Nur-Proxy-Subnetz stammen, dessen Flag --purpose auf GLOBAL_MANAGED_PROXY gesetzt ist. Wenn Sie das Nur-Proxy-Subnetz verwenden, schlägt das Erstellen der Weiterleitungsregel fehl.
- Wenn Sie dieselbe interne IP-Adresse mit mehreren Weiterleitungsregeln verwenden möchten, setzen Sie das Flag --purpose für die IP-Adresse auf SHARED_LOADBALANCER_VIP.

Berechtigungen

Damit Sie dieser Anleitung folgen können, müssen Sie in der Lage sein, Instanzen zu erstellen und ein Netzwerk in einem Projekt zu ändern. Sie müssen entweder Inhaber oder Bearbeiter des Projekts sein oder alle folgenden Compute Engine-IAM-Rollen haben.

Aufgabe	Erforderliche Rolle
Netzwerke, Subnetze und Load-Balancer-Komponenten erstellen	Compute-Netzwerkadministrator
Firewallregeln hinzufügen und löschen	Compute-Sicherheitsadministrator
Instanzen erstellen	Compute Instance Admin

Weitere Informationen finden Sie in folgenden Leitfäden:

Netzwerk und Subnetze konfigurieren

Konfigurieren Sie im VPC-Netzwerk ein Subnetz in jeder Region, in der Ihre Back-Ends konfiguriert sind. Konfigurieren Sie außerdem in jeder Region, in der Sie den Load-Balancer konfigurieren möchten, ein proxy-only-subnet.

In diesem Beispiel werden das folgende VPC-Netzwerk, die folgende Region und die folgenden Subnetze verwendet:

Netzwerk. Das Netzwerk ist ein VPC-Netzwerk im benutzerdefinierten Modus mit dem Namen NETWORK.
Subnetze für Backends
- Ein Subnetz mit dem Namen SUBNET_A in der Region REGION_A verwendet 10.1.2.0/24 für seinen primären IP-Bereich.
- Ein Subnetz mit dem Namen SUBNET_B in der Region REGION_B verwendet 10.1.3.0/24 für seinen primären IP-Bereich.
Subnetze für Proxys.
- Ein Subnetz mit dem Namen PROXY_SN_A in der Region REGION_A verwendet 10.129.0.0/23 für seinen primären IP-Bereich.
- Ein Subnetz mit dem Namen PROXY_SN_B in der Region REGION_B verwendet 10.130.0.0/23 für seinen primären IP-Bereich.

Auf regionenübergreifende Load Balancer kann von jeder Region innerhalb der VPC aus zugegriffen werden. Daher können Clients aus jeder Region global auf Ihre Load-Balancer-Back-Ends zugreifen.

Backend-Subnetze konfigurieren

Console

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

Zur Seite VPC-Netzwerke
Klicken Sie auf VPC-Netzwerk erstellen.
Geben Sie einen Namen für das Netzwerk an.
Wählen Sie im Abschnitt Subnetze als Modus für die Subnetzerstellung Benutzerdefiniert aus.
Erstellen Sie ein Subnetz für die Back-Ends des Load-Balancers. Geben Sie im Bereich Neues Subnetz folgende Informationen ein:
- Geben Sie einen Namen für das Subnetz an.
- Wählen Sie eine Region aus: REGION_A
- Geben Sie einen IP-Adressbereich ein: 10.1.2.0/24
Klicken Sie auf Fertig.
Klicken Sie auf Subnetz hinzufügen.
Erstellen Sie ein Subnetz für die Back-Ends des Load-Balancers. Geben Sie im Bereich Neues Subnetz folgende Informationen ein:
- Geben Sie einen Namen für das Subnetz an.
- Wählen Sie eine Region aus: REGION_B
- Geben Sie einen IP-Adressbereich ein: 10.1.3.0/24
Klicken Sie auf Fertig.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie mit dem Befehl gcloud compute networks create das benutzerdefinierte VPC-Netzwerk:
```
gcloud compute networks create NETWORK \
    --subnet-mode=custom
```

Erstellen Sie mit dem Befehl gcloud compute networks subnets create ein Subnetz im Netzwerk NETWORK in der Region REGION_A:

gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

Erstellen Sie mit dem Befehl gcloud compute networks subnets create ein Subnetz im Netzwerk NETWORK in der Region REGION_B:

gcloud compute networks subnets create SUBNET_B \
    --network=NETWORK \
    --range=10.1.3.0/24 \
    --region=REGION_B

Terraform

Verwenden Sie zum Erstellen des VPC-Netzwerks die Ressource google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Verwenden Sie zum Erstellen des VPC-Subnetzes im Netzwerk lb-network-crs-reg die Ressource google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}

resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Stellen Sie eine POST-Anfrage an die Methode networks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Nur-Proxy-Subnetz konfigurieren

Ein Nur-Proxy-Subnetz stellt eine Reihe von IP-Adressen bereit, die Google Cloud zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Die Proxys beenden Verbindungen vom Client und erstellen neue Verbindungen zu den Back-Ends.

Dieses Nur-Proxy-Subnetz wird von allen Envoy-basierten regionalen Load-Balancern in derselben Region des VPC-Netzwerks verwendet. Pro Zweck, Region und Netzwerk kann jeweils nur ein Nur-Proxy-Subnetz aktiv sein.

Console

Wenn Sie die Google Cloud Console verwenden, können Sie das Nur-Proxy-Subnetz später auf der Seite Load-Balancing erstellen.

Führen Sie die folgenden Schritte aus, wenn Sie jetzt das Nur-Proxy-Subnetz erstellen möchten:

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

Zur Seite VPC-Netzwerke
Klicken Sie auf den Namen des VPC-Netzwerks.
Klicken Sie auf dem Tab Subnetz auf Subnetz hinzufügen.
Geben Sie einen Namen für das Nur-Proxy-Subnetz an.
Wählen Sie eine Region aus: REGION_A
Wählen Sie in der Liste Zweck die Option Regionenübergreifender verwalteter Proxy aus.
Geben Sie im Feld IP-Adressbereich den Wert 10.129.0.0/23 ein.
Klicken Sie auf Hinzufügen.

Erstellen Sie das Nur-Proxy-Subnetz in REGION_B.

Klicken Sie auf dem Tab Subnetz auf Subnetz hinzufügen.
Geben Sie einen Namen für das Nur-Proxy-Subnetz an.
Wählen Sie eine Region aus: REGION_B
Wählen Sie in der Liste Zweck die Option Regionenübergreifender verwalteter Proxy aus.
Geben Sie im Feld IP-Adressbereich den Wert 10.130.0.0/23 ein.
Klicken Sie auf Hinzufügen.

gcloud

Erstellen Sie das Nur-Proxy-Subnetz mit dem Befehl gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23

    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

Terraform

Verwenden Sie die Ressource google_compute_subnetwork, um das VPC-Nur-Proxy-Subnetz im Netzwerk lb-network-crs-reg zu erstellen.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Erstellen Sie das Nur-Proxy-Subnetz mit der Methode subnetworks.insert und ersetzen Sie PROJECT_ID dabei durch Ihre Projekt-ID.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Firewallregeln konfigurieren

In diesem Beispiel werden die folgenden Firewallregeln verwendet:

fw-ilb-to-backends: Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und eingehende SSH-Verbindungen über TCP-Port 22 von jeder Adresse aus ermöglicht. Sie können einen restriktiveren IP-Quelladressbereich für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Adressbereiche des Systems an, von dem aus Sie SSH-Sitzungen initiieren. In diesem Beispiel wird das Ziel-Tag allow-ssh verwendet, um die VMs zu identifizieren, auf die die Firewallregel angewendet wird.
fw-healthcheck. Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und Traffic von den Systemen für Systemdiagnosen von Google Cloudzulässt (130.211.0.0/22 und 35.191.0.0/16). In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet, um die VMs zu identifizieren, auf die die Firewallregel angewendet wird.
fw-backends. Eine Regel für eingehenden Traffic, die für die Instanzen gilt, für die ein Load Balancing durchgeführt wird, und die TCP-Traffic auf den Ports 80, 443 und 8080 von den verwalteten Proxys des internen Proxy-Network Load Balancers zulässt. In diesem Beispiel wird das Ziel-Tag load-balanced-backend verwendet, um die VMs zu identifizieren, auf die die Firewallregel angewendet wird.

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

Die Back-End-Instanzen werden von den Ziel-Tags definiert. Ohne die Ziel-Tags gelten die Firewallregeln für alle Ihre Backend-Instanzen im VPC-Netzwerk. Achten Sie beim Erstellen der Back-End-VMs darauf, die angegebenen Ziel-Tags wie in Verwaltete Instanzgruppe erstellen beschrieben zu verwenden.

Console

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

Zu den Firewall-Richtlinien
Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen zulässt:
- Name: fw-ilb-to-backends
- Netzwerk: NETWORK
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: allow-ssh
- Quellfilter: IPv4-Bereiche.
- IPv4-Quellbereiche: 0.0.0.0/0
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen TCP an und geben Sie 22 als Portnummer ein.
Klicken Sie auf Erstellen.
Klicken Sie ein zweites Mal auf Firewallregel erstellen, um die Regel zum Zulassen vonGoogle Cloud -Systemdiagnosen zu erstellen:
- Name: fw-healthcheck
- Netzwerk: NETWORK
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: load-balanced-backend
- Quellfilter: IPv4-Bereiche.
- IPv4-Quellbereiche: 130.211.0.0/22 und 35.191.0.0/16
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen TCP an und geben Sie 80 als Portnummer ein.
  Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit den von Ihren Systemdiagnosen verwendeten übereinstimmen. Wenn Sie tcp:80 für das Protokoll und den Port verwenden,kann Google Cloud mit HTTP auf Port 80 Ihre VMs kontaktieren. Es kann jedoch nicht HTTPS auf Port 443 verwenden, um den Kontakt herzustellen.
Klicken Sie auf Erstellen.
Klicken Sie ein drittes Mal auf Firewallregel erstellen, um die Regel zu erstellen, die Verbindungen von den Proxyservern des Load-Balancers zu den Back-Ends zulässt:
- Name: fw-backends
- Netzwerk: NETWORK
- Trafficrichtung: Eingehend
- Aktion bei Übereinstimmung: Zulassen
- Ziele: Angegebene Ziel-Tags
- Zieltags: load-balanced-backend
- Quellfilter: IPv4-Bereiche.
- IPv4-Quellbereiche: 10.129.0.0/23 und 10.130.0.0/23
- Protokolle und Ports:
  - Wählen Sie Angegebene Protokolle und Ports aus.
  - Klicken Sie das Kästchen TCP an und geben Sie 80, 443, 8080 als Portnummer ein.
Klicken Sie auf Erstellen.

gcloud

Erstellen Sie die Firewallregel fw-ilb-to-backends, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen. Wenn Sie source-ranges weglassen,Google Cloud bezieht die Regel auf jede Quelle.
```
gcloud compute firewall-rules create fw-ilb-to-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Erstellen Sie die Regel fw-healthcheck, um Google Cloud-Systemdiagnosen zuzulassen. In diesem Beispiel wird der gesamte TCP-Traffic von Systemdiagnosetests zugelassen. Sie können jedoch Ihren Anforderungen entsprechend eine kleinere Gruppe von Ports konfigurieren:
```
gcloud compute firewall-rules create fw-healthcheck \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
```
Erstellen Sie die Regel fw-backends, um Verbindungen von den Proxys des internen Proxy-Network Load Balancers zu Ihren Back-Ends zuzulassen. Legen Sie für source-ranges die zugewiesenen Bereiche des Nur-Proxy-Subnetzes fest, z. B. 10.129.0.0/23 und 10.130.0.0/23.
```
gcloud compute firewall-rules create fw-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=SOURCE_RANGE \
    --target-tags=load-balanced-backend \
    --rules=tcp:80,tcp:443,tcp:8080
```

API

Erstellen Sie die Firewallregel fw-ilb-to-backends durch Senden einer POST-Anfrage an die Methode firewalls.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Erstellen Sie die Firewallregel fw-healthcheck durch Senden einer POST-Anfrage an die Methode firewalls.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Erstellen Sie die Firewallregel fw-backends, um TCP-Traffic im Proxy-Subnetz für die Methode firewalls.insert zuzulassen. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Erstellen Sie eine verwaltete Instanzgruppe.

In diesem Abschnitt wird gezeigt, wie Sie eine Vorlage und eine verwaltete Instanzgruppe erstellen. Die verwaltete Instanzgruppe stellt VM-Instanzen bereit, auf denen die Backend-Server eines beispielhaften regionenübergeifenden internen Proxy-Network Load Balancer ausgeführt werden. Für Ihre Instanzgruppe können Sie einen HTTP-Dienst definieren und dem entsprechenden Port einen Portnamen zuordnen. Der Backend-Dienst des Load-Balancers leitet den Traffic an den benannten Port weiter. Der Traffic von Clients wird auf Backend-Server verteilt. Zur Veranschaulichung stellen Back-Ends ihre eigenen Hostnamen bereit.

Console

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

Instanzvorlagen aufrufen
1. Klicken Sie auf Instanzvorlage erstellen.
2. Geben Sie für Name gil4-backendeast1-template ein.
3. Das Bootlaufwerk sollte auf ein Debian-Image wie Debian GNU/Linux 12 (bookworm) eingestellt sein. Diese Anleitungen verwenden Befehle, die nur für Debian verfügbar sind, z. B. apt-get.
4. Klicken Sie auf Erweiterte Optionen.
5. Klicken Sie auf Netzwerk und konfigurieren Sie die folgenden Felder:
  1. Geben Sie für Netzwerk-Tags allow-ssh und load-balanced-backend ein.
  2. Wählen Sie für Netzwerkschnittstellen Folgendes aus:
    - Netzwerk: NETWORK
    - Subnetz: SUBNET_B
6. Klicken Sie auf Verwaltung. Fügen Sie im Feld Startskript das nachfolgende Skript ein.
```
#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2
```
7. Klicken Sie auf Erstellen.
8. Klicken Sie auf Instanzvorlage erstellen.
9. Geben Sie für Name gil4-backendwest1-template ein.
10. Das Bootlaufwerk sollte auf ein Debian-Image wie Debian GNU/Linux 12 (bookworm) eingestellt sein. Diese Anleitungen verwenden Befehle, die nur für Debian verfügbar sind, z. B. apt-get.
11. Klicken Sie auf Erweiterte Optionen.
12. Klicken Sie auf Netzwerk und konfigurieren Sie die folgenden Felder:
  1. Geben Sie für Netzwerk-Tags allow-ssh und load-balanced-backend ein.
  2. Wählen Sie für Netzwerkschnittstellen Folgendes aus:
    - Netzwerk: NETWORK
    - Subnetz: SUBNET_A
13. Klicken Sie auf Verwaltung. Fügen Sie im Feld Startskript das nachfolgende Skript ein.
```
#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2
```
14. Klicken Sie auf Erstellen.
Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

Zu den Instanzgruppen
1. Klicken Sie auf Instanzgruppe erstellen.
2. Wählen Sie Neue verwaltete Instanzgruppe (zustandslos) aus. Weitere Informationen finden Sie unter Zustandslose oder zustandsorientierte MIGs.
3. Geben Sie für Name gl4-ilb-miga ein.
4. Wählen Sie für Standort die Option Einzelne Zone aus.
5. Wählen Sie bei Region die Option REGION_A aus.
6. Wählen Sie bei Zone die Option ZONE_A aus.
7. Wählen Sie bei Instanzvorlage die Option gil4-backendwest1-template aus.
8. Geben Sie an, wie viele Instanzen die Gruppe umfassen soll.
  
  Geben Sie für dieses Beispiel unter Autoscaling die folgenden Optionen an:
  - Wählen Sie für Autoscaling-Modus Off:do not autoscale aus.
  - Geben Sie für Maximale Anzahl von Instanzen den Wert 2 ein.
  Optional können Sie im Abschnitt Autoscaling der Benutzeroberfläche die Instanzgruppe so konfigurieren, dass Instanzen basierend auf der CPU-Auslastung automatisch hinzugefügt oder entfernt werden.
9. Klicken Sie auf Erstellen.
10. Klicken Sie auf Instanzgruppe erstellen.
11. Wählen Sie Neue verwaltete Instanzgruppe (zustandslos) aus. Weitere Informationen finden Sie unter Zustandslose oder zustandsorientierte MIGs.
12. Geben Sie für Name gl4-ilb-migb ein.
13. Wählen Sie für Standort die Option Einzelne Zone aus.
14. Wählen Sie bei Region die Option REGION_B aus.
15. Wählen Sie bei Zone die Option ZONE_B aus.
16. Wählen Sie bei Instanzvorlage die Option gil4-backendeast1-template aus.
17. Geben Sie an, wie viele Instanzen die Gruppe umfassen soll.
  
  Geben Sie für dieses Beispiel unter Autoscaling die folgenden Optionen an:
  - Wählen Sie für Autoscaling-Modus Off:do not autoscale aus.
  - Geben Sie für Maximale Anzahl von Instanzen den Wert 2 ein.
  Optional können Sie im Abschnitt Autoscaling der Benutzeroberfläche die Instanzgruppe so konfigurieren, dass Instanzen basierend auf der CPU-Auslastung automatisch hinzugefügt oder entfernt werden.
18. Klicken Sie auf Erstellen.

gcloud

Bei den gcloud CLI-Anleitungen in diesem Handbuch wird davon ausgegangen, dass Sie Cloud Shell oder eine andere Umgebung verwenden, in der Bash installiert ist.

Erstellen Sie mit dem Befehl gcloud compute instance-templates create eine VM-Instanzvorlage mit HTTP-Server.

gcloud compute instance-templates create gil4-backendwest1-template \
   --region=REGION_A \
   --network=NETWORK \
   --subnet=SUBNET_A \
   --tags=allow-ssh,load-balanced-backend \
   --image-family=debian-12 \
   --image-project=debian-cloud \
   --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://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

gcloud compute instance-templates create gil4-backendeast1-template \
    --region=REGION_B \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --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://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2'

Erstellen Sie mit dem Befehl gcloud compute instance-groups managed create eine verwaltete Instanzgruppe in der Zone.

gcloud compute instance-groups managed create gl4-ilb-miga \
    --zone=ZONE_A \
    --size=2 \
    --template=gil4-backendwest1-template

gcloud compute instance-groups managed create gl4-ilb-migb \
    --zone=ZONE_B \
    --size=2 \
    --template=gil4-backendeast1-template

API

Erstellen Sie mit der Methode instanceTemplates.insert die Instanzvorlage. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil4-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Erstellen Sie mit der Methode instanceGroupManagers.insert in jeder Zone eine verwaltete Instanzgruppe. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

Load-Balancer konfigurieren

In diesem Abschnitt werden die folgenden Ressourcen für den regionenübergreifenden internen Proxy-Network Load Balancer erstellt:

Eine globale TCP-Systemdiagnose.
Ein globaler Backend-Dienst mit denselben MIGs wie das Backend.
Ein globaler Ziel-Proxy.
Zwei globale Weiterleitungsregeln mit regionalen IP-Adressen. Verwenden Sie für die IP-Adresse der Weiterleitungsregel den IP-Adressbereich SUBNET_A oder SUBNET_B. Wenn Sie das Nur-Proxy-Subnetz verwenden, schlägt das Erstellen der Weiterleitungsregel fehl.

Proxyverfügbarkeit

Manchmal haben Google Cloud Regionen nicht genügend Proxykapazität für einen neuen Load-Balancer. In diesem Fall gibt die Google Cloud -Konsole beim Erstellen des Load-Balancers eine Warnmeldung zur Proxyverfügbarkeit aus. Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

Wählen Sie eine andere Region für den Load-Balancer aus. Diese Option kann sinnvoll sein, wenn Sie Back-Ends in einer anderen Region haben.
Wählen Sie ein VPC-Netzwerk aus, dem bereits ein Nur-Proxy-Subnetz zugewiesen ist.
Warten Sie, bis das Kapazitätsproblem behoben ist.

Console

Konfiguration starten

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

Load Balancing aufrufen
Klicken Sie auf Load-Balancer erstellen.
Wählen Sie unter Typ des Load Balancers die Option Network Load Balancer (TCP/UDP/SSL) aus und klicken Sie auf Weiter.
Wählen Sie unter Proxy oder Passthrough die Option Proxy-Load Balancer aus und klicken Sie auf Weiter.
Wählen Sie für Öffentlich oder intern die Option Intern aus und klicken Sie auf Weiter.
Wählen Sie für Regionenübergreifende oder Einzelregions-Bereitstellung die Option Best für regionenübergreifende Arbeitslasten aus und klicken Sie auf Weiter.
Klicken Sie auf Konfigurieren.

Grundlegende Konfiguration

Geben Sie einen Namen für den Load Balancer an.
Wählen Sie für Netzwerk die Option NETWORK aus.

Frontend mit zwei Weiterleitungsregeln konfigurieren

Klicken Sie auf Front-End-Konfiguration.

Geben Sie einen Namen für die Weiterleitungsregel an.
Wählen Sie in der Liste Subnetzwerkregion die Option REGION_A aus.
Nur-Proxy-Subnetz reservieren

Wählen Sie in der Liste Subnetzwerk die Option SUBNET_A aus.
Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.

Geben Sie einen Namen für die statische IP-Adresse an.
Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.2.99 ein.
Wählen Sie Reservieren aus.

Klicken Sie auf Fertig.
Klicken Sie auf Front-End-IP und -Port hinzufügen, um die zweite Weiterleitungsregel hinzuzufügen.

Geben Sie einen Namen für die Weiterleitungsregel an.
Wählen Sie in der Liste Subnetzwerkregion die Option REGION_B aus.
Nur-Proxy-Subnetz reservieren

Wählen Sie in der Liste Subnetzwerk die Option SUBNET_B aus.
Klicken Sie in der Liste IP-Adresse auf IP-Adresse erstellen. Die Seite Statische interne IP-Adresse reservieren wird geöffnet.

Geben Sie einen Namen für die statische IP-Adresse an.
Wählen Sie im Abschnitt Statische IP-Adresse die Option Selbst auswählen aus.
Geben Sie im Abschnitt Benutzerdefinierte IP-Adresse 10.1.3.99 ein.
Wählen Sie Reservieren aus.

Klicken Sie auf Fertig.

Backend-Dienst konfigurieren

Klicken Sie auf Backend-Konfiguration.
Klicken Sie in der Liste Backend-Dienste erstellen oder auswählen auf Backend-Dienst erstellen.
Geben Sie einen Namen für den Backend-Dienst an.
Wählen Sie für Protocol die Option TCP aus.
Geben Sie als Benannter Port http ein.
Wählen Sie in der Liste Backend-Typ die Option Instanzgruppe aus.
Klicken Sie in der Liste Systemdiagnose auf Systemdiagnose erstellen und geben Sie dann die folgenden Informationen ein:

Geben Sie im Feld Name global-http-health-check ein.
Wählen Sie in der Liste Protokoll die Option HTTP aus.
Geben Sie in das Feld Port die Zahl 80 ein.
Klicken Sie auf Erstellen.

Im Abschnitt Neues Backend:

Wählen Sie in der Liste Instanzgruppe in REGION_A die Option gl4-ilb-miga aus.
Legen Sie für Portnummern den Wert 80 fest.
Wählen Sie für den Ausgleichsmodus die Option Connection aus.
Klicken Sie auf Fertig.
Klicken Sie auf Backend hinzufügen, um ein weiteres Backend hinzuzufügen.
Wählen Sie in der Liste Instanzgruppe in REGION_B die Option gl4-ilb-migb aus.
Legen Sie für Portnummern den Wert 80 fest.
Klicken Sie auf Fertig.

Konfiguration prüfen

Klicken Sie auf Prüfen und abschließen.
Prüfen Sie die Konfigurationseinstellungen des Load-Balancers.
Klicken Sie auf Erstellen.

gcloud

Definieren Sie die HTTP-Systemdiagnose mit dem Befehl gcloud compute health-checks create tcp.

gcloud compute health-checks create tcp global-health-check \
   --use-serving-port \
   --global

Definieren Sie den Backend-Dienst mit dem Befehl gcloud compute backend-services create.

gcloud compute backend-services create gl4-gilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=TCP \
  --enable-logging \
  --logging-sample-rate=1.0 \
  --health-checks=global-health-check \
  --global-health-checks \
  --global

Fügen Sie dem Backend-Dienst mit dem Befehl gcloud compute backend-services add-backend Backends hinzu.

gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-miga \
  --instance-group-zone=ZONE_A \
  --global

gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

Erstellen Sie den Zielproxy.

Erstellen Sie den Zielproxy mit dem Befehl gcloud compute target-tcp-proxies create.

gcloud compute target-tcp-proxies create gilb-tcp-proxy \
  --backend-service=gl4-gilb-backend-service \
  --global

Erstellen Sie zwei Weiterleitungsregeln, eine mit einer VIP (10.1.2.99) in REGION_B und eine weitere mit einer VIP (10.1.3.99) in REGION_A. Weitere Informationen finden Sie unter Statische interne IPv4-Adresse reservieren.

Bei benutzerdefinierten Netzwerken müssen Sie in der Weiterleitungsregel auf das Subnetz verweisen. Achten Sie darauf, dass dies das VM-Subnetz und nicht das Proxy-Subnetz ist.

Verwenden Sie den Befehl gcloud compute forwarding-rules create mit den richtigen Flags.

gcloud compute forwarding-rules create gil4forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

gcloud compute forwarding-rules create gil4forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

API

Erstellen Sie die Systemdiagnose durch Senden einer POST-Anfrage an die Methode healthChecks.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Erstellen Sie den globalen Backend-Dienst durch Senden einer POST-Anfrage an die Methode backendServices.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Erstellen Sie den Ziel-TCP-Proxy durch Senden einer POST-Anfrage an die Methode targetTcpProxies.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetTcpProxy

{
"name": "l4-ilb-proxy",
}

Erstellen Sie die Firewallregel durch Senden einer POST-Anfrage an die Methode forwardingRules.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Erstellen Sie die Firewallregel durch Senden einer POST-Anfrage an die Methode globalForwardingRules.insert. Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Load-Balancer testen

VM-Instanz zum Testen der Konnektivität erstellen

Erstellen Sie eine Client-VM in den Regionen REGION_B und REGION_A:

gcloud compute instances create l4-ilb-client-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_A \
    --zone=ZONE_A \
    --tags=allow-ssh

gcloud compute instances create l4-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

Verwenden Sie SSH, um eine Verbindung zu jeder Clientinstanz herzustellen.

gcloud compute ssh l4-ilb-client-a --zone=ZONE_A

gcloud compute ssh l4-ilb-client-b --zone=ZONE_B

Prüfen Sie, ob die IP-Adresse ihren Hostnamen bereitstellt.
- Prüfen Sie, ob die Client-VM beide IP-Adressen erreichen kann. Der Befehl sollte erfolgreich sein und den Namen der Backend-VM zurückgeben, von der die Anfrage verarbeitet wurde:
```
curl 10.1.2.99
```
```
curl 10.1.3.99
```

Failover testen

Prüfen Sie das Failover auf Backends in der Region REGION_A, wenn Backends in der REGION_B fehlerhaft oder nicht erreichbar sind. Entfernen Sie alle Backends aus REGION_B, um ein Failover zu simulieren:
```
gcloud compute backend-services remove-backend gl4-gilb-backend-service \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global
```
Stellen Sie eine SSH-Verbindung zu einer Client-VM in REGION_B her.
```
gcloud compute ssh l4-ilb-client-b \
   --zone=ZONE_B
```

Senden Sie Anfragen an die IP-Adresse mit Load-Balancing in der Region REGION_B. Die Befehlsausgabe zeigt Antworten von Backend-VMs in REGION_A:

{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl 10.1.3.99)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.3.99: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Zusätzliche Konfigurationsoptionen

In diesem Abschnitt wird die Konfiguration des Beispiels um alternative und zusätzliche Optionen erweitert. Alle Aufgaben sind optional. Sie können sie in beliebiger Reihenfolge ausführen.

Load-Balancer mit TLS-Routen erstellen

In diesem Abschnitt erfahren Sie, wie Sie einen Load Balancer erstellen, der SNI-basiertes Routing verwenden kann. Mit SNI-basiertem Routing können Ihre Proxy-Netzwerk-Load-Balancer Traffic anhand des SNI-Hostnamens (Server Name Indication) weiterleiten, der während des TLS-Handshake angegeben wird.

Für diesen Load Balancer verwenden wir dieselben Netzwerke, Subnetze und Firewallregeln, die zuvor auf dieser Seite erstellt wurden. Sie konfigurieren die im folgenden Diagramm dargestellte Bereitstellung:

Konfiguration des regionsübergreifenden internen Proxy-Network Load Balancers mit TLS-Routen — Konfiguration des externen Proxy-Network-Load-Balancers mit TLS-Routen.

Backend einer verwalteten Instanzgruppe erstellen

In diesem Abschnitt erfahren Sie, wie Sie Back-Ends für verwaltete Instanzgruppen (Managed Instance Group, MIG) für den Load Balancer erstellen. Die MIG stellt VM-Instanzen bereit, auf denen die Backend-Server für dieses Beispiel ausgeführt werden.

Bei der Anleitung für die Google Cloud CLI in diesem Leitfaden wird davon ausgegangen, dass Sie Cloud Shell oder eine andere Umgebung verwenden, in der bash installiert ist.

Erstellen Sie eine Instanzvorlage mit einem HTTPS-Dienst vom Typ „echo“, der über Port 443 verfügbar gemacht wird.

gcloud compute instance-templates create INSTANCE_TEMPLATE_NAME \
--region=REGION_A \
--network=NETWORK \
--subnet=SUBNET_A \
--stack-type=IPv4_ONLY \
--tags=allow-ssh,load-balanced-backend \
--image-family=debian-12 \
--image-project=debian-cloud \
--metadata=startup-script='#! /bin/bash
sudo sed -i "s/^#DNS=.*/DNS=8.8.8.8 8.8.4.4/" /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved
sudo rm -rf /var/lib/apt/lists/*
sudo apt-get -y clean
sudo apt-get -y update
sudo apt-get -y install ca-certificates curl gnupg software-properties-common
sudo curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
sudo apt-get -y update
sudo apt-get -y install docker-ce
sudo which docker
echo "{ \"registry-mirrors\": [\"https://mirror.gcr.io\"] }" | sudo tee -a /etc/docker/daemon.json
sudo service docker restart
sudo docker run -e HTTPS_PORT=9999 -p 443:9999 --rm -dt mendhak/http-https-echo:22'

Ersetzen Sie Folgendes:

INSTANCE_TEMPLATE_NAME: ein Name für die Instanzvorlage.
REGION_A: die Region für die Instanzvorlage.
NETWORK: Der Name des Netzwerks.
SUBNET_A: der Name des Subnetzwerks.

Erstellen Sie anhand der Instanzvorlage eine verwaltete Instanzgruppe:

gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
  --zone=ZONE_A \
  --size=2 \
  --template=INSTANCE_TEMPLATE_NAME

Ersetzen Sie ZONE_A durch die Zone der Instanzgruppe.

Legen Sie den Namen des Bereitstellungsports für die verwaltete Instanzgruppe fest:
```
gcloud compute instance-groups managed set-named-ports INSTANCE_GROUP_NAME \
  --named-ports=PORT_NAME:PORT_NUMBER \
  --zone=ZONE_A
```
Ersetzen Sie Folgendes:
- PORT_NAME: Ein Name für den Serving-Port, z. B. tcp443.
- PORT_NUMBER: Eine Portnummer für den Bereitstellungsport, z. B. 443.

Firewall konfigurieren

Konfigurieren Sie eine Firewallregel, um Traffic vom Load Balancer und von den Systemdiagnoseprüfungen zu den Backend-Instanzen zuzulassen.

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
   --target-tags=allow-health-check \
    --rules=tcp:443

Ersetzen Sie FIREWALL_RULE_NAME durch einen Namen für die Firewallregel.

Load-Balancer konfigurieren

Erstellen Sie eine HTTPS-Systemdiagnose:
```
gcloud compute health-checks create http HTTPS_HEALTH_CHECK_NAME \
    --global \
    --port=HC_PORT
```
Ersetzen Sie Folgendes:
- HTTP_HEALTH_CHECK_NAME: Ein Name für die Systemdiagnose.
- HC_PORT: der Port für die Systemdiagnose.
Erstellen Sie einen Backend-Dienst.
```
gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=TCP \
    --port-name=PORT_NAME \
    --health-checks=global-health-check \
    --global-health-checks \
    --global
```
Ersetzen Sie Folgendes:
- BACKEND_SERVICE_NAME: Ein Name für den Backend-Dienst.
- PORT_NAME: der Portname für den Backend-Dienst. Verwenden Sie denselben benannten Port, der für die Instanzgruppe konfiguriert ist, z. B. tcp443.
- HTTPS_HEALTH_CHECK_NAME: der Name der HTTPS-Systemdiagnose.

Fügen Sie die Backend-Instanzgruppe Ihrem Backend-Dienst hinzu:

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --balancing-mode=UTILIZATION \
    --max-utilization=0.8 \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=ZONE_A \
    --global

Ersetzen Sie Folgendes:

INSTANCE_GROUP_NAME: Der Name der Backend-Instanzgruppe.
ZONE_A: Zone der Instanzgruppe.

Erstellen Sie einen Ziel-TCP-Proxy.

gcloud beta compute target-tcp-proxies create TARGET_TCP_PROXY_NAME \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --proxy-header=NONE \
    --global

Ersetzen Sie TARGET_TCP_PROXY_NAME durch den Namen des Ziel-TCP-Proxys.

Erstellen Sie eine TLS-Routenspezifikation und speichern Sie sie in einer YAML-Datei.

cat <<EOF | tee YAML_FILE_NAME
name: TLS_ROUTE_NAME
targetProxies:
- projects/PROJECT_NUMBER/locations/global/targetTcpProxies/TARGET_TCP_PROXY
rules:
- matches:
  - sniHost:
    - example.com
  action:
  destinations:
  - serviceName: projects/PROJECT_NUMBER/locations/global/backendServices/BACKEND_SERVICE
EOF

Ersetzen Sie Folgendes:

YAML_FILE_NAME: Ein Name für die YAML-Datei, z. B. tls-route.yaml.
TLS_ROUTE_NAME: ein Name für die TLS-Route.
PROJECT_NUMBER: die Projektnummer

Erstellen Sie die TLS-Routenressource mit der YAML-Spezifikationsdatei.

gcloud network-services tls-routes import TLS_ROUTE_NAME \
  --source=YAML_FILE_NAME \
  --global

Erstellen Sie die Weiterleitungsregel.
```
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=IP_ADDRESS \
  --ports=PORT \
  --target-tcp-proxy=TARGET_TCP_PROXY_NAME \
  --global
```
Ersetzen Sie Folgendes:
- FORWARDING_RULE_NAME ist ein Name für die Weiterleitungsregel.
- NETWORK: Der Name des Netzwerks.
- SUBNET_A: der Name des Subnetzwerks in derselben Region wie der Load-Balancer.
- IP_ADDRESS: die IP-Adresse des Load-Balancers.
- PORT_NUMBER: Der von der Weiterleitungsregel verwendete Port, z. B. 443.

Load-Balancer testen

Nachdem Sie den Load-Balancer konfiguriert haben, können Sie Traffic zum Testen an die IP-Adresse des Load-Balancers senden.

Prüfen Sie, ob Sie über den Load-Balancer auf den HTTPS-Dienst zugreifen können.
```
curl https://example.com --resolve example.com:443:IP_ADDRESS -k
```
Der Befehl sollte eine Antwort von einer der VMs in der verwalteten Instanzgruppe zurückgeben, wobei der Hostname an die Console ausgegeben wird.
```
"path": "/",
"headers": {
  "host": "example.com",
  "user-agent": "curl/7.81.0",
  "accept": "*/*"
},
"method": "GET",
"body": "",
"fresh": false,
"hostname": "example.com",
"ip": "::ffff:10.142.0.2",
"ips": [],
"protocol": "https",
"query": {},
"subdomains": [],
"xhr": false,
"os": {
  "hostname": "0cd3aec9b351"
},
"connection": {
  "servername": "example.com"
}
```
Sie können das weiter überprüfen, indem Sie einen anderen SNI-Hostnamen angeben, der nicht mit einer TLS-Route übereinstimmt, oder indem Sie überhaupt keinen SNI-Hostnamen angeben. In diesem Fall wird die Anfrage verworfen.
- Führen Sie einen Test mit einem SNI-Hostname aus, der nicht mit „example.com“ übereinstimmt, um sicherzustellen, dass die Verbindung abgelehnt wird.
```
curl https://unknown.com --resolve unknown.com:443:IP_ADDRESS -k
```
- Führen Sie einen Test mit einer Nur-Text-Verbindung ohne TLS durch, um sicherzustellen, dass die Verbindung abgelehnt wird.
```
curl example.com:443 --resolve example.com:443:IP_ADDRESS -k
```
Diese Befehle geben den folgenden Fehler zurück.
```
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection
```
Der Fehlercode connection_refused wird in den proxyStatus-Logs angezeigt, wenn der Load-Balancer solche ungültigen Verbindungen ablehnt.

PROXY-Protokoll für den Erhalt der Verbindungsinformationen des Clients

Der interne Proxy-Network Load Balancer beendet TCP-Verbindungen vom Client und erstellt neue Verbindungen zu den VM-Instanzen. Standardmäßig bleiben die ursprüngliche IP-Adresse des Clients und die Portinformationen nicht automatisch erhalten.

Aktivieren Sie deshalb das PROXY-Protokoll (Version 1). Damit bleiben die ursprünglichen Verbindungsinformationen erhalten und werden an Ihre Instanzen gesendet. Mit diesem Protokoll wird mit der Anfrage zusätzlich ein Header mit Quell-IP-Adresse, Ziel-IP-Adresse und Portnummern an die Instanz gesendet.

Achten Sie darauf, dass die Back-End-Instanzen des internen Proxy-Network Load Balancers HTTP- oder HTTPS-Server ausführen, die PROXY-Protokoll-Header unterstützen. Wenn die HTTP-Server nicht für die Unterstützung von PROXY-Protokoll-Headern konfiguriert sind, geben die Back-End-Instanzen leere Antworten zurück. Das PROXY-Protokoll funktioniert beispielsweise nicht mit der Apache HTTP Server-Software. Sie können verschiedene Webserver-Software wie Nginx verwenden.

Wenn Sie das PROXY-Protokoll für Nutzer-Traffic festlegen, müssen Sie es auch für die Systemdiagnosen festlegen. Wenn Sie Systemdiagnosen und Inhaltsbereitstellung über denselben Port durchführen, legen Sie den --proxy-header der Systemdiagnose so fest, dass er mit der Einstellung des Load-Balancers übereinstimmt.

Der PROXY-Protokoll-Header enthält in der Regel eine einzelne, für Nutzer lesbare Textzeile im folgenden Format:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

Im Folgenden ist ein Beispiel für das PROXY-Protokoll dargestellt:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

Im vorherigen Beispiel lautet die Client-IP-Adresse 192.0.2.1, die Load Balancing-IP-Adresse 198.51.100.1, der Clientport 15221 und der Zielport 110.

Ist die IP-Adresse des Clients nicht bekannt, erstellt der Load Balancer einen Proxy-Protokoll-Header in folgendem Format:

PROXY UNKNOWN\r\n

PROXY-Protokoll-Header für den Ziel-TCP-Proxy aktualisieren

In der Beispielkonfiguration für Load Balancer auf dieser Seite erfahren Sie, wie Sie den PROXY-Protokoll-Header beim Erstellen des internen Proxy-Network Load Balancers aktivieren. Führen Sie die folgenden Schritte aus, um den PROXY-Protokoll-Header eines bestehenden Ziel-TCP-Proxys zu ändern.

Console

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

Load Balancing aufrufen
Klicken Sie neben dem Load Balancer auf Bearbeiten.
Klicken Sie auf Front-End-Konfiguration.
Ändern Sie den Wert des Felds Proxyprotokoll zu Ein.
Klicken Sie auf Update (Aktualisieren), um die Änderungen zu speichern.

gcloud

Bearbeiten Sie im folgenden Befehl das Feld --proxy-header und legen Sie es je nach Anforderung auf NONE oder PROXY_V1 fest.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

Dieselbe IP-Adresse für mehrere interne Weiterleitungsregeln verwenden

Damit mehrere interne Weiterleitungsregeln dieselbe interne IP-Adresse haben, müssen Sie die IP-Adresse reservieren und das Flag --purpose auf SHARED_LOADBALANCER_VIP setzen.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Sitzungsaffinität aktivieren

Die Beispielkonfiguration erstellt einen Backend-Dienst ohne Sitzungsaffinität.

Diese Verfahren zeigen, wie Sie einen Backend-Dienst für den vorher erstellten Beispiel-Load Balancer aktualisieren, damit der Backend-Dienst die Client-IP-Affinität oder Cookie-Affinität verwendet.

Wenn die Client-IP-Affinität aktiviert ist, leitet der Load-Balancer die Anfragen eines bestimmten Clients anhand eines Hashs, der aus der IP-Adresse des Clients und der IP-Adresse des Load-Balancers (der internen IP-Adresse einer internen Weiterleitungsregel) erstellt wurde, an dieselbe Backend-VM weiter.

Console

So aktivieren Sie die Client-IP-Sitzungsaffinität:

Rufen Sie in der Google Cloud Console die Seite Load Balancing auf.
Load-Balancing aufrufen
Klicken Sie auf Back-Ends.
Klicken Sie auf den Namen des Backend-Dienstes, den Sie für dieses Beispiel erstellt haben, und dann auf Bearbeiten.
Klicken Sie auf der Seite Back-End-Dienstdetails auf Erweiterte Konfiguration.
Wählen Sie im Menü unter Sitzungsaffinität die Option Client-IP aus.
Klicken Sie auf Aktualisieren.

gcloud

Aktualisieren Sie den Backend-Dienst BACKEND_SERVICE mit dem folgenden gcloud-Befehl. Geben Sie dabei die Sitzungsaffinität der Client-IP an:

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

Verbindungsausgleich aktivieren

Sie können für Backend-Dienste den Verbindungsausgleich aktivieren, um Dienstausfälle für Nutzer zu minimieren, wenn eine Instanz, die Traffic bereitstellt, beendet bzw. manuell oder durch Autoscaling entfernt wird. Weitere Informationen zum Verbindungsausgleich finden Sie unter Verbindungsausgleich aktivieren.

Regionenübergreifenden internen Proxy-Network Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Berechtigungen

Netzwerk und Subnetze konfigurieren

Backend-Subnetze konfigurieren

Console

gcloud

Terraform

API

Nur-Proxy-Subnetz konfigurieren

Console

gcloud

Terraform

API

Firewallregeln konfigurieren

Console

gcloud

API

Erstellen Sie eine verwaltete Instanzgruppe.

Console

gcloud

API

Load-Balancer konfigurieren

Proxyverfügbarkeit

Console

Konfiguration starten

gcloud

API

Load-Balancer testen

VM-Instanz zum Testen der Konnektivität erstellen

Failover testen

Zusätzliche Konfigurationsoptionen

Load-Balancer mit TLS-Routen erstellen

Backend einer verwalteten Instanzgruppe erstellen

Firewall konfigurieren

Load-Balancer konfigurieren

Load-Balancer testen

PROXY-Protokoll für den Erhalt der Verbindungsinformationen des Clients

PROXY-Protokoll-Header für den Ziel-TCP-Proxy aktualisieren

Console

gcloud

Dieselbe IP-Adresse für mehrere interne Weiterleitungsregeln verwenden

gcloud

Sitzungsaffinität aktivieren

Console

gcloud

Verbindungsausgleich aktivieren

Nächste Schritte

Regionenübergreifenden internen Proxy-Network Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten