Gérer la haute disponibilité

Sélectionnez une version de la documentation :

Gérez la haute disponibilité de vos clusters AlloyDB Omni pour ajouter de la résilience aux pannes et aux défaillances grâce à des mécanismes de basculement et de récupération automatisés.

Configurer la spécification de haute disponibilité

Pour configurer la haute disponibilité, renseignez les informations suivantes dans votre spécification 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

Remplacez les variables suivantes :

  • NUMBER_OF_STANDBYS: nombre de nœuds de secours à configurer. Définir cette valeur sur 0 désactive la haute disponibilité. La valeur maximale est 5. Si vous ne savez pas de combien de nœuds de secours vous avez besoin, commencez par 2 pour une haute résilience.

  • (Facultatif) READ_ONLY_PORT : port de l'équilibreur de charge ou adresse IP virtuelle utilisée pour le point de terminaison en lecture seule de secours. La valeur par défaut est 5433 (port principal plus 1).

  • (Facultatif) HEALTHCHECK_PERIOD : nombre de secondes à attendre entre chaque vérification de l'état. La valeur par défaut est 30. La valeur minimale est 1. La valeur maximale est 86400 (un jour).

  • (Facultatif) AUTOFAILOVER_TRIGGER_THRESHOLD : nombre de fois où la vérification de l'état peut échouer avant qu'un basculement ne se produise. La valeur par défaut est 3. La valeur minimale est 0, mais si elle est définie sur 0, AlloyDB Omni utilise la valeur par défaut.

    Un basculement automatique se produit si la vérification de l'état échoue AUTOFAILOVER_TRIGGER_THRESHOLD fois ou pendant HEALTHCHECK_PERIOD * AUTOFAILOVER_TRIGGER_THRESHOLD secondes (90 secondes par défaut).

  • (Facultatif) AUTOHEAL_TRIGGER_THRESHOLD : nombre de fois où la vérification de l'état peut échouer avant le début de la réparation automatique. La valeur par défaut est 5. La valeur minimale est 0, mais si elle est définie sur 0, AlloyDB Omni utilise la valeur par défaut.

    Une récupération automatique se produit si la vérification de l'état échoue AUTOHEAL_TRIGGER_THRESHOLD fois ou pendant HEALTHCHECK_PERIOD * AUTOHEAL_TRIGGER_THRESHOLD secondes.

Vérifier les points de terminaison de secours en lecture seule

Lorsque vous définissez enableStandbyAsReadReplica: true, l'équilibreur de charge (adresse IP virtuelle HAProxy et Keepalived) expose automatiquement un point de terminaison en lecture seule dédié en plus du point de terminaison principal en lecture/écriture.

HAProxy achemine le trafic entre les secours actifs comme suit :

  • Exécute des vérifications d'état sur tous les nœuds de secours à l'aide de GET /isstandby.
  • Répartit les requêtes de lecture entre les secours actifs à l'aide de l'équilibrage de charge leastconn.
  • Met automatiquement à jour le routage lors du basculement sans abandonner les connexions client à la nouvelle topologie de secours.

Pour vérifier les points de terminaison de votre cluster, exécutez l'une des commandes suivantes :

alloydbctl

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

Remplacez les variables suivantes :

Ansible

  1. Créez un playbook Ansible pour le rôle google.alloydbomni_orchestrator.status. Par exemple, 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

    Remplacez les variables suivantes :

    • STATUS_PLAYBOOK_NAME: nom de votre playbook Ansible. Par exemple, My cluster status.

    • ANSIBLE_USER: utilisateur du système d'exploitation qu'Ansible utilise pour se connecter à vos nœuds AlloyDB Omni.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: clé privée qu'Ansible utilise pour se connecter à vos nœuds AlloyDB Omni à l'aide de SSH.

  2. Exécutez le playbook :

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

    Remplacez les variables suivantes :

Les points de terminaison sont signalés sous status.primary.endpoints :

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

Appliquer votre spécification DBCluster

Pour appliquer votre spécification DBCluster configurée, exécutez l'une des commandes suivantes :

alloydbctl

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

Remplacez les variables suivantes :

Ansible

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

Remplacez les variables suivantes :

  • RESTORE_PLAYBOOK: chemin d'accès au playbook que vous avez créé pour votre CRD DBCluster.

  • DEPLOYMENT_SPEC: chemin d'accès à la spécification de déploiement que vous avez créée dans Installer les composants AlloyDB Omni.

  • DBCLUSTER_SPECIFICATION: chemin d'accès à la spécification DBCluster que vous avez créée dans Créer un cluster.

Basculer vers une instance de secours

Vous pouvez effectuer des commutations lorsque vous devez tester votre configuration de haute disponibilité ou toute autre activité de maintenance planifiée nécessitant de permuter les répliques principale et de secours. Une fois la commutation effectuée, la direction de la réplication et les rôles des instances principale et de secours sont inversés.

Les commutations effectuent les actions suivantes :

  1. L'orchestrateur AlloyDB Omni met l'instance principale hors connexion.

  2. L'orchestrateur AlloyDB Omni promeut l'instance de secours en tant que nouvelle instance principale.

  3. L'orchestrateur AlloyDB Omni convertit l'instance principale en instance de secours.

  4. AlloyDB Omni démarre l'instance de secours nouvellement convertie.

Effectuer une commutation

Pour effectuer une commutation, procédez comme suit :

  1. Vérifiez que vos instances principale et de secours sont opérationnelles.

  2. Vérifiez que la status.phase de haute disponibilité est Ready.

    alloydbctl

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

    Remplacez les variables suivantes :

    Ansible

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

    Remplacez les variables suivantes :

  3. Créez une spécification Switchover au format suivant :

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

    Remplacez les variables suivantes :

    • SWITCHOVER_NAME: nom de cette spécification Switchover. Par exemple, my-switchover-1. Ce nom doit être unique chaque fois qu'une commutation est effectuée.

    • DBCLUSTER_NAME: nom de votre cluster de bases de données que vous avez défini dans Créer un cluster.

    • (Facultatif) NEW_PRIMARY_NAME : instance de secours qui devient la nouvelle instance principale. Pour mapper le nom de l'instance à un hôte, consultez le champ instanceList dans l'état du DBCluster référencé.

  4. Si vous utilisez Ansible, créez un playbook pour votre spécification 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

    Remplacez les variables suivantes :

    • SWITCHOVER_PLAYBOOK_NAME: nom de votre playbook Ansible. Par exemple, My Switchover.

    • ANSIBLE_USER: utilisateur du système d'exploitation qu'Ansible utilise pour se connecter à vos nœuds AlloyDB Omni.

    • ANSIBLE_SSH_PRIVATE_KEY_FILE: clé privée qu'Ansible utilise pour se connecter à vos nœuds AlloyDB Omni à l'aide de SSH.

  5. Appliquez votre spécification Switchover.

    alloydbctl

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

    Remplacez les variables suivantes :

    • DEPLOYMENT_SPEC: chemin d'accès à la spécification de déploiement que vous avez créée dans Installer les composants AlloyDB Omni.

    • SWITCHOVER_SPECIFICATION: chemin d'accès à la spécification Switchover que vous avez créée à l'étape 3.

    Ansible

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

    Remplacez les variables suivantes :

    • SWITCHOVER_PLAYBOOK: chemin d'accès au playbook que vous avez créé pour votre CRD Switchover à l'étape 4.

    • DEPLOYMENT_SPEC: chemin d'accès à la spécification de déploiement que vous avez créée dans Installer les composants AlloyDB Omni.

    • SWITCHOVER_SPECIFICATION: chemin d'accès à la spécification Switchover que vous avez créée à l'étape 3.

Équilibreur de charge pour la haute disponibilité

L'équilibreur de charge (HAProxy) assure une haute disponibilité en associant ses nœuds à Keepalived et à une adresse IP virtuelle. Keepalived utilise le protocole VRRP (Virtual Router Redundancy Protocol) pour contrôler une adresse IP virtuelle flottante. Les applications clientes de base de données se connectent à cette adresse IP virtuelle au lieu de l'adresse IP du nœud de base de données.

Dans les configurations où aucun équilibreur de charge dédié n'est utilisé, Keepalived est installé directement sur les nœuds de base de données. Dans ce scénario, la haute disponibilité est obtenue en attribuant dynamiquement l'adresse IP virtuelle au nœud principal actuel, ce qui garantit un basculement fluide si l'instance principale devient indisponible.

Pour établir une élection stable, Keepalived attribue des priorités VRRP aux nœuds du cluster de bases de données. Le premier nœud d'équilibreur de charge assume le rôle principal avec une priorité Keepalived plus élevée, par exemple 110. Les nœuds suivants agissent en tant que nœuds secondaires avec une priorité inférieure, par exemple 100.

Pour s'assurer que l'adresse IP virtuelle pointe vers un nœud opérationnel, Keepalived exécute des vérifications d'état continues toutes les deux secondes. Cela permet de vérifier l'état du processus systemd HAProxy. Si le service HAProxy sur l'instance principale échoue, Keepalived migre l'adresse IP virtuelle vers un nœud secondaire opérationnel.

Si l'appartenance du nœud de base de données change, HAProxy et Keepalived pointent automatiquement vers les nouveaux nœuds de base de données actifs. La configuration de routage sous-jacente est mise à jour sans abandonner les connexions client actives.

Configurer l'équilibreur de charge

Pour configurer l'adresse IP virtuelle des nœuds d'équilibreur de charge, ajoutez le champ dbLoadBalancerOptions suivant au champ primarySpec de votre spécification DBCluster :

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

Remplacez les variables suivantes :

  • VIRTUAL_IP: adresse IP statique utilisée pour l'adresse IP virtuelle flottante. Les applications clientes de base de données utilisent l'adresse IP définie ici. Pour vous assurer que Keepalived peut diffuser des ARP sans frais, cette adresse IP doit être disponible, ne pas pouvoir effectuer de bouclage et, dans le cas d'un environnement sur site, appartenir au même sous-réseau que vos interfaces de nœud principal.

  • VIRTUAL_IP_INTERFACE: interface réseau où VIRTUAL_IP est configuré. La valeur par défaut est eth0.