Ce document explique les comportements et les interactions entre une application avec état, un agent de vérification de l'état et un plan de contrôle régional propre à l'application utilisé pour surveiller et orchestrer un basculement zonal en déployant des disques persistants régionaux.
Ce document est destiné aux développeurs d'applications et fait suite à la page Options de haute disponibilité avec des disques persistants régionaux. Il détaille la conception et l'architecture décrites dans la section Créer des services de base de données à haute disponibilité à l'aide de disques persistants régionaux. Nous vous recommandons de commencer par lire cet autre document, en particulier les sections Considérations de conception et Comparer les coûts, les performances et la résilience.
Une application sans état augmente la résilience, car elle dispose d'au moins une instance de machine virtuelle (VM) secondaire s'exécutant dans une autre zone Compute Engine. Lorsque l'instance de VM principale échoue, l'application continue de s'exécuter sur l'instance de VM secondaire. Une application avec état peut conserver son état d'application sur un disque persistant zonal afin de récupérer cet état lors du redémarrage d'une instance de VM. Pour plus de résilience, une application avec état doit également conserver son état d'application sur une instance de VM secondaire.
Le schéma suivant illustre une application avec état à deux nœuds classique, dupliquée sur deux zones. Dans chaque zone, l'application dispose d'un disque persistant zonal pour capturer l'état de l'application, et d'une connexion réseau entre les instances de VM pour synchroniser les modifications de l'état de l'application entre les nœuds.
Ajouter un disque persistant régional
Une autre façon de synchroniser l'état d'une application avec état consiste à ajouter un disque persistant régional. Lorsqu'une application écrit son état sur un disque persistant régional, Google Cloud synchronise automatiquement le stockage de blocs avec une autre zone. Le stockage sur disque persistant régional permet également de garantir qu'une seule instance de VM à la fois entre les deux zones est associée au disque persistant régional.
Le schéma suivant illustre l'architecture d'une application de base de données avec état.
Comme le montre le schéma précédent, il existe toujours deux instances de VM d'application (une instance de VM principale et une instance de VM secondaire) déployées dans deux zones. En plus d'utiliser un disque persistant régional pour le stockage de l'état de l'application, vous disposez désormais d'une entité supplémentaire : le plan de contrôle régional propre à l'application. Le plan de contrôle régional propre à l'application décide quelle instance de VM est associée au disque persistant régional et quelle instance de VM constitue l'instance de VM principale actuelle. Cette architecture est une configuration active/passive, car seule l'instance de VM principale peut commit un état d'application sur le disque persistant régional.
Instances de VM et application avec état
Le schéma d'architecture précédent illustre une application de base de données active/passive. Les configurations suivantes sont également possibles :
- Si votre objectif de temps de récupération (RTO, Recovery Time Objective) peut admettre la latence supplémentaire du démarrage d'une instance de VM secondaire, vous pouvez réaliser des économies sur les coûts liés à Compute Engine en n'exécutant que l'instance de VM active. Lors d'un basculement, le plan de contrôle régional propre à l'application démarre l'instance de VM secondaire et associe le disque persistant régional.
- Vous pouvez utiliser des charges de travail de traitement par lot ou par flux qui établissent un point de contrôle de leur progression sur le disque persistant régional. Lors d'un basculement, l'application reprend le traitement à partir de ce dernier point de contrôle.
Gérer les démarrages d'instances de VM
Étant donné qu'une seule instance de VM peut être associée à un disque persistant régional à la fois, vous devez démarrer les instances de VM et associer le disque persistant régional de manière systématique. Une bonne pratique consiste à séparer le démarrage de l'application et de l'instance de VM de l'association du disque persistant régional. Les scripts de démarrage de l'instance de VM ne doivent pas lancer l'association du disque persistant régional. Ils doivent plutôt démarrer l'agent de vérification de l'état et attendre que le disque persistant régional soit associé.
Au démarrage, l'instance de VM doit effectuer les étapes séquentielles suivantes :
- Démarrer l'agent de vérification de l'état
- Attendre que le disque persistant régional soit associé
- Une fois le disque persistant régional associé, installer le système de fichiers
- Une fois le système de fichiers installé, démarrer l'application
Ces étapes couvrent le démarrage du système, mais il existe également le cas du basculement. Lors d'un basculement, le disque persistant régional est associé de force à l'instance de VM secondaire. Il est également supprimé de force de l'instance de VM principale, et les opérations d'E/S du système de fichiers échouent. À ce stade, vous devez arrêter ou redémarrer l'instance de VM.
Exécuter l'agent de vérification de l'état et les vérifications de l'état
Comme décrit dans la section précédente, l'instance de VM attend que le disque persistant régional soit associé avant de démarrer l'application. Le plan de contrôle régional propre à l'application associe le disque persistant régional, mais seulement à une instance de VM qui attend que ce disque soit associé. Lorsqu'un disque est associé, le plan de contrôle propre à l'application surveille l'état de l'application et lance un basculement si elle devient non opérationnelle.
Chaque instance de VM présente l'un des états suivants :
- Inactif
- En cours de démarrage
- En attente d'un disque
- Application en cours d'exécution
L'agent de vérification de l'état indique l'état actuel de l'instance de VM. Plutôt que de signaler ces deux états à l'aide d'une seule vérification de l'état, vous pouvez exécuter deux vérifications de l'état binaires. Si l'instance de VM est prête à être associée au disque persistant régional, ou si le disque persistant régional est associé et accessible en écriture, la vérification de l'état de l'instance de VM indique un état opérationnel. Si l'application est en cours d'exécution et capable d'écrire son état sur le disque persistant régional, la vérification indique un état opérationnel.
L'utilisation de deux vérifications de l'état binaires présente plusieurs avantages :
- Vous pouvez utiliser le service géré de vérification de l'état de Compute Engine, qui interroge l'agent de vérification de l'état et résout également les erreurs temporaires via le nombre de seuils.
- Un groupe d'instances géré (MIG, Managed Instance Group) peut surveiller la vérification de l'état de l'instance et autoréparer une instance de VM non opérationnelle.
- L'équilibreur de charge peut surveiller la vérification de l'état de l'application et acheminer le trafic vers l'instance d'application active.
Vous pouvez empêcher le système de réagir à une défaillance temporaire en diminuant la fréquence de signalement des vérifications de l'état, ou en augmentant le seuil des signaux répétés requis pour passer d'un niveau à un autre. Ces deux approches retardent la réaction du système face à une interruption et augmentent le temps de récupération. En testant et en mesurant ces paramètres, vous pouvez ajuster les paramètres de vérification de l'état pour équilibrer le temps de récupération du système.
Comprendre le plan de contrôle régional propre à l'application
La dernière partie de l'architecture est le plan de contrôle régional propre à l'application, qui est responsable des deux fonctions suivantes :
- Gérer le cycle de vie des instances de VM principale et secondaire
- Déterminer si un basculement est requis en surveillant l'état de la vérification de l'état de l'application
Si un basculement est nécessaire, le plan de contrôle régional propre à l'application l'orchestre en procédant comme suit :
- Il vérifie qu'une instance de VM secondaire est en cours d'exécution et attend que le disque persistant régional soit associé.
- Il force l'association du disque persistant régional à l'instance de VM secondaire.
- Il surveille et redémarre l'instance de VM principale ayant échoué. Lorsque l'instance de VM est redémarrée, le plan de contrôle lance une restauration le cas échéant.
Le plan de contrôle régional propre à l'application lui-même doit avoir une disponibilité élevée dans les deux zones où l'application s'exécute. Dans les centres de données sur site, la haute disponibilité est souvent obtenue en déployant des serveurs supplémentaires pour créer un quorum, décider quelle instance de VM est la principale et orchestrer le basculement. Cette approche utilise souvent des outils de surveillance haute disponibilité tels que Heartbeat, Pacemaker ou Keepalived.
Bien que vous puissiez utiliser le plan de contrôle régional propre à l'application n'importe où dans le cloud, Google Cloud propose les services gérés et régionaux suivants, qui simplifient la mise en œuvre de cette approche :
- Produits Google Cloud sans serveur tels que App Engine, Cloud Run et Cloud Functions, qui sont faciles à gérer et à déployer
- Vérifications de l'état gérées qui déchargent la surveillance des instances de l'application
- Groupes d'instances gérés qui gèrent le cycle de vie des instances de serveur
Le schéma suivant illustre l'utilisation de Cloud Functions pour le plan de contrôle régional propre à l'application, ainsi qu'un groupe d'instances géré avec état et des vérifications de l'état gérées.
Le schéma précédent montre deux instances de VM de l'application : la principale et la secondaire. Chaque instance de VM s'exécute dans une zone distincte et est gérée par un MIG régional avec état. Un disque persistant régional est disponible dans les deux mêmes zones. Deux services de vérification de l'état gérés sont en cours d'exécution. L'un des services de vérification de l'état géré surveille l'état de fonctionnement de l'instance de VM, et il est utilisé par le MIG avec état. L'autre service de vérification de l'état surveille l'état de fonctionnement de l'application, et il est utilisé par le pool cible de l'équilibreur de charge.
Un plan de contrôle régional propre à l'application interagit avec l'état de fonctionnement de l'application du pool cible et avec le MIG régional avec état afin de surveiller l'état de l'application et d'initier l'association du disque persistant régional à l'instance de VM opérationnelle actuelle.
Étapes suivantes
- Consultez la page Provisionner des disques persistants régionaux dans Google Kubernetes Engine.
- Pour savoir comment adapter les outils haute disponibilité sur site pour les utiliser dans Google Cloud, consultez la page Modèles d'utilisation d'adresses IP flottantes.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.