Hochverfügbarkeit verwalten

Wählen Sie eine Dokumentationsversion aus:

Sie können die Hochverfügbarkeit für Ihre AlloyDB Omni-Cluster verwalten, um Ausfälle und Fehler durch automatisierte Failover- und Wiederherstellungsmechanismen zu minimieren.

Spezifikation für Hochverfügbarkeit konfigurieren

Geben Sie die folgenden Informationen in der DBCluster-Spezifikation an, um die Hochverfügbarkeit zu konfigurieren:

DBCluster:
  metadata:
    ...
  spec:
    ...
    readOnlyPort: READ_ONLY_PORT
    availability:
      numberOfStandbys: NUMBER_OF_STANDBYS
      enableStandbyAsReadReplica: true
      enableAutoFailover: true
      enableAutoHeal: true
      replayReplicationSlotsOnStandbys: true
      healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
      autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD
      autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Ersetzen Sie die folgenden Variablen:

  • NUMBER_OF_STANDBYS: Anzahl der Stand-by-Knoten, die eingerichtet werden sollen. Wenn Sie diesen Wert auf 0 setzen, wird die Hochverfügbarkeit deaktiviert. Der Höchstwert ist 5. Wenn Sie sich nicht sicher sind, wie viele Stand-by-Knoten Sie benötigen, beginnen Sie mit 2 für eine hohe Ausfallsicherheit.

  • (Optional) READ_ONLY_PORT: Der Port auf dem Load-Balancer oder der virtuellen IP-Adresse, der für den schreibgeschützten Stand-by-Endpunkt verwendet wird. Der Standardwert ist 5433 (primärer Port plus 1).

  • (Optional) HEALTHCHECK_PERIOD: Anzahl der Sekunden, die zwischen den einzelnen Systemdiagnosen gewartet werden soll. Der Standardwert ist 30. Der Mindestwert ist 1. Der Höchstwert ist 86400 (ein Tag).

  • (Optional) AUTOFAILOVER_TRIGGER_THRESHOLD: Anzahl der Male, die die Systemdiagnose fehlschlagen kann, bevor ein Failover ausgeführt wird. Der Standardwert ist 3. Der Mindestwert ist 0. Wenn der Wert jedoch auf 0 gesetzt ist, verwendet AlloyDB Omni den Standardwert.

    Ein automatisches Failover wird ausgeführt, wenn die Systemdiagnose AUTOFAILOVER_TRIGGER_THRESHOLD -mal oder für HEALTHCHECK_PERIOD * AUTOFAILOVER_TRIGGER_THRESHOLD Sekunden fehlschlägt (standardmäßig 90 Sekunden).

  • (Optional) AUTOHEAL_TRIGGER_THRESHOLD: Anzahl der Male, die die Systemdiagnose fehlschlagen kann, bevor die automatische Reparatur beginnt. Der Standardwert ist 5. Der Mindestwert ist 0. Wenn der Wert jedoch auf 0 gesetzt ist, verwendet AlloyDB Omni den Standardwert.

    Eine automatische Wiederherstellung wird ausgeführt, wenn die Systemdiagnose AUTOHEAL_TRIGGER_THRESHOLD -mal oder für HEALTHCHECK_PERIOD * AUTOHEAL_TRIGGER_THRESHOLD Sekunden fehlschlägt.

Schreibgeschützte Stand-by-Endpunkte prüfen

Wenn Sie enableStandbyAsReadReplica: true festlegen, stellt der Load-Balancer (HAProxy und virtuelle Keepalived-IP-Adresse) zusätzlich zum primären Lese-/Schreibendpunkt automatisch einen dedizierten schreibgeschützten Endpunkt bereit.

HAProxy leitet den Traffic wie folgt über aktive Stand-bys weiter:

  • Führt Systemdiagnosen auf allen Stand-by-Knoten mit GET /isstandby aus.
  • Verteilt Leseabfragen mit leastconn-Load-Balancing auf aktive Stand-bys.
  • Aktualisiert das Routing bei einem Failover automatisch, ohne die Clientverbindungen zur neuen Stand-by-Topologie zu trennen.

Führen Sie einen der folgenden Befehle aus, um die Clusterendpunkte zu prüfen:

alloydbctl

alloydbctl get -d "DEPLOYMENT_SPEC" -t DBCluster -n DBCLUSTER_NAME

Ersetzen Sie die folgenden Variablen:

Ansible

  1. Erstellen Sie ein Ansible-Playbook für die Rolle google.alloydbomni_orchestrator.status. Beispiel: status.yaml:

    - name: STATUS_PLAYBOOK_NAME
  hosts: localhost
  vars:
    ansible_user: ANSIBLE_USER
    ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
  roles:
  - role: google.alloydbomni_orchestrator.status

    Ersetzen Sie die folgenden Variablen:

    • STATUS_PLAYBOOK_NAME: Name des Ansible-Playbooks. Beispiel: My cluster status.

    • ANSIBLE_USER: Betriebssystemnutzer, mit dem sich Ansible in Ihre AlloyDB Omni-Knoten einloggt.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: Privater Schlüssel, mit dem sich Ansible über SSH mit Ihren AlloyDB Omni-Knoten verbindet.

  2. Führen Sie das Playbook aus:

    ansible-playbook status.yaml -i "DEPLOYMENT_SPEC" -e resource_type=DBCluster \
  -e resource_name=DBCLUSTER_NAME

    Ersetzen Sie die folgenden Variablen:

Die Endpunkte werden unter status.primary.endpoints gemeldet:

    - Read-Write: VIRTUAL_IP:5432
    - Read-Only: VIRTUAL_IP:5433

DBCluster-Spezifikation anwenden

Führen Sie einen der folgenden Befehle aus, um die konfigurierte DBCluster-Spezifikation anzuwenden:

alloydbctl

alloydbctl apply -d "DEPLOYMENT_SPEC" -r "DBCLUSTER_SPECIFICATION"

Ersetzen Sie die folgenden Variablen:

Ansible

ansible-playbook DBCLUSTER_PLAYBOOK -i "DEPLOYMENT_SPEC" \
      -e resource_spec="DBCLUSTER_SPECIFICATION"

Ersetzen Sie die folgenden Variablen:

  • RESTORE_PLAYBOOK: Pfad zum Playbook, das Sie für die DBCluster-CRD erstellt haben.

  • DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.

  • DBCLUSTER_SPECIFICATION: Pfad zur DBCluster Spezifikation, die Sie unter Cluster erstellen erstellt haben.

Switchover zur Stand-by-Instanz durchführen

Sie können Switchovers durchführen, wenn Sie die Einrichtung für Hochverfügbarkeit oder andere geplante Wartungsarbeiten testen müssen, bei denen das primäre und das Stand-by-Replikat getauscht werden müssen. Nach dem Switchover werden die Richtung der Replikation und die Rollen des primären und des Stand-by-Replikats umgekehrt.

Bei Switchovers werden die folgenden Aktionen ausgeführt:

  1. Der AlloyDB Omni-Orchestrator nimmt die primäre Instanz offline.

  2. Der AlloyDB Omni-Orchestrator stuft das Stand-by-Replikat zur neuen primären Instanz hoch.

  3. Der AlloyDB Omni-Orchestrator wandelt die primäre Instanz in ein Stand-by-Replikat um.

  4. AlloyDB Omni startet das neu konvertierte Stand-by-Replikat.

Switchover durchführen

So führen Sie einen Wechsel durch:

  1. Prüfen Sie, ob die primäre Instanz und das Stand-by-Replikat fehlerfrei sind.

  2. Prüfen Sie, ob die status.phase der Hochverfügbarkeit Ready ist.

    alloydbctl

    alloydbctl get -d "DEPLOYMENT_SPEC" -t DBCluster -n DBCLUSTER_SPECIFICATION -o yaml

    Ersetzen Sie die folgenden Variablen:

    Ansible

    ansible-playbook status.yaml -i DEPLOYMENT_SPEC -e resource_type=DBCluster \
  -e resource_name=DBCLUSTER_SPECIFICATION

    Ersetzen Sie die folgenden Variablen:

  3. Erstellen Sie eine Switchover-Spezifikation im folgenden Format:

    Switchover:
  metadata:
    name: SWITCHOVER_NAME
  spec:
    dbClusterRef: DBCLUSTER_NAME
    newPrimary: NEW_PRIMARY_NAME

    Ersetzen Sie die folgenden Variablen:

    • SWITCHOVER_NAME: Name für diese Switchover-Spezifikation. Beispiel: my-switchover-1. Dieser Name muss bei jedem Switchover eindeutig sein.

    • DBCLUSTER_NAME: Name des Datenbankclusters, den Sie unter Cluster erstellen definiert haben.

    • (Optional) NEW_PRIMARY_NAME: Die Stand-by-Instanz, die zur neuen primären Instanz wird. Informationen zum Zuordnen des Instanznamens zu einem Host finden Sie im Feld instanceList im Status des referenzierten DBCluster.

  4. Wenn Sie Ansible verwenden, erstellen Sie ein Playbook für die Switchover-Spezifikation.

    - name: SWITCHOVER_PLAYBOOK_NAME
  hosts: localhost
  vars:
    ansible_user: ANSIBLE_USER
    ansible_ssh_private_key_file: ANSIBLE_SSH_PRIVATE_KEY_FILE
  roles:
  - role: google.alloydbomni_orchestrator.switchover

    Ersetzen Sie die folgenden Variablen:

    • SWITCHOVER_PLAYBOOK_NAME: Name des Ansible-Playbooks. Beispiel: My Switchover.

    • ANSIBLE_USER: Betriebssystemnutzer, mit dem sich Ansible in Ihre AlloyDB Omni-Knoten einloggt.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: Privater Schlüssel, mit dem sich Ansible über SSH mit Ihren AlloyDB Omni-Knoten verbindet.

  5. Wenden Sie die Switchover-Spezifikation an.

    alloydbctl

    alloydbctl apply -d "DEPLOYMENT_SPEC" -r "SWITCHOVER_SPECIFICATION"

    Ersetzen Sie die folgenden Variablen:

    • DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.

    • SWITCHOVER_SPECIFICATION: Pfad zur Switchover-Spezifikation, die Sie in Schritt 3 erstellt haben.

    Ansible

    ansible-playbook SWITCHOVER_PLAYBOOK -i "DEPLOYMENT_SPEC" \
  -e resource_spec="SWITCHOVER_SPECIFICATION"

    Ersetzen Sie die folgenden Variablen:

    • SWITCHOVER_PLAYBOOK: Pfad zum Playbook, das Sie in Schritt 4 für die Switchover-CRD erstellt haben.

    • DEPLOYMENT_SPEC: Pfad zur Bereitstellungsspezifikation, die Sie unter AlloyDB Omni-Komponenten installieren erstellt haben.

    • SWITCHOVER_SPECIFICATION: Pfad zur Switchover-Spezifikation, die Sie in Schritt 3 erstellt haben.

Load-Balancer für Hochverfügbarkeit

Der Load-Balancer (HAProxy) erreicht Hochverfügbarkeit, indem seine Knoten mit Keepalived und einer virtuellen IP-Adresse gekoppelt werden. Keepalived verwendet das Virtual Router Redundancy Protocol (VRRP), um eine Floating-IP-Adresse zu steuern. Datenbankclientanwendungen stellen eine Verbindung zu dieser virtuellen IP-Adresse anstelle der IP-Adresse des Datenbankknotens her.

In Konfigurationen, in denen kein dedizierter Load-Balancer verwendet wird, wird Keepalived direkt auf den Datenbankknoten installiert. In diesem Szenario wird Hochverfügbarkeit erreicht, indem die virtuelle IP-Adresse dynamisch dem aktuellen primären Knoten zugewiesen wird. So ist ein nahtloses Failover möglich, wenn die primäre Instanz nicht mehr verfügbar ist.

Um eine stabile Wahl zu ermöglichen, weist Keepalived den Datenbankclusterknoten VRRP-Prioritäten zu. Der erste Load-Balancer-Knoten übernimmt die primäre Rolle mit einer höheren Keepalived-Priorität, z. B. 110. Nachfolgende Knoten fungieren als sekundäre Knoten mit einer niedrigeren Priorität, z. B. 100.

Damit die virtuelle IP-Adresse auf einen fehlerfreien Knoten verweist, führt Keepalived alle zwei Sekunden kontinuierliche Systemdiagnosen aus. So wird der Status des systemd-HAProxy-Prozesses geprüft. Wenn der HAProxy-Dienst auf der primären Instanz ausfällt, migriert Keepalived die virtuelle IP-Adresse zu einem fehlerfreien sekundären Knoten.

Wenn sich die Mitgliedschaft des Datenbankknotens ändert, verweisen HAProxy und Keepalived automatisch auf die neuen aktiven Datenbankknoten. Die zugrunde liegende Routingkonfiguration wird aktualisiert, ohne dass aktive Clientverbindungen getrennt werden.

Load-Balancer konfigurieren

Fügen Sie das folgende Feld dbLoadBalancerOptions dem Feld primarySpec in der DBCluster-Spezifikation hinzu, um die virtuelle IP-Adresse für die Load-Balancer-Knoten zu konfigurieren:

DBCluster:
  spec:
    primarySpec:
      ...
      dbLoadBalancerOptions:
        onprem:
          loadBalancerIP: "VIRTUAL_IP"
          loadBalancerType: "internal"
          loadBalancerInterface: "VIRTUAL_IP_INTERFACE"

Ersetzen Sie die folgenden Variablen:

  • VIRTUAL_IP: Statische IP-Adresse, die für die Floating-IP-Adresse verwendet wird. Datenbankclientanwendungen verwenden die hier definierte IP-Adresse. Damit Keepalived Gratuitous-ARPs erfolgreich senden kann, muss diese IP-Adresse verfügbar sein, darf keine Loopback-Adresse sein und muss im Fall von On-Premises-Umgebungen zum selben Subnetz wie die Schnittstellen des primären Knotens gehören.

  • VIRTUAL_IP_INTERFACE: Netzwerkschnittstelle, auf der VIRTUAL_IP konfiguriert ist. Der Standardwert ist eth0.