Warmen wiederherstellbaren Webserver mit Compute Engine und Cloud Storage bereitstellen

Last reviewed 2021-06-23 UTC

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 diesem Architektur leitet ein Load-Balancer den Traffic an Compute Engine-Instanzen in verwalteten Instanzgruppen weiter, die den Inhalt bereitstellen. Bei einem Ausfall aktualisieren Sie die Konfiguration des externen Application Load Balancers und führen einen Failover zu einer statischen 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:

Ein externer Load-Balancer leitet Traffic an verwaltete Instanzgruppen weiter und Nutzer sehen den gesamten Inhalt der Website.

Bei einem Failover aktualisieren Sie die Konfiguration des Load-Balancers, um Traffic an Cloud Storage weiterzuleiten. Dies wird in der folgenden Abbildung dargestellt:

Der Load-Balancer leitet Nutzer jetzt zu einer statischen Website weiter, die in Cloud Storage gehostet wird und eine eingeschränkte Nutzererfahrung bietet.

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ären Regionen ausfallen. Die Kosten einer statischen Website mit Cloud Storage sind niedriger als die Ausführung einer anderen verwalteten Instanzgruppe. Es kommt jedoch zu einer kurzen Verzögerung, wenn Sie die Load-Balancer-Konfiguration zwischen den Hosting-Optionen aktualisieren. Die eingeschränkte Website-Erfahrung in Cloud Storage ist besser als eine nicht verfügbare Website und eine schlechte Kundenerfahrung.

Ein alternativer Ansatz, bei dem Cloud DNS anstelle des externen Application Load Balancers zur Steuerung des Failovers verwendet wird, finden Sie unter Warmen wiederherstellbaren Webserver mit Cloud DNS mit Compute Engine und Cloud Storage bereitstellen auf Ihrem Mobilgerät. Dieses Muster ist nützlich, wenn Sie Cloud DNS haben oder 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
  • Einen externen Application Load Balancer erstellen und konfigurieren
  • Testen Sie das warme Failover für den Webserver mit einer aktualisierten Konfiguration des Load-Balancers.
  • Testen Sie die Wiederherstellung und den Failback mit einer aktualisierten Konfiguration des Load-Balancers.

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. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Vorbereitung

  1. 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.
  2. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  3. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  4. Compute Engine API aktivieren.

    Aktivieren Sie die API

  5. Installieren Sie die Google Cloud CLI.
  6. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

    gcloud init
  7. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  8. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  9. Compute Engine API aktivieren.

    Aktivieren Sie die API

  10. Installieren Sie die Google Cloud CLI.
  11. Führen Sie folgenden Befehl aus, um die gcloud CLI zu initialisieren:

    gcloud init
  12. 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 Anleitung alle Befehle in Cloud Shell oder in Ihrer lokalen Entwicklungsumgebung ein.

  1. 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 und us-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.

  1. Erstellen Sie die VPC mit einem benutzerdefinierten Subnetzmodus:

    gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
    
  2. 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 und 10.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.

  1. 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 Bereichs 0.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.

  2. 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
    
  3. 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:

Die VM verfügt über eine einfache HTML-Seite, die auf dem nichtflüchtigen Speicher mit einer Apache-Konfigurationsdatei gespeichert ist, die aus dem bereitgestellten Speicherort geladen wird.

Sie erstellen diese Umgebung in den folgenden Schritten.

  1. 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.

  2. 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
    
  3. 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.

  4. Geben Sie die Datei aus und beenden Sie den Editor. In Nano verwenden Sie beispielsweise Ctrl-O, um die Datei auszugeben, und beenden dann mit Ctrl-X.

  5. Machen Sie das Konfigurationsskript ausführbar und führen Sie es dann aus:

    chmod +x configure-vm.sh
    ./configure-vm.sh
    
  6. Beenden Sie die SSH-Sitzung zur VM:

    exit
    
  7. 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.

  1. Bevor Sie ein Image erstellen können, müssen Sie die VM beenden:

    gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE
    
  2. 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 Load-Balancer mit einem Back-End-Dienst für HTTP-Traffic an Port 80, verwenden die in den vorherigen Schritten erstellte Systemdiagnose und ordnen eine externe IP-Adresse dem Back-End-Dienst zu.

Weitere Informationen finden Sie unter Einfachen externen HTTP-Load-Balancer einrichten.

  1. 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
    
  2. 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)")
    
  3. 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.

  1. Bestätigen Sie die Domain, die Sie mit Ihrem Cloud Storage-Bucket verwenden möchten.

  2. 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 unter static-web.example.com gespeichert.

  3. 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
    
  4. Laden Sie die einfache HTML-Datei in den Cloud Storage-Bucket hoch:

    gsutil cp index.html gs://static-web.$DOMAIN
    
  5. 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
    
  6. 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
    

Cloud Storage-Bucket dem Load-Balancer hinzufügen

Da der Cloud Storage-Bucket zum Hosten statischer Webinhalte erstellt und konfiguriert wurde, benötigt der Load-Balancer Informationen darüber, wie Traffic an ihn weitergeleitet werden kann.

Unter Load-Balancer erstellen und konfigurieren haben Sie einen Back-End-Dienst für die verwalteten Instanzgruppen erstellt. Der Back-End-Dienst hat eine URL-Zuordnung. Ein HTTP-Zielproxy leitet Nutzer über den Load-Balancer an die VMs weiter.

Konfigurieren Sie für den Load-Balancer ein neues Back-End und eine neue URL-Zuordnung, um den Traffic an den Cloud Storage-Bucket weiterzuleiten. Wenn Sie einen Failover ausführen müssen, aktualisieren Sie den Load-Balancer so, dass er diese Konfiguration verwendet.

  1. Fügen Sie ein Back-End für den Cloud Storage-Bucket hinzu:

    gcloud compute backend-buckets create \
        web-bucket-$NAME_SUFFIX \
        --gcs-bucket-name=static-web.$DOMAIN
    
  2. Erstellen Sie eine URL-Zuordnung, die Traffic zum Back-End zulässt:

    gcloud compute url-maps create \
        web-map-http-bucket-$NAME_SUFFIX \
        --default-backend-bucket=web-bucket-$NAME_SUFFIX
    
  3. Sehen Sie sich die Ressourcenbereitstellungen an, bevor Sie einen Zonenfehler simulieren. Alle Ressourcen wurden zur Unterstützung der Umgebung erstellt, wie in der folgenden Abbildung dargestellt:

    Ein externer Load-Balancer leitet Traffic an verwaltete Instanzgruppen weiter und Nutzer sehen den gesamten Inhalt der Website.

    • Ein Load-Balancer leitet den Traffic an zwei verwaltete Instanzgruppen weiter. Die verwalteten Instanzgruppen enthalten jeweils zwei VMs, auf denen eine einfache Website ausgeführt wird.
    • Ein Cloud Storage-Bucket ist so konfiguriert, dass statische Seiten gehostet werden, wenn die verwalteten Instanzgruppen ausfallen.
    • Der Load-Balancer ist so konfiguriert, dass er die statische Website in Cloud Storage verwendet, leitet den Traffic aber derzeit nicht an den Storage-Bucket weiter.

Failover auf Cloud Storage-Bucket

In einer realen Umgebung erhalten Sie möglicherweise eine Benachrichtigung über Cloud Monitoring oder eine andere Monitoring-Lösung, wenn ein Problem mit den verwalteten Instanzgruppen auftritt. In der Benachrichtigung wird ein Mensch aufgefordert, den Umfang des Fehlers zu verstehen, bevor Sie den Load-Balancer aktualisieren, um Traffic an die von Cloud Storage gehostete statische Website weiterzuleiten. Alternativ können Sie Ihre Monitoring-Lösung verwenden, um automatisch auf Ausfälle mit den verwalteten Instanzgruppen zu reagieren.

Bei einem Failover leitet der externe Application Load Balancer den Traffic an die von Cloud Storage gehostete statische Website weiter, wie in der folgenden Abbildung dargestellt:

Der Load-Balancer leitet Nutzer jetzt zu einer statischen Website weiter, die in Cloud Storage gehostet wird, und bietet so eine eingeschränkte Nutzererfahrung.

Wenn Sie oder Ihre Monitoring-Lösung als am besten geeignete Aktion ermitteln, den Load-Balancer zu aktualisieren, sodass der Traffic an den Storage-Bucket weitergeleitet wird, aktualisieren Sie das HTTP-Proxy-Ziel für die Verwendung der URL-Zuordnung, die Sie im vorherigen Abschnitt erstellt haben. In diesem Dokument aktualisieren Sie den Load-Balancer manuell, um Traffic an die von Cloud Storage gehostete statische Website weiterzuleiten.

  1. Aktualisieren Sie das vorhandene HTTP-Proxy-Ziel, um die URL-Zuordnung für den Cloud Storage-Bucket zu verwenden:

    gcloud compute target-http-proxies update \
        http-lb-proxy-$NAME_SUFFIX \
        --url-map=web-map-http-bucket-$NAME_SUFFIX
    
  2. Verwenden Sie jetzt curl oder öffnen Sie Ihren Webbrowser, um auf die IP-Adresse des Load-Balancers zuzugreifen:

    curl $IP_ADDRESS
    

    Die statische Website von Cloud Storage 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 test static web server with warm failover from Cloud Storage!</p>
    </body>
    </html>
    

    Es kann einige Minuten dauern, bis der Load-Balancer die Konfiguration aktualisiert und den Traffic korrekt an Ihren Cloud Storage-Bucket weiterleitet. Warten Sie gegebenenfalls einige Minuten und versuchen Sie noch einmal, auf die Website zuzugreifen.

Failback auf die verwalteten Instanzgruppen

Nachdem die Probleme mit den verwalteten Instanzgruppen behoben wurden, können Sie zum Inhalt der verwalteten Instanzgruppen mit Load-Balancing zurückkehren, indem Sie die Konfiguration der URL-Zuordnung noch einmal 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 die Konfiguration des Load-Balancers manuell.

  1. Aktualisieren Sie das HTTP-Proxy-Ziel, um die URL-Zuordnung für die verwalteten Instanzgruppen noch einmal zu verwenden:

    gcloud compute target-http-proxies update \
        http-lb-proxy-$NAME_SUFFIX \
        --url-map=web-map-http-$NAME_SUFFIX
    
  2. Verwenden Sie curl noch einmal oder öffnen Sie den Webbrowser, um auf die IP-Adresse des Load-Balancers zuzugreifen:

    curl $IP_ADDRESS
    

    Es kann einige Minuten dauern, bis der Load-Balancer die Konfiguration aktualisiert und den Traffic korrekt an Ihre verwalteten Instanzgruppen zurücksendet. Warten Sie gegebenenfalls einige Minuten und versuchen Sie noch einmal, auf die Website zuzugreifen.

    Die Hauptwebsite der verwalteten Instanzgruppen wird zurückgegeben, wie in der folgenden Beispielausgabe dargestellt:

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

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.

  1. Löschen Sie den Cloud Storage-Bucket:

    gsutil rm -r gs://static-web.$DOMAIN
    
  2. 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 url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet
    
    gcloud compute backend-services delete \
        web-backend-service-$NAME_SUFFIX --global --quiet
    
    gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet
    
  3. 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
    
  4. 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
    
  5. 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
    
  6. 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