La haute disponibilité vise à maintenir l'accès à un service malgré la panne d'un composant, au moyen de systèmes redondants.
Définition simple
Une architecture HA peut associer des nœuds actifs et passifs, des contrôles de santé et une bascule automatique. Elle exige d'identifier les points uniques de défaillance et de tester les scénarios de panne ; elle ne remplace pas les sauvegardes.
À quoi ça sert ?
Maintenir les applications critiques accessibles lors de la panne d’un serveur ou de certains équipements, réduire les interruptions pendant des opérations planifiées et respecter des objectifs de disponibilité. Le périmètre doit être explicite : protéger deux hôtes ne garantit pas une continuité si le stockage, l’alimentation ou le lien Internet reste unique.
Comment ça fonctionne ?
Une plateforme HA surveille l’état de ses composants avec des sondes ou échanges réguliers (health checks, heartbeats). Si un composant tombe en panne, un mécanisme de failover peut rediriger le trafic ou redémarrer les services sur une autre ressource. Les architectures sont souvent actives/passives ou actives/actives. Pour les clusters qui partagent des données, il est essentiel de gérer le quorum ou un mécanisme équivalent afin de réduire les risques de split-brain.
- Surveillance Sondes et heartbeats
- Panne détectée Nœud indisponible
- Bascule Failover du cluster
- Nœud restant Ressources de secours
- Service repris Après délai éventuel
La haute disponibilité limite les interruptions ; selon le mécanisme, une VM peut devoir redémarrer et le service subir un délai.
Points clés
- Un point unique de défaillance caché : alimentation, pare-feu, switch, stockage ou DNS.
- Capacité insuffisante sur les nœuds restants pour absorber la charge après bascule.
- Quorum, heartbeats ou réseau de cluster mal configurés, pouvant empêcher ou perturber le failover.
- État applicatif ou stockage partagé non cohérent après un incident.
- Tests de bascule jamais réalisés et temps de reprise réel inconnu.
Points d’attention
Un groupe de deux ou trois hôtes de virtualisation partage une architecture de stockage conçue pour la disponibilité. Si l’un des hôtes tombe en panne, les machines virtuelles concernées peuvent être redémarrées sur les hôtes restants, sous réserve de ressources suffisantes. La HA du cluster ne signifie pas nécessairement que les VM poursuivent leur exécution sans interruption.
Actif/passif, actif/actif et tolérance de panne
Dans un modèle actif/passif, le nœud secondaire prend le relais lorsque le principal devient indisponible. Le modèle actif/actif distribue certaines charges sur plusieurs instances, mais demande souvent une gestion particulière des sessions, des données et de la répartition du trafic. Le dimensionnement doit prévoir ce qui se passe en cas de perte d’un nœud, et pas seulement lorsque tous les composants fonctionnent.
La tolérance aux pannes peut viser des interruptions plus faibles que certaines formes de haute disponibilité, mais elle exige des mécanismes et des investissements supplémentaires. HA et absence totale d’interruption ne sont pas synonymes.
Détection des pannes, quorum et bascule
Les sondes de santé surveillent la disponibilité des composants. Le failover peut prendre diverses formes : redirection par un répartiteur, promotion d’une base secondaire, transfert d’une adresse virtuelle ou redémarrage d’une VM ailleurs. Le délai réel dépend de la détection, des dépendances et du mécanisme de reprise.
Le quorum protège certains clusters contre des décisions concurrentes prises par deux parties isolées. Sans mécanisme anti-split-brain approprié, plusieurs nœuds peuvent croire qu’ils sont seuls actifs et endommager des données communes.
HA, PRA, réplication et sauvegarde : les limites
La haute disponibilité vise surtout à limiter une interruption causée par une panne couverte par l’architecture. Le PRA (plan de reprise d’activité) prévoit comment redémarrer les services après un incident majeur ; la réplication peut fournir une copie rapidement exploitable ; la sauvegarde permet de revenir à une version plus ancienne et indépendante.
Un cluster HA ne répare pas une suppression accidentelle ou une attaque qui affecte simultanément les nœuds. Les objectifs de SLA, RTO et RPO doivent être mesurés et accompagnés de tests d’incident réels.
Termes associés
Concepts associés
En résumé
À retenir : la HA combine redondance, détection de panne et bascule pour limiter les interruptions. Elle doit couvrir les points de défaillance réels et compléter, non remplacer, PRA et sauvegardes.