Technologie Eranea
migration 100 % automatique et iso-fonctionnelle
vers x86, Linux & Java
02 Juillet 2015
Table des Matiè...
pour décrire le code de l'application mais il faut lire en fait à chaque fois « le code source de
l'application à laquelle...
introduire en continu et automatiquement les dernières modifications de l'application originale
en Cobol dans sa version J...
les générations technologiques, vers les outils de développement les plus productifs du moment, afin de
maximiser en perma...
menée a priori pour le garantir.
• son iso-fonctionnalité parfaite n'est pas toujours garantie. Il ne peut alors pas être ...
la moderniser et lui ajouter, si possible, de nouvelles fonctions par différents outils de « traduction ».
Les transformat...
Enfin, l'acceptation du nouveau système doit se faire sur des critères comportant nécessairement
une part de subjectivité ...
essentiel : ils peuvent passer au nouveau système sans aucune nécessité de formation supplémentaire.
C'est un point essent...
migration incrémentale via automatisation 100% et iso-fonctionnalité intégrale (1)
migration incrémentale via automatisati...
2. continuité de l'évolution : le point précédent permet de continuer la maintenance et les
évolutions du système au fil d...
Des scénarios de référence capturés sur l'ancien système via 3270 peuvent être rejoués à la
demande sur le système Java po...
Eranea a donc fait le choix délibéré de favoriser la productivité des développeurs dans leur
nouvel environnement et leur ...
4.3.1. Transcodage
système de transcodage
Pour atteindre les avantages clefs décrits dans le paragraphe précédent, Eranea ...
intégration continue : synoptique
◦ alimentation en code source à partir du mainframe puis stockage dans l'entrepôt logici...
4.3.2. Framework d'exécution
association transcodeur + runtime
Plusieurs librairies composent le framework d'exécution Nea...
4.3.3. Environnement de développement
Un plugin Eclipse (ou autre IDE) est installé sur la station de travail des développ...
Elles amènent une très forte activité de communication entre la machine hébergeant une instance
sécurisée et celle héberge...
dominance de l'architecture x86
Intel et AMD disposent désormais d'une part de marché plus que dominante sur le marché des...
Dans les comptes « vierges » sur le sujet et recherchant des coûts optimaux, Eranea recommande une
stratégie Open Source.
...
évolution du marché des systèmes d'exploitation
Dans le cas d'environnements de grande échelle, le recours à Linux permet ...
• un fournisseur identique à Linux (si RHEL est choisi par ailleurs) donc une simplification
organisationnelle.
5.3. Archi...
mutuellement pour recevoir et traiter les requêtes TCP de création de sessions http.
Puis, elles passent les requêtes aux ...
5.4. Architecture batch
Elle est fondée sur 5 composants essentiels :
 L'ordonnanceur batch (Control/M de BMC, par exempl...
l’enchaînement des appels aux programmes applicatifs et utilitaires tiers selon les sollicitations du
plan d'ordonnancemen...
Prochain SlideShare
Chargement dans…5
×

Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel

1 588 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 588
Sur SlideShare
0
Issues des intégrations
0
Intégrations
652
Actions
Partages
0
Téléchargements
11
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Eranea : presentation technique de la solution de transcodage Cobol vers Java, automatique et iso-fonctionnel

  1. 1. Technologie Eranea migration 100 % automatique et iso-fonctionnelle vers x86, Linux & Java 02 Juillet 2015 Table des Matières 1.Préambule................................................................................................................................................1 2.Introduction.............................................................................................................................................2 3.Analyse du marché..................................................................................................................................3 3.1.Solutions alternatives......................................................................................................................3 3.2.Comparaison au transcodage iso-fonctionnel..................................................................................3 3.2.1.Synthèse...................................................................................................................................3 3.2.2.Rehosting <> transcodage.......................................................................................................4 3.2.3.Transformation <> transcodage...............................................................................................5 4.Solution de Migration Eranea.................................................................................................................7 4.1.Principes..........................................................................................................................................7 4.2.Méthodologie...................................................................................................................................8 4.3.Technologie...................................................................................................................................12 4.3.1.Transcodage...........................................................................................................................13 4.3.2.Framework d'exécution..........................................................................................................15 4.3.3.Environnement de développement........................................................................................16 5.Architecture technique Eranea..............................................................................................................16 5.1.Objectifs fonctionnels....................................................................................................................16 5.2.Composants techniques.................................................................................................................16 5.2.1.Serveurs x86 et stockage.......................................................................................................16 5.2.2.Virtualisation..........................................................................................................................18 5.2.3.Distribution Linux.................................................................................................................19 5.2.4.Application Server (AS) Java................................................................................................20 5.3.Architecture transactionnelle.........................................................................................................21 5.4.Architecture batch.........................................................................................................................23 1. Préambule 1. Pour toute question ou information complémentaire, merci d'envoyer un mail à contact@eranea.com. Un Proof of Concept (PoC) est également réalisable de manière simple et rapide. 2. Pour la concision des textes, le mot « Cobol » est utilisé de manière systématique dans la suite 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 1 de 24
  2. 2. pour décrire le code de l'application mais il faut lire en fait à chaque fois « le code source de l'application à laquelle la solution est appliquée » : cela peut être PacBase, CoolGen, RPG, Ideal-Datacom, EasyTrieve, etc. 3. Voir http://www.eranea.com/presentation pour une illustration graphique de l'ensemble des informations ci-après 2. Introduction Ce document présente la solution de migration Eranea du monde mainframe / Cobol (IBM z/OS, Bull GCOS, etc.) vers une plate-forme x86 / Linux / Java avec interface web/ajax. Elle est également applicable à toute application Cobol fonctionnant dans un autre environnement (AS/400, AIX, Solaris, OpenVMS, etc.) La nouvelle plate-forme cible est désormais le plus souvent une infrastructure de type « private cloud » : l'application dans sa nouvelle forme Java est directement installée sur une plate-forme de déploiement et d'administration de cloud privé comme, par exemple, CloudStack, OpenStack (elle- même basée sur Java), etc. Un tel choix permet de profiter de tous les gains de productivité en termes de gestion apportés par ces technologies et de tout leur potentiel de croissance efficace à très grande échelle. Cette infrastructure privée peut ensuite donner naissance à un cloud hybride où l'application est partiellement migrée vers un opérateur public, voire à une externalisation complète sur le cloud de cet opérateur afin d'atteindre une optimisation économique maximale. Les deux apports majeurs de la technologie Eranea sont : • une très forte modernisation : l'obsolescence de la plate-forme mainframe est remplacée par un nouveau système respectant tous les standards d'infrastructure (x86, Linux) et d'applications (Java, web/ajax) actuels. Une partie de la modernisation est effectuée à travers la migration elle- même mais, de plus, cette dernière offre à l'application le potentiel de mettre en œuvre à court terme toutes les fonctions de la nouvelle plate-forme non directement utilisées durant le projet. • des économies massives : de manière consistante à travers différents projets, Eranea permet à ses clients de réaliser une économie toujours supérieure à 80 % , voire 90 % dans les situations les plus favorables lors de la sortie d'un mainframe vers une plate-forme x86. Cela signifie donc des millions d'euros d'économies effectives, annuellement récurrentes, en matériels et logiciels. Ce résultant très attrayant est par ailleurs atteint fluidement, sans aucun risque, grâce à la méthodologie de migration incrémentale d'Eranea sans « Big Bang ». Elle est sous-tendue par les caractéristiques de sa technologie, spécifiquement développée pour permettre cette approche particulièrement adaptée à la migration des applications métier critiques des très grands comptes. En effet, la technologie dispose de deux caractéristiques distinctives par rapport à la concurrence : • automatisation continue à 100 % : l'application originale est transformée vers Java et web/ajax sans aucune intervention humaine. Cette transformation automatique, appelée transcodage, peut donc être répétée aussi souvent que nécessaire (chaque 24h voire N fois par jour) pour 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 2 de 24
  3. 3. introduire en continu et automatiquement les dernières modifications de l'application originale en Cobol dans sa version Java, et permettre ainsi la poursuite de la maintenance durant toute la durée du projet de migration sans travail à double. • iso-fonctionnalité stricte : l'application Java génère exactement les mêmes résultats que l'application originale « au bit près ». Les données qu'elle produit sont donc indiscernables de celles produites par l'application originale. La combinaison de ces deux caractéristiques permet une migration totalement incrémentale : chaque utilisateur transactionnel ou chaque traitement batch peut être migré vers la nouvelle version java/web sur x86 sans aucune corrélation avec ses pairs (dans l'absolu, un par un et en totale indépendance). Tous restent cependant parfaitement intégrés au système global par le travail en direct, permis par l'iso- fonctionnalité, sur la base de données originale de l'application mainframe. 3. Analyse du marché 3.1. Solutions alternatives La solution de transcodage d'Eranea est souvent comparée à 2 types de solutions : • les solutions de « rehosting » qui transportent l'application dans son état courant (Cobol, 3270, etc.) vers une plate-forme beaucoup plus économique en lui apportant le moins de changements possibles : Cobol reste Cobol, interface homme-machine reste de type « écran passif », etc. On utilise un compilateur Cobol ciblant Linux pour exécuter les modules sources inchangés sur la nouvelle plate-forme. Les APIs système (CICS, batch, etc.) sont apportées par l'environnement d'exécution du compilateur et des modules tiers complémentaires. • les solutions de « transformation » qui changent une ou plusieurs technologies de départ pour les faire évoluer vers l'état de l'art. Elles apportent aussi le plus souvent des améliorations structurelles ou fonctionnelles dans l'application. Elles sont le plus souvent basées sur des outils d'analyse du patrimoine applicatif, puis de régénération de celui-ci dans une forme qui se veut optimisée. 3.2. Comparaison au transcodage iso-fonctionnel 3.2.1. Synthèse Au vu de l'analyse ci-après, le transcodage iso-fonctionnel, tel que pratiqué par Eranea, apparaît comme la meilleure synthèse entre les avantages du rehosting et de la transformation, sans les inconvénients majeurs de ces 2 types de solutions. Cette synthèse, qu'est le transcodage, souhaite traiter les deux pans du problème posé au responsable informatique pour la sortie du mainframe : les aspects tactiques de l'exploitation (« Run ») qui doit toujours être réalisée pour un coût moindre sur des plates-formes technologiques pérennes et les aspects stratégiques du développement (« Build ») qui doit protéger les lourds investissements applicatifs déjà réalisés en les transportant de manière agile et rapide, à travers 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 3 de 24
  4. 4. les générations technologiques, vers les outils de développement les plus productifs du moment, afin de maximiser en permanence la compétitivité de l'entreprise face à sa concurrence et à face l'évolution permanente de son métier. Pour ce faire, le transcodage iso-fonctionnel rassemble les caractéristiques suivantes : • comme le rehosting, et contrairement à la transformation, il définit une cible parfaitement claire et objective : un système qui produit les mêmes résultats que le système original afin, d'une part, d'en faciliter les tests et d'en rendre la validation totalement quantifiable et objective et, d'autre part, de permettre une migration transparente pour les utilisateurs. • comme le rehosting (quand il est lui aussi strictement iso-fonctionnel), et contrairement à la transformation, il permet une migration très fluide et incrémentale, éliminant tous les risques et préservant la continuité des affaires. • comme le rehosting, il apporte des gains économiques très substantiels (> 80 % des coûts initiaux). • à l'opposé du rehosting, et comme la transformation, il transporte l'application vers une nouvelle plate-forme technologique plus moderne (Java + interface web) dont il utilise directement une partie des possibilités, mettant le reste du potentiel à disposition des développeurs qui poursuivront la maintenance évolutive de l'application après le projet. • comme la transformation, le transcodage place l'application sur de nouvelles bases technologiques très pérennes qui lui offrent une extension massive de sa durée de vie et une agilité nouvelle très importante, afin de maximiser son ouverture et sa vitesse d'évolution ainsi que la productivité des développeurs. • à l'opposé de la transformation, le transcodage place « le chemin vers le but » (= les différentes étapes de la migration) en priorité maximale, en le favorisant par rapport même au maximum de transformation possible. La volonté est de rendre la plate-forme cible atteignable par une série de multiples d'étapes simples, minimales et maîtrisées (et le plus souvent réversibles) pour maximiser le succès du projet en réduisant son taux de risque à zéro. Cette priorité se fait bien sûr au détriment de certaines transformations structurelles qui restent bien sûr possibles par les développeurs à l'issue du projet. • à l'opposé de la transformation, l'automatisation totale est le choix privilégié afin de contenir les coûts et délais du projet. Elle permet la continuité de la maintenance de l'application originale, le plus souvent barrée durant une transformation profonde. Cette automatisation totale donne également lieu à une méthodologie de tests efficace et objective. La validation du projet est alors très « mécanique » au meilleur sens du terme alors que la transformation amène toujours le projet dans des zones plus subjectives de validation. 3.2.2. Rehosting <> transcodage • Le rehosting a pour principal but d'atteindre les mêmes économies très fortes que le transcodage. Il y parvient le plus souvent même si l'analyse des licences de runtime doit être 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 4 de 24
  5. 5. menée a priori pour le garantir. • son iso-fonctionnalité parfaite n'est pas toujours garantie. Il ne peut alors pas être « raccordé » directement au système à migrer. Il conduit alors à la construction d'un système parallèle avec tout le danger que cela comporte (voir ci-dessous la section « transformation ») • de même, certaines constructions Cobol ou API mainframes ne sont pas toujours supportées par le compilateur Linux. Elles nécessitent l'adjonction d'outils qui réalisent des modifications « les plus compatibles possibles ». Ces outils d'adaptation doivent être totalement automatisés sans aucune intervention manuelle sous peine d'empêcher la répétabilité de la compilation pour les nouvelles versions de l'application quand sa maintenance doit continuer en parallèle de la migration. • le principal défaut du rehosting est de laisser l'application du client dans sa technologie d'origine, en voie d'obsolescence, qui doit alors continuer à être maîtrisée et utilisée par des développeurs Cobol. • en ce sens, il ne résout par le problème de raréfaction (donc de cherté croissante) des ressources humaines compétentes dans ces technologies en fin de vie. La masse des développeurs « pointus » dans ces secteurs est actuellement en train de s'approcher de la retraite. • une problématique sous-jacente est que le rehosting perpétue les technologies obsolescentes avec la fourniture par les prestataires de librairies reproduisant les interfaces du mainframe (CICS, batch, Cobol). Ce sont des librairies maintenues sous forme propriétaire avec une pérennité non garantie. Le transcodage s'appuie quant à lui sur un socle technologique très ouvert et portable (Java) dans toutes ses couches, qui sont toutes disponibles en Open Source, gage total d'autonomie complète pour le client en cas de nécessité. Ce socle est d'ailleurs celui des plus grands systèmes informatiques du moment (Google, Facebook, Amazon, etc.) En synthèse, l'approche « rehosting » a des apports économiques très solides, similaires au transcodage. Sa parfaite iso-fonctionnalité doit être vérifiée a priori pour éviter toute obligation de migration en mode « Big Bang ». Par contre, le rehosting ne résout pas les problèmes cruciaux actuels pour nombre de responsables informatiques : obsolescence des technologies de base et raréfaction rapide de la main d’œuvre compétente nécessaire pour faire vivre les systèmes les utilisant. Bien sûr, il apporte l'un des avantages également obtenu par le transcodage : la perpétuation de la structure organisationnelle et des algorithmes de l'application originale car il maintient finalement celle-ci totalement dans son contexte original. Il est juste donc de voir le rehosting comme une solution aux problèmes tactiques de l'exploitation (coûts) mais pas à ceux du développement, cependant beaucoup plus stratégiques pour le long terme puisqu'il en va de la protection des lourds investissements en compétences métier par leur transposition vers un contexte technologiquement pérenne. 3.2.3. Transformation <> transcodage Le parti pris initial des solutions de transformation est justement de modifier l'application initiale pour 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 5 de 24
  6. 6. la moderniser et lui ajouter, si possible, de nouvelles fonctions par différents outils de « traduction ». Les transformations apportées sont souvent doubles : technologiques (passage à Java, à html/ajax) et fonctionnelles (restructuration structurelle, orientation objet, modification des processus, etc.). Ces solutions de transformation ont pour objectif un bond fonctionnel en avant maximal : il n'est clairement pas dans leurs objectifs de se soucier de l'iso-fonctionnalité assurant la compatibilité avec le système à migrer. De cette volonté d'évolution maximale découlent les quatre soucis principaux de la solution : • Le taux de modifications fonctionnelles et algorithmiques est intrinsèquement très important. Il est souvent très dur à ingérer par les développeurs en place qui passent, en général, par un énorme « trou de productivité », le temps de reprendre pied dans les millions de lignes de code source massivement restructuré qui leur sont livrés en fin de projet. Leur « prise en main » nécessite toujours un fort investissement pour revenir au même niveau de maîtrise que celui des codes sources de l'application originale. Des modifications trop importantes peuvent parfois conduire à un rejet complet de cette forme de transformation. • Une partie de ces transformations est le plus souvent manuelle : elles ne peuvent donc être répétées qu'un nombre limité de fois durant le projet, sous peine d'en grever dangereusement les coûts. Par ailleurs, cette même contrainte bloque le plus souvent la poursuite de la maintenance de l'application dans sa forme originelle durant le projet de transformation. Ce point peut devenir particulièrement gênant quand les contraintes du métier (réglementation, marché, concurrence, etc.) lui imposent une évolution très rapide. • Le nouveau système n'est pas compatible avec l'ancien. La migration offre alors seulement deux voies vers ce nouveau système indépendant et parallèle : ◦ la migration « Big Bang » où tous les utilisateurs et traitements sont basculés ensemble au Jour J : nombre de projets de migration de ce type sont tristement célèbres pour les dégâts irréversibles (retours arrières très pénibles, etc.) qu'ils ont parfois causés. Il y a de toute façon une taille limite et une criticité maximale du système initial au-delà desquelles ce genre de migration est hors sujet ! ◦ la migration incrémentale entre les deux systèmes (ancien et nouveau) fonctionnant en parallèle : cette forme de migration donne alors naissance - obligatoirement - à un troisième système, le plus caché possible, assurant la synchronisation des données entre les deux systèmes. La problématique associée devient alors quasi-systématiquement celle de la complexité de mettre en phase des systèmes conçus sans objectif de cohérence particulier. Cette complexité s'accroît encore quand la synchronisation des données doit être à la fois bidirectionnelle et en temps réel (ce qui est toujours le cas sur les plus grandes applications). Il peut alors arriver que coûts et délais explosent sous les contraintes de ce système de synchronisation, souvent sous-estimé dans les phases initiales du projet. • La problématique des tests associés à la validation du nouveau système peut devenir conséquente : ils doivent être bâtis à partir de rien. Ils sont donc générateurs de coûts bien supérieurs à ceux produits très naturellement par la vérification directe de l'iso-fonctionnalité. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 6 de 24
  7. 7. Enfin, l'acceptation du nouveau système doit se faire sur des critères comportant nécessairement une part de subjectivité qui est totalement absente du transcodage iso-fonctionnel, strictement objectif et quantifié dans sa validation. Les objectifs d'une solution de transformation peuvent être extrêmement ambitieux tant sur les plans technique que fonctionnel. Ils peuvent l'être d'autant plus que le prestataire est déchargé de la responsabilité de compatibilité avec l'existant. La contre-partie est celle de la création du système de synchronisation parfois fort complexe. La validation du nouveau système peut également s'avérer pénible et coûteuse car ses tests de validation sont à bâtir sans le support du système existant et ses critères de validation comportent une part de subjectivité. Il est donc juste de voir la transformation comme une protection de toute la propriété intellectuelle et les compétences métier intégrées par le client dans son application à migrer. En cela, la problématique stratégique du développement est correctement traitée. Mais, c'est le chemin de transition que cette voie peine à définir correctement : il est soit impraticable par ses risques (Big Bang), soit extrêmement coûteux et complexe (synchronisation). Il faut ajouter à cela un risque très fort de perte de maîtrise sur la nouvelle version de l'application de par sa structure bouleversée. 4. Solution de Migration Eranea Cette section rappelle les principes généraux de la technologie et de la méthodologie Eranea quand elles sont utilisées dans le cadre d'une migration de mainframe vers architecture x86. Il apparaît intéressant de décrire le mode opératoire d'une migration habituelle afin de voir les avantages classiques de la technologie Eranea. Ils peuvent ensuite être adaptés à des cas plus spécifiques : L4G comme Pacbase, Ideal-Datacom, besoins particuliers des éditeurs de logiciel, simulateur indépendant basé sur une application opérationnelle, etc. N.B. : dans un but de généralité et de clarté, la présentation ci-après est faite sur la base d'un contexte système limité à z/OS, CICS, DB2. Elle est transposable à d'autres contextes (AIX, OS/400, Solaris, OpenVMS, etc. à la place de z/OS, IMS comme moniteur transactionnel au lieu de CICS, Oracle comme cible au lieu de DB2 LUW, présence de fichiers VSAM, etc.) le cas échéant. 4.1. Principes La solution migratoire d'Eranea permet d'éviter toute migration brutale de type « Big Bang » pour des systèmes complexes dans leur architecture et critiques pour le métier. Ces migrations brutales sont le plus souvent vouées à l'échec et nécessairement très dangereuses pour les activités industrielles et commerciales que le système supporte. Au contraire, Eranea propose une méthodologie favorisant l'absence totale de risque et la forme incrémentale complète du processus migratoire, tout en garantissant la poursuite des évolutions du système sans aucune interruption de maintenance due à cette migration. Pour les utilisateurs finaux, l'iso-fonctionnalité parfaite du nouveau système a un impact positif 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 7 de 24
  8. 8. essentiel : ils peuvent passer au nouveau système sans aucune nécessité de formation supplémentaire. C'est un point essentiel pour la flexibilité de cette mutation. Par ailleurs, cette absence de formation diminue d'autant les coûts du projet. A la fin de la migration, les développeurs peuvent poursuivre sans perte de productivité l'évolution du nouveau système nativement en Java. En effet, ils y retrouvent sans effort toutes les constructions algorithmiques et syntaxiques familières du système originel. Ils poursuivent cette évolution dans le cadre d'outils au niveau de l'état de l'art : IDE Eclipse, outils de qualité Java, etc. Eranea contribue, par ailleurs, à l'amélioration de cette productivité en fournissant un plugin pour Eclipse (adaptable aux autres IDEs) qui permet, entre autres, une édition efficace du code source original Cobol (si le besoin persiste pour certains développeurs fortement réfractaires à Java), un transcodage instantané dans l'IDE, un debugging interactif orienté vers le langage original (visualisation des structures de variables avec leurs valeurs, etc.) L'ensemble du système informatique migré est alors conforme à l'état de l'art aussi bien pour l'exploitation que pour le développement. 4.2. Méthodologie Eranea a développé sa technologie pour satisfaire les contraintes de la méthodologie de migration qu'elle juge optimale : complètement incrémentale et sans aucun risque. Elle est fondée sur l'utilisation des bases de données en tant que « pivot » et vecteur de communication / collaboration en temps réel entre l'ancien et le nouveau système. Ses outils permettent une migration : • 100 % automatisée : le code source originel est transformé vers Java / JEE et html/ajax sans aucune intervention manuelle. Ceci est réalisé, par exemple, en moins de 15 minutes pour une application de plus de 10 millions de lignes de code source. • parfaitement iso-fonctionnelle : le code Java produit les mêmes résultats « au bit près » dans sa version Java que via le code original. Les algorithmes et leur structure de codage sont rigoureusement conservés dans le code traduit. En conséquence, les résultats stockés en base de données partagée par le Java transcodé sont indiscernables de ceux fournis par l'application originale. De même, pour l'utilisateur final, l'ergonomie de l'interface homme-machine est absolument identique dans la technologie html/ajax résultante : mêmes champs dans les mêmes écrans, mêmes séquences de saisie et d'enchaînement inter-écrans. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 8 de 24
  9. 9. migration incrémentale via automatisation 100% et iso-fonctionnalité intégrale (1) migration incrémentale via automatisation 100% et iso-fonctionnalité intégrale (2) De ces 2 caractéristiques fondamentales découlent les avantages essentiels de la méthodologie : 1. équivalence fonctionnelle : l'automatisation totale de la conversion permet de transcoder les nouvelles versions de l'application dans leur langage original au fur et à mesure de la maintenance. Le système Java peut donc être mis à jour exactement en même temps que le système original : il reste ainsi au même niveau fonctionnel tant que les 2 fonctionnent en parallèle. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 9 de 24
  10. 10. 2. continuité de l'évolution : le point précédent permet de continuer la maintenance et les évolutions du système au fil des contraintes réglementaires, des changements du métier, des nouveaux produits introduits sur le marchà, etc. C'est un critère très important lorsque la migration est appelée à durer longtemps pour des raisons de sécurité (incrémentalité maximale) ou de taille (forte échelle du projet). 3. fonctionnement parallèle collaboratif : l'application transcodée est connectée à la base de données de l'ancien système (via JDBC et DRDA) comme seule source de données. Cette base de données sert donc de pivot et de vecteur de collaboration entre le monde Java et celui du mainframe. Les résultats produits par l'ancien code et le nouveau code Java sont indiscernables. Il suffit donc que la base de données soit commune aux 2 systèmes pour que leurs utilisateurs y partagent le fruit de leur travail et donc collaborent en temps réel exactement comme ils le font dans le système original isolé : à travers les informations stockées. La base de données utilisée est donc celle du système original durant toute la migration des traitements. Quand cette phase est terminée et que l'arrêt total du système initial est visé, la base de données peut être migrée sur système ouvert. Si un système de messagerie asynchrone du type MQ Series, ou un outil similaire est utilisé, le serveur central reste sur z/OS durant la migration puis bascule vers Linux et JMS, selon le niveau d'utilisation de MQ, en fin de projet. 4. Incrémentalité de la migration : le point précédent permet une migration très incrémentale. Pour le système dans son ensemble, les résultats persistants en base de données d'un traitement sont les mêmes, qu'ils soient exécutés sur la version originale ou Java. Puisque la base de données est unique, il est donc indifférent qu'un traitement soit exécuté sur le mainframe ou sur son homologue Java. En conséquence, il est possible de déplacer individuellement chaque utilisateur interactif ou chaque étape de traitement d'un travail batch selon des contraintes ou objectifs qui peuvent être externes au projet de migration lui-même. La vitesse d'exécution du projet pourra donc être adaptée au contexte opérationnel du moment chez le client, afin d'en maximiser l'efficacité. 5. absence de risque : l'incrémentalité de la migration permet d'éliminer les risques car les utilisateurs ou traitements batch peuvent être transférés 1 par 1 sur le nouveau système. Tous les risques globaux d'une migration de type Big Bang sont ici totalement absents ! Il ne faut que quelques « pionniers » pour valider chaque composant migré : leur travail quotidien via ces nouveaux composants sert de validation sans perte de productivité puisque les pionniers sont connectés à la même base de données que leurs collègues encore sur l'ancien système. Ensuite, le « gros de la troupe » peut arriver par vagues successives de plus en plus importantes au fil de la prise de confiance sur le nouveau système. C'est la technique des « petits pas continus vers l'avant » : elle induit une certaine durée mais donne de bien meilleures garanties de succès ! 6. tests continus : le niveau de risque est encore abaissé par la mise à disposition d'un système de tests automatisés. En effet, l'iso-fonctionnalité permet en permanence de tester « mécaniquement » et automatiquement la validité du système. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 10 de 24
  11. 11. Des scénarios de référence capturés sur l'ancien système via 3270 peuvent être rejoués à la demande sur le système Java pour en comparer l'identité des résultats (tant au niveau de la base de données que des écrans). Il en est de même pour les traitements batchs. Le système mainframe sert donc de « spécifications live » tant qu'il existe et en comparaison duquel la validité du nouveau système Java peut être garantie en permanence. En conséquence, les mises en production mainframe + Java simultanées évoquées plus haut sont réalisées avec une garantie parfaite de qualité, d'ailleurs tant pour le système mainframe que pour le système Java. Ces tests unitaires qualitatifs sont également utilisés sous forme de tests de charge par exécution parallèle multiple afin de valider le bon comportement lors des pointes d'activité. 7. incréments et investissements minimaux : dans l'absolu, un seul et unique serveur x86 est nécessaire pour héberger les premiers traitements migrés. Le coût d'investissement pour le démarrage initial du projet est donc absolument minimum. De même, les serveurs correspondants à la croissance ultérieure du système pourront être acquis et mis en service de manière unitaire au fil des besoins. Ils peuvent bien sûr être strictement identiques aux modèles déjà standardisés par le client. Des instances Linux virtualisées dans le cadre d'un hyperviseur de virtualisation déjà en place chez le client sont également possibles. 8. maintenabilité : le code source Java généré à partir de l'application originale est destiné à être maintenu en tant que nouveau code source de référence à la fin du projet. Eranea a donc fait de gros investissements pour en assurer la lisibilité et la maintenabilité. De plus, d'importants investissements ont été également réalisés pour simplifier aussi la migration des développeurs vers leur nouveau patrimoine logiciel. Les algorithmes et structures syntaxiques sont préservés au maximum afin de leur « faciliter la vie » et de préserver toutes leurs compétences métier (finalement, le plus important de leurs savoirs !) dans du logiciel dont ils connaissent et maîtrisent parfaitement la structure. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 11 de 24
  12. 12. Eranea a donc fait le choix délibéré de favoriser la productivité des développeurs dans leur nouvel environnement et leur adhésion au projet plutôt que l'orthodoxie théorique du code généré. Il serait en effet contre-productif voire irréaliste et même dangereux de les « ensevelir » sous des millions de lignes de code source certes iso-fonctionnelles mais totalement restructurées et donc longues (voir impossibles) à assimiler dans le seul but de les rendre plus conformes aux formes canoniques de la programmation orientée-objet. 4.3. Technologie La technologie Eranea comporte 5 domaines : • Les composants de transcodage utilisés durant le projet tant que Java n'est pas intégralement devenu le nouveau langage de référence. • Le framework d'exécution utilisé durant et après le projet, aussi longtemps que le code Java maintenu fait appel à des méthodes d'iso-fonctionnalité et d'émulation livrées par ces librairies. • Un système d'intégration continue permettant l'automatisation complète du transcodage au déploiement multi-serveurs sur Cloud privé des nouvelles versions des applications. • Un framework et une application de monitoring / alerting temps-réel pour permettre aux équipes système / exploitation un suivi centralisé des multiples serveurs d'applications. • Les composants IDE : plugin Eclipse (ou autre IDE) permettant l'édition de l'application originale (si souhaité) et l'accès efficace aux fonctions de gestion du cycle de vie du logiciel. Eranea a développé en interne l'intégralité de sa technologie spécifique de transcodage, de développement, de déploiement, d'exécution, et de suivi des applications. Les librairies et composants tiers sur lesquelles elle s'appuie comptent parmi les plus grands standards de l'Open Source (Java JEE, Apache Commons, Jenkins, Subversion, etc.). Notre solution offre donc toutes les garanties nécessaires de qualité, de pérennité et d'évolutivité. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 12 de 24
  13. 13. 4.3.1. Transcodage système de transcodage Pour atteindre les avantages clefs décrits dans le paragraphe précédent, Eranea installe pour chaque projet son système de transcodage automatique au sein des infrastructures du client. Il se compose essentiellement : • d'un entrepôt logiciel basé sur Subversion et alimenté en continu depuis le mainframe par les évolutions du code applicatif original et du code Java résultant de son transcodage • d'un moteur d'intégration continue sur base Jenkins en charge de l'exécution de tous les travaux automatisés : 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 13 de 24
  14. 14. intégration continue : synoptique ◦ alimentation en code source à partir du mainframe puis stockage dans l'entrepôt logiciel, ◦ analyse structurelle /syntaxique et structuration du code source original, ◦ transcodage vers Java des programmes et copybooks applicatifs, vers XML pour les descriptions d'écrans (BMS, etc.) et JCLs, ◦ compilation du code Java produit, ◦ packaging Java : war, ear, etc. ◦ déploiement automatique sur les multiples niveaux systèmes de développement, tests d'intégration et production ◦ [selon l'organisation classique du monde mainframe, les étapes « transcodage » à « déploiement » sont en fait le plus souvent exécutées plusieurs fois en parallèle pour gérer des codes sources différents en fonction de leur niveau de validation dans les différents environnements du client (développement, intégration / recette, formation, production, etc.) • du système de capture et exécution automatisée des tests comparatifs 3270 <> html/ajax. Il est en fait intégré à NeaControlCenter (auparavant nommée Integrate - voir ci-dessous) pour sa partie interactive et déclenché par le moteur d'intégration continue pour sa partie batch. Ce système de capture est également utilisé pour la capture et le replay de tests de programmes batchs. • de la base de données relationnelles stockant tous les éléments précédents : ◦ rapports d'analyse et structuration du code original et du code Java : erreurs, suggestions d'améliorations du codage Cobol initial, etc. ◦ définition des tests et compte-rendus de leurs exécutions ◦ journaux de tous les travaux exécutés par le moteur d'intégration continue ◦ logs et informations diverses remontées des systèmes opérationnels • de l'application NeaControlCenter permettant : ◦ la consultation de la base de données contenant les informations précitées et le déclenchement manuel direct de certaines actions et traitements : transcodages, déploiements, etc. ◦ la consultation des données d'inventaire du client (liste des applications, programmes, copybooks, …) avec des fonctionnalités avancées de recherche par références croisées, taux de couverture par tests unitaires ou simplement full-text. La pratique habituelle consiste à héberger chaque composant Eranea (entrepôt logiciel, base de données, moteur d'intégration, application NeaControlCenter) sur une instance Linux séparée. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 14 de 24
  15. 15. 4.3.2. Framework d'exécution association transcodeur + runtime Plusieurs librairies composent le framework d'exécution NeaRuntime. Elles assurent toutes les fonctions d'iso-fonctionnalité (sémantiques du autre langage de programmation, APIs transactionnelle et batch, interface homme-machine) et d'émulation (moniteur transactionnel, interface homme- machine, fonctions batch, etc.) de l'environnement initial. Elles sont automatiquement insérées dans les paquetages Java (war, ear, etc.) correspondant aux applications transcodées fabriquées par le moteur d'intégration continue. Les JCL des programmes batch sont eux transcodés vers une structure XCL (format XML spécifique développé par Eranea) qui transpose iso-fonctionnellement les directives JCL originales. Ces structures XCL pour les différents travaux sont traitées par un interpréteur idoine pour assurer l'enchaînement des steps d'appels de programmes ou utilitaires tiers (SORT, etc.) selon les directives ou paramètres initiaux du JCL. L'ensemble de NeaRuntime est très fortement instrumenté au standard JMX pour donner accès à des centaines de métriques (valeurs instantanées, compteurs, états, etc.) concernant tous les objets actifs à l'exécution (programmes, zones mémoire, cpu, queues, terminaux, sessions, etc.) pour répliquer / dépasser le niveau de transparence des moniteurs transactionnels et batchs du mainframe. Toutes ces métriques peuvent être visualisées dans toute console compatible standard JMX (Zabbix, Centreon, etc.) pour être consultées en live ou historisées afin offrir aux équipes d'exploitation toute la transparence de fonctionnement dont elles peuvent avoir besoin. L'application NeaControlCenter utilise également toutes ces métriques pour répliquer en mode web tous les outils auxquels les exploitants sont habitués sur le mainframe. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 15 de 24
  16. 16. 4.3.3. Environnement de développement Un plugin Eclipse (ou autre IDE) est installé sur la station de travail des développeurs. Il étend les fonctions standard de l'IDE autour de Java afin de permettre de visualiser et éditer facilement le code source original Cobol durant et après le projet tant qu'il en est fait usage : Java doit devenir le nouveau langage de référence mais certains développeurs Cobol ont besoin d'un temps d'adaptation parfois supérieur à la durée du projet pour passer à Java. Le plugin leur permet donc de continuer à faire évoluer leurs programmes en Cobol et il les transforme « au vol » en Java. Java doit à terme devenir le langage de référence pour pouvoir faire un levier maximum sur le nouveau code source généré par les outils Eranea : toutes les fonctions spécifique à Java / JEE ne peuvent être intégrées que de cette manière. Ce plugin permet également un accès simplifié aux fonctions de gestion du cycle de vie du logiciel fournies par la plate-forme Eranea et / ou celle du client. 5. Architecture technique Eranea Cette section présente brièvement les divers composants de l'architecture technique standard proposée par Eranea. Elle permet de mieux cerner les contours de l'infrastructure matérielle et logicielle du système résultant d'une migration de mainframe vers x86. 5.1. Objectifs fonctionnels L'architecture technique mise en place délivre les mêmes garanties de service en termes de qualité de service (« Service Level Agreements » - SLAs - sur temps de réponse, débit global, disponibilité, reprise après désastre / catastrophe, etc.) que le système original. Les briques technologiques de base décrites ci-dessous sont combinées pour atteindre les exigences de ces SLAs. 5.2. Composants techniques 5.2.1. Serveurs x86 et stockage Eranea n'a pas de spécifications particulières pour le choix des fournisseurs de serveurs x86 (processeurs Intel Xeon) et du stockage. Elle peut s'appuyer sur les standards déjà en place chez le client. Concernant le stockage, il est cependant quasi-impératif qu'il soit centralisé sur un SAN commun à tous les serveurs du nouveau système afin de ne pas limiter les possibilités apportées en termes de haute disponibilité et de performances (migration inter-serveurs d'instances, cloning « live » d'instances, etc.) par les instances virtualisées sur l'hyperviseur. En complément, les couches de virtualisation propriétaire (VMWare) ou ouvertes (kvm) offrent toutes des fonctions nécessaires de tolérance aux pannes et haute disponibilité. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 16 de 24
  17. 17. Elles amènent une très forte activité de communication entre la machine hébergeant une instance sécurisée et celle hébergeant son clone de secours. En effet, tous les secteurs de disque et les zones mémoires modifiés sont transférés en temps réel vers l'autre machine de même que, par exemple, les informations sur les connexions TCP. Dans de telles situations, l'interconnexion entre les machines (switches de réseau local) ainsi que l'architecture d'accès au stockage permanent doivent être particulièrement disponibles et performantes. Le recours à des systèmes spécialisés (« engineered systems » - type IBM PureFlex, Cisco UCS ou Oracle ExaLogic) peut s'avérer nécessaire si des très forts débits sont à atteindre sur des instances critiques. Équivalence x86 <> processeurs propriétaires PowerPC, Sparc, etc Enfin, il est à noter, au vu du graphique ci-dessus que la puissance nominale des processeurs x86 est actuellement identique (voire supérieure) à celle des processeurs propriétaires (y.c les processeurs mainframe) qui, dans le passé, justifiaient leur prix plus élevé par une puissance supérieure. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 17 de 24
  18. 18. dominance de l'architecture x86 Intel et AMD disposent désormais d'une part de marché plus que dominante sur le marché des processeurs pour serveurs de tout type : bien au-delà des 2/3 en valeur (voir graphique ci-dessus) et encore bien davantage en nombre d'unités : 9'850'000 serveurs x86 par an contre 210'000 serveurs Risc et moins de 4'000 mainframes de type z/OS. Cette dominance très forte leur permet d'offrir la même puissance de calcul que leurs concurrents à un prix beaucoup plus faible. En effet, ils produisent un nombre de pièces très élevé dont le prix est de plus en plus défini par la quantité de R&D qu'elles incluent. Intel et AMD peuvent donc amortir cette R&D sur beaucoup plus d'unités et donc être imbattables en termes de ratio prix-performances. Les benchmarks de type TPC-C, par exemple, démontrent ceci sans ambiguïté. Ce processeur, qui est, par ailleurs, le seul utilisé dans les plus grandes infrastructures mondiales (Google, Facebook, Amazon, etc.), est clairement le meilleur choix du moment pour délivrer l'infrastructure la plus efficace possible en termes économiques. Ce processeur profite d'ailleurs du « bouillonnement innovateur » de ces grands systèmes pour s'améliorer en permanence par une collaboration étroite entre les clients et le fondeur de silicium. Tout ceci sans compter que le développement de l'architecture x86 est, en sus, mutualisé par son emploi décliné dans des versions adaptées sur d'autres plates-formes : PCs de bureaux, ordinateurs portables, etc. 5.2.2. Virtualisation Dans les comptes satisfaits par les outils qu'ils ont mis en place, Eranea utilise la virtualisation existante pour autant qu'elle permette de réaliser le niveau de service souhaité par le client en termes de haute disponibilité et de tolérance aux pannes. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 18 de 24
  19. 19. Dans les comptes « vierges » sur le sujet et recherchant des coûts optimaux, Eranea recommande une stratégie Open Source. Satisfaisant les critères précédents, c'est la plate-forme kvm (déclinée éventuellement en RedHat RHEL pour une version supportée ) qu'Eranea recommande pour un choix de virtualisation OSS dans un compte « vierge » de standard : l'appui architectural fort de kvm sur le noyau Linux en fait l'hyperviseur qui évolue le plus vite actuellement de part la taille de la communauté de développement du noyau, ce qui indirectement contribue de manière massive et continue aux performances et aux fonctionnalités de kvm. 5.2.3. Distribution Linux Dans le cas d'un cloud privé type CloudStack ou OpenStack, la distribution Linux est apportée par la solution globale. Dans une architecture plus traditionnelle, elle est choisie selon les principes suivants. Eranea utilise la distribution Linux en place chez ses clients. Pour ceux à la recherche d'une situation plus classique avec un fournisseur supportant officiellement ce système d'exploitation, Eranea recommande la distribution RHEL de Redhat : • Elle a obtenu, en termes de sécurité, la certification EAL4+ , niveau identique aux autres systèmes et plates-formes standards du marché (Solaris, AIX, VMWare, etc.). • Elle fait partie d'une suite d'outils Redhat (Satellite, etc.) qui permet une gestion efficace (configuration, patching, monitoring, etc.) de multiples instances. • Elle dispose d'un support commercial adapté aux grandes entreprises et possède des références prestigieuses dans ces entreprises. C'est la distribution leader du marché professionnel. • Elle permet d'avoir une bonne connexité avec le serveur Java AS si celui-ci est JBoss et donc de réduire le nombre de fournisseurs. Eranea n'a pas réellement de dépendance envers Linux pour le système cible : certains projets terminés fonctionnent sous MS-Windows qui est aussi la plate-forme quotidienne de travail d'une partie importante de nos développeurs. Des tests voire des projets ont également été faits sur Solaris, AIX et sur z/OS lui-même. La devise « Write Once, Run Anywhere » de Java est donc abondamment vérifiée et a été un critère décisif du choix exclusif de Java par Eranea. Cependant, il est clair que la prédominance de Linux dans le monde des serveurs d'entreprise s'accroît au fil des ans en tant que solution fortement éprouvée à très grande échelle et financièrement optimale. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 19 de 24
  20. 20. évolution du marché des systèmes d'exploitation Dans le cas d'environnements de grande échelle, le recours à Linux permet l'utilisation de composants système nécessaires à l'élaboration d'architectures apportant hautes performances, haute disponibilité et tolérance aux pannes. Elles s'appuient sur le serveur web Apache, ses extensions ainsi que des composants de type HAProxy, etc. qui permettent la construction de clusters très puissants et solides dans leurs couches basses. (voir ci-après) 5.2.4. Application Server (AS) Java Pour les projets transactionnels peu complexes, Eranea recommande Apache Tomcat. Par ailleurs, Eranea respecte les interfaces JEE : elle peut donc s'adapter à tout serveur d'application qui les respecte aussi et peut de toute façon adapter son code à un AS qui s'en écarterait. JBoss de Redhat, WebLogic d'Oracle et Websphere d'IBM sont 3 choix possibles. Pour les contextes favorables à l'Open Source et à l'efficacité financière résultante, Eranea recommande, pour la compatibilité JEE, la voie JBoss (version communautaire AS7 ou version supportée commercialement EAP-6 actuellement) de Redhat car elle offre : • une sophistication très élevée, allant jusqu'à compléter le standard JEE par ses propres solutions (cache-mémoire, communications multicast, gestion par domaine, etc.) dans les domaines où ce standard ne définit rien (haute disponibilité, etc.). Certaines de ces fonctions avancées (cache, load balancing, etc.) sont impératives pour les plus grands projets. • une garantie officielle de compatibilité JEE : Oracle a certifié JBoss AS7 comme « fully- compliant » au niveau 6 (le dernier) des spécifications du standard JEE. • un niveau de prix très bas : soit la gratuité totale pour la version communautaire, soit des redevances modestes pour la version commerciale (issue d'ailleurs de la version communautaire et très proche de celle-ci) 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 20 de 24
  21. 21. • un fournisseur identique à Linux (si RHEL est choisi par ailleurs) donc une simplification organisationnelle. 5.3. Architecture transactionnelle Dans le cadre de partitions z/OS indépendantes ou de paires de partitions couplées par Sysplex, le cluster de traitement décrit ci-après pourra en fait être réalisé à plusieurs exemplaires indépendants de plus faible échelle pour augmenter encore la flexibilité et l'efficacité économique du système résultant. Une infrastructure constituée de multiples serveurs x86 est donc pleinement justifiée. Ils doivent cependant être placés « au pied du mainframe » (i.e sur le même réseau local, avec un nombre minimum de hops et avec un fort débit LAN : > 1 Gbps) durant la migration afin que les accès aux données via JDBC / DRDA ne soient pas grevés par des temps d'aller-retour vers le mainframe trop longs. La bonne connectivité au mainframe doit permettre de rendre la durée de ces allers-retours sans impact : dans ses projets avec une infrastructure idoine, Eranea limite le temps réseau autour de 1 ms. Pour les transactions, les temps de réponse seront alors préservés. Pour les batchs, les mécanismes de prefetch vers DB2 au niveau des curseurs SQL annihileront l'impact de ces allers-retours d' « approvisionnement en données ». cluster de traitement multi-étages L'architecture proposée pour ce cluster de traitement est à 3 étages : • unification (1er étage) : un groupe très limité de machines (ou instances) pour unifier l'accès au cluster, visible finalement à travers une seule adresse IP. Cette adresse masque les étages supplémentaires, et donc leur sophistication ainsi que leur évolution au fil du temps. Équipé principalement de HAProxy associé au module VRRP, ces machines se surveillent 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 21 de 24
  22. 22. mutuellement pour recevoir et traiter les requêtes TCP de création de sessions http. Puis, elles passent les requêtes aux machines du 2ème étage du cluster selon des algorithmes très simples (round robin, nombre de sessions actives, etc.) après s'être assurées de leur présence. Ainsi, le nombre et la configuration réseau des machines de distribution et traitement du cluster peuvent évoluer librement sans qu'il soit nécessaire de reporter ces évolutions au niveau des machines des utilisateurs ou d'autres serveurs d'infrastructure (DNS, etc.). Si un tel dispositif existe déjà par ailleurs dans le système sous une forme de matériel spécialisé (type Cisco ACE ou équivalent chez F5, etc.), il pourra remplacer l'étage 1 du cluster. • distribution (2ème étage) : un ensemble de machines équipées d'Apache Web Server configuré avec des modules qui permettent un dialogue dynamique bidirectionnel avec les instances d'AS Java. Ces instances d'AS peuvent ainsi renseigner Apache sur leur charge en temps réel. Apache peut alors dispatcher les requêtes de transaction entrantes vers la machine la plus adaptée (i.e la moins chargée) après la satisfaction des autres contraintes (entité organisationnelle source, type de transaction, type de SLA, etc.). Cet étage peut aussi éventuellement prendre en charge l'authentification et les autorisations si l'architecture applicative le permet. Les machines du 3ème étage sont alors déchargées d'autant. Cet étage peut s'appuyer totalement ou partiellement sur les fonctions de haute disponibilité / tolérance aux pannes de la couche de virtualisation, ceci pour atteindre la satisfaction des niveaux de contraintes les plus élevés des divers SLAs. • traitement (3ème étage) : un ensemble de machines équipées de Java et de l'AS qui hébergent le code des applications transcodées et l'exécutent au fil des demandes utilisateurs. Les mécanismes de haute disponibilité / tolérance aux pannes au niveau Java AS sont combinés de manière idoine avec ceux offerts par la couche virtualisation (voir plus haut) pour satisfaire les divers niveaux de SLA. Ces configurations spécifiques par niveau de SLA peuvent conduire une forme de spécialisation des machines de l'étage 3. Cette spécialisation est connue de l'étage 2 pour dispatcher vers les bonnes machines selon les contraintes des activités demandées. L'ensemble de ces machines ne contient aucune donnée applicative spécifique. Elles sont donc très similaires dans leur configuration (selon les étages et les niveaux de SLA) et peuvent ainsi être gérées par des outils efficaces de pilotage /administration global au niveau des arrêts, démarrages, mises à jour logicielles, etc. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 22 de 24
  23. 23. 5.4. Architecture batch Elle est fondée sur 5 composants essentiels :  L'ordonnanceur batch (Control/M de BMC, par exemple, mais valide aussi pour Autosys, TWS, etc.) : il assure le séquencement des travaux selon la logique consignée dans le plan commun, ainsi que la centralisation des événements asynchrones (fin de jobs, apparition de fichiers, etc.) et la gestion du calendrier horaire pour déclencher les travaux pour lesquels toutes les conditions d'exécution sont réunies. Son architecture permet une exécution distribuée mais un contrôle centralisé des travaux s'exécutant sur les diverses plates-formes : un serveur central donne les ordres d'exécution des travaux aux agents situés sur les diverses machines. Les rapports d'exécution et le suivi des performances sont ensuite centralisés sur le serveur central depuis lequel l'ensemble du suivi / administration du système, à travers une interface utilisateur riche, peut être réalisé sans inefficacité particulière due au nombre de machines impliquées. Il permet également une bonne coordination / synchronisation des chaînes de traitement incluant des travaux s'exécutant successivement sur les différentes plates-formes : les conditions « OUT » générées par certains jobs qui deviennent les conditions « IN » des jobs dépendants sont répercutées en transparence par l'ordonnanceur d'un environnement à l'autre (z/OS <> Linux). De même, dans le cadre d'une architecture x86 où le nombre de machines physiques / d'instances est multiplié, les travaux sur chacune d'elles sont coordonnés strictement par un accès global efficace à ces conditions.  Les exécuteurs batch : sous le contrôle de leur agent piloté par l'ordonnanceur central, ces exécuteurs déroulent les scripts XCL et exécutent les chaînes de traitement applicatif par 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 23 de 24
  24. 24. l’enchaînement des appels aux programmes applicatifs et utilitaires tiers selon les sollicitations du plan d'ordonnancement central.  Le système de gestion de bases de données DB2 d’IBM qui reste le seul gestionnaire de base de données. Il est accessible directement depuis les nouveaux composants x86/Linux/Java : infrastructure de tests applicatifs, serveurs d’applications opérationnels, postes de développement. Au niveau de ces systèmes, la connectivité à DB2 est vue sous forme JDBC depuis les composants JAVA. Elle est ensuite effectivement assurée par un lien DRDA vers le mainframe.  Le serveur NFS de partage des fichiers : il offre à toutes les instances de Linux, amenées à utiliser des fichiers séquentiels, un accès partagé et uniforme aux fichiers permanents utilisés par le système du client. Il s'appuie sur le SAN (existant ou futur) pour stocker effectivement ces données et en assurer la sauvegarde (backup), ainsi que le mirroring synchrone si il est nécessaire aux niveaux de services garantis formellement aux utilisateurs. Il peut être associé aux services HFS de z/OS qui rendent accessibles sur le même mode des fichiers qui doivent encore être partagés entre z/OS et Linux.  Les machines (instances) délivrant les éventuels services complémentaires indispensables : pilotage des sorties, impressions effectives, envoi de mails, etc. Ces services sont accessibles par toutes les machines exécutant les diverses chaînes en batch. 02 juillet 2015 © 2015 Eranea – http://www.eranea.com Page 24 de 24

×