Gérer la haute disponibilité dans Kubernetes

Sélectionnez une version de la documentation :

Cette page explique comment activer et tester la haute disponibilité sur votre cluster de bases de données AlloyDB Omni basé sur Kubernetes. Dans ce document, nous partons du principe que vous maîtrisez les bases de l'application des fichiers manifestes Kubernetes et de l'utilisation de l'outil de ligne de commande kubectl.

Présentation

Pour activer la haute disponibilité dans votre cluster de bases de données, configurez l'opérateur Kubernetes AlloyDB Omni afin de créer des instances répliquées de secours de votre instance de base de données principale. L'opérateur AlloyDB Omni configure votre cluster de base de données pour mettre à jour en continu les données de ce réplica et correspond à toutes les modifications de données apportées à votre instance principale.

Activer la haute disponibilité

Avant d'activer la haute disponibilité sur votre cluster de bases de données, assurez-vous que votre cluster Kubernetes possède les éléments suivants :

  • Espace de stockage pour deux copies complètes de vos données

  • Ressources de calcul pour deux instances de base de données s'exécutant en parallèle

Pour activer la haute disponibilité :

  1. Modifiez le fichier manifeste du cluster de bases de données pour inclure une section availability sous sa section spec. Cette section utilise le paramètre numberOfStandbys pour spécifier le nombre de nœuds de secours à ajouter.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Remplacez NUMBER_OF_STANDBYS par le nombre de serveurs de secours que vous souhaitez ajouter. La valeur maximale est de 5. Si vous ne savez pas combien de standbys vous avez besoin, commencez par définir la valeur sur 1 ou 2.

  2. Appliquez à nouveau le fichier manifeste.

Désactiver la haute disponibilité

Pour désactiver la haute disponibilité :

  1. Définissez numberOfStandbys sur 0 dans le fichier manifeste du cluster :

    spec:
  availability:
    numberOfStandbys: 0

  2. Appliquez à nouveau le fichier manifeste.

Vérifier la haute disponibilité sur un cluster de bases de données

Pour vérifier l'état de la haute disponibilité sur un cluster de bases de données, consultez son état HAReady. Si l'état de HAReady est True, la haute disponibilité est activée et fonctionne sur le cluster. Si la valeur est False, cela signifie que le service est activé, mais pas prêt, car il est en cours de configuration.

Pour vérifier l'état de HAReady à l'aide de la ligne de commande kubectl, exécutez la commande suivante :

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Remplacez les éléments suivants :

  • DB_CLUSTER_NAME : nom du cluster de base de données.

  • NAMESPACE : espace de noms du cluster de bases de données.

Basculer vers une instance de secours

Si votre instance principale devient indisponible pendant une période configurable, l'opérateur AlloyDB Omni bascule automatiquement de l'instance de base de données principale vers l'instance de secours. Les paramètres suivants déterminent le moment où un basculement automatique doit être lancé :

  • Délai entre les vérifications de l'état (30 secondes par défaut)

  • Nombre de vérifications de l'état consécutives ayant échoué (par défaut, 3)

Un basculement automatique démarre après le nombre spécifié de vérifications d'état consécutives ayant échoué, avec le délai spécifié entre chaque vérification de l'état d'état ayant échoué. Si les valeurs par défaut sont conservées, un basculement automatique se produit après trois échecs consécutifs de vérification de l'état#39;état, chacun espacé de 30 secondes.

Effectuer un basculement manuel est une bonne option lorsque vous souhaitez récupérer rapidement après une défaillance inattendue et réduire les temps d'arrêt.

L'opérateur AlloyDB Omni est compatible avec le basculement automatique et manuel. Le basculement automatique est activé par défaut.

Le basculement entraîne la séquence d'événements suivante :

  1. L'opérateur AlloyDB Omni met hors connexion l'instance de base de données principale.

  2. L'opérateur AlloyDB Omni promeut la réplique de secours en tant que nouvelle instance de base de données principale.

  3. L'opérateur AlloyDB Omni supprime l'instance de base de données principale précédente.

  4. L'opérateur AlloyDB Omni crée un réplica de secours.

Désactiver le basculement automatique

Les basculements automatiques sont activés par défaut sur les clusters de bases de données.

Pour désactiver le basculement automatique, procédez comme suit :

  1. Définissez enableAutoFailover sur false dans le fichier manifeste du cluster :

    spec:
  availability:
    enableAutoFailover: false

Ajuster les paramètres de déclenchement du basculement automatique

Vous pouvez utiliser les paramètres pour ajuster les basculements automatiques pour chaque cluster de bases de données.

L'opérateur AlloyDB Omni effectue régulièrement des vérifications de l'état de l'instance de base de données principale ainsi que de toutes les répliques de secours. La fréquence par défaut des vérifications de l'état est de 30 secondes. Si une instance atteint le seuil de déclenchement du basculement automatique, l'opérateur AlloyDB Omni déclenche un basculement automatique.

La valeur seuil correspond au nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'un basculement. Pour modifier la période de vérification de l'état de santé ou la valeur seuil, définissez les champs healthcheckPeriodSeconds et autoFailoverTriggerThreshold sur des valeurs entières dans le fichier manifeste du cluster :

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Remplacez les éléments suivants :

  • HEALTHCHECK_PERIOD : valeur entière indiquant le nombre de secondes à attendre entre chaque vérification de l'état#39;état. La valeur par défaut est 30. La valeur minimale est 1 et la valeur maximale est 86400 (équivalent à un jour).

  • AUTOFAILOVER_TRIGGER_THRESHOLD : valeur entière correspondant au nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'un basculement. La valeur par défaut est 3. La valeur minimale est 0. Il n'y a pas de valeur maximale. Si ce champ est défini sur 0, la valeur par défaut 3 est utilisée à la place.

Déclencher un basculement manuel

Pour déclencher un basculement manuel, créez et appliquez un manifeste pour une nouvelle ressource de basculement :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Remplacez les éléments suivants :

  • FAILOVER_NAME : nom de cette ressource (par exemple, failover-1).

  • NAMESPACE : espace de noms de cette ressource de basculement, qui doit correspondre à l'espace de noms du cluster de bases de données auquel elle s'applique.

  • DB_CLUSTER_NAME : nom du cluster de bases de données pour lequel effectuer le basculement.

Pour surveiller le basculement, exécutez la commande suivante :

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Remplacez les éléments suivants :

  • FAILOVER_NAME : nom que vous avez attribué à la ressource de basculement lors de sa création.

  • NAMESPACE : espace de noms du cluster de bases de données.

La commande renvoie Success une fois que la nouvelle instance de base de données principale est prête à être utilisée. Pour surveiller l'état de la nouvelle instance de secours, consultez la section suivante.

Basculer vers une instance de secours

La commutation est effectuée lorsque vous souhaitez tester votre configuration de reprise après sinistre ou toute autre activité planifiée nécessitant d'inverser les rôles de la base de données principale et de la réplique de secours.

Une fois la commutation terminée, le sens de la réplication et les rôles de l'instance de base de données principale et de la réplique de secours sont inversés. Utilisez les commutations pour mieux contrôler le test de votre configuration de reprise après sinistre sans perte de données.

L'opérateur AlloyDB Omni est compatible avec le basculement manuel. Un basculement entraîne la séquence d'événements suivante :

  1. L'opérateur AlloyDB Omni met hors connexion l'instance de base de données principale.

  2. L'opérateur AlloyDB Omni promeut la réplique de secours en tant que nouvelle instance de base de données principale.

  3. L'opérateur AlloyDB Omni transforme l'ancienne instance de base de données principale en réplica de secours.

Effectuer une commutation

Avant de commencer une permutation, procédez comme suit :

Pour effectuer un basculement, créez et appliquez un fichier manifeste pour une nouvelle ressource de basculement :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     newPrimary: STANDBY_REPLICA_NAME

Remplacez les éléments suivants :

  • SWITCHOVER_NAME : nom de cette ressource de bascule, par exemple switchover-1.

  • DB_CLUSTER_NAME : nom de l'instance de base de données principale à laquelle s'applique l'opération de basculement.

  • STANDBY_REPLICA_NAME : nom de l'instance de base de données que vous souhaitez promouvoir en tant que nouvelle instance principale.

    Pour identifier le nom de la réplique de secours, exécutez la commande suivante :

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Réparer automatiquement une instance de secours

Si une instance de secours devient indisponible, l'opérateur AlloyDB Omni la répare en supprimant l'ancienne instance répliquée de secours et en créant une nouvelle instance répliquée de secours pour la remplacer. Le délai par défaut pour déclencher une réparation automatique est de 90 secondes.

La réparation automatique du cluster de bases de données permet de maintenir une réplication saine et continue de la base de données principale.

Désactiver la réparation automatique de l'instance

Par défaut, la réparation automatique d'une instance de secours est activée sur les clusters de bases de données.

Pour désactiver les réparations automatiques :

  1. Dans le fichier manifeste du cluster, définissez enableAutoHeal sur false :

    spec:
  availability:
    enableAutoHeal: false

Ajuster les paramètres de déclenchement de la réparation automatique

Pour chaque cluster de bases de données, vous pouvez utiliser des paramètres pour ajuster les réparations automatiques.

L'opérateur AlloyDB Omni effectue régulièrement des vérifications de l'état que vous pouvez configurer. Pour en savoir plus, consultez Ajuster les paramètres de déclenchement du basculement automatique. Si une réplique de secours atteint le seuil de déclenchement de la réparation automatique, l'opérateur AlloyDB Omni déclenche une réparation automatique.

La valeur seuil correspond au nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'une réparation. Pour modifier la valeur du seuil, définissez autoHealTriggerThreshold dans le fichier manifeste du cluster :

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Remplacez les éléments suivants :

  • AUTOHEAL_TRIGGER_THRESHOLD : valeur entière indiquant le nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'une réparation. La valeur par défaut est 5. La valeur minimale est de 2 en raison d'éventuelles erreurs ponctuelles et temporaires lors des vérifications de l'état en mode veille.

Résoudre les problèmes de réparation d'instances

Si vous utilisez un grand nombre de clusters de bases de données dans un même cluster Kubernetes, ou si vos clusters de bases de données sont sous-provisionnés, la réparation automatique peut entraîner une indisponibilité de l'opérateur AlloyDB Omni ou des clusters de bases de données. Si vous recevez une erreur commençant par HealthCheckProber: health check for instance failed et faisant référence à un délai d'attente ou à un échec de connexion, essayez les correctifs recommandés suivants :

Voici des exemples d'erreurs qui peuvent être causées par une réparation automatique excessive. Ces exemples omettent les détails de l'environnement qui vous aident à identifier la source de l'erreur, comme le nom d'un cluster ou une adresse IP.

  • HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

Utiliser une instance répliquée de secours comme instance en lecture seule

Pour utiliser une réplique de secours comme instance en lecture seule, procédez comme suit :

  1. Définissez enableStandbyAsReadReplica sur true dans le fichier manifeste du cluster de bases de données :

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Appliquez à nouveau le fichier manifeste.

  3. Vérifiez que le point de terminaison en lecture seule est indiqué dans le champ status de l'objet DBCluster :

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    L'exemple de réponse suivant montre le point de terminaison de l'instance en lecture seule :

    Status:
[...]
Primary:
  [...]
  Endpoints:
    Name: Read-Write
    Value: 10.128.0.81:5432
    Name: Read-Only
    Value: 10.128.0.82:5432