Internes TCP/UDP-Load-Balancing einrichten

Diese Anleitung vermittelt anhand eines Beispiels die Grundlagen des internen TCP/UDP-Load-Balancing der Google Cloud Platform. Bevor Sie sie durchgehen, machen Sie sich mit folgenden Themen vertraut:

Berechtigungen

Damit Sie dieser Anleitung folgen können, müssen Sie Instanzen erstellen und ein Netzwerk in einem Projekt ändern können. Sie sollten 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 setzen und löschen Sicherheitsadministrator
Instanzen erstellen Instanzadministrator

Einrichtung

In dieser Anleitung erfahren Sie, wie Sie einen internen TCP/UDP-Load-Balancer konfigurieren und testen. Die Schritte in diesem Abschnitt erläutern, wie Sie folgende Elemente konfigurieren:

  1. ein VPC-Netzwerk mit benutzerdefinierten Subnetzen als Beispiel
  2. Firewall-Regeln, die eingehende Verbindung zu Back-End-VMs ermöglichen
  3. vier Back-End-VMs:
    • zwei VMs in einer nicht verwalteten Instanzgruppe in Zone us-west1-a
    • zwei VMs in einer nicht verwalteten Instanzgruppe in Zone us-west1-c
  4. eine Client-VM zum Testen von Verbindungen
  5. die folgenden internen TCP/UDP-Komponenten für den Load-Balancer:
    • eine Systemdiagnose für den Back-End-Dienst
    • einen internen Back-End-Dienst in der Region us-west1, um die Verteilung von Verbindungen zu den zwei zonalen Instanzgruppen zu verwalten
    • eine interne Weiterleitungsregel und eine interne IP-Adresse für das Front-End des Load-Balancers

Die Architektur dieses Beispiels sieht folgendermaßen aus:

Beispielkonfiguration für internes TCP/UDP-Load-Balancing (zum Vergrößern klicken)
Beispielkonfiguration für internes TCP/UDP-Load-Balancing (zum Vergrößern klicken)

Netzwerk, Region und Subnetz konfigurieren

Sie benötigen ein VPC-Netzwerk mit mindestens einem Subnetz. Ein interner TCP/UDP-Load-Balancer ist regional. Der Traffic innerhalb des VPC-Netzwerks wird an den Load-Balancer weitergeleitet, wenn seine Quelle aus einem Subnetz in derselben Region stammt wie der Load-Balancer.

Dieses Beispiel verwendet ein VPC-Netzwerk, eine Region und Subnetz mit den folgenden Parametern:

Gehen Sie folgendermaßen vor, um das Netzwerk und das Subnetz zu erstellen.

Konsole

  1. Gehen Sie auf die VPC-Netzwerkseite der Google Cloud Platform Console.
    Zur VPC-Netzwerkseite
  2. Klicken Sie auf VPC-Netzwerk erstellen.
  3. Geben Sie einen Namen von lb-network ein.
  4. Im Bereich Subnetze:
    • Wählen Sie für Modus für Subnetzerstellung die Option Benutzerdefiniert aus.
    • Geben Sie im Bereich Neues Subnetz die folgenden Informationen ein:
      • Name: lb-subnet
      • Region: us-west1
      • IP-Adressbereich: 10.1.2.0/24
      • Klicken Sie auf Fertig.
  5. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie das benutzerdefinierte VPC-Netzwerk:

    gcloud compute networks create lb-network --subnet-mode=custom

  2. Erstellen Sie im Netzwerk lb-network in der Region us-west1 ein Subnetz:

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

API

Stellen Sie eine POST-Anfrage an die Methode networks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Stellen Sie eine POST-Anfrage an die Methode subnetworks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks
{
  "name": "lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "privateIpGoogleAccess": false
}

Firewallregeln konfigurieren

Dieses Beispiel verwendet die folgenden Firewallregeln:

  • fw-allow-lb-subnet: Eine Regel für eingehenden Traffic, die für alle Ziele im VPC-Netzwerk gilt und Traffic von Quellen im Bereich 10.1.2.0/24 zulässt. Diese Regel lässt eingehenden Traffic von einer beliebigen Quelle innerhalb des Subnetzes lb-subnet an die Instanzen (VMs) zu, für die Load-Balancing durchgeführt wird.

  • fw-allow-ssh: Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und eingehende SSH-Verbindungen über TCP-Port 22 von allen IP-Adressen zulässt. 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. Dieses Beispiel verwendet das Zieltag allow-ssh, um die VMs zu identifizieren, auf die es angewendet werden soll.

  • fw-allow-health-check: Eine Regel für eingehenden Traffic, die für die Instanzen mit Load-Balancing gilt und Traffic von den GCP-Systemen für Systemdiagnosen zulässt (130.211.0.0/22 und 35.191.0.0/16). Dieses Beispiel verwendet das Zieltag allow-health-check, um die Instanzen zu identifizieren, auf die es angewendet werden soll.

Ohne diese Firewallregeln blockiert die vorkonfigurierte Regel zum Ablehnen von eingehendem Traffic den eingehenden Datenverkehr zu den Back-End-Instanzen.

Konsole

  1. Rufen Sie in der Google Cloud Platform Console die Seite "Firewallregeln" auf.
    Zur Seite "Firewallregeln"
  2. Klicken Sie auf Firewallregel erstellen und geben Sie die folgenden Informationen ein, um die Regel für Subnetz-Traffic zu erstellen:
    • Name: fw-allow-lb-subnet
    • Netzwerk: lb-network
    • Priorität: 1000
    • Traffic-Richtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Alle Instanzen im Netzwerk
    • Quellfilter: IP ranges
    • Quell-IP-Bereiche: 10.1.2.0/24
    • Protokolle und Ports: Alle zulassen
  3. Klicken Sie auf Erstellen.
  4. Klicken Sie noch einmal auf Firewallregel erstellen, um die Regel zu erstellen, die eingehende SSH-Verbindungen zulässt:
    • Name: fw-allow-ssh
    • Netzwerk: lb-network
    • Priorität: 1000
    • Traffic-Richtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Angegebene Zieltags
    • Ziel-Tags: allow-ssh
    • Quellfilter: IP ranges
    • Quell-IP-Bereiche: 0.0.0.0/0
    • Protokolle und Ports: Wählen Sie Angegebene Protokolle und Ports aus und geben Sie dann Folgendes ein: tcp:22
  5. Klicken Sie auf Erstellen.
  6. Klicken Sie ein drittes Mal auf Firewallregel erstellen, um die Regel zu erstellen, die GCP-Systemdiagnosen zulässt:
    • Name: fw-allow-health-check
    • Netzwerk: lb-network
    • Priorität: 1000
    • Traffic-Richtung: Eingehend
    • Aktion bei Übereinstimmung: Zulassen
    • Ziele: Angegebene Zieltags
    • Ziel-Tags: allow-health-check
    • Quellfilter: IP ranges
    • Quell-IP-Bereiche: 130.211.0.0/22 und 35.191.0.0/16
    • Protokolle und Ports: Alle zulassen
  7. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie die Firewallregel fw-allow-lb-subnet, um die Kommunikation mit dem Subnetz zuzulassen:

    gcloud compute firewall-rules create fw-allow-lb-subnet \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.1.2.0/24 \
    --rules=tcp,udp,icmp

  2. Erstellen Sie die Firewallregel fw-allow-ssh, die SSH-Verbindungen zu VMs mit dem Netzwerktag allow-ssh zulässt. Wenn Sie source-ranges auslassen, interpretiert die GCP die Regel als jede Quelle.

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

  3. Erstellen Sie die Regel fw-allow-health-check, um GCP-Systemdiagnosen zuzulassen.

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

API

Erstellen Sie die Firewallregel fw-allow-lb-subnet. Stellen Sie dazu eine POST-Anfrage an die Methode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
  "name": "fw-allow-lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "10.1.2.0/24"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS",
  "logConfig": {
    "enable": false
  },
  "disabled": false
}

Erstellen Sie die Firewallregel fw-allow-ssh. Stellen Sie dazu eine POST-Anfrage an die Methode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
  "name": "fw-allow-ssh",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

Erstellen Sie die Firewallregel fw-allow-health-check. Stellen Sie dazu eine POST-Anfrage an die Methode firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
  "name": "fw-allow-health-check",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "allow-health-check"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS",
  "logConfig": {
    "enable": false
  },
  "disabled": false
}

Back-End-VMs und Instanzgruppen erstellen

Dieses Beispiel verwendet zwei nicht verwaltete Instanzgruppen mit jeweils zwei Back-End-VMs (Server). Die beiden Instanzgruppen befinden sich dabei in den separaten Zonen us-west1-a und us-west1-c, um den regionalen Charakter des internen TCP/UDP-Load-Balancing zu veranschaulichen.

  • Die Instanzgruppe ig-a enthält diese beiden VMs:
    • vm-a1
    • vm-a2
  • Die Instanzgruppe ig-c enthält diese beiden VMs:
    • vm-c1
    • vm-c2

Auf den Traffic zu allen vier Back-End-VMs wird Load-Balancing angewendet. Jede der vier VMs führt einen Apache-Webserver auf den TCP-Ports 80 und 443 aus. Jedem dieser Server ist dabei eine interne IP-Adresse im lb-subnet und eine sitzungsspezifische externe (öffentliche) IP-Adresse zugewiesen. Sie können die externen IP-Adressen später entfernen.

Externe IP-Adressen für die Back-End-VMs sind nicht erforderlich. In diesem Beispiel sind sie aber praktisch, weil die Back-End-VMs auf diese Weise Apache aus dem Internet herunterladen können. Außerdem vereinfachen sie die Verbindung über SSH.

Apache ist standardmäßig für die Bindung an eine beliebige IP-Adresse konfiguriert. Interne TCP/UDP-Load-Balancer liefern Pakete und behalten die Ziel-IP dabei bei. Stellen Sie deshalb sicher, dass die auf den Back-End-VMs ausgeführte Serversoftware die IP-Adresse der internen Weiterleitungsregel des Load-Balancers überwacht. Wenn Sie mehrere interne Weiterleitungsregeln konfigurieren, achten Sie darauf, dass die Software die jeweils zugewiesene interne IP-Adresse überwacht. Die Ziel-IP-Adresse eines Pakets, das ein interner TCP/UDP-Load-Balancer an eine Back-End-VM liefert, ist die interne IP-Adresse der Weiterleitungsregel.

Zur Vereinfachung der Anleitung führen diese Back-End-VMs Debian GNU/Linux 9 aus.

Konsole

Backend-VMs erstellen

  1. Rufen Sie in der Google Cloud Platform Console die Seite "VM-Instanzen" auf.
    Zur Seite "VM-Instanzen"
  2. Wiederholen Sie die nachstehenden Schritte, um vier VMs mit den folgenden Namen- und Zonenkombinationen zu erstellen.
    • Name: vm-a1, Zone: us-west1-a
    • Name: vm-a2, Zone: us-west1-a
    • Name: vm-c1, Zone: us-west1-c
    • Name: vm-c2, Zone: us-west1-c
  3. Klicken Sie auf Instanz erstellen.
  4. Legen Sie den Namen wie in Schritt 2 angegeben fest.
  5. Wählen Sie us-west1 für die Region aus und legen die Zone wie in Schritt 2 angegeben fest.
  6. Überprüfen Sie im Bereich Bootlaufwerk, ob das ausgewählte Image Debian GNU/Linux 9 Stretch ist. Klicken Sie auf Auswählen, um das Image bei Bedarf zu ändern.

  7. Klicken Sie auf Verwaltung, Sicherheit, Laufwerke, Netzwerke, einzelne Mandanten und nehmen Sie die folgenden Änderungen vor:

    • Klicken Sie auf Netzwerk und fügen Sie die folgenden Netzwerktags hinzu: allow-ssh und allow-health-check.
    • Klicken Sie dann unter Netzwerkschnittstellen auf die Schaltfläche "Bearbeiten", nehmen Sie die folgenden Änderungen vor und klicken Sie dann auf Fertig:
      • Netzwerk: lb-network
      • Subnetz: lb-subnet
      • Primäre interne IP: sitzungsspezifisch (automatisch)
      • Externe IP: sitzungsspezifisch

    • Klicken Sie auf Management. Kopieren Sie im Feld Startskript den folgenden Skriptinhalt und fügen Sie ihn ein: Der Skriptinhalt ist für alle vier VMs gleich:

      #! /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

  8. Klicken Sie auf Erstellen.

Instanzgruppen erstellen

  1. Gehen Sie in der Google Cloud Platform Console zur Seite "Instanzgruppen".
    Zur Seite "Instanzgruppen"
  2. Wiederholen Sie die folgenden Schritte, um mit diesen Kombinationen zwei nicht verwaltete Instanzgruppen mit jeweils zwei VMs zu erstellen.
    • Instanzgruppe: ig-a, Zone: us-west1-a, VMs: vm-a1 und vm-a2
    • Instanzgruppe: ig-c, Zone: us-west1-c, VMs: vm-c1 und vm-c2
  3. Klicken Sie auf Instanzgruppe erstellen.
  4. Legen Sie den Namen wie in Schritt 2 angegeben fest.
  5. Wählen Sie im Bereich Standort die Option Einzelne Zone aus, legen Sie die Region us-west1 fest und wählen Sie dann eine Zone aus, wie in Schritt 2 angegeben.
  6. Wählen Sie nun im Bereich Gruppentyp die Option Nicht verwaltete Instanzgruppe aus.
  7. Geben Sie bei Netzwerk den Parameter lb-network ein.
  8. Geben Sie dann bei Subnetzwerk den Parameter lb-subnet ein.
  9. Fügen Sie im Bereich VM-Instanzen die in Schritt 2 angegebenen VMs hinzu.
  10. Klicken Sie auf Erstellen.

gcloud

  1. Zum Erstellen der vier VMs führen Sie den folgenden Befehl viermal mit den nachstehenden vier Kombinationen für [VM-NAME] und [ZONE] aus. Der Skriptinhalt ist für alle vier VMs identisch.

    • [VM-NAME] mit vm-a1 und [ZONE] mit us-west1-a
    • [VM-NAME] mit vm-a2 und [ZONE] mit us-west1-a
    • [VM-NAME] mit vm-c1 und [ZONE] mit us-west1-c
    • [VM-NAME] mit vm-c2 und [ZONE] mit us-west1-c
    gcloud compute instances create [VM-NAME] \
    --zone=[ZONE] \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'

  2. Erstellen Sie die zwei nicht verwalteten Instanzgruppen in jeder Zone:

    gcloud compute instance-groups unmanaged create ig-a \
    --zone=us-west1-a
gcloud compute instance-groups unmanaged create ig-c \
    --zone=us-west1-c

  3. Fügen Sie den entsprechenden Instanzgruppen die VMs hinzu:

    gcloud compute instance-groups unmanaged add-instances ig-a \
    --zone=us-west1-a \
    --instances=vm-a1,vm-a2
gcloud compute instance-groups unmanaged add-instances ig-c \
    --zone=us-west1-c \
    --instances=vm-c1,vm-c2

API

Verwenden Sie für die vier VMs die folgenden VM-Namen und -Zonen:

  • [VM-NAME] mit vm-a1 und [ZONE] mit us-west1-a
  • [VM-NAME] mit vm-a2 und [ZONE] mit us-west1-a
  • [VM-NAME] mit vm-c1 und [ZONE] mit us-west1-c
  • [VM-NAME] mit vm-c2 und [ZONE] mit us-west1-c

Erstellen Sie jetzt vier Back-End-VMs. Stellen Sie dazu vier POST-Anfragen an die Methode instances.insert:

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances
{
  "name": "[VM-NAME]",
  "tags": {
    "items": [
      "allow-health-check",
      "allow-ssh"
    ]
  },
  "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/n1-standard-1",
  "canIpForward": false,
  "networkInterfaces": [
    {
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
      "accessConfigs": [
        {
          "type": "ONE_TO_ONE_NAT",
          "name": "external-nat",
          "networkTier": "PREMIUM"
        }
      ]
    }
  ],
  "disks": [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "autoDelete": true,
      "deviceName": "[VM-NAME]",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
        "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ]
  "metadata": {
    "items": [
      {
        "key": "startup-script",
        "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
      }
    ]
  },
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Erstellen Sie nun zwei Instanzgruppen. Stellen Sie dazu eine POST-Anfrage an die Methode instanceGroups.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups
{
  "name": "ig-a",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
}

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups
{
  "name": "ig-c",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
}

Fügen Sie jeder Instanzgruppe Instanzen hinzu. Stellen Sie dazu eine POST-Anfrage an die Methode instanceGroups.addInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a/addInstances
{
  "instances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a1",
      "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a2"
    }
  ]
}

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c/addInstances
{
  "instances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c1",
      "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c2"
    }
  ]
}

Client-VM erstellen

Dieses Beispiel erstellt eine Client-VM (vm-client), die sich in derselben Region wie die Back-End-VMs (Server) befindet. Der Client validiert die Konfiguration des Load-Balancers und demonstriert das erwartete Verhalten, wie im Abschnitt "Test" beschrieben.

Konsole

  1. Rufen Sie in der Google Cloud Platform Console die Seite "VM-Instanzen" auf.
    Zur Seite "VM-Instanzen"
  2. Klicken Sie auf Instanz erstellen.
  3. Setzen Sie den Namen auf vm-client.
  4. Setzen Sie dann die Zone auf us-west1-a.
  5. Klicken Sie auf Verwaltung, Sicherheit, Laufwerke, Netzwerke, einzelne Mandanten und nehmen Sie die folgenden Änderungen vor:
    • Klicken Sie auf Netzwerk und fügen Sie den Netzwerk-Tags den Parameter allow-ssh hinzu.
    • Klicken Sie dann unter Netzwerkschnittstellen auf die Schaltfläche "Bearbeiten", nehmen Sie die folgenden Änderungen vor und klicken Sie dann auf Fertig:
      • Netzwerk: lb-network
      • Subnetz: lb-subnet
      • Primäre interne IP: sitzungsspezifisch (automatisch)
      • Externe IP: sitzungsspezifisch
  6. Klicken Sie auf Erstellen.

gcloud

Die Client-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 der Client in der Zone us-west1-a und verwendet dasselbe Subnetz wie die Back-End-VMs.

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

API

Stellen Sie eine POST-Anfrage an die Methode instances.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances
{
  "name": "vm-client",
  "tags": {
    "items": [
      "allow-ssh"
    ]
  },
  "machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/machineTypes/n1-standard-1",
  "canIpForward": false,
  "networkInterfaces": [
    {
      "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
      "accessConfigs": [
        {
          "type": "ONE_TO_ONE_NAT",
          "name": "external-nat",
          "networkTier": "PREMIUM"
        }
      ]
    }
  ],
  "disks": [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "autoDelete": true,
      "deviceName": "[VM-NAME]",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
        "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ]
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Komponenten für den Load-Balancer konfigurieren

In diesen Schritten konfigurieren Sie alle Komponenten für den internen TCP/UDP-Load-Balancer. Zuerst konfigurieren Sie die Systemdiagnose und den Back-End-Dienst und danach die Front-End-Komponenten:

  • Systemdiagnose: Dieses Beispiel verwendet eine HTTP-Systemdiagnose, die lediglich auf die HTTP-Antwort 200 (OK) prüft. Weitere Informationen finden Sie im Abschnitt "Systemdiagnosen" der Übersicht über das interne TCP/UDP-Load-Balancing.

  • Back-End-Dienst: Da der HTTP-Traffic über den internen Load-Balancer weitergeleitet werden muss, müssen Sie TCP und nicht UDP verwenden.

  • Weiterleitungsregel: Dieses Beispiel erstellt eine einzelne interne Weiterleitungsregel.

  • Interne IP-Adresse: In diesem Beispiel wird bei der Erstellung der Weiterleitungsregel eine interne IP-Adresse (10.1.2.99) festgelegt.

Konsole

Load-Balancer erstellen und Back-End-Dienst konfigurieren

  1. Rufen Sie in der Google Cloud Platform Console die Seite "Load-Balancing" auf.
    Zur Seite "Load-Balancing"
  2. Klicken Sie auf Load-Balancer erstellen.
  3. Klicken Sie unter TCP-Load-Balancing auf Konfiguration starten.
  4. Wählen Sie unter Internet oder nur intern die Option Nur zwischen meinen VMs aus.
  5. Klicken Sie auf Weiter.
  6. Setzen Sie den Namen auf be-ilb.
  7. Klicken Sie auf Back-End-Konfiguration und nehmen Sie folgende Änderungen vor:
    1. Region: us-west1
    2. Netzwerk: lb-network
    3. Wählen Sie im Bereich Neues Element unter Back-Ends die Instanzgruppe ig-a aus und klicken Sie dann auf Fertig.
    4. Klicken Sie auf Back-End hinzufügen. Wählen Sie im angezeigten Bereich Neues Element die Instanzgruppe ig-c aus und klicken Sie noch einmal auf Fertig.
    5. Wählen Sie unter Systemdiagnose die Option Weitere Systemdiagnose erstellen aus, geben Sie die folgenden Informationen ein und klicken Sie dann auf Speichern und fortfahren:
      • Name: hc-http-80
      • Protokoll: HTTP
      • Port: 80
      • Proxy-Protokoll: NONE
      • Anfrage-Pfad: /
    6. Überprüfen Sie, bevor Sie fortfahren, ob sich neben der Back-End-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt insgesamt noch einmal durch, wenn nicht.
  8. Klicken Sie auf Front-End-Konfiguration. Nehmen Sie im Bereich Neue(r) Front-End-IP und -Port die folgenden Änderungen vor:
    1. Name: fr-ilb
    2. Subnetz: ilb-subnet
    3. Wählen Sie unter Interne IP 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.1.2.99
    4. Ports: Wählen Sie Einzeln aus und geben Sie als Portnummer 80 ein.
    5. Überprüfen Sie, bevor Sie fortfahren, ob sich neben der Front-End-Konfiguration ein blaues Häkchen befindet. Gehen Sie diesen Schritt insgesamt noch einmal durch, wenn nicht.
  9. Klicken Sie auf Überprüfen und abschließen. Kontrollieren Sie die Einstellungen.
  10. Klicken Sie auf Erstellen.

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 \
    --port=80

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

    gcloud compute backend-services create be-ilb \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west1 \
    --health-checks=hc-http-80

  3. Fügen Sie dem Back-End-Dienst die beiden Instanzgruppen hinzu:

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-a \
    --instance-group-zone=us-west1-a
gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-c \
    --instance-group-zone=us-west1-c

  4. Erstellen Sie eine Weiterleitungsregel für den Back-End-Dienst. Geben Sie dabei im Subnetz die interne IP 10.1.2.99 an.

    gcloud compute forwarding-rules create fr-ilb \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

API

Erstellen Sie die Systemdiagnose. Stellen Sie dazu eine POST-Anfrage an die Methode healthChecks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
{
  "name": "hc-http-80",
  "type": "HTTP",
  "httpHealthCheck": {
    "port": 80
  }
}

Erstellen Sie den regionalen Back-End-Dienst. Stellen Sie dazu eine POST-Anfrage an die Methode regionBackendServices.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices
{
  "name": "be-ilb",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a",
      "balancingMode": "CONNECTION"
    }
    {
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c",
      "balancingMode": "CONNECTION"
    }
  ],
  "healthChecks": [
    "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/hc-http-80"
  ],
  "loadBalancingScheme": "INTERNAL",
  "connectionDraining": {
    "drainingTimeoutSec": 0
  }
}

Erstellen Sie die Weiterleitungsregel. Stellen Sie dazu eine POST-Anfrage an die Methode forwardingRules.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules
{
  "name": "fr-ilb",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "ports": [
    "80"
  ],
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "backendService": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb",
  "networkTier": "PREMIUM"
}

Test

Diese Tests zeigen Ihnen, wie Sie die Konfiguration des Load-Balancers validieren und das erwartete Verhalten ermitteln können.

Load-Balancing testen

Dieser Test nimmt von einer separaten Client-VM Verbindung mit dem Load-Balancer auf, also nicht von einer Back-End-VM des Load-Balancers. Dabei wird folgendes Verhalten erwartet: Der Traffic wird zwischen den vier Back-End-VMs verteilt, da keine Sitzungsaffinität konfiguriert wurde.

  1. Stellen Sie eine Verbindung zur Client-VM-Instanz her.

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

  2. Stellen Sie mit curl eine Webanfrage an den Load-Balancer, um dessen IP-Adresse zu kontaktieren. Wiederholen Sie die Anfrage. So können Sie sehen, dass Antworten von verschiedenen Back-End-VMs stammen. Der Name der VM, die die Antwort generiert, wird aufgrund des Inhalts von /var/www/html/index.html auf jeder Back-End-VM im Text der HTML-Antwort angezeigt. Die erwarteten Antworten ähneln den Folgenden: Page served from: vm-a1, Page served from: vm-a2 und so weiter.

    curl http://10.1.2.99

    • Wenn Sie der internen Weiterleitungsregel ein Dienstlabel hinzufügen, können Sie mithilfe des internen DNS den Load-Balancer kontaktieren. Verwenden Sie dazu dessen Dienstnamen.

      curl http://web-test.fr-ilb.il4.us-west1.lb.[PROJECT_ID].internal

IP-Adresse des Load-Balancers per Ping kontaktieren

Dieser Test zeigt ein erwartetes Verhalten: Sie können die IP-Adresse des Load-Balancers nicht per Ping kontaktieren. Dies liegt daran, dass interne TCP/UDP-Load-Balancer in die virtuelle Netzwerkprogrammierung implementiert sind – sie sind keine separaten Geräte.

  1. Stellen Sie eine Verbindung zur Client-VM-Instanz her.

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

  2. Versuchen Sie, die IP-Adresse des Load-Balancers per Ping zu kontaktieren. Beachten Sie, dass Sie keine Antwort erhalten und der ping-Befehl in diesem Beispiel nach 10 Sekunden abläuft.

    timeout 10 ping 10.1.2.99

Anfragen von VMs mit Load-Balancing senden

Dieser Test zeigt, dass Anfragen an den Load-Balancer, die von einer der Back-End-VMs, also den Server-VMs mit Load-Balancing, stammen, immer von derselben VM beantwortet werden, von der die Anfrage stammt.

Das interne TCP/UDP-Load-Balancing wird mithilfe von virtueller Netzwerkprogrammierung und VM-Konfiguration im Gastbetriebssystem implementiert. Auf Linux-VMs führt die Linux-Gastumgebung die lokale Konfiguration durch. Dazu installiert sie eine Route in der Routingtabelle des Gastbetriebssystems. Durch diese lokale Route bleibt der Traffic zur IP-Adresse des Load-Balancers in der VM mit Load-Balancing selbst. (Diese lokale Route unterscheidet sich von den Routen im VPC-Netzwerk.)

  1. Stellen Sie eine Verbindung zur einer Backend-VM wie vm-a1 her:

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

  2. Stellen Sie mit curl eine Webanfrage an den Load-Balancer (nach IP-Adresse oder Dienstname). Wiederholen Sie die Anfrage. Die Antwort wird von der Back-End-VM gesendet, von der die Anfrage stammt. Die erwartete Antwort beim Testen von vm-a1 lautet immer: Page served from: vm-a1.

    curl http://10.1.2.99

  3. Überprüfen Sie die lokale Routingtabelle und suchen Sie nach einem Ziel, das mit der IP-Adresse des Load-Balancers selbst übereinstimmt: 10.1.2.99. Diese Route ist notwendiger Bestandteil des internen TCP/UDP-Load-Balancings. Zugleich zeigt sie, warum eine Anfrage von einer VM hinter dem Load-Balancer immer von derselben VM beantwortet wird.

    ip route show table local | grep 10.1.2.99

Zusätzliche Konfigurationsoptionen

Dieser Abschnitt erweitert die Konfiguration aus dem Beispiel um alternative und zusätzliche Optionen. Alle Aufgaben sind optional. Sie können sie in beliebiger Reihenfolge durchführen.

Verwaltete Instanzgruppen konfigurieren

In der Beispielkonfiguration wurden zwei nicht verwaltete Instanzgruppen erstellt. Sie können stattdessen auch verwaltete Instanzgruppen, dazu gehören auch zonale und regionale verwaltete Instanzgruppen, als Back-Ends für das interne TCP/UDP-Load-Balancing verwenden.

Für verwaltete Instanzgruppen müssen Sie eine Instanzvorlage erstellen. Dieses Verfahren zeigt Ihnen, wie Sie die beiden nicht verwalteten zonalen Instanzgruppen aus dem Beispiel durch eine einzelne, regional verwaltete Instanzgruppe ersetzen. Eine regional verwaltete Instanzgruppe erstellt automatisch VMs in mehreren Zonen der Region. Das vereinfacht die Verteilung des Produktionstraffics auf die Zonen.

Verwaltete Instanzgruppen unterstützen auch Autoscaling und die automatische Reparatur. Wenn Sie Autoscaling mit internem TCP/UDP-Load-Balancing verwenden, können Sie keine Skalierung anhand von Load-Balancing durchführen.

Dieses Verfahren zeigt Ihnen, wie Sie den Back-End-Dienst für das interne TCP/UDP-Load-Balancing des Beispiels so ändern, dass er eine regional verwaltete Instanzgruppe verwendet.

Konsole

Instanzvorlage

  1. Rufen Sie in der Google Cloud Platform Console die Seite "VM-Instanzvorlagen" auf.
    Zur Seite "VM-Instanzvorlagen"
  2. Klicken Sie auf Instanzvorlage erstellen.
  3. Setzen Sie den Namen auf template-vm-ilb.
  4. Wählen Sie einen Maschinentyp aus.
  5. Zum Einstellen des Bootlaufwerks klicken Sie auf Ändern, wählen Sie Debian GNU/Linux 9 Stretch aus, und klicken Sie dann auf Auswählen.
  6. Klicken Sie auf Verwaltung, Sicherheit, Laufwerke, Netzwerke, einzelne Mandanten.
    • Klicken Sie auf Netzwerk und nehmen Sie die folgenden Änderungen vor:
      • Netzwerk: lb-network
      • Subnetz: lb-subnet
      • Netzwerk-Tags: allow-ssh und allow-health-check
    • Klicken Sie auf Management. Kopieren Sie im Feld Startskript den folgenden Skriptinhalt und fügen Sie ihn 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.

Verwaltete Instanzgruppe

  1. Rufen Sie in der Google Cloud Platform Console die Seite "VM-Instanzen" auf.
    Zur Seite "VM-Instanzgruppen"
  2. Klicken Sie auf Instanzgruppe erstellen.
  3. Setzen Sie den Namen auf ig-ilb.
  4. Wählen Sie als Standort die Option Mehrere Zonen aus und setzen Sie die Region auf us-west1.
  5. Setzen Sie die Instanzvorlage auf template-vm-ilb.
  6. (Optional) Konfigurieren Sie das Autoscaling. Sie können die Instanzgruppe nicht auf Basis der Verwendung von HTTP-Load-Balancing automatisch skalieren, da die Instanzgruppe ein Back-End für das interne TCP/UDP-Load-Balancing ist.
  7. Setzen Sie die Mindestanzahl von Instanzen auf 1 und die maximale Anzahl von Instanzen auf 6.
  8. (Optional) Konfigurieren Sie die automatische Reparatur. Wenn Sie die automatische Reparatur konfigurieren, verwenden Sie dieselbe Systemdiagnose, die der Back-End-Dienst für das interne TCP/UDP-Load-Balancing verwendet. Verwenden Sie in diesem Beispiel hc-http-80.
  9. Klicken Sie auf Erstellen.

gcloud

  1. Erstellen Sie die Instanzvorlage. Optional können Sie für die zu verwendende Imagevorlage andere Parameter festlegen wie den Maschinentyp.

    gcloud compute instance-templates create template-vm-ilb \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --region=us-west1 \
    --network=lb-network \
    --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'

  2. Erstellen Sie eine regional verwaltete Instanzgruppe mit der Vorlage:

    gcloud compute instance-groups managed create ig-ilb \
    --template=template-vm-ilb \
    --region=us-west1 \
    --size=6

  3. Fügen Sie dem bereits erstellten Back-End-Dienst die regional verwaltete Instanzgruppe als Back-End hinzu:

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-ilb \
    --instance-group-region=us-west1

  4. Trennen Sie die Verbindung der beiden nicht verwalteten (zonalen) Instanzgruppen zum Back-End-Dienst:

    gcloud compute backend-services remove-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-a \
    --instance-group-zone=us-west1-a
gcloud compute backend-services remove-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-c \
    --instance-group-zone=us-west1-c

Externe IP-Adressen aus Backend-VMs entfernen

Bei der Erstellung der Backend-VMs wurde jeder eine sitzungsspezifische externe IP-Adresse zugewiesen, damit über ein Startskript Apache heruntergeladen werden konnte. Da die Back-End-VMs nur von einem internen Load-Balancer verwendet werden, können Sie deren externe IP-Adressen entfernen. Dadurch wird verhindert, dass die Back-End-VMs direkt auf das Internet zugreifen.

Konsole

  1. Rufen Sie in der Google Cloud Platform Console die Seite "VM-Instanzen" auf.
    Zur Seite "VM-Instanzen"
  2. Wiederholen Sie die folgenden Schritte für jede Back-End-VM.
  3. Klicken Sie auf den Namen der Back-End-VM, zum Beispiel vm-a1, um die Seite VM-Instanzdetails anzuzeigen.
  4. Klicken Sie auf Bearbeiten.
  5. Klicken Sie im Bereich Netzwerkschnittstellen auf die Schaltfläche Bearbeiten.
  6. Wählen Sie im Pop-up-Fenster Externe IP die Option Keine aus und klicken Sie dann auf Fertig.
  7. Klicken Sie auf Speichern.

gcloud

  1. Wenn Sie die Zone einer Instanz, z. B. bei einer regionalen verwalteten Instanzgruppe, ermitteln möchten, führen Sie für jede Instanz den folgenden Befehl aus. Ersetzen Sie [SERVER-VM] durch den Namen der VM, die Sie aufrufen möchten.

    gcloud compute instances list --filter="name=[SERVER-VM]"

  2. Wiederholen Sie den folgenden Schritt für jede Back-End-VM. Ersetzen Sie dabei [SERVER-VM] durch den Namen der VM und [ZONE] durch die Zone der VM.

    gcloud compute instances delete-access-config [SERVER-VM] \
    --zone=[ZONE] \
    --access-config-name=external-nat

API

Stellen Sie für jede Back-End-VM eine POST-Anfrage an die Methode instances.deleteAccessConfig. Ersetzen Sie dabei vm-a1 durch den Namen der VM und us-west1-a durch die Zone der VM.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/v1-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None

Traffic auf mehreren Ports akzeptieren

Die interne Weiterleitungsregel ist die Komponente, die den Port für eingehenden Traffic steuert. Dieses Verfahren zeigt Ihnen, wie Sie die Weiterleitungsregel für Port 80 durch eine ersetzen, die Traffic auf den Ports 80 und 443 akzeptiert. Beim Erstellen der Back-End-VMs installiert und konfiguriert das Startskript Apache und stellt dabei auch ein, dass HTTPS-Traffic auf Port 443 weitergeleitet wird. Sie müssen eine Weiterleitungsregel ersetzen, da die GCP Weiterleitungsregeln nicht aktualisiert.

gcloud

  1. Löschen Sie die vorhandene Weiterleitungsregel fr-ilb.

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

  2. Erstellen Sie eine Weiterleitungsregel zum Ersetzen der vorhandenen. Verwenden Sie dabei für die Ports 80 und 443 denselben Namen. Die anderen Parameter für diese Regel, einschließlich IP-Adresse und Back-End-Dienst, sind identisch.

    gcloud compute forwarding-rules create fr-ilb \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=80,443 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

  3. Stellen Sie eine Verbindung zur Client-VM-Instanz her und testen Sie HTTP- und HTTPS-Verbindungen.

    • Stellen Sie eine Verbindung zur Client-VM her:

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

    • Testen Sie die HTTP-Konnektivität:

      curl http://10.1.2.99

    • Testen Sie die HTTPS-Konnektivität. Das Flag --insecure ist erforderlich, da die Apache-Serverkonfiguration im Beispielsetup selbstsignierte Zertifikate verwendet.

      curl https://10.1.2.99 --insecure

    • Beachten Sie, dass HTTP-Anfragen (an Port 80) und HTTPS-Anfragen (an Port 443) von allen Back-End-VMs verarbeitet werden.

Sitzungsaffinität verwenden

Die Beispielkonfiguration erstellt einen Back-End-Dienst ohne Sitzungsaffinität.

Dieses Verfahren zeigt Ihnen, wie Sie den Back-End-Dienst für den internen TCP/UDP-Load-Balancer aus dem Beispiel so aktualisieren, dass er Sitzungsaffinität auf Basis von Client-IP-Adressen verwendet.

Der Load Balancer leitet die Anfragen eines bestimmten Clients anhand von einem Hash an dieselbe Back-End-VM weiter. Der Hash wird dabei aus der IP-Adresse des Clients und der IP-Adresse des Load-Balancers (der internen IP-Adresse einer internen Weiterleitungsregel) erstellt.

Konsole

  1. Rufen Sie in der Google Cloud Platform Console die Seite "Load-Balancing" auf.
    Zur Seite "Load-Balancing"
  2. Klicken Sie auf be-ilb. Das ist der Name des für dieses Beispiel erstellten Back-End-Dienstes. Klicken Sie dann auf Bearbeiten.
  3. Klicken Sie auf der Seite Internen Load-Balancer bearbeiten auf Back-End-Konfiguration.
  4. Wählen Sie aus dem Pop-up-Menü Sitzungsaffinität die Option Client-IP aus.
  5. Klicken Sie auf Aktualisieren.

gcloud

Aktualisieren Sie den Back-End-Dienst be-ilb mit dem folgenden gcloud-Befehl. Geben Sie dabei die Sitzungsaffinität der Client-IP an:

gcloud compute backend-services update be-ilb \
    --session-affinity CLIENT_IP

API

Stellen Sie eine PATCH-Anfrage an die Methode regionBackendServices/patch.

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb
{
  "sessionAffinity": "CLIENT_IP"
}

Weitere Informationen zum Verwenden der Sitzungsaffinität, um die Verteilung von Traffic zu beeinflussen, sowie eine Beschreibung der einzelnen Optionen finden Sie unter Trafficverteilung.

Weiterleitungsregel in einem anderen Subnetz erstellen

Dieses Verfahren erstellt eine zweite IP-Adresse und Weiterleitungsregel in einem anderen Subnetz. Dies dient dazu, Ihnen zu zeigen, dass Sie für einen internen TCP/UDP-Load-Balancer mehrere Weiterleitungsregeln erstellen können. Die Region für die Weiterleitungsregel muss dabei mit der Region des Back-End-Dienstes übereinstimmen.

Je nach Firewallregeln können Clients in jedem Subnetz in der Region eine der internen IP-Adressen des TCP/UDP-Load-Balancers kontaktieren.

  1. Erstellen Sie im Netzwerk lb-network in der Region us-west1 ein zweites Subnetz:

    gcloud compute networks subnets create second-subnet \
    --network=lb-network \
    --range=10.5.6.0/24 \
    --region=us-west1

  2. Erstellen Sie eine zweite Weiterleitungsregel für die Ports 80 und 443. Die anderen Parameter für diese Regel, einschließlich IP-Adresse und Back-End-Dienst, sind dieselben wie für die primäre Weiterleitungsregel fr-ilb.

    gcloud compute forwarding-rules create fr-ilb-2 \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=second-subnet \
    --address=10.5.6.99 \
    --ip-protocol=TCP \
    --ports=80,443 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

  3. Stellen Sie eine Verbindung zur Client-VM-Instanz her und testen Sie HTTP- und HTTPS-Verbindungen zu den IP-Adressen.

    • Stellen Sie eine Verbindung zur Client-VM her:
    gcloud compute ssh vm-client --zone=us-west1-a
    • Testen Sie die HTTP-Konnektivität zu den IP-Adressen:
    curl http://10.1.2.99
curl http://10.5.6.99
    • Testen Sie die HTTPS-Konnektivität. Die Verwendung von --insecure ist erforderlich, da die Apache-Serverkonfiguration im Beispielsetup selbstsignierte Zertifikate verwendet.
    curl https://10.1.2.99 --insecure
curl https://10.5.6.99 --insecure
    • Beachten Sie, dass Anfragen von allen Back-End-VMs verarbeitet werden, unabhängig vom verwendeten Protokoll (HTTP oder HTTPS) oder der verwendeten IP-Adresse.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

dieser Seite
Feedback zur Dokumentation
Load-Balancing
Feedback zum Produkt