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. Ce document suppose que vous connaissez les bases de l'application des fichiers manifestes Kubernetes et de l'utilisation de l'outil de ligne de commande kubectl.

Présentation

Vous activez la haute disponibilité dans votre cluster de bases de données en configurant l'opérateur Kubernetes AlloyDB Omni pour 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 bases de données pour mettre à jour en continu les données de cette instance répliquée et correspond à toutes les modifications de données de 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 dispose des éléments suivants :

  • 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é, procédez comme suit :

  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 d'instances répliquées de secours à ajouter.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Remplacez NUMBER_OF_STANDBYS par le nombre d'instances répliquées de secours que vous souhaitez ajouter. La valeur maximale est 5. Si vous n'êtes pas sûr du nombre d'instances répliquées de secours dont 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é, procédez comme suit :

  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, la haute disponibilité est activée, mais pas prête, car elle est en cours de configuration.

Pour vérifier l'état 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 bases 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 démarrer :

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

  • Nombre de vérifications d'é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 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, 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 l'instance répliquée 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 une instance répliquée 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 des paramètres pour ajuster les basculements automatiques pour chaque cluster de bases de données.

L'opérateur AlloyDB Omni émet des vérifications d'état régulières pour l'instance de base de données principale, ainsi que pour toutes les instances répliquées de secours. La fréquence par défaut des vérifications d'é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 avant le déclenchement d'un basculement. Pour modifier la période de vérification de l'état 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. 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 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 fichier 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 à basculer.

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 de permuter les rôles de la base de données principale et de l'instance répliquée 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 l'instance répliquée 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 la commutation manuelle. Une commutation 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 l'instance répliquée de secours en tant que nouvelle instance de base de données principale.

  3. L'opérateur AlloyDB Omni transforme l'instance de base de données principale précédente en instance répliquée de secours.

Effectuer une commutation

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

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

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 commutation, par exemple switchover-1.

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

  • 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 l'instance répliquée 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 répare l'instance en supprimant l'ancienne instance répliquée de secours et en créant une nouvelle instance répliquée de secours à sa place. 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 continue et saine 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, procédez comme suit :

  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 émet des vérifications d'état régulières que vous pouvez configurer. Pour en savoir plus, consultez Ajuster les paramètres de déclenchement du basculement automatique. Si une instance répliquée 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 avant le déclenchement d'une réparation. Pour modifier la valeur 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 correspondant au nombre d'échecs consécutifs de la vérification de l'état avant le déclenchement d'une réparation. La valeur par défaut est 5. La valeur minimale est 2 en raison d'éventuelles erreurs ponctuelles et temporaires lors des vérifications d'état de l'instance de secours.

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

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

Voici des exemples d'erreurs pouvant ê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, tels que 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 instance répliquée 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