Cette page explique comment créer des groupes d'instances gérés (MIG) régionaux. Vous pouvez également créer des MIG zonaux (une seule zone). Les MIG régionaux et zonaux sont compatibles avec l'autoréparation, l'équilibrage de charge, l'autoscaling, la mise à jour automatique et les charges de travail avec état.
Les MIG régionaux offrent une plus grande disponibilité que les MIG zonaux, car leurs instances gérées sont réparties de manière uniforme sur plusieurs zones d'une même région. Toutefois, les MIG régionaux présentent des limites différentes de celles des MIG zonaux.
Qu'il soit zonal ou régional, le MIG base chacune de ses instances gérées sur un modèle d'instance commun et une configuration avec état facultative.
Chaque instance gérée est une entité de données dans le MIG qui contient l'état actuel et l'état souhaité d'une instance de VM. Les MIG maintiennent la haute disponibilité de vos applications en s'assurant de manière proactive que les VM existantes restent à l'état RUNNING.
Pour en savoir plus sur les groupes d'instances et les fonctionnalités qui leur sont associées, consultez la présentation des groupes d'instances.
Avant de commencer
- Si vous voulez utiliser les exemples d'API de ce guide, configurez l'accès aux API.
- Si vous voulez utiliser les exemples de ligne de commande de ce guide, installez l'outil de ligne de commande
gcloud. - Lisez la page relative aux modèles d'instance.
- Apprenez-en plus sur les groupes d'instances gérés (MIG).
- Lisez la section concernant les régions et zones.
Limites
- Chaque MIG régional peut contenir jusqu'à 2 000 VM.
- Lors de la mise à jour d'un MIG, vous ne pouvez pas spécifier plus de 1 000 VM dans une même requête.
- Vous ne pouvez pas utiliser de MIG régionaux avec un équilibreur de charge utilisant l'option d'équilibrage maxRate.
- Lorsqu'ils sont utilisés conjointement à l'autoscaling basé sur les métriques Cloud Monitoring, les MIG régionaux présentent les limitations suivantes :
- Contrairement aux MIG à zone unique, ils ne sont pas compatibles avec le filtrage des métriques par instance.
- Contrairement aux MIG à zone unique, ils ne sont pas compatibles avec l'autoscaling utilisant des métriques par groupe.
Opter pour des groupes d'instances gérés régionaux
Google recommande d'utiliser des MIG régionaux au lieu des MIG zonaux, car ils vous permettent de répartir la charge de votre application entre plusieurs zones, plutôt que de limiter votre application à une seule zone ou de gérer plusieurs groupes d'instances sur différentes zones. L'utilisation de plusieurs zones 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 de VM d'une même zone ne répond plus, un MIG régional continue à prendre en charge vos VM comme suit :
Les VM qui appartiennent aux zones restantes du MIG régional continuent de diffuser le trafic. Aucune nouvelle VM n'est ajoutée et aucune VM n'est redistribuée (sauf si vous configurez l'autoscaling).
Une fois la zone défaillante récupérée, le MIG recommence à diffuser le trafic depuis cette zone.
Pour concevoir des applications robustes et évolutives, utilisez des MIG régionaux.
Redistribution proactive des instances
Par défaut, un MIG régional tente de maintenir une distribution uniforme des VM dans les zones de la région afin de maximiser la disponibilité de votre application en cas de défaillance de la zone.
Si vous supprimez ou abandonnez des instances de votre groupe, cela entraîne une distribution inégale entre les zones. Le groupe redistribue alors les instances de manière proactive pour rétablir une distribution égale.
Pour rétablir une distribution égale entre les zones, le groupe supprime des VM dans les zones contenant davantage de VM et ajoute des VM dans celles qui en contiennent moins. Le groupe choisit automatiquement les VM à supprimer.
Par exemple, supposons que vous disposiez d'un MIG régional avec quatre instances dans chacune des trois zones suivantes : a, b et c. Si vous supprimez trois instances gérées dans c, le groupe tente d'effectuer un rééquilibrage afin que les instances soient à nouveau distribuées de manière égale entre les zones. Dans ce cas, le groupe supprime deux instances (une de a et une de b) et crée deux instances dans la zone c, afin que chaque zone contienne trois instances. La distribution est ainsi à nouveau égale. Vous n'avez pas la possibilité de sélectionner les instances qui seront supprimées. Le groupe perd temporairement de la capacité pendant le démarrage des nouvelles instances.
Pour empêcher la redistribution automatique de vos VM, vous pouvez désactiver la redistribution proactive des instances lors de la création ou de la mise à jour d'un MIG régional.
Cette fonctionnalité est utile lorsque vous devez :
- Supprimer ou abandonner des machines virtuelles du groupe sans affecter les autres instances de machines virtuelles en cours d'exécution. Par exemple, vous pouvez supprimer une VM de nœud de calcul par lot une fois la tâche terminée sans affecter les autres nœuds de calcul.
- Protéger les machines virtuelles d'une suppression automatique indésirable due à la redistribution proactive en utilisant des applications avec état.
Si vous désactivez la redistribution proactive des instances, un MIG n'ajoute ni ne supprime aucune VM de manière proactive pour atteindre l'équilibre. Toutefois, il profite toujours des opérations de redimensionnement pour tendre vers l'équilibre, chacune de ces opérations étant traitée comme une opportunité d'équilibrer le groupe. Par exemple, lors d'un scaling vertical, le groupe utilise automatiquement le rescaling pour supprimer des VM des zones les plus importantes. Lors d'un scaling horizontal, il ajoute des VM aux zones les plus petites.
Provisionner la taille appropriée pour un MIG afin d'assurer la disponibilité
Divers événements peuvent entraîner l'indisponibilité d'une ou de plusieurs VM. Vous pouvez atténuer le problème à l'aide de plusieurs services Google Cloud :
- Utilisez un MIG régional pour distribuer votre application sur plusieurs zones.
- Utilisez l'autoréparation pour recréer des VM défaillantes.
- Utilisez l'équilibrage de charge pour détourner automatiquement le trafic utilisateur des VM indisponibles.
Toutefois, même si vous faites appel à ces services, vos utilisateurs peuvent toujours rencontrer des problèmes si trop de VM sont indisponibles simultanément.
Afin de parer aux cas extrêmes dans lesquels une zone tout entière devient indisponible ou tout un groupe de VM cesse de répondre, Google vous recommande vivement de surprovisionner votre MIG. Selon les besoins de l'application, le surprovisionnement du groupe empêche votre système de tomber en panne lorsqu'une zone ou un groupe de VM 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 de VM que votre application n'en requiert au quotidien. Déterminez le niveau de surprovisionnement nécessaire en tenant compte des besoins de l'application et de vos contraintes budgétaires.
Estimer la taille de groupe recommandée
Compute Engine vous recommande de provisionner suffisamment de VM afin que, si toutes les VM d'une zone sont indisponibles, le nombre de VM restantes est toujours conforme au nombre minimal de VM requis.
Déterminez la taille minimale recommandée pour votre groupe à l'aide du tableau suivant :
| Nombre de zones | VM supplémentaires | Nombre total recommandé de VM |
|---|---|---|
| 2 | +100 % | 200 % |
| 3 | +50 % | 150 % |
| 4 | +33 % | 133 % |
Le nombre recommandé de VM supplémentaires est inversement proportionnel au nombre de zones où se trouve votre MIG. Ainsi, vous pouvez réduire le nombre de VM supplémentaires en distribuant votre application de manière égale sur un nombre plus élevé de zones.
Provisionner un MIG régional sur trois zones ou plus
Lorsque vous créez un MIG régional dans une région comportant au moins trois zones, nous vous recommandons de surprovisionner votre groupe d'au moins 50 %. Par défaut, un MIG régional crée des VM dans trois zones. Des 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 VM distribuées entre trois zones dans votre MIG, nous vous recommandons d'ajouter au moins 50 % de VM supplémentaires. Dans ce cas, 50 % de 20 VM équivalent à 10 VM supplémentaires, soit un total de 30 VM dans le groupe. Si vous créez un MIG régional avec une taille de 30, le groupe distribue les VM de la manière la plus équitable possible entre les trois zones, comme ci-dessous :
| Zone | Nombre de VM |
|---|---|
| exemple-zone-1 | 10 |
| exemple-zone-2 | 10 |
| exemple-zone-3 | 10 |
En cas de défaillance de l'une des zones, il vous reste 20 VM pour diffuser le trafic.
Provisionner un MIG régional sur deux zones
Pour provisionner vos VM sur deux zones au lieu de trois, nous vous recommandons de doubler le nombre de VM. Par exemple, si vous avez besoin de 20 VM pour votre service, réparties sur deux zones, nous vous recommandons de configurer un MIG régional avec 40 VM, de sorte que chaque zone dispose de 20 VM. En cas de défaillance de l'une des zones, il vous reste 20 VM pour diffuser le trafic.
| Zone | Nombre de VM |
|---|---|
| exemple-zone-1 | 20 |
| exemple-zone-2 | 20 |
Si le nombre de VM de votre groupe n'est pas facilement divisible entre deux zones, Compute Engine répartit les VM aussi équitablement que possible et place les VM restantes de manière aléatoire dans l'une des zones.
Provisionner un MIG régional sur une zone
Il est possible de créer un MIG régional sur une seule zone. Cette opération s'apparente à la création d'un MIG zonal.
La création d'un MIG régional à une seule zone est déconseillée, car cela offre une garantie minime en matière d'applications à disponibilité élevée. En cas de défaillance de la zone, l'intégralité de votre MIG devient indisponible, ce qui risque de perturber les utilisateurs.
Sélectionner des zones pour votre groupe
La configuration par défaut d'un MIG régional consiste à répartir les VM aussi équitablement 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 VM, 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 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 ou des zones spécifiques dans lesquelles le groupe doit s'exécuter, vous devez le faire lors de la création du groupe. Une fois que 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électionne 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 VM dans toutes ses zones, les nouvelles VM sont distribuées par défaut équitablement entre les différentes zones. Il est donc essentiel de provisionner suffisamment de VM pour prendre en charge vos applications dans le nombre de zones spécifié.
Créer un MIG régional
Créez un MIG régional dans 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 VM du groupe, Compute Engine crée autant de VM que possible, puis tente de créer les VM restantes lorsqu'un quota supplémentaire devient disponible.
Puisque vous créez un MIG régional, gardez à l'esprit que certaines ressources, comme les disques persistants, sont zonales. 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 VM créées par ce MIG régional.
Par défaut, si vous ne spécifiez pas explicitement des zones individuelles dans votre requête, Compute Engine choisit automatiquement trois zones dans lesquelles créer des VM. Si vous devez créer des VM 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 requête. Pour en savoir plus, consultez la section Sélectionner des zones pour votre groupe.
La redistribution proactive des instances est activée par défaut. Si vous devez gérer manuellement le nombre de VM dans chaque zone, vous pouvez désactiver la redistribution proactive des instances, mais vous ne pourrez pas configurer l'autoscaling. Pour en savoir plus, consultez la section Redistribution proactive des instances.
Console
- Dans Cloud Console, accédez à la page Groupes d'instances.
- Cliquez sur Créer un groupe d'instances pour définir un nouveau groupe d'instances.
- Sous Emplacement, sélectionnez Plusieurs zones.
- Choisissez la région souhaitée.
- Si vous souhaitez choisir des zones spécifiques, cliquez sur Configurer des zones pour sélectionner les zones à utiliser.
- Si vous souhaitez désactiver la redistribution proactive des instances
- Assurez-vous que le mode d'autoscaling est Désactivé.
- Définissez la redistribution des instances sur Désactivé.
- Choisissez un modèle d'instance pour le groupe d'instances ou créez-en un.
- Indiquez le nombre de VM pour ce groupe. Pensez à provisionner suffisamment de VM pour prendre en charge votre application en cas de défaillance d'une zone.
- Terminez le processus de création de MIG.
gcloud
Tous les MIG 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'option --region. Par exemple, la commande qui suit permet de créer un groupe d'instances géré régional s'étendant sur 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'option --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
Si vous souhaitez désactiver la redistribution proactive des instances, définissez l'option --instance-redistribution-type sur NONE. Vous ne pouvez pas désactiver la redistribution proactive des instances si l'autoscaling est activé.
gcloud compute instance-groups managed create example-rmig \
--template example-template --base-instance-name example-instances \
--size 30 --instance-redistribution-type NONEAPI
Tous les MIG 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, envoyez une requête POST à la méthode regionInstanceGroupManagers.insert. Spécifiez le nom du groupe, sa taille, le nom de base de ses instances et l'URL de son modèle d'instance dans le corps de la requête.
POST https://compute.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"}
]
}
}
Remplacez les éléments suivants :
project-id: ID du projet pour cette requête.region: région du groupe.base-instance-name: nom d'instance pour chaque instance de VM créée au sein du groupe. Par exemple, le nom d'instance de baseexample-instancepermettrait la création d'instances portant des noms du typeexample-instance-[RANDOM_STRING], où[RANDOM_STRING]est une chaîne aléatoire générée par le serveur.instance-template-name: modèle d'instance à utiliser.instance-group-name: nom du MIG.target-size: nombre cible de VM pour le groupe.
Si vous souhaitez sélectionner des zones spécifiques, ou si vous créez des VM 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 la liste des zones. Remplacez [ZONE] par le nom de la zone dans laquelle créer les VM.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers
{
"baseInstanceName": "base-instance-name",
"instanceTemplate": "global/instanceTemplates/instance-template-name",
"name": "instance-group-size",
"targetSize": "target-size",
"distributionPolicy": {
"zones": [
{"zone": "zones/zone"},
{"zone": "zones/zone"}
]
}
}
Par exemple, la requête qui suit permet de créer un MIG régional nommé example-rmig et comportant 10 instances gérées réparties sur les zones us-east1-b et us-east1-c :
POST https://compute.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"}
]
}
}
Si vous souhaitez désactiver la redistribution proactive des instances, indiquez la propriété updatePolicy dans votre requête et définissez sa valeur instanceRedistributionType sur NONE.
Vous ne pouvez pas désactiver la redistribution proactive des instances si l'autoscaling est activé.
POST https://compute.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",
"updatePolicy": {
"instanceRedistributionType": "NONE"
},
}Lister les instances d'un groupe d'instances géré régional
Pour obtenir la liste des instances gérées de votre MIG régional, utilisez Cloud Console, la commande instance-groups managed list-instances de l'outil de ligne de commande gcloud ou une requête appelant la méthode regionInstanceGroupManagers.listManagedInstances.
Console
- Dans Cloud Console, accédez à la page Groupes d'instances.
- Cliquez sur le nom du MIG régional pour lequel vous souhaitez afficher les instances.
La page d'informations 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
Remplacez les éléments suivants :
instance-group-name: nom du MIG.region: région du MIG.
Par exemple, la commande suivante répertorie les instances qui appartiennent à un MIG nommé example-rmig dans la région us-east1 :
gcloud compute instance-groups managed list-instances example-rmig --region us-east1
API
Dans l'API, envoyez une requête GET vide à la méthode regionInstanceGroupManagers.listManagedInstances.
GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name
Exemple :
GET https://compute.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 MIG régional à l'aide de l'outil de mise à jour. Cet outil vous permet de mettre à jour tout ou partie des VM 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 MIG sans mettre à jour les VM 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 VM existantes vers le nouveau modèle d'instance. Vous devez recréer individuellement les instances ou exécuter l'outil de mise à jour pour appliquer les modifications. En revanche, les VM nouvellement créées dans le groupe utiliseront le nouveau modèle d'instance.
Désactiver et réactiver la redistribution proactive des instances
La redistribution proactive des instances conserve un nombre de VM équitable dans les zones sélectionnées de la région. Cette configuration maximise la disponibilité de votre application en cas de défaillance de la zone.
La redistribution proactive des instances est activée par défaut pour les MIG régionaux, mais vous pouvez la désactiver pour les MIG sans autoscaling. Lorsque la redistribution proactive des instances est désactivée, le groupe ne tente pas de redistribuer les VM de manière proactive entre les zones. Ceci est utile si vous devez :
- supprimer manuellement ou abandonner des instances gérées du groupe sans affecter les autres VM en cours d'exécution ;
- supprimer automatiquement une VM de nœud de calcul par lot à la fin de l'exécution de la tâche sans affecter les autres nœuds de calcul ;
- protéger les VM d'une suppression automatique inattendue due à la redistribution proactive en utilisant des applications avec état.
Si vous supprimez ou abandonnez des instances gérées du groupe et que cela provoque un déséquilibre des VM entre les zones, vous devez alors rééquilibrer manuellement le groupe avant de pouvoir réactiver la redistribution proactive. Pour rééquilibrer manuellement le groupe, redimensionnez-le ou supprimez des instances gérées des zones qui comportent le plus de VM.
Lorsque vous redimensionnez un MIG pour lequel la redistribution proactive des instances est désactivée, le groupe profite toujours des opérations de redimensionnement pour tendre vers l'équilibre, chacune de ces opérations étant traitée comme une opportunité d'équilibrer le groupe. Lorsque le groupe est redimensionné à la hausse, il essaie d'ajouter des VM aux zones ayant le plus petit nombre de VM. Lorsqu'il est redimensionné à la baisse, il supprime toujours des VM dans les zones en comportant le plus grand nombre.
Pour créer un MIG régional avec la redistribution proactive des instances désactivée, ou pour activer ou désactiver cette fonctionnalité pour un groupe existant, vous pouvez utiliser la console, l'outil gcloud ou l'API.
Créer un groupe avec la redistribution proactive désactivée
Console
- Dans Cloud Console, accédez à la page Groupes d'instances.
- Cliquez sur Créer un groupe d'instances pour définir un nouveau groupe d'instances.
- Sous Emplacement, sélectionnez Plusieurs zones.
- Choisissez la région souhaitée.
- Si vous souhaitez choisir des zones spécifiques, cliquez sur Configurer des zones pour sélectionner les zones à utiliser.
- Pour désactiver la redistribution proactive des instances :
- Assurez-vous que le mode d'autoscaling est Désactivé.
- Définissez la redistribution des instances sur Désactivé.
- Choisissez un modèle d'instance pour le groupe ou créez-en un.
- Indiquez le nombre de VM pour ce groupe. Pensez à provisionner suffisamment de VM pour prendre en charge votre application en cas de défaillance d'une zone.
- Terminez le processus de création de MIG.
gcloud
Pour créer un MIG régional sans redistribution proactive des instances, utilisez la commande gcloud compute instance-groups managed create avec l'option --instance-redistribution-type définie sur NONE.
gcloud compute instance-groups managed create instance-group-name \
--template template \
--size target-size \
--zones zones \
--instance-redistribution-type NONE
Remplacez les éléments suivants :
instance-group-name: nom du MIG.template: nom du modèle d'instance à utiliser pour le groupe.target-size: taille cible du groupe.zones: liste des zones d'une région unique dans laquelle vous devez déployer des VM.
Exemple :
gcloud compute instance-groups managed create example-rmig \
--template example-template \
--size 30 \
--zones us-east1-b,us-east1-c \
--instance-redistribution-type NONEAPI
Pour créer un MIG régional sans autoscaling et sans redistribution proactive des instances, créez une requête POST pour appeler la méthode regionInstanceGroupManagers.insert. Dans le corps de la requête, incluez la propriété updatePolicy et définissez son champ instanceRedistributionType sur NONE.
POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name
{
"name": "instance-group-name",
"baseInstanceName": "base-instance-name",
"instanceTemplate": "global/instanceTemplates/template",
"targetSize": "target-size",
"distributionPolicy": {
"zones": [
{"zone": "zones/zone"},
{"zone": "zones/zone"}
]
},
"updatePolicy": {
"instanceRedistributionType": "NONE"
}
}
Replace the following:
project-id. The project ID for this request.region. The region for the instance group.instance-group-name. The name for the MIG.base-instance-name. The name prefix for each instance. The instance name suffix is auto generated.template. The name of the instance template to use for the group.target-size. The target size of the instance group.zone. The name of a zone in the single region where you need to deploy VMs.
Désactiver la redistribution proactive des instances
Pour pouvoir désactiver la redistribution proactive des instances, vous devez désactiver l'autoscaling.
Console
- Dans Cloud Console, accédez à la page Groupes d'instances.
- Sélectionnez le MIG à mettre à jour, puis cliquez sur Modifier le groupe.
- Assurez-vous que le mode d'autoscaling est Désactivé.
- Désactivez la redistribution automatique en définissant le paramètre Redistribution des instances sur Désactivé.
- Cliquez sur Enregistrer.
gcloud
Si vous souhaitez désactiver la redistribution proactive des instances pour un MIG régional sans autoscaling, exécutez la commande compute instance-groups managed update avec l'option --instance-redistribution-type définie sur NONE.
gcloud compute instance-groups managed update instance-group-name
--instance-redistribution-type NONE
--region region
Remplacez les éléments suivants :
instance-group-name: nom du MIG.region: région du groupe d'instances.
API
Dans l'API, envoyez une requête PATCH à la méthode regionInstanceGroupManagers.patch. Dans le corps de la requête, incluez la propriété updatePolicy et définissez son champ instanceRedistributionType sur NONE.
PATCH https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/[instance-group-name
{
"updatePolicy": {
"instanceRedistributionType": "NONE"
}
}
Remplacez les éléments suivants :
project-id: ID du projet pour cette requête.region: région du groupe d'instances.instance-group-name: nom d'un MIG sans autoscaling.
Activer la distribution proactive des instances
Pour activer la distribution proactive des instances, exécutez une commande semblable à celle utilisée pour désactiver la redistribution proactive des instances, mais définissez le type de redistribution des instances sur PROACTIVE.
Si vous avez supprimé ou abandonné manuellement certaines instances gérées, entraînant une répartition inégale des VM au sein de la région, vous devez rééquilibrer manuellement le groupe avant de pouvoir réactiver la redistribution proactive des instances. Il ne doit pas y avoir plus d'une VM de différence entre deux zones.
Vous pouvez procéder manuellement à une distribution équitable des instances entre les zones en supprimant les VM des zones comportant le plus d'instances ou en redimensionnant le groupe à la hausse afin que les zones comportant le moins de VM se remplissent jusqu'à obtention d'une distribution égale.
Un MIG régional n'autorise pas l'activation de la redistribution proactive des instances tant que les VM ne sont pas réparties de manière homogène entre les zones (c'est-à-dire tant qu'il existe une différence d'au moins deux VM entre deux zones). Cela permet d'éviter une suppression automatique involontaire des VM dans les zones contenant le plus de VM, ce qui serait l'option utilisée pour obtenir une répartition régulière.
Activer l'autoscaling pour un groupe d'instances géré régional
Compute Engine propose l'autoscaling pour les MIG, ce qui permet à vos groupes d'ajouter (c'est-à-dire effectuer un scaling horizontal) ou de supprimer (c'est-à-dire effectuer un scaling vertical) automatiquement des VM selon que la charge augmente ou diminue.
Si vous activez l'autoscaling pour un MIG 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 VM du groupe pour maintenir une utilisation moyenne de 66 % sur l'ensemble des VM de toutes les zones.
L'autoscaling tente de distribuer les VM de la manière la plus équitable 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, par exemple au moyen d'un équilibreur de charge. 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.
Si votre workflow utilise les VM de trois zones de manière équitable, en cas de défaillance d'une zone entière ou de tout un groupe de VM d'une même zone, vous pouvez perdre un tiers de la capacité, mais les deux tiers restants sont toujours disponibles dans les autres zones. Nous vous recommandons de surprovisionner le MIG régional avec autoscaling : vous éviterez ainsi de surcharger les serveurs restants durant les périodes d'indisponibilité d'une zone.
Si des ressources (par exemple, des VM préemptives) sont temporairement indisponibles dans une zone, le groupe continue d'essayer de créer ces VM dans cette zone. Une fois que les ressources sont à nouveau disponibles, le groupe acquiert le nombre souhaité de VM en cours d'exécution.
Si l'équilibrage de charge est activé et que des ressources sont indisponibles dans une zone, ce qui entraîne une utilisation accrue des ressources existantes dans cette zone, des VM peuvent être créées dans des zones présentant des taux d'utilisation plus faibles, causant ainsi une distribution temporairement inégale.
L'autoscaler n'ajoute des VM dans une zone qu'à concurrence de 1/n du nombre maximal spécifié pour le groupe, n étant le nombre de zones provisionnées. Par exemple, si vous utilisez le nombre de zones par défaut (soit 3) et si le paramètre maxNumReplicas configuré pour l'autoscaling est défini sur 15, l'autoscaler ne peut ajouter que jusqu'à 1/3 * 15 = 5 VM par zone pour le groupe. En cas de défaillance d'une zone, l'autoscaler n'augmente 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 MIG, 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 de VM. Vous devez donc majorer la valeur
maxNumReplicasde 50 % par rapport au nombre que vous auriez défini indépendamment du surprovisionnement.
Par exemple, si vous estimez que 20 VM 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 de VM, au lieu de 20
Cette configuration garantit que le MIG ne sera pas à court de capacité en cas de défaillance d'une zone unique. En effet, les deux tiers des VM 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 VM jusqu'à concurrence du nombre maximal de VM que vous avez spécifié, de façon à assurer l'objectif d'utilisation de deux tiers.
Cependant, vous ne devez pas compter uniquement sur le surprovisionnement de vos MIG pour gérer une charge accrue. Nous vous recommandons 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 VM.
Activer l'autoscaling
Console
- Dans Cloud Console, accédez à la page Groupes d'instances.
- Si vous ne disposez d'aucun groupe d'instances, créez-en un. Sinon, cliquez sur le nom d'un MIG régional existant dans la liste.
- Sur la page d'informations du groupe d'instances, cliquez sur le bouton Modifier le groupe.
- Sous "Autoscaling", cochez Activé.
- Renseignez les propriétés de la configuration de l'autoscaling.
- Enregistrez les modifications.
gcloud
À l'aide de l'outil de ligne de commande gcloud, utilisez la sous-commande set-autoscaling en spécifiant l'option --region pour activer l'autoscaling régional. Pour plus d'informations sur la création d'un autoscaler, consultez la documentation sur l'autoscaling.
Par exemple, les extraits de code suivants configurent un autoscaler pour un exemple de groupe d'instances. Remplacez us-east1 par la région de votre groupe d'instances géré 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-east1API
Pour configurer l'autoscaling régional dans l'API, appelez la [méthode regionAutoscalers.insert [(/compute/docs/reference/rest/v1/regionAutoscalers/insert)
POST https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/regionAutoscalers/
Le corps de votre requête doit contenir les champs name, target et autoscalingPolicy. autoscalingPolicy doit définir cpuUtilization et maxNumReplicas.
Pour faciliter l'identification, nous vous recommandons de nommer la ressource d'autoscaler d'après la ressource MIG qui l'utilise.
{
"name": "<var>autoscaler-name</var>",
"target": "regions/us-east1/instanceGroupManagers/<var>instance-group-name</var>",
"autoscalingPolicy": {
"maxNumReplicas": <var>max-number-of-instances</var>,
"cpuUtilization": {
"utilizationTarget": <var>target-utilization</var>
},
"coolDownPeriodSec": <var>seconds</var>
}
}
Exemple :
{
"name": "example-rmig",
"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, consultez la présentation des groupes d'instances.
Vous pouvez affecter un MIG 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 au sein 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 acceptés pour les MIG 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 les types de services d'équilibrage de charge suivants :
- Équilibrage de charge HTTP(S) externe
- Équilibrage de charge HTTP(S) interne
- Équilibrage de charge proxy SSL
- Équilibrage de charge proxy TCP
- Équilibrage de charge TCP/UDP interne
Un service de backend peut contenir plusieurs backends. Un groupe d'instances est un type de backend. Les instances du groupe d'instances répondent au trafic provenant de l'équilibreur de charge. Le service de backend sait ainsi quelles instances il peut exploiter, quel volume de trafic ces dernières peuvent traiter et quel volume elles traitent actuellement. En outre, le service de backend vérifie l'intégrité des instances et n'envoie pas de nouvelles connexions aux instances défectueuses.
Suivez ces instructions pour ajouter un groupe d'instances géré à un service de backend.
Console
- Accédez à la page "Équilibrage de charge" de Cloud Console.
- Cliquez sur le nom du service de backend auquel vous ajoutez le groupe d'instances géré.
- Cliquez sur Modifier.
- Cliquez sur +Ajouter un backend.
- Sélectionnez le groupe d'instances que vous souhaitez ajouter.
- Modifiez les paramètres facultatifs que vous souhaitez modifier.
- Enregistrez les modifications.
gcloud
Avec l'outil de ligne de commande gcloud, utilisez la commande add-backend :
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
--instance-group=INSTANCE_GROUP \
[--instance-group-region=INSTANCE_GROUP_REGION | --instance-group-zone=INSTANCE_GROUP_ZONE] \
--balancing-mode=BALANCING_MODE
Des paramètres supplémentaires sont requis en fonction du mode d'équilibrage du groupe d'instances géré. Pour en savoir plus, consultez la commande add-backend dans le SDK.
API
Pour ajouter un service de backend à l'aide de l'API REST, consultez les informations sur backendServices.
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 VM. 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
- Accédez à la page "Pools cibles" de Cloud Console.
- Cliquez sur le pool cible auquel vous souhaitez ajouter le groupe d'instances.
- Cliquez sur le bouton Modifier.
- Faites défiler l'écran vers le bas jusqu'à la section Instances de VM, puis cliquez sur Sélectionner des groupes d'instances.
- Sélectionnez un groupe d'instances dans le menu déroulant.
- Enregistrez les modifications.
gcloud
Avec l'outil de ligne de commande gcloud, utilisez 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 auxquels 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://compute.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/regionInstanceGroupManagers/[INSTANCE_GROUP]/setTargetPools
où :
[PROJECT_ID]est l'ID de projet de cette requête.[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.
Déployez ce script et exécutez-le en continu sur chaque VM du groupe. 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.
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 VM à déconnecter d'après leur nom (afin de limiter la défaillance aux seules VM 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 zoneeurope-west1-bet affectant les VM dont le nom commence parinstance-base-name:gcloud compute project-info add-metadata --metadata failed_zone='europe-west1-b',failed_instance_names='instance-base-name-'
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 MIG réagit.
- Faites en sorte que vos VM 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 la VM.
- Arrêtez les VM. Par défaut, celles-ci sont recréées peu de temps après par le MIG 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
- Découvrez comment créer des applications à disponibilité élevée avec des MIG régionaux et un équilibrage de charge.
- Lisez la documentation sur l'équilibrage de charge.
- Lisez la documentation sur l'autoscaling.
- Apprenez à créer des applications Web évolutives et résilientes.
- Découvrez la reprise après sinistre sur Google Cloud Platform.