Hyperviseurs, clusters et HA
Comprendre les types d'hyperviseurs et les mécanismes de haute disponibilité et de migration à chaud entre hôtes.
À retenir
- Les hyperviseurs de type 1 (bare-metal) dominent en production grâce à leur surface d'attaque réduite.
- HA redémarre les VM après une panne détectée ; la migration à chaud les déplace sans coupure de service.
- Un cluster HA nécessite un stockage partagé et une compatibilité CPU entre hôtes.
- Le dimensionnement N+1 ou N+2 de la capacité de secours doit être testé, pas seulement configuré.
Type 1 vs Type 2 : deux familles d'hyperviseurs
Un hyperviseur permet d'exécuter plusieurs machines virtuelles sur un même matériel physique en partageant CPU, mémoire, stockage et réseau. On distingue deux familles :
| Type | Fonctionnement | Exemples | Usage typique |
|---|---|---|---|
| Type 1 (bare-metal) | S'exécute directement sur le matériel, sans OS hôte intermédiaire | VMware ESXi, Microsoft Hyper-V, KVM | Data centers, production d'entreprise |
| Type 2 (hébergé) | S'exécute au-dessus d'un système d'exploitation hôte | VirtualBox, VMware Workstation | Postes de développement, tests |
Point clé
en environnement de production, on utilise quasi systématiquement un hyperviseur de type 1 : l'absence d'OS hôte intermédiaire réduit la surface d'attaque et la latence d'accès au matériel.
Clusters et haute disponibilité (HA)
Un cluster d'hyperviseurs regroupe plusieurs hôtes physiques partageant un stockage commun (SAN, NAS ou stockage hyperconvergé). Cette mise en commun permet deux mécanismes essentiels :
- HA (High Availability) : en cas de panne d'un hôte physique, les VM qu'il hébergeait sont automatiquement redémarrées sur un autre hôte du cluster. Il y a une brève interruption de service (le temps du redémarrage), mais pas de perte définitive.
- vMotion / Live Migration : migration à chaud d'une VM en cours d'exécution d'un hôte vers un autre, sans interruption perceptible, généralement utilisée pour la maintenance planifiée (mise à jour firmware, remplacement matériel).
Attention
ne confondez jamais HA et migration à chaud. HA implique un redémarrage (donc une coupure courte) après détection d'une panne ; la migration à chaud est proactive et sans coupure, mais nécessite que la VM et l'hôte de destination soient tous deux opérationnels au moment du transfert.
Prérequis techniques d'un cluster HA
- Stockage partagé accessible par tous les hôtes du cluster (SAN/NAS/vSAN)
- Réseau de management dédié et redondant entre les hôtes
- Compatibilité CPU entre hôtes (ou EVC / CPU compatibility mode activé)
- Licence et configuration cohérentes sur chaque nœud
Un piège classique consiste à ajouter un hôte au cluster avec un processeur d'une génération différente sans activer le mode de compatibilité CPU (EVC chez VMware, par exemple) : la migration à chaud échoue alors avec des erreurs difficiles à diagnostiquer pour un débutant.
Illustration : HA au niveau Kubernetes
Le principe de haute disponibilité existe aussi à un niveau plus applicatif, par exemple avec les PodDisruptionBudget qui limitent le nombre de pods indisponibles simultanément lors d'une maintenance planifiée :
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: webapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: webapp
Ce manifeste garantit qu'au moins deux instances de l'application restent disponibles pendant un drain de nœud, un principe conceptuellement proche du HA au niveau hyperviseur.
Le calcul du taux de consolidation
Un cluster surdimensionné en capacité de HA (par exemple en réservant systématiquement la capacité d'un hôte entier « N+1 ») coûte cher en ressources inutilisées. Un cluster sous-dimensionné ne pourra pas absorber la charge des VM d'un hôte tombé en panne, provoquant une dégradation de performance généralisée.
Sur le terrain
sur des clusters de taille moyenne (4 à 8 hôtes), la règle empirique N+1 (un hôte de capacité de secours) est un bon point de départ ; au-delà de 12-16 hôtes, on peut souvent passer à N+2 sans surcoût relatif significatif.
Astuce
testez régulièrement le déclenchement réel du HA (mise en maintenance simulée d'un hôte) plutôt que de vous fier uniquement à la configuration théorique : des règles d'anti-affinité mal configurées peuvent empêcher un redémarrage effectif en conditions réelles.