Réhéberger une base de données IMS et des communications de données IMS sur Azure à l’aide de Raincode IMSql

Cette architecture explique comment implémenter une charge de travail d’application mainframe IMS (Information Management System) sur Azure à l’aide de Raincode IMSql. Il est plus complexe de migrer une application de base de données IMS (DB) vers une solution native cloud que de migrer une application de base de données relationnelle. Cet article explique comment réhéberger sur Azure une charge de travail IMS s’exécutant sur un mainframe et reposant sur des fonctionnalités et capacités IMS critiques. Vous n’avez pas besoin de traduire ou de modifier votre application existante.

Architecture des charges de travail IMS DB et IMS Data Communications avant migration

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. Les utilisateurs se connectent au mainframe via TCP/IP à l’aide de protocoles mainframe standard tels que TN3270 et HTTPS.

2. Les gestionnaires de transactions interagissent avec les utilisateurs et appellent l’application pour satisfaire les demandes des utilisateurs.

3. Les utilisateurs interagissent avec des écrans IMS ou des pages Web au niveau du front-end de la couche applicative.

4. Le code d’application utilise les capacités de stockage de la couche de données back-end hiérarchique IMS DB.

5. Les traitements par lots effectuent des opérations sur des mégadonnées hors ligne.

6. Outre le traitement des transactions, d’autres services fournissent l’authentification, la sécurité, la gestion, la surveillance et la création de rapports. Ces services interagissent avec d’autres services système.

Architecture IMSql sur Azure

Téléchargez un fichier Visio de cette architecture.

Flux de travail

Le workflow suivant correspond au diagramme précédent :

1. Serveur de terminaux IMSql

   Traditionnellement, les utilisateurs locaux accèdent à l’interface mainframe z/OS à l’aide d’un terminal INTERNE IBM ou d’un logiciel d’émulation de terminal. Une application qui a un réseau géographiquement dispersé avec des milliers d’utilisateurs se connecte au mainframe à l’aide d’un terminal. Si vous réhébergez une application IMS Data Communications (DC) sur un système cloud distribué, vous devez héberger de manière centralisée l’application et la ressource et les publier pour les appareils clients distants. Pour héberger et publier l’application et la ressource sur Azure, utilisez des serveurs terminal IMSql.

2. Broker de service SQL Server

   Dans le mainframe, IMS DC transmet et traite les messages dans une région de contrôle pour orchestrer la couche de communication entre les terminaux utilisateur et les programmes d’application. Après le réhébergement, le broker de service SQL Server orchestre cette couche de communication asynchrone. Ce répartiteur de services prend en charge la communication via son infrastructure de remise de messages et effectue un scale-out des messages pour séparer les serveurs de traitement, les utilisateurs actuels et leur traitement des transactions.

3. Serveur de traitement IMSql

   Le serveur de traitement exécute le code recompilé Raincode pour les programmes IMS dans .NET Framework ou .NET. Le serveur contient l’infrastructure sous-jacente afin que les programmes recompilés s’exécutent efficacement et avec une équivalence fonctionnelle correcte. Le serveur de traitement IMSql peut générer des requêtes dynamiques et appeler des procédures stockées dans SQL Server créées pendant la recompilation d’appel data Language/One (DL/I).

4. SQL Server en tant que magasin de données hiérarchique

   Les données sont stockées hiérarchiquement dans IMS. IMSql utilise le même modèle sur SQL Server. Ce modèle utilise des bases de données relationnelles hautes performances pour implémenter logiquement des segments hiérarchiques à partir de IMS. Le modèle prend en charge la mise à l’échelle indépendante avec des segments. Les données de segment sont stockées au format EBCDIC brut afin qu’elles ne nécessitent pas de conversion pour l’application. En utilisant la plateforme SQL en tant que service (PaaS), IMSql peut tirer parti des fonctionnalités sous-jacentes de haute disponibilité et de récupération d’urgence fournies par Azure.

5. API d’appel DL/I

   L’API IMSql traduit les appels COBOL IMS DL/I en requêtes SQL équivalentes. L’API récupère les données et les retourne au programme d’application au format attendu. IMSql suit la position du programme sur l’enregistrement de table pour effectuer des opérations de création, de lecture, de mise à jour et de suppression comme la base de données hiérarchique. Pour répondre aux appels DL/I gourmands en performances, IMSql peut créer des procédures stockées dans SQL Server pendant la compilation.

6. Raincode JCL

   Raincode job control language (JCL) est un interpréteur compatible Z/OS JCL. Raincode JCL lisse la transition de la logique métier complexe incorporée dans JCL aux plateformes Azure et .NET. Raincode JCL exécute le code compilé par les compilateurs Raincode COBOL, PL/I et ASM370. Raincode JCL exécute les étapes écrites dans la plupart des langages. Implémentez le code écrit par l’utilisateur pour le configurer et l’adapter à la planification par lots sur mesure.

7. Vue des données IMSql

   IMSql définit des vues SQL relationnelles à partir de copybooks ou de structures d’enregistrement afin que les services Azure et les nouvelles applications puissent accéder aux segments IMS au moyen de simples instructions SQL. Les vues IMSql sont accessibles en écriture, de sorte que les applications modernes peuvent lire et écrire dans IMS via SQL Server.

Migration des données via IMSql

Migration d’objets de base de données

• IMSql extrait et transfère la description de base de données IMS d’origine (DBD) à partir du mainframe. IMSql utilise des informations DBD pour produire des scripts SQL pour générer une base de données et des tables cibles dans Azure SQL.

• Chaque segment d’un DBD IMS est traduit sous forme de table dans Azure.

• Les tableaux incluent un champ clé, des champs de recherche et des données de segment IMS représentées dans EBCDIC.

• Les tables Azure SQL conservent la structure arborescente des segments IMS et les relations entre clés primaires et étrangères.

Chargement initial des données

• Les données de la base de données IMS sont extraites au moyen d’un job sur mainframe et d’utilitaires de téléchargement tels que DFSRRC00 et DFSURGL0.

• Vous pouvez transférer des fichiers binaires extraits vers des Azure à l’aide de connecteurs Azure Data Factory, tels que FTP et SECURE FTP (SFTP) et une solution Java qui s’exécute sur les services de sous-système Unix.

• IMSql dispose d’un utilitaire de chargement intégré pour effectuer les chargements de données initiaux. Cet outil utilise l’utilitaire bcp (Bulk Copy Program) SQL Server. L’outil garantit que bcp s’exécute et vérifie que l’intégrité référentielle entre les tables correspond à la structure hiérarchique attendue.

• Cette migration traite d’une charge de données unique à partir de la base de données IMS, mais elle ne traite pas de la coexistence et de la synchronisation des données associée.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. La base de données IMS contient le DBD et les données de segment.

2. Les utilitaires IBM extraient et déchargent les informations de base de données IMS.

3. Le fichier DBD et les fichiers de données binaires correspondants sont générés séparément.

4. Les étapes suivantes décrivent le processus d’ingestion des données :

   1. Le connecteur FTP d'Azure Data Factory copie les jeux de données IMS mainframe dans le stockage de données Azure.

   2. Les fichiers de données IMS mainframe sont copiés dans Azure Blob par SFTP.

   3. Mainframe JCL exécute une solution de Java personnalisée qui déplace les données entre le système mainframe et le Stockage Blob SFTP.

5. IMSql crée la base de données et les tables cibles, et gère l’intégrité référentielle à l’aide du fichier DBD.

6. IMSql charge les objets de données créés dans les tables correspondantes dans l’ordre séquentiel.

7. Azure SQL Managed Instance héberge des données IMS migrées.

8. La base de données d’application contient les données de segment brutes utilisées pour le traitement imS en ligne et le traitement par lots.

9. Les vues de lecture et d'écriture d'IMS contiennent des données de segment dont la taille s'étend en fonction de la disposition du copybook.

Migrer les données de base de données IMS à l’aide de Raincode zBridge

Raincode zBridge facilite l’accès aux données non relationnelles de mainframe sur Azure, y compris les données des segments de base de données IMS. Vous pouvez accéder à ces données dans Azure SQL bases de données pour les applications distribuées et à des fins de création de rapports et d’analyse.

Importez des fichiers de données de segment IMS dans zBridge en utilisant un copybook COBOL correspondant ou une instruction INCLUDE PL/I. Les données apparaissent sous forme de lignes SQL qui convertissent les types numériques mainframe en types SQL et qui convertissent les chaînes en ASCII si nécessaire. zBridge prend également en charge des structures de données complexes.

Composants

• Azure Logic Apps est une plateforme cloud pour des solutions d’intégration puissantes. Les utilisateurs mainframe familiarisés avec les terminaux 3270 et la connectivité locale peuvent utiliser le connecteur Logic Apps IBM 3270 pour accéder aux applications mainframe IBM et les exécuter. Dans cette architecture, Logic Apps prend en charge l’interaction mainframe avec les applications Azure migrées à l’aide de l’Internet public ou d’une connexion privée Azure ExpressRoute qui utilise Microsoft Entra ID pour l’authentification.

• Groupes de machines virtuelles identiques Azure est un service de calcul qui fournit une mise à l’échelle de machine virtuelle à charge équilibrée et automatisée qui simplifie la gestion des applications et augmente la disponibilité. Dans cette architecture, Virtual Machine Scale Sets fournit suffisamment de machines virtuelles pour les besoins de traitement en ligne et par lots de la charge de travail IMSql.

• Réseau virtuel Azure prend en charge la communication sécurisée entre les ressources Azure, telles que les machines virtuelles Azure et les réseaux Internet et locaux. Réseau virtuel est comme un réseau traditionnel que vous utilisez dans votre propre centre de données, mais il fournit la mise à l’échelle, la disponibilité et l’isolation de l’infrastructure Azure. Dans cette architecture, Réseau virtuel fournit une base réseau sécurisée pour une communication efficace entre les composants IMSql.

• ExpressRoute est un service de connectivité qui étend vos réseaux locaux dans le Microsoft Cloud via une connexion privée facilitée par un fournisseur de connectivité. Vous pouvez utiliser ExpressRoute pour établir des connexions aux services cloud Microsoft tels qu’Azure et Microsoft 365. Dans cette architecture, ExpressRoute fournit une connectivité sécurisée et à bande passante élevée entre les environnements mainframe locaux et les applications IMS migrées qui s’exécutent sur Azure.

• Microsoft Entra ID est un service de gestion des identités et des accès d’entreprise basé sur le cloud. Dans cette architecture, Microsoft Entra ID protège contre les attaques de cybersécurité et fournit l’authentification unique et l’authentification multifacteur pour aider les utilisateurs à se connecter et à accéder aux ressources.

• SQL Managed Instance fournit une instance de SQL Server entièrement managée dans Azure. Dans cette architecture, SQL Managed Instance fournit la plateforme de base de données relationnelle pour les structures de données de base de données IMS hiérarchiques converties avec une haute disponibilité et une intégration de service Azure.

Alternatives

• Vous pouvez utiliser SQL Server dans une machine virtuelle Azure au lieu de SQL Managed Instance. Nous vous recommandons de SQL Managed Instance en raison de sa haute disponibilité, de son intégration aux services Azure et de la gestion des correctifs de sécurité et de la maintenance.

• Vous pouvez utiliser une architecture de machine virtuelle unique Azure au lieu de Virtual Machine Scale Sets. Tenez compte des machines virtuelles uniques pour les charges de travail qui ont des exigences de charge et de performances constantes et qui ne nécessitent pas de mise à l’échelle. Cette architecture utilise Virtual Machine Scale Sets pour gérer les charges de travail IMS classiques.

Détails du scénario

Les systèmes OLTP (Mainframe Online Transaction Processing) peuvent traiter des millions de transactions pour de nombreux utilisateurs. IBM IMS est un gestionnaire de transactions mainframe classique pour OLTP. IBM IMS comprend IMS DC, le gestionnaire de transactions et la base de données IMS, le système de gestion de base de données hiérarchique sous-jacent (SGBD).

IMSql fournit un hébergement de charge de travail basé sur IMS sur des implémentations distribuées Azure et locales, basées sur des SQL Server. IMSql fournit une solution holistique pour les charges de travail IMS, notamment les composants de l’application, des données et des intergiciels. IMSql peut ingérer des structures de données de base de données IMS hiérarchiques dans un modèle de données relationnelle dans SQL Server, SQL Server sur les machines virtuelles Azure et SQL Managed Instance. Il dispose d’API intégrées pour les appels DL/I du programme d’application IMS et étend la couche de données au-delà des charges de travail hiérarchiques aux applications natives cloud pour les données relationnelles.

Cette solution :

• Modernise l’infrastructure et réduit les coûts élevés, les limitations ainsi que le manque de flexibilité des charges de travail IMS monolithiques sur mainframe.

• Implémente des solutions natives cloud et DevOps pour réduire la dette technique.

• Envoie des données de base de données IMS aux applications basées sur le cloud qui n’utilisent pas de mainframes, y compris les applications IA et d’analytique.

Cas d’usage potentiels

Cette solution peut être utile pour :

• Banque, finance, assurance, gouvernement et commerce de détail qui utilisent Mainframe IMS. La plupart de ces organisations exécutent leurs applications OLTP et batch principales sur la base de données IMS et le contrôleur de domaine IMS.

• Clients mainframe IBM zSeries qui doivent migrer des applications critiques pour l’entreprise. Ces clients souhaitent souvent maintenir la continuité avec d’autres applications locales et éviter les effets d’un redéploiement complet.

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

• Nithish Aruldoss | Architecte Ingénierie
• Améthyste Salomon | Architecte ingénieur principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Copier des fichiers du mainframe vers Azure Data Factory à l’aide du connecteur FTP
• Transfert de fichiers mainframe vers le stockage Blob à l’aide de SFTP
• Qu’est-ce que le réseau virtuel ?
• Qu’est-ce qu’ExpressRoute ?
• Documentation Microsoft Fabric

Ressources associées

• Refactorisation générale de mainframe vers Azure
• Réorganiser des applications de traitement par lots mainframe sur Azure