Gestione dell'alta disponibilità

Seleziona una versione della documentazione:

Gestisci l'alta affidabilità per i cluster AlloyDB Omni per aggiungere resilienza a interruzioni ed errori tramite meccanismi di failover e ripristino automatici.

Configura la specifica di alta affidabilità

Per configurare l'alta affidabilità, inserisci le seguenti informazioni nella specifica DBCluster:

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

Sostituisci le seguenti variabili:

  • NUMBER_OF_STANDBYS: il numero di nodi di standby da configurare. Se imposti questo valore su 0, disabiliti l'alta affidabilità. Il valore massimo è 5. Se non sai quanti nodi di standby ti servono, inizia con 2 per un'elevata resilienza.

  • (Facoltativo) READ_ONLY_PORT: la porta sul bilanciatore del carico o sull'indirizzo IP virtuale utilizzato per l'endpoint di sola lettura di standby. Il valore predefinito è 5433 (porta principale più 1).

  • (Facoltativo) HEALTHCHECK_PERIOD: il numero di secondi da attendere tra ogni controllo di integrità. Il valore predefinito è 30. Il valore minimo è 1. Il valore massimo è 86400 (un giorno).

  • (Facoltativo) AUTOFAILOVER_TRIGGER_THRESHOLD: il numero di volte in cui il controllo di integrità può non riuscire prima che si verifichi un failover. Il valore predefinito è 3. Il valore minimo è 0, ma se il valore è impostato su 0, AlloyDB Omni utilizza il valore predefinito.

    Si verifica un failover automatico se il controllo di integrità non riesce AUTOFAILOVER_TRIGGER_THRESHOLD volte o per HEALTHCHECK_PERIOD * AUTOFAILOVER_TRIGGER_THRESHOLD secondi (90 secondi per impostazione predefinita).

  • (Facoltativo) AUTOHEAL_TRIGGER_THRESHOLD: il numero di volte in cui il controllo di integrità può non riuscire prima che inizi la riparazione automatica. Il valore predefinito è 5. Il valore minimo è 0, ma se il valore è impostato su 0, AlloyDB Omni utilizza il valore predefinito.

    Si verifica un ripristino automatico se il controllo di integrità non riesce AUTOHEAL_TRIGGER_THRESHOLD volte o per HEALTHCHECK_PERIOD * AUTOHEAL_TRIGGER_THRESHOLD secondi.

Verifica gli endpoint di standby di sola lettura

Quando imposti enableStandbyAsReadReplica: true, il bilanciatore del carico (indirizzo IP virtuale HAProxy e Keepalived) espone automaticamente un endpoint di sola lettura dedicato oltre all'endpoint di lettura/scrittura principale.

HAProxy instrada il traffico tra gli standby attivi nel seguente modo:

  • Esegue controlli di integrità su tutti i nodi di standby utilizzando GET /isstandby.
  • Distribuisce le query di lettura tra gli standby attivi utilizzando il bilanciamento del carico leastconn.
  • Aggiorna automaticamente il routing in caso di failover senza interrompere le connessioni client alla nuova topologia di standby.

Per verificare gli endpoint del cluster, esegui uno dei seguenti comandi:

alloydbctl

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

Sostituisci le seguenti variabili:

Ansible

  1. Crea un playbook Ansible per il ruolo google.alloydbomni_orchestrator.status. Ad esempio, 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

    Sostituisci le seguenti variabili:

    • STATUS_PLAYBOOK_NAME: il nome del playbook Ansible. Ad esempio, My cluster status.

    • ANSIBLE_USER: l'utente del sistema operativo che Ansible utilizza per accedere ai nodi AlloyDB Omni.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: la chiave privata che Ansible utilizza per connettersi ai nodi AlloyDB Omni tramite SSH.

  2. Esegui il playbook:

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

    Sostituisci le seguenti variabili:

Gli endpoint vengono segnalati in status.primary.endpoints:

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

Applica la specifica DBCluster

Per applicare la specifica DBCluster configurata, esegui uno dei seguenti comandi:

alloydbctl

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

Sostituisci le seguenti variabili:

Ansible

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

Sostituisci le seguenti variabili:

Esegui il cambio a un'istanza in standby

Puoi eseguire i cambi quando devi testare la configurazione di alta affidabilità o altre attività di manutenzione pianificate che richiedono di scambiare la replica principale e quella di standby. Una volta eseguito il cambio, la direzione della replica e i ruoli della replica principale e di standby vengono invertiti.

I cambi eseguono le seguenti azioni:

  1. L'orchestratore AlloyDB Omni mette offline la replica principale.

  2. L'orchestratore AlloyDB Omni promuove la replica di standby a nuova replica principale.

  3. L'orchestratore AlloyDB Omni converte la replica principale in una replica di standby.

  4. AlloyDB Omni avvia la replica di standby appena convertita.

Esegui un cambio

Per eseguire un cambio, completa i seguenti passaggi:

  1. Verifica che le istanze principale e di standby siano integre.

  2. Verifica che la status.phase di alta affidabilità sia Ready.

    alloydbctl

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

    Sostituisci le seguenti variabili:

    Ansible

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

    Sostituisci le seguenti variabili:

  3. Crea una specifica Switchover utilizzando il seguente formato:

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

    Sostituisci le seguenti variabili:

    • SWITCHOVER_NAME: il nome di questa specifica Switchover. Ad esempio, my-switchover-1. Questo nome deve essere univoco ogni volta che viene eseguito un cambio.

    • DBCLUSTER_NAME: il nome del cluster di database definito in Creare un cluster.

    • (Facoltativo) NEW_PRIMARY_NAME: l'istanza in standby che diventa la nuova istanza principale. Per mappare il nome dell'istanza a un host, consulta il campo instanceList nello stato del DBCluster a cui viene fatto riferimento.

  4. Se utilizzi Ansible, crea un playbook per la specifica Switchover.

    - 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

    Sostituisci le seguenti variabili:

    • SWITCHOVER_PLAYBOOK_NAME: il nome del playbook Ansible. Ad esempio, My Switchover.

    • ANSIBLE_USER: l'utente del sistema operativo che Ansible utilizza per accedere ai nodi AlloyDB Omni.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: la chiave privata che Ansible utilizza per connettersi ai nodi AlloyDB Omni tramite SSH.

  5. Applica la specifica Switchover.

    alloydbctl

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

    Sostituisci le seguenti variabili:

    • DEPLOYMENT_SPEC: il percorso della specifica di deployment creata in Installare i componenti di AlloyDB Omni.

    • SWITCHOVER_SPECIFICATION: il percorso della specifica Switchover creata nel passaggio 3.

    Ansible

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

    Sostituisci le seguenti variabili:

    • SWITCHOVER_PLAYBOOK: il percorso del playbook creato per il CRD Switchover nel passaggio 4.

    • DEPLOYMENT_SPEC: il percorso della specifica di deployment creata in Installare i componenti di AlloyDB Omni.

    • SWITCHOVER_SPECIFICATION: il percorso della specifica Switchover creata nel passaggio 3.

Bilanciatore del carico per l'alta affidabilità

Il bilanciatore del carico (HAProxy) raggiunge l'alta affidabilità accoppiando i suoi nodi con Keepalived e un IP virtuale. Keepalived utilizza il protocollo VRRP (Virtual Router Redundancy Protocol) per controllare un IP virtuale mobile. Le applicazioni client di database si connettono a questo IP virtuale anziché all'indirizzo IP del nodo di database.

Nelle configurazioni in cui non viene utilizzato un bilanciatore del carico dedicato, Keepalived viene installato direttamente sui nodi di database. In questo scenario, l'alta affidabilità viene raggiunta assegnando dinamicamente l'IP virtuale al nodo principale corrente, garantendo un failover senza interruzioni se la replica principale non è disponibile.

Per stabilire un'elezione stabile, Keepalived assegna le priorità VRRP ai nodi del cluster di database. Il primo nodo del bilanciatore del carico assume il ruolo principale con una priorità Keepalived più alta, ad esempio 110. I nodi successivi fungono da nodi secondari con una priorità inferiore, ad esempio 100.

Per assicurarsi che l'IP virtuale punti a un nodo integro, Keepalived esegue controlli di integrità continui ogni due secondi. In questo modo viene verificato lo stato del processo systemd HAProxy. Se il servizio HAProxy sulla replica principale non riesce, Keepalived esegue la migrazione dell'IP virtuale a un nodo secondario integro.

Se l'appartenenza al nodo di database cambia, HAProxy e Keepalived puntano automaticamente ai nuovi nodi di database attivi. La configurazione di routing sottostante viene aggiornata senza interrompere le connessioni client attive.

Configura il bilanciatore del carico

Per configurare l'IP virtuale per i nodi del bilanciatore del carico, aggiungi il seguente campo dbLoadBalancerOptions al campo primarySpec nella specifica DBCluster:

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

Sostituisci le seguenti variabili:

  • VIRTUAL_IP: l'indirizzo IP statico utilizzato per l'IP virtuale mobile. Le applicazioni client di database utilizzano l'indirizzo IP definito qui. Per assicurarti che Keepalived possa trasmettere correttamente gli ARP senza costi, questo indirizzo IP deve essere disponibile, non può essere di loopback e, nel caso di on-premise, appartiene alla stessa subnet delle interfacce del nodo principale.

  • VIRTUAL_IP_INTERFACE: l'interfaccia di rete in cui è configurato VIRTUAL_IP. Il valore predefinito è eth0.