Mardi 9 Juillet à 10:30 le processeur d'un de mes serveurs est tombé en panne. La panne aurait pu passer inaperçue, si elle n'avait pas impliqué le serveur SQL. Cela étant dit, cette panne a mis en évidence un vrai problème disponibilité du réseau. Le but étant d'apprendre de ces erreurs je vous propose de détailler un peu ce qu'il s'est passé et surtout ce que je viens de mettre en place pour éviter ce genre de problème à l'avenir.

L'architecture du réseau

Avant ce crash, le serveur SQL était une machine physique, elle assumait 3 instances de SQL pour fournir aux deux serveurs WEB (Alpha pour la production, Vector pour l'homologation) les environnements nécessaire au site web. La dernière instance étant la base de données pour le serveur TFS.

La Panne

Comme je le disais un peu plus haut. Malgré la possibilité d'effectuer un redémarrage manuel à distance en utilisant le Mindstorm dans l'armoire. Le robot a été incapable de redémarrer le serveur. Apres 5 tentatives je reçois un message sur mon téléphone pour m'informer que le serveur SQL est HS. Et là, c'est le drame. Les deux serveurs WEB sont plantés ainsi que le serveur TFS. Après check du serveur c’est le processeur qui est mis en cause. Malgré l'installation d'une nouvelle carte mère et d'un nouveau processeur, Windows n’a pas été capable de redémarrer. Pas grave, ce sera l'occasion de tester en directe le plan de sauvegarde du serveur SQL. A cette date, mon réseau était monté de la façon suivante.

L'évolution

Pour ressortir quelque chose de constructif de cette panne, je décide de revoir complètement le mode de fonctionnement du réseau. Au lieu d’installer SQL en directement sur le serveur Windows fraîchement installé, j’ai créé une nouvelle machine virtuelle sur laquelle j’ai installé SQL et ces fameuses 3 instances. Cette Machine Virtuelle vient donc s’ajouter aux deux existantes qui stockent les environnements de production et d’homologation avec les serveurs IIS.

Matériellement mon réseau est donc équipé d’un deuxième serveur de 8Go de mémoire Vive. Le premier reçoit le nom de Cluster1 et le second Cluster2. J’ai déployé sur les deux machines les 3 serveurs virtuels.

Toutes les 30 secondes le serveur de domaine demande au Cluster1 de donner son état. Si au bout d’une minute le Cluster n’a pas répondu. Le serveur de domaine tente la procédure de redémarrage manuel en s’appuyant sur Mindstorm. Au bout de 5 tentatives, il identifie le serveur comme étant HS et démarre le Cluster2. Au démarrage du Cluster2 la première action est de récupérer les machines virtuelles sauvegardées sur un autre serveur (Zeta) la veille (tous les jours a 3 heures du matin) une fois récupérées, il boot les 3 VM et notifie le serveur de domaine de son état. Dès lors le serveur de domaine route les paquets du Cluster1 vers le Cluster2. L’interruption de service est de 7 minutes. Coté site Web et TFS la seule perte résident dans les modifications de la journée.

Reste à faire ?

C’est bien beau mais que reste-t-il à faire pour avoir un système complètement « Sécurisé »

1. Avoir une deuxième ligne en cas de coupure de la première
2. Scripter toutes les entrées de la base de la journée afin de les rejouer au moment du démarrage du Cluster de secours. Ainsi il n’y aura pas de perte de données.

Je suis bien conscient qu’avoir une telle architecture pour un particulier relève de la folie furieuse. Qu’installer mon site Web sur une plateforme Azure aurait permis de laisser d’autres se charger de cette problématique de haute disponibilité. Mais ca aurai été moins drôle ! En tout cas si vous souhaitez le code source de l’automate de « Load-Balancing », « Boot des VM » ou autres informations complémentaires n’hésitez pas.