Haute disponibilité : raisonner en domaines de panne.

Dessiner le chemin utilisateur

Partir d’une requête et suivre DNS, réseau, répartiteur, application, identité, base et stockage. À chaque étape, identifier ce qui peut interrompre l’ensemble. Deux applications utilisant un stockage unique partagent encore un point de défaillance.

Choisir le bon mécanisme

Le redémarrage d’une VM sur un autre hôte réduit l’impact d’une panne matérielle, mais prend du temps. Un cluster applicatif peut maintenir un service via plusieurs instances. Actif/passif et actif/actif ont des implications différentes sur les écritures, les sessions et les conflits de données.

• Répartir les composants entre domaines de panne réellement indépendants.
• Prévoir assez de capacité après la perte d’un nœud.
• Documenter la cohérence des données et les comportements en cas de partition réseau.

Comprendre quorum et fencing

Un cluster doit décider quels membres peuvent continuer à agir quand ils ne se voient plus. Le quorum aide à prendre cette décision ; le fencing peut isoler un nœud pour empêcher des écritures concurrentes dangereuses. Leur conception dépend de la technologie et de la topologie. Un simple nombre pair ou impair de serveurs ne résout pas toute la question.

Exercer les pannes et le retour

Tester la perte d’un hôte, d’un lien, d’un stockage ou d’un site selon le périmètre prévu. Vérifier détection, bascule, capacité résiduelle et reconnexion des clients. Tester aussi le retour au nominal. La haute disponibilité ne remplace pas les sauvegardes ni un plan de reprise face à une corruption généralisée.