Partager via


Migrer des charges de travail OLTP IBM z/OS vers Azure

Azure Front Door
Azure Traffic Manager
Azure Kubernetes Service (AKS)
Azure Spring Apps
Cache Azure pour Redis

Les systèmes de traitement des transactions en ligne (OLTP) sont le visage de votre entreprise car ils interagissent directement avec les clients. En migrant vers une infrastructure adaptable dynamiquement, votre entreprise peut créer et lancer des produits rapidement afin que les clients puissent utiliser vos produits plus tôt.

Architecture

Le diagramme suivant illustre l’architecture d’un système OLTP qui s’exécute sur un mainframe z/OS avant la migration vers Azure :

Schéma d’une architecture OLTP sur z/OS.

Le diagramme montre l’architecture d’une application OLTP qui s’exécute sur un mainframe z/OS. Un utilisateur local accède au système via une interface Web et se connecte via divers protocoles de communication tels que HTTPS, SNA LU 6.2 et Telnet 3270. Le système est divisé en plusieurs couches qui sont représentées par des cases numérotées. Des flèches relient les boîtes pour montrer comment les différents composants interagissent dans l’environnement mainframe. La case numéro un comprend les protocoles de communication. Des flèches à double face relient le boîtier un à l’utilisateur sur site et au terminal TN3270. La case numéro deux comprend les gestionnaires de transactions, y compris le SCIC et le SGI. Des flèches à double face relient les cases un et deux. La couche d’application comprend des cases numérotées quatre et cinq pour les composants front-end et de logique métier. Des flèches à double face relient les cases trois et quatre. Une flèche pointe de la couche application vers la boîte six, qui contient d’autres services. La case numéro cinq est la couche de données, qui contient des bases de données, telles que DB2 et IMS DB, et des fichiers VSAM. Une flèche à deux côtés relie la couche de données et la couche d’application. Une flèche pointe de la couche de données vers la boîte six. La case numéro six comprend d’autres services, tels que la sécurité, la gestion, la surveillance et les services de production de rapports.

Flux de travail

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

  1. Les utilisateurs se connectent à l’ordinateur central via le protocole TCP (Transmission Control Protocol) ou le protocole IP (Internet Protocol) à 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. Dans le front-end de la couche d’application, les utilisateurs interagissent avec les écrans du système de contrôle des informations client (CICS) ou du système de gestion de l’information (IMS) ou avec les pages Web.

  4. Les gestionnaires de transactions utilisent la logique métier écrite en COBOL (Common Business-oriented Language) ou PL/I (Programming Language One) pour mettre en œuvre les transactions.

  5. Le code de l’application utilise les capacités de stockage de la couche de données, telles que DB2, IMS DB ou VSAM.

  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 tous les autres services du système.

Le diagramme suivant montre comment migrer cette architecture vers Azure.

Diagramme illustrant une architecture permettant de migrer une charge de travail OLTP z/OS vers Azure.

Le diagramme montre comment migrer une charge de travail OLTP z/OS vers Azure. L’architecture est divisée en plusieurs couches qui représentent les différents composants et leurs interactions. Chaque couche utilise des chiffres et des flèches pour mettre en évidence le flux de données. La couche 1 représente un utilisateur local. Une flèche à deux côtés relie l’utilisateur et Azure ExpressRoute. La couche 2 représente les demandes d’entrée. Cette couche contient deux zones reliées par une flèche pointillée à deux côtés intitulée Pare-feu d’applications web Azure. La zone de gauche contient des icônes pour Azure Front Door et Azure Traffic Manager. Une flèche à double face relie la boîte de gauche à une icône qui représente Internet. Une autre flèche à deux côtés relie l’icône Internet à Microsoft Entra ID. La zone de droite contient des icônes pour Azure Application Gateway et Azure Load Balancer. Une flèche à double face relie cette boîte à une boîte étiquetée à l’avant. La boîte étiquetée front-end se trouve à l’intérieur de la couche d’application. Il contient des icônes pour Gestion des API Azure, Azure App Service, Azure Kubernetes Service (AKS) et Azure Spring Apps. Trois flèches en pointillés et à double face relient le boîtier frontal à un boîtier étiqueté logique métier. Cette zone contient des icônes pour Azure Functions, Azure WebJobs, AKS et Azure Spring Apps. Les icônes d’Azure Service Bus et d’Azure Queue Storage (asynchrone) se trouvent au-dessus et en dessous des trois flèches. Une flèche à double face relie la couche d’application à la couche de cache. La couche de cache contient Azure Cache pour Redis. Une flèche pointe de la couche de cache vers la couche de surveillance. Dans cette couche, une flèche pointillée passe d’Azure Monitor aux journaux Azure Monitor, puis à une boîte bleue contenant des icônes intitulées Tableau de bord Log Analytics et alertes. La couche de surveillance inclut également Application Insights. Une flèche pointillée pointe depuis Application Insights vers la zone bleue. Une autre flèche pointe de la couche d’application vers Application Insights. La couche de données contient deux cases. Une boîte contient des icônes pour Azure Table Storage et Azure Files. L’autre zone contient Azure SQL, Azure Cosmos DB, Azure Database pour PostgreSQL et Azure Database pour MySQL. Une flèche à deux côtés relie la couche de données et la couche d’application.

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

  1. Les utilisateurs mainframe connaissent bien les terminaux 3270 et la connectivité sur site. Dans le système migré, ils interagissent avec les applications Azure via l’Internet public ou via une connexion privée implémentée via Azure ExpressRoute. Microsoft Entra ID fournit l’authentification.

  2. Les demandes d’entrée sont envoyées à un service d’équilibreur de charge global, tel qu’Azure Front Door ou Azure Traffic Manager. L’équilibreur de charge peut servir une base d’utilisateurs géographiquement dispersée. Il achemine les requêtes selon des règles définies pour les charges de travail prises en charge. Ces équilibreurs de charge peuvent se coordonner avec Azure Application Gateway ou Azure Load Balancer pour équilibrer la charge de la couche application. Le service Azure Content Delivery Network met en cache le contenu statique dans les serveurs Edge pour une réponse rapide. Un pare-feu d’applications Web (WAF) permet de sécuriser le service.

  3. Le serveur frontal de la couche d’application utilise des services Azure tels qu’Azure App Service pour implémenter des écrans d’application et interagir avec les utilisateurs. Les écrans sont des versions migrées des écrans mainframe.

  4. Le code COBOL et PL/I dans le back-end de la couche d’application implémente la logique métier. Le code peut utiliser des services et des fonctionnalités tels que Azure Functions, WebJobs et les microservices Azure Spring Apps. Les applications peuvent s’exécuter dans un conteneur Azure Kubernetes Service (AKS).

  5. Un magasin de données en mémoire accélère les applications OLTP à haut débit. Par exemple, In-Memory OLTP, qui est une fonctionnalité d’Azure SQL Database et d’Azure SQL Managed Instance, et Azure Cache pour Redis.

  6. La couche de données peut inclure :

    • Fichiers, tables et objets blob implémentés à l’aide du stockage Azure.
    • Bases de données relationnelles de la famille Azure SQL.
    • Implémentations Azure des bases de données open source PostgreSQL et MySQL.
    • Azure Cosmos DB, qui est une base de données NoSQL.

    Ces magasins contiennent les données migrées à partir de l’ordinateur central pour que la couche d’application puisse les utiliser.

  7. Les services natifs d’Azure, tels qu’Application Insights et Azure Monitor, surveillent de manière proactive l’intégrité du système. Vous pouvez intégrer les journaux Azure Monitor à l’aide d’un tableau de bord Azure.

Composants

Cette architecture se compose de plusieurs services cloud Azure. Il est divisé en quatre catégories de ressources : mise en réseau et identité, application, stockage et surveillance. Les sections suivantes décrivent les services de chaque ressource et leurs rôles.

Mise en réseau et identité

Lorsque vous concevez une architecture d’application, il est essentiel de hiérarchiser les composants de mise en réseau et d’identité afin de garantir la sécurité, les performances et la facilité de gestion lors des interactions sur l’Internet public ou les connexions privées. Les composants suivants de l’architecture sont essentiels pour répondre efficacement à cette exigence.

  • ExpressRoute gère les connexions privées entre les infrastructures locales et les centres de données Azure.

  • Microsoft Entra ID est un service de gestion des identités et des accès qui peut se synchroniser avec un annuaire local.

  • Azure Front Door fournit un équilibrage de charge HTTP global avec basculement instantané. Son option de mise en cache peut accélérer la diffusion de contenu statique.

  • Traffic Manager dirige les demandes entrantes du système de noms de domaine en fonction des méthodes de routage du trafic que vous avez choisies.

  • Un pare-feu Azure permet de protéger les applications web contre les attaques malveillantes et les vulnérabilités web courantes, telles que l’injection SQL et les scripts intersites.

  • Le réseau de diffusion de contenu met en cache le contenu statique dans les serveurs de périphérie pour permettre des réponses rapides et utilise des optimisations réseau pour améliorer la réponse du contenu dynamique. Content Delivery Network est particulièrement utile quand la base des utilisateurs est mondiale.

  • Application Gateway est un service de contrôleur de distribution d’applications. Il fonctionne au niveau de la couche 7, la couche application, et dispose de diverses fonctionnalités d’équilibrage de charge.

  • Load Balancer est un équilibreur de charge de couche 4 (TCP ou User Datagram Protocol). Dans cette architecture, il fournit des options d’équilibrage de charge pour Azure Spring Apps et AKS.

Application

Azure fournit des services managés qui prennent en charge un déploiement plus sûr, évolutif et efficace des applications. Les services de couche application utilisés par l’architecture précédente peuvent vous aider à optimiser l’architecture de votre application.

  • Gestion des API Azure prend en charge la publication, le routage, la sécurisation, la journalisation et l’analyse des API. Vous pouvez contrôler la façon dont les données sont présentées et étendues, ainsi que les applications qui peuvent y accéder. Vous pouvez restreindre l’accès à vos applications ou autoriser des tiers.

  • App Service est un service complètement managé permettant de créer, déployer et mettre à l’échelle des applications web. Vous pouvez créer des applications à l’aide de .NET, .NET Core, Node.js, Java, Python ou PHP. Les applications peuvent s’exécuter dans des conteneurs ou sur Windows ou Linux. Dans une migration de mainframe, les écrans ou l’interface web du front-end peuvent être codés en utilisant des API REST basées sur HTTP. Ils peuvent être séparés en fonction de l’application mainframe et peuvent être sans état pour orchestrer un système basé sur des microservices.

  • WebJobs est une fonctionnalité d’App Service qui exécute un programme ou un script dans la même instance qu’une application web, une application API ou une application mobile. Une tâche Web peut être un bon choix pour mettre en œuvre une logique de programme partageable et réutilisable. Pour plus d’informations, consultez Exécuter des tâches en arrière-plan avec des WebJobs dans App Service.

  • AKS est un service Kubernetes complètement managé, qui permet de déployer et de gérer des applications conteneurisées. AKS simplifie le déploiement d’un cluster AKS managé dans Azure en déchargeant la surcharge opérationnelle sur Azure.

  • Azure Spring Apps est un service Spring entièrement managé, créé et exploité conjointement par Microsoft et VMware. Vous pouvez utiliser Azure Spring Apps pour déployer, gérer et exécuter facilement des microservices Spring et écrire des applications Spring à l’aide de Java ou .NET.

  • Azure Service Bus est un service de messagerie cloud fiable pour une intégration hybride simple. Les files d’attente Service Bus et de stockage peuvent connecter le serveur frontal à la logique métier du système migré.

  • Azure Functions fournit un environnement permettant d’exécuter de petits morceaux de code, appelés fonctions, sans avoir à établir d’infrastructure d’application. Vous pouvez l’utiliser pour traiter des données en masse, intégrer des systèmes, travailler avec l’Internet des objets et créer des API et des microservices simples. Utilisez des microservices pour créer des serveurs qui se connectent aux services Azure et qui sont toujours à jour.

  • Azure Cache pour Redis est un service de mise en cache en mémoire entièrement managé pour le partage de données et d’état entre les ressources de calcul. Il inclut Redis open source et Redis Enterprise, un produit commercial de Redis Labs, en tant que service géré. Vous pouvez améliorer les performances des applications OLTP à haut débit en les concevant pour qu’elles soient mises à l’échelle et qu’elles utilisent un magasin de données en mémoire tel qu’Azure Cache pour Redis.

Stockage et base de données

Cette architecture prend en charge un stockage cloud évolutif et plus sécurisé ainsi que des bases de données gérées pour une gestion flexible et intelligente des données.

Supervision

Les outils de surveillance suivants fournissent une analyse complète des données et des informations précieuses sur les performances des applications.

  • Azure Monitor collecte, analyse et agit sur les données personnelles de vos environnements Azure et locaux.

    Les alertes Azure Monitor sont une fonctionnalité de Monitor. Pour plus d’informations, consultez Créer, afficher et gérer des alertes de métrique à l’aide d’Azure Monitor.

  • Log Analytics est un outil du portail Azure que vous utilisez pour interroger les journaux Azure Monitor à l’aide d’un langage de requête puissant. Vous pouvez interagir avec les résultats de vos requêtes ou les utiliser avec d’autres fonctionnalités Azure Monitor, telles que les alertes de requête de journal ou les classeurs. Pour plus d’informations, consultez Vue d’ensemble de Log Analytics dans Azure Monitor.

  • Application Insights est une fonctionnalité d’Azure Monitor qui fournit une surveillance au niveau du code de l’utilisation, de la disponibilité et des performances des applications. Il surveille l’application, détecte les anomalies telles que les performances médiocres et les défaillances, et envoie les données personnelles au portail Azure. Vous pouvez également utiliser Application Insights pour la journalisation, le traçage distribué et les métriques d’application personnalisées.

Détails du scénario

En raison de l’évolution des besoins et des données de l’entreprise, les applications doivent évoluer et produire des résultats sans créer de problèmes d’infrastructure. Cet exemple de charge de travail montre comment vous pouvez migrer une application OLTP mainframe z/OS vers un système plus sécurisé, évolutif et hautement disponible dans le cloud à l’aide des services PaaS (Platform as a Service) Azure. Cette migration aide les entreprises des secteurs de la finance, de la santé, de l’assurance et du commerce de détail à réduire les délais de livraison des applications. Cela permet également de réduire les coûts d’exécution des applications.

Cas d’usage potentiels

Cette architecture est idéale pour les charges de travail OLTP qui présentent les caractéristiques suivantes :

  • Ils servent une base d’utilisateurs internationale.

  • Leur utilisation varie considérablement au fil du temps, de sorte qu’ils bénéficient d’une évolutivité flexible et d’une tarification basée sur l’utilisation.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

  • Vous pouvez déployer cette architecture OLTP dans plusieurs régions. Il peut également disposer d’une couche de données géorépliquée.

  • Les services de base de données Azure prennent en charge la redondance de zone et peuvent basculer vers un nœud secondaire en cas de panne ou pour permettre des activités de maintenance.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

  • ExpressRoute crée une connexion privée à Azure à partir d’un environnement local. Vous pouvez également utiliser un VPN de site à site.

  • Microsoft Entra ID peut authentifier les ressources et contrôler l’accès à l’aide du contrôle d’accès en fonction du rôle Azure.

  • Les services de base de données dans Azure prennent en charge diverses options de sécurité telles que le chiffrement des données au repos.

  • Pour obtenir des conseils généraux sur la conception de solutions plus sécurisées, consultez Liens rapides sur la sécurité.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

Utilisez la calculatrice de prix Azure pour estimer les coûts de votre implémentation.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.

Ce scénario utilise Azure Monitor et Application Insights pour surveiller l’intégrité des ressources Azure. Vous pouvez définir des alertes pour une gestion proactive.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

  • Cette architecture utilise des services PaaS Azure tels qu’App Service, qui dispose de fonctionnalités de mise à l’échelle automatique.

  • Pour plus d’informations, consultez Mise à l’échelle automatique.

Contributeurs

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

Auteurs principaux :

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

Étapes suivantes

Consultez les architectures associées et les informations techniques associées.