Groupes d'instances

Vous pouvez créer et gérer des groupes d'instances de machines virtuelles (VM) afin de ne pas avoir à contrôler individuellement chaque instance de votre projet. Compute Engine propose deux types de groupes d'instances différents : les groupes d'instances gérés et ceux non gérés.

Groupes d'instances gérés

Les groupes d'instances gérés utilisent un modèle d'instance pour créer un groupe d'instances identiques et ils sont contrôlés comme une entité unique. Si vous souhaitez apporter des modifications aux instances faisant partie d'un groupe d'instances géré, vous apportez la modification à l'ensemble du groupe d'instances. Comme les groupes d'instances gérés contiennent des instances identiques, ils offrent les fonctionnalités suivantes :

  • Lorsque vos applications nécessitent des ressources de calcul supplémentaires, les groupes d'instances gérés peuvent effectuer un scaling automatique du nombre d'instances du groupe.
  • Les groupes d'instances gérés font appel à des services d'équilibrage de charge pour répartir le trafic entre toutes les instances du groupe.
  • Si une instance du groupe s'arrête, plante ou est supprimée par une action différente des commandes des groupes d'instances, le groupe d'instances géré recrée automatiquement l'instance afin qu'elle puisse reprendre ses tâches de traitement. L'instance recréée porte le même nom et a le même modèle d'instance que l'instance précédente, même si le groupe fait référence à un modèle d'instance différent.
  • Les groupes d'instances gérés peuvent automatiquement identifier et recréer des instances non opérationnelles dans un groupe afin de garantir l'exécution optimale de toutes les instances.
  • Le programme de mise à jour de groupes d'instances gérés vous permet de déployer facilement de nouvelles versions de logiciels sur des instances de vos groupes d'instances gérés, tout en contrôlant la vitesse et le champ d'application du déploiement, ainsi que le niveau d'interruption de votre service.

Types de groupes d'instances gérés

Vous pouvez créer deux types de groupes d'instances gérés :

Les groupes d'instances gérés régionaux sont généralement préférables aux groupes d'instances gérés par zone, car ils vous permettent de répartir la charge des applications sur plusieurs zones, plutôt que de confiner votre application dans une seule zone ou de gérer plusieurs groupes d'instances dans différentes zones. Cette réplication constitue une protection contre les défaillances de zones et les scénarios imprévus, comme le dysfonctionnement d'un groupe entier d'instances d'une même zone. Si cela se produit, votre application peut continuer à diffuser le trafic à partir d'instances exécutées dans une autre zone de la même région.

Choisissez des groupes d'instances gérés par zone si vous souhaitez éviter un temps de latence légèrement plus élevé, induit par la communication entre zones, ou si vous avez besoin d'un contrôle plus précis de la taille de vos groupes dans chaque zone.

Groupes d'instances gérés et le réseau

Par défaut, les instances du groupe seront placées sur le réseau default et des adresses IP de la plage régionale leur seront attribuées de manière aléatoire. Vous pouvez également restreindre la plage d'adresses IP du groupe en créant un réseau VPC en mode personnalisé et un sous-réseau qui utilise une plage d'adresses IP plus restreinte, puis en spécifiant ce sous-réseau dans le modèle d'instance. Cela peut simplifier la création de règles de pare-feu.

Une fois que vous avez créé un groupe d'instances géré, les nouvelles instances démarrent dans le groupe dès que le système peut les provisionner. Ce processus peut prendre beaucoup de temps selon le nombre d'instances du groupe. Vérifiez le statut des instances dans votre groupe d'instances géré.

Groupes d'instances gérés et autoscaling

Les groupes d'instances gérés prennent en charge l'autoscaling afin que vous puissiez ajouter ou supprimer de façon dynamique des instances d'un groupe d'instances géré, en réponse à des augmentations ou des diminutions de charge. Vous activez l'autoscaling et choisissez une stratégie d'autoscaling afin de déterminer la manière dont vous souhaitez évoluer. Les règles d'autoscaling applicables incluent le scaling en fonction de l'utilisation du processeur, de la capacité d'équilibrage de charge, des métriques de Stackdriver Monitoring ou d'une charge de travail basée sur une file d'attente comme Google Cloud Pub/Sub.

L'autoscaling nécessite l'ajout et la suppression d'instances d'un groupe, vous ne pouvez donc l'utiliser qu'avec des groupes d'instances gérés, afin que l'autoscaler puisse gérer des instances identiques. L'autoscaling ne fonctionne pas sur les groupes d'instances non gérés, qui peuvent contenir des instances hétérogènes.

Pour plus d'informations, reportez-vous à la section Autoscaling des groupes d'instances.

Groupes d'instances gérés et autoréparation

Les groupes d'instances gérés maintiennent la haute disponibilité de vos applications en s'assurant de manière proactive que vos instances restent disponibles, c'est-à-dire à l'état RUNNING. Un groupe d'instances géré recrée automatiquement une instance qui n'est pas à l'état RUNNING. Cependant, se baser sur l'état de l'instance peut ne pas s'avérer suffisant. Vous pouvez choisir de recréer des instances lorsqu'une application se bloque, plante ou manque de mémoire.

L'autoréparation basée sur les applications améliore la disponibilité de ces dernières grâce à un signal de vérification de l'état qui détecte les problèmes propres aux applications, tels que le blocage, le plantage ou la surcharge. Si une vérification de l'état identifie une application défaillante sur une instance, le groupe recrée automatiquement cette instance.

Vérification de l'état

Les vérifications de l'état permettant de surveiller des groupes d'instances gérés sont semblables à celles utilisées pour l'équilibrage de charge, à quelques différences près au niveau de leur comportement. Les vérifications de l'état pour l'équilibrage de charge aident à détourner le trafic des instances non réactives afin de le diriger vers des instances opérationnelles. Elles n'entraînent aucune recréation d'instances de la part de Compute Engine. Par ailleurs, les vérifications de l'état des groupes d'instances gérés signalent de manière proactive que des instances doivent être supprimées et recréées lorsqu'elles passent à l'état UNHEALTHY.

Dans la plupart des cas, utilisez des vérifications de l'état distinctes pour l'équilibrage de charge et l'autoréparation. Les vérifications de l'état relatives à l'équilibrage de charge peuvent et devraient se révéler plus agressives, car elles déterminent si une instance reçoit du trafic utilisateur ou non. Comme vos clients comptent sur la disponibilité de vos services, vous devez identifier rapidement les instances non réactives afin de pouvoir rediriger le trafic si nécessaire. En revanche, les vérifications de l'état relatives à l'autoréparation entraînent le remplacement proactif des instances défaillantes par Compute Engine. Ces vérifications de l'état devraient donc être plus conservatrices que celles destinées à l'équilibrage de charge.

Comportement de l'autoréparation

L'autoréparation recrée les instances non opérationnelles à l'aide du modèle d'instance utilisé à l'origine pour créer l'instance de VM (il ne s'agit pas nécessairement du modèle d'instance actuel dans le groupe d'instances géré). Par exemple, si une instance de VM a été créée à l'aide du modèle instance-template-a et que vous mettez ensuite à jour le groupe d'instances géré de façon qu'il utilise le modèle instance-template-b en mode OPPORTUNISTIC, l'autoréparation recréera quand même l'instance avec instance-template-a. En effet, comme les recréations liées à l'autoréparation ne sont pas initiées par l'utilisateur, Compute Engine ne veut pas supposer que l'instance de VM devrait utiliser le nouveau modèle. Si vous souhaitez appliquer un nouveau modèle, consultez la section Modifier le modèle d'instance d'un groupe d'instances géré.

Le nombre d'instances faisant simultanément l'objet d'une autoréparation est inférieur à la taille du groupe d'instances géré. Cela garantit que le groupe continue à exécuter un sous-ensemble d'instances lorsque la règle d'autoréparation ne correspond pas à la charge de travail, lorsque les règles de pare-feu sont mal configurées, ou en cas de problèmes de connectivité réseau ou d'infrastructure entraînant une fausse identification de toutes les instances opérationnelles comme étant non opérationnelles. Toutefois, si un groupe d'instances géré zonal ne comporte qu'une instance ou si un groupe d'instances géré régional ne compte qu'une instance par zone, l'autoréparation recréera ces instances si elles ne sont plus opérationnelles.

L'autoréparation ne recréera pas une instance UNHEALTHY au cours de la période d'initialisation de cette dernière, comme spécifié par la propriété autoHealingPolicies[].initialDelaySec. Cela permet de retarder la vérification et l'éventuelle recréation prématurée de l'instance si celle-ci est en cours de démarrage. Le délai initial commence au moment où le champ currentAction de l'instance prend la valeur VERIFYING.

Autoréparation et disques

Lors de la recréation d'une instance à partir de son modèle, le processus d'autoréparation traite les divers types de disques différemment. En cas de tentative de recréation d'une instance gérée, certaines configurations de disque peuvent entraîner l'échec de l'autoréparation.

Type autodelete Comportement lors d'une opération d'autoréparation
Nouveau disque persistant true Le disque est recréé comme spécifié dans le modèle de l'instance. Toutes les données écrites sur ce disque sont perdues lorsque le disque et son instance sont recréés.
Nouveau disque persistant false L'ancien disque est dissocié, mais il reste disponible. Toutefois, la recréation d'instances de VM échoue, car Compute Engine ne peut pas recréer un disque existant.
Disque persistant existant true L'ancien disque est supprimé. La recréation d'instances de VM échoue, car Compute Engine ne peut pas réassocier un disque supprimé à l'instance.
Disque persistant existant false L'ancien disque est réassocié comme spécifié dans le modèle de l'instance. Les données figurant sur le disque sont conservées. Toutefois, pour les disques en lecture-écriture existants, un groupe d'instances géré ne peut contenir qu'une seule VM, car un même disque persistant ne peut pas être associé à plusieurs instances en mode lecture-écriture.
Nouveau disque SSD local N/A Le disque est recréé comme spécifié dans le modèle de l'instance. Les données figurant sur un disque SSD local sont perdues en cas de recréation ou de suppression d'une instance.

Le processus d'autoréparation ne réassocie pas les disques qui ne sont pas spécifiés dans le modèle de l'instance, tels que les disques que vous avez associés manuellement à une VM après sa création.

Pour conserver les données importantes écrites sur le disque, vous devez prendre des précautions, par exemple :

  • prendre des instantanés réguliers des disques persistants ;

  • exporter des données vers une autre source, telle que Cloud Storage.

Si vous souhaitez conserver des paramètres importants de vos instances, Google vous recommande également d'utiliser dans votre modèle d'instance une image personnalisée contenant tous les paramètres personnalisés dont vous avez besoin. Ainsi, lorsqu'une instance est recréée, le groupe d'instances géré utilise l'image personnalisée que vous avez spécifiée.

Mettre à jour les groupes d'instances gérés

Vous pouvez facilement déployer de nouvelles versions de logiciels sur des instances de vos groupes d'instances gérés. Le déploiement d'une mise à jour se fait automatiquement selon vos spécifications : vous pouvez contrôler la vitesse et le champ d'application de la mise à jour afin de maîtriser les interruptions de votre application. Vous pouvez éventuellement effectuer des déploiements partiels pour des tests en version Canary. Consultez la page Mettre à jour les groupes d'instances gérés.

Groupes d'instances non gérés

Les groupes d'instances non gérés sont des groupes d'instances différentes que vous pouvez ajouter au groupe et supprimer arbitrairement. Les groupes d'instances non gérés ne permettent pas l'autoscaling, ne prennent pas en charge la mise à jour progressive, ni l'utilisation de modèles d'instance. Pour cette raison, Google recommande de créer des groupes d'instances gérés, autant que possible. Utilisez des groupes d'instances non gérés uniquement si vous devez appliquer un équilibrage de charge à vos configurations préexistantes ou à des groupes d'instances différentes.

Si vous devez créer un groupe d'instances différentes qui ne suivent pas un modèle d'instance, consultez la section Groupes d'instances non gérés.

Groupes d'instances et équilibrage de charge

Toutes les configurations d'équilibrage de charge disponibles sur Google Cloud Platform nécessitent que vous spécifiiez un backend (un groupe d'instances, un pool cible ou un groupe de points de terminaison réseau) pouvant diffuser le trafic distribué à partir du service de backend de l'équilibreur de charge.

Pour l'équilibrage de charge HTTP(S), interne, proxy TCP et proxy SSL, vous pouvez attribuer un groupe d'instances au service de backend. Un service de backend est un service centralisé de gestion des backends, qui à son tour gère les instances qui traitent les requêtes des utilisateurs pour votre équilibreur de charge. Chaque service de backend contient un ou plusieurs backends, et chacun d'entre eux peut contenir un groupe d'instances. Le service de backend connaît les instances qu'il peut utiliser, le trafic qu'il peut gérer et le trafic qu'il traite actuellement. Vous pouvez affecter un groupe d'instances, géré ou non, à un service de backend.

Pour l'équilibrage de la charge du réseau, vous devez ajouter des instances de VM individuelles à un pool cible ou attribuer un ou plusieurs groupes d'instances gérés à un pool cible, ce qui entraîne l'ajout de toutes les instances du groupe d'instances au pool cible spécifié.

Pour plus d'informations sur les différentes configurations d'équilibrage de charge, consultez la documentation sur l'équilibrage de charge.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine