Fiabilité dans Virtual Machine Scale Sets
Cet article contient des recommandations spécifiques en matière de fiabilité et des informations sur la prise en charge des zones de disponibilité pour Virtual Machine Scale Sets.
Remarque
Virtual Machine Scale Sets ne peut être déployé que dans une seule région. Si vous souhaitez déployer des machines virtuelles dans plusieurs régions, consultez Machines virtuelles-Reprise d’activité : basculement inter-région.
Pour obtenir une vue d’ensemble architecturale de la fiabilité dans Azure, consultez Fiabilité Azure.
Recommandations en matière de fiabilité
Cette section contient des recommandations pour atteindre la résilience et la disponibilité. Chaque recommandation appartient à l’une des deux catégories suivantes :
Les éléments d’intégrité couvrent des domaines tels que les éléments de configuration et le bon fonctionnement des principaux composants de votre charge de travail Azure, tels que les paramètres de configuration des ressources Azure, les dépendances vis-à-vis d’autres services, etc.
Les éléments de risque couvrent des domaines tels que les exigences de disponibilité et de reprise d’activité, les tests, le monitoring, le déploiement et d’autres éléments qui, s’ils ne sont pas résolus, augmentent les risques de problèmes dans l’environnement.
Matrice de priorité des recommandations de fiabilité
Chaque recommandation est marquée conformément à la matrice de priorité suivante :
| Image | Priority | Description |
|---|---|---|
|
Élevé | Correctif immédiat nécessaire. |
|
Moyenne | Corriger dans les 3 à 6 mois. |
|
Faible | Doit être examiné. |
Résumé des recommandations en matière de fiabilité
Haute disponibilité
Activer la stratégie de réparation automatique
Pour obtenir une haute disponibilité pour les applications, activez les réparations automatiques d’instances afin de conserver un ensemble de machines virtuelles saines. Lorsque l’Extension d’intégrité d’application ou les sondes d’intégrité Load Balancer détectent qu’une instance n’est pas saine, la réparation automatique d’instance supprime l’instance non saine et en crée une pour la remplacer.
Une période de grâce peut être définie à l’aide de la propriété automaticRepairsPolicy.gracePeriod. La période de grâce, spécifiée en minutes et au format ISO 8601, peut être comprise entre 10 et 90 minutes, et a une valeur par défaut de 30 minutes.
// Azure Resource Graph Query
// Find VMSS instances associated with autoscale settings when autoscale is disabled
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| project name, id, tags
| join kind=leftouter (
resources
| where type == "microsoft.insights/autoscalesettings"
| where tostring(properties.targetResourceUri) contains "Microsoft.Compute/virtualMachineScaleSets"
| project id = tostring(properties.targetResourceUri), autoscalesettings = properties
) on id
| where isnull(autoscalesettings) or autoscalesettings.enabled == "false"
| project recommendationId = "vmss-4", name, id, tags, param1 = "autoscalesettings: Disabled"
| order by id asc
Déployer Virtual Machine Scale Sets dans des zones de disponibilité avec Virtual Machine Scale Sets Flex
Au moment de créer vos groupes de machines virtuelles identiques, utilisez des zones de disponibilité pour protéger vos applications et données contre les défaillances peu probables du centre de données. Pour plus d’informations, consultez Prise en charge des zones de disponibilité.
// Azure Resource Graph Query
// Find VMSS instances with one or no Zones selected
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| where array_length(zones) <= 1 or isnull(zones)
| project recommendationId = "vmss-8", name, id, tags, param1 = "AvailabilityZones: Single Zone"
| order by id asc
Évolutivité
Déployer des machines virtuelles en mode d’orchestration flexible
Toutes les machines virtuelles, y compris les machines virtuelles à instance unique, doivent être déployées dans un groupe identique à l’aide du mode d’orchestration flexible pour assurer la pérennité de votre application en termes de mise à l’échelle et de disponibilité. L’orchestration flexible garantit une haute disponibilité (jusqu’à 1000 machines virtuelles) en répartissant les machines virtuelles entre différents domaines d’erreur dans une région ou une zone de disponibilité.
Pour plus d’informations sur l’utilisation appropriée des groupes identiques, consultez Quand utiliser Virtual Machine Scale Sets plutôt que des machines virtuelles ?
// Azure Resource Graph Query
// Find all zonal VMs that are NOT deployed with Flex orchestration mode
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| where properties.orchestrationMode != "Flexible"
| project recommendationId = "vmss-1", name, id, tags, param1 = strcat("orchestrationMode: ", tostring(properties.orchestrationMode))
Configurer la mise à l’échelle automatique de Virtual Machine Scale Sets
La mise à l’échelle automatique est une fonctionnalité intégrée d’Azure Monitor qui accroît les performances et la rentabilité de vos ressources en ajoutant et en supprimant des machines virtuelles de groupe identique en fonction de la demande. En outre, vous pouvez choisir de mettre à l’échelle vos ressources manuellement à un nombre spécifique d’instances ou en fonction de seuils de métriques. Vous pouvez également planifier le nombre d’instances qui sont mises à l’échelle pendant les fenêtres de temps désignées.
Pour découvrir comment activer les mises à niveau automatiques d’images de système d’exploitation, consultez Mises à niveau automatiques d’images de système d’exploitation de groupes de machines virtuelles identiques Azure.
// Azure Resource Graph Query
// Find VMSS instances associated with autoscale settings when predictiveAutoscalePolicy_scaleMode is disabled
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| project name, id, tags
| join kind=leftouter (
resources
| where type == "microsoft.insights/autoscalesettings"
| where tostring(properties.targetResourceUri) contains "Microsoft.Compute/virtualMachineScaleSets"
| project id = tostring(properties.targetResourceUri), autoscalesettings = properties
) on id
| where autoscalesettings.enabled == "true" and autoscalesettings.predictiveAutoscalePolicy.scaleMode == "Disabled"
| project recommendationId = "vmss-5", name, id, tags, param1 = "predictiveAutoscalePolicy_scaleMode: Disabled"
| order by id asc
Définir des stratégies de scale-in personnalisées Virtual Machine Scale Sets par défaut
La fonctionnalité de stratégie de scale-in personnalisée de Virtual Machine Scale Sets vous permet de configurer l’ordre dans lequel les machines virtuelles sont mises à l’échelle. Il existe trois configurations de stratégie de scale-in :
Vous pouvez effectuer un scale-out ou un scale-in du déploiement d’un groupe de machines virtuelles identiques en fonction d’un ensemble de métriques, notamment des métriques personnalisées de plateforme et définies par l’utilisateur. Alors qu’un scale-out crée des machines virtuelles basées sur le modèle de groupe identique, un scale-in affecte les machines virtuelles en cours d’exécution qui peuvent avoir des configurations et/ou des fonctions différentes à mesure que la charge de travail du groupe identique évolue.
Il n’est pas nécessaire de spécifier une stratégie de scale-in si vous souhaitez simplement suivre l’ordre par défaut, car la stratégie de scale-in personnalisée par défaut offre le meilleur algorithme et la meilleure flexibilité pour la plupart des scénarios. L’ordre par défaut est le suivant :
- Équilibrer les machines virtuelles parmi les zones de disponibilité (si le groupe identique est déployé avec prise en charge des zones de disponibilité)
- Équilibrer les machines virtuelles parmi les domaines d’erreur (meilleur effort)
- Supprimer la machine virtuelle ayant l’ID d’instance la plus élevée
Utilisez uniquement les stratégies La plus récente et La plus ancienne lorsque votre charge de travail nécessite la suppression des machines virtuelles les plus anciennes ou les plus récentes après l’équilibrage parmi les zones de disponibilité.
Remarque
L’équilibrage parmi les zones de disponibilité ou les domaines d’erreur ne déplace pas les machines virtuelles entre les zones de disponibilité ou les domaines d’erreur. L’équilibrage est effectué par le biais de la suppression de machines virtuelles des zones de disponibilité ou domaines d’erreur déséquilibrés jusqu’à ce que la distribution des machines virtuelles soit équilibrée.
// Azure Resource Graph Query
// Find VMSS instances where strictly zoneBalance is set to True
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| where properties.orchestrationMode == "Uniform" and properties.zoneBalance == true
| project recommendationId = "vmss-6", name, id, tags, param1 = "strictly zoneBalance: Enabled"
| order by id asc
Récupération d’urgence
Activer la stratégie de protection pour toutes les machines virtuelles de groupe de machines virtuelles identiques
Utilisez la stratégie de protection Virtual Machine Scale Sets si vous souhaitez que des machines virtuelles spécifiques soient traitées différemment du reste de l’instance de groupe identique.
Lorsque votre application traite le trafic, vous pouvez souhaiter que des machines virtuelles spécifiques soient traitées différemment du reste de l’instance de groupe identique. Par exemple, si certaines machines virtuelles du groupe identique effectuent des opérations de longue durée, vous préférerez peut-être attendre qu’elles soient terminées avant de mettre à l’échelle ces machines virtuelles. Il est également possible que des machines virtuelles spécialisées du groupe identique effectuent des tâches spécialisées différentes de celles des autres membres du groupe. Dès lors, vous ne souhaiterez peut-être pas que ces machines virtuelles spéciales soient modifiées en même temps que les autres machines virtuelles du groupe. La protection des instances met à disposition des contrôles supplémentaires pour permettre de tels scénarios pour votre application.
// Azure Resource Graph Query
// Find all VMs that do NOT have health monitoring enabled
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| join kind=leftouter (
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| mv-expand extension=properties.virtualMachineProfile.extensionProfile.extensions
| where extension.properties.type in ( "ApplicationHealthWindows", "ApplicationHealthLinux" )
| project id
) on id
| where id1 == ""
| project recommendationId = "vmss-2", name, id, tags, param1 = "extension: null"
Surveillance
Activer le monitoring de l’intégrité des applications Virtual Machine Scale Sets
La surveillance de l’intégrité de votre application est un signal important pour la gestion et la mise à niveau votre déploiement. Azure Virtual Machine Scale Sets prend en charge les mises à niveau propagées, notamment :
- Mises à niveau automatiques de l’image du système d’exploitation
- Mise à jour corrective automatique des invités de machine virtuelle, qui s’appuie sur le monitoring de l’intégrité des machines virtuelles individuelles pour mettre à niveau votre déploiement.
- Sondes d’intégrité Load BalancerouExtension d’intégrité d’application, qui supervisent l’intégrité des applications de chaque machine virtuelle de votre groupe identique et effectuent des réparations d’instance à l’aide de la fonctionnalité Réparations automatiques des instances.
// Azure Resource Graph Query
// Find all VMs that do NOT have automatic repair policy enabled
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| where properties.automaticRepairsPolicy.enabled == false
| project recommendationId = "vmss-3", name, id, tags, param1 = "automaticRepairsPolicy: Disabled"
Efficacité du système
Configurer l’algorithme de diffusion de la stratégie d’allocation pour la diffusion maximale
Avec « max spreading » (répartition max), le groupe identique répartit vos machines virtuelles sur autant de domaines d’erreur possibles au sein de chaque zone. Cette répartition peut s’effectuer sur plus ou moins de cinq domaines d’erreur par zone. Avec une diffusion fixe statique, le groupe identique répartit vos machines virtuelles dans exactement cinq domaines d’erreur par zone. Si le groupe identique ne parvient pas à trouver cinq domaines d’erreur distincts par zone pour satisfaire la demande d’allocation, la demande échoue.
Pour plus d’informations, consultez Options de diffusion.
// Azure Resource Graph Query
// Find VMSS instances where Spreading algorithm is set to Static
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| where properties.platformFaultDomainCount > 1
| project recommendationId = "vmss-7", name, id, tags, param1 = "platformFaultDomainCount: Static"
| order by id asc
Automatisation
Définir les options d’orchestration de patch sur « Orchestré par Azure »
Activez la mise à jour corrective automatique des invités de machine virtuelle pour vos machines virtuelles Azure. La mise à jour corrective automatique des invités de machine virtuelle facilite la gestion des mises à jour en appliquant une mise à jour corrective automatique et sécurisée aux machines virtuelles afin de maintenir la conformité en matière de sécurité, tout en limitant le rayon d’impact des machines virtuelles.
resources
| where type == "microsoft.compute/virtualmachinescalesets"
| join kind=inner (
resources
| where type == "microsoft.compute/virtualmachines"
| project id = tostring(properties.virtualMachineScaleSet.id), vmproperties = properties
) on id
| extend recommendationId = "vmss-9", param1 = "patchMode: Manual", vmproperties.osProfile.linuxConfiguration.patchSettings.patchMode
| where isnotnull(vmproperties.osProfile.linuxConfiguration) and vmproperties.osProfile.linuxConfiguration.patchSettings.patchMode !in ("AutomaticByPlatform", "AutomaticByOS")
| distinct recommendationId, name, id, param1
| union (resources
| where type == "microsoft.compute/virtualmachinescalesets"
| join kind=inner (
resources
| where type == "microsoft.compute/virtualmachines"
| project id = tostring(properties.virtualMachineScaleSet.id), vmproperties = properties
) on id
| extend recommendationId = "vmss-9", param1 = "patchMode: Manual", vmproperties.osProfile.windowsConfiguration.patchSettings.patchMode
| where isnotnull(vmproperties.osProfile.windowsConfiguration) and vmproperties.osProfile.windowsConfiguration.patchSettings.patchMode !in ("AutomaticByPlatform", "AutomaticByOS")
| distinct recommendationId, name, id, param1)
Prise en charge des zones de disponibilité
Les zones de disponibilité Azure sont au moins trois groupes physiquement distincts de centres de données dans chaque région Azure. Les centres de données de chaque zone sont équipés d’une infrastructure réseau, de refroidissement et d’alimentation indépendante. En cas de défaillance de zone locale, les zones de disponibilité sont conçues de telle sorte que si une zone est affectée, les services, la capacité et la haute disponibilité de la région sont pris en charge par les deux autres zones.
Les défaillances sont aussi bien des défaillances logicielles et matérielles que des événements de type tremblements de terre, inondations et incendies. La tolérance aux défaillances est obtenue par la redondance et l’isolation logique des services Azure. Pour obtenir des informations détaillées sur les zones de disponibilité dans Azure, consultez Régions et zones de disponibilité.
Les services Azure compatibles avec les zones de disponibilité sont conçus pour fournir le niveau approprié de fiabilité et de flexibilité. Ils peuvent être configurés de deux façons. Un service peut être redondant interzone, avec une réplication automatique entre les zones, ou zonal, avec des instances épinglées à une zone spécifique. Vous pouvez également combiner ces approches. Pour plus d’informations sur l’architecture zonale et redondante interzone, consultez Recommandations pour l’utilisation de zones de disponibilité et de régions.
Avec Azure Virtual Machine Scale Sets, vous pouvez créer et gérer un groupe de machines virtuelles à charge équilibrée. Le nombre de machines virtuelles peut augmenter ou diminuer automatiquement en fonction de la demande ou d’un calendrier défini. Les groupes identiques offrent une haute disponibilité à vos applications, et vous permettent de gérer, configurer et mettre à jour de manière centralisée de nombreuses machines virtuelles. Il n’y a aucun coût pour le groupe identique lui-même. Vous payez uniquement pour chaque instance de machine virtuelle que vous créez.
Virtual Machine Scale Sets prend en charge les déploiements zonaux et redondants interzones au sein d’une région :
Déploiement zonal. Lorsque vous créez un groupe identique dans une zone unique, vous contrôlez la zone dans laquelle toutes les machines virtuelles de ce groupe s’exécutent. Le groupe identique est géré et mis à l’échelle automatiquement uniquement dans cette zone.
Déploiement redondant interzone. Un groupe identique redondant interzone permet de créer un groupe identique unique qui couvre plusieurs zones. Par défaut, au fur et à mesure que des machines virtuelles sont créées, elles sont équilibrées uniformément parmi les zones.
Prérequis
Pour utiliser des zones de disponibilité, votre groupe identique doit être créé dans une région Azure prise en charge.
Toutes les machines virtuelles, même les machines virtuelles à instance unique, doivent être déployées dans un groupe identique à l’aide du mode d’orchestration flexible pour assurer la pérennité de votre application en termes de mise à l’échelle et de disponibilité.
SLA
Étant donné que les zones de disponibilité sont physiquement distinctes et fournissent une source d’alimentation, un réseau et un refroidissement distincts, les contrats SLA (contrats de niveau de service) augmentent. Pour plus d’informations, consultez le contrat SLA pour Microsoft Online Services.
Créer un groupe de machines virtuelles identiques avec les zones de disponibilité activées
Vous pouvez créer un groupe identique qui utilise des zones de disponibilité en appliquant l’une des méthodes suivantes :
Le processus de création d’un groupe identique qui utilise un déploiement zonal est le même que celui décrit dans l’article de démarrage rapide. Lorsque vous sélectionnez une région Azure prise en charge, vous pouvez créer un groupe identique dans une zone disponible ou plus, comme indiqué dans l’exemple suivant :
Le groupe identique et les ressources prises en charge, notamment l’équilibreur de charge Azure et l’adresse IP publique, sont créés dans la même zone que vous spécifiez.
Prise en charge du basculement zonal
Des groupes de machines virtuelles identiques sont créés avec cinq domaines d’erreur par défaut dans les régions Azure sans zones. Pour les régions qui prennent en charge le déploiement de zone de disponibilité Virtual Machine Scale Sets et si cette option est sélectionnée, la valeur par défaut du nombre de domaines d’erreur est de 1 pour chacune des zones. FD = 1 implique dans ce cas que les instances de machine virtuelle appartenant au groupe identique sont réparties entre plusieurs racks dans la mesure du possible. Pour plus d’informations, consultez Choisir le bon nombre de domaines d’erreur pour un groupe de machines virtuelles identiques.
Conception à faible latence
Il est recommandé de configurer Virtual Machine Scale Sets avec la redondance de zone. Toutefois, si votre application a des exigences strictes en matière de faible latence, vous devrez peut-être implémenter un déploiement zonal pour vos machines virtuelles de groupes identiques. Avec un déploiement zonal de groupes identiques, il est recommandé de créer plusieurs machines virtuelles de groupe identique parmi plusieurs zones. Par exemple, vous pouvez créer une instance de groupe identique épinglée à la zone 1 et une instance épinglée à la zone 2 ou 3. Vous devez également utiliser un équilibreur de charge ou une autre logique d’application pour diriger le trafic vers les groupes identiques appropriés pendant une panne de zone.
Important
Si vous refusez le déploiement prenant en charge la zone, vous renoncez à la protection contre l’isolation des erreurs sous-jacentes. La non-configuration des zones de disponibilité force la dépendance envers des ressources qui n’obéissent pas au placement et à la séparation des zones (y compris les dépendances sous-jacentes de ces ressources). Ces ressources ne doivent pas survivre à des scénarios de zone descendante. Les solutions qui tirent parti de ces ressources doivent définir une stratégie de récupération d’urgence et configurer une récupération de la solution dans une autre région.
Techniques de déploiement sécurisées
Pour mieux contrôler l’emplacement de déploiement de vos machines virtuelles, vous devez déployer des machines virtuelles zonales plutôt que des machines virtuelles de groupe identique régionales. Toutefois, les machines virtuelles zonales fournissent uniquement l’isolation de zone et non la redondance de zone. Pour obtenir une redondance de zone complète avec des machines virtuelles zonales, il doit y avoir au moins deux machines virtuelles dans différentes zones.
Il est également recommandé d’utiliser l’option de déploiement avec diffusion maximale pour vos machines virtuelles redondantes interzones. Pour plus d’informations, consultez les options de diffusion.
Options de diffusion
Lorsque vous déployez un groupe identique dans une ou plusieurs zones de disponibilité, vous disposez des options de diffusion suivantes (à compter de la version 2017-12-01 de l’API) :
Diffusion maximale (platformFaultDomainCount = 1). La diffusion maximale est l’option de déploiement recommandée, car elle offre la meilleure diffusion dans la plupart des cas. Si vous souhaitez répartir les réplicas sur des unités matérielles d’isolation distinctes, nous vous recommandons de les répartir sur plusieurs zones de disponibilité et d’utiliser la diffusion maximale au sein de chaque zone.
Avec « max spreading » (répartition max), le groupe identique répartit vos machines virtuelles sur autant de domaines d’erreur possibles au sein de chaque zone. Cette répartition peut s’effectuer sur plus ou moins de cinq domaines d’erreur par zone.
Remarque
Avec la diffusion maximale, quel que soit le nombre de domaines d’erreur sur lesquels les machines virtuelles sont réparties, vous ne verrez qu’un seul domaine d’erreur dans la vue d’instance de machine virtuelle de groupe identique ainsi que dans les métadonnées de l’instance. La répartition dans chaque zone est implicite.
Diffusion fixe statique (platformFaultDomainCount = 5). Avec une diffusion fixe statique, le groupe identique répartit vos machines virtuelles dans exactement cinq domaines d’erreur par zone. Si le groupe identique ne parvient pas à trouver cinq domaines d’erreur distincts par zone pour satisfaire la demande d’allocation, la demande échoue.
Diffusion alignée sur les domaines d’erreur des disques managés (platformFaultDomainCount = 2 ou 3) Vous pouvez envisager d’aligner le nombre de domaines d’erreur de groupe identique sur le nombre de domaines d’erreur de disques managés. Cet alignement peut aider à éviter la perte de quorum si tout un domaine d’erreur de disques managés tombe en panne. Le nombre de domaines d’erreur peut être défini sur une valeur inférieure ou égale au nombre de domaines d’erreur de disques managés disponibles dans chacune des régions. Pour en savoir plus sur le nombre de domaines d’erreur Disques managés par région, consultez [insérer la documentation ici](lien ici).
Équilibrage des zones
Pour les groupes identiques déployés sur plusieurs zones (redondants interzones), vous pouvez choisir le meilleur équilibre des zones ou l’équilibre strict des zones. Un groupe identique est considéré comme « équilibré » si chaque zone compte le même nombre de machines virtuelles (plus ou moins une machine virtuelle) que toutes les autres zones du groupe identique. Par exemple :
| Groupe identique | Machines virtuelles dans la zone 1 | Machines virtuelles dans la zone 2 | Machines virtuelles dans la zone 3 | Équilibrage des zones |
|---|---|---|---|---|
| Groupe identique équilibré | 2 | 3 | 3 | Ce groupe identique est considéré comme équilibré. Une seule de ces zones présente un nombre de machines virtuelles différent, et ce nombre n’est inférieur que de 1 à celui des autres zones. |
| Groupe identique déséquilibré | 1 | 3 | 3 | Ce groupe identique est considéré comme déséquilibré. En effet, la zone 1 comporte 2 machines virtuelles de moins que les zones 2 et 3. |
Il est possible que les machines virtuelles du groupe identique soient correctement créées, mais que le déploiement d’extensions sur ces machines virtuelles échoue. Les machines virtuelles avec des erreurs d’extension sont toujours comptabilisées lorsque l’équilibre d’un groupe identique est évalué. Par exemple, un groupe identique composé de trois machines virtuelles dans la zone 1, trois machines virtuelles dans la zone 2 et trois machines virtuelles dans la zone 3 est considéré comme étant équilibré même si toutes les extensions ont échoué dans la zone 1 et toutes les extensions ont réussi dans les zones 2 et 3.
Avec « best effort zone balance » (meilleur équilibre des zones), le groupe identique tente de diminuer et d’augmenter la taille des instances tout en maintenant l’équilibre. Toutefois, si pour une raison quelconque l’équilibrage n’est pas possible (par exemple, si une zone tombe en panne, le groupe identique ne peut pas créer une machine virtuelle dans cette zone), le groupe identique autorise un déséquilibre temporaire pour effectuer un scale-in ou un scale-out. Lors des tentatives de scale-out ultérieures, le groupe identique ajoute des machines virtuelles aux zones qui ont besoin de plus de machines virtuelles pour que le groupe identique soit équilibré. De même, lors des tentatives suivantes de diminution de la taille des instances, le groupe identique retire des machines virtuelles aux zones qui ont besoin de moins de machines virtuelles pour équilibrer le groupe identique. Avec « strict zone balance » (équilibre des zones strict), toute tentative du groupe identique pour diminuer et augmenter la taille des instances échoue si cela crée un déséquilibre.
Pour utiliser un équilibre de zones « au mieux », définissez zoneBalance sur false. Le paramètre zoneBalance est le paramètre par défaut dans la version d’API 2017-12-01. Pour utiliser un équilibre de zones strict, définissez zoneBalance sur true.
Migrer vers une prise en charge des zones de disponibilité
Pour savoir comment redéployer un groupe identique régional avec prise en charge des zones de disponibilité, consultez Migrer des machines virtuelles et Virtual Machine Scale Sets vers la prise en charge des zones de disponibilité.
Conseils supplémentaires
Groupes de placement
Important
Les groupes de placement s’appliquent uniquement aux groupes de machines virtuelles identiques s’exécutant en mode d’orchestration Uniforme.
Lorsque vous déployez un groupe de machines virtuelles identiques, vous avez la possibilité de déployer avec un ou plusieurs groupes de placement par zone de disponibilité. Pour les groupes identiques régionaux, le choix consiste à avoir un groupe de placement unique dans la région, ou plusieurs groupes de placement dans la région. Si la propriété de groupe identique singlePlacementGroup est définie sur false, le groupe identique peut se composer de plusieurs groupes de placement et présente une plage de 0 à 1000 machines virtuelles. Si la propriété a la valeur par défaut true, le groupe identique est composé d’un seul groupe de placement et a une plage de 0 à 100 machines virtuelles. Pour la plupart des charges de travail, nous recommandons d’utiliser plusieurs groupes de placement, qui permettent une plus grande mise à l’échelle. Dans la version d’API 2017-12-01, pour les groupes identiques de zone unique et inter-zones l’option par défaut est plusieurs groupes de placement, mais pour les groupes identiques régionaux l’option par défaut est un seul groupe de placement.