Stratégies de migration d’applications d’un environnement mainframe

Quand la plupart des équipes migrent des applications d’environnements mainframe vers Azure, elles suivent généralement une approche pragmatique : réutiliser partout et quand c’est possible. Ensuite, elles démarrent un déploiement par phases où les applications sont réécrites ou remplacées.

La migration d’applications engage généralement une ou plusieurs des stratégies suivantes :

• Réhéberger : Déplacez du code, des programmes et des applications existants depuis le mainframe. Recompiler le code à exécuter dans un émulateur de mainframe qui est hébergé dans une instance cloud. En règle générale, avec cette approche, vous commencez par déplacer les applications vers un émulateur dans le cloud, puis vous migrez la base de données vers une base de données dans le cloud. Certaines opérations d’ingénierie et de refactorisation sont nécessaires avec cette stratégie ainsi que des conversions de données et de fichiers.

  Vous pouvez aussi faire appel à un fournisseur d’hébergement traditionnel. L’un des avantages majeurs du cloud est l’externalisation de la gestion de l’infrastructure. Recherchez un fournisseur de centre de données qui va héberger vos charges de travail de mainframe pour vous. Ce modèle peut vous faire gagner du temps, réduire votre dépendance à l’égard des fournisseurs et diminuer vos coûts intermédiaires.

• Mettre hors service : Mettez hors service les applications qui ne sont plus nécessaires avant la migration.

• Regénération : certaines organisations choisissent de réécrire entièrement les programmes à l’aide de techniques modernes. Cette approche est moins courante que l’approche lift-and-shift, car elle s’avère plus chère et plus complexe. Après ce type de migration, il est souvent judicieux de commencer à remplacer des modules et du code en s’aidant de moteurs de transformation de code.

• Remplacement : cette approche remplace les fonctionnalités du mainframe par des options équivalentes dans le cloud. SaaS (Software as a Service) est une option. Avec SaaS, vous utilisez une solution créée spécifiquement pour répondre à un besoin de l’entreprise, comme les finances, les ressources humaines, la fabrication ou la planification des ressources de l’entreprise. En outre, il existe maintenant de nombreuses applications métier capables de résoudre des problématiques qui étaient gérées par des solutions mainframe personnalisées.

Commencez par planifier les charges de travail que vous voulez migrer en priorité, puis déterminez les exigences pour déplacer les applications, les bases de code héritées et les bases de données héritées.

Émulation de mainframe dans Azure

Les services Azure peuvent émuler des environnements mainframe traditionnels. Vous pouvez ensuite réutiliser le code et les applications mainframe existants. Vous pouvez émuler des composants serveur courants, comme les systèmes de traitement transactionnel en ligne (OLTP), de traitement par lots et d’ingestion des données.

Systèmes OLTP

Beaucoup d’environnements mainframe ont des systèmes OLTP qui traitent des milliers ou des millions de mises à jour pour de grands nombres utilisateurs. Ces applications utilisent souvent des logiciels de traitement transactionnel et de gestion des formulaires/de l’écran, tels qu’un système de contrôle des informations client (CICS), un système de gestion des informations (IMS) et un processeur d’interface de terminal (TIP).

Quand vous déplacez des applications OLTP vers Azure, des émulateurs pour les moniteurs de traitement transactionnel de mainframe peuvent s’exécuter en tant que service IaaS (Infrastructure as a Service)en utilisant des machines virtuelles sur Azure. Les serveurs web peuvent également implémenter la gestion de l’écran et les fonctionnalités des formulaires. Combinez cette approche avec des API de base de données, comme ADO (ActiveX Data Objects), ODBC (Open Database Connectivity) et JDBC (Java Database Connectivity) pour l’accès aux données et les transactions.

Mises à jour par lots avec des contraintes de temps

Beaucoup de systèmes mainframe effectuent mensuellement ou annuellement les mises à jour de millions d’enregistrements de compte, en particulier ceux utilisés dans les banques, les compagnies d’assurance et les organismes publics. Les ordinateurs mainframe gèrent ces types de charges de travail en offrant des systèmes de gestion des données à haut débit. Les traitements par lots sur ces mainframes s’effectuent généralement en série par nature et leurs performances dépendent du débit d’IOPS (entrées/sorties par seconde) assuré par le backbone du mainframe.

Les environnements de traitement par lots dans le cloud utilisent le calcul parallèle et des réseaux à haut débit pour améliorer les performances. Azure propose plusieurs options de calcul, de stockage et de mise en réseau qui vous aident à optimiser les performances du traitement par lots.

Systèmes d’ingestion des données

Les ordinateurs mainframe ingèrent de grandes quantités de données qui leur sont transmises pour traitement par les solutions des services commerciaux, financiers, de fabrication, etc. Avec Azure, vous pouvez utiliser des utilitaires en ligne de commande simples, comme AzCopy, pour copier des données vers et depuis un emplacement de stockage. Vous pouvez aussi utiliser le service Azure Data Factory, pour ingérer des données provenant de magasins de données disparates, et pour créer et planifier des workflows basés sur des données.

En plus des environnements d’émulation, Azure fournit des services PaaS (platform as a service) et d’analytique qui contribuent à optimiser les environnements mainframe existants.

Migrer des charges de travail OLTP vers Azure

L’approche lift-and-shift est l’option sans code qui vous permet de migrer rapidement des applications existantes vers Azure. Chaque application migre telle quelle, ce qui offre les avantages du cloud sans les risques ni les coûts liés aux modifications de code. Cette approche est possible quand vous utilisez un émulateur pour les moniteurs TP de mainframe sur Azure.

Les moniteurs TP sont proposés par différents fournisseurs et s’exécutent sur des machines virtuelles, une option IaaS (infrastructure as a service) disponible sur Azure. Les diagrammes suivants montrent la situation avant et après d’une application en ligne adossée au système IBM DB2 (un SGBD) sur un mainframe IBM z/OS. Le système DB2 pour z/OS utilise des fichiers VSAM (Virtual Storage Access Method) pour stocker les données et ISAM (Indexed Sequential Access Method) pour les fichiers plats. Cette architecture utilise également le système CICS pour la supervision des transactions.

Sur Azure, les environnements d’émulation exécutent le gestionnaire de traitement transactionnel et les travaux par lots qui utilisent JCL. Dans la couche Données, DB2 est remplacé par Azure SQL Database, mais vous pouvez aussi utiliser Microsoft SQL Server, DB2 LUW ou Oracle Database. Un émulateur prend en charge IMS, VSAM et SEQ. Les outils de gestion du système mainframe sont remplacés par des services Azure et par des logiciels d’autres fournisseurs, qui s’exécutent sur des machines virtuelles.

Les serveurs web implémentent couramment les fonctionnalités de gestion de l’écran et de saisie de formulaires, que vous pouvez combiner avec des API de base de données, comme ADO, ODBC et JDBC pour l’accès aux données et les transactions. Le choix exact des composants IaaS Azure à utiliser dépend de votre système d’exploitation. Par exemple :

• Machines virtuelles Windows : Internet Information Server (IIS) avec ASP.NET pour la gestion de l’écran et la logique métier. Utilisez ADO.NET pour les transactions et l’accès aux données.

• Machines virtuelles Linux : des serveurs d’applications basés sur Java, par exemple Apache Tomcat, traitent la gestion de l’écran et les fonctionnalités métier basées sur Java. Utilisez JDBC pour les transactions et l’accès aux données.

Migrer des charges de travail par lots vers Azure

Les opérations par lots dans Azure diffèrent de l’environnement de traitement par lots classique sur les ordinateurs mainframe. Les traitements par lots sur ces ordinateurs s’effectuent généralement en série par nature et leur performance dépend du débit IOPS assuré par le mainframe principal. Les environnements de traitement par lots dans le cloud utilisent le calcul parallèle et des réseaux à haut débit pour améliorer les performances.

Pour optimiser les performances des traitements par lots à l’aide d’Azure, vous pouvez utiliser les options de calcul, de stockage, de mise en réseau et de supervision comme suit.

Calcul

Utilisez :

• Utilisez des machines virtuelles avec la fréquence d’horloge la plus élevée. Les applications mainframe sont souvent monothread et les processeurs des mainframes ont une fréquence d’horloge élevée.

• Utilisez des machines virtuelles avec une grande capacité de mémoire pour permettre la mise en cache des données et des applications des zones de travail.

• Utilisez des machines virtuelles avec des processeurs virtuels à très haute densité pour tirer pleinement parti du traitement multithread, si l’application prend en charge les threads multiples.

• Utilisez le traitement parallèle (Azure facilite le scale-out pour ce type de traitement) afin d’augmenter la puissance de calcul disponible au moment d’un traitement par lots.

Stockage

Utilisez :

• Utilisez des SSD Premium Azure ou des Disques Ultra Azure pour bénéficier du débit IOPS maximal.

• Utilisez l’entrelacement sur plusieurs disques pour augmenter le débit IOPS par taille de stockage.

• Partitionnez le stockage afin de répartir les E/S entre plusieurs dispositifs de stockage Azure.

Mise en réseau

• Activez l’accélération réseau Azure pour réduire la latence.

Surveillance

• Utilisez des outils de supervision, comme Azure Monitor, Application Insights et les journaux Azure. Ces outils vous aident à superviser les exécutions par lots trop performantes et à réduire les goulots d’étranglement.

Migrer des environnements de développement

Les architectures distribuées du cloud s’appuient sur différents ensembles d’outils de développement qui offrent les avantages des pratiques et des langages de programmation modernes. Pour faciliter cette transition, utilisez un environnement de développement avec d’autres outils conçus pour émuler les environnements IBM z/OS. La liste suivante présente les options proposées par Microsoft et d’autres fournisseurs :

Migrer des données et des bases de données

La migration d’application implique généralement le réhébergement de la couche Données. Vous pouvez migrer facilement des bases de données SQL Server, open source et d’autres bases de données relationnelles vers des solutions entièrement managées sur Azure. Vous pouvez utiliser Azure SQL Managed Instance, Azure Database pour PostgreSQL et Azure Database pour MySQL avec Azure Database Migration Service.

Par exemple, vous pouvez effectuer la migration si la couche Données de mainframe utilise :

• IBM DB2 ou une base de données IMS. Utilisez Azure SQL Database, SQL Server, DB2 LUW ou Oracle Database sur Azure.

• Des fichiers VSAM et autres fichiers plats. Utilisez des fichiers plats ISAM (Indexed Sequential Access Method) pour Azure SQL Database, SQL Server, DB2 LUW ou Oracle.

• Des groupes de données de génération (GDG). Migrez vers des fichiers sur Azure qui utilisent une convention de nommage et des extensions de noms de fichiers offrant les mêmes fonctionnalités que les GDG.

La couche Données IBM comprend plusieurs composants clés que vous devez également migrer. Par exemple, quand vous migrez une base de données, vous migrez en même temps une collection de données stockées dans des pools, chacun d’eux contenant des dbextents, qui sont des jeux de données VSAM z/OS. Votre migration doit inclure le répertoire qui identifie les emplacements des données dans les pools de stockage. De plus, votre plan de migration doit prendre en compte le journal de base de données, qui contient un enregistrement des opérations effectuées sur la base de données. Une base de données peut avoir un, deux (double ou autre) ou quatre journaux (doubles et autres).

La migration de la base de données inclut également les composants ci-dessous :

• Gestionnaire de base de données : il fournit l’accès aux données dans la base de données. Le gestionnaire de base de données s’exécute dans sa propre partition dans un environnement z/OS.
• Demandeur d’applications : il accepte les demandes des applications avant de les passer à un serveur d’applications.
• Adaptateur de ressources en ligne : il inclut les composants du demandeur d’applications à utiliser dans les transactions CICS.
• Adaptateur de ressources par lots : il implémente les composants du demandeur d’applications pour les applications par lots dans z/OS.
• Interactive SQL (ISQL) : s’exécute comme une application et une interface CICS, et permet aux utilisateurs d’entrer des instructions SQL ou des commandes d’opérateur.
• Application CICS : elle s’exécute sous le contrôle de CICS, en utilisant les sources de données et les ressources disponibles dans CICS.
• Application par lots : elle exécute un processus logique sans communication interactive avec les utilisateurs pour produire des mises à jour de données en bloc ou générer des rapports à partir d’une base de données, par exemple.

Optimiser la mise à l’échelle et le débit pour Azure

D’une manière générale, les systèmes mainframe effectuent un scale-up, tandis que le cloud effectue un scale-out. Pour optimiser la mise à l’échelle et le débit des applications de style mainframe qui s’exécutent sur Azure, il est important de bien comprendre comment les mainframes peuvent séparer et isoler les applications. Un système mainframe z/OS utilise une fonctionnalité de partitions logiques appelée LPAR pour isoler et gérer les ressources dont a besoin une application spécifique sur une instance unique.

Un mainframe peut utiliser une partition logique pour une région CICS et les programmes COBOL associés, et une partition LPAR distincte pour DB2. D’autres partitions LPAR sont souvent utilisées pour les environnements de développement, de test et de préproduction.

Sur Azure, il est plus courant d’utiliser des machines virtuelles séparées à la place. Une architecture Azure déploie généralement des machines virtuelles pour la couche Application, un groupe séparé de machines virtuelles pour la couche Données, un autre groupe pour le développement, et ainsi de suite. Vous pouvez optimiser chaque niveau de traitement en utilisant le type de machines virtuelles et les fonctionnalités les plus adaptés à l’environnement existant.

De plus, chaque niveau peut fournir des services de reprise d’activité après sinistre. Par exemple, les machines virtuelles de base de données et de production peuvent nécessiter une reprise d’activité à chaud, alors que les machines virtuelles de développement et de test prennent en charge une reprise d’activité à froid.

La figure suivante illustre un déploiement Azure possible avec un site principal et un site secondaire. Dans le site principal, les machines virtuelles de test, de préproduction et de production sont déployées avec une haute disponibilité. Le site secondaire est utilisé pour la sauvegarde et pour la reprise d’activité après sinistre.

Effectuer une migration par étapes vers Azure

Le déplacement de solutions d’un mainframe vers Azure peut impliquer une migration intermédiaire. Vous déplacez d’abord certaines applications, tandis que d’autres restent temporairement ou définitivement sur le mainframe. Cette approche nécessite généralement des systèmes qui permettent aux applications et aux bases de données d’interagir entre le mainframe et Azure.

Un scénario courant consiste à déplacer une application vers Azure, mais en conservant sur l’ordinateur mainframe toutes les données dont a besoin l’application. Un logiciel spécifique permet aux applications sur Azure d’accéder aux données à partir du mainframe. Heureusement, il existe un large éventail de solutions qui permettent l’intégration entre Azure et les environnements mainframe existants, la prise en charge de scénarios hybrides et la migration progressive. Les partenaires Microsoft, les éditeurs de logiciels indépendants et les intégrateurs système peuvent vous aider dans votre démarche.

Une option est Microsoft Host Integration Server. Cette solution fournit l’architecture de base de données relationnelle distribuée (DRDA) nécessaire pour les applications dans Azure. Elle permet aux applications d’accéder aux données de DB2 qui restent sur le mainframe. Il existe d’autres options pour l’intégration entre les environnements mainframe et Azure, parmi lesquelles les solutions fournies par IBM, Attunity et Codit, ainsi que des solutions open source.

Solutions de partenaires

Si vous envisagez une migration de mainframe, l’écosystème partenaire peut vous aider.

Azure fournit une infrastructure fiable, hautement disponible et évolutive pour les systèmes qui s’exécutent sur des ordinateurs mainframe. Certaines charges de travail peuvent migrer assez facilement. Vous pouvez réhéberger d’autres charges de travail qui dépendent de logiciels système hérités, comme CICS et IMS. Utilisez des solutions de partenaires et migrez-les vers Azure au fil du temps. Quel que soit votre choix, Microsoft et ses partenaires peuvent vous aider à optimiser votre environnement pour Azure tout en maintenant le même niveau de fonctionnalités logicielles de votre système mainframe.

En savoir plus

Pour plus d’informations, consultez les ressources suivantes :

• Prise en main d’Azure

• Déployer IBM DB2 pureScale sur Azure

• Documentation Host Integration Server