Distribuer des instances à l'aide de groupes d'instances gérés régionaux

Cette page explique comment créer des groupes d'instances gérés avec des instances distribuées sur une seule région.

Contrairement aux groupes d'instances gérés zonaux, qui appartiennent à une seule zone, les groupes d'instances gérés régionaux améliorent la disponibilité des applications en répartissant les instances entre plusieurs zones d'une même région. Par exemple, un groupe d'instances géré régional associé à la région us-east1 pourra par défaut gérer la distribution équitable des instances dans trois zones de cette région : us-east1-b, us-east1-c et us-east1-d.

Pour les régions contenant plus de trois zones, le groupe d'instances géré régional peut choisir trois zones pour y créer des instances. Vous pouvez également sélectionner les zones dans lesquelles créer des instances, ou créer des instances dans des régions comportant moins de trois zones. Par exemple, si vous souhaitez accélérer les charges de travail exploitant des GPU, vous devez sélectionner les zones qui prennent en charge les GPU.

À l'instar des groupes d'instances gérés zonaux, les groupes d'instances gérés régionaux prennent en charge l'autoscaling, l'équilibrage de charge interne et l'équilibrage de charge externe.

Avant de commencer

Limites

  • Chaque groupe d'instances géré régional peut contenir jusqu'à 2 000 instances.
  • Lors de la mise à jour d'un groupe d'instances géré, vous ne pouvez pas spécifier plus de 1 000 instances dans une même requête.
  • Vous ne pouvez pas utiliser de groupes d'instances gérés régionaux avec un équilibreur de charge utilisant l'option d'équilibrage maxRate.

Opter pour des groupes d'instances gérés régionaux

Google recommande d'utiliser des groupes d'instances gérés régionaux plutôt que zonaux, car ils vous permettent de répartir la charge des applications entre plusieurs zones. Vous évitez ainsi de confiner une application dans une zone unique ou de gérer plusieurs groupes d'instances localisés dans différentes zones. Cette réplication vous protège contre les défaillances de zone et les scénarios inattendus dans lesquels un groupe entier d'instances d'une même zone cesse de fonctionner correctement. Dans une telle éventualité, votre application peut continuer à traiter le trafic à partir d'instances exécutées dans une autre zone de la même région.

En cas de défaillance d'une zone ou lorsque tout un groupe d'instances d'une même zone ne répond plus, les groupes d'instances gérés régionaux continuent à prendre en charge vos VM comme suit :

  • Les instances qui appartiennent aux zones restantes du groupe d'instances géré régional continuent à diffuser le trafic. Aucune nouvelle instance n'est ajoutée ni redistribuée (sauf si vous configurez l'autoscaling).

  • Une fois la zone défaillante récupérée, le groupe d'instances recommence à diffuser le trafic depuis cette zone.

Pour concevoir des applications robustes et évolutives, utilisez des groupes d'instances gérés régionaux.

Rééquilibrage automatique

Les groupes d'instances gérés régionaux tentent de maintenir un nombre égal d'instances de VM à l'échelle du nombre de zones spécifié, afin de pouvoir gérer les charges de travail à haute disponibilité. Si une autre action, comme un appel de méthode deleteInstances ou abandonInstances, déséquilibre le nombre d'instances de VM entre les différentes zones, le groupe intervient activement pour rétablir cet équilibre. Il peut ainsi être amené à supprimer ou ajouter des instances pour restaurer l'équilibre.

Par exemple, supposons que vous disposez d'un groupe d'instances géré régional comportant deux instances dans la zone us-central1-a, une instance dans la zone us-central1-b et une instance dans la zone us-central1-c. Le fait de supprimer l'instance de VM de la zone us-central1-c poussera le groupe à tenter un rééquilibrage, afin que les instances soient à nouveau réparties de manière égale entre les zones.

Dans ce cas, le groupe supprime une instance de la zone us-central1-a et ajoute une instance à la zone us-central1-c, afin que chacune des zones contienne une instance. Vous n'avez pas la possibilité de sélectionner l'instance à supprimer.

Ce comportement est activé par défaut pour permettre aux groupes d'instances gérés régionaux de gérer des charges de travail à haute disponibilité, mais vous devez en être conscient lorsque vous supprimez ou retirez des instances d'un groupe d'instances géré régional.

Provisionner la taille appropriée pour un groupe d'instances géré

Afin de parer aux cas extrêmes dans lesquels une zone tout entière devient indisponible ou tout un groupe d'instances cesse de répondre, Compute Engine recommande fortement de surprovisionner les groupes d'instances gérés. Selon les besoins de l'application, le surprovisionnement du groupe peut empêcher votre système de tomber en panne lorsqu'une zone ou un groupe d'instances ne répond plus.

Google formule ces recommandations de surprovisionnement en retenant comme priorité la disponibilité de votre application pour les utilisateurs. Ces recommandations impliquent de provisionner et d'acheter plus d'instances de machine virtuelle que votre application n'en requiert au quotidien. Il vous appartient de trouver le compromis optimal entre le niveau de surprovisionnement répondant aux besoins de l'application et vos contraintes budgétaires.

Provisionner un groupe d'instances géré régional sur trois zones ou plus

Si vous créez un groupe d'instances géré régional dans une région comportant au moins trois zones, Google recommande de le surprovisionner d'au moins 50 %. Par défaut, un groupe d'instances géré régional crée des instances dans trois zones. Des instances de VM distribuées entre trois zones suffisent déjà à préserver au moins les deux tiers de votre capacité de diffusion. En cas de défaillance de l'une des zones, les deux autres zones de la région peuvent continuer à diffuser le trafic sans interruption. En cas de perte d'un tiers de la capacité, un surprovisionnement à 150 % garantit que 100 % du trafic reste pris en charge par les zones restantes.

Par exemple, si vous avez besoin de 20 instances de machine virtuelle réparties entre trois zones dans votre groupe d'instances géré, nous vous recommandons d'ajouter au moins 50 % d'instances supplémentaires. Dans ce cas, 50 % de 20 instances équivalent à 10 instances supplémentaires, soit un total de 30 instances dans le groupe. Si vous créez un groupe d'instances géré régional contenant 30 instances, ce groupe distribue les instances de manière aussi égale que possible entre les trois zones, comme suit :

Zone Nombre d'instances
exemple-zone-1 10
exemple-zone-2 10
exemple-zone-3 10

En cas de défaillance de l'une des zones, il vous restera 20 instances pour diffuser le trafic.

Provisionner un groupe d'instances géré régional sur deux zones

Si vous souhaitez provisionner les instances dans deux zones au lieu de trois, Google recommande de doubler le nombre d'instances. Par exemple, s'il vous faut 20 instances de machine virtuelle pour assurer votre service et que vos instances sont réparties entre deux zones, vous devez configurer un groupe d'instances géré régional comportant 40 instances, de sorte que chaque zone contienne 20 instances. En cas de défaillance de l'une des zones, il vous restera 20 instances pour diffuser le trafic.

Zone Nombre d'instances
exemple-zone-1 20
exemple-zone-2 20

Si les instances de votre groupe ne peuvent pas être distribuées en nombre égal entre les deux zones, Compute Engine répartit les instances de manière aussi égale que possible et place aléatoirement l'instance restante dans l'une des zones.

Provisionner un groupe d'instances géré régional dans une zone

Il est possible de créer un groupe d'instances géré régional comportant une seule zone. Cette opération s'apparente à la création d'un groupe d'instances géré zonal, à quelques différences près :

  • Si vous créez un groupe d'instances géré régional comportant une seule zone, vous aurez la possibilité d'ajouter des zones à ce groupe ultérieurement. Vous ne pouvez pas ajouter de zones supplémentaires à un groupe d'instances géré zonal.

  • Nombre de nouvelles fonctionnalités sont d'abord introduites dans les groupes d'instances gérés zonaux.

La création d'un groupe d'instances géré régional à une seule zone est déconseillée, car cette configuration est celle qui offre le moins de disponibilité. En cas de défaillance de la zone ou de la région, l'intégralité de votre groupe d'instances géré devient indisponible, ce qui risque de perturber les utilisateurs.

Sélectionner des zones pour votre groupe

La configuration par défaut d'un groupe d'instances géré régional consiste à répartir les instances de manière aussi égale que possible entre trois zones. Pour diverses raisons, vous pouvez avoir besoin de sélectionner des zones spécifiques pour une application. Par exemple, si vous avez besoin de GPU pour vos instances, vous pouvez sélectionner uniquement les zones prenant en charge les GPU. Vous pourriez aussi avoir des disques persistants qui ne sont disponibles que dans certaines zones, ou vous pourriez préférer commencer avec des instances de VM déployées dans quelques zones seulement, plutôt que dans trois zones d'une région sélectionnées de manière aléatoire.

Si vous souhaitez choisir le nombre de zones et/ou sélectionner les zones spécifiques dans lesquelles le groupe d'instances doit s'exécuter, vous devez le faire lors de la création du groupe. À partir du moment où vous avez choisi des zones spécifiques lors de la création, vous ne pouvez plus les modifier ni les mettre à jour par la suite.

  • Pour sélectionner plus de trois zones dans une région, vous devez spécifier ces zones une à une. Par exemple, pour sélectionner les quatre zones d'une région, vous devez désigner explicitement ces quatre zones dans votre requête. Si vous ne le faites pas, Compute Engine sélectionnera trois zones par défaut.

  • Pour sélectionner deux zones ou une seule zone d'une région, vous devez spécifier explicitement chaque zone. Même si la région ne contient que deux zones, vous devez spécifier explicitement les zones dans votre requête.

Que vous souhaitiez choisir des zones spécifiques ou simplement sélectionner la région puis laisser Compute Engine créer des instances dans toutes ses zones, les instances de VM seront distribuées de manière égale entre les différentes zones. Il est donc essentiel de provisionner suffisamment d'instances de VM pour prendre en charge vos applications dans le nombre de zones spécifié.

Créer un groupe d'instances géré régional

Pour créer un groupe d'instances géré régional, vous pouvez utiliser l'outil de ligne de commande gcloud, la console ou l'API.

Si la capacité de chaque zone est insuffisante pour prendre en charge les instances du groupe d'instances, Compute Engine crée autant d'instances que possible, puis tente de créer les instances restantes lorsqu'un quota supplémentaire devient disponible.

Puisque vous créez un groupe d'instances géré régional, gardez à l'esprit que certaines ressources, comme les disques persistants, sont de type zonal. Si vous spécifiez dans votre modèle d'instance des ressources zonales telles que des disques persistants supplémentaires, ces disques doivent être présents dans toutes les zones pour pouvoir être associés aux instances créées par ce groupe d'instances géré régional.

Par défaut, si vous ne désignez pas explicitement les zones dans votre demande, Compute Engine choisit trois zones pour y créer les instances. Si vous devez créer des instances dans plus de trois zones ou dans moins de trois zones, ou si vous souhaitez sélectionner les zones utilisées, fournissez la liste des zones voulues dans votre demande. Reportez-vous à la section Sélectionner des zones pour votre groupe.

Console

  1. Accédez à la page "Groupes d'instances" de la console GCP.

    Accéder à la page "Groupes d'instances"

  2. Cliquez sur Créer un groupe d'instances pour définir un nouveau groupe d'instances.
  3. Sous Emplacement, sélectionnez Multizone.
  4. Choisissez la région souhaitée.
  5. Si vous souhaitez choisir des zones spécifiques, cliquez sur Configurer des zones pour sélectionner les zones à utiliser.
  6. Choisissez un modèle d'instance pour le groupe d'instances ou créez-en un.
  7. Indiquez le nombre d'instances pour ce groupe. Pensez à provisionner suffisamment d'instances pour prendre en charge votre application en cas de défaillance d'une zone.
  8. Terminez le processus de création du groupe d'instances géré.

gcloud

Tous les groupes d'instances gérés requièrent un modèle d'instance. Commencez par créer un modèle d'instance si vous n'en avez pas. Par exemple, la commande suivante crée un modèle d'instance de base doté des propriétés par défaut :

gcloud compute instance-templates create example-template

Ensuite, utilisez la sous-commande instance-groups managed create avec l'indicateur --region. Par exemple, la commande suivante crée un groupe d'instances géré régional dans trois zones de la région us-east1 :

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --region us-east1

Si vous souhaitez sélectionner les zones spécifiques que le groupe doit utiliser, ajoutez l'indicateur --zones :

gcloud compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --zones us-east1-b,us-east1-c

API

Tous les groupes d'instances gérés requièrent un modèle d'instance. Commencez par créer un modèle d'instance si vous n'en avez pas.

Dans l'API, créez une requête POST utilisant la méthode regionInstanceGroupManagers.insert. Dans le corps de la demande, indiquez le nom du groupe, sa taille, le nom de base de ses instances et l'URL de son modèle d'instance.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers

{
  "baseInstanceName": "[BASE_INSTANCE_NAME]",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "[INSTANCE_GROUP_NAME]",
  "targetSize": "[TARGET_SIZE]",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/[ZONE]"},
       {"zone": "zones/[ZONE]"}
      ]
   }
}

où :

  • [PROJECT_ID] est l'ID de projet pour cette demande.
  • [REGION] est la région du groupe d'instances.
  • [BASE_INSTANCE_NAME] est le nom de base de toutes les instances créées au sein du groupe d'instances. Par exemple, le nom d'instance de base example-instance engendrerait des instances portant des noms du type example-instance-[RANDOM_STRING], où [RANDOM_STRING] est une chaîne aléatoire générée par le serveur.
  • [INSTANCE_TEMPLATE_NAME] est le modèle d'instance à utiliser.
  • [TARGET_SIZE] est le nombre cible d'instances du groupe d'instances.

Si vous souhaitez sélectionner des zones spécifiques, ou si vous créez des instances dans une région comportant moins de trois zones ou plus de trois zones, incluez la propriété distributionPolicy dans votre requête et fournissez une liste de zones. Remplacez [ZONE] par le nom de la zone dans laquelle créer les instances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers

{
  "baseInstanceName": "[BASE_INSTANCE_NAME]",
  "instanceTemplate": "global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
  "name": "[INSTANCE_GROUP_NAME]",
  "targetSize": "[TARGET_SIZE]",
  "distributionPolicy": {
     "zones": [
       {"zone": "zones/[ZONE]"},
       {"zone": "zones/[ZONE]"}
      ]
   }
}

Par exemple, la demande qui suit crée un groupe d'instances nommé example-rmig et comportant 10 instances distribuées entre les zones us-east1-b et us-east1-c :

POST https://www.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers
{

  "baseInstanceName": "example-instance",
  "instanceTemplate": "global/instanceTemplates/example-instance",
  "name": "example-rmig",
  "targetSize": 10,
  "distributionPolicy": {
      "zones": [
        {"zone": "zones/us-east1-b"},
        {"zone": "zones/us-east1-c"}
      ]
   }
}

Lister les instances d'un groupe d'instances géré régional

Pour obtenir la liste des instances de votre groupe d'instances géré régional, utilisez la console GCP, la commande instance-groups managed list-instances de l'outil de ligne de commande gcloud ou une requête utilisant la méthode regionInstanceGroupManagers.listManagedInstances.

Console

  1. Accédez à la page "Groupes d'instances" de la console GCP.

    Accéder à la page "Groupes d'instances"

  2. Cliquez sur le nom du groupe d'instances géré régional dont vous souhaitez afficher les instances.

La page "Détails du groupe d'instances" vous présente la liste des instances de ce groupe d'instances.

gcloud

Exécutez la commande instance-groups managed list-instances :

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] --region [REGION]

où :

  • [INSTANCE_GROUP_NAME] est le nom du groupe d'instances.
  • [REGION] est la région du groupe d'instances.

Par exemple, la commande suivante répertorie les instances faisant partie d'un groupe d'instances nommé example-rmig et associé à la région us-east1 :

gcloud compute instance-groups managed list-instances example-rmig --region us-east1

API

Dans l'API, créez une demande GET vide utilisant la méthode regionInstanceGroupManagers.listManagedInstances.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Exemple :

GET https://www.googleapis.com/compute/v1/projects/myproject/regions/us-east1/instanceGroupManagers/example-rmig

Mettre à jour un groupe d'instances géré régional

Vous pouvez mettre à jour un groupe d'instances géré régional à l'aide de l'outil de mise à jour de groupe d'instances. Cet outil vous permet de mettre à jour tout ou partie des instances d'un groupe vers un nouveau modèle d'instance. Vous pouvez également utiliser l'outil de mise à jour pour effectuer des mises à jour Canary et contrôler la vitesse de votre mise à jour.

De même, vous pouvez modifier le modèle d'instance d'un groupe d'instances sans mettre à jour les instances existantes à l'aide de la commande set-instance-template de gcloud ou de la méthode setInstanceTemplate de l'API. Notez que la modification du modèle d'instance ne met pas automatiquement à jour les instances existantes vers le nouveau modèle. Vous devez recréer individuellement les instances ou exécuter l'outil de mise à jour de groupe d'instances pour appliquer les modifications. En revanche, les instances de machine virtuelle nouvellement créées dans le groupe utiliseront le nouveau modèle d'instance.

Activer l'autoscaling pour un groupe d'instances géré régional

Compute Engine propose une fonction d'autoscaling pour les groupes d'instances gérés, qui peuvent ainsi ajouter ou supprimer automatiquement des instances selon que la charge augmente ou diminue. Vous pouvez aussi activer l'autoscaling pour les groupes d'instances gérés régionaux.

Si vous activez l'autoscaling pour un groupe d'instances géré régional, cette fonctionnalité se comporte comme suit :

  • Une règle d'autoscaling s'applique au groupe dans son ensemble (et non à des zones individuelles). Par exemple, si vous configurez l'autoscaler pour un objectif d'utilisation du processeur de 66 %, celui-ci suit toutes les instances du groupe pour maintenir une utilisation moyenne de 66 % sur l'ensemble des instances de toutes les zones.

  • L'autoscaling tente de répartir les instances aussi uniformément que possible entre les zones disponibles. En règle générale, l'autoscaler équilibre la taille des zones en développant les zones les plus petites et en prévoyant une redirection de la charge depuis les zones les plus importantes. Nous vous déconseillons de configurer un équilibreur de charge personnalisé privilégiant une zone par rapport aux autres, car cela pourrait provoquer un comportement inattendu.

  • En cas de défaillance d'une zone entière ou de tout un groupe d'instances d'une même zone, vous pouvez perdre un tiers de la capacité, mais les deux tiers restants seront toujours disponibles dans les autres zones. Nous vous recommandons de définir la règle d'autoscaling de manière à surprovisionner le groupe d'instances géré concerné : vous éviterez ainsi de surcharger les serveurs restants durant les périodes d'indisponibilité d'une zone.

L'autoscaler n'ajoutera des instances à une zone qu'à concurrence d'un tiers du nombre maximal spécifié pour le groupe. Par exemple, si le paramètre maxNumReplicas configuré pour l'autoscaling est défini sur 15, l'autoscaler ne peut ajouter des instances dans une zone qu'à concurrence de 1/3 * 15 = 5 instances. En cas de défaillance d'une zone, l'autoscaler n'augmentera le nombre d'instances que jusqu'aux deux tiers de maxNumReplicas dans les deux zones restantes combinées.

Provisionner la configuration de l'autoscaler

De même que pour les groupes d'instances gérés, vous devez surprovisionner la configuration de l'autoscaler en tenant compte des considérations suivantes :

  • L'objectif d'utilisation configuré pour l'autoscaling doit correspondre aux deux tiers de la valeur effective souhaitée.
  • Pour tenir compte de cet objectif d'utilisation réduit, l'autoscaler ajoutera davantage d'instances. Vous devez donc majorer la valeur maxNumReplicas de 50 % par rapport au nombre que vous auriez défini indépendamment du surprovisionnement.

Par exemple, si vous estimez que 20 instances suffisent à gérer vos pics de charge et si l'objectif d'utilisation est fixé à 80 %, configurez l'autoscaler comme suit :

  • 2/3 * 0,8 = 0,53 ou 53 % pour l'objectif d'utilisation, au lieu de 80 %
  • 3/2 * 20 = 30 pour le nombre maximal d'instances, au lieu de 20

Cette configuration garantit que le groupe d'instances ne sera pas à court de capacité en cas de défaillance d'une zone unique. En effet, les deux tiers des instances resteront disponibles, ce qui est suffisant pour absorber la charge supplémentaire provenant de la zone défaillante (puisque vous avez réduit l'objectif d'utilisation bien en deçà de la capacité). L'autoscaler ajoute également des instances jusqu'à concurrence du nombre maximal que vous avez spécifié, de façon à assurer l'objectif d'utilisation de 2/3.

Cependant, vous ne devez pas compter uniquement sur le surprovisionnement de vos groupes d'instances gérés pour gérer une charge accrue. Google vous recommande de tester régulièrement vos applications pour vous assurer qu'elles sont en mesure de gérer les pointes d'utilisation qui résulteraient d'une défaillance de zone supprimant un tiers des instances.

Activer l'autoscaling

Console

  1. Accédez à la page "Groupes d'instances" de la console GCP.

    Accéder à la page "Groupes d'instances"

  2. Si vous ne disposez d'aucun groupe d'instances, créez-en un. Dans le cas contraire, cliquez sur le nom d'un groupe d'instances géré régional existant dans la liste.
  3. Sur la page d'informations du groupe d'instances, cliquez sur le bouton Modifier le groupe.
  4. Sous "Autoscaling", cochez Activé.
  5. Renseignez les propriétés de la configuration de l'autoscaling.
  6. Enregistrez les modifications.

gcloud

À l'aide de l'outil de ligne de commande gcloud, utilisez la sous-commande set-autoscaling en spécifiant l'indicateur --region pour activer l'autoscaling régional. Pour plus d'informations sur la création d'un autoscaler, reportez-vous la documentation relative à l'autoscaling.

À titre d'exemple, l'extrait de code ci-dessous configure un autoscaler pour un groupe d'instances nommé example-rmig. Remplacez us-east1 par le nom de la région contenant votre groupe d'instances géré, example-autoscaler par le nom souhaité pour l'autoscaler et example-rmig par le nom du groupe d'instances géré régional :

gcloud compute instance-groups managed set-autoscaling example-rmig \
  --target-cpu-utilization 0.8 --max-num-replicas 5 --region us-east1

API

Pour configurer l'autoscaling dans l'API, envoyez une demande POST à l'URL suivante, en spécifiant votre propre ID de projet et la région de votre groupe d'instances géré :

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/regionAutoscalers/

Le corps de la demande doit contenir les champs name, target et autoscalingPolicy. Le champ autoscalingPolicy doit définir les paramètres cpuUtilization et maxNumReplicas.

{
 "name": "[AUTOSCALER_NAME]",
 "target": "regions/us-east1/instanceGroupManagers/[INSTANCE_GROUP_NAME]",
 "autoscalingPolicy": {
    "maxNumReplicas": [MAX_NUM_INSTANCES],
    "cpuUtilization": {
       "utilizationTarget": [TARGET_UTILIZATION]
     },
    "coolDownPeriodSec": [SECONDS]
  }
}

Exemple :

{
 "name": "example-autoscaler",
 "target": "regions/us-east1/instanceGroupManagers/example-rmig",
 "autoscalingPolicy": {
    "maxNumReplicas": 10,
    "cpuUtilization": {
       "utilizationTarget": 0.8
     },
    "coolDownPeriodSec": 30
  }
}

Mettre à jour un autoscaler

Vous pouvez mettre à jour un autoscaler régional comme vous le feriez pour un autoscaler zonal. Reportez-vous à la section Mettre à jour un autoscaler.

Ajouter un groupe d'instances géré régional à un équilibreur de charge

La fonctionnalité d'équilibrage de charge de Google Cloud Platform utilise des groupes d'instances pour diffuser le trafic. Selon le type d'équilibreur de charge que vous utilisez, vous pouvez ajouter des groupes d'instances à un pool cible ou à un service de backend cible. Pour en savoir plus sur les groupes d'instances gérés et l'équilibrage de charge, reportez-vous à la présentation des groupes d'instances.

Vous pouvez affecter un groupe d'instances géré régional en tant que cible d'un service de backend dans le but d'équilibrer la charge externe ou d'équilibrer la charge interne, ou dans le cadre d'un pool cible afin d'équilibrer la charge réseau.

Dans le cas de l'équilibrage de charge HTTP(S), seuls maxRatePerInstance et maxUtilization sont pris en charge pour les groupes d'instances gérés régionaux.

Ajouter un groupe d'instances géré régional à un service de backend

Un service de backend est nécessaire pour créer un équilibreur de charge HTTP(S), interne ou SSL. Ce type de service contient des backends individuels qui comportent chacun un groupe d'instances, géré ou non. Les instances du groupe répondent au trafic provenant de l'équilibreur de charge. Le service de backend sait à son tour quelles instances il peut exploiter, quel volume de trafic il peut traiter et quel volume il traite actuellement. En outre, le service de backend vérifie l'état et n'envoie pas de nouvelles connexions aux instances défectueuses.

Pour découvrir comment ajouter un groupe d'instances à un service de backend, consultez la section Ajouter des groupes d'instances à un service de backend.

Ajouter un groupe d'instances géré régional à un pool cible

Un pool cible est un objet qui contient une ou plusieurs instances de machine virtuelle. Il permet à un équilibreur de charge réseau de transférer des requêtes utilisateur vers le pool cible associé. Les instances qui appartiennent à ce pool cible traitent ces requêtes et renvoient une réponse. Vous pouvez ajouter un groupe d'instances géré à un pool cible pour que, lorsque des instances sont ajoutées ou supprimées dans ce groupe, le pool soit lui aussi automatiquement mis à jour avec les modifications.

Le pool cible dans lequel vous ajoutez un groupe d'instances géré doit avoir été créé au préalable. Pour en savoir plus, consultez la section Ajouter un pool cible.

Pour ajouter un groupe d'instances géré existant à un pool cible, suivez les instructions ci-dessous. Ce processus permet d'ajouter toutes les instances de VM faisant partie du groupe géré au pool cible.

Console

  1. Accédez à la page "Pools cibles" de la console GCP.

    Accéder à la page "Pools cibles"

  2. Cliquez sur le pool cible auquel vous souhaitez ajouter le groupe d'instances.
  3. Cliquez sur le bouton Modifier.
  4. Faites défiler l'écran vers le bas jusqu'à la section Instances de VM, puis cliquez sur Sélectionner des groupes d'instances.
  5. Sélectionnez un groupe d'instances dans le menu déroulant.
  6. Enregistrez les modifications.

gcloud

Dans l'outil de ligne de commande gcloud, exécutez la commande set-target-pools :

gcloud beta compute instance-groups managed set-target-pools [INSTANCE_GROUP] \
    --target-pools [TARGET_POOL,..] [--region REGION]

où :

  • [INSTANCE_GROUP] est le nom du groupe d'instances.
  • [TARGET_POOL] est le nom du ou des pools cibles dans lesquels vous souhaitez ajouter le groupe d'instances.
  • [REGION] est la région du groupe d'instances.

API

Dans l'API, envoyez une demande POST à l'adresse URI suivante :

POST https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/regionInstanceGroupManagers/[INSTANCE_GROUP]/setTargetPools

où :

  • [PROJECT_ID] est l'ID de projet pour cette demande.
  • [REGION] est la région du groupe d'instances.
  • [INSTANCE_GROUP] est le nom du groupe d'instances.

Le corps de la requête doit contenir une liste d'URI pointant vers les pools cibles auxquels vous souhaitez ajouter le groupe. Exemple :

{
  "targetPools": [
    "regions/us-central1/targetPools/example-targetpool-1",
    "regions/us-central1/targetPools/example-targetpool-2"
  ]
}

Simuler une défaillance de zone pour un groupe d'instances géré régional

Afin de vérifier que votre groupe d'instances géré régional est suffisamment surprovisionné pour survivre à une panne de zone, vous pouvez utiliser l'exemple suivant, qui simule une défaillance affectant une seule zone.

Ce script arrête et démarre Apache dans le cadre de son scénario par défaut. Si cela ne convient pas pour votre application, remplacez les commandes d'arrêt et de démarrage d'Apache par votre propre scénario de défaillance et de récupération.

  1. Déployez ce script et exécutez-le en continu sur chaque instance de machine virtuelle du groupe d'instances. Pour ce faire, vous pouvez ajouter le script au modèle d'instance, ou l'inclure dans une image personnalisée et utiliser cette image dans le modèle d'instance.

    zone_failure/failure.sh 
    #!/usr/bin/env bash

# Copyright 2016 Google Inc. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

set -o nounset
set -o errexit
set -o pipefail

function GetMetadata() {
  curl -s "$1" -H "Metadata-Flavor: Google"
}

PROJECT_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/project/attributes"
INSTANCE_METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance"
ZONE=$(GetMetadata "$INSTANCE_METADATA_URL/zone" | cut -d '/' -f 4)
INSTANCE_NAME=$(hostname)

# We keep track of the state to make sure failure and recovery is triggered only once.
STATE="healthy"
while true; do
  if [[ "$ZONE" = "$(GetMetadata $PROJECT_METADATA_URL/failed_zone)" ]] && \
     [[ "$INSTANCE_NAME" = *"$(GetMetadata $PROJECT_METADATA_URL/failed_instance_names)"* ]]; then
    if [[ "$STATE" = "healthy" ]]; then
      STATE="failure"
      # Do something to simulate failure here.
      echo "STARTING A FAILURE"
      /etc/init.d/apache2 stop
    fi
  else
    if [[ "$STATE" = "failure" ]] ; then
      STATE="healthy"
      # Do something to recover here.
      echo "RECOVERING FROM FAILURE"
      /etc/init.d/apache2 start
    fi
  fi
  sleep 5
done

  2. Simulez une défaillance de zone en définissant ces deux champs de métadonnées de projet :

    • failed_zone : définit la zone dans laquelle vous souhaitez simuler la panne (limite la défaillance à une seule zone).
    • failed_instance_names : choisissez les instances à déconnecter d'après leur nom (afin de limiter la défaillance aux seules instances dont le nom contient cette chaîne).

    Vous pouvez définir ces métadonnées à l'aide de l'outil de ligne de commande gcloud. Par exemple, la commande suivante définit une défaillance touchant la zone europe-west1-b et affectant les instances dont le nom commence par instance-base-name :

    gcloud compute project-info add-metadata --metadata failed_zone='europe-west1-b',failed_instance_names='instance-base-name-'

  3. Après avoir simulé la panne, lancez la récupération en supprimant les clés de métadonnées :

    gcloud compute project-info remove-metadata --keys failed_zone,failed_instance_names

Voici quelques exemples des scénarios de défaillance que vous pouvez exécuter à l'aide de ce script :

  • Arrêtez complètement votre application pour voir comment le groupe d'instances géré réagit.
  • Faites en sorte que vos instances renvoient un état "non opérationnel" lors des vérifications de l'état effectuées par l'équilibreur de charge.
  • Reconfigurez iptables de manière à bloquer une partie du trafic à destination ou en provenance de l'instance.
  • Arrêtez les instances de machine virtuelle. Par défaut, celles-ci sont recréées peu de temps après par le groupe d'instances géré régional, mais leur nouvelle incarnation s'arrêtera dès l'exécution du script et aussi longtemps que les valeurs de métadonnées resteront définies. Vous obtenez ainsi une boucle de plantage.

Étapes suivantes

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

Envoyer des commentaires concernant…

Cette page
Commentaires sur la documentation
Documentation Compute Engine
Commentaires sur le produit