Remplacement SNA Serveur solution basée sur z/Linux François-Xavier DUCREUX – i-BP CRIP Thématique Mainframe 16 septembre 2010 1

Remplacement SNA Serveur – solution basée sur z/Linux Contexte Remplacement des échanges SNA (LU6.2) entre les serveurs d’agences et les partitions HOST CICS/DB2 : application Popix Contraintes Fin de support des versions Microsoft SNA Server utilisées sur les serveurs d’agences Contrainte sur le contrat OBS ne supportant plus SNA Prise en compte du nouveau DATA CENTER – suppression du protocole DLSW de transport SNA entre les serveurs d’agences et le site central (1T 2008) Sans remise en cause de l’architecture client/serveur Popix ( sans modification de l’application – uniquement des couches techniques)

Remplacement SNA Serveur – solution basée sur z/Linux Objectifs à court terme Réponse aux contraintes du contrat OBS Réponse à la contrainte de la suppression du DLSW Objectifs à moyen terme Suppression des flux internes i-BP dans les environnements de gestion des changements (abandon de l’architecture TOKEN RING)  Nécessaire avant le déménagement sur le nouveau DATA CENTER (1T 2010)  Architecture arrivée à ses limites, contraignant les accès simultanés entre les serveurs et le HOST. 3

Remplacement SNA Serveur – solution basée sur z/Linux Périmètre concerné début 2008 2 800 serveurs contenant SNA Server Jusqu’à une douzaine de sessions simultanées par serveur Serveurs localisés dans les agences ou dans les sièges des banques Pour les environnements de production ou d’école (formation) Ainsi qu’un nombre important de serveurs hébergés par i-BP Pour les environnements de développement, d’intégration, de qualification, etc. 4

Remplacement SNA Serveur – solution basée sur z/Linux Approche de la problématique Étude menée fin 2007 pour permettre de démarrer l’implémentation dès janvier 2008 Intégration d’une contrainte supplémentaire concernant l’optimisation des coûts de la solution : l’application Popix étant amenée à disparaître au profit du nouveau réseau d’agences en cours de déploiement à l’époque Consultation des plusieurs fournisseurs pour connaître les solutions possibles : IBM Microsoft RUMBA 5

Remplacement SNA Serveur – solution basée sur z/Linux Les caractéristiques de la solution recherchée Stabilité du fonctionnement Prise en charge de la redondance entre les deux sites du DATA CENTER (actif/actif) Prise en compte du PCA Possibilité de gestion de la charge Suivi de la solution en production En cas d’incident : vitesse et complétude du rétablissement du fonctionnement pour les utilisateurs  bascule sur l’autre site, etc. Et ensuite, facilité de retour à la situation nominale 6

Remplacement SNA Serveur – solution basée sur z/Linux Solution Microsoft Basée sur HIS Branch Office et BizTalk Étude « papier » puis réalisation d’une maquette Solution IBM 3 solutions proposées basées sur CommServer sous AIX, Linux ou z/Linux Solution RUMBA Basée sur du REWAMPING et nécessitant l’acquisition et l’installation de couches supplémentaires sur le HOST Solution écartée après l’étude « papier » 7

Remplacement SNA Serveur – solution basée sur z/Linux Maquette Microsoft Solution peu stable (communication entre le client et le serveur) Taux d’erreurs important avec la montée en charge Performances très disparates Maquette IBM Réalisée sur serveurs Linux sur machines Intel Mise en ordre de marche rapide : moins de 2 heures Solution très stable mais basée sur un nouveau produit (CommServer) 8

Remplacement SNA Serveur – solution basée sur z/Linux Au final : choix de la solution COMMSERVER d’IBM AIX : délai de mise à disposition des machines incompatible avec les contraintes du projet (remplacement sur le 1T 2008) Choix de la solution Linux Installée sur machine z (abandon de Linux sur Intel – installation déconseillée sur VMWARE) L’installation sur le HOST permet l’intégration « automatique » dans les plans de continuité et de reprise : sans actions particulières Coût de la solution z/Linux s’est révélé être le moins cher Nécessité de monter les équipes i-BP en compétence sur la partie Linux car très peu connue (AIX était le système UNIX connu et maîtrisé en interne) 9

Remplacement SNA Serveur – solution basée sur z/Linux Solution finale Mise en place d’une partition z/Linux sur chaque site i-BP (1 machine par site – z9 en 2008) Partition native (pas de z/VM) Mise en œuvre d’un processeur spécialisé IFL par machine et dédié à chaque partition z/Linux Installation de CommServer sur z/Linux Etablissement des liens entre les partitions Linux et les partitions frontales réseau pour assurer la communication avec les applications LU 6.2 CICS via ENTERPRISE EXTENDER Côté agences : remplacement sur les serveurs Popix du client SNA par le client COMMSERVER – transparent pour les utilisateurs 10

Remplacement SNA Serveur – solution basée sur z/Linux Solution finale Communication assurée via  Des liens OSA pour les accès externes aux partitions  Des liens HIPERSOCKET pour la communication interne – accès doublés par d’autres cartes OSA par sécurité La redondance est assurée par chaque partition z/Linux Nativement la moitié du parc de serveurs d’agences pointe sur une partitions z/Linux (notion de Linux maître / backup pour chaque serveur) Bascule automatique sur l’autre en cas de problème – relativement transparent aux utilisateurs : anomalie uniquement sur la transaction en cours d’exécution OSPF assure la répartition de charge 11

Remplacement SNA Serveur – solution basée sur z/Linux Schéma de la solution mise en place Partition frontale z/OS O S P F O S P F 2 Partitions Prod z/OS O S P F Mainframe site 1 IP Poste Popix Serveur Popix Partition Linux 1 Master Backup O S P F Client CS IP O S P F 3 Partitions Prod z/OS O S P F Partition frontale z/OS Hipersocket OSA Mainframe site 2 Partition Linux 2 IP Existant 12

Remplacement SNA Serveur – solution basée sur z/Linux Mise en œuvre de z/Linux Choix de la distribution RED HAT (déjà installé sur quelques serveurs OPEN) z/Linux est géré par la même équipe que z/OS Pour les compétences et les connaissances de l’équipe au niveau des machines z, de l’interaction avec le HARDWARE (OSA, CPU, disques, HMC, …) z/Linux est installé sur des volumes 3390 (CKD) ce qui permet son intégration automatique dans les plans de secours standards z/Linux est gérée avec les mêmes processus que z/OS : environnement de référence (installation), partition système, diffusion en production par clonage depuis la référence Environnement très stable  Pas ou peu de corrections appliquées  Très peu de REBOOT (2 fois par an en planifié) 13

Remplacement SNA Serveur – solution basée sur z/Linux Mise en œuvre de CommServer Produit « jeune » au début de la mise en place (début 2008) Problèmes de performance, consommation CPU, mauvais traitement des ruptures de sessions réseau, … Problèmes sans aucun lien avec z/Linux lui-même Intervention des Labs US sur site  réécriture d’une partie du code Situation stabilisée ensuite 14

Remplacement SNA Serveur – solution basée sur z/Linux Problème rencontré Manque de puissance du processeur IFL pour absorber la pointe de la journée (09h00-09h15)  Relatif à une activité spécifique réalisée à l’ouverture des agences Uniquement sur les machines z9 utilisées à l’époque  Pas de souhait d’investir sur un second processeur Réglé de fait suite au passage sur z10 fin 2008 15

Remplacement SNA Serveur – solution basée sur z/Linux Au final Une solution très satisfaisante Mise en œuvre dans les délais Sans impact sur les utilisateurs ni sur les applications HOST 16