1. Einführung
In dieser Anleitung wird beschrieben, wie Sie einen vorhandenen Netzwerk-Load-Balancer von einem Zielpool-Backend auf einen regionalen Backend-Dienst umstellen.
Aufgaben in diesem Lab
- Vorteile regionaler Back-End-Dienste
- Netzwerk-Load-Balancer mit Zielpools erstellen
- Zielpool-Validierung durchführen
- Regionalen Backend-Dienst mit nicht verwalteten Instanzgruppen erstellen
- Migration von Zielpool zu Backend-Dienst ausführen
- Validierung der Backend-Dienste durchführen
Voraussetzungen
- Erfahrung mit Load-Balancern
2. Regionale Back-End-Dienste für Netzwerk-Load-Balancing – Übersicht
Google Cloud-Kunden haben dank Netzwerk-Load-Balancing ein leistungsstarkes Tool für die Verteilung von externem Traffic zwischen virtuellen Maschinen in einer Google Cloud-Region. Um unseren Kunden die Verwaltung des eingehenden Traffics zu erleichtern und das Verhalten des Load-Balancers zu steuern, unterstützen wir seit Kurzem Back-End-Dienste für das Netzwerk-Load-Balancing. So profitieren unsere Kunden von einer verbesserten Skalierung, Geschwindigkeit, Leistung und Ausfallsicherheit bei der Bereitstellung – und das alles auf einfache Weise.
Ab sofort unterstützen wir Back-End-Dienste mit Netzwerk-Load-Balancing – eine deutliche Verbesserung gegenüber dem bisherigen Ansatz, Zielpools. Ein Back-End-Dienst definiert, wie unsere Load-Balancer eingehenden Traffic auf angehängte Back-Ends verteilen und bietet detaillierte Kontrolle über das Verhalten des Load-Balancers.
3. Vorteile regionaler Backend-Dienste
Die Auswahl eines regionalen Back-End-Dienstes als Load-Balancer bringt eine Reihe von Vorteilen für Ihre Umgebung mit sich.
Regionale Back-End-Dienste bieten von Anfang an Folgendes:
- Zuverlässige Systemdiagnose mit einheitlichen Systemdiagnosen: Mit regionalen Back-End-Diensten können Sie jetzt die Load-Balancing-Funktionen für Systemdiagnosen in vollem Umfang nutzen, ohne Einschränkungen durch Legacy-HTTP-Systemdiagnosen zu vermeiden. Aus Compliancegründen waren TCP-Systemdiagnosen mit Unterstützung für benutzerdefinierte Anfrage- und Antwortstrings oder HTTPS eine häufige Anfrage von Netzwerk-Load-Balancing-Kunden.
- Bessere Ausfallsicherheit mit Failover-Gruppen: Mit Failover-Gruppen können Sie eine Instanzgruppe als primäre und eine andere als sekundäre Gruppe festlegen und den Traffic Failover ausführen, wenn die Integrität der Instanzen in der aktiven Gruppe einen bestimmten Schwellenwert unterschreitet. Um mehr Kontrolle über den Failover-Mechanismus zu erhalten, können Sie einen Agent wie keepaowned oder pacemaker verwenden und anhand von Statusänderungen der Back-End-Instanz eine fehlerfreie oder fehlerhafte Systemdiagnose verfügbar machen.
- Skalierbarkeit und Hochverfügbarkeit mit verwalteten Instanzgruppen: Regionale Back-End-Dienste unterstützen verwaltete Instanzgruppen als Back-Ends. Sie können jetzt eine Vorlage für Ihre Back-End-VM-Instanzen festlegen und Autoscaling auf der Grundlage der CPU-Auslastung oder anderer Monitoring-Messwerte nutzen.
Zusätzlich zu den oben genannten Funktionen können Sie den Verbindungsausgleich für das verbindungsorientierte Protokoll (TCP) und eine schnellere Programmierung bei großen Bereitstellungen nutzen.
Codelab-Netzwerktopologie
In dieser Anleitung wird beschrieben, wie Sie einen vorhandenen Netzwerk-Load-Balancer von einem Zielpool-Backend auf einen regionalen Backend-Dienst umstellen.
Durch den Wechsel zu einem regionalen Back-End-Dienst können Sie Features wie Nicht-Legacy-Systemdiagnosen (für TCP, SSL, HTTP, HTTPS und HTTP/2), verwaltete Instanzgruppen, den Verbindungsausgleich und die Failover-Richtlinie nutzen.
Dieser Leitfaden führt Sie durch die Umstellung des folgenden beispielhaften Zielpool-basierten Netzwerk-Load-Balancers auf einen regionalen Back-End-Dienst
Vorher: Netzwerk-Load-Balancing mit einem Zielpool
Die daraus resultierende Bereitstellung des auf einem Back-End-Dienst basierenden Netzwerk-Load-Balancers sieht so aus.
Nachher: Netzwerk-Load-Balancing mit einem regionalen Back-End-Dienst
In diesem Beispiel wird davon ausgegangen, dass Sie einen herkömmlichen Zielpool-basierten Netzwerk-Load-Balancer mit zwei Instanzen in der Zone us-central-1a und zwei Instanzen in der Zone us-central-1c haben.
Für eine solche Umstellung sind folgende Schritte erforderlich:
- Gruppieren Sie die Zielpool-Instanzen in Instanzgruppen. Backend-Dienste funktionieren nur mit verwalteten oder nicht verwalteten Instanzgruppen. Beachten Sie, dass es keine Begrenzung für die Anzahl von Instanzen gibt, die in einem einzelnen Zielpool platziert werden können, aber Instanzgruppen haben eine maximale Größe. Wenn Ihr Zielpool mehr als diese maximale Anzahl von Instanzen enthält, müssen Sie seine Back-Ends auf mehrere Instanzgruppen aufteilen. Wenn Ihre vorhandene Bereitstellung einen Sicherungszielpool enthält, erstellen Sie für diese Instanzen eine separate Instanzgruppe. Diese Instanzgruppe wird als Failover-Gruppe konfiguriert.
- Erstellen Sie einen regionalen Backend-Dienst. Wenn Ihre Bereitstellung einen Sicherungszielpool enthält, müssen Sie beim Erstellen des Back-End-Dienstes ein Failover-Verhältnis angeben. Diese sollte der Failover-Quote entsprechen, die zuvor für die Zielpoolbereitstellung konfiguriert wurde.
- Fügen Sie dem Back-End-Dienst Instanzgruppen hinzu, die zuvor erstellt wurden. Wenn Ihre Bereitstellung einen Sicherungszielpool enthält, markieren Sie die entsprechende Failover-Instanzgruppe mit dem Flag -failover, wenn Sie sie dem Back-End-Dienst hinzufügen.
- Konfigurieren Sie eine Weiterleitungsregel, die auf den neuen Back-End-Dienst verweist. Sie haben hier zwei Möglichkeiten:
- Empfohlen: Aktualisieren Sie die vorhandene Weiterleitungsregel, sodass sie auf den Back-End-Dienst verweist. ODER
- Erstellen Sie eine neue Weiterleitung, die auf den Back-End-Dienst verweist. Dazu müssen Sie eine neue IP-Adresse für das Front-End des Load-Balancers erstellen. Ändern Sie dann Ihre DNS-Einstellungen, um nahtlos von der IP-Adresse des alten Zielpool-basierten Load-Balancers zur neuen IP-Adresse zu wechseln.
Umgebung für das selbstbestimmte Lernen einrichten
- Melden Sie sich in der Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.
Notieren Sie sich die Projekt-ID, also den projektübergreifend nur einmal vorkommenden Namen eines Google Cloud-Projekts. Der oben angegebene Name ist bereits vergeben und kann leider nicht mehr verwendet werden. Sie wird in diesem Codelab später als PROJECT_ID bezeichnet.
- Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Google Cloud-Ressourcen nutzen zu können.
Dieses Codelab sollte ohne großen Aufwand betrieben werden. Folgen Sie der Anleitung im Abschnitt „Bereinigen“, . Hier erfahren Sie, wie Sie Ressourcen herunterfahren, damit Ihnen über dieses Tutorial hinaus keine Kosten entstehen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.
Cloud Shell starten
Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.
Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:
Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:
Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, wodurch die Netzwerkleistung und Authentifizierung erheblich verbessert werden. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.
In Cloud Shell anmelden und Projekt-ID festlegen
gcloud config list project gcloud config set project [YOUR-PROJECT-ID] Perform setting your projectID: projectid=YOUR-PROJECT-ID echo $projectid
4. VPC-Netzwerk erstellen
VPC-Netzwerk
Aus Cloud Shell
gcloud compute networks create network-lb --subnet-mode custom
Subnetz erstellen
Aus Cloud Shell
gcloud compute networks subnets create network-lb-subnet \
--network network-lb --range 10.0.0.0/24 --region us-central1
Firewallregeln erstellen
Aus Cloud Shell
gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag
Nicht verwaltete Instanzen erstellen
Erstellen Sie Instanzen 2 Instanzen pro Zone, us-central1-a und us-central1-c
In Cloud Shell Instanz 1 erstellen
gcloud compute instances create www1 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-a \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"
In Cloud Shell Instanz 2 erstellen
gcloud compute instances create www2 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-a \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www2</h1></body></html>' | tee /var/www/html/index.html"
In Cloud Shell Instanz 3 erstellen
gcloud compute instances create www3 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-c \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www3</h1></body></html>' | tee /var/www/html/index.html"
In Cloud Shell Instanz 4 erstellen
gcloud compute instances create www4 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-c \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www4</h1></body></html>' | tee /var/www/html/index.html"
Firewallregel erstellen, um externen Traffic zu diesen VM-Instanzen zuzulassen
Aus Cloud Shell
gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag
Statische externe IP-Adresse für den Load-Balancer erstellen
Aus Cloud Shell
gcloud compute addresses create network-lb-ip-1 \
--region us-central1
Legacy-HTTP-Systemdiagnose-Ressource hinzufügen
Aus Cloud Shell
gcloud compute http-health-checks create basic-check
5. Weiterleitungsregel und Zielpool erstellen
Zielpool erstellen
gcloud compute target-pools create www-pool \
--region us-central1 --http-health-check basic-check
Instanzen zum Zielpool us-central1-a hinzufügen
gcloud compute target-pools add-instances www-pool \ --instances www1,www2 \ --instances-zone us-central1-a
Fügen Sie Ihre Instanzen dem Zielpool us-central1-c hinzu.
gcloud compute target-pools add-instances www-pool \ --instances www3,www4 \ --instances-zone us-central1-c
Weiterleitungsregel hinzufügen
gcloud compute forwarding-rules create www-rule \ --region us-central1 \ --ports 80 \ --address network-lb-ip-1 \ --target-pool www-pool
Validieren Sie die Funktionalität des Zielpools
Identifizieren Sie die Frontend-IP-Adresse, indem Sie Load Balancer → Frontends (www-rule) auswählen.
Greifen Sie mit dem curl-Befehl von Ihrem Workstationterminal aus auf die externe IP-Adresse zu und beobachten Sie das Load-Balancing für alle vier Zielinstanzen. Schließen Sie das Terminal nach der Validierung.
while true; do curl -m1 IP_ADDRESS; done
6. Netzwerk-Load-Balancer vom Zielpool auf den Backend-Dienst umstellen
Einheitliche Systemdiagnosen für den Back-End-Dienst erstellen
gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1
Instanzgruppen aus vorhandenen Instanzen aus dem Zielpool erstellen
gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1a --zone=us-central1-a gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1a --zone=us-central1-a --instances=www1,www2
Instanzgruppen aus vorhandenen Instanzen aus dem Zielpool erstellen
gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1c --zone=us-central1-c gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1c --zone=us-central1-c --instances=www3,www4
Back-End-Dienst erstellen und mit den neu erstellten Systemdiagnosen verknüpfen
gcloud compute backend-services create my-backend-service --region us-central1 --health-checks my-tcp-health-check --health-checks-region us-central1 --load-balancing-scheme external
Back-End-Dienst konfigurieren und Instanzgruppen hinzufügen
gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1a --instance-group-zone us-central1-a --region us-central1 gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1c --instance-group-zone us-central1-c --region us-central1
Vorhandene Weiterleitungsregel zur Unterstützung von Back-End-Diensten aktualisieren
Notieren Sie sich den Namen der Weiterleitungsregel „www-rule“. und die zugehörige IP-Adresse an, indem Sie Folgendes tun:
Load-Balancer → Front-Ends auswählen
Außerdem sind die vier Zielpools
Load Balancer auswählen → „www-pool“ auswählen
Traffic durch Aktualisierung der vorhandenen Weiterleitungsregel an Back-End-Dienste weiterleiten
gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1
Load Balancer „www-pool“ prüfen ist nicht mehr mit dem Front-End "www-rule" konfiguriert. (siehe Screenshot unten)
Load-Balancer auswählen → www-pool
Validieren, dass die Frontend-Weiterleitungsregel jetzt mit dem Load-Balancer "my-backend-service" verknüpft ist
Load-Balancer → Front-Ends auswählen
Beachten Sie den Regelnamen „www-rule“ Die IP-Adresse bleibt erhalten und der Load-Balancer „my-backend-service“ wird jetzt verwendet
Greifen Sie über den curl-Befehl auf dem Workstation-Terminal auf die externe IP-Adresse zu und beobachten Sie das Load-Balancing für den neu zugeordneten Back-End-Dienst. Schließen Sie das Terminal nach der Validierung.
while true; do curl -m1 IP_ADDRESS; done
7. Bereinigungsschritte
gcloud compute forwarding-rules delete www-rule --region=us-central1 --quiet gcloud compute backend-services delete my-backend-service --region us-central1 --quiet gcloud compute target-pools delete www-pool --region us-central1 --quiet gcloud compute addresses delete network-lb-ip-1 --region us-central1 --quiet gcloud compute firewall-rules delete www-firewall-network-lb --quiet gcloud compute instances delete www4 --zone us-central1-c --quiet gcloud compute instances delete www3 --zone us-central1-c --quiet gcloud compute instances delete www2 --zone us-central1-a --quiet gcloud compute instances delete www1 --zone us-central1-a --quiet gcloud compute networks subnets delete network-lb-subnet --region us-central1 --quiet gcloud compute networks delete network-lb --quiet gcloud compute instance-groups unmanaged delete www-instance-group-central1a --zone us-central1-a --quiet gcloud compute instance-groups unmanaged delete www-instance-group-central1c --zone us-central1-c --quiet
8. Glückwunsch!
Herzlichen Glückwunsch zum Abschluss des Codelabs.
Behandelte Themen
- Vorteile regionaler Back-End-Dienste
- Netzwerk-Load-Balancer mit Zielpools erstellen
- Zielpool-Validierung durchführen
- Regionalen Backend-Dienst mit nicht verwalteten Instanzgruppen erstellen
- Migration von Zielpool zu Backend-Dienst ausführen
- Validierung der Backend-Dienste durchführen