Projets

Virtualisation et consolidation pour le PRA de la mutuelle AGPM

PSI-PRA... la mutuelle d'assurances AGPM a bâti son plan de reprise d'activité pour ses serveurs Windows et son Mainframe, et virtualisée sa production.

PublicitéL'AGPM est une mutuelle d'assurances. Elle a bâti son plan de reprise d'activité pour ses serveurs Windows et son Mainframe. Sa production est virtualisée. Ses serveurs de secours sont conservés éteints pour une reprise sous quatre jours, mais qui devrait s'avérer plus rapide en pratique. Les PSI (Plan de Secours Informatique) et les PRA (Plan de reprise d'activité) arrivent en tête des préoccupations des entreprises françaises quelque soit leur taille. Cette problématique a été abondamment traitée lors d'une journée organisée le jeudi 27 mars par NetApp. L'occasion d'entendre le témoignage de l'AGPM (Association générale de prévoyance militaire), une association mutualiste qui emploie 780 personnes. Elle assure des missions de mutuelle d'assurances (de biens et de personnes), ainsi que de commercialisation de prêts ou de produits d'épargne. L'AGPM gère 600.000 adhérents et un million de contrats. Elle est présente via trente points d'accueil en France, y compris les DOM-TOM. Un historique en réseau SAN Fibre Channel Son informatique repose sur un Mainframe IBM pour les traitements 'batch' et sur des serveurs Windows, notamment pour des bases SQL Server et la messagerie Exchange de Microsoft. Journée NetApp oblige, le stockage de l'AGPM exploite des baies de stockage FAS 3020 du constructeur. Ces baies sont connectées vers les serveurs applicatifs et entre elles à la fois en Fibre Channel et en Gigabit Ethernet. « Nous avions un historique important en réseau SAN », justifie Jean Michel Massé, directeur adjoint de la DSIT de l'AGPM. Multiplication des serveurs et des applications La direction a demandé aux équipes informatiques de bâtir un PRA. Un bunker avait alors été bâti à Toulon (83). « Nous avons un bunker informatique, mais que se passerait-t-il en cas de crash d'un avion sur le bâtiment nous a-t-il été demandé ? », résume Jean-Michel Lassé. Dans le même temps, la DSIT devait faire face à une croissance exponentielle de ses serveurs Windows, dont certains n'étaient utilisés qu'à hauteur de 20% de leurs capacités. D'une informatique traditionnelle à base d'un mainframe IBM, l'AGPM avait ainsi évolué vers les systèmes ouverts, au risque d'être débordé. Il devenait urgent de passer à une phase de consolidation. « On multipliait les serveurs et les applications, et on ne s'en sortait plus, car il n'y a que deux personnes pour gérer l'infrastructure dans l'équipe système », reprend Jean Michel Massé. Virtualisation de 110 serveurs La mutuelle a alors adopté la consolidation et la virtualisation de ses serveurs via VMware. Toute la production est virtualisée. Ce qui représente 110 machines virtuelles (VM), déployées sur un total de 19 lames sous ESX 3.01 de VMware de technologie x86 d'origine Fujitsu Siemens. Sept lames sont conservées sous Windows Server 2003. Le stockage, pour sa part, s'arcboute sur un cluster de deux contrôleurs FAS3020. Certains applicatifs tels Exchange, sont déployés en iSCSI et des accès fichiers s'effectuent en CIFS. Deux sites ont été constitués. Le site principal (3 châssis Blade Center de Fujitsu Siemens, 20 lames, cluster de 2 baies FAS 3020) est séparé par deux cent mètres du second site (3 châssis Blade Center de Fujitsu Siemens, 21 lames, 1 baie FAS 3020) destiné à la reprise d'activité, sur le même campus. Toujours savoir où se trouvent les VM Des sauvegardes régulières sont effectuées sur la baie de secours de stockage FAS 3020 tandis que les serveurs en lames, similaires à ceux de la salle principale, restent éteints, prêts à démarrer. « Nous ne voulons pas partager les ressources que constitue l'ensemble des serveurs de secours, malgré des mécanismes comme VMotion, DRS (Distributed Resource Scheduler) ou HA(High Availability) de VMware, qui équilibrent la charge, car nous voulons savoir où se trouvent les machines virtuelles », déclare Fabrice Grosso, administrateur du stockage. Il n'est pas question, par exemple, que les équipes des études et de développement de la direction informatique - une soixantaine de personnes - utilisent les serveurs de secours en temps normal afin de ne pas compliquer le redémarrage en cas de panne, dans la précipitation. Les mécanismes de sauvegarde de NetApp Les sauvegardes sont réalisées tous les soirs à 19 heures. 150 snapshots sont effectués pour autant de volumes à sauvegarder du cluster principal, les applications étant actives. Ces snapshots sont ensuite recopiés vers la baie de secours. Cette opération s'effectue via les outils Snapvault de NetApp. « L'avantage de SnapVault comparé à SnapMirror est que l'on conserve les différentes itérations des sauvegardes. SnapVault correspond plutôt aux besoins en sauvegarde tandis que SnapMirror répond aux besoins en continuité d'activité. SnapVault évite également de propager d'éventuels virus de la configuration principale à celle de secours, relève Fabrice Grosso. L'AGPM utilise les outils de sauvegarde spécifiques pour Exchange et SQL : Snap Manager for Exchange, et Snap Manager for SQL. » Des disques SATA pour le secours Dans le détail des configurations matérielles, le cluster de stockage principal gère une capacité de 11,2 To en disques Fibre Channel, 3,6 To en disques SATA et 3,6 To en disques SATA protégé par le dispositif SnapLock de NetApp, destiné à un archivage légal, nécessaire pour les documents d'assurance. En tout, 150 volumes sont définis dans la baie. Les serveurs en lames sont dépourvus de disques et démarrent depuis les disques du cluster FAS3020. Quant au serveur FAS3020 de stockage de secours, il possède une capacité de 19,2 To en disques SATA, complété d'un autre espace de 3,6 To en SATA. Les serveurs de secours sont dans la même configuration que la salle principale. Un premier redémarrage en une demi journée Tous les serveurs et les baies de stockage sont interconnectés via deux commutateurs SAN en Fibre Channel. Cependant, la réplication entre les baies s'effectue via le réseau Ethernet afin de faciliter une éventuelle externalisation vers un autre site si nécessaire. Les volumes recopiés sur la baie de sauvegarde sont conservés en lecture seule. Les outils Flexclone de NetApp servent ensuite à dupliquer ces volumes avec des droits en écriture et lecture, afin que les applications redémarrées sur les serveurs de secours puissent les utiliser. Développer ses propres scripts de gestion du stockage L'AGPM a du définir ses propres scripts afin de surveiller l'état d'occupation des disques car la mutuelle essaye de tirer parti de toute la capacité disque installée. Cela a pris trois semaines de développement. Les scripts assurent également l'affectation (le mapping) automatique des volumes Flexclone aux lames de secours, lorsque celles-ci démarrent. Les scripts définissent également les partages CIFS sur la baie de secours. Un test de basculement sur le site de secours a eu lieu avec uniquement une dizaine de lames, soit la moitié de la production. « Nous avons redémarré en une demi journée. En Juin prochain, nous testerons le basculement de toute la production », annonce Fabrice Rosso. Le Mainframe est séparé du SAN Le système Mainframe, pour sa part, est resté à l'écart de ce réseau. La société loue les services de Sungard, pour disposer de capacités de redémarrage en cas de destruction du Mainframe. « L'objectif est de migrer depuis le Mainframe d'IBM, dont les coûts des redevances sont trop élevées, vers les systèmes ouverts ». Le déploiement des nouveaux serveurs de stockage FAS320 a été réalisé entre Janvier et Septembre 2007. Le projet de stockage a été réalisé par l'intégrateur APX Synstar, pour un coût indiqué entre 200.000 et 300.000 €.