1. Einführung
Diese Anleitung enthält eine Anweisungen zum Übertragen eines vorhandenen Netzwerk-Load-Balancers von einem Zielpool-Back-End zu einem regionalen Back-End-Dienst.
Aufgaben in diesem Lab
- Vorteile regionaler Back-End-Dienste
- Netzwerk-Load-Balancer mit Zielpools erstellen
- Zielpool validieren
- Regionalen Backend-Dienst mit nicht verwalteten Instanzgruppen erstellen
- Migration von Zielpools zu Backend-Diensten durchführen
- Back-End-Dienste prüfen
Voraussetzungen
- Erfahrung mit Load-Balancern
2. Regionale Back-End-Dienste für das Netzwerk-Load Balancing – Übersicht
Mit Network Load Balancing haben Google Cloud-Kunden ein leistungsstarkes Tool zum Verteilen externen Traffics auf virtuelle Maschinen in einer Google Cloud-Region. Damit unsere Kunden den eingehenden Traffic leichter verwalten und das Verhalten des Load Balancers steuern können, haben wir vor Kurzem die Unterstützung für Backend-Dienste in Network Load Balancing aufgenommen. So können unsere Kunden ihre Bereitstellungen einfacher skalieren, schneller umsetzen, leistungsfähiger gestalten und ausfallsicherer machen.
Wir unterstützen jetzt Back-End-Dienste mit Netzwerk-Load Balancing. Das ist eine erhebliche Verbesserung gegenüber dem bisherigen Ansatz, Zielpools. Ein Back-End-Dienst definiert, wie unsere Load Balancer eingehenden Traffic an verbundene Back-Ends verteilen, und bietet eine detaillierte Steuerung des Verhaltens des Load Balancers.
3. Vorteile regionaler Backend-Dienste
Wenn Sie einen regionalen Back-End-Dienst als Load Balancer auswählen, hat das eine Reihe von Vorteilen für Ihre Umgebung.
Regionale Backend-Dienste bieten standardmäßig Folgendes:
- Hochpräzise Systemdiagnose mit einheitlicher Systemdiagnose: Mit regionalen Back-End-Diensten können Sie jetzt alle Vorteile der Systemdiagnosefunktionen für das Load Balancing nutzen und sind nicht mehr an die Einschränkungen der bisherigen HTTP-Systemdiagnosen gebunden. Aus Compliance-Gründen waren TCP-Systemdiagnosen mit Unterstützung für benutzerdefinierte Anfrage- und Antwortstrings oder HTTPS eine häufige Anforderung für 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 Instanzgruppe festlegen und den Traffic per Failover umleiten, wenn der Zustand der Instanzen in der aktiven Gruppe unter einen bestimmten Grenzwert fällt. Wenn Sie den Failover-Mechanismus besser steuern möchten, können Sie einen Agenten wie keepalived oder pacemaker verwenden und eine fehlerfreie oder fehlerhafte Systemdiagnose basierend auf Zustandsänderungen der Backend-Instanz freigeben.
- 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 Vorteilen können Sie das Verbindungsablaufverfahren für das verbindungsorientierte Protokoll (TCP) und eine schnellere Programmierzeit für große Bereitstellungen nutzen.
Codelab-Netzwerktopologie
Diese Anleitung enthält eine Anweisungen zum Übertragen eines vorhandenen Netzwerk-Load-Balancers von einem Zielpool-Back-End zu einem regionalen Back-End-Dienst.
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, Verbindungsausgleich und Failover-Richtlinien nutzen.
Dieser Leitfaden führt Sie durch die Umstellung des folgenden Beispiels eines zielpoolbasierten Netzwerk-Load-Balancers auf die Verwendung eines regionalen Back-End-Dienstes.
Vorher:Netzwerk-Load Balancing mit 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 traditionellen zielpoolbasierten 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 Zielpoolinstanzen in Instanzgruppen. Backend-Dienste funktionieren nur mit verwalteten oder nicht verwalteten Instanzgruppen. Die Anzahl der Instanzen, die in einen einzelnen Zielpool verschoben werden können, ist nicht begrenzt. Allerdings haben Instanzgruppen eine maximale Größe. Wenn Ihr Zielpool mehr als die maximal zulässige Anzahl von Instanzen umfasst, müssen Sie die 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 Backend-Dienstes ein Failover-Verhältnis festlegen. Dies sollte dem Failover-Verhältnis entsprechen, das zuvor für die Bereitstellung des Zielpools konfiguriert wurde.
- Fügen Sie dem Back-End-Dienst Instanzgruppen hinzu, die Sie zuvor erstellt haben. 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 zwei Möglichkeiten:
- Empfohlen: Aktualisieren Sie die vorhandene Weiterleitungsregel so, dass 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 Frontend des Load Balancers erstellen. Ändern Sie dann die DNS-Einstellungen, um nahtlos von der IP-Adresse des alten Zielpools zur neuen IP-Adresse zu wechseln.
Einrichtung der Umgebung im eigenen Tempo
- Melden Sie sich in der Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto 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 die Abrechnung in der Cloud Console aktivieren, um Google Cloud-Ressourcen verwenden zu können.
Die Ausführung dieses Codelabs sollte nur wenige Kosten verursachen, wenn überhaupt. Folgen Sie unbedingt der Anleitung im Abschnitt „Bereinigen“, um Ressourcen herunterzufahren, damit keine weiteren Kosten anfallen. Neuen Nutzern der Google Cloud Platform steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.
Cloud Shell starten
Sie können Google Cloud zwar per Fernzugriff von Ihrem Laptop aus nutzen, 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 sollte nur wenige Minuten dauern. Wenn der Vorgang abgeschlossen ist, sollte in etwa Folgendes angezeigt werden:
Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Dadurch werden Netzwerkleistung und Authentifizierung erheblich verbessert. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.
Melden Sie sich in Cloud Shell an und legen Sie Ihre Projekt-ID fest.
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
Über Cloud Shell
gcloud compute networks create network-lb --subnet-mode custom
Subnetz erstellen
Über Cloud Shell
gcloud compute networks subnets create network-lb-subnet \
--network network-lb --range 10.0.0.0/24 --region us-central1
Firewallregeln erstellen
Über 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
Instanzen in 2 Instanzen pro Zone erstellen, us-central1-a und us-central1-c
Instanz 1 in Cloud Shell 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"
Instanz 2 in Cloud Shell 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 zum Zulassen von externem Traffic zu diesen VM-Instanzen erstellen
Über 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
Ressource für die Legacy-HTTP-Systemdiagnose hinzufügen
Über 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
Fügen Sie die Instanzen dem Zielpool „us-central1-a“ hinzu.
gcloud compute target-pools add-instances www-pool \ --instances www1,www2 \ --instances-zone us-central1-a
Fügen Sie die 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
Geben Sie die IP-Adresse des Front-Ends an, indem Sie „Load Balancer“ → „Frontends (www-rule)“ auswählen.
Verwenden Sie den Befehl „curl“ auf dem Terminal Ihrer Workstation, um auf die externe IP-Adresse zuzugreifen und das Load Balancing über die vier Zielinstanzen hinweg zu beobachten. Schließen Sie das Terminal nach der Validierung.
while true; do curl -m1 IP_ADDRESS; done
6. Netzwerk-Load Balancer vom Zielpool zum Backend-Dienst übertragen
Einheitliche Systemdiagnosen für Ihren Backend-Dienst erstellen
gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1
Instanzgruppen aus vorhandenen Instanzen im 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 im 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 für die Unterstützung von Backend-Diensten aktualisieren
Notieren Sie sich den Namen der Weiterleitungsregel „www-rule“ und die zugehörige IP-Adresse. Gehen Sie dazu so vor:
Wählen Sie „Load Balancer“ → „Front-Ends“ aus.
Außerdem wurden die vier Zielpools notiert.
Load Balancer auswählen → „www-pool“ auswählen
Traffic an Backend-Dienste weiterleiten, indem die vorhandene Weiterleitungsregel aktualisiert wird
gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1
Prüfen Sie, ob der Load Balancer „www-pool“ nicht mehr mit dem Frontend „www-rule“ konfiguriert ist (siehe Screenshot unten).
Wählen Sie „Load Balancer“ → „www-pool“ aus.
Prüfen, ob die frontend-Weiterleitungsregel jetzt mit dem Load Balancer „my-backend-service“ verknüpft ist
Wählen Sie „Load Balancer“ → „Front-Ends“ aus.
Beachten Sie, dass der Regelname „www-rule“ die IP-Adresse beibehalten wird und der Load-Balancer „my-backend-service“ jetzt verwendet wird.
Verwenden Sie den Befehl „curl“ auf dem Terminal Ihrer Workstation, um auf die externe IP-Adresse zuzugreifen und das Load Balancing über den neu verknüpften Backend-Dienst zu beobachten. Schließen Sie das Terminal nach der Bestätigung.
while true; do curl -m1 IP_ADDRESS; done
7. Bereinigen
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 von regionalen Backend-Diensten
- Netzwerk-Load-Balancer mit Zielpools erstellen
- Zielpool validieren
- Regionalen Backend-Dienst mit nicht verwalteten Instanzgruppen erstellen
- Migration von Zielpools zu Backend-Diensten durchführen
- Back-End-Dienste prüfen