Domaines d’erreur et zones de disponibilité d’Azure Dedicated Host : le guide complet de la haute disponibilité

By Mirko Peters · 2026-10-25

Découvrez comment configurer les domaines d’erreur et les zones de disponibilité d’Azure Dedicated Host pour bâtir des architectures cloud mono-locataire et hautement disponibles pour les entreprises.

Automatically translated with AI from the original post. Read the English original

Les domaines d’erreur et les zones de disponibilité d’Azure Dedicated Host assurent une isolation de l’infrastructure physique pour les charges de travail des entreprises. En répartissant des serveurs mono-locataires sur des baies matérielles distinctes et sur des centres de données distincts, les architectes cloud peuvent concevoir des environnements hautement disponibles, qui atténuent aussi bien les défaillances de composants au niveau des baies que les pannes catastrophiques touchant un site régional, sans renoncer à la conformité réglementaire.

Points clés

• Les zones de disponibilité isolent les groupes d’hôtes dédiés grâce à des infrastructures physiques indépendantes d’alimentation, de refroidissement et de réseau, au sein d’une même région Azure.
• Les domaines d’erreur répartissent les hôtes dédiés sur des baies de serveurs physiques distinctes, afin de se protéger contre les défaillances matérielles localisées.
• Les groupes d’hôtes fonctionnent comme des conteneurs logiques qui imposent des frontières régionales et zonales à votre infrastructure physique dédiée.
• Le placement manuel des machines virtuelles sur des domaines d’erreur distincts garantit que les copies redondantes d’une application ne partagent jamais la même baie de serveurs physiques.
• Associer la redondance au niveau des zones à la séparation par domaines d’erreur offre une disponibilité de niveau entreprise pour les charges de travail critiques les plus exigeantes.

Comprendre l’architecture d’Azure Dedicated Host

Lorsque vous migrez des applications critiques vers Microsoft Azure, atteindre une haute disponibilité demande bien plus que de déployer plusieurs machines virtuelles derrière un équilibreur de charge. Sur une infrastructure cloud partagée, les hyperviseurs répartissent automatiquement les charges de travail des clients dans le centre de données afin d’optimiser l’utilisation des ressources. Cependant, les organisations soumises à des cadres de conformité stricts, ou celles qui exploitent des bases de données d’entreprise sensibles à la latence, ont souvent besoin de savoir avec une précision absolue où se trouve leur puissance de calcul physique.

C’est là qu’intervient l’architecture cloud mono-locataire. Plutôt que de partager une carte mère avec des charges de travail inconnues, un hôte dédié Azure réserve un serveur physique entier à votre abonnement. Mais louer le matériel ne représente que la moitié du défi. Pour empêcher qu’une seule défaillance matérielle ne mette l’ensemble de votre système hors service, vous devez maîtriser le fonctionnement des groupes d’hôtes, des zones de disponibilité et des domaines d’erreur.

Le rôle des groupes d’hôtes

Avant de provisionner le moindre serveur physique dans Azure, vous devez créer un groupe d’hôtes. Considérez-le comme une frontière logique ou un conteneur qui détermine l’emplacement de votre infrastructure dédiée. Lorsque vous configurez un groupe d’hôtes, vous définissez sa région Azure cible et, point essentiel, s’il se trouve ou non dans une zone de disponibilité.

Les groupes d’hôtes simplifient l’administration en regroupant plusieurs serveurs physiques sous une même gestion centralisée. Ils imposent aussi des règles de placement strictes. Un groupe d’hôtes ne peut pas s’étendre sur plusieurs zones de disponibilité : si votre architecture exige une redondance inter-zones, vous devez provisionner un groupe d’hôtes distinct pour chaque zone. Une fois votre groupe d’hôtes actif, vous pouvez y ajouter des hôtes dédiés et commencer à répartir vos machines virtuelles.

Maîtriser les zones de disponibilité pour une résilience régionale

Les zones de disponibilité sont des emplacements physiquement distincts au sein d’une même région Azure. Chaque zone dispose de sa propre source d’alimentation électrique indépendante, de systèmes de refroidissement dédiés et d’une infrastructure réseau robuste. En cas de panne de courant imprévue ou de défaillance d’une infrastructure locale affectant la zone 1, les zones 2 et 3 continuent de fonctionner sans interruption.

Lorsque vous appliquez les zones de disponibilité aux hôtes dédiés, votre stratégie d’architecture doit tenir compte des limites régionales. Un groupe d’hôtes étant rattaché à une zone spécifique, il est impossible de répartir un même groupe d’hôtes sur plusieurs zones. Si vous souhaitez assurer une haute disponibilité pour une base de données d’entreprise s’exécutant sur du matériel dédié, vous devez déployer au moins deux groupes d’hôtes :

• Créez le groupe d’hôtes A dans la zone de disponibilité 1 et affectez-lui des hôtes dédiés.
• Créez le groupe d’hôtes B dans la zone de disponibilité 2 et affectez-lui également des hôtes dédiés.
• Déployez votre machine virtuelle de base de données principale sur l’hôte dédié de la zone 1.
• Déployez votre machine virtuelle de base de données réplica ou secondaire sur l’hôte dédié de la zone 2.

Cette séparation délibérée garantit qu’un incident localisé dans un centre de données ne puisse pas mettre hors service à la fois vos instances d’application principale et secondaire.

Atténuer les risques matériels grâce aux domaines de panne

Si les zones de disponibilité protègent contre les perturbations généralisées d’un centre de données, les domaines de panne traitent les vulnérabilités matérielles localisées au sein même des baies serveur. Dans un centre de données Azure, les serveurs sont organisés en rangées et en baies physiques, connectées à des commutateurs réseau Top-of-Rack et à des unités de distribution d’énergie partagées.

Un domaine de panne désigne un groupe d’hôtes dédiés partageant une même source d’alimentation et un même commutateur réseau. En affectant vos hôtes dédiés à différents domaines de panne lors de la création du groupe d’hôtes, vous garantissez qu’une panne physique affectant une baie ne mettra pas hors service l’ensemble de votre cluster applicatif.

Concevoir la redondance au niveau des baies

Prenons l’exemple d’une application métier interne standard alimentée par deux machines virtuelles identiques traitant le trafic web. Si vous placez les deux machines virtuelles sur un même hôte dédié, toute maintenance matérielle obligatoire ou défaillance imprévue d’un composant de ce serveur physique mettra immédiatement hors ligne les deux machines virtuelles.

Pour éliminer ce point de défaillance unique, vous devez :

1. Configurer votre groupe d’hôtes pour utiliser au moins deux domaines de panne.
2. Déployer l’hôte dédié A et l’affecter au domaine de panne 1.
3. Déployer l’hôte dédié B et l’affecter au domaine de panne 2.
4. Placer votre première machine virtuelle d’application web sur l’hôte A.
5. Placer votre seconde machine virtuelle d’application web sur l’hôte B.

Lorsque Azure planifie une maintenance de plateforme ou qu’un problème matériel localisé au niveau d’une baie affecte le domaine de panne 1, seul l’hôte A est touché. Votre seconde machine virtuelle, exécutée sur l’hôte B dans le domaine de panne 2, reste pleinement opérationnelle et maintient vos services métier accessibles aux utilisateurs finaux.

Conclusion et prochaines étapes

Concevoir une haute disponibilité avec Azure Dedicated Host exige une planification rigoureuse à plusieurs niveaux d’architecture. En exploitant les groupes d’hôtes, en structurant vos déploiements sur plusieurs zones de disponibilité et en séparant les serveurs physiques en domaines de panne distincts, vous obtenez un contrôle total sur votre environnement cloud mono-locataire, tout en conservant une résilience de niveau entreprise.

Pour écouter une analyse complète de l’isolation matérielle, des mécanismes de licences et des pièges tarifaires courants, n’hésitez pas à écouter l’épisode complet du podcast M365 FM pour découvrir d’autres analyses d’experts sur le cloud !

Questions fréquentes

Un seul Azure Dedicated Host peut-il s’étendre sur plusieurs zones de disponibilité ?

Non. Un groupe d’hôtes individuel et ses hôtes dédiés associés doivent résider dans une seule zone de disponibilité. Pour utiliser plusieurs zones, vous devez créer un groupe d’hôtes distinct pour chaque zone.

Quelle est la différence entre une zone de disponibilité et un domaine de panne sur les hôtes dédiés ?

Les zones de disponibilité assurent une séparation physique entre des centres de données distincts, dotés d’alimentations électriques et de systèmes de refroidissement indépendants. Les domaines de panne assurent une séparation entre les baies serveur physiques d’un même centre de données, afin d’atténuer les défaillances matérielles et réseau localisées.

Dois-je configurer des domaines de panne pour mes machines virtuelles sur des hôtes dédiés ?

Non, les machines virtuelles héritent de la séparation au niveau des baies de l’hôte dédié sur lequel elles sont placées. Vous affectez l’hôte dédié à un domaine de panne précis lors de son provisionnement au sein de votre groupe d’hôtes.

Puis-je utiliser le placement automatique des machines virtuelles sur plusieurs domaines de défaillance dans un groupe d'hôtes ?

Oui, Azure peut placer automatiquement des machines virtuelles sur les hôtes disponibles d'un groupe d'hôtes. Toutefois, pour les charges de travail à haute disponibilité stricte, le placement manuel est souvent préférable afin de garantir une redondance précise entre les domaines de défaillance.