Le CHU de Nantes mise sur VPlex pour la continuité d’activités

Le CHU de Nantes dispose d’une infrastructure hautement virtualisée, depuis plusieurs années, exploitant plusieurs centaines de machines virtuelles. Le fruit d’une volonté du RSSI, explique Julien Besnier, Ingénieur de production rattaché à l’équipe de support technique de la DSI du centre hospitalier : « il s’agissait d’assurer la continuité de production des applications critiques. Dans l'hôpital, on travaille 24h sur 24. Ce programme a conduit à mettre en place un plan de continuité de l’activité basé sur Vplex. »

Virtualiser pour gagner en fiabilité

L’infrastructure informatique du CHU est répartie sur plusieurs sites, avec « deux sites majeurs distants d’une dizaine de kilomètres et séparés par la Loire ». Les réseaux des deux sites sont interconnectés doublement via les fibres de la communauté urbaine de Nantes. En s’appuyant sur les outils de VMware, la DSI « a virtualisé au maximum tout ce qui pouvait l’être pour gagner en souplesse en cas d’incident sur un site. La demande était de pouvoir supporter sur un seul site l’ensemble des applications ». Ensemble, les deux sites présentent donc une capacité double à celle des besoins de production. Certaines applications n’étant pas virtualisables, elles profitent de clusters actif/passif « avec accès croisé aux ressources de stockage ». Un ensemble de stockage primaire est installé au sud de la Loire, sur le site dit « Turner », quand le second se trouve au nord, « les deux étant répliqués en continu par le processus Mirror View ».

Las, un incident a montré que dans certains cas, cela pouvait conduire à des délais de remise en production trop élevés : « cela rentrait dans le contrat, qui nous accordait 4 heures pour remonter les applications critiques. Mais ce n’était pas satisfaisant pour les utilisateurs. Un tel délai, pour le soignant qui attend pour lancer son application, c’est toujours trop long », explique Julien Besnier.

D’où la volonté de virtualiser le stockage, avec une architecture VPlex pour les machines virtuelles. L’architecture ainsi revue fait intervenir un troisième site, hébergeant le witness de l’infrastructure VPlex, qui vérifie en continu l’état des baies. Ce site-là assure également l’hébergement des sauvegardes, avec les outils d’Avamar. « Pour gagner encore en sécurité, nous avons ajouté un lien direct en les deux VPlex, un choix rendu possible par la faible latence sur le lien et qui nous permet d’opérer des bascules très rapides. »

Des gains considérables

Et les gains sont flagrants. « Nous avons rencontré quelques incidents graves », reconnaît Julien Besnier. Comme la perte d’une baie de stockage lors d’une opération de maintenance, sur le site nord : « toutes les applications portées par des machines virtuelles se sont raccrochées automatiquement à la baie de Turner. Nous n’avons perdu qu'une seule entrée/sortie. » Pour l’ingénieur, « c’est le cas idéal. VPlex fait tellement bien son travail que l’on pourrait ne pas s’en rendre compte. » D’ailleurs, grâce au cache d’entrées/sorties des VPlex, les utilisateurs eux-mêmes n’ont rien vu.

 

Un incident plus grave a encore montré l’efficacité du système : « nous avons perdu toutes les liaisons sur un site. La situation était plus difficile car le witness ne voyait plus rien. » En outre, le CHU exploitait alors une version 5.0 d’ESX avec laquelle les machines virtuelles ne réalisaient pas qu’elles avaient perdu leurs ressources de stockage : « elles sont restées figées. » Il a donc fallu les arrêter, les migrer, puis les relancer. VPlex a toutefois permis de limiter les interventions manuelles : « nous avons eu seulement à nous occuper des machines virtuelles, pas du stockage. » Toutefois, le witness ne voyant plus rien, « nous avons du lancer une commande manuelle pour assurer la resynchronisation des VPlex ».

Le CHU de Nantes exploite désormais la version 5.5 d’ESX qui, grâce aux fonctions dédiées à la haute disponibilité, aurait permis d’éviter les interventions manuelles sur les machines virtuelles. Ce qu’il a d’ailleurs eu l’occasion de faire, lors d’un troisième incident.

Intégrer les serveurs physiques

A ce stade, Julien Besnier estime disposer d’une « protection significative », mais les serveurs physiques ne sont pas encore intégrés « et l’on perd pas mal de temps avec eux en cas d’incident. Surtout, ce sont dans notre cas des applications très critiques avec un impact conséquent ». Un projet de refonte du système d’information permettra prochainement d’intégrer les ressources de stockage des serveurs physiques à l’infrastructure VPlex. « En arrivant à cette architecture, en cas de problème, le support technique n’aura presque plus rien à faire, car VPlex sécurise très bien l’infrastructure. »