Créer des services à haute disponibilité à l'aide d'un disque persistant régional


Le disque persistant régional est une option de stockage qui vous permet de mettre en œuvre des services à haute disponibilité dans Compute Engine. Un disque persistant régional réplique de manière synchrone les données entre deux zones de la même région et garantit la haute disponibilité pour les données du disque jusqu'à une défaillance zonale.

Ce document explique comment créer des services à haute disponibilité à l'aide d'un disque persistant régional.

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

Cette section explique comment créer des services à haute disponibilité avec un disque persistant régional.

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.

Tenez compte des points suivants lorsque vous concevez pour la haute disponibilité :

  • L'effet de l'utilisation de disques persistants régionaux ou d'autres solutions sur les performances des applications et des écritures sur disque.
  • L'objectif de temps de récupération du service. Prenez connaissance de la vitesse à laquelle votre service doit se remettre d'une panne de zone, ainsi que des exigences du contrat de niveau de service.
  • Le coût de 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 d'applications synchrone et asynchrone sont les suivantes :

  • Utilisez 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
  • Utilisez une VM unique avec des disques persistants régionaux. 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.

  • Ne démarrez pas la deuxième VM avant que le basculement ne soit nécessaire. 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
Réplication synchrone
au niveau de l'application
Réplication 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
Atténue la corruption des applications (ex. : intolérance aux plantages d'applications) 2 2
Coût $ $$

  • Deux instances de la base de données ou de la VM en cours d'exécution, configuration et gestion de la réplication des applications, mise en réseau interzone
$$

  • Deux instances de la base de données ou de la VM en cours d'exécution, configuration et gestion 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. Aucuns frais ne s'appliquent lors de la mise en réseau interzone entre les instances dupliquées des disques persistants régionaux.
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 (tolérance très faible à 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 atténuer. 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 principale MySQL n'entraîne pas la corruption de ses instances de VM 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.

En cas de pannes importantes dans Google Cloud, par exemple si une région entière devient indisponible, votre application peut devenir indisponible. En fonction de vos besoins, envisagez 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 de VM 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.

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 principale et l'instance dupliquée de basculement Plusieurs problèmes peuvent survenir et empêcher l'instance de VM 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é de l'instance principale, par exemple)
  2. Charge élevée sur l'instance principale, ce qui empêche l'instance de VM 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 définies 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. Le temps nécessaire à la répétition des transactions (étape 2 ci-dessus) peut être extrêmement long 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 Pour les deux approches, il est nécessaire de prendre des dispositions pour garantir la présence d'une seule instance principale à la fois afin d'éviter tout problème de split-brain.

Vérifications d'état

Les vérifications de l'état utilisées par l'équilibreur de charge sont mises en œuvre par l'agent de vérification de l'état. L'agent de vérification de l'état remplit deux fonctions :

  1. L'agent de vérification de l'état réside dans les VM principale et secondaire. Il surveille les instances de VM et communique avec l'équilibreur de charge afin de diriger le trafic. Cela fonctionne mieux lorsqu'il est configuré avec des 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 de VM 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 de VM 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

Étapes suivantes