Considérations de conception pour les charges de travail résilientes avec des disques régionaux

Last reviewed 2020-09-23 UTC

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 régionaux répliqués de manière synchrone.

Ce document est destiné aux développeurs d'applications et fait suite à la page Créer des services à haute disponibilité à l'aide de disques 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 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 Compute Engine secondaire s'exécutant dans une autre zone. Lorsque l'instance principale échoue, l'application continue de s'exécuter sur l'instance secondaire. Une application avec état peut conserver son état d'application sur un disque zonal, ou un disque disponible dans une seule zone, pour récupérer son état lors du redémarrage d'une instance. Pour plus de résilience, une application avec état doit également conserver son état d'application sur une instance secondaire.

La figure 1 illustre une application avec état à deux nœuds classique, dupliquée sur deux zones. Dans chaque zone, l'application dispose d'un disque zonal pour capturer l'état de l'application, et d'une connexion réseau entre les instances pour synchroniser les modifications de l'état de l'application entre les nœuds.

Un équilibreur de charge est utilisé afin de dupliquer l'état d'une application sur une instance principale et une instance secondaire, qui se trouvent dans différentes zones.

Figure 1 : Application avec état à deux nœuds sans disques régionaux

Ajouter un disque régional

Une autre façon de synchroniser l'état d'une application avec état consiste à ajouter un disque régional. Lorsqu'une application écrit son état sur un disque régional, Google Cloud synchronise automatiquement le stockage de blocs avec une autre zone.

La figure 2 illustre l'architecture d'une application de base de données avec état.

Un disque régional est associé à deux instances de VM sur deux zones.

Figure 2. Application de base de données avec état

Comme le montre la figure 2, il existe toujours deux instances de calcul d'application (une instance principale et une instance secondaire) déployées dans deux zones. En plus d'utiliser un disque 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 est associée au disque régional et quelle instance constitue l'instance principale actuelle. Cette architecture est une configuration active/passive, car seule l'instance principale peut commit un état d'application sur le disque régional.

Instances Compute et application avec état

La figure 2 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 secondaire, vous pouvez réaliser des économies sur les coûts liés à Compute Engine en n'exécutant que l'instance active. Lors d'un basculement, le plan de contrôle régional propre à l'application démarre l'instance secondaire et associe le disque régional à cette instance.
  • 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 régional. Lors d'un basculement, l'application reprend le traitement à partir de ce dernier point de contrôle.

Gérer les démarrages des instances Compute Engine

Étant donné qu'une seule instance de calcul peut être associée à un disque régional à la fois, vous devez démarrer les instances et associer le disque régional de manière systématique. Une bonne pratique consiste à séparer le démarrage de l'application et de l'instance de calcul de l'association du disque régional. Les scripts de démarrage de l'instance ne doivent pas lancer l'association du disque régional. Ils doivent plutôt démarrer l'agent de vérification de l'état;état et attendre que le disque régional soit associé.

Au démarrage, l'instance de calcul doit effectuer les étapes séquentielles suivantes:

  1. Démarrer l'agent de vérification de l'état
  2. Attendez que le disque régional soit associé.
  3. Une fois le disque régional associé, installez le système de fichiers.
  4. 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 régional est associé de force à l'instance secondaire. Le disque régional est également supprimé de force de l'instance 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 calcul.

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 calcul attend que le disque régional soit associé avant de démarrer l'application. Le plan de contrôle régional propre à l'application associe le disque régional, mais seulement à une instance de calcul 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 calcul 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'état indique l'état actuel de l'instance. 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 calcul est prête à être associée au disque régional, ou si le disque régional est associé et accessible en écriture, la vérification de l'état'instance indique un état opérationnel. Si l'application est en cours d'exécution et capable d'écrire son état sur le disque 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'état de l'instance et autoréparer une instance de calcul 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 calcul 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 :

  1. Vérifie qu'une instance secondaire est en cours d'exécution et attend que le disque régional soit associé.
  2. Il force l'association du disque régional à l'instance secondaire.
  3. Il surveille et redémarre l'instance principale ayant échoué. Lorsque l'instance principale 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 calcul 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 :

La figure 3 illustre l'utilisation des fonctions Cloud Run 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.

Un plan de contrôle régional propre à l'application gère les VM principale et secondaire.

Figure 3. Plan de contrôle régional propre à l'application

La figure 3 montre deux instances de calcul de l'application : la principale et la secondaire. Chaque instance s'exécute dans une zone distincte et est gérée par un MIG régional avec état. Un disque 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'état géré surveille l'état de fonctionnement de l'instance, 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 régional à l'instance de calcul opérationnelle actuelle.

Étape suivante