AlloyDB Omni-Hochverfügbarkeitscluster auf GCE-VMs mit RPM Orchestrator bereitstellen

1. Einführung

In diesem Codelab wird die Bereitstellung eines AlloyDB Omni-Hochverfügbarkeitsclusters (HA) auf Google Compute Engine-VMs (GCE) demonstriert. Am Ende dieses Codelabs haben Sie eine HA-Referenzarchitektur mit drei Datenbankknoten und zwei HAProxy-Knoten sowie einem Steuerknoten für Verwaltungsaufgaben bereitgestellt.

Voraussetzungen

  • Über die Cloud Console auf ein Google Cloud-Projekt und Cloud Shell zugreifen
  • Das Google Cloud SDK (gcloud) ist installiert und konfiguriert. Weitere Informationen zur Installation von gcloud finden Sie unter gcloud-install.
  • Terraform v1.9.8 ist installiert.

Lerninhalte

  • GCE-VMs für AlloyDB Omni erstellen und vorbereiten
  • So installieren und führen Sie den AlloyDB Omni RPM Orchestrator aus.
  • So installieren und konfigurieren Sie AlloyDB Omni-RPMs für die HA-Referenzarchitektur.

Voraussetzungen

  • URL-Link zu AlloyDB Omni-RPMs und RPM-Orchestrator abrufen Füllen Sie dazu das Anmeldeformular für AlloyDB Omni aus. Die Links werden an die E‑Mail-Adresse gesendet, die mit dem Server der Repository-URL verknüpft ist. Initialisieren Sie die folgenden Umgebungsvariablen, damit die URLs, die im Codelab verwendet werden, immer verfügbar sind.
    export ORCHESTRATOR_ANSIBLE_COLLECTION_PATH="..."
    export ALLOYDB_OMNI_REPOSITORY_URL="..."
    export ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL="..."
    export ALLOYDB_OMNI_COMMON_REPOSITORY_URL=....
    export ETCD_REPOSITORY_URL="..."
    
  • Ein funktionierendes Terminal mit Zugriff auf den AlloyDB Omni-Bereitstellungsstack. Sie können Cloud Shell für diesen Zweck verwenden.

2. Einrichtung und Anforderungen

Projekteinrichtung

Google Cloud-Projekt erstellen

  1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
  2. Die Abrechnung für das Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Symbol zum Aktivieren von Cloud Shell

Alternativ können Sie auch die Tasten „G“ und „S“ drücken. Wenn Sie sich in der Google Cloud Console befinden oder diesen Link verwenden, wird Cloud Shell durch diese Sequenz aktiviert.

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Google Cloud Shell-Terminal, das zeigt, dass die Umgebung verbunden ist

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 in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

3. Google Cloud Compute Engine-VMs erstellen

Terraform-Skripts vorbereiten

  1. Definieren Sie Umgebungsvariablen für Ihre Projekt-ID und den gewünschten Clusternamen. Sie werden im gesamten Codelab verwendet.
    export PROJECT="your-project-id"
    export CLUSTER="your-cluster-name"
    
    Hinweis: Die Google Cloud-Projekt-ID sollte nur zwischen 6 und 30 Zeichen lang sein. Weitere Informationen finden Sie unter https://docs.cloud.google.com/resource-manager/docs/creating-managing-projects#before_you_begin.
  2. Achten Sie darauf, dass Sie mit einem Google Cloud-Konto angemeldet sind.
    gcloud auth login
    
  3. Erstellen Sie ein Arbeitsverzeichnis für die Bereitstellung und kopieren Sie die erforderlichen Terraform-Konfigurationsdateien aus der Repository-Quelle.
    mkdir -p ~/alloydb-omni/$PROJECT/$CLUSTER
    cd ~/alloydb-omni/$PROJECT/$CLUSTER
    gcloud storage cp gs://alloydb-omni-install/rpm-orchestrator/gce/terraform/*.tf .
    
  4. Erstellen Sie eine terraform.tfvars-Datei, um die erforderlichen Parameter gemäß der Referenzarchitektur anzugeben. Verwenden Sie dazu den folgenden Inhalt:
    cat > terraform.tfvars <<EOF
    # Required instance counts for reference architecture
    db_instance_count      = 3
    haproxy_instance_count = 2
    control_instance_count = 1
    
    # Optional: Customize if needed with the below variables
    # os_image             = "rocky-linux-cloud/rocky-linux-9"
    # zone                 = "us-west4-c"
    # region_1             = "us-west4"
    # db_instance_type     = "c4-highmem-4"
    # db_disk_type         = "hyperdisk-balanced"
    # db_data_size         =  "50" # GB
    # data_dir             =  "/data"
    EOF
    

Terraform-Skripts ausführen und validieren

  1. Sie können die VMs jetzt bereitstellen.
    terraform init
    
  2. Bevor Sie VMs erstellen, müssen Sie sicherstellen, dass Sie den erforderlichen Zugriff zum Erstellen von VMs und anderen Ressourcen haben. Zusammenfassend benötigen Sie die folgenden Berechtigungen.
    roles/compute.admin
    roles/iam.roleAdmin
    roles/compute.osAdminLogin
    roles/iam.serviceAccountCreator
    roles/iam.serviceAccountUser
    roles/artifactregistry.repoAdmin
    roles/storage.objectUser
    roles/resourcemanager.projectIamAdmin
    roles/serviceusage.serviceUsageAdmin
    
  3. Validieren Sie die Konfiguration und wenden Sie sie an, um die Ressourcen bereitzustellen.
    terraform validate
    terraform apply --auto-approve
    
    Hinweis: Achten Sie darauf, dass Sie Terraform v1.9.8 verwenden, wie in der Bereitstellungskonfiguration erwartet.
  4. Wenn Terraform abgeschlossen ist, prüfen Sie, ob die VMs erfolgreich erstellt wurden. Dazu können Sie die erstellten Instanzen mit gcloud auflisten.
    gcloud compute instances list --filter="name~$CLUSTER" --project=$PROJECT
    
    Sie sollten Instanzen sehen, die Ihren drei DB-Knoten, zwei HAProxy-Knoten und der Steuerungs-VM und den entsprechenden Zonen entsprechen. Notieren Sie die ZONE für den Steuerknoten. Wir benötigen sie später in diesem Codelab.
    export ZONE=$(gcloud compute instances list \
      --filter="name=$CLUSTER-control"          \
      --format="value(zone)" --project=$PROJECT)
    

4. VMs für die Bereitstellung vorbereiten

Sie müssen eine SSH-Sitzung zum Steuerungsknoten erstellen und Schritte ausführen, um den SSH-Zugriff auf alle VMs (auch als Knoten bezeichnet) zu aktivieren.

  1. Prüfen Sie, ob die Umgebungsvariablen für Ihr Projekt und Ihren Cluster definiert sind.
    export PROJECT="your-project-id"
    export CLUSTER="your-cluster-name"
    
  2. Erstellen Sie einen SSH-Schlüssel und fügen Sie ihn hinzu, um sich bei der Kontroll-VM anzumelden.
    # Replace values with your specific GCP project, cluster and zone details
    ssh-keygen -t ed25519 -f $HOME/.ssh/google_compute_engine
    gcloud compute os-login ssh-keys add --key-file=$HOME/.ssh/google_compute_engine.pub --project=$PROJECT
    
  3. Erstellen Sie eine Firewallregel, die SSH-Verbindungen und VRRP-Traffic zulässt.
    gcloud compute config-ssh --project=$PROJECT
    gcloud compute firewall-rules create $CLUSTER-allow-ssh --network=$CLUSTER --project=$PROJECT --direction=INGRESS --action=allow --rules=tcp:22 --source-ranges="0.0.0.0/0"
    gcloud compute firewall-rules create $CLUSTER-allow-vrrp --network=$CLUSTER --project=$PROJECT --allow=112 --source-ranges="0.0.0.0/0"
    
  4. Stellen Sie eine SSH-Verbindung zur Kontroll-VM her:
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
    
  5. Erstellen Sie auf dem Kontrollknoten eine Linux-Gruppe mit demselben Namen wie der Nutzername:
    sudo groupadd $(id -un)
    sudo usermod -aG $(id -un) $(id -un)
    
  6. Beim Einrichten von Terraform werden einige Konfigurationsskripts erstellt und im Verzeichnis /tmp/ der Steuerungs-VM bereitgestellt. Dazu gehören unter anderem Clustername, Dienstkonto und Projektname. Erstellen Sie mithilfe von Einrichtungs-Skripts auf dem Steuerknoten einen passwortlosen SSH-Zugriff von den Steuerknoten auf alle Clusterknoten.
    /tmp/setup-ssh-for-cluster.sh
    
    Wichtig: Notieren Sie sich den service_account-Nutzer. Wir verwenden dies später in diesem Codelab als SSH_USER.
  7. Für dieses Codelab können wir SELinux auf allen Knoten deaktivieren. Das Terraform-Script fügt „/tmp/run-all.sh“ hinzu, das für diesen Zweck verwendet werden kann.
    /tmp/run-all.sh sudo setenforce 0
    
  8. Wenn Sie sich für AlloyDB Omni registriert und die Links erhalten haben, müssen Sie diese URLs auch Umgebungsvariablen hinzufügen.
    cat >> ~/.codelab.env <<EOF
    export ORCHESTRATOR_ANSIBLE_COLLECTION_PATH="..."
    export ALLOYDB_OMNI_REPOSITORY_URL="..."
    export ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL="..."
    export ALLOYDB_OMNI_COMMON_REPOSITORY_URL=....
    export ETCD_REPOSITORY_URL="..."
    EOF
    
    Wählen Sie eine virtuelle IP-Adresse für Ihre Umgebung aus der Eingabevariable „cidr_range“ in der Datei terraform/variables.tf aus, die nicht mit den anderen Knoten in Konflikt steht. Beispiel:
    cat >> ~/.codelab.env <<EOF
    export VIRTUAL_IP="10.1.0.50"
    EOF
    

5. Erforderliche Softwarekomponenten auf allen VMs installieren

Im nächsten Schritt installieren Sie die erforderlichen Softwarekomponenten auf den VMs. Dies kann auf dem Steuerknoten koordiniert werden. Alle folgenden Befehle müssen auf dem Steuerknoten ausgeführt werden.

  1. Stellen Sie über SSH eine Verbindung zur Kontroll-VM her, falls Sie sich noch nicht auf dem Kontrollknoten befinden.
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
    
    Wenn Sie sich an der SSH-Eingabeaufforderung der Kontroll-VM befinden, geben Sie die Quellumgebungsdatei ein.
    source ~/.codelab.env
    
  2. Installieren Sie auf dem Steuerknoten Ansible und die erforderlichen Python-Bibliotheken.
    sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm -y
    sudo dnf install -y ansible
    sudo dnf install -y python3-grpcio python3-protobuf python3-googleapis-common-protos python3-grpcio-status
    
  3. Laden Sie als Nächstes die TAR-Datei für die RPM Orchestrator Ansible-Sammlung herunter und installieren Sie sie.
    gcloud storage cp "gs://${ORCHESTRATOR_ANSIBLE_COLLECTION_PATH#https://storage.googleapis.com/}google-alloydbomni_orchestrator-*.tar.gz" .
    ansible-galaxy collection install google-alloydbomni_orchestrator-0.1.0-6.tar.gz
    ansible-galaxy collection list | grep alloydbomni_orchestrator
    
    Hinweis: Die Variable ORCHESTRATOR_ANSIBLE_COLLECTION_PATH muss am Ende „/“ enthalten.
  4. Der Orchestrator verwendet eine Bereitstellungsspezifikationsdatei im Ansible-Inventarformat, um die Clustertopologie zu verstehen. Erstellen Sie auf dem Steuerknoten eine Datei mit dem Namen deployment_spec.yaml mit den Knotendetails.
    cat > deployment_spec.yaml <<EOF
    alloydbomni:
      vars:
        cluster_manager:
          name: "$CLUSTER"
        etcd:
          setup: true
          config_forcewrite: true
        alloydbomni:
          major_version: "18"
          repo_url: $ALLOYDB_OMNI_REPOSITORY_URL
        alloydbomni_monitor:
          repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL
        alloydbomni_cluster_manager:
          repo_url: $ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL
        alloydbomni_node_manager:
          repo_url: $ALLOYDB_OMNI_ORCHESTRATOR_REPOSITORY_URL
        pgbouncer:
          repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL
        pgbackrest:
          repo_url: $ALLOYDB_OMNI_COMMON_REPOSITORY_URL
    
      children:
        primary_instance_nodes:
          hosts:
            $CLUSTER-db1:
            $CLUSTER-db2:
            $CLUSTER-db3:
        load_balancer_nodes:
          hosts:
            $CLUSTER-haproxy1:
            $CLUSTER-haproxy2:
    EOF
    
    Hinweis: Prüfen Sie die generierte Datei, um sicherzustellen, dass sie auf gültige Werte verweist.
  5. Erstellen Sie ein Playbook mit dem Namen install.yaml, das auf die Installationsrolle aus der Orchestrator-Sammlung verweist.
    cat > install.yaml <<EOF
    - name: Install AlloyDB Omni cluster components
      hosts: all
      vars:
        ansible_become: true
        ansible_user: $SSH_USER
        ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
      roles:
        - role: google.alloydbomni_orchestrator.install
    EOF
    
    Hinweis: Prüfen Sie die generierte Datei, um sicherzustellen, dass sie auf gültige Werte verweist.
  6. Führen Sie das Playbook mit Ihrer Inventardatei aus, um die RPMs auf allen angegebenen Knoten herunterzuladen und zu installieren.
    ansible-playbook -i deployment_spec.yaml install.yaml
    

6. AlloyDB Omni-Cluster booten

In dieser Phase haben wir alle erforderlichen Komponenten auf allen Knoten installiert. Wir sind bereit, den AlloyDB Omni-Cluster zu booten.

  1. Stellen Sie über SSH eine Verbindung zur Kontroll-VM her, falls Sie sich noch nicht auf dem Kontrollknoten befinden.
    gcloud compute ssh "$CLUSTER-control" --zone=$ZONE --project=$PROJECT
    
    Wenn Sie sich an der SSH-Eingabeaufforderung der Kontroll-VM befinden, geben Sie die Quellumgebungsdatei ein.
    source ~/.codelab.env
    
  2. Generieren Sie einen Hash für Ihr Passwort und notieren Sie ihn.
    encoded_password=$(echo -n "your unique password" | base64)
    
  3. Damit ein Cluster erstellt werden kann, muss AlloyDB Omni wissen, wie er konfiguriert werden soll. Erstellen Sie einen Dateinamen dbcluster.yaml für die Spezifikationen des DB-Clusters.
    cat > dbcluster.yaml <<EOF
    Secret:
      metadata:
        name: db-pw-$CLUSTER
      spec:
        type: Opaque
        data:
          $CLUSTER: $encoded_password
    ---
    DBCluster:
      metadata:
        name: $CLUSTER
      spec:
        databaseVersion: 18.1.0
        mode: ""
        availability:
          numberOfStandbys: 2
          enableAutoFailover: true
          enableAutoHeal: true
          autoFailoverTriggerThreshold: 2
          autoHealTriggerThreshold: 2
          healthcheckPeriodSeconds: 5
          replayReplicationSlotsOnStandbys: false
        primarySpec:
          adminUser:
            passwordRef:
              name: db-pw-$CLUSTER
          resources:
            cpu: 4
            memory: 32Gi
            disks:
            - name: DataDisk
              path: $PGDATA
          dbLoadBalancerOptions:
            gcp:
              loadBalancerIP: "$VIRTUAL_IP"
              loadBalancerType: "internal"
              loadBalancerInterface: "eth0"
    EOF
    
  4. Erstellen Sie ein Playbook mit dem Namen bootstrap.yaml, das auf die Bootstrap-Ansible-Rolle zum Erstellen des AlloyDB Omni-Clusters verweist.
    cat > bootstrap.yaml <<EOF
    - name: Create DBCluster
      hosts: localhost
      vars:
        ansible_become: true
        ansible_user: $SSH_USER
        ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
      roles:
      - role: google.alloydbomni_orchestrator.bootstrap
    EOF
    
  5. Playbook ausführen, um Cluster zu erstellen
    ansible-playbook bootstrap.yaml -i deployment_spec.yaml -e resource_spec=dbcluster.yaml
    

7. Optional: PgBouncer-Verbindungspooler konfigurieren

AlloyDB Omni unterstützt einfaches Verbindungs-Pooling mit PgBouncer. Sie können PgBouncer direkt nach der Bereitstellung des Clusters konfigurieren und booten.

  1. Erstellen Sie eine Ressourcenspezifikationsdatei namens pgbouncer.yaml, die den Connection Pooler mit Ihrem Datenbankcluster verknüpft:
    cat > pgbouncer.yaml <<EOF
    PgBouncer:
      metadata:
        name: pgbouncer-pooler
      spec:
        dbclusterRef: $CLUSTER
        allowSuperUserAccess: true
        accessMode: "rw"
        port: 6432
    EOF
    
  2. Bootstrappen Sie den PgBouncer-Pooler mit demselben bootstrap.yaml-Playbook, das Sie zuvor erstellt haben, und übergeben Sie die neue Spezifikationsdatei:
    ansible-playbook bootstrap.yaml -i deployment_spec.yaml -e resource_spec=pgbouncer.yaml
    

8. AlloyDB Omni-Cluster prüfen

Um zu prüfen, ob Ihr Cluster richtig funktioniert und über den Load-Balancer zugänglich ist, können Sie über den Knoten „control“ mit dem Standard-PostgreSQL-Client eine Verbindung zu ihm herstellen.

  1. Installieren Sie das PostgreSQL 18-Client-Repository und -Paket auf dem Steuerknoten:
    sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
    sudo dnf install -y postgresql18
    
  2. Stellen Sie mit der zuvor reservierten virtuellen IP-Adresse eine Verbindung zum Cluster her. Sie werden aufgefordert, das Passwort einzugeben, das Sie in dbcluster.yaml codiert haben:
    /usr/pgsql-18/bin/psql -h $VIRTUAL_IP -U postgres -W
    
  3. Sobald die Verbindung hergestellt ist, können Sie grundlegende SQL-Abfragen ausführen, um den Clusterstatus zu prüfen, z. B. die Datenbankversion:
    postgres=# SELECT version();
    
    Sie sollten eine Ausgabe sehen, die darauf hinweist, dass PostgreSQL 18 mit AlloyDB Omni ausgeführt wird. Geben Sie \q ein, um den Prompt zu beenden.

9. Optional: Daten mit pgBackRest sichern

AlloyDB Omni ist in pgBackRest integriert, um Sicherungen direkt in Cloud Storage zu verwalten. Sie können einen Sicherungsplan konfigurieren und eine On-Demand-Sicherung für den GCS-Bucket auslösen, der durch Ihre Terraform-Einrichtung erstellt wurde.

  1. Erstellen Sie eine Spezifikationsdatei für den Sicherungsplan namens backup_plan.yaml, die auf den bereitgestellten GCS-Bucket verweist:
    cat > backup_plan.yaml <<EOF
    BackupPlan:
      metadata:
        name: pgb-plan
      spec:
        dbclusterRef: $CLUSTER
        backupLocation:
          type: GCS
          gcsOptions:
            bucket: $CLUSTER-gcs-backups
            key: /backups
    EOF
    
  2. Erstellen Sie ein Ansible-Playbook mit dem Namen backup.yaml, das auf die Rolle für die Sicherungsverwaltung verweist:
    cat > backup.yaml <<EOF
    - name: Manage AlloyDB Omni Backups
      hosts: localhost
      vars:
        ansible_become: true
        ansible_user: $SSH_USER
        ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
      roles:
        - role: google.alloydbomni_orchestrator.backup
    EOF
    
  3. Wenden Sie den Sicherungsplan mit dem Playbook backup.yaml an:
    ansible-playbook backup.yaml -i deployment_spec.yaml -e resource_spec=backup_plan.yaml
    
  4. Nachdem der Plan erfolgreich eingerichtet wurde, erstellen Sie eine On-Demand-Sicherungsressourcendatei mit dem Namen create_backup.yaml.
    cat > create_backup.yaml <<EOF
    Backup:
      metadata:
        name: on-demand-backup
      spec:
        backupPlanRef: pgb-plan
        dbclusterRef: $CLUSTER
    EOF
    
  5. Führen Sie das Playbook aus, um die Sicherung zu starten:
    ansible-playbook backup.yaml -i deployment_spec.yaml -e resource_spec=create_backup.yaml
    
  6. So prüfen Sie den Status des Backups: Erstellen Sie ein status.yaml-Playbook:
- name: Fetch AlloyDB Omni Resource Status
hosts: localhost
vars:
  ansible_become: true
  ansible_user: $SSH_USER
  ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
roles:
  - role: google.alloydbomni_orchestrator.status
EOF
  1. Führen Sie das Playbook aus, um alle Sicherungen aufzulisten:
ansible-playbook status.yaml -i deployment_spec.yaml -e resource_type=Backup
  1. Alternativ können Sie -e resource_name=on-demand-backup übergeben, um detaillierte Informationen zu einer bestimmten Sicherung zu erhalten, die zuvor erstellt wurde:
ansible-playbook status.yaml -i deployment_spec.yaml \
  -e resource_type=Backup \
  -e resource_name=on-demand-backup

10. Ressourcen bereinigen

Wenn Sie die Bereitstellung abgeschlossen haben, können Sie die bereitgestellten Ressourcen löschen, um Kosten zu vermeiden.

  1. Erstellen Sie ein Playbook mit dem Namen teardown.yaml:
    cat > teardown.yaml <<EOF
    - name: Tear down AlloyDB Omni cluster
      hosts: localhost
      vars:
        ansible_become: true
        ansible_user: $SSH_USER
        ansible_ssh_private_key_file: $HOME/ssh-key-cluster-sa
      roles:
      - role: google.alloydbomni_orchestrator.delete
    EOF
    
  2. Führen Sie das Playbook mit „ansible-playbook“ aus. Wenn Sie Sicherungen konfiguriert haben, löschen Sie zuerst die Backup- und BackupPlan-Ressourcen:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=Backup" -e "resource_name=on-demand-backup"
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=BackupPlan" -e "resource_name=pgb-plan"
    
    Wenn Sie PgBouncer konfiguriert haben, löschen Sie als Nächstes die Verbindungspooler-Ressource:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=PgBouncer" -e "resource_name=pgbouncer-pooler"
    
    Geben Sie dann „DBCluster“ als „resource_type“ an und löschen Sie den Datenbankcluster selbst:
    ansible-playbook teardown.yaml -i deployment_spec.yaml  -e "resource_type=DBCluster" -e "resource_name=$CLUSTER"
    
  3. Sobald der Cluster gelöscht wurde, melden Sie sich vom Steuerknoten ab, wechseln Sie zurück zum Terminal und rufen Sie Ihr Terraform-Arbeitsverzeichnis auf.
    Hinweis: Wenn Sie sich gerade erst in der Cloud Shell angemeldet haben, müssen Sie Folgendes festlegen:
    export PROJECT="your-project-id"
    export CLUSTER="your-cluster-name"
    
  4. Löschen Sie die VRRP-Firewallregel und löschen Sie die von Terraform verwalteten Ressourcen:
    gcloud compute firewall-rules delete -q "$CLUSTER-allow-vrrp" --project="$PROJECT"
    gcloud compute firewall-rules delete -q "$CLUSTER-allow-ssh" --project="$PROJECT"
    terraform destroy
    
  5. Bestätigen Sie die Vernichtung, wenn Sie dazu aufgefordert werden. Da verbleibende Netzwerkressourcen oder Routen gelegentlich ein vollständiges Entfernen verhindern können, führen Sie die folgenden sicheren Bereinigungsbefehle aus, um sicherzustellen, dass alle zugehörigen Firewallregeln, NAT-Gateways, Router, Routen, Subnetze und Netzwerke vollständig entfernt werden. Ersetzen Sie REGION durch Ihre spezifische Bereitstellungsregion, z. B. „us-central1“:
    # Delete any remaining firewall rules associated with the cluster
    gcloud compute firewall-rules list --project=$PROJECT 2> /dev/null | grep ^$CLUSTER- | cut -f1 -d' ' | \
      while read rule; do gcloud compute firewall-rules delete --project=$PROJECT --quiet $rule; done
    
    # Delete the Cloud NAT gateway and router if they still exist
    gcloud compute routers nats describe $CLUSTER-nat-gw --router=$CLUSTER-router --region=REGION --project=$PROJECT 2>/dev/null \
      && gcloud compute routers nats delete $CLUSTER-nat-gw --router=$CLUSTER-router --region=REGION --project=$PROJECT --quiet
    
    gcloud compute routers describe $CLUSTER-router --region=REGION --project=$PROJECT 2>/dev/null \
      && gcloud compute routers delete $CLUSTER-router --region=REGION --project=$PROJECT --quiet
    
    # Delete any remaining custom routes
    gcloud compute routes list --project=$PROJECT --filter="network:$CLUSTER" --format="value(name)" 2>/dev/null | \
      while read route; do gcloud compute routes delete --project=$PROJECT --quiet $route 2>/dev/null || true; done
    
    # Delete the subnet and network if they still exist
    gcloud compute networks subnets describe $CLUSTER --region=REGION --project=$PROJECT 2>/dev/null \
      && gcloud compute networks subnets delete $CLUSTER --region=REGION --project=$PROJECT --quiet
    
    gcloud compute networks describe $CLUSTER --project $PROJECT 2> /dev/null \
      && gcloud compute networks delete $CLUSTER --project $PROJECT --quiet
    

11. Glückwunsch

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

  • GCE-VMs für AlloyDB Omni erstellen und vorbereiten
  • So installieren und führen Sie den AlloyDB Omni RPM Orchestrator aus.
  • So installieren und konfigurieren Sie AlloyDB Omni-RPMs für die HA-Referenzarchitektur.

Weitere Informationen zu AlloyDB Omni finden Sie in der Dokumentation.

12. Umfrage

Wie werden Sie diese Anleitung verwenden?

Nur durchlesen Lesen und Übungen machen