Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les zones de disponibilité Azure sont des emplacements isolés vis-à-vis des pannes au sein d’une région Azure, qui fournissent une alimentation, un refroidissement et une mise en réseau redondants. Elles vous permettent d’exécuter des applications avec une haute disponibilité et une tolérance aux pannes en cas de défaillances de centre de données. Les régions Azure qui prennent en charge les zones de disponibilité disposent d’un minimum de trois zones distinctes. Chaque zone de disponibilité se compose d’un ou plusieurs centres de données équipés d’une infrastructure indépendante (alimentation, réseau et refroidissement). Les zones de disponibilité sont reliées par un réseau hautes performances avec une latence aller-retour inférieure à 2 millisecondes. Pour plus d'informations, consultez Vue d’ensemble des zones de disponibilité.
Pour protéger vos groupes de machines virtuelles identiques contre les défaillances au niveau du centre de données, vous pouvez créer un groupe identique dans les zones de disponibilité. Pour utiliser les zones de disponibilité, votre groupe identique doit être créé dans une région Azure prise en charge.
Considérations de conception pour les zones de disponibilité
Virtual Machine Scale Sets prend en charge trois modèles de déploiement zonal :
- Redondant interzone ou s’étendant sur plusieurs zones (recommandé)
- Zonal ou aligné sur une zone (zone unique)
- Zones géographiques
Redondant interzone ou s’étendant sur plusieurs zones
Un scale set redondant interzone ou s’étendant sur plusieurs zones répartit les instances sur l’ensemble des zones sélectionnées, "zones": ["1","2","3"]. Par défaut, le scale set applique une approche best effort pour répartir uniformément les instances entre les zones sélectionnées. Cependant, vous pouvez spécifier que vous souhaitez un équilibrage strict des zones en définissant "zoneBalance": "true" dans votre déploiement. Chaque machine virtuelle et ses disques sont zonaux, ils sont donc épinglés à une zone spécifique. Les instances entre les zones sont connectées par un réseau hautes performances avec une faible latence. En cas de panne zonale ou de problème de connectivité, la connectivité aux instances au sein de la zone concernée peut être compromise, tandis que les instances dans les autres zones de disponibilité ne devraient pas être affectées. Vous pouvez ajouter de la capacité au scale set pendant une panne zonale, et le scale set ajoute davantage d’instances dans les zones non affectées. Lorsque la zone est rétablie, vous devrez peut-être réduire votre scale set à sa capacité d’origine. Une bonne pratique consiste à configurer des règles d’autoscale en fonction de l’utilisation du processeur ou de la mémoire. Les règles de mise à l’échelle automatique permettraient au groupe identique de réagir en cas de perte d’instances de machine virtuelle dans cette zone en augmentant la taille des instances dans les zones opérationnelles restantes.
Répartir les instances entre les zones de disponibilité permet de respecter le SLA de 99,99 % pour les instances réparties entre les zones de disponibilité, et est recommandé pour la plupart des charges de travail dans Azure.
Zonal ou aligné sur une zone (zone unique)
Un scale set zonal ou aligné sur une zone place les instances dans une seule zone de disponibilité "zones": ['1']. Chaque machine virtuelle et ses disques sont zonaux, ils sont donc épinglés à une zone spécifique. Cette configuration est principalement utilisée lorsque vous avez besoin d’une latence plus faible entre les instances.
Zones géographiques
Un Virtual Machine Scale Set régional correspond à une configuration où l’affectation de zone n’est pas explicitement définie ("zones"=[] ou "zones"=null). Dans cette configuration, le scale set crée des instances régionales (non épinglées à une zone) et place implicitement des instances dans l’ensemble de la région. Il n’y a aucune garantie d’équilibrage ni de répartition entre les zones, ni que les instances se retrouvent dans la même zone de disponibilité. La colocalisation des disques est garantie pour les disques Ultra et Premium v2, best effort pour les disques Premium v1, et non garantie pour les disques Standard SKU (SSD ou HDD).
Dans le cas rare d’une panne zonale totale, une partie ou la totalité des instances au sein du scale set peut être affectée.
Domaines d’erreur et zones de disponibilité
Un domaine d’erreur est un groupe d’isolation des pannes au sein d’une zone de disponibilité ou d’un centre de données, composé de nœuds matériels partageant la même alimentation, la même mise en réseau, le même refroidissement et le même calendrier de maintenance de la plateforme. Les instances de machine virtuelle qui se trouvent sur des domaines d’erreur différents ne sont pas susceptibles d’être affectées par la même panne planifiée ou non planifiée. Vous pouvez spécifier la façon dont les instances sont réparties entre les domaines d’erreur au sein d’une région ou d’une zone.
- Diffusion maximale (platformFaultDomainCount = 1)
- Répartition fixe (platformFaultDomainCount = 5)
- Répartition fixe alignée sur les domaines d’erreur des disques de stockage (platformFaultDomainCount = 2 ou 3, pour les déploiements régionaux uniquement)
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 répartition fixe statique, le scale set répartit vos VM sur le nombre spécifié de domaines d’erreur. Si le scale set ne peut pas allouer au moins le nombre de domaines d’erreur spécifié pour satisfaire la demande d’allocation, la demande échoue.
Nous vous recommandons de déployer avec « max spreading » (répartition max.) pour la plupart des charges de travail, car cette approche fournit la meilleure répartition dans la plupart des cas. Si vous avez besoin que les réplica soient répartis sur des unités matérielles d’isolation distinctes, nous vous recommandons de les répartir sur plusieurs zones de disponibilité et d’utiliser « max spreading » (répartition max.) au sein de chaque zone.
Remarque
Avec « max spreading » (répartition max.), un seul domaine d’erreur s’affiche dans la vue d’instance de machine virtuelle ainsi que dans les métadonnées de l’instance, quel que soit le nombre de domaines d’erreur sur lesquels les machines virtuelles sont réparties. La répartition dans chaque zone est implicite.
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 identique, vous pouvez également déployer avec un seul groupe de placement par zone de disponibilité, ou plusieurs groupes par zone. Pour les groupes identiques régionaux (non-zonaux), le choix consiste à avoir un groupe de placement unique dans la région ou plusieurs groupes dans la région. Si la propriété de groupe identique appelée singlePlacementGroup est définie sur false, le groupe identique peut se composer de plusieurs groupes de placement et présente une plage de 0 à 1 000 machines virtuelles. Lorsque la valeur par défaut est définie sur true, le groupe identique est composé d’un seul groupe de placement et présente 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 (non-zonaux) l’option par défaut est un seul groupe de placement.
Remarque
Si vous utilisez « max spreading » (répartition max), vous devez utiliser plusieurs groupes de placement.
Équilibrage des zones
Pour les groupes identiques déployés sur plusieurs zones, vous avez également la possibilité de choisir « meilleur équilibre de zone d’effort » ou « équilibre de zone strict ». Pour plus d’informations, consultez l’équilibrage de zone dans les groupes identiques.
Créer des scale sets s’étendant sur plusieurs zones ou zonaux
Quand vous déployez un groupe de machines virtuelles identiques, vous pouvez utiliser une seule zone de disponibilité dans une région, ou bien plusieurs zones.
Vous pouvez créer un groupe identique qui utilise des zones de disponibilité avec l’une des méthodes suivantes :
Utilisation du portail Azure
Le processus de création d’un groupe identique qui utilise une zone de disponibilité est identique à celui décrit dans l’article de prise en main. 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.
Utilisation de l’interface de ligne de commande Microsoft Azure
Le processus de création d’un groupe identique qui utilise une zone de disponibilité est identique à celui décrit dans l’article de prise en main. Pour utiliser les zones de disponibilité, vous devez créer votre groupe identique dans une région Azure prise en charge.
Ajoutez le paramètre --zones à la commande az vmss create, puis spécifiez la zone à utiliser (par exemple, zone 1, 2 ou 3).
az vmss create \
--resource-group myResourceGroup \
--name myScaleSet \
--image <SKU Image> \
--upgrade-policy-mode automatic \
--admin-username azureuser \
--generate-ssh-keys \
--zones 1 2 3
Quelques minutes sont nécessaires pour créer et configurer l’ensemble des ressources et machines virtuelles du groupe identique dans les zones que vous spécifiez. Pour obtenir un exemple complet de groupe identique redondant interzone et de ressources réseau, consultez cet exemple de script CLI.
Utilisation d'Azure PowerShell
Pour utiliser les zones de disponibilité, vous devez créer votre groupe identique dans une région Azure prise en charge. Ajoutez le paramètre -Zone au commandlet New-AzVmssConfig et spécifiez la ou les zones à utiliser (par exemple la zone 1, 2, ou 3).
New-AzVmss `
-ResourceGroupName "myResourceGroup" `
-Location "EastUS2" `
-VMScaleSetName "myScaleSet" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer" `
-UpgradePolicy "Automatic" `
-Zone "1", "2", "3"
Utiliser les modèles Azure Resource Manager
Le processus de création d’un groupe identique qui utilise une zone de disponibilité est identique à celui décrit dans l’article de prise en main pour Linux ou Windows.
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "myScaleSet",
"location": "East US 2",
"apiVersion": "2017-12-01",
"zones": [
"1",
"2",
"3"
]
}
Si vous créez une adresse IP publique ou un équilibreur de charge, spécifiez la propriété "sku": {"name":"Standard"} pour créer des ressources réseau redondantes interzone. Vous devez également créer un groupe de sécurité réseau et les règles associées pour autoriser tout le trafic. Pour plus d’informations, voir Présentation d’Azure Load Balancer Standard et Standard Load Balancer et zones de disponibilité.
Mettre à jour un groupe identique pour ajouter des zones de disponibilité
Vous pouvez modifier une échelle pour développer l’ensemble des zones sur lesquelles répartir des instances de machine virtuelle. L’extension vous permet de tirer parti d’un SLA de disponibilité zonale plus élevé (99,99 %) par rapport au SLA de disponibilité régional (99,95 %). Ou étendez votre scale set pour tirer parti de nouvelles zones de disponibilité qui n’étaient pas disponibles lorsque le scale set a été créé.
Cette fonctionnalité peut être utilisée avec la version d’API 2023-03-01 ou une version ultérieure.
Étendre un scale set pour utiliser les zones de disponibilité
Vous pouvez mettre à jour le scale set afin d’augmenter le nombre d’instances dans une ou plusieurs zones de disponibilité supplémentaires, jusqu’au nombre de zones de disponibilité prises en charge par la région. Pour les régions qui prennent en charge les zones, le nombre minimal de zones est de 3.
Important
Lorsque vous étendez le groupe identique vers des zones supplémentaires, les instances d’origine ne sont ni migrées ni modifiées. Lorsque vous effectuez un scale-out, de nouvelles instances sont créées et réparties uniformément entre les zones de disponibilité sélectionnées. Les données des instances d’origine ne sont pas migrées vers les nouvelles zones. Lorsque vous réduisez le scale set, les instances régionales seront priorisées pour la suppression en premier. Après cela, les instances seront supprimées en fonction de la stratégie de scale-in.
L’extension vers un scale set zonal se fait en 3 étapes :
- Préparer l’extension zonale
- Mettre à jour le paramètre zones sur le scale set
- Ajouter de nouvelles instances zonales et supprimer les instances d’origine
Préparer l’extension zonale
Avertissement
Cette fonctionnalité vous permet d’ajouter des zones au scale set. Vous ne pouvez pas revenir à un scale set régional ni supprimer des zones une fois qu’elles ont été ajoutées.
Afin de préparer l’extension zonale :
- Vérifiez que vous disposez d’un quota suffisant pour la taille de VM dans la région sélectionnée afin de gérer davantage d’instances.
- Vérifiez que la taille de VM et les types de disques que vous utilisez sont disponibles dans toutes les zones souhaitées. Vous pouvez utiliser l’API Compute Resources SKUs pour déterminer quelles tailles sont disponibles dans quelles zones
- Validez que la configuration du scale set est valide pour les scale sets zonaux :
-
platformFaultDomainCountdoit être défini sur 1 ou 5. La répartition fixe avec 2 ou 3 domaines d’erreur n’est pas prise en charge pour les déploiements zonaux. - Les réservations de capacité ne sont pas prises en charge pendant l’extension de zone. Une fois que le scale set est entièrement zonal (il n’y a plus d’instances régionales), vous pouvez ajouter un groupe de réservation de capacité au scale set.
- Les déploiements Azure Dedicated Host ne sont pas pris en charge.
-
Mettre à jour le paramètre zones sur le scale set
Mettez à jour le scale set pour modifier le paramètre zones.
- Accédez au scale set que vous souhaitez mettre à jour
- Dans l’onglet Disponibilité de la page d’accueil du scale set, recherchez la propriété Zone de disponibilité et sélectionnez Modifier
- Dans la boîte de dialogue Modifier l’emplacement, sélectionnez la ou les zones souhaitées
- Sélectionnez Appliquer
Ajouter de nouvelles instances zonales et supprimer les instances d’origine
Vous pouvez équilibrer manuellement votre scale set entre les zones en déclenchant une opération de scale-out, puis en effectuant une réduction. Pour plus de détails, veuillez consulter la section Comment équilibrer manuellement votre scale set.
Problèmes connus et limitations
Les instances d’origine ne sont pas migrées vers les zones nouvellement ajoutées. Votre charge de travail doit gérer toute migration ou réplication des données requise.
Les scale sets exécutant Service Fabric RP ou Azure Kubernetes Service ne sont pas pris en charge.
Vous ne pouvez pas supprimer ni remplacer des zones, seulement en ajouter.
Vous ne pouvez pas passer d’un scale set s’étendant sur plusieurs zones ou zonal à un scale set régional.
platformFaultDomainCountdoit être défini sur 1 ou 5. La répartition fixe avec 2 ou 3 domaines d’erreur n’est pas prise en charge pour les déploiements zonaux.Les réservations de capacité ne sont pas prises en charge pendant l’extension de zone. Une fois que le scale set est entièrement zonal (il n’y a plus d’instances régionales), vous pouvez ajouter un groupe de réservation de capacité au scale set.
Les déploiements Azure Dedicated Host ne sont pas pris en charge
Étapes suivantes
Maintenant que vous avez créé un groupe identique dans une zone de disponibilité, vous pouvez apprendre à déployer des applications sur des groupes identiques de machines virtuelles ou à utiliser la mise à l’échelle automatique avec des groupes identiques de machines virtuelles.