Deux serveurs applicatifs peuvent partager une cause de panne

Un second serveur applicatif peut prendre le relais d’un processus défaillant. La possibilité pour le client de poursuivre son travail dépend aussi des composants communs. Le prochain investissement devrait donc couvrir une panne identifiée plutôt que seulement augmenter le nombre de serveurs.

Microsoft recommande d’examiner la redondance du calcul, des données et du réseau le long des parcours critiques. Doubler la couche applicative ne répond pas encore à la question du parcours complet.

Rendre visible le chemin commun

Dans l’exemple fictif, les clients ouvrent une liste de projets. Deux instances applicatives sur des machines virtuelles distinctes lisent la même base de données. Un unique répartiteur de charge, exploité par l’équipe, se trouve devant elles. Il distribue les requêtes ; il ne s’agit pas ici d’un service d’accès géré et redondant en interne. Les données de session nécessaires pour continuer ne sont pas conservées uniquement sur une instance applicative.

Les identifiants du tableau appartiennent uniquement à cet exemple. Au départ, aucun composant ne remplace la base ou le répartiteur. Le tableau décrit les effets attendus, pas une disponibilité mesurée.

Quelle panne la seconde instance peut couvrir

Même le premier cas reste une attente à tester. Si la machine restante est surchargée ou si le routage ne fonctionne pas, sa seule présence ne suffit pas. Deux VM peuvent aussi partager un site, l’alimentation électrique ou une autre infrastructure ; les domaines de panne réels doivent correspondre au besoin.

Traiter spécifiquement la couche de données commune

Pour que la liste reste disponible lors d’une panne de base de données, la couche de données a besoin d’une approche adaptée à la disponibilité et au basculement. Il faut préciser la perte de données acceptable, la cohérence et le comportement des écritures en cours. Un second processus de base de données ne prouve pas non plus une continuité sûre.

Microsoft distingue les réplicas en fonctionnement des copies de sauvegarde datées. Une sauvegarde sert à la restauration ; elle n’est pas automatiquement une base de remplacement en fonctionnement immédiatement disponible. La réplication ne remplace pas une restauration testée après une modification involontaire des données. Les mesures nécessaires dépendent de l’objectif métier.

Décider à partir du parcours utilisateur touché

L’analyse de panne de Microsoft suit chaque parcours critique et ses dépendances internes et externes. Pour notre exemple, les trois cas du tableau devraient être testés séparément dans un environnement autorisé. Il faut consigner la détection, le comportement au chargement de la liste, la reprise et le rôle responsable.

Si un parcours de restauration convenu couvre suffisamment une interruption de la base, l’instance applicative supplémentaire peut rester utile contre les pannes de processus ou pour la maintenance. Si l’activité exige une continuité lors d’une panne de base ou d’accès, ces lacunes demeurent. Le nombre de machines ne permet pas de déduire un taux de disponibilité.

Sources

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup