Options de haute disponibilité avec des disques persistants régionaux

Ce document explique comment créer des services à haute disponibilité à l'aide de disques persistants régionaux. Pour cela, il vous présentera différentes options permettant d'augmenter la disponibilité des services et comparera les coûts, les performances et la résilience de différentes architectures de services. Il décrit en outre quelques types de défaillances et actions de reprise pour vous aider à déterminer si les disques persistants régionaux constituent la solution idéale pour votre service à haute disponibilité.

Le disque persistant régional permet une réplication synchrone des données entre deux zones d'une même région. Les disques persistants régionaux peuvent donc vous aider dans l'implémentation de services à haute disponibilité dans Compute Engine.

L'avantage des disques persistants régionaux est qu'en cas de défaillance de zone, qui pourrait rendre votre instance de VM indisponible, vous pouvez associer de force un disque persistant régional à une instance de VM située dans une zone secondaire de la même région. Pour effectuer cette tâche, vous devez soit démarrer une autre instance de VM dans la même zone que le disque persistant régional que vous souhaitez associer de force, soit garder une instance de VM de secours dans cette zone. Un système de secours à chaud (hot standby) est une instance de VM en cours d'exécution qui est identique à celle que vous utilisez. Les deux instances ont les mêmes données.

L'opération d'association forcée s'exécute en moins d'une minute, ce qui permet d'atteindre un objectif de temps de récupération (RTO) en quelques minutes. Le RTO total dépend non seulement du basculement du stockage (l'association forcée du disque persistant régional), mais aussi du besoin de créer une instance de VM secondaire au préalable, de la durée pendant laquelle le système de fichiers sous-jacent détecte le disque associé au système de secours, du temps de récupération des applications correspondantes, ainsi que d'autres facteurs.

Considérations de conception

Avant de commencer à concevoir un service à haute disponibilité, vous devez connaître les caractéristiques de l'application, du système de fichiers et du système d'exploitation. Ces caractéristiques constituent la base du travail de conception et peuvent vous aider à écarter certaines approches. Par exemple, si une application n'est pas compatible avec la réplication au niveau de l'application, les options de conception correspondantes deviennent alors non applicables.

De même, si l'application, le système de fichiers ou le système d'exploitation ne tolèrent pas les plantages, l'utilisation de disques persistants régionaux ou d'instantanés de disques persistants zonaux ne peut pas être envisagée. La tolérance aux plantages est définie comme la possibilité de se remettre d'une interruption soudaine sans perdre ni corrompre les données déjà validées sur un disque persistant avant le plantage.

Réfléchissez aux éléments suivants :

  1. Sachez quel sera l'impact sur les performances des applications et des opérations d'écriture.
  2. Déterminez l'objectif de temps de récupération du service. Prenez connaissance de la rapidité avec laquelle votre service doit se remettre d'une panne de zone, ainsi que des exigences du contrat de niveau de service.
  3. Comprenez à combien revient la conception d'une architecture de service résiliente et fiable. En termes de coût, les options qui s'offrent à vous pour la réplication synchrone et la réplication asynchrone des applications sont les suivantes :

    Utiliser deux instances de la base de données et de la VM. Dans ce cas, les éléments suivants déterminent le coût total :

    • Coût des instances de VM
    • Coût des disques persistants
    • Coûts liés à la gestion de la réplication des applications

    Pour obtenir une haute disponibilité avec un disque persistant régional, utilisez les mêmes composants d'instances de VM et de disques persistants, mais incluez également un disque persistant régional. Les disques persistants régionaux coûtent deux fois plus par octet que les disques persistants zonaux, car ils sont répliqués dans deux zones.

    Toutefois, le fait d'utiliser des disques persistants régionaux peut réduire vos coûts de maintenance, car les données sont automatiquement répliquées sur deux instances dupliquées sans avoir à gérer la réplication des applications.
    Pour réduire encore plus les coûts de l'hôte, démarrez la VM de secours à la demande pendant le basculement plutôt que de la maintenir en mode "hot standby".

Comparer les coûts, les performances et la résilience

Le tableau suivant présente les compromis en termes de coût, de performances et de résilience pour les différentes architectures de service.

Architecture de service
à haute disponibilité
Instantanés de disques persistants
zonaux
Synchrone au niveau de
l'application
Asynchrone au niveau de
l'application
Solution à haute disponibilité
utilisant un disque persistant
régional
Protège contre les pannes d'application, de VM et de zone1
Minimise la corruption des applications (ex. : intolérance aux plantages d'applications)2
Coût $ €€
Deux instances de la base de données/VM en cours d'exécution + coût de gestion et de configuration de la réplication des applications + mise en réseau interzone
€€
Deux instances de la base de données/VM en cours d'exécution + coût de gestion et de configuration de la réplication des applications + mise en réseau interzone
1,5x $ - $$
Les coûts sont identiques à ceux de la réplication d'applications si vous utilisez un système de secours à chaud (hot standby). Vous pouvez réduire les coûts en faisant tourner une VM de secours à la demande pendant le basculement.
Performances des applications
Aucun impact

Compromis en termes de performances des applications avec la réplication synchrone

Aucun impact

Aucun impact pour la plupart des applications
Adapté aux applications ayant un RPO peu exigeant (aucune tolérance à la perte de données)
Perte de données selon le moment où l'instantané a été pris

Aucune perte de données3

Perte de données, car la réplication est asynchrone

Aucune perte de données
Délai de récupération du stockage après un sinistre4 0 (minutes) 0 (secondes) 0 (secondes) 0 (secondes) – pour forcer l'association du disque à une instance de VM de secours

1 L'utilisation de disques persistants régionaux ou d'instantanés ne suffit pas à empêcher les échecs et les corruptions, ni à les minimiser. Votre application, votre système de fichiers et éventuellement d'autres composants logiciels doivent tolérer les plantages ou utiliser un processus de suspension.

2 La réplication de certaines applications permet de limiter dans une certaine mesure la corruption d'applications. Par exemple, la corruption de l'application maîtresse MySQL n'entraîne pas la corruption de ses instances dupliquées. Pour en savoir plus, consultez la documentation de l'application concernée.

3 La perte de données est la perte irréversible de données validées sur une option de stockage persistante. Les données non validées sont elles aussi perdues.

4 Les performances de basculement n'incluent pas la vérification du système de fichiers ni la récupération et le chargement de l'application après le basculement.

Créer des services de base de données à haute disponibilité à l'aide de disques persistants régionaux

Cette section présente les concepts de base qui vous aideront à créer des solutions à haute disponibilité pour les services de bases de données avec état (MySQL, Postgres, etc.) en utilisant des disques persistants régionaux et Compute Engine.

Les éléments évoqués portent sur la minimisation des pannes dans des zones uniques. Il est toujours possible qu'une application devienne indisponible en cas de panne plus importante, par exemple, si une région entière devient indisponible. En fonction de vos besoins, vous pouvez envisager de recourir à des techniques de réplication interrégionales pour une disponibilité encore plus élevée.

Les configurations de base de données à haute disponibilité comportent généralement au moins deux instances de VM. De préférence, ces instances font partie d'un ou de plusieurs groupes d'instances gérés :

  • Une instance de VM principale dans la zone principale
  • Une instance de VM de secours dans une zone secondaire

Une instance de VM principale comporte au moins deux disques persistants : un disque de démarrage et un disque persistant régional. Le disque persistant régional contient des données de base de données et toutes les autres données modifiables devant être conservées dans une autre zone en cas de panne.

Pour pouvoir se remettre d'une panne de configuration potentiellement causée par la mise à jour d'un système d'exploitation, une instance de VM de secours a besoin d'un disque de démarrage distinct. Vous ne pouvez pas forcer l'association d'un disque de démarrage à une autre VM lors d'un basculement.

Les instances de VM principale et de secours sont configurées pour utiliser un équilibreur de charge. Le trafic est alors dirigé vers la VM principale en suivant les signaux émis par la vérification de l'état. Cette configuration est également appelée "hot standby" (configuration de secours à chaud). Le scénario de reprise après sinistre pour les données décrit d'autres configurations de basculement qui pourraient être mieux adaptées à votre propre scénario.

Vérifications d'état

Les vérifications de l'état sont mises en œuvre par l'agent de vérification de l'état et remplissent deux objectifs :

  1. L'agent de vérification de l'état réside dans les VM principale et secondaire. Il surveille les instances et communique avec l'équilibreur de charge afin de diriger le trafic. Cela est particulièrement utile pour les groupes d'instances.
  2. L'agent de vérification de l'état est synchronisé avec le plan de contrôle régional propre à l'application, et se base sur le comportement de ce dernier pour prendre des décisions liées au basculement. Le plan de contrôle doit se trouver dans une zone différente de l'instance dont il surveille l'état.

    L'agent de vérification de l'état doit être tolérant aux pannes. Dans l'image qui suit, notez par exemple que le plan de contrôle est distinct de l'instance principale qui réside dans la zone us-central1-a, et de la VM de secours qui réside dans la zone us-central1-f.

Rôle de l'agent de vérification de l'état dans la VM

Rôle de l'agent de vérification de l'état dans les instances de VM principale et de secours

Basculement

Lorsqu'une panne est détectée dans une VM ou une base de données principale, le plan de contrôle de l'application peut initier le basculement vers la VM de secours dans la zone secondaire. Pendant le basculement, le disque persistant régional qui est répliqué de manière synchrone sur la zone secondaire est associé de force à la VM de secours par le plan de contrôle de l'application, et tout le trafic est redirigé vers cette VM en suivant les signaux de vérification de l'état.

La latence de basculement globale, temps de détection des pannes exclu, est égale à la somme des latences suivantes :

  • Zéro seconde pour l'association forcée d'un disque persistant régional à une VM de secours
  • Temps nécessaire à l'initialisation de l'application et à la reprise après un plantage

La page Structure de la reprise après sinistre présente les composants actuellement disponibles dans Compute Engine. Grâce à une réplication au niveau du disque, le disque persistant régional constitue un autre composant clé pour la conception de solutions à haute disponibilité.

Modes de défaillance

Le tableau suivant répertorie les différents modes de défaillance et les actions recommandées pour les services utilisant des disques persistants régionaux.

Catégorie de défaillance et (probabilité) Types de défaillances Action
Défaillance de zone (moyenne) Défaillance de disque uniquement, dans la zone locale. Les défaillances peuvent être temporaires ou de longue durée.



Plan de contrôle Compute Engine
Panne de courant
Panne de réseau

Les incidents temporaires liés aux opérations des disques régionaux seront traités de manière transparente par un disque persistant régional sans nécessiter de basculement. Un disque persistant régional détecte automatiquement les erreurs et les lenteurs, change de mode de réplication et rattrape les données répliquées sur une seule zone.

En cas de problèmes de stockage dans une zone principale, un disque persistant régional effectue automatiquement des opérations de lecture à partir d'une zone secondaire. Cela peut entraîner une latence accrue des opérations de lecture. Dans ces circonstances, l'application peut choisir de déclencher un basculement en fonction de l'impact que cela aura sur les performances.



Le plan de contrôle des applications peut déclencher le basculement en fonction des seuils de vérification de l'état.
Défaillance de l'application (élevée) Application qui ne répond pas
Actions de l'administrateur de l'application (par exemple, une mise à jour)
Erreur humaine
(par exemple, mauvaise configuration de paramètres tels que le certificat SSL, les LCA, etc.)
Le plan de contrôle des applications peut déclencher le basculement en fonction des seuils de vérification de l'état.
Défaillance de la VM (moyenne) Défaillance matérielle / d'infrastructure
VM qui ne répond pas en raison de conflits dans le processeur ou d'une interruption du réseau intermédiaire
Les VM sont généralement autoréparatrices. Le plan de contrôle des applications peut déclencher le basculement en fonction des seuils de vérification de l'état.
Corruption de l'application (faible à moyenne) Corruption des données d'application
(par exemple, en raison de bugs au niveau de l'application ou d'une mauvaise mise à jour du système d'exploitation)
Reprise de l'application :
  • Essayez les outils de récupération spécifiques à une application donnée, le cas échéant. L'article sur la corruption d'une page de base de données MySQL vous en propose un exemple.
  • Effectuez une restauration à partir d'une archive de réplication logique. Par exemple, une instance dupliquée avec accès en lecture ou une archive de journaux logiques telle que l'archivage continu PostgresSQL.

Difficultés liées à la réplication des base de données

Le tableau suivant répertorie les problèmes courants liés à la configuration et à la gestion de la réplication synchrone ou semi-synchrone des applications (comme MySQL), et les compare à la réplication par blocs avec des disques persistants régionaux.

Difficultés Réplication synchrone
ou semi-synchrone des applications
Réplication par blocs avec
des disques persistants régionaux
Maintenir une réplication stable entre l'instance dupliquée maîtresse et l'instance dupliquée de basculement Plusieurs problèmes peuvent survenir et empêcher l'instance de rester en mode haute disponibilité :
  1. Mauvaise configuration des paramètres de réplication (non-concordance des certificats SSL ou LCA manquant côté maître, par exemple)
  2. Charge élevée sur l'instance maîtresse, ce qui empêche l'instance dupliquée de basculement de suivre
  3. Bugs entraînant des problèmes de réplication (problèmes d'application, mauvaise configuration du système d'exploitation ou défaillance de Docker, par exemple)
  4. Défaillances d'infrastructure (conflits dans le processeur, VM figée ou interruption du réseau intermédiaire, par exemple)
Les échecs de stockage sont gérés par des disques persistants régionaux. Cela se produit de manière transparente pour l'application, à l'exception d'une éventuelle fluctuation des performances du disque.
Des vérifications de l'état paramétrées par l'utilisateur doivent permettre de révéler tout problème au niveau des applications ou des VM, et de déclencher un basculement.
Le délai total de basculement est plus long que souhaité. Le temps nécessaire à l'opération de basculement n'a pas de limite supérieure définie. Le temps nécessaire à la répétition des transactions (étape 2 ci-dessus) peut être arbitraire selon le schéma et la charge de la base de données. Les disques persistants régionaux fournissent une réplication synchrone. Le temps de basculement est donc limité par la somme des latences suivantes :
  1. Création d'une VM secondaire, sauf si une instance de VM de secours à chaud est déjà disponible
  2. Association forcée d'un disque persistant régional
  3. Initialisation de l'application
Split-brain Les deux approches nécessitent que des dispositions soient prises pour veiller à ce qu'il n'y ait qu'un seul maître à la fois, cela afin d'éviter tout problème de split-brain.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine