Détecter un problème relatif aux défaillances de répartition pendant la création ou le redimensionnement d’ordinateurs virtuels dans Azure
Article
S’applique à : ✔️ Machines virtuelles Linux ✔️ Machines virtuelles Windows
Quand vous créez une machine virtuelle (VM), démarrez des machines virtuelles ayant été arrêtées (libérées) ou redimensionnez une machine virtuelle, Microsoft Azure alloue des ressources de calcul à votre abonnement. Nous investissons constamment dans l’infrastructure et dans l’ajout de fonctionnalités afin de garantir la disponibilité de tous les types de machines virtuelles et de répondre aux besoins des clients. Toutefois, il est possible que vous rencontriez des échecs d’allocation de ressources en raison d’une augmentation sans précédent de la demande pour les services Azure dans certaines régions. Ce problème peut se produire lorsque vous essayez de créer, de démarrer ou de redimensionner des machines virtuelles dans une région, et que celles-ci affichent le code d’erreur et le message suivants :
Code d’erreur : AllocationFailed ou ZonalAllocationFailed
Message d’erreur : « L’allocation a échoué. We do not have sufficient capacity for the requested VM size in this region. Read more about improving likelihood of allocation success at https://aka.ms/allocation-guidance" »
Recommandation alternative : lorsque vous recevez une autre recommandation, cela signifie que la taille de machine virtuelle que vous avez demandée n’est pas actuellement disponible dans la région ou la zone sélectionnée. Pour augmenter vos chances d’allouer correctement une machine virtuelle, vous pouvez sélectionner l’une des options alternatives. Appliquez simplement les modifications à votre sélection d’entrée de machine virtuelle ou redimensionnez la machine virtuelle existante dans l’option souhaitée et essayez de démarrer ou de recréer la machine virtuelle.
Par exemple, essayez l’une de ces options alternatives pour augmenter les chances de succès de l’allocation :
Tailles de machine virtuelle alternatives pour la même zone et la même région : Standard_A2_v2, Standard_A2m_v2, or Standard_D2a_v4
Autres zones pour la même taille et la même région de machine virtuelle : zone 1 et 3
Notes
Si vous résolvez des problèmes de groupe de machines virtuelles identiques (VMSS), le processus est le même que pour une machine virtuelle standard. Pour résoudre le problème, suivez les instructions de cet article.
Message d’erreur : « L’allocation a échoué. Si vous essayez d’ajouter une nouvelle machine virtuelle à un groupe de machines virtuelles identiques avec un seul groupe de placements ou de mettre à jour/redimensionner une machine virtuelle existante dans un groupe de machines virtuelles identiques avec un seul groupe de placements, sachez qu’une telle allocation est limitée à un seul cluster dont la capacité peut être insuffisante. Consultez http://aka.ms/allocation-guidance." pour en savoir plus sur la façon d’augmenter les chances de succès de l’allocation ;
Cet article explique les causes de certains échecs d’allocation courants et propose des solutions possibles.
En attendant que votre type de machine virtuelle préféré soit disponible dans votre région par défaut, nous conseillons aux clients qui rencontrent des problèmes de déploiement de suivre les instructions du tableau suivant en guise de solution de contournement temporaire.
Identifiez le scénario qui correspond le mieux à votre cas, puis renvoyez votre demande d’allocation à l’aide de la solution de contournement suggérée pour accroître les chances de réussite de l’allocation. Vous pouvez également réessayer à un autre moment. Cela signifie que suffisamment de ressources ont été libérées dans le cluster, la région ou la zone pour répondre à votre demande.
Envisagez d’utiliser des réservations de capacité à la demande pour faire en sorte que la capacité soit toujours disponible pour vos charges de travail. Cette option vous permet de réserver la capacité de calcul à l’avance, ce qui garantit que vos machines virtuelles peuvent être déployées en fonction des besoins sans échecs d’allocation. Cette approche peut améliorer la fiabilité et la prévisibilité de vos déploiements.
Machine virtuelle autonome
Cause
Si vous disposez d’une machine virtuelle autonome dans Azure, ce qui signifie qu’elle ne fait pas partie d’un groupe de placement de disponibilité ou de proximité avec d’autres machines virtuelles et que vous rencontrez des échecs d’allocation lors de la tentative d’une opération Create, Start ou Redeploy, cela indique qu’Azure ne dispose pas actuellement d’une capacité suffisante pour répondre à votre demande dans la région ou la zone spécifiée.
Solutions de contournement
Pour contourner ce problème, appliquez l’une des méthodes suivantes :
Réessayez l’allocation
Parfois, le problème peut être temporaire et une nouvelle tentative d’allocation après une courte période peut résoudre le problème.
Redimensionner la machine virtuelle
Envisagez de modifier la taille de la machine virtuelle pour accroître les chances de disponibilité dans la région ou la zone.
Modifier la région ou la zone
Si la région ou la zone actuelle rencontre une forte demande, essayez de déployer la machine virtuelle dans une autre région ou zone de disponibilité où il peut y avoir plus de capacité.
Redimensionnez une machine virtuelle, ajoutez des machines virtuelles ou démarrez des machines virtuelles partiellement arrêtées (libérées) dans un groupe à haute disponibilité existant
Notes
Une machine virtuelle ne peut être ajoutée à un groupe à haute disponibilité que lors de sa création. Pour ajouter une machine virtuelle existante à un groupe à haute disponibilité ou modifier le groupe à haute disponibilité d’une machine virtuelle, la machine virtuelle doit être supprimée et recréée. Pour en savoir plus, consultez Modification du groupe à haute disponibilité d’une machine virtuelle en utilisant Azure PowerShell.
Cause
Une demande pour redimensionner une machine virtuelle ou ajouter une machine virtuelle à un groupe à haute disponibilité existant doit être effectuée sur le cluster d’origine qui héberge le groupe à haute disponibilité existant. Le cluster peut ne pas prendre en charge la taille de machine virtuelle demandée ou ne pas disposer de la capacité suffisante pour le moment.
Une désallocation partielle signifie que vous avez arrêté (désalloué) une ou plusieurs machines virtuelles, mais pas toutes, dans un groupe à haute disponibilité. Quand vous libérez une machine virtuelle, les ressources associées sont elles aussi libérées. Démarrer des machines virtuelles dans un groupe à haute disponibilité partiellement libéré équivaut à ajouter des machines virtuelles à un groupe à haute disponibilité existant. Par conséquent, la demande d’allocation doit être tentée sur le cluster d’origine qui héberge le groupe à haute disponibilité existant, lequel peut ne pas disposer d’une capacité suffisante.
Solutions de contournement
Pour contourner ce problème, appliquez l’une des méthodes suivantes :
Lors du déploiement d'une nouvelle machine virtuelle, si celle-ci peut faire partie d’un autre groupe à haute disponibilité, créez-la dans un autre groupe à haute disponibilité (dans la même région ou zone). Cette nouvelle machine virtuelle peut ensuite être ajoutée au même réseau virtuel.
Envisagez de redimensionner la machine virtuelle dans une autre taille susceptible de bénéficier d’une plus grande disponibilité dans la région ou la zone. Pour vous assurer que les tailles de machine virtuelle sont prises en charge dans votre groupe à haute disponibilité, utilisez des groupes à haute disponibilité, listez les tailles disponibles et utilisez des API REST.
Arrêtez (libérez) toutes les machines virtuelles du même groupe à haute disponibilité, puis démarrez toutes les machines virtuelles applicables dans un lot pour autoriser l’allocation à partir de tous les clusters disponibles, plutôt que simplement le cluster où le groupe à haute disponibilité est actuellement alloué.
Pour arrêter toutes les machines virtuelles du groupe à haute disponibilité, procédez comme suit :
Dans le portail Azure, accédez à Machines virtuelles.
Sélectionnez Ajouter un filtre et ajoutez un filtre pour le groupe à haute disponibilité que vous souhaitez gérer.
Cochez la case en regard de toutes les machines virtuelles présentes dans le groupe à haute disponibilité.
Sélectionnez Arrêter, puis attendez que l’opération se termine et que toutes les machines virtuelles affichent l’état Arrêté (libéré).
Sélectionnez Démarrer pour allouer à nouveau toutes les machines virtuelles.
Démarrer des machines virtuelles entièrement arrêtées (libérées) dans un groupe à haute disponibilité
Cause
Une désallocation complète signifie que vous avez arrêté (désalloué) toutes les machines virtuelles d’un groupe à haute disponibilité. La demande d’allocation pour démarrer ces machines virtuelles cible tous les clusters qui prennent en charge les tailles souhaitées dans la région ou la zone.
Solutions de contournement
Pour contourner ce problème, appliquez l’une des méthodes suivantes :
Réessayez l’allocation
Parfois, le problème peut être temporaire et une nouvelle tentative d’allocation après une courte période peut résoudre le problème.
Redimensionner les machines virtuelles
Envisagez de redimensionner la machine virtuelle dans une autre taille susceptible de bénéficier d’une plus grande disponibilité dans la région ou la zone. Pour vous assurer que les tailles de machine virtuelle sont prises en charge dans votre groupe à haute disponibilité, utilisez des groupes à haute disponibilité, listez les tailles disponibles et utilisez des API REST.
Modifier la région ou la zone
Si la région ou la zone actuelle rencontre une forte demande, essayez de déployer ou de migrer les machines virtuelles vers une autre région ou zone de disponibilité où il peut y avoir plus de capacité.
Échecs d’allocation pour les machines virtuelles dans les zones de disponibilité
Cause
Les zones de disponibilité Azure sont des centres de données physiquement et logiquement séparés au sein d’une région Azure. Chaque zone de disponibilité est indépendante des autres, avec sa propre alimentation, son propre système de refroidissement et sa propre infrastructure réseau. Ils sont conçus pour garantir la haute disponibilité et la résilience en isolant les défaillances dans une seule zone, réduisant ainsi l’impact sur d’autres zones au sein de la même région.
Toutefois, en raison des conditions de contrainte de déploiement supplémentaires associées aux zones de disponibilité, des échecs d’allocation peuvent se produire.
Solutions de contournement
Pour contourner ce problème, appliquez l’une des méthodes suivantes :
Réessayez l’allocation
Parfois, une nouvelle tentative de la demande d’allocation peut s’avérer fructueuse, car des ressources peuvent avoir été libérées dans la zone.
Redimensionner la machine virtuelle
Envisagez de redimensionner la machine virtuelle dans une autre taille susceptible de bénéficier d’une plus grande disponibilité dans la région ou la zone.
Modifier la région ou la zone
Si la région ou la zone actuelle rencontre une forte demande, essayez de déployer ou de migrer les machines virtuelles vers une autre région ou zone de disponibilité où il peut y avoir plus de capacité. La région ou la zone peut être modifiée à l’aide des méthodes suivantes :
Créez une machine virtuelle à l’aide d’une copie du disque du système d’exploitation, dans une autre zone ou sans la contrainte zonale. La suppression de la contrainte zonale étend les options d’allocation à l’ensemble de la région, plutôt que de les limiter à une seule zone.
Si vous souhaitez en savoir plus, consultez les articles suivants :
Échecs d’allocation dus à un nombre de contraintes trop élevé
Cause
Lorsque la plateforme Azure Compute ne peut pas allouer de machine virtuelle pour répondre aux contraintes requises spécifiées dans la requête, des échecs d’allocation « overconstrained » se produisent. Ces défaillances se produisent généralement lorsque des exigences spécifiques ne peuvent pas être remplies dans les ressources disponibles. Elles sont souvent indiquées par des erreurs telles que OverconstrainedZonalAllocationRequest ou OverconstrainedAllocationRequest.
Ces contraintes incluent généralement (mais pas toujours) les éléments suivants :
Taille de machine virtuelle/référence SKU
Mise en réseau accélérée
Zone de disponibilité
Disque éphémère
Groupe de placement de proximité (PPG)
Disque Ultra ou PremiumSSDv2
Solutions de contournement
Pour contourner ce problème, appliquez l’une des méthodes suivantes :
Réessayez l’allocation
Parfois, une nouvelle tentative de la demande d’allocation peut s’avérer fructueuse, car des ressources peuvent avoir été libérées dans la zone.
Redimensionner la machine virtuelle
Envisagez de redimensionner la machine virtuelle dans une autre taille susceptible de bénéficier d’une plus grande disponibilité dans la région ou la zone.
Modifier la région ou la zone
Si la région ou la zone actuelle rencontre une forte demande, essayez de déployer ou de migrer les machines virtuelles vers une autre région ou zone de disponibilité où il peut y avoir plus de capacité. La région ou la zone peut être modifiée à l’aide des méthodes suivantes :
Créez une machine virtuelle à l’aide d’une copie du disque du système d’exploitation, dans une autre zone ou sans la contrainte zonale. La suppression de la contrainte zonale étend les options d’allocation à l’ensemble de la région, plutôt que de les limiter à une seule zone.
Si vous souhaitez en savoir plus, consultez les articles suivants :
Ajustez les contraintes qui peuvent limiter l’allocation : il peut y avoir suffisamment de disponibilité pour la référence SKU de la machine virtuelle dans la zone. Toutefois, les contraintes définies peuvent empêcher l’allocation. Pour augmenter la probabilité de réussite de l’allocation, envisagez d’ajuster les contraintes comme suit :
Désactivez les performances réseau accélérées.
Supprimez la machine virtuelle de tout groupe de placement de proximité.
Supprimez les disques UltraSSD ou PemiumSSDv2.
Échecs d’allocation pour les machines virtuelles à l’aide de groupes de placement de proximité
Les groupes de placement de proximité garantissent que les ressources se trouvent dans le même centre de données pour réduire la latence. Toutefois, la contrainte de déploiement ajoutée peut parfois entraîner des échecs d’allocation. Pour plus d’informations et suivre les bonnes pratiques, consultez Groupes de placement de proximité.
Cause
Lorsque vous demandez à démarrer ou à allouer la première machine virtuelle dans un groupe de placement de proximité, le centre de données est automatiquement sélectionné. Si la taille de machine virtuelle requise n’est pas disponible dans ce centre de données, la demande échoue. Dans les scénarios avec des charges de travail élastiques où des instances de machine virtuelle sont ajoutées ou supprimées dynamiquement, l’application d’une contrainte de groupe de placement de proximité peut entraîner un échec d’allocation et la la demande d’allocation n'aboutit pas.
Solution de contournement
Libérez toutes les machines virtuelles du groupe de placement de proximité et essayez de modifier l’ordre dans lequel vous démarrez vos machines virtuelles. Le démarrage de vos machines virtuelles avec la référence SKU la plus restrictive peut d’abord augmenter les chances d’allocations réussies.
Échecs d’allocation pour les anciennes tailles de machine virtuelle (Av1, Dv1, DSv1, D15v2, DS15v2, etc.)
À mesure que nous étendons l’infrastructure Azure, nous déployons du matériel de nouvelle génération conçu pour prendre en charge les types de machines virtuelles les plus récents. Certaines anciennes machines virtuelles ne peuvent pas être exécutées dans notre infrastructure de dernière génération. Les clients peuvent donc rencontrer des échecs d’allocation avec ces références SKU héritées. Pour éviter de rencontrer ce problème, nous encourageons les clients qui utilisent des machines virtuelles de séries anciennes à envisager de passer aux machines virtuelles équivalentes plus récentes, conformément aux recommandations suivantes. Ces machines virtuelles sont optimisées pour le matériel récent. Elles vous permettent ainsi de profiter d’une tarification et de performances améliorées.
Envisagez de passer à D16v3/DS16v3 ou D32v3/DS32v3. Celles-ci sont conçues pour s’exécuter sur le matériel de dernière génération. Pour vous assurer d’isoler votre instance de machine virtuelle du matériel dédié à un seul client, envisagez de passer aux nouvelles tailles de machine virtuelle telles que E64i_v3 ou E64is_v3, qui sont conçues pour s’exécuter sur le matériel de dernière génération.
Échecs d’allocation pour les déploiements de grande échelle (plus de 500 cœurs)
Réduisez le nombre d’instances de la taille de machine virtuelle demandée, puis recommencez le déploiement. Éventuellement, pour les déploiements à grande échelle, évaluez aussi les groupes de machines virtuelles identiques Azure avec plusieurs groupes de placement. Le nombre d’instances de machines virtuelles peut augmenter ou diminuer automatiquement en réponse à la demande ou à une planification définie. L’allocation a donc plus de chances de réussir, puisque les déploiements sous forme de groupe multi-placements peuvent être répartis sur plusieurs clusters. En savoir plus sur l’utilisation des groupes de machines virtuelles identiques volumineux et sur la façon de convertir un groupe identique existant pour couvrir plusieurs groupes de placement. Notez que vous pouvez modifier un groupe identique afin qu’il prenne en charge plusieurs groupes de placement au lieu d’un seul. Vous ne pouvez cependant pas effectuer de conversion dans le sens inverse.
Informations contextuelles
Fonctionnement de l’allocation
Les serveurs des centres de données Azure sont partitionnés en clusters. En règle générale, les tentatives de demande d’allocation sont exécutées dans plusieurs clusters, mais il est possible que certaines contraintes (la taille de la machine virtuelle, les disques Ultra SSD et les groupes de placement de proximité, par exemple) de la demande d’allocation forcent la plateforme Azure à exécuter la tentative dans un seul cluster. Le diagramme 1 ci-dessous illustre le cas d’une allocation classique dans laquelle la tentative est exécutée dans plusieurs clusters.
Raisons des échecs d’une allocation
Lorsqu’une demande d’allocation comporte un grand nombre de contraintes, il y a plus de risque de ne pas trouver de ressources libres puisque le pool de ressources disponibles est réduit. En outre, si votre demande d’allocation est restreinte (par exemple, lorsque vous utilisez des groupes de placement de proximité, mais que le type de ressource que vous avez demandé n’est pas pris en charge par l’ensemble de clusters et les clusters proches), votre requête échoue même si le cluster dispose de ressources libres. Le diagramme 2 suivant illustre le cas où une allocation échoue, car les clusters candidats associés au groupe de placement de proximité n’ont pas de ressources libres. Le diagramme 3 illustre le cas où une allocation échoue, car les clusters candidats associés au groupe de placement de proximité ne prennent pas en charge la taille de machine virtuelle demandée, même si les clusters disposent de ressources libres.
Azure HPC est une fonctionnalité cloud conçue spécialement pour les charges de travail HPC et IA, qui utilise des processeurs de pointe et une interconnexion InfiniBand de classe HPC pour offrir les meilleures performances, scalabilité et valeur aux applications. Azure HPC permet aux utilisateurs de laisser libre cours à l’innovation, la productivité et l’agilité métier grâce à une gamme de technologies HPC et IA hautement disponibles qui peuvent être allouées dynamiquement à mesure que vos besoins technico
Résoudre les problèmes d’un message d’erreur AllocationFailed ou ZonalAllocationFailed lorsque vous créez, redémarrez ou redimensionnez des groupes de machines virtuelles identiques dans Azure.
Découvrez le provisionnement et les différents états d’alimentation possibles d’une machine virtuelle. Le provisionnement et les états d’alimentation ont une incidence sur la facturation.
Explique comment résoudre les erreurs de référence SKU non disponible quand vous déployez des ressources avec un modèle Azure Resource Manager (modèle ARM) ou un fichier Bicep.
Résolvez l’erreur ZonalAllocationFailed, AllocationFailed ou OverconstrainedAllocationRequest lorsque vous créez, déployez ou mettez à jour un cluster Kubernetes.
