Distribuer des instances à l'aide des 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 maintient par défaut une distribution égale 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 en sélectionne trois pour y créer des instances. Vous pouvez également sélectionner les zones dans lesquelles créer des instances ou choisir de créer des instances dans des régions comportant moins de trois zones. Par exemple, pour accélérer les charges de travail exploitant des GPU, sélectionnez des zones compatibles avec 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

Si vous souhaitez utiliser les exemples d'API de ce guide, configurez l'accès à l'API.
Si vous souhaitez utiliser les exemples de ligne de commande de ce guide, installez l'outil de ligne de commande gcloud.
Lisez la section relative aux modèles d'instance.
Lisez la section relative aux groupes d'instances gérés.
Lisez la section concernant les régions et zones.

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 au lieu des groupes d'instances gérés 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. 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. Le cas échéant, votre application peut continuer à diffuser le trafic à partir d'instances s'exécutant 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, un groupe d'instances géré régional continue à prendre en charge vos instances de VM comme suit :

Les instances qui appartiennent aux zones restantes du groupe d'instances géré régional continuent de diffuser le trafic. Aucune nouvelle instance n'est ajoutée et aucune instance n'est 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.

Redistribution proactive des instances

Par défaut, un groupe d'instances géré régional tente de maintenir une distribution égale des instances de VM entre les zones de la région afin de maximiser la disponibilité de votre application en cas de défaillance d'une zone.

Si vous utilisez les commandes delete ou abandon sur les instances de VM 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 instances dans les zones contenant davantage d'instances de VM et ajoute de nouvelles instances dans celles qui en contiennent moins. Le groupe choisit automatiquement les instances à supprimer.

La redistribution proactive rétablit une distribution égale entre les zones. — **Exemple de redistribution proactive**

Par exemple, supposons vous disposiez d'un groupe d'instances géré régional avec quatre instances dans chaque zone : us-central1-a, us-central1-b et us-central1-c. Si vous supprimez trois instances de VM dans us-central1-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 dans chacune des zones suivantes : us-central1-a et us-central1-b) et crée deux instances dans la zone us-central1-c, afin que chaque zone contienne trois instances et qu'une distribution égale soit ainsi obtenue. Vous n'avez pas la possibilité de sélectionner l'instance à supprimer.

Pour empêcher la redistribution automatique de vos instances, vous pouvez désactiver la redistribution proactive des instances lors de la création ou de la mise à jour d'un groupe d'instances géré 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 instance de 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.

La désactivation de la redistribution proactive peut affecter la capacité en cas de défaillance d'une zone. — *Distribution inégale après la désactivation de la redistribution proactive*

Si vous désactivez la redistribution proactive des instances, un groupe d'instances géré n'ajoute ni ne supprime les instances 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 à la baisse, le groupe utilise automatiquement le rescaling pour supprimer des instances des zones les plus importantes. Lors d'un scaling à la hausse, il ajoute des instances aux zones les plus petites.

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

Divers événements peuvent entraîner l'indisponibilité d'une ou de plusieurs instances. Vous pouvez atténuer le problème à l'aide de plusieurs services GCP :

Utilisez un groupe d'instances géré régional pour distribuer votre application sur plusieurs zones.
Utilisez l'autoréparation pour recréer des instances défaillantes.
Utilisez l'équilibrage de charge pour détourner automatiquement le trafic utilisateur des instances indisponibles.

Toutefois, même si vous faites appel à ces services, vos utilisateurs peuvent toujours rencontrer des problèmes si trop d'instances sont indisponibles simultanément.

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, nous vous recommandons vivement de surprovisionner votre groupe d'instances géré. 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 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 machines virtuelles que votre application n'en requiert au quotidien. Déterminez le niveau de surprovisionnement en tenant compte des besoins de l'application et de vos contraintes budgétaires.

Estimer la taille recommandée pour un groupe d'instances géré

Compute Engine vous recommande de provisionner suffisamment d'instances afin que, si toutes les instances d'une zone sont indisponibles, le nombre d'instances restantes est toujours conforme au nombre minimal d'instances requis.

Déterminez la taille minimale recommandée pour votre groupe d'instances à 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 dans lesquelles se trouve votre groupe d'instances géré. 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 groupe d'instances géré régional sur trois zones ou plus

Lorsque 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 VM distribuées 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 avec une taille de 30, le groupe d'instances distribue les instances de la manière la plus équitable possible entre les trois zones, comme ci-dessous :

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 reste 20 instances pour diffuser le trafic.

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

Pour provisionner vos instances dans deux zones au lieu de trois, Google recommande de doubler le nombre d'instances. Par exemple, si vous avez besoin de 20 instances de VM pour assurer votre service et que vos instances sont distribuées entre deux zones, nous vous recommandons de 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 reste 20 instances pour diffuser le trafic.

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

S'il est difficile de diviser le nombre d'instances de votre groupe entre deux zones, Compute Engine répartit les instances de la manière la plus équitable possible, puis place de manière aléatoire les instances restantes 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.

La création d'un groupe d'instances géré 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 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 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 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 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. 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. Sinon, 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 instances dans toutes ses zones, les instances de VM sont 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

Créez un groupe d'instances géré 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 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 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 instances créées par ce groupe d'instances géré 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 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 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 d'instances 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

Accédez à la page Groupes d'instances de la console GCP.
Accéder à 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
1. Assurez-vous que le mode d'autoscaling est Désactivé.
2. 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 d'instances pour ce groupe. Pensez à provisionner suffisamment d'instances pour prendre en charge votre application en cas de défaillance d'une zone.
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

Si vous souhaitez désactiver la redistribution proactive des instances, définissez l'indicateur --instance-redistribution-type sur NONE. Cette fonctionnalité étant en version bêta, vous devez utiliser l'outil gcloud beta. Vous ne pouvez pas désactiver la redistribution proactive des instances si l'autoscaling est activé.

gcloud beta compute instance-groups managed create example-rmig \
    --template example-template --base-instance-name example-instances \
    --size 30 --instance-redistribution-type NONE

Remarque : Si vous désactivez la redistribution proactive des instances, utilisez le composant gcloud beta, car cette fonctionnalité est actuellement en version bêta.

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 pour appeler 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 la liste des 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"}
      ]
   }
}

Si vous souhaitez désactiver la redistribution proactive des instances, incluez la propriété updatePolicy dans votre requête et définissez instanceRedistributionType sur NONE. Cette fonctionnalité étant en version bêta, vous devez utiliser l'API bêta. Vous ne pouvez pas désactiver la redistribution proactive des instances si l'autoscaling est activé.

POST https://www.googleapis.com/compute/beta/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 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 appelant la méthode regionInstanceGroupManagers.listManagedInstances.

Console

Accédez à la page "Groupes d'instances" de la console GCP.
Accéder à la page "Groupes d'instances"
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 machines virtuelles 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 d'instances é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 groupes d'instances gérés régionaux, mais vous pouvez la désactiver pour les groupes d'instances gérés sans autoscaling. Lorsque la redistribution proactive des instances est désactivée, le groupe ne tente pas de redistribuer les instances de manière proactive entre les zones. Ceci est utile si vous devez :

Supprimer manuellement ou abandonner des machines virtuelles du groupe sans affecter les autres instances de machines virtuelles en cours d'exécution.
Supprimer automatiquement une instance de nœud de calcul en traitement par lots à la fin de l'exécution de la tâche sans affecter les autres nœuds de calcul.
Protéger les instances d'une suppression automatique inattendue due à la redistribution proactive en utilisant des applications avec état.

Si vous supprimez ou abandonnez des instances de VM du groupe et que cela provoque un déséquilibre des instances 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 des zones qui en comportent le plus.

Lorsque vous redimensionnez un groupe d'instances géré pour lequel la redistribution proactive est désactivée, le groupe utilise les opportunités pour tendre vers l'équilibre, traitant chaque opération de redimensionnement comme une opportunité d'équilibrer le groupe. Lorsque le groupe est redimensionné à la hausse il essaie d'ajouter des instances aux zones ayant le plus petit nombre de VM ; lorsque le groupe est redimensionné à la baisse, le groupe supprime toujours des instances dans les zones en comportant le plus grand nombre.

*Exemple de redimensionnement manuel d'un groupe pour obtenir une redistribution uniforme*

Pour créer un groupe d'instances 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

Accédez à la page "Groupes d'instances" de la console GCP.
Accéder à 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 :
1. Assurez-vous que le mode d'autoscaling est Désactivé.
2. 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 d'instances pour ce groupe. Pensez à provisionner suffisamment d'instances pour prendre en charge votre application en cas de défaillance d'une zone.
Terminez le processus de création du groupe d'instances géré.

gcloud

Pour créer un nouveau groupe d'instances gérés régional sans redistribution proactive des instances, utilisez la commande gcloud beta compute instance-groups managed create avec l'indicateur --instance-redistribution-type défini sur NONE.

gcloud beta compute instance-groups managed create [INSTANCE_GROUP_NAME] \
    --template [TEMPLATE] \
    --size [SIZE] \
    --zones [ZONES] \
    --instance-redistribution-type NONE

Où :

[INSTANCE_GROUP_NAME] est le nom du groupe d'instances.
[TEMPLATE] est le nom du modèle d'instance à utiliser pour le groupe.
[SIZE] correspond à la taille cible du groupe d'instances.
[ZONES] correspond à la liste des zones d'une région où vous devez déployer des instances de VM.

Exemple :

gcloud beta compute instance-groups managed create example-rmig \
    --template example-template \
    --size 30 \
    --zones us-east1-b,us-east1-c \
    --instance-redistribution-type NONE

API

Pour créer un groupe d'instances géré 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://www.googleapis.com/compute/beta/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"
    }
}

Où :

[PROJECT_ID] est l'ID de projet pour cette requête.
[REGION] est la région du groupe d'instances.
[INSTANCE_GROUP_NAME] est le nom du groupe d'instances.
[BASE_INSTANCE_NAME] est le préfixe du nom de chaque instance. Le suffixe du nom d'instance est généré automatiquement.
[TEMPLATE] est le nom du modèle d'instance à utiliser pour le groupe.
[TARGET_SIZE] correspond à la taille cible du groupe d'instances.
[ZONE] est le nom d'une zone de la région où vous devez déployer des instances de VM.

Désactiver la redistribution proactive des instances

Pour pouvoir désactiver la redistribution proactive des instances, vous devez désactiver l'autoscaling.

Console

Accédez à la page "Groupes d'instances" de la console GCP.
Accéder à la page "Groupes d'instances"
Sélectionnez le groupe d'instances à 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 groupe d'instances géré régional sans autoscaling, exécutez la commande compute instance-groups managed update avec l'indicateur --instance-redistribution-type défini sur NONE.

 gcloud beta compute instance-groups managed update [INSTANCE_GROUP_NAME]
    --instance-redistribution-type NONE \
    --region [REGION]

où :

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

Remarque : Si vous désactivez la redistribution proactive des instances, utilisez le composant gcloud beta, car cette fonctionnalité est actuellement en version bêta.

API

Dans l'API, créez une requête PATCH pour appeler la méthode regionInstanceGroupManagers.patch. Dans le corps de la requête, incluez la propriété updatePolicy et définissez le champ instanceRedistributionType sur NONE

PATCH
https://www.googleapis.com/compute/beta/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP]

{
    "updatePolicy": {
         "instanceRedistributionType": "NONE"
    }
}

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 d'un groupe d'instances géré sans autoscaling.

Remarque : Si vous désactivez la redistribution proactive des instances, utilisez l'API car cette fonctionnalité est actuellement en version bêta.

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, entraînant une répartition inégale des instances 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 égale des instances entre les zones en supprimant les VM des zones comportant le plus d'instances ou en redimensionnant le groupe à la hausse de sorte que les zones comportant le moins d'instances se remplissent jusqu'à obtention d'une distribution égale.

Un groupe d'instances géré régional n'autorise pas l'activation de la redistribution proactive des instances tant que ces dernières 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 d'instances, 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 groupes d'instances gérés, qui peuvent ainsi ajouter ou supprimer automatiquement des instances selon que la charge augmente ou diminue.

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 distribuer les instances 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 instances de trois zones de manière équitable, 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 sont toujours disponibles dans les autres zones. Nous vous recommandons de surprovisionner le groupe d'instances géré 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 instances préemptives) sont temporairement indisponibles dans une zone, le groupe continue d'essayer de créer ces instances gérées dans cette zone. Une fois que les ressources sont à nouveau disponibles, le groupe acquiert le nombre souhaité d'instances 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 instances 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 instances 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 instances par zone pour le groupe d'instances. 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 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

Accédez à la page "Groupes d'instances" de la console GCP.
Accéder à la page "Groupes d'instances"
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.
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'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

Vous devez disposer d'un service de backend pour pouvoir créer un équilibreur de charge interne, proxy TCP, proxy SSL ou HTTP(S). 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 machines virtuelles. 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 la console GCP.
Accéder à la page "Pools cibles"
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

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.

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

Afficher sur GitHub

#!/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

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-'
```
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 machines virtuelles. 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

Découvrez comment créer des applications à disponibilité élevée avec des groupes d'instances gérés régionaux et un équilibrage de charge.
Lisez la documentation sur l'équilibrage de charge.
Lisez la documentation relative à l'autoscaling.
Apprenez à créer des applications Web évolutives et résilientes.
Découvrez la reprise après sinistre sur Google Cloud Platform.

Avant de commencer

Limites

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

Redistribution proactive des instances

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

Estimer la taille recommandée pour un groupe d'instances géré

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

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

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

Sélectionner des zones pour votre groupe

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

Console

gcloud

API

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

Console

gcloud

API

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

Désactiver et réactiver la redistribution proactive des instances

Créer un groupe avec la redistribution proactive désactivée

Console

gcloud

API

Désactiver la redistribution proactive des instances

Console

gcloud

API

Activer la distribution proactive des instances

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

Provisionner la configuration de l'autoscaler

Activer l'autoscaling

Console

gcloud

API

Mettre à jour un autoscaler

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

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

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

Console

gcloud

API

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

Étapes suivantes

Envoyer des commentaires concernant…