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), aux déploiements multizones et aux mises à jour progressives automatisées.

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, les adresses IP 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 adresses IP, 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 adresses IP, 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 état	Groupes d'instances gérés sans état
Charge de travail	Charges de travail avec état où les disques, les adresses IP 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 et les adresses IP 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 progressives automatisées 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 Adresses IP	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, serveurs DNS avec adresse IP avec état et charges de travail personnalisées avec état, 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, des adresses IP 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 en ajoutant une configuration.

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é (MIG) avec état récupère sa configuration d'instance à partir de la combinaison du modèle d'instance, de la configuration facultative sur toutes les instances, des règles avec état et des configurations facultatives par instance que vous avez définis. Une fois la configuration de votre groupe effectuée, le groupe d'instances géré utilise cette configuration lors de la création des VM. Pour appliquer une configuration mise à jour aux VM existantes, consultez la page Appliquer de nouvelles configurations de VM dans un MIG.

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.
Spécifiez les adresses IP avec état en ajoutant la configuration de l'interface réseau à la règle avec état.
Indiquez que les adresses IP doivent être traitées comme sans état en supprimant la configuration 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 disques propres à une instance, des paires clé/valeur de métadonnées et des adresses IP). Les métadonnées et les disques spécifiques à l'instance n'ont pas besoin d'être définis dans le modèle d'instance du groupe d'instances géré. Cependant, les interfaces réseau des adresses IP avec état doivent être définies dans le modèle d'instance du MIG.

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.
Configurez des adresses IP individuellement pour les instances d'un MIG pour qu'elles deviennent avec état ou sans état.

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 :

Il utilise le type de machine n2-standard-2, en fonction du modèle d'instance.
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.
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.
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.
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 :

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.
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.
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).

Votre avis

Nous souhaitons en savoir plus sur vos cas d'utilisation, les défis que vous rencontrez ou vos impressions sur les MIG avec état. Nous vous invitons à nous faire part de vos commentaires à l'adresse suivante : mig-discuss@google.com.

Étape suivante

Consultez la page Configurer des groupes d'instances gérés (MIG) avec état pour apprendre à gérer les charges de travail avec état tout en conservant les noms d'instances, les disques persistants et les métadonnées dans les instances gérées.
Apprenez à migrer une charge de travail existante vers un MIG avec état.
Apprenez-en plus sur le fonctionnement des groupes d'instances gérés avec état.
Apprenez-en plus sur les groupes d'instances gérés.
Découvrez comment utiliser des instances gérées.