La CNAF va enfin éteindre ses mainframes Bull et IBM

Objectif : éteindre les mainframes, mais préserver le code Cobol

Si l’une des propositions techniques évoquait une virtualisation du code Cobol en J2EE, les autres solutions proposaient une simple adaptation et recompilation du code via différents compilateurs x86. C'était notamment le cas de la solution avancée par Accenture/Atos qui a emporté l’appel d’offre : « En tant qu’établissement public, le coût était bien évidemment un critère important, de même que le dimensionnement des machines et la capacité à pouvoir mener un tel projet", souligne Fabrice Charraire, Chef de projet "Filière unique" de la CNAF. L’option de réécrire les 13 millions de lignes de code de Cristal et de SDP a été rapidement écartée. « Cela aurait été un projet d’une toute autre envergure et il faut savoir que nous devons faire face à de grosses évolutions réglementaires 3 fois par an au minimum, et nous avons des livraisons de code chaque mois. Il nous fallait donc à la fois mener cette migration vers une nouvelle plateforme, mais aussi intégrer ces évolutions permanentes. Nous n’avons pas écarté la possibilité de faire du reengineering de notre code, mais la solution LiberTP proposée par Bull nous permettra à l’avenir de faire cohabiter l’ordonnancement des programmes Cobol, mais aussi des programmes J2EE dans le même moteur. Nous pourrons ainsi faire évoluer le code graduellement et développer des APIs. »

En outre, le groupement Accenture/Atos a apporté à la CNAF la garantie qu’il n’y aurait pas de gel des développements lors de la migration. Une garantie qui s’est avérée particulièrement judicieuse par la suite. En effet, alors que le projet battait son plein, les équipes de la CNAF ont dû mettre en place la PPA (prime d’activité).

Une architecture x86 totalement virtualisée sous VMware ESX

L’architecture cible retenue retient le principe d’un Cloud privé VMware constitué de clusters ESX mettant en oeuvre 3 serveurs x86 Bullion de 120 cœurs, dont un est maintenu en réserve (spare). Sur cette architecture, chacune des 102 CAF dispose de sa propre machine virtuelle. « Il y a une VM Linux par CAF car celles-ci sont indépendantes dans leur fonctionnement », précise Fabrice Charraire. « Il s’agit véritablement d’un Cloud privé car nous sommes en train de construire un datacenter où les autres applications métiers ou support de la CNAF autres que Cristal et SDP viendront s’exécuter à leur tour. » 

Dans la conception de l'architecture cible, les ingénieurs ont transposé, pièce par pièce, les composants de la plateforme existante, même s'il y a un monde entre les architectures mainframe et la cible. Cette dernière met en œuvre le moteur transactionnel LiberTP et le moniteur de batch LiberBatch, deux solutions éditées par Bull pour ces projets de migration mainframe. Le premier exécute à la fois le code Cobol via avec un runtime Cobol Micro Focus, mais aussi des applications Java J2EE. LiberBatch assure pour sa part l'exécution des traitements JCL et JES sur x86. Côté bases de données, les bases DB2 sur z/OS et PostgreSQL sur GCOS 8 font place à PostgreSQL sous Red Hat Linux.

Un code Cobol portable, mais à adapter

En dépit de cette recherche de compatibilité, le code source de Cristal et SDP, mais aussi l'ensemble des batchs qui gravitent autour des applications ont du être adaptés à cette plateforme x86 de nouvelle génération et à son runtime Micro Focus. Ces adaptations ont mobilisé une équipe d’une demi-douzaine de développeurs Bull sur une période de 6 mois. Paradoxalement, du fait de sa double infrastructure IBM / Bull, la CNAF était déjà experte en portage Cobol. En effet, les développements étaient menés jusqu’à aujourd’hui sur un mainframe IBM puis porté sur GCOS pour les CAF qui étaient sur la plateforme Bull. « Une partie de nos programmes Cobol étaient déjà portables. Il a néanmoins fallu les adapter car les runtimes mainframe sont plus souples et permissifs que ne l'est celui de Micro Focus. En outre, nous utilisions Install one, un produit qui a aujourd’hui disparu, mais dont nous avions acheté les sources et avec lequel nous écrivions le code source de Cristal et SDP. Il s’agit de modèles qui nous garantissent une certaine qualité du code produit. Pour les parties spécifiques du code liées à la plateforme, nous adaptions notre code z/OS pour qu’il fonctionne sur GCOS. L’équipe Bull a fait exactement la même chose, mais à destination de la plateforme cible x86. A travers l’usine logicielle que nous avons conçue avec Bull, ce portage se fait de manière automatisée vers GCOS et maintenant Micro Focus. » Cette usine a permis d’intégrer dans la version Micro Focus toutes les modifications réalisées tout au long des 2 années de projets dans les versions z/OS et GCOS.

Les mainframes Bull définitivement arrêtés à la fin du mois

A l'heure actuelle, les applications Cristal et SDP ont été basculées et 100 % des CAF exploitent ces applications sur la nouvelle architecture. Les mainframes Bull GCOS qui n’exécutaient que Cristal et SDP seront éteints à l'échéance de leur fin de contrat, c'est-à-dire à la fin du mois de juin. Pour la partie z/OS, la situation est plus complexe puisque d’autres applications étaient exécutées sur ces machines. Le portage de ces applications est en cours et les mainframes IBM pourront être enfin éteints d’ici à la fin d’année. Néanmoins, de très importantes économies vont être générées dès maintenant puisque le modèle économique du mainframe IBM est basé sur une consommation facturée au MIPS.

Pour dimensionner la plateforme x86 cible, l'appel d’offre imposait de pouvoir traiter 4 500 transactions/seconde. Des benchs ont été menés dès la phase de dialogue compétitif avec chacun des candidats et un test grandeur nature a été réalisé avec des injecteurs de charge qui ont simulé l’activité des 102 CAF. "La plateforme a tenu les 4 500 transactions/seconde avec un niveau de charge correct sur 2 machines seulement, la troisième étant conservée en spare." Actuellement, cette infrastructure délivre plus de 120 millions de transactions et traite 3 milliards de requêtes SQL chaque jour et la puissance disponible laisse encore une marge de progression. "A l’avenir, le choix de l’architecture x86 nous offre la possibilité d’accroitre très simplement la puissance disponible par ajout de serveurs plus ou moins puissants selon les besoins futurs."

Un projet dans les temps grâce à l'aide des CAF pilotes

Si la cible initiale du projet était une mise en production en juin 2016, celle-ci a été réalisée à la fin du mois de mai, donc un peu avant la date prévue. Pourtant, le projet "Filière unique" n’a pas démarré sous les meilleurs auspices. En effet, peu après l’attribution du marché à Accenture et Atos, un candidat malheureux a attaqué en justice la décision de la CNAF. La procédure a entériné le choix du groupement Accenture / Atos, mais l'attente de la décision a décalé d’un mois la date de début du projet. De même, comme il est fréquent dans les projets de cette ampleur, les développements liés au portage des applications ont pris un peu de retard. « Nous avons du faire appel à plusieurs CAF afin d’accélérer les phases de test et qu’ils nous aident à valider les livrables. Le rôle des CAF des Hautes-Pyrénées, de l’Aude, du Finistère et des Bouches du Rhône a été clé dans cette phase du projet. Enormément de pression a été mise sur nos équipes afin de rattraper le temps perdu lors des phases de test. Par contre, pour le déploiement lui-même, celui-ci s’est déroulé très rapidement. Nous avions bloqué deux week-ends en cas de retard, mais nous n’en avons pas eu besoin. C’est le résultat d’un pilotage strict du projet, permis notamment par le sponsoring du projet par le directeur général de la CNAF qui a insufflé à tout le réseau des CAF cette volonté d’aboutir dans les temps. »

S'il y a eu relativement peu de modifications à apporter au code source de Cristal, ce ne fut pas le cas sur le volet JCL, avec énormément de petits scripts à reprendre - l'influence des spécificités techniques de la plateforme sur les scripts est bien plus grand. Il est à noter que tous ces traitements restent écris en JCL et sont exécutés par LiberBatch. Ce n’est que sur les futurs scripts que les développeurs de la CNAF utiliseront les langages de script Unix Korn Shell ou Bash Shell directement et se passeront de plus en plus de LiberBatch. L’impact est plus important sur le travail des exploitants qui n’ont plus des instances CICS à gérer mais des machines virtuelles Linux. Néanmoins, VMware et Linux étaient déjà présents dans l’environnement informatique de la CNAF et désormais le mot d'ordre est de généraliser le recours à cette plateforme d’exploitation pour toutes les applications.  Toute la production informatique est réinternalisée dans les datacenters de la CNAF, avec un datacenter à Sophia Antipolis et un second à Valenciennes.

Si, avec un budget de 22 millions d’euros, le coût du projet peut sembler extrêmement élevé, le retour d’investissement est attendu dès la fin 2017. « Le MCO (Maintien en Condition Opérationnelle, NDLR) de nos deux plateformes mainframe était de l’ordre de 24 millions d’euros par an, un chiffre qui va tomber à 5 millions pour les quelques applications qui resteront en production sous z/OS. C’était un projet qui était devenu absolument nécessaire si on considère les contraintes de financement qui pèsent sur la branche famille. C’est une contribution à l’effort d’économie qui est demandé à la CNAF », conclut Fabrice Charraire.