Internen Passthrough-Network-Load-Balancer für Drittanbieter-Appliances einrichten

In Google Cloud können Sie Appliances von Drittanbietern hochverfügbar und horizontal skalieren. Dazu konfigurieren Sie eine statische Route und legen als nächsten Hop den internen Passthrough-Network-Load-Balancer von Google Cloud fest. Auf diese Weise kann der Load-Balancer Traffic für ein Zielpräfix gleichmäßig auf einen Pool aus VM-Appliances von Drittanbietern verteilen.

In diesem Leitfaden wird anhand eines Beispiels erläutert, wie ein interner Passthrough-Network-Load-Balancer als nächster Hop konfiguriert wird. Bevor Sie diese Anleitung durcharbeiten, sollten Sie sich mit Folgendem vertraut machen:

Berechtigungen

Damit Sie dieser Anleitung folgen können, müssen Sie Instanzen erstellen und ein Netzwerk in einem Projekt ändern. Sie sollten daher entweder Inhaber oder Bearbeiter des Projekts sein oder über alle folgenden IAM-Rollen für Compute Engine verfügen:

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

Weitere Informationen finden Sie in folgenden Leitfäden:

Interne Passthrough-Network-Load-Balancer als nächste Hops mit gemeinsamen Back-Ends einrichten

In dieser Anleitung erfahren Sie, wie Sie einen internen Passthrough-Network-Load-Balancer als Next-Hop für eine statische Route zur Integration skalierter virtueller Appliances verwenden.

Die in dieser Anleitung beschriebene Lösung erstellt Appliance-VMs, auf denen Debian Linux ausgeführt wird. Die Beispiel-VMs führen keine Paketfilterung durch. Sie können diese Funktionalität jedoch hinzufügen. Ändern Sie dazu die Netzwerkkonfiguration in diesem Beispiel oder verwenden Sie eine andere Paketfilter- oder Routing-Software.

In diesem Abschnitt werden Schritte erläutert, mit denen Sie die folgenden Ressourcen konfigurieren können:

  • Beispiele für VPC-Netzwerke und benutzerdefinierte Subnetze
  • Google Cloud-Firewall-Regeln, die eingehende Verbindungen zu Back-End-Appliance-VMs ermöglichen
  • Statische Routen
  • Zwei Client-VMs zum Testen von Verbindungen
  • Die folgenden Komponenten für internen Passthrough-Network-Load-Balancer:
    • Backend-VMs in einer verwalteten Instanzgruppe (MIG, managed instance group)
    • Eine Systemdiagnose für den Back-End-Dienst
    • Ein interner Back-End-Dienst in der Region us-west1, um die Verteilung von Verbindungen zwischen den Back-End-VMs zu verwalten
    • Eine interne Weiterleitungsregel und eine interne IP-Adresse für das Frontend des Load-Balancers

Dieses Beispiel zeigt das Load-Balancing für mehrere Back-End-NICs, wie unter Load-Balancing für mehrere NICs beschrieben.

Die Topologie sieht so aus:

Detailliertes Beispiel für den nächsten Hop mit Multi-NIC für den internen Passthrough-Network Load Balancer
Detailliertes Beispiel für den nächsten Hop mit Multi-NIC für den internen Passthrough-Network Load Balancer (zum Vergrößern klicken)

Das Diagramm zeigt einige der im Beispiel erstellten Ressourcen:

  • Anwendungsinstanzen hinter einem internen Passthrough-Network-Load-Balancer (in diesem Beispiel fr-ilb1). Die Anwendungsinstanzen haben ausschließlich interne IP-Adressen.
  • Für jede Anwendungsinstanz ist das Flag can-ip-forward aktiviert. Ohne dieses Flag kann eine Compute Engine-VM nur dann ein Paket übertragen, wenn die Quell-IP-Adresse des Pakets mit der internen IP-Adresse der VM, einer IP-Adresse aus einem Alias-IP-Bereich oder einer IP-Adresse einer Weiterleitungsregel, die zur VM aufgelöst wird, übereinstimmt. Das Flag can-ip-forward ändert dieses Verhalten, sodass die VM Pakete mit einer beliebigen Quell-IP-Adresse übertragen kann.
  • Eine statische Route mit dem Ziel 10.50.1.0/24 und dem nächsten Hop auf die Weiterleitungsregel des Load-Balancers eingestellt, fr-ilb1.

Das Diagramm zeigt außerdem den Trafficfluss:

  • Das VPC-Netzwerk testing hat eine statische Route für Traffic, die für das Subnetz 10.50.1.0/24 bestimmt ist. Diese Route leitet den Traffic zum Load-Balancer weiter.
  • Der Load Balancer leitet den Traffic basierend auf der konfigurierten Sitzungsaffinität an eine der Anwendungsinstanzen weiter. (Die Sitzungsaffinität wirkt sich nur auf den TCP-Traffic aus.)

Weitere Anwendungsfälle finden Sie unter Interne TCP/UDP-Load-Balancer als nächste Hops.

Netzwerke, Regionen und Subnetze konfigurieren

In diesem Beispiel werden die folgenden VPC-Netzwerke, Regionen und Subnetze verwendet:

  • Netzwerke: Für dieses Beispiel sind zwei Netzwerke mit jeweils mindestens einem Subnetz erforderlich. Jede Back-End-Appliance-VM von einem Drittanbieter muss über mindestens zwei Netzwerkschnittstellen verfügen, eine in jedem VPC-Netzwerk. Die Netzwerke in diesem Beispiel sind VPC-Netzwerke im benutzerdefinierten Modus mit den Namen testing und production. Das Netzwerk testing in diesem Beispiel enthält den Client und den Load-Balancer. Das Netzwerk production enthält die Ziel-VM.

  • Region: Die Subnetze befinden sich in der Region us-west1. Die Subnetze müssen sich in derselben Region befinden, weil VM-Instanzen zonale Ressourcen sind.

  • Subnetze: In den Subnetzen testing-subnet und production-subnet werden die primären IP-Adressbereiche 10.30.1.0/24 bzw. 10.50.1.0/24 verwendet.

So erstellen Sie die Beispielnetzwerke und -subnetze:

Console

Erstellen Sie das testing-Netzwerk und das testing-subnet:

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

    Zur Seite VPC-Netzwerke

  2. Klicken Sie auf VPC-Netzwerk erstellen.

  3. Geben Sie als Namen testing ein.

  4. Im Bereich Subnetze:

    • Legen Sie Modus für Subnetzerstellung auf Benutzerdefiniert fest.
    • Geben Sie im Bereich Neues Subnetz folgende Informationen ein:
      • Name: testing-subnet
      • Region: us-west1
      • IP-Adressbereich: 10.30.1.0/24
      • Klicken Sie auf Fertig.

  5. Klicken Sie auf Erstellen.

Erstellen Sie das production-Netzwerk und das production-subnet:

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

    Zur Seite VPC-Netzwerke

  2. Klicken Sie auf VPC-Netzwerk erstellen.

  3. Geben Sie als Namen production ein.

  4. Im Bereich Subnetze:

    • Legen Sie Modus für Subnetzerstellung auf Benutzerdefiniert fest.
    • Geben Sie im Bereich Neues Subnetz folgende Informationen ein:
      • Name: production-subnet
      • Region: us-west1
      • IP-Adressbereich: 10.50.1.0/24
      • Klicken Sie auf Fertig.

  5. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie die VPC-Netzwerke im benutzerdefinierten Modus:

    gcloud compute networks create testing --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. Erstellen Sie Subnetze in den testing- und production-Netzwerken in der Region us-west1:

    gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

Firewallregeln konfigurieren

Dieses Beispiel verwendet die folgenden Firewallregeln:

  • fw-allow-testing-from-both: Eine Regel für eingehenden Traffic, die für alle Ziele im testing-Netzwerk gilt. Mit dieser Regel wird Traffic von Quellen im IP-Adressbereich 10.30.1.0/24 und 10.50.1.0/24 zugelassen. Diese beiden Bereiche decken die primären internen IP-Adressen der VMs in beiden Netzwerken ab.

  • fw-allow-production-from-both: Eine Regel für eingehenden Traffic, die für alle Ziele im production-Netzwerk gilt. Mit dieser Regel wird Traffic von Quellen im IP-Adressbereich 10.30.1.0/24 und 10.50.1.0/24 zugelassen. Diese beiden Bereiche decken die primären internen IP-Adressen der VMs in beiden Netzwerken ab.

  • fw-allow-testing-ssh: Eine Regel für eingehenden Traffic, die auf die VM-Instanzen im VPC-Netzwerk testing angewendet wird. Diese Regel lässt eingehende SSH-Verbindungen an TCP-Port 22 von jeder Adresse aus zu. Sie können einen eingeschränkteren IP-Bereich von Quellen für diese Regel auswählen. Geben Sie dazu beispielsweise nur die IP-Bereiche 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 welche die Firewallregel angewendet wird.

  • fw-allow-production-ssh: Eine Regel für eingehenden Traffic, die auf die VM-Instanzen im VPC-Netzwerk production angewendet wird. Diese Regel lässt eingehende SSH-Verbindungen an TCP-Port 22 von jeder Adresse aus zu. Wie bei der fw-allow-testing-ssh-Regel können Sie einen restriktiveren Quell-IP-Bereich für diese Regel auswählen.

  • fw-allow-health-check: Eine Regel für eingehenden Traffic für die Appliance-VMs von Drittanbietern, für die ein Load-Balancing stattfindet. Diese Regel lässt Traffic von den Systemdiagnosesystemen von Google Cloud (130.211.0.0/22 und 35.191.0.0/16) zu. In diesem Beispiel wird das Ziel-Tag allow-health-check verwendet, um die Instanzen zu identifizieren, auf die sie angewendet werden soll.

  • fw-allow-production-health-check: Eine Regel für eingehenden Traffic für die Appliances von Drittanbietern, für die ein Load-Balancing durchgeführt wird. Diese Regel lässt Traffic von den Systemdiagnosesystemen von Google Cloud (130.211.0.0/22 und 35.191.0.0/16) zu. In diesem Beispiel wird das Ziel-Tag allow-health-check verwendet, um die 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 Back-End-Instanzen. Sie müssen eine Firewallregel erstellen, um Systemdiagnosen aus den IP-Bereichen von Google Cloud-Prüfsystemen zuzulassen. Weitere Informationen finden Sie unter Prüfungs-IP-Bereiche.

Console

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

    Zu den Firewall-Richtlinien

  2. Klicken Sie auf Firewallregel erstellen und geben Sie folgende Informationen ein, um die Regel zu erstellen, die es Test-VMs erlaubt, Pakete aus den Test- und den Produktions-Subnetzen zu empfangen:

    • Name: fw-allow-testing-from-both
    • Netzwerk: testing
    • Priorität: 1000
    • Trafficrichtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Alle Instanzen im Netzwerk
    • Quellfilter: IPv4-Bereiche.
    • Quell-IPv6-Bereiche: 10.30.1.0/24, 10.50.1.0/24
    • Protokolle und Ports: Alle zulassen

  3. Klicken Sie auf Erstellen.

  4. Klicken Sie auf Firewallregel erstellen und geben Sie folgende Informationen ein, um die Regel zu erstellen, die Produktions-VMs erlauben soll, Pakete aus den Test- und Produktions-Subnetzen zu empfangen:

    • Name: fw-allow-production-from-both
    • Netzwerk: production
    • Priorität: 1000
    • Trafficrichtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Alle Instanzen im Netzwerk
    • Quellfilter: IPv4-Bereiche.
    • Quell-IPv6-Bereiche: 10.30.1.0/24, 10.50.1.0/24
    • Protokolle und Ports: Alle zulassen

  5. Klicken Sie auf Erstellen.

  6. Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen in der Testumgebung zulässt:

    • Name: fw-allow-testing-ssh
    • Netzwerk: testing
    • Priorität: 1000
    • 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 und geben Sie Folgendes ein: tcp:22

  7. Klicken Sie auf Erstellen.

  8. Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen in der Produktionsumgebung zulässt:

    • Name: fw-allow-production-ssh
    • Netzwerk: production
    • Priorität: 1000
    • 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 und geben Sie Folgendes ein: tcp:22

  9. Klicken Sie auf Erstellen.

  10. Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die Google Cloud-Systemdiagnosen in der Testumgebung zulässt:

    • Name: fw-allow-health-check
    • Netzwerk: testing
    • Priorität: 1000
    • Trafficrichtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Angegebene Ziel-Tags
    • Zieltags: allow-health-check
    • Quellfilter: IPv4-Bereiche.
    • IPv4-Quellbereiche: 130.211.0.0/22 und 35.191.0.0/16
    • Protokolle und Ports: tcp

  11. Klicken Sie auf Erstellen.

  12. Klicken Sie auf Firewallregel erstellen, um die Regel zu erstellen, die Google Cloud-Systemdiagnosen in der Produktionsumgebung zulässt:

    • Name: fw-allow-production-health-check
    • Netzwerk: production
    • Priorität: 1000
    • Trafficrichtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Angegebene Ziel-Tags
    • Zieltags: allow-health-check
    • Quellfilter: IPv4-Bereiche.
    • IPv4-Quellbereiche: 130.211.0.0/22 und 35.191.0.0/16
    • Protokolle und Ports: tcp

  13. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie die Firewallregel fw-allow-testing-subnet, damit Test-VMs Pakete aus den Subnetzen testing und production empfangen können:

    gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  2. Erstellen Sie die Firewallregel fw-allow-production-subnet, damit Produktions-VMs Pakete aus den Subnetzen testing und production empfangen können:

    gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  3. Erstellen Sie die Firewallregel fw-allow-testing-ssh, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen. Wenn Sie source-ranges weglassen, bezieht Google Cloud die Regel auf jede Quelle.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. Erstellen Sie die Firewallregel fw-allow-production-ssh, um SSH-Verbindungen zu VMs mit dem Netzwerk-Tag allow-ssh zu ermöglichen.

    gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  5. Erstellen Sie die Regel fw-allow-health-check, um Google Cloud-Systemdiagnosen auf den VM-Appliances von Drittanbietern im testing-Netzwerk zuzulassen.

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

  6. Erstellen Sie die Firewallregel fw-allow-production-health-check, um Google Cloud-Systemdiagnosen auf den VM-Appliances von Drittanbietern im production-Netzwerk zuzulassen.

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

Virtuelle Appliances von Drittanbietern erstellen

Die folgenden Schritte zeigen, wie Sie eine Instanzvorlage und eine verwaltete regionale Instanzgruppe mit mehr als einer Netzwerkschnittstelle erstellen. Diese Instanzgruppe wird für dieses Beispiel als virtuelle Appliance des Drittanbieters verwendet.

Console

Sie müssen gcloud für diesen Schritt verwenden, da Sie eine Instanzvorlage mit mehr als einer Netzwerkschnittstelle erstellen müssen. Die Google Cloud Console unterstützt derzeit keine Instanzvorlagen mit mehr als einer Netzwerkschnittstelle.

gcloud

  1. Erstellen Sie eine lokale Datei mit dem Namen config.sh und fügen Sie den folgenden Inhalt ein:

    #!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
# Read VM network configuration:
md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

  2. Erstellen Sie eine Instanzvorlage für Ihre virtuellen Appliances von Drittanbietern. In der Instanzvorlage muss das Flag --can-ip-forward enthalten sein, damit aus der Vorlage erstellte VM-Instanzen Pakete aus anderen Instanzen in den testing- und production-Netzwerken weiterleiten können.

    gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check,my-network-tag \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script="$(< config.sh)"

  3. Erstellen Sie eine verwaltete Instanzgruppe für Ihre virtuellen Appliances von Drittanbietern. Mit diesem Befehl wird eine regionale verwaltete Instanzgruppe erstellt, die dann in us-west1 automatisch skaliert werden kann.

    gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3

Load-Balancing-Ressourcen erstellen

In diesen Schritten konfigurieren Sie alle Komponenten für den internen Passthrough-Network-Load-Balancer. Zuerst konfigurieren Sie die Systemdiagnose und den Backend-Dienst und danach die Frontend-Komponenten:

  • Systemdiagnose: In diesem Beispiel prüft die HTTP-Systemdiagnose auf die HTTP-Antwort 200 (OK). Weitere Informationen finden Sie im Abschnitt "Systemdiagnose" der Übersicht über den internen Passthrough-Network-Load-Balancer.

  • Backend-Dienst: Auch wenn der Backend-Dienst in diesem Beispiel das TCP-Protokoll festlegt, leitet Google Cloud den Traffic für alle Protokolle (TCP, UDP und ICMP) weiter, wenn der Load-Balancer der nächste Hop einer Route ist.

  • Weiterleitungsregel: Auch wenn in diesem Beispiel die Weiterleitungsregel den TCP-Port 80 angibt, wird der Traffic auf einem beliebigen TCP- oder UDP-Port an die Back-Ends des Load-Balancers gesendet, wenn der Load-Balancer der nächste Hop einer Route ist.

  • Interne IP-Adresse: Im Beispiel wird eine interne IP-Adresse (10.30.1.99) für die Weiterleitungsregel angegeben.

Console

Konfiguration starten

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

    Load Balancing aufrufen

  2. Klicken Sie auf Load-Balancer erstellen.
  3. Wählen Sie unter Typ des Load Balancers die Option Network Load Balancer (TCP/UDP/SSL) aus und klicken Sie auf Weiter.
  4. Wählen Sie für Proxy oder Passthrough die Option Passthrough-Load Balancer aus und klicken Sie auf Weiter.
  5. Wählen Sie für Öffentlich oder intern die Option Intern aus und klicken Sie auf Weiter.
  6. Klicken Sie auf Konfigurieren.

Ersten Load-Balancer erstellen

  1. Legen Sie als Name ilb1 fest.
  2. Legen Sie als Region us-west1 fest.
  3. Setzen Sie das Netzwerk auf testing.
  4. Click Backend configuration and make the following changes:
    1. Wählen Sie unter Back-Ends im Bereich Neues Element die Instanzgruppe third-party-instance-group aus und klicken Sie auf Fertig.
    2. Wählen Sie unter Systemdiagnose die Option Weitere Systemdiagnose erstellen aus, geben Sie die folgenden Informationen ein und klicken Sie auf Speichern und fortfahren:
      • Name: hc-http-80
      • Protokoll: HTTP
      • Port: 80
      • Proxyprotokoll: NONE
      • Anfragepfad: / Wenn Sie die Google Cloud Console zum Erstellen des Load-Balancers verwenden, ist die Systemdiagnose global. Wenn Sie eine regionale Systemdiagnose erstellen möchten, verwenden Sie gcloud oder die API.
    3. Wählen Sie unter Sitzungsaffinität die Option Client-IP aus.
    4. Überprüfen Sie, bevor Sie fortfahren, ob sich neben Backend-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt noch einmal durch, wenn nicht.
  5. Klicken Sie auf Frontend-Konfiguration. In the New Frontend IP and port section, make the following changes:
    1. Name: fr-ilb1
    2. Subnetzwerk: testing-subnet
    3. Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus, geben Sie die folgenden Informationen ein und klicken Sie dann auf Reservieren:
      • Name: ip-ilb
      • Statische IP-Adresse: Selbst auswählen
      • Benutzerdefinierte IP-Adresse: 10.30.1.99
    4. Ports: Wählen Sie Einzeln aus und geben Sie als Portnummer den Wert 80 ein. Beachten Sie, dass die Auswahl eines Protokolls und eines Ports für den Load-Balancer die verwendeten Protokolle und Ports nicht einschränkt, wenn der Load-Balancer der nächste Hop einer Route ist.
    5. Überprüfen Sie, bevor Sie fortfahren, ob sich neben der Frontend-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt noch einmal durch, wenn nicht.
  6. Klicken Sie auf Prüfen und abschließen. Kontrollieren Sie die Einstellungen.
  7. Klicken Sie auf Erstellen.

Konfiguration starten

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

    Load Balancing aufrufen

  2. Klicken Sie auf Load-Balancer erstellen.
  3. Wählen Sie unter Typ des Load Balancers die Option Network Load Balancer (TCP/UDP/SSL) aus und klicken Sie auf Weiter.
  4. Wählen Sie für Proxy oder Passthrough die Option Passthrough-Load Balancer aus und klicken Sie auf Weiter.
  5. Wählen Sie für Öffentlich oder intern die Option Intern aus und klicken Sie auf Weiter.
  6. Klicken Sie auf Konfigurieren.

Zweiten Load-Balancer erstellen

  1. Legen Sie als Name ilb2 fest.
  2. Legen Sie als Region us-west1 fest.
  3. Setzen Sie das Netzwerk auf production.
  4. Click Backend configuration and make the following changes:
    1. Wählen Sie unter Back-Ends im Bereich Neues Element die Instanzgruppe third-party-instance-group aus und klicken Sie auf Fertig.
    2. Wählen Sie bei Systemdiagnose die Option hc-http-80 aus.
    3. Wählen Sie unter Sitzungsaffinität die Option Client-IP aus.
    4. Überprüfen Sie, bevor Sie fortfahren, ob sich neben Backend-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt noch einmal durch, wenn nicht.
  5. Klicken Sie auf Frontend-Konfiguration. In the New Frontend IP and port section, make the following changes:
    1. Name: fr-ilb2
    2. Subnetzwerk: production-subnet
    3. Wählen Sie unter Interne IP-Adresse die Option Statische interne IP-Adresse reservieren aus, geben Sie die folgenden Informationen ein und klicken Sie dann auf Reservieren:
      • Name: ip-ilb2
      • Statische IP-Adresse: Selbst auswählen
      • Benutzerdefinierte IP-Adresse: 10.50.1.99
    4. Ports: Wählen Sie Einzeln aus und geben Sie als Portnummer den Wert 80 ein. Beachten Sie, dass die Auswahl eines Protokolls und eines Ports für den Load-Balancer die verwendeten Protokolle und Ports nicht einschränkt, wenn der Load-Balancer der nächste Hop einer Route ist.
    5. Überprüfen Sie, bevor Sie fortfahren, ob sich neben der Frontend-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt noch einmal durch, wenn nicht.
  6. Klicken Sie auf Prüfen und abschließen. Kontrollieren Sie die Einstellungen.

  7. Klicken Sie auf Erstellen.

  8. Konfigurieren Sie die Load-Balancer-Ressourcen im production-VPC-Netzwerk.

gcloud

  1. Erstellen Sie eine neue HTTP-Systemdiagnose, um die TCP-Konnektivität zu den VMs auf Port 80 zu testen.

    gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80

  2. Erstellen Sie zwei interne Back-End-Dienste in der Region us-west1.

    gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

    gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

  3. Fügen Sie die Instanzgruppen, die die virtuellen Appliances von Drittanbietern enthalten, als Back-Ends in den Back-End-Diensten hinzu.

    gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  4. Erstellen Sie die internen Weiterleitungsregeln und verbinden Sie sie mit den Back-End-Diensten, um die Konfiguration des Load-Balancers abzuschließen. Beachten Sie, dass das Protokoll (TCP) und der Port (80) der Load-Balancer die Ports und Protokolle nicht einschränken, die an die Back-End-Instanzen (die virtuellen Appliances von Drittanbietern) weitergeleitet werden, wenn die Load-Balancer als nächste Hops für Routen verwendet werden.

    gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99

    gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99

Statische Routen erstellen, die die Load Balancer als nächste Hops definieren

Zwei statische Routen erstellen, die einen Load-Balancer als nächsten Hop verwenden

Console

Erste Route erstellen

  1. Rufen Sie in der Google Cloud Console die Seite Routen auf.

    Zur Seite „Routen“

  2. Klicken Sie auf Route erstellen.

  3. Geben Sie für die Route Name ilb-nhop-dest-10-50-1 ein.

  4. Wählen Sie das Netzwerk testing aus.

  5. Geben Sie als Quell-IP-Bereich 10.50.1.0/24 ein.

  6. Geben Sie bei Instanztags den Wert my-network-tag ein.

  7. Wählen Sie unter Nächster Hop Weiterleitungsregel des internen TCP/UDP-Load-Balancers angeben aus.

    Verwenden Sie die gcloud CLI oder die API, um die IP-Adresse des Load-Balancers als nächsten Hop anzugeben.

  8. Geben Sie den Namen der Weiterleitungsregel an. Wählen Sie für den Namen der Weiterleitungsregel fr-ilb1 aus.

  9. Klicken Sie auf Erstellen.

Zweite Route erstellen

  1. Klicken Sie auf Route erstellen.
  2. Geben Sie für die Route Name ilb-nhop-dest-10-30-1 ein.
  3. Wählen Sie das Netzwerk testing aus.
  4. Geben Sie als Quell-IP-Bereich 10.30.1.0/24 ein.

  5. Wählen Sie unter Nächster Hop Weiterleitungsregel des internen TCP/UDP-Load-Balancers angeben aus.

    Verwenden Sie die gcloud CLI oder die API, um die IP-Adresse des Load-Balancers als nächsten Hop anzugeben.

  6. Wählen Sie für den Namen der Weiterleitungsregel fr-ilb2 aus.

  7. Klicken Sie auf Erstellen.

gcloud

Erstellen Sie statische Routen, wobei der nächste Hop auf die Weiterleitungsregel jedes Load-Balancers festgelegt und der Zielbereich entsprechend festgelegt sind.

Für das Flag --next-hop-ilb können Sie entweder den Namen oder die IP-Adresse der Weiterleitungsregel angeben. Die IP-Adresse der Weiterleitungsregel für den nächsten Hop kann sich entweder im selben VPC-Netzwerk, das die Route enthält, oder in einem Peering-VPC-Netzwerk befinden. Weitere Informationen finden Sie unter Next-Hop-Projekt und ‑Netzwerk.

In diesem Beispiel verwendet die erste Route die IP-Adresse 10.30.1.99 und die zweite Route den Namen der Weiterleitungsregel fr-ilb12.

Sie können optional ein oder mehrere Instanz-Tags für die Route angeben. Die Route kann für bestimmte VMs gelten, wenn Sie Netzwerk-Tags für die Route angeben. Wenn Sie kein Netzwerk-Tag angeben, gilt die Route für alle VMs im VPC-Netzwerk. In diesem Beispiel verwendet die Route my-network-tag für das Netzwerk-Tag der Route.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

testing-VM-Instanz erstellen

In diesem Beispiel wird eine VM-Instanz mit der IP-Adresse 10.30.1.100 in der testing-subnet (10.30.1.0/24) im testing-VPC-Netzwerk erstellt.

gcloud

  1. Erstellen Sie die testing-vm mit dem folgenden Befehl.

    gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,my-network-tag \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo 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
    sudo systemctl restart apache2'

production-VM-Instanz erstellen

In diesem Beispiel wird eine VM-Instanz mit der IP-Adresse 10.50.1.100 in der production-subnet (10.50.1.0/24) im production-VPC-Netzwerk erstellt.

gcloud

Die production-vm kann sich in einer beliebigen Zone in derselben Region wie der Load-Balancer befinden. Außerdem kann sie jedes Subnetz in dieser Region verwenden. In diesem Beispiel befindet sich production-vm in der Zone us-west1-a.

  1. Erstellen Sie die production-vm mit dem folgenden Befehl.

    gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo 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
    sudo systemctl restart apache2'

Load-Balancing für eine Bereitstellung mit mehreren NICs testen

  1. Integrität der Back-Ends des Load-Balancers prüfen

    gcloud compute backend-services get-health ilb1 --region us-west1

    gcloud compute backend-services get-health ilb2 --region us-west1

  2. Verbindung von der testing-VM testen

    gcloud compute ssh testing-vm --zone=us-west1-a

    curl http://10.50.1.99

    exit

  3. Verbindung von der production-VM testen

    gcloud compute ssh production-vm --zone=us-west1-a

    curl http://10.30.1.99

    exit

Symmetrisches Hashing aktivieren

Beim Berechnen des Hashs, der der Back-End-Instanz zugeordnet ist, ignoriert Google Cloud die Richtung von IP-Adressen und Ports. Der berechnete konsistente Hashwert eines TCP/UDP-Pakets ist unabhängig von der Richtung, aus der das Paket stammt. Dies wird als symmetrisches Hashing bezeichnet.

Zum Aktivieren dieses Hashing-Verhaltens auf vorhandenen internen Passthrough-Network-Load-Balancern müssen Sie die Weiterleitungsregel und die Route für den nächsten Hop neu erstellen.

Weitere Informationen finden Sie unter Symmetrisches Hashing.

Weiterleitungsregeln löschen und neu erstellen

Console

Weiterleitungsregel löschen und neue erstellen

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

    Zur Seite „Load-Balancing“

  2. Klicken Sie auf den be-ilb-Load-Balancer und dann auf Bearbeiten.

  3. Klicken Sie auf Frontend-Konfiguration.

  4. Halten Sie den Mauszeiger über die Weiterleitungsregel und klicken Sie dann auf Löschen, um sie zu entfernen.

  5. Klicken Sie auf Frontend-IP und Port hinzufügen.

  6. Nehmen Sie im Bereich Neue Frontend-IP-Adresse und neuer Frontend-Port folgende Änderungen vor:

    1. Name: FORWARDING_RULE_NAME
    2. Subnetzwerk: SUBNET_NAME
    3. Wählen Sie unter Interne IP-Adresse die Option IP_ADDRESS aus.
    4. Ports: PORT_NUMBER oder ALL
    5. Klicken Sie auf Fertig.
    6. Überprüfen Sie, bevor Sie fortfahren, ob sich neben der Frontend-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt noch einmal durch, wenn nicht.

  7. Klicken Sie auf Prüfen und abschließen. Kontrollieren Sie die Einstellungen.

  8. Klicken Sie auf Erstellen.

gcloud

  1. Löschen Sie Ihre vorhandenen Weiterleitungsregeln.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

  2. Erstellen Sie neue Weiterleitungsregeln mit demselben Namen.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

Wenn SNAT nicht erforderlich ist

Wie im vorherigen Beispiel gezeigt, ist die Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) nicht erforderlich, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Weiterleitungsregel für den internen Passthrough-Network-Load-Balancer wurde am oder nach dem 22. Juni 2021 erstellt.
  • Die statische Route, die auf die Weiterleitungsregel verweist, wurde am oder nach dem 22. Juni 2021 erstellt.
  • Der Backend-Dienst des internen Passthrough-Network-Load-Balancers verwendet nicht die Einstellung Sitzungsaffinität NONE.

So können Sie eine vorhandene interne Passthrough-Network-Load-Balancer-Route für den nächsten Hop in symmetrisches Hashing konvertieren:

  • Achten Sie darauf, dass der Backend-Dienst des internen PPassthrough-Network-Load-Balancers die Einstellung NONE Sitzungsaffinität nicht verwendet

  • Erstellen Sie eine Ersatz-Weiterleitungsregel, die auf denselben Backend-Dienst verweist. Die Ersatzweiterleitungsregel verwendet eine andere IP-Adresse.

  • Erstellen Sie eine statische Ersatzroute, die auf die neue Weiterleitungsregel verweist. Achten Sie darauf, dass diese Ersatzroute eine höhere Priorität als die vorhandene Route hat.

  • Löschen Sie die vorhandene Route mit niedrigerer Priorität (die auf die vorherige Weiterleitungsregel verweist) und löschen Sie dann die vorherige Weiterleitungsregel.

Clean-up

  1. Entfernen Sie in der Konfiguration des Load-Balancers das Back-End aus den Back-End-Diensten.

    gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  2. Löschen Sie die Routen.

    gcloud compute routes delete ilb-nhop-dest-10-50-1

    gcloud compute routes delete ilb-nhop-dest-10-30-1

  3. Löschen Sie in den Load-Balancer-Konfigurationen die Weiterleitungsregeln.

    gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

    gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

  4. Löschen Sie in den Load-Balancer-Konfigurationen die Back-End-Dienste.

    gcloud compute backend-services delete ilb1 \
    --region=us-west1

    gcloud compute backend-services delete ilb2 \
    --region=us-west1

  5. Löschen Sie in den Load-Balancer-Konfigurationen die Systemdiagnose.

    gcloud compute health-checks delete hc-http-80 \
    --region=us-west1

    Wenn Sie die Google Cloud Console verwendet haben, ist die Systemdiagnose global. Der Befehl lautet daher so:

    gcloud compute health-checks delete hc-http-80 \
     --global

  6. Löschen Sie die verwaltete Instanzgruppe.

    gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

  7. Löschen Sie die Instanzvorlagen.

    gcloud compute instance-templates delete third-party-template

    gcloud compute instance-templates delete third-party-template-multinic

  8. Löschen Sie die Test- und Produktionsinstanzen.

    gcloud compute instances delete testing-vm \
    --zone=us-west1-a

    gcloud compute instances delete production-vm \
    --zone=us-west1-a

Nächste Schritte