Dieses Dokument richtet sich an Architekten und Personen, die in Betriebs- und Verwaltungsteams arbeiten. In diesem Dokument wird ein Beispielmuster beschrieben, das Sie für Ihre eigenen Bereitstellungen in Google Cloud verwenden können.
In dieser Architektur leitet Cloud DNS Traffic an Compute Engine-Instanzen in verwalteten Instanzgruppen weiter, die Inhalte bereitstellen. Bei einem Ausfall aktualisieren Sie die Cloud DNS-Zone und führen einen Failover auf eine statische Website in Cloud Storage durch.
Um diese Lösung bereitzustellen, benötigen Sie einen registrierten Domainnamen, den Sie selbst verwalten und für dieses Dokument verwenden möchten.
In Produktionsbereitstellungen enthält Ihre Website wahrscheinlich deutlich mehr Dateien und zusätzlichen Anwendungscode auf den virtuellen Maschinen (VMs) der verwalteten Instanzgruppe, als in diesem Dokument beschrieben. Cloud Storage hostet dann eine eingeschränktere statische Version, die nur minimale Funktionen bietet. In einem Szenario mit warmem Failover sehen die Nutzer diese eingeschränkte Website, bis die verwalteten Instanzgruppen wiederhergestellt sind und Traffic für die gesamte Website bereitstellen können.
Architektur
In dieser Architektur stellen Sie Ressourcen zum Erstellen einer Umgebung bereit, wie in der folgenden Abbildung dargestellt:
Bei einem Failover aktualisieren Sie die Cloud DNS-Konfiguration, um Traffic an Cloud Storage weiterzuleiten, wie in der folgenden Abbildung dargestellt:
Dieses Muster mit warmem Failover vermeidet die Kosten für die Ausführung einer anderen verwalteten Instanzgruppe in einer anderen Region, die Sie nur verwenden, wenn die primäre Region ausfällt. Die Kosten einer statischen Website mit Cloud Storage sind niedriger als die Ausführung einer anderen verwalteten Instanzgruppe. Wenn Sie Cloud DNS zwischen den Hosting-Optionen aktualisieren, kommt es jedoch zu einer kurzen Verzögerung. Die Beschränkung der Websiteerfahrung in Cloud Storage ist besser als eine überhaupt nicht verfügbare Website und eine schlechte Kundenerfahrung.
Ein alternativer Ansatz, bei dem ein externer Application Load Balancer statt Cloud DNS zur Steuerung des Failovers verwendet wird, finden Sie unter Warmen wiederherstellbaren Webserver mit Compute Engine und Cloud Storage bereitstellen. Dieses Muster ist nützlich, wenn Sie kein Cloud DNS haben oder es nicht verwenden möchten.
Für die Ausführung zuverlässiger Anwendungen in Google Cloud empfehlen wir Ihnen, Ihre Anwendungsinfrastruktur auf den Umgang mit Ausfällen vorzubereiten. Je nach Anwendung und geschäftlichen Anforderungen benötigen Sie unter Umständen ein Muster für kalten Failover, warmen Failover oder heißen Failover. Weitere Informationen zur Bestimmung des besten Ansatzes für Ihre eigenen Anwendungen finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
In diesem Dokument wird ein einfacher Apache-Webserver verwendet. Der gleiche Ansatz für die Infrastrukturbereitstellung gilt jedoch auch für andere Anwendungsumgebungen, die Sie erstellen müssen.
Ziele
- Regionale verwaltete Instanzgruppen mit einem benutzerdefinierten VM-Image erstellen
- Cloud Storage-Bucket erstellen
- Cloud DNS-Zone erstellen und konfigurieren
- Warmen Failover des Webservers mit aktualisierten Cloud DNS-Einträgen testen
- Wiederherstellung und Failback mit aktualisierten Cloud DNS-Einträgen testen
Kosten
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Hinweise
Von Ihrer Organisation definierte Sicherheitsbeschränkungen verhindern möglicherweise, dass die folgenden Schritte ausgeführt werden. Informationen zur Fehlerbehebung finden Sie unter Anwendungen in einer eingeschränkten Google Cloud-Umgebung entwickeln.
- Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Compute Engine API aktivieren.
- Installieren Sie die Google Cloud CLI.
-
Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:
gcloud init
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Compute Engine API aktivieren.
- Installieren Sie die Google Cloud CLI.
-
Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:
gcloud init
Sie können die Google Cloud CLI in der Google Cloud Console ausführen, ohne die Google Cloud CLI zu installieren. Verwenden Sie Cloud Shell, um die gcloud CLI in der Google Cloud Console auszuführen.
Umgebung vorbereiten
In diesem Abschnitt definieren Sie einige Variablen für Ihre Ressourcennamen und Standorte. Diese Variablen werden von den Google Cloud CLI-Befehlen verwendet, wenn Sie die Ressourcen bereitstellen.
Sofern nicht anders angegeben, geben Sie in dieser Bereitstellung alle Befehle in Cloud Shell oder in Ihrer lokalen Entwicklungsumgebung ein.
Ersetzen Sie
PROJECT_ID
durch Ihre Projekt-ID: Geben Sie bei Bedarf ein eigenes Namenssuffix für Ressourcen an, damit Sie diese leichter suchen und identifizieren zu können, z. B.app
.Geben Sie zwei Regionen wie
us-west1
undus-west2
und eine Zone innerhalb dieser Regionen an, z. B.us-west1-a
. Diese Zone definiert, wo die anfängliche Basis-VM erstellt wird, die zum Erstellen eines Images für die verwaltete Instanzgruppe verwendet wird.Zum Schluss legen Sie eine Domain fest, die für Ihre statische Website verwendet wird, z. B.
example.com
.PROJECT_ID=PROJECT_ID NAME_SUFFIX=app REGION1=us-west1 REGION2=us-west2 ZONE=us-west1-a DOMAIN=example.com
VPC und Subnetz erstellen
Für den Netzwerkzugriff auf die VMs erstellen Sie eine Virtual Private Cloud (VPC) und Subnetze. Da Sie verwaltete Instanzgruppen in zwei Regionen benötigen, erstellen Sie in jeder Region ein Subnetz. Weitere Informationen zu den Vorteilen des benutzerdefinierten Subnetzmodus für die Verwaltung von IP-Adressbereichen in Ihrer Umgebung finden Sie unter VPC-Netzwerke im benutzerdefinierten Modus verwenden.
Erstellen Sie die VPC mit einem benutzerdefinierten Subnetzmodus:
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
Erstellen Sie nun zwei Subnetze in der neuen VPC, eines für jede Region. Definieren Sie Ihre eigenen Adressbereiche wie
10.1.0.0/20
und10.2.0.0/20
, die in Ihren Netzwerkbereich passen:gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=10.1.0.0/20 \ --region=$REGION1 gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range=10.2.0.0/20 \ --region=$REGION2
Firewallregeln erstellen
Verwenden Sie Firewallregeln, um den Netzwerktraffic in der VPC ordnungsgemäß zu ermöglichen.
Erstellen Sie Firewallregeln, um Web-Traffic und Systemdiagnosen für den Load-Balancer und die verwalteten Instanzgruppen zuzulassen:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:80 \ --source-ranges=0.0.0.0/0 \ --target-tags=http-server gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Die HTTP-Regel lässt Traffic zu jeder VM zu, auf die das Tag
http-server
angewendet wird, sowie aus einer beliebigen Quelle mithilfe des Bereichs0.0.0.0/0
. Für die Regel „Systemdiagnose“ sind für Google Cloud Standardbereiche festgelegt, damit die Plattform den Zustand von Ressourcen ordnungsgemäß überprüfen kann.Wenn Sie SSH-Traffic für die Erstkonfiguration eines Basis-VM-Images zulassen möchten, legen Sie für Ihre Firewallregel mithilfe des Parameters
--source-range
Ihre Firewallregel fest. Möglicherweise müssen Sie zusammen mit Ihrem Netzwerkteam ermitteln, welche Quellbereiche in Ihrer Organisation verwendet werden.Ersetzen Sie
IP_ADDRESS_SCOPE
durch Ihre eigenen IP-Adressbereiche:gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ --source-ranges=IP_ADDRESS_SCOPE
Prüfen Sie nach dem Erstellen der Firewallregeln, ob die drei Regeln hinzugefügt wurden:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"
Die folgende Beispielausgabe zeigt, dass die drei Regeln korrekt erstellt wurden:
NAME NETWORK DIRECTION PRIORITY ALLOW allow-health-check-app network-app INGRESS 1000 tcp:80 allow-http-app network-app INGRESS 1000 tcp:80 allow-ssh-app network-app INGRESS 1000 tcp:22
Basis-VM-Image erstellen und konfigurieren
Wenn Sie identische VMs erstellen möchten, die Sie ohne zusätzliche Konfiguration bereitstellen, verwenden Sie ein benutzerdefiniertes VM-Image. Dieses Image erfasst die Betriebssystem- und Apache-Konfiguration und wird in den nächsten Schritten verwendet, um jede VM in der verwalteten Instanzgruppe zu erstellen.
Erstellen Sie auf der VM eine einfache index.html
-Datei im nichtflüchtigen Speicher und stellen Sie sie auf /var/www/example.com
bereit. Eine Apache-Konfigurationsdatei unter /etc/apache2/sites-available/example.com.conf
stellt Webinhalte für den bereitgestellten nichtflüchtigen Speicherspeicherort bereit.
Das folgende Diagramm zeigt die einfache HTML-Seite, die von Apache bereitgestellt und im nichtflüchtigen Speicher gespeichert wird:
Sie erstellen diese Umgebung in den folgenden Schritten.
Erstellen Sie eine Basis-VM mit einem angehängten nichtflüchtigen Speicher:
gcloud compute instances create vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ --image=debian-10-buster-v20210420 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk-device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Sie verwenden die zu Beginn dieses Dokuments definierten Parameter, um die VM zu benennen und eine Verbindung zum richtigen Subnetz herzustellen. Namen werden auch von den Parametern für das Bootlaufwerk und das Datenlaufwerk zugewiesen.
Stellen Sie zum Installieren und Konfigurieren der einfachen Website zuerst eine SSH-Verbindung zur Basis-VM her:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Erstellen Sie in Ihrer SSH-Sitzung zur VM ein Skript, um die VM in einem Editor Ihrer Wahl zu konfigurieren. Im folgenden Beispiel wird Nano als Editor verwendet:
nano configure-vm.sh
Fügen Sie das folgende Konfigurationsskript in die Datei ein:
#!/bin/bash NAME_SUFFIX=app # Create directory for the basic website files sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Find the disk name, then format and mount it DISK_NAME="google-disk-base-$NAME_SUFFIX" DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')" sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Install Apache sudo apt-get update && sudo apt-get -y install apache2 # Write out a basic HTML file to the mounted persistent disk sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF' <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p> </body> </html> EOF # Write out an Apache configuration file sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF' <VirtualHost *:80> ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/example.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> EOF # Enable the Apache configuration file and reload service sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Aktualisieren Sie die Variable
NAME_SUFFIX
so, dass sie dem Wert zu Beginn dieses Dokuments entspricht, z. B. app.Geben Sie die Datei aus und beenden Sie den Editor. In Nano verwenden Sie beispielsweise
Ctrl-O
, um die Datei auszugeben, und beenden dann mitCtrl-X
.Machen Sie das Konfigurationsskript ausführbar und führen Sie es dann aus:
chmod +x configure-vm.sh ./configure-vm.sh
Beenden Sie die SSH-Sitzung zur VM:
exit
Rufen Sie die IP-Adresse der VM ab und rufen Sie mit
curl
die einfache Webseite auf:curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP)")
Die einfache Website wird zurückgegeben, wie in der folgenden Beispielausgabe gezeigt:
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p> </body> </html>
Mit diesem Schritt wird bestätigt, dass Apache richtig konfiguriert ist, und die Seite wird aus dem angehängten nichtflüchtigen Speicher geladen. In den nächsten Abschnitten erstellen Sie ein Image mit dieser Basis-VM und konfigurieren eine Instanzvorlage mit einem Startskript.
Compute Engine-Ressourcen bereitstellen
Dieses Muster eines warmen Failovers verwendet verwaltete Instanzgruppen zum Ausführen der VMs. Die verwalteten Instanzgruppen werden in zwei Regionen ausgeführt und jede Gruppe überwacht den Zustand der VMs. Wenn ein Ausfall auftritt und eine der VMs fehlschlägt, erstellt die verwaltete Instanzgruppe die VM neu. Durch diese Konfiguration wird eine hochverfügbare Anwendung erstellt, auch ohne den warmen Failover zu einer statischen Website in Cloud Storage.
Bevor Sie ein Image erstellen können, müssen Sie die VM beenden:
gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
Führen Sie die folgenden Befehle aus, um die VM-Images, Instanzvorlagen und verwalteten Instanzgruppen zu erstellen:
# Create the base VM images gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute images create image-disk-$NAME_SUFFIX \ --source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Create instance templates gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine-type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server \ --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Create a health check for VM instances gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Create the managed instance groups gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
Load-Balancer erstellen und konfigurieren
Damit Nutzer auf Ihre Website zugreifen können, müssen Sie Traffic zu den VMs zulassen, die in den verwalteten Instanzgruppen ausgeführt werden. Außerdem möchten Sie den Traffic automatisch an neue VMs weiterleiten, wenn in einer verwalteten Instanzgruppe ein Zonenfehler auftritt.
Im folgenden Abschnitt erstellen Sie einen externen HTTPS-Load-Balancer mit einem Back-End-Dienst für HTTP-Traffic an Port 80, verwenden die in den vorherigen Schritten erstellte Systemdiagnose und ordnen dem Back-End-Dienst eine externe IP-Adresse zu.
Weitere Informationen finden Sie unter Einfachen externen HTTP-Load-Balancer einrichten.
Erstellen und konfigurieren Sie den Load-Balancer für Ihre Anwendung:
# Configure port rules for HTTP port 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Create a backend service and add the managed instance groups to it gcloud compute backend-services create \ web-backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Create a URL map for the backend service gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Configure forwarding for the HTTP traffic gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http-$NAME_SUFFIX gcloud compute forwarding-rules create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Rufen Sie die IP-Adresse der Weiterleitungsregel für den Web-Traffic ab:
IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress)")
Verwenden Sie
curl
oder öffnen Sie Ihren Webbrowser, um die Website mithilfe der IP-Adresse des Load-Balancers aus dem vorherigen Schritt aufzurufen:curl $IP_ADDRESS
Es dauert einige Minuten, bis der Load-Balancer die Bereitstellung abgeschlossen hat und Traffic korrekt an Ihr Back-End weitergeleitet wird. Wenn der Load-Balancer noch bereitgestellt wird, wird ein HTTP 404-Fehler zurückgegeben. Warten Sie gegebenenfalls einige Minuten und versuchen Sie noch einmal, auf die Website zuzugreifen.
Die einfache Website wird zurückgegeben, wie in der folgenden Beispielausgabe gezeigt:
<!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a Compute Engine website with warm failover to Cloud Storage!</p> </body> </html>
Storage-Bucket erstellen und konfigurieren
Cloud Storage wird verwendet, um statische Websitedateien zu speichern. In diesem einfachen Beispiel erstellen Sie eine einzelne Datei mit etwas anderem Text als auf den VMs.
In Produktionsbereitstellungen enthält Ihre Website wahrscheinlich viel mehr Dateien und zusätzlichen Anwendungscode auf Ihren verwalteten Instanzgruppen-VMs, als in diesem Dokument gezeigt. Die statische, in Cloud Storage gehostete Version ist dann oft eine eingeschränktere Version, die minimale Funktionen bietet. In einem Szenario mit warmem Failover wird diese eingeschränkte Website von Cloud Storage angezeigt, bis die verwalteten Instanzgruppen wiederhergestellt sind und Traffic für die gesamte Website bereitstellen können.
Bestätigen Sie die Domain, die Sie mit Ihrem Cloud Storage-Bucket verwenden möchten.
Erstellen Sie einen Cloud Storage-Bucket, der dem Namen der Domain entspricht, die Ihnen gehört und die Sie verwenden möchten:
gsutil mb gs://static-web.$DOMAIN
Die am Anfang dieses Dokuments definierte Variable
DOMAIN
wird verwendet, z. B.example.com
. In diesem Beispiel werden die statischen Dateien unterstatic-web.example.com
gespeichert.Erstellen Sie eine lokale Datei, die Sie im nächsten Schritt in den Cloud Storage-Bucket kopieren:
cat <<EOF > index.html <!doctype html> <html lang=en> <head> <meta charset=utf-8> <title>HA / DR example</title> </head> <body> <p>Welcome to a test static web server with warm failover from Cloud Storage!</p> </body> </html> EOF
Laden Sie die einfache HTML-Datei in den Cloud Storage-Bucket hoch:
gsutil cp index.html gs://static-web.$DOMAIN
Damit Nutzer die statischen Webinhalte aufrufen können, legen Sie die entsprechenden Berechtigungen für den Cloud Storage-Bucket fest:
gsutil iam ch allUsers:objectViewer gs://static-web.$DOMAIN
Konfigurieren Sie den Cloud Storage-Bucket so, dass die Datei
index.html
als Standardwebseite bereitgestellt wird:gsutil web set -m index.html gs://static-web.$DOMAIN
DNS-Zone und -Eintrag erstellen
Erstellen Sie eine Cloud DNS-Zone, damit der Traffic an die warme statische Website in Cloud Storage weitergeleitet werden kann, wenn bei den verwalteten Instanzgruppen ein Ausfall auftritt. Unter normalen Bedingungen leitet diese DNS-Zone den Traffic über den externen Load-Balancer an die verwalteten Instanzgruppen weiter, die in den vorherigen Abschnitten erstellt wurden.
Erstellen Sie die Cloud DNS-Zone:
gcloud dns managed-zones create zone-$NAME_SUFFIX \ --dns-name=$DOMAIN \ --description="DNS zone for warm site failover"
Die am Anfang dieses Dokuments definierte Variable
DOMAIN
wird verwendet, z. B.example.com
.Rufen Sie die Details der Cloud DNS-Zone ab:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
Die folgende Beispielausgabe zeigt die
nameServers
für die Zone, z. B.ns-cloud-b1.googledomains.com
.[...] kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com.
Cloud DNS muss für Ihre Domain autoritativ sein. Erstellen Sie Nameserver-Einträge bei Ihrem Domain-Registrator, die auf Ihre Cloud DNS-Zone verweisen. Verwenden Sie die im vorherigen Schritt zurückgegebenen Nameserver-Adressen.
Weitere Informationen und ein Beispiel für die Verwendung von Google Domains finden Sie unter Nameserver aktualisieren.
Fügen Sie in Ihrer Cloud DNS-Zone einen Eintrag für
www
mithilfe der IP-Adresse des Load-Balancers hinzu, die Sie in einem vorherigen Abschnitt abgerufen haben:gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Dieser Eintrag leitet Nutzeranfragen für die Website über den Load-Balancer an die verwalteten Instanzgruppen weiter. Eine TTL von 300 Sekunden wird festgelegt, um den Zeitraum zu verkürzen, für den der im Cache gespeicherte DNS-Eintrag für einen Nutzer vorhanden ist.
Erstellen Sie einen Eintrag, der vom Cloud Storage-Bucket für die statische Website verwendet werden soll:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
In diesem Beispiel wird
static-web
als Subdomain verwendet. Verlassen Siec.storage.googleapis.com.
. Es wird wieder eine TTL von 300 Sekunden festgelegt, um die Dauer zu verkürzen, für die der im Cache gespeicherte DNS-Eintrag für einen Nutzer vorhanden ist.Führen Sie abschließend einen Commit für die Ergänzungen des DNS-Eintrags in der Zone durch:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
DNS-Zone und -Einträge prüfen und testen
Sehen wir uns die Ressourcenbereitstellungen an, bevor Sie einen Zonenfehler simulieren. Alle Ressourcen wurden zur Unterstützung der Umgebung erstellt, wie in der folgenden Abbildung dargestellt:
- Einträge einer Cloud DNS-Zone leiten Nutzer an den Load-Balancer weiter, damit sie auf die verwalteten Instanzgruppen der VMs verteilt werden können.
- Ein Cloud Storage-Bucket ist so konfiguriert, dass er statische Webseiten hostet, wenn bei den verwalteten Instanzgruppen ein Ausfall auftritt.
- Die Cloud DNS-Zone ist für die Verwendung der statischen Website in Cloud Storage konfiguriert, löst jedoch derzeit keine Anfragen an den Storage-Bucket auf.
Um die DNS-Einträge und die Testauflösung anzuzeigen, müssen Sie Adressen für die Cloud DNS-Server auflösen. Testen Sie in Produktionsbereitstellungen unbedingt, ob die Adressen korrekt aufgelöst werden, und aktualisieren Sie dann Ihre eigenen DNS-Server, um entsprechend aufzulösen. In diesem Dokument werden nicht die Schritte zum Aktualisieren Ihrer eigenen DNS-Server beschrieben. Sie erfahren nur, wie Trafficzugriffe unter normalen und Failover-Bedingungen korrekt überprüft werden.
Rufen Sie wieder die Details der Cloud DNS-Zone ab:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
Die folgende Beispielausgabe zeigt die
nameServers
für die Zone, z. B.ns-cloud-b1.googledomains.com
.[...] kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com.
Verwenden Sie den Befehl
dig
, um denwww
-Eintrag für Ihre Cloud DNS-Zone mit einem dieser Nameserver aufzulösen:dig @ns-cloud-b1.googledomains.com www.$DOMAIN
In diesem Beispiel wird die Nameserver-Adresse
ns-cloud-b1.googledomains.com
verwendet, die vom vorherigendescribe
-Befehl zurückgegeben wurde. Geben Sie Ihre eigene Nameserver-Adresse an, die in der Ausgabe des vorherigen Befehls angezeigt wurde.Die folgende Beispielausgabe zeigt, dass der Eintrag in die IP-Adresse des Load-Balancers aufgelöst wird. Wenn Sie diesen Nameserver für den Zugriff auf die Adresse verwendet haben, z. B. mit
curl
und dem Parameter--resolve
mit dem Cloud DNS-Nameserver, wird die Standardseite von einem der verwalteten Instanzgruppen hinter dem Load-Balancer angezeigt.; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Verwenden Sie wieder den Befehl
dig
, um den DNS-Eintrag für die statische Website in Cloud Storage zu prüfen:dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
Die folgende Beispielausgabe zeigt, dass der Eintrag in Cloud Storage aufgelöst wird, das die statischen Inhalte aus dem Storage-Bucket bereitstellen kann:
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com static-web.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com.
Failover zum Cloud Storage-Bucket ausführen
In einer Produktionsumgebung können Sie bei Verwendung von Cloud Monitoring oder einer anderen Monitoring-Lösung eine Benachrichtigung erhalten, wenn es ein Problem mit den verwalteten Instanzgruppen gibt. In der Benachrichtigung wird ein Mensch aufgefordert, den Umfang des Fehlers nachzuvollziehen, bevor Sie die Cloud DNS-Einträge aktualisieren, um Traffic an die von Cloud Storage gehostete statische Website weiterzuleiten. Alternativ können Sie Ihre Monitoring-Lösung verwenden, um Ausfälle bei den verwalteten Instanzgruppen automatisch zu beheben.
Bei einem Failover löst Cloud DNS den Traffic auf die in Cloud Storage gehostete statische Website auf, wie in der folgenden Abbildung dargestellt:
Wenn Sie oder Ihre Monitoring-Lösung die beste Aktion zum Aktualisieren der Cloud DNS-Einträge ermitteln, um den Traffic an Cloud Storage weiterzuleiten, aktualisieren Sie den vorhandenen A
-DNS-Eintrag. In diesem Dokument aktualisieren Sie manuell die Cloud DNS-Einträge, um Traffic an die von Cloud Storage gehostete statische Website weiterzuleiten.
Entfernen Sie für den Failover der Cloud DNS-Einträge den vorhandenen
A
-Eintrag, der in den Load-Balancer aufgelöst wird:gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Erstellen Sie einen
CNAME
-Eintrag fürwww
, der auf den von Cloud Storage gehosteten Inhalt verweist:gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Führen Sie einen Commit für die Aktualisierungen in der Cloud DNS-Zone durch:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Prüfen Sie mit dem Befehl
dig
, ob derwww
-Eintrag jetzt in die Adresse der statischen Cloud Storage-Website aufgelöst wird:dig @ns-cloud-b1.googledomains.com www.$DOMAIN
Die folgende Beispielausgabe zeigt, dass der Eintrag
www.example.com
in den CNAME-Eintrag der statischen Cloud Storage-Website aufgelöst wird. Anfragen für den Zugriff aufwww.example.com
werden zum Cloud Storage-Bucket weitergeleitet, der die statische Website anzeigt:; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com.
Failback auf die verwalteten Instanzgruppen ausführen
Nachdem Probleme mit den verwalteten Instanzgruppen behoben wurden, können Sie Inhalte wieder aus den verwalteten Instanzgruppen mit Load-Balancing bereitstellen, indem Sie die Cloud DNS-Einträge wieder aktualisieren. Auch hier kann ein Mensch diese Entscheidung mithilfe von Cloud Monitoring-Statistiken zum Zustand der verwalteten Instanzgruppen treffen. Sie können auch Automatisierung verwenden, um auf den wiederhergestellten Zustand der verwalteten Instanzgruppe zu reagieren. In diesem Dokument aktualisieren Sie manuell die Cloud DNS-Einträge.
Bei einem Failback löst Cloud DNS den Traffic wieder zu den verwalteten Instanzgruppen auf, wie in der folgenden Abbildung gezeigt:
Entfernen Sie den
www
-CNAME-Eintrag, der Traffic an den von Cloud Storage gehosteten Inhalt weiterleitet:gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Fügen Sie einen
A
-Eintrag hinzu, der wieder auf den Load-Balancer vor den verwalteten Instanzgruppen verweist:gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Führen Sie einen Commit für die Aktualisierungen in der Cloud DNS-Zone durch:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Verwenden Sie noch einmal den Befehl
dig
, um zu bestätigen, dass derwww
-Eintrag in die Adresse des Load-Balancers vor den verwalteten Instanzgruppen aufgelöst wird:dig @ns-cloud-b1.googledomains.com www.$DOMAIN
Die folgende Beispielausgabe zeigt, dass der Eintrag in die IP-Adresse des Load-Balancers aufgelöst und Traffic von einer der verwalteten Instanzgruppen bereitgestellt werden würde:
; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> @ns-cloud-b1.googledomains.com www.example.com ; (1 server found) [...] ;; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Bereinigen
Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.
Führen Sie die folgenden Schritte aus, um die in diesem Dokument erstellten einzelnen Ressourcen zu löschen:
Löschen Sie die DNS-Zone und die DNS-Einträge:
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIX
Löschen Sie den Cloud Storage-Bucket:
gsutil rm -r gs://static-web.$DOMAIN
Löschen Sie die Konfiguration des Load-Balancers:
gcloud compute forwarding-rules delete \ http-content-rule-$NAME_SUFFIX --global --quiet gcloud compute target-http-proxies delete \ http-lb-proxy-$NAME_SUFFIX --quiet gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet gcloud compute backend-services delete \ web-backend-service-$NAME_SUFFIX --global --quiet
Löschen Sie die verwaltete Instanzgruppe und die Systemdiagnose:
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 --quiet gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
Löschen Sie die Instanzvorlagen, Images, Basis-VM und nichtflüchtigen Speicher:
gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ template-$NAME_SUFFIX-$REGION2 --quiet gcloud compute images delete image-$NAME_SUFFIX --quiet gcloud compute images delete image-disk-$NAME_SUFFIX --quiet gcloud compute instances delete vm-base-$NAME_SUFFIX \ --zone=$ZONE --quiet
Löschen Sie die Firewallregeln.
gcloud compute firewall-rules delete \ allow-health-check-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-ssh-$NAME_SUFFIX --quiet gcloud compute firewall-rules delete \ allow-http-$NAME_SUFFIX --quiet
Löschen Sie das Subnetz und die VPC.
gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
Nächste Schritte
- Ein alternativer Ansatz, bei dem ein externer Application Load Balancer statt Cloud DNS zur Steuerung des Failovers verwendet wird, finden Sie unter Warmen wiederherstellbaren Webserver mit Compute Engine und Cloud Storage bereitstellen. Dieses Muster ist nützlich, wenn Sie kein Cloud DNS haben oder es nicht verwenden möchten.
- Informationen zur Bestimmung des besten Ansatzes für Ihre eigenen Anwendungen und zur Verwendung der richtigen Wiederherstellungsmethode finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
- Unter Szenarien der Notfallwiederherstellung für Anwendungen finden Sie weitere Muster für Anwendungen, z. B. kalten und heißen Failover.
- Weitere Möglichkeiten zur Handhabung von Skalierung und Verfügbarkeit finden Sie unter Muster für skalierbare und robuste Anwendungen.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center