Comment le CH de Saint-Martin a retrouvé une IT redondante après Irma
L’IT fonctionnant depuis l’unique salle que l’ouragan n’a pas détruite, il fallait redéployer un double du datacenter. La difficulté fut alors de synchroniser des équipements de générations différentes.
Le 5 septembre 2017, entre 1H00 et 8H00 du matin, l’ouragan Irma dévastait l’île de Saint-Martin, dans la mer des Caraïbes. Parmi les immeubles touchés, le seul Centre Hospitalier de la partie française a notamment vu le toit de sa salle informatique arraché par la tempête, projetant des trombes d’eau sur les serveurs, baie de stockage et autre appliance de sauvegarde.
Par chance, le CH disposait d’une seconde salle, réplique de la première, justement prévue pour être redondante et assurer le maintien de l’activité. Problème, il faudra attendre un an pour redéployer la salle détruite et revenir à un fonctionnement normal.
Pourquoi si longtemps ? Parce que les matériels informatiques ayant entretemps évolué, ceux à installer n’étaient plus du même modèle que ceux encore en place et, dès lors, la synchronisation entre les deux salles n’était plus automatiquement garantie.
« Avoir deux salles informatiques en mode active-active était une prérogative du gouvernement depuis 2013, dans le cadre de l’informatisation du dossier patient. Dès lors que nous n’en avons plus eu qu’une seule, toute évolution de notre datacenter a été gelée. Nous avons maintenu l’exécution des applications médicales et administratives existantes, mais nous ne pouvions plus prendre le risque d’en installer de nouvelles, faute de pouvoir basculer sur une solution de secours en cas de problème », raconte Jean-François Desrumaux, le chef de projet informatique du Centre Hospitalier de Saint-Martin.
À force de tests et de validation, l’équipe parviendra in fine à restaurer un ensemble actif-actif grâce à l’emploi du système de stockage virtualisé SANsymphony de DataCore.
Deux salles en mode actif-actif au niveau des baies de stockage
Au départ, c’est-à-dire en 2014, l’informatique du Centre Hospitalier de Saint-Martin se compose d’un cœur de réseau en 10 Gbit/s qui répartit les utilisateurs entre deux salles identiques où sont exécutées les applications. Dans chacune de ces salles, on trouve deux serveurs ESXi, des modèles x3650M4 d’IBM, dotés chacun de 8 cœurs Xeon E5 à 2,4 GHz, 128 Go de RAM, deux disques SSD de 128 Go chacun pour démarrer et deux ports FC en 8 Gbit/s.
Chacun de ses ports est relié à l’un des deux switches Fiber Channel, desquels partent également des connexions vers une baie de disques IBM StoreWize V3700, offrant 10 To de capacité, et vers un serveur SANsymphony, installé sur un IBM x3250M4. La fonction de ce dernier est de présenter les volumes de stockage aux deux serveurs ESXi.
Entre les deux salles, la redondance est assurée à deux niveaux. D’une part, les serveurs de virtualisation, qui fonctionnent sous VMware vSphere HA & DRS, communiquent via le réseau Ethernet 10 Gbit/s pour s’assurer qu’ils exécutent tous le même jeu de machines virtuelles. D’autre part, un lien FC dédié d’une salle à l’autre permet aux baies Storwize de synchroniser leurs contenus en temps réel grâce à la fonction Global Mirror d’IBM.
S’il y a bien au total 20 To de capacité entre les deux salles, chacune d’elle ne voit bien qu’un SAN de 10 To.
À cette installation s’ajoute un système de sauvegarde dans une seule salle. En l’occurrence, le logiciel Dataclone de Matrix protège en permanence le contenu des machines virtuelles sur un NAS de 6 To, également de marque Matrix. Hélas, la salle détruite lors de l’ouragan sera justement celle qui hébergeait cette sauvegarde.
Des serveurs IBM inondés qui redémarrent
Après le passage de l’ouragan, dès que l’électricité est rétablie, soit au bout de trois jours, l’équipe de Jean-François Desrumaux remet en route l’informatique. Comme il n’y a plus de seconde salle pour répartir l’activité des applications, il est décidé de gonfler la mémoire des deux serveurs ESXi épargnés jusqu’à 384 Go. « Tripler la quantité de RAM nous est apparu comme une solution satisfaisante pour maintenir la fluidité des applications. Ainsi, nous n’avions pas besoin d’augmenter aussi la puissance processeur », indique Jean-François Desrumaux.
En l’occurrence, ces deux serveurs étant les derniers à maintenir les applications en activité, le chef de projet informatique est peu enclin à perturber leur fonctionnement. Pas question donc de les décommissionner pour les remplacer par des modèles plus performants, ce qui aurait supposé des semaines d’indisponibilité.
Du côté des machines inondées, il s’avère que les deux serveurs ESXi d’IBM redémarrent ! « Il n’était cependant pas question de les remettre en production pour exécuter les applications, car nous n’étions plus certains de leur fiabilité. Puisque nous n’avions plus de redondance, nous avons eu l’idée, pour protéger à minima notre activité, d’entreposer ces deux serveurs dans un local et de les utiliser comme équipement de secours, au titre de PRA », raconte Jean-François Desrumaux.
« Nous les avons donc équipés chacun de 5 To à partir des disques issus des baies de stockage et avons mis en place un dispositif qui réplique dessus, de manière quotidienne et asynchrone, les contenus des serveurs ESXi de production.
DataCore pour créer une redondance entre deux baies différentes
Remplacer l’appliance Matrix par un nouveau modèle dans la salle épargnée ne pose pas de problème, puisque ce dispositif est relativement indépendant du reste.
Toute la problématique est en revanche de racheter des matériels qui pourraient se synchroniser entre deux salles. Nous sommes alors en 2017, et les modèles proposés par IBM n’ont plus rien à avoir avec ceux de 2014. En particulier, la baie de stockage Storewize est désormais une V3700v2, avec des disques SAS en 12 Gbit/s et un nouvel OS, tandis que celle encore en production utilise des disques SAS en 6 Gbit/s.
L’idée est donc plutôt d’assurer la synchronisation entre deux baies de disques au niveau du serveur SANsymphony de Datacore. Celui-ci a en effet la capacité d’assembler des baies de stockage différentes pour les présenter comme un seul volume logique aux serveurs. Il n’est toujours pas question d’additionner les capacités de l’une et de l’autre : SANsymphony présentera toujours aux serveurs un seul volume de 10 To. Ou plutôt de 20 To désormais, puisque Jean-François Desrumaux ambitionne alors de doubler la capacité de stockage de son futur datacenter afin d’accueillir de nouvelles applications.
La validation de cette solution durera de décembre 2017 à novembre 2018. La difficulté supplémentaire à résoudre fut que la future seconde salle disposait toujours de son propre serveur SANsymphony. Or, celui-ci était condamné à souffrir du même inconvénient que les baies de stockage : la machine physique qui l’hébergerait ne serait plus la même. Ce serait désormais un x3250M6 de Lenovo, IBM ayant revendu cette gamme à son confrère chinois fin 2014.
Juste une journée pour rendre opérationnelle la nouvelle seconde salle
Une fois tous les tests menés et les bons réglages effectués, le déploiement de la nouvelle seconde salle, reconstruite entretemps, ne dure qu’une journée. C’est le temps qu’il faut au premier serveur SANsymphony pour qu’il réplique les 8 To utiles de sa baie sur le nouveau système de stockage.
Du point de vue de l’administration, il aura suffi de redéfinir les chemins entre les deux salles entre tous les serveurs et toutes les baies de disques. Pour aller au plus simple, les 10 To supplémentaires sont configurés comme une nouvelle LUN. Depuis l’interface de configuration d’ESXi, l’équipe de Jean-François Desrumaux y a abonné toutes les VMs des nouvelles applications.
Depuis décembre 2018, le CH de Saint-Martin fonctionne à nouveau avec deux salles informatiques en mode actif-actif et aucun problème technique n’est à signaler. Jean-François Desrumaux ne prévoit plus d’évolution sur son matériel avant 2022.