Groupes d'instances gérés avec état

Vous pouvez créer des déploiements à haute disponibilité de charges de travail avec état sur des instances de VM à l'aide de groupes d'instances gérés avec état. Les charges de travail avec état incluent des applications avec des données ou des configurations avec état, telles que des bases de données, des applications monolithiques anciennes et des opérations de calcul par lot de longue durée avec des points de contrôle.

Avec les groupes d'instances gérés avec état, vous pouvez améliorer la disponibilité et la résilience de ces applications avec état grâce à l'autoréparation (récupération automatique des charges de travail en échec) et les déploiements multizones. Vous pouvez également simplifier les mises à jour des instances avec état en ⁠contrôlant les déploiements de mises à jour.

Un groupe d'instances géré avec état conserve l'état unique de chaque instance (y compris le nom de l'instance, les disques persistants associés et les métadonnées) lors du redémarrage, de la recréation, de l'autoréparation ou de la mise à jour de la VM.

Cette page explique quand utiliser les groupes d'instances gérés avec état et présente leur fonctionnement général. Pour des informations plus détaillées, consultez la page Fonctionnement des groupes d'instances gérés (MIG) avec état.

Pour savoir comment configurer un groupe d'instances géré avec état, consultez la page Configurer des groupes d'instances gérés (MIG) avec état.

En quoi les charges de travail avec état sont-elles différentes des charges de travail sans état ?

Vous pouvez utiliser des groupes d'instances gérés avec les charges de travail avec état et sans état. La principale différence est que les charges de travail avec état conservent l'état de chaque VM (par exemple, un segment de base de données ou une configuration d'application) sur les disques, tandis que les charges de travail sans état, comme une interface Web, ne conservent aucun état de VM.

Vous traitez les VM avec des charges de travail avec état comme des machines personnalisées : vous vous souciez de l'identité (nom), des métadonnées et des données de chaque machine individuelle. Vous ne pouvez pas facilement faire évoluer les charges de travail avec état horizontalement, car le scaling peut nécessiter la réplication, la création ou la suppression de segments de données, ou la modification de la configuration globale de l'application. Lorsque vous recréez ou mettez à jour une machine avec une charge de travail avec état, vous devez conserver l'état unique de la VM. Des exemples d'applications avec état incluent Cassandra, ElasticSearch, mongoDB, MySQL, PostgreSQL et Kafka.

Vous traitez les VM avec des charges de travail sans état comme étant interchangeables et vous ne vous souciez que du nombre de VM de diffusion dont vous disposez. Aucune VM n'est traitée différemment. Vous pouvez facilement faire évoluer les charges de travail sans état horizontalement en ajoutant ou en supprimant des VM. Lors de la mise à jour de votre application, vous pouvez supprimer les machines et les remplacer par de nouvelles machines avec des noms, des métadonnées et des disques différents. Lorsqu'une VM sans état est supprimée ou recréée, toutes les données de la machine sont perdues : les disques sont supprimés ou entièrement recréés. Une interface Web est un exemple d'application sans état.

Groupes d'instances gérés avec étatGroupes d'instances gérés sans état
Charge de travail Charges de travail avec état où les disques et/ou les métadonnées sont conservés pendant les opérations de recréation de VM. Charges de travail sans état hautement disponibles et évolutives, où les disques sont entièrement recréés lors du scaling horizontal, de l'autoréparation, de la mise à jour automatique et de la recréation de la VM.
Fonctionnalités des groupes d'instances gérés
  • Autoréparation
  • Mises à jour contrôlées d'instances spécifiques
  • Déploiements multizones
  • Autoréparation
  • Mises à jour progressives automatisées
  • Déploiements multizones
  • Autoscaling
Éléments pouvant être conservés
  • Noms des instances
  • Disques persistants, y compris les disques non définis dans le modèle d'instance
  • Métadonnées spécifiques aux instances
Noms des instances

Tous les groupes d'instances gérés acceptent les noms d'instances personnalisés et pouvant être conservés.

Quand utiliser des groupes d'instances gérés avec état

Envisagez d'utiliser des groupes d'instances gérés avec état (MIG avec état) lorsque vous déployez une application ou un cluster avec état sur Compute Engine. Vous pouvez ainsi améliorer sa disponibilité avec la fonction autoréparation. Ces MIG avec état autorisent en outre des déploiements multizones et vous permettent de simplifier les mises à jour des instances avec état en orchestrant des déploiements de mises à jour et en contrôlant le niveau autorisé d'interruption des instances.

Les groupes d'instances gérés avec état sont destinés aux applications avec des données ou une configuration avec état. Par exemple :

  • Bases de données (Cassandra, ElasticSearch, mongoDB et ZooKeeper, par exemple) : avant de choisir d'utiliser des groupes d'instances gérés avec état, envisagez d'utiliser des services entièrement gérés, tels que MySQL et PostgreSQL, disponibles dans Cloud SQL, pour vous concentrer sur vos applications et ne pas avoir à gérer les VM.
  • Applications de traitement des données (Kafka et Flink, par exemple) : avant de choisir d'utiliser des groupes d'instances gérés avec état, envisagez d'utiliser des services entièrement gérés, tels que Dataflow ou Dataproc, pour vous concentrer sur vos tâches de traitement des données et ne pas avoir à gérer les VM.
  • Autres applications avec état (TeamCity, Jenkins, Bamboo et les charges de travail avec état personnalisées, par exemple).
  • Applications monolithiques anciennes : ces applications stockent l'état de l'application sur un disque de démarrage ou sur des disques persistants supplémentaires, ou reposent sur une configuration avec état, comme des noms d'instances de VM ou des paires clé/valeur de métadonnées spécifiques.
  • Charges de travail par lot avec des points de contrôle : avec cette configuration, vous pouvez conserver les résultats des points de contrôle des opérations de calcul de longue durée en prévision de l'échec de la charge de travail ou de la VM, ou en vue de la préemption d'instance. Les groupes d'instances gérés avec état peuvent recréer une machine en échec, tout en préservant son disque de données, afin que vos opérations de calcul puissent reprendre à partir du dernier point de contrôle.

Pour assurer la résilience en cas de défaillance d'une zone, votre application doit répliquer les données sur plusieurs instances au niveau de l'application. Par exemple, ElasticSearch et Cassandra prennent en charge cette fonctionnalité. Vous pouvez utiliser un MIG régional pour rendre une telle application résiliente aux défaillances de zone en déployant des instances dupliquées redondantes dans plusieurs zones et en vous appuyant sur la fonctionnalité de réplication de données de votre application. En cas de défaillance d'une zone, vos données sont diffusées à partir des instances dupliquées disponibles dans les zones restantes.

Passez en revue les limites pour déterminer si un MIG avec état répond entièrement à vos besoins.

Qu'est-ce qui rend un groupe d'instances géré avec état

Un groupe d'instances géré est considéré comme étant avec état si vous avez créé une configuration avec état.

Vous pouvez créer une configuration avec état lorsque vous créez votre MIG ou convertir un groupe sans état existant en un groupe avec état à l'aide d'une configuration avec état.

Vous créez une configuration avec état en définissant une règle avec état non vide et/ou une ou plusieurs configurations par instance non vides :

  • Une règle avec état définit les éléments que vous souhaitez conserver pour toutes les instances de votre groupes d'instances géré.
  • Une configuration par instance définit les éléments à conserver pour une instance de VM spécifique.

La configuration devient effective après que vous ou le groupe d'instances géré l'avez appliquée :

  • Un groupe d'instances géré applique automatiquement votre configuration de règle avec état aux instances nouvelles et existantes.
  • Lorsque vous créez ou mettez à jour des configurations par instance, vous pouvez choisir d'appliquer la nouvelle configuration manuellement ou automatiquement.

Une fois la configuration avec état (règle avec état et/ou configurations par instance) appliquée, vous pouvez la vérifier en inspectant l'état conservé de chaque instance gérée.

Les modifications apportées ultérieurement à la configuration avec état ou à la taille de votre groupe d'instances géré (par exemple, la diminution de sa taille, ou la suppression ou l'abandon d'instances) peuvent affecter les états conservés des instances.

Configuration avec état

Un groupe d'instances géré avec état récupère sa configuration d'instance à partir de la combinaison du modèle d'instance, de la règle avec état et des configurations par instance que vous définissez. Après avoir appliqué le modèle d'instance, la règle avec état et/ou les configurations par instance à votre groupe, le groupe d'instances géré utilise cette configuration lors de la création, de la recréation, de l'autoréparation ou de la mise à jour automatique de ses instances de VM.

Règle avec état

Une règle avec état définit des éléments avec état courants pour toutes les instances d'un groupe d'instances géré. Chaque élément que vous incluez dans la règle avec état doit être défini dans le modèle d'instance du groupe d'instances géré.

Vous pouvez apporter les modifications suivantes à une règle avec état :

  • Configurez les disques pour qu'ils deviennent avec état en les ajoutant à la règle avec état.
  • Configurez les disques pour qu'ils deviennent sans état en les supprimant de la règle avec état.

Configurations par instance

Une configuration par instance définit des éléments avec état qui sont uniques pour une instance gérée spécifique (par exemple, des paires clé/valeur de métadonnées spécifiques à une instance). Ces éléments n'ont pas besoin d'être définis dans le modèle d'instance du groupe d'instances géré.

Vous pouvez apporter les modifications suivantes à une configuration par instance pour une instance spécifique d'un groupe d'instances géré :

  • Configurez les disques qui sont définis dans le modèle d'instance pour qu'ils deviennent avec état pour l'instance (en les ajoutant à la configuration par instance) ou sans état (en les supprimant de la configuration par instance).
  • Configurez les disques existants, non définis dans le modèle d'instance, de manière à les associer et à les rendre avec état pour l'instance (en les ajoutant à la configuration par instance), ou à les dissocier de l'instance (en les supprimant de la configuration par instance).
  • Ajoutez ou supprimez des paires clé/valeur de métadonnées avec état spécifiques à l'instance.

Exemple de configuration avec état

Voici un exemple de configuration avec état :

Modèle d'instance + règle avec état + configuration par instance = configuration d'instance gérée

Dans ce schéma :

  • Le modèle d'instance définit une configuration courante pour toutes les instances de VM d'un groupe d'instances géré.
  • La règle avec état définit une configuration avec état courante pour les disques avec le nom d'appareil data-disk, qui sont définis par le modèle d'instance, et qui sont créés et associés individuellement à chaque instance de VM dans le groupe d'instances géré.
  • La configuration par instance définit une configuration avec état pour une instance de VM spécifique nommée node-1. Elle indique qu'un disque existant, my-legacy-1, doit être associé à l'instance node-1 et traité comme étant avec état. Elle spécifie également une paire clé/valeur de métadonnées à conserver individuellement pour l'instance node-1 : node-id:xyz273.

Lors de la création de la VM node-1, le groupe d'instances géré effectue les opérations suivantes :

  1. Il utilise le type de machine n2-standard-2, en fonction du modèle d'instance.
  2. Il crée et associe un disque de démarrage avec un nom de disque généré automatiquement (boot-node-1) et un nom d'appareil (boot-disk) à l'aide d'une image Debian GNU/Linux, en fonction du modèle d'instance. Il traite le disque de démarrage boot-node-1 comme étant sans état, car il n'est pas configuré dans la règle avec état ni dans la configuration par instance.
  3. Il crée et associe un disque supplémentaire avec un nom de disque généré automatiquement (data-disk-1) et un nom d'appareil (data-disk) à l'aide d'une image personnalisée, en fonction du modèle d'instance. Il traite le disque supplémentaire data-disk-1 comme étant avec état, car son nom d'appareil est spécifié dans la règle avec état.
  4. Il associe un disque existant avec le nom de disque my-legacy-1, et utilise le nom d'appareil legacy-disk, en fonction de la configuration par instance. Il traite le disque supplémentaire my-legacy-1 comme étant avec état, car son nom d'appareil est spécifié dans la configuration par instance.
  5. Définit trois paires clé/valeur de métadonnées : deux provenant du modèle d'instance (app:example-stateful-app, version:1.0) et une de la configuration par instance (node-id:xyz273). Le groupe d'instances géré traite la paire clé/valeur node-id:xyz273 comme étant avec état, car elle est spécifiée dans la configuration par instance.

Lors de la recréation de la VM node-1, en supposant que la même configuration est toujours effective, le groupe d'instances géré recrée les éléments sans état et conserve les éléments avec état :

  1. Il recrée le disque de démarrage à partir de l'image d'origine :

    Tout d'abord, il supprime le disque de démarrage boot-node-1, puis le recrée à partir de l'image Debian GNU/Linux, comme spécifié dans le modèle d'instance.

  2. Il conserve des disques supplémentaires, data-disk-1 et my-legacy-1 :

    Il dissocie les disques supplémentaires avant de supprimer la VM, puis les associe à la VM après sa recréation.

  3. Il conserve la paire clé/valeur de métadonnées individuelles, node-id:xyz273 :

    Il définit les métadonnées une fois la VM recréée. Il définit également les paires clé/valeur courantes à partir du modèle d'instance (app:example-stateful-app et version:1.0).

Étape suivante