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 | $ | $$
|
$$
|
$1.5x - $$
|
Performances des applications |
|
|
|
|
Adapté aux applications ayant un RPO peu exigeant (tolérance très faible à la perte de données) |
|
|
|
|
Délai de récupération du stockage après un sinistre4 |
|
|
|
|
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é :
|
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 :
|
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 :
- 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.
- 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
.
Étapes suivantes
- Découvrez comment créer et gérer des volumes de disques persistants régionaux.
- Apprenez à créer des applications Web fiables et évolutives sur Google Cloud.
- Consultez le Guide de planification de reprise après sinistre.