Modifier

Partager via


Réhéberger un mainframe général sur Azure

Machines virtuelles Azure
Réseau virtuel Azure
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Site Recovery

La réhébergement est un moyen d’exécuter des applications mainframe héritées, intactes, sur un système ouvert. Cela constitue le moyen le plus rapide de retirer des applications de votre matériel mainframe et de les exécuter sur une plateforme Windows ou Linux dans un environnement natif cloud. Le code d’application écrit dans des langages hérités tels que COBOL ou PL/1 est migré tel quel et recompilé dans le nouvel environnement sans modification de la logique métier. Le réhébergement permet de conserver la logique de l’application. En même temps, le réhébergement réduit le risque et le coût qui est fourni avec le recodage de l’application pour le nouvel environnement.

Le réhébergement est une méthode rentable pour relever les défis liés à la maintenance de l’ancien matériel mainframe. Communément appelé opération lift-and-shift, le réhébergement déplace les applications stratégiques et principales hors du mainframe et les migre vers le cloud. Avec cette approche, le matériel sous-jacent change en passant, par exemple, d’un mainframe IBM à x86. Toutefois, la logique fonctionnelle et métier n’est pas touchée. Cette migration est la plus rapide et la moins impactante du point de vue de l’utilisateur final. L’application conserve les mêmes interfaces et la même apparence que celles auxquelles les utilisateurs sont habitués.

Pour les équipes qui explorent les fonctionnalités cloud, les applications de réhébergement constituent un excellent moyen d’utiliser des fonctionnalités cloud telles que la mise à l’échelle automatique, le stockage managé et les conteneurs. Cette architecture montre un exemple de réhébergement général qui met en évidence deux méthodologies de déploiement des charges de travail. Vous pouvez utiliser Azure Kubernetes Service (AKS) ou des machines virtuelles Azure. La méthode que vous utilisez dépend de la portabilité de l’application et de votre préférence.

Cas d’usage potentiels

De nombreux scénarios peuvent tirer parti de la réhébergement sur Azure. Voici quelques cas d’usage possibles :

  • Optimisation des coûts : vous souhaitez réduire considérablement les coûts d’exploitation et de maintenance élevés du matériel mainframe et ses licences ou logiciels associés.
  • Indépendance par rapport à l’emplacement : vous planifiez la sortie d’un centre de données et souhaitez une plateforme alternative hautement disponible, sécurisée et fiable pour héberger vos applications héritées.
  • Interruption minimale : vous devez migrer des applications mainframe stratégiques tout en conservant la continuité des opérations métier quotidiennes.
  • Impact minimal sur l’utilisateur : déplacez vos applications à partir d’anciens matériels, mais continuez à fournir aux utilisateurs les mêmes interfaces ou de meilleures interfaces.
  • Amélioration négligeable : les applications sont réhébergées dans le cloud sans modification significative du code. Elles continuent à fournir à votre équipe de développement la base de code familière et, en même temps, éliminent le développement, le test et la refonte qui sont des postes coûteux lorsque l’on utilise un nouveau langage.

Architecture mainframe

Il s’agit de l’architecture de pré-migration.

Diagramme montrant les applications mainframe avant la migration vers Azure.

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

Données mainframe

  1. L’entrée s’effectue via TCP/IP, notamment TN3270, HTTP et HTTPS.

  2. L’entrée dans le mainframe utilise des protocoles mainframe standard.

  3. Les applications de destination peuvent être des systèmes de traitement par lots ou en ligne.

  4. Les langages COBOL, PL/I, Assembleur et compatibles s’exécutent dans un environnement activé à cette fin.

  5. Les services de données et de base de données utilisés sont des bases de données hiérarchiques, réseau et relationnelles.

  6. Les services courants incluent l’exécution des programmes, les opérations d’E/S, la détection d’erreurs et la protection au sein de l’environnement.

  7. Les middlewares (intergiciels) et les utilitaires gèrent des services tels que le stockage sur bande, la mise en file d’attente, la sortie ainsi que les services web au sein de l’environnement.

  8. Les systèmes d’exploitation fournissent l’interface entre le moteur et le logiciel.

  9. Les partitions sont nécessaires pour exécuter des charges de travail distinctes et pour séparer les types de travail au sein de l’environnement.

Architecture

Cette architecture présente une solution réhébergée sur Microsoft Azure.

Diagramme montrant les applications mainframe après la migration vers Azure.

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

Dataflow

  1. Les données sont généralement transmises via ExpressRoute par des clients distants ou par d’autres applications exécutées dans Azure. Dans les deux cas, les connexions TCP/IP constituent le moyen principal de se connecter au système. L’accès utilisateur est assuré par le port TLS 443 pour accéder aux applications web. La couche de présentation de l’application web peut être conservée inchangée pour réduire les besoins en renouvellement des utilisateurs finaux. Pour l’accès administrateur aux machines virtuelles, vous pouvez utiliser des hôtes Azure Bastion afin d’optimiser la sécurité en réduisant les ports ouverts.

  2. L'accès aux clusters de calcul d’application se fait par l’intermédiaire d’un équilibreur de charge Azure. Avec cette approche, vous pouvez effectuer un scale-out des ressources de calcul pour traiter le travail d’entrée. Des équilibreurs de charge au niveau du protocole réseau de niveau 7 et du niveau 4 sont disponibles. Le type à utiliser dépend de la façon dont l’entrée de l’application atteint le point d’entrée du cluster de calcul.

  3. L’utilisation de clusters de calcul d’application dépend du fait que l’application prend en charge les machines virtuelles dans un cluster de calcul ou que l’application s’exécute dans un conteneur que vous déployez dans un cluster Compute conteneur comme Kubernetes. La plupart des logiciels partenaires mainframe pour les applications écrites dans des langages hérités préfèrent utiliser des machines virtuelles. Certains logiciels partenaires de systèmes mainframe peuvent également prendre en charge le déploiement en conteneurs.

  4. Les serveurs d’applications reçoivent l’entrée dans les clusters de calcul, et partagent l’état et les données d’application à l’aide d’Azure Cache pour Redis ou d’un accès direct à la mémoire à distance (RDMA). Les serveurs d’applications hébergent différents programmes d’application COBOL ou PL/1. Un gestionnaire de systèmes transactionnels est un émulateur sur Azure qui peut gérer les charges de travail des systèmes de contrôle des informations clients (CICS) et des systèmes de gestion des informations (IMS). Un émulateur de système batch sur Azure joue le rôle de langage de contrôle de travail (JCL).

  5. Vous pouvez utiliser des services Azure ou d’autres logiciels partenaires hébergés dans des machines virtuelles pour la gestion des systèmes, des utilitaires et des données.

  6. Les données mainframe sont migrées vers les bases de données Azure. Azure fournit divers services de stockage de données efficaces tels que Azure SQL Database, SQL Server sur des machines virtuelles Azure et Azure SQL Managed Instance. Lorsque vous effectuez un choix, vous devez prendre en considération de nombreux facteurs, comme le type de charge de travail, les requêtes de bases de données croisées et les exigences de validation en deux phases. Les services de données Azure fournissent un stockage de données évolutif et hautement disponible que vous pouvez partager entre plusieurs ressources informatiques dans un cluster. Vous pouvez rendre ces services géoredondants, puis les configurer de sorte qu’en cas de basculement, l’instance de la base de données de reprise après sinistre devienne active.

  7. AKS vous permet d’étendre et de réduire vos charges de travail de modernisation de mainframe dans Azure afin de tirer parti de la plateforme cloud. Lorsque vous déployez plusieurs clusters AKS, choisissez des régions où AKS est disponible. Vous pouvez ensuite utiliser des régions jumelées pour une architecture hautement résiliente. Il est important d’exécuter plusieurs instances d’un cluster AKS sur plusieurs régions et dans des configurations hautement disponibles.

  8. Azure Data Factory permet l’ingestion et la synchronisation des données avec plusieurs sources de données, tant au sein d’Azure qu’à partir de sources externes. Le stockage blob Azure est une zone d’atterrissage commune pour les sources de données externes.

  9. Utilisez Azure Site Recovery pour la récupération d’urgence des composants de cluster de machines virtuelles et de conteneurs. Azure Site Recovery réplique et synchronise l’environnement de production vers la région de basculement.

Composants

  • Machines Virtuelles : cette fonctionnalité constitue une ressource informatique évolutive à la demande. Une machine virtuelle Azure vous donne la flexibilité de la virtualisation sans que vous ayez à acheter le matériel physique qui exécute la machine virtuelle ni à en assurer la maintenance.

  • Réseau virtuel Azure : Réseau virtuel constitue le bloc de construction fondamental de votre réseau privé dans Azure. Réseau virtuel permet à de nombreux types de ressources Azure, comme les machines virtuelles Azure, de communiquer de manière sécurisée entre elles, avec Internet et avec des réseaux locaux. Réseau virtuel est semblable à un réseau traditionnel que vous exploitez dans votre propre centre de données. Cependant, cette fonctionnalité apporte les avantages de l’infrastructure Azure tels que la mise à l'échelle, la disponibilité et l’isolation.

  • Cartes d’interface du réseau virtuel Azure : une interface réseau permet à une machine virtuelle Azure de communiquer avec des ressources sur Internet, sur Azure et locales. Comme le montre cette architecture, vous pouvez ajouter plusieurs cartes d’interface réseau à la même machine virtuelle Azure. Ainsi, les machines virtuelles enfants Solaris disposent de leur propre périphérique d’interface réseau et de leur adresse IP dédiée.

  • Stockage sur disque Azure : les disques managés Azure sont des volumes de stockage de niveau bloc qui sont gérés par Azure et utilisés avec des machines virtuelles Azure. Les types de disques disponibles sont le stockage sur disques de stockage Ultra, SSD Premium Azure, SSD Standard Azure et HDD Standard Azure. Pour cette architecture, nous vous recommandons d'utiliser les disques SSD Premium ou les disques SSD Ultra.

  • Azure Files : cette fonctionnalité offre des partages de fichiers managés dans le cloud accessibles via le protocole SMB (Server Message Block) standard. Vous pouvez monter des partages de fichiers Azure simultanément sur des déploiements cloud ou locaux de Windows, Linux et macOS.

  • Azure ExpressRoute : cette fonctionnalité vous permet d’étendre vos réseaux locaux au cloud de Microsoft via une connexion privée assurée par un fournisseur de connectivité. Vous pouvez également établir des connexions aux services cloud de Microsoft, comme Microsoft Azure et Microsoft 365.

  • AKS : déployez et gérez des applications conteneurisées plus facilement avec un service Kubernetes complètement managé. Azure Kubernetes Service (AKS) offre une instance Kubernetes serverless, une expérience intégrée d’intégration continue et livraison continue (CI/CD), ainsi qu’une sécurité et une gouvernance de classe Entreprise. Réunissez vos équipes dédiées aux déploiements et aux opérations sur une même plateforme pour rapidement créer, livrer et mettre à l'échelle des applications en toute confiance.

  • Azure Container Registry : créez, stockez, sécurisez, analysez, répliquez et gérez des images conteneurs et des artefacts avec une instance de distribution OCI géo-répliquée et complètement managée. Connectez-vous à des environnements tels que AKS et Azure Red Hat OpenShift, et à des services Azure tels que App Service, Machine Learning et Batch.

  • Site Recovery : Site Recovery offre une facilité de déploiement, d’efficacité des coûts et de fiabilité. Déployez des processus de réplication, de basculement et de récupération grâce à Site Recovery pour assurer le fonctionnement de vos applications lors de pannes planifiées ou non planifiées.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

  • Pour tirer parti des fonctionnalités d’Azure, utilisez une approche basée sur des conteneurs pour le déploiement. Cette approche est utile si l’application doit évoluer à la demande et obtenir un approvisionnement élastique de la capacité sans avoir à gérer l’infrastructure. Cela vous permet également d’ajouter la mise à l’échelle automatique et les déclencheurs pilotés par les événements. Un conteneur regroupe tous les logiciels nécessaires à l’exécution en un seul package exécutable. Il comprend le code d’une application ainsi que les fichiers config, les bibliothèques et les dépendances associés nécessaires à l’exécution de l’application.
  • Vous devez orchestrer et gérer des services conteneurisés et leurs composants de mise en réseau et de stockage associés. AKS est une excellente option, car elle automatise la gestion des clusters et des ressources. Vous indiquez le nombre de nœuds dont vous avez besoin, et AKS ajuste vos conteneurs sur les nœuds appropriés pour utiliser au mieux les ressources. AKS prend également en charge les déploiements et les restaurations automatisés, la découverte de services, l’équilibrage de charge ainsi que l’orchestration du stockage. De plus, AKS prend en charge le « self-healing » (l’autoadaptation). En cas de défaillance d’un conteneur, AKS en démarre un nouveau. Vous pouvez également stocker de manière sécurisée les secrets et les paramètres de configuration en dehors des conteneurs.
  • L’architecture utilise Site Recovery pour mettre en miroir les machines virtuelles Azure dans une région Azure secondaire pour un basculement et une récupération d’urgence rapides en cas de défaillance d’un centre de données Azure.
  • Pour optimiser le temps d’activité des charges de travail sur l’approche de déploiement AKS, il est recommandé de déployer l’application dans plusieurs clusters AKS de régions différentes. L’état de votre application peut être disponible sur plusieurs clusters, car AKS autorise la réplication de stockage dans plusieurs régions.
  • Pour optimiser le temps d’activité des charges de travail sur une approche de déploiement basée sur une machine virtuelle, envisagez d’utiliser Azure Virtual Machine Scale Sets. Les groupes de machines virtuelles identiques Azure vous permettent de créer et de gérer un groupe de machines virtuelles à charge équilibrée. Le nombre d’instances de machine virtuelle peut augmenter ou diminuer automatiquement en fonction d’une demande ou d’un calendrier défini. Les groupes identiques offrent une haute disponibilité à vos applications, et vous permettent de gérer, configurer et mettre à jour de manière centralisée de nombreuses machines virtuelles.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

  • Cette solution utilise un groupe de sécurité réseau Azure pour gérer le trafic entre les ressources Azure. Pour plus d’informations, consultez Groupes de sécurité réseau.
  • Azure Bastion optimise la sécurité de l’accès administrateur en minimisant les ports ouverts. Bastion fournit une connectivité RDP/SSH sécurisée et fluide à vos machines virtuelles de réseau virtuel, directement à partir du portail Azure via TLS.

Optimisation des coûts

L’optimisation des coûts consiste pour vous à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Azure optimise les coûts en s’exécutant sur des machines virtuelles Windows. Avec les machines virtuelles Windows, vous pouvez désactiver les machines virtuelles lorsqu’elles ne sont pas utilisées et générer un script de planification pour les modèles d’utilisation connus. Azure identifie le bon nombre ou les types de ressources, analyse les dépenses au fil du temps et met à l’échelle pour répondre aux besoins métier sans dépasser le budget alloué.

Utilisez la calculatrice de prix Azure pour estimer le coût des services dans cette architecture.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

  • L’architecture cible est fonctionnelle avec Azure Cloud Services.
  • Le déploiement basé sur des conteneurs favorise également l’adoption des principes de travail reposant sur les méthodologies DevOps et Agile.
  • Vous disposez d’une flexibilité totale en ce qui concerne les options de déploiement en environnement de développement et de production.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

  • L’efficacité des performances est intégrée à cette solution en raison des équilibreurs de charge. En cas de défaillance d’un serveur de présentation ou de transaction, le serveur qui se trouve derrière l’équilibreur de charge assume la charge de travail.
  • Kubernetes fournit un autoscaler de cluster. L’autoscaler ajuste le nombre de nœuds en fonction des ressources de calcul demandées dans le pool de nœuds.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autre contributeur :

Étapes suivantes

Pour plus d’informations, contactez legacy2azure@microsoft.com.