Comment limiter le risque d'indisponibilité d'une VM ?

Bonjour Christophe Smagghe,

Merci pour votre message et pour le partage des détails concernant les redéploiements fréquents de la machine virtuelle dus à des défaillances de l’hôte.

1. Compréhension du comportement actuel

L’événement « Redéploiement en raison d’une défaillance de l’hôte (Non planifiée) » indique que l’hôte physique sous-jacent Azure a rencontré un problème, et qu’Azure a automatiquement déplacé votre machine virtuelle vers un hôte sain.

Cela fait partie du mécanisme d’auto-réparation de la plateforme Azure visant à maintenir la disponibilité du service. Cependant, pendant ce processus, la machine virtuelle peut subir une interruption (généralement de quelques minutes à des durées plus longues selon le temps de détection et de récupération).

2. Peut-on éviter cela en changeant le type de VM ?

Changer la taille/le type de la VM ne garantit pas un placement sur un matériel plus résilient et n’élimine pas la possibilité de défaillances d’hôte.

Azure gère automatiquement le placement de l’infrastructure, et toutes les tailles de VM suivent les mêmes principes de fiabilité sous-jacents.

Par conséquent, changer uniquement la taille de la VM ne permettra pas de résoudre le problème.

3. Approches recommandées pour réduire l’impact (Bonnes pratiques)

Afin de minimiser l’impact de ces défaillances d’hôte non planifiées, Microsoft recommande d’adopter une architecture hautement disponible plutôt que de s’appuyer sur une seule VM.

Option 1 : Utiliser les Zones de disponibilité (recommandé)

• Déployer les VM sur plusieurs centres de données physiques au sein d’une même région
• Chaque zone dispose d’une alimentation, d’un refroidissement et d’un réseau indépendants
• Si une zone est affectée, les autres restent disponibles

Option 2 : Utiliser des groupes de disponibilité (Availability Sets)

• Répartit les VM sur plusieurs domaines de panne (séparation matérielle) et domaines de mise à jour
• Protège contre les défaillances d’hôte similaires à celles que vous avez rencontrées

Option 3 : Utiliser plusieurs VM derrière un équilibreur de charge

• Exécuter au moins 2 VM en parallèle
• Les placer derrière un Azure Load Balancer ou Application Gateway
• Garantit que l’application reste disponible même si une VM est redéployée

Option 4 : Envisager les groupes de machines virtuelles identiques (VM Scale Sets)

• Gère automatiquement plusieurs instances de VM
• Offre une résilience et des capacités de mise à l’échelle intégrées

4. Recommandation clé pour votre scénario

Puisque votre charge de travail repose actuellement sur une seule VM, elle est intrinsèquement vulnérable aux interruptions en cas de défaillance d’hôte.

Pour réduire significativement, voire éliminer les interruptions :

• Passer à une architecture multi-VM (Zones ou Groupes de disponibilité)
• Associer cela à un équilibrage de charge pour le basculement

5. Remarques supplémentaires

• Des défaillances d’hôte occasionnelles sont normales dans des environnements cloud à grande échelle
• Azure gère automatiquement la récupération (comme observé dans votre cas)
• L’objectif est de concevoir pour la résilience plutôt que d’éviter complètement les défaillances d’hôte

6. Résumé de la réponse à votre question

• Changer le type de VM → N’améliore pas la résilience
• Utiliser les Zones / Groupes de disponibilité → Solution recommandée
• Utiliser plusieurs VM → Meilleure approche pour éviter les interruptions

Remarque : Ce contenu est traduit depuis l’anglais ; veuillez ignorer toute erreur grammaticale.