Modifier

Partager via

Utiliser LzLabs Software Defined Mainframe (SDM) dans un déploiement VM Azure

Machines virtuelles Azure
Azure Database pour PostgreSQL
Réseau virtuel Azure
Azure Resource Manager

LzLabs Software Defined Mainframe (SDM) réduit considérablement les risques et la complexité inhérents au réhébergement de charges de travail héritées en éliminant la nécessité de rechercher, modifier et recompiler le code source des applications héritées. Cette approche permet aux programmes exécutables binaires z/Architecture d’opérer à des vitesses natives sur des ordinateurs d’architecture x86_64 exécutant une pile logicielle de systèmes ouverts, ouvrant la voie à la modernisation des ressources héritées.

Architecture

Diagramme montrant l’architecture et le flux de données décrits en détail dans le texte de l’article qui l’accompagne.Téléchargez un fichier SVG de cette architecture.

Workflow

  1. Les applications LzLabs SDM sont accessibles de la même façon que des applications mainframe ordinaires via un terminal 3270. Vous pouvez utiliser l’émulateur de terminal de votre choix. Pour la gestion, l’administration et d’autres activités, le client LzWorkbench est utilisé. Le composant serveur s’exécute sur la machine virtuelle SDM.
  2. L’accès au port est généralement configuré pour s’adapter aux exigences de sécurité du client.
  3. Pour une implémentation sécurisée de SDM, vous devez implémenter un serveur frontal de services web composé des éléments suivants :
  4. SDM peut être configuré pour le basculement avec un appairage de réseaux virtuels (VNet) vers la sauvegarde, la récupération d’urgence et les régions Azure secondaires. Cela contribue à améliorer la disponibilité de SDM pour les charges de travail de production, car Azure conserve un réplica cohérent au en cas de déconnexion de la machine virtuelle initiale.
  5. La machine virtuelle SDM dans l’environnement de production est répliquée et synchronisée dans la région de basculement par Azure Site Recovery. Ce service conserve le disque du système d’exploitation principal pour la production et les images de disque attachées synchronisés avec le SDM de la région secondaire. Il le fait pour tous les disques attachés, à l’exception du disque responsable du traitement des fichiers d’index (voir le point 10). Site Recovery est également utilisé pour assurer la synchronisation de toutes les autres images de machine virtuelle avec la région secondaire.
  6. La base de données dans cette architecture est une IaaS PostgreSQL. Actuellement, le service Azure PostgreSQL ne peut pas être utilisé, et IaaS PostgreSQL doit être utilisé avec SDM dans les déploiements. Cela est dû à une limitation dans Azure PostgreSQL pour le traitement des types de données définis par l’utilisateur (UDT). L’instance de base de données dans la région secondaire est tenue à jour avec le journal des transactions à écriture anticipée. Cela permet un basculement entre régions. Quand le basculement se produit, le mode est défini sur actif. Le même processus est utilisé pour assurer la cohérence transactionnelle de la base de données de basculement de production au sein de la région de production. En utilisant le journal des transactions à écriture anticipée pour maintenir la synchronisation de ces deux réplicas, la couche base de données reste hautement disponible. Remarque : pour des performances optimales, la machine virtuelle de base de données et la machine virtuelle SDM doivent être placées dans un groupe de placement de proximité Azure.
  7. Un serveur frontal de services web doit être déployé pour la région de récupération d’urgence afin maintenir un accès sécurisé au système. De nombreuses charges de travail mainframe ont une couche de services web API pour accéder aux transactions CICS et aux données DB2.
  8. Pour l’intégration des identités RACF et Top Secret à l’aide d’extensions Active Directory, LzVault assure l’authentification et l’autorisation dans Azure pour les règles de sécurité migrées à partir du mainframe.
  9. Le serveur Barman est configuré dans la couche Données. Celui-ci fournit des réplicas d’instantanés de la base de données PostgreSQL pour la récupération jusqu’à une date et heure au sein tant de la région de production que de la région secondaire.
  10. Comme mentionné au point 5, le disque qui gère le traitement des fichiers indexés pour SDM doit être synchronisé entre les régions à l’aide d’une solution de mise en miroir de bases de données. En effet, Azure Site Recovery ne peut pas garantir la cohérence des transactions nécessaire pour une base de données. Étant donné que le traitement des fichiers indexés n’est pas effectué dans PostgreSQL, vous devez utiliser une solution capable de le fournir.
  11. Pour prendre en charge la planification du traitement par lots, vous devez utiliser un planificateur tel qu’Azure Logic Apps ou SMA.
  12. Pour assurer la disponibilité, deux machines virtuelles SDM sont déployées dans un groupe à haute disponibilité Azure. Azure Load Balancer fournit des services d’équilibrage de charge aux deux machines virtuelles. L’état est partagé entre les deux machines virtuelles à l’aide d’un disque partagé Azure. Celui-ci est répliqué via DRDB vers l’instance de récupération d’urgence.

Composants

  • Les machines virtuelles Azure sont l’un des nombreux types de ressources informatiques évolutives, à la demande proposées par Azure. Une machine virtuelle Azure vous offre la flexibilité de la virtualisation sans que vous ayez à acheter le matériel physique qui l’exécute ni à en assurer la maintenance.
  • Les réseaux virtuels constituent le bloc de construction fondamental de votre réseau privé dans le réseau virtuel Azure. Le réseau virtuel Azure permet à de nombreux types de ressources Azure, y compris aux machines virtuelles, de communiquer de manière sécurisée entre elles, avec Internet et avec des réseaux locaux. Un réseau virtuel est similaire à un réseau traditionnel que vous utiliseriez dans votre propre centre de données, mais avec les avantages supplémentaires de l’infrastructure Azure, tels que la mise à l’échelle, la disponibilité et l’isolation.
  • L'interface réseau virtuelle Azure est un contrôleur d'interface réseau (NIC) qui permet à une machine virtuelle Azure de communiquer avec internet, d'autres ressources dans Azure et des ressources locales. Comme le montre cette architecture, vous pouvez ajouter des NIC à la même machine virtuelle, ce qui permet aux machines virtuelles enfants Solaris de disposer de leurs propres dispositif d’interface réseau et adresse IP dédiés.
  • Les disques managés SSD Azure sont des volumes de stockage de niveau bloc gérés par Azure et utilisés avec des machines virtuelles Azure. Les types de disques disponibles sont les disques Ultra Disk, Premium SSD, SSD Standard et HDD Standard. Pour cette architecture, nous vous recommandons d'utiliser les disques SSD Premium ou les disques SSD.Ultra.
  • Les services Stockage Azure et Azure Files offrent des partages de fichiers entièrement gérés dans le cloud, qui sont accessibles via le protocole SMB standard du secteur. Les partages de fichiers Azure peuvent être montés simultanément via des déploiements cloud ou locaux de Windows, Linux et macOS.
  • Azure ExpressRoute vous permet d’étendre vos réseaux locaux au cloud de Microsoft via une connexion privée assurée par un fournisseur de connectivité. Avec ExpressRoute, vous pouvez établir des connexions aux services de cloud computing Microsoft, comme Microsoft Azure et Office 365.
  • Azure SQL Database est un moteur de base de données PaaS (Platform as a Service) complètement managé qui prend en charge la plupart des fonctions de gestion de base de données sans intervention de l’utilisation, telles que la mise à niveau, la mise à jour corrective, les sauvegardes et la surveillance. Azure SQL Database s’exécute toujours sur la dernière version stable du moteur de base de données SQL Server et un système d’exploitation corrigé offrant une disponibilité de 99,99 %. Les fonctionnalités PaaS intégrées dans Azure SQL Database vous permettent de vous concentrer sur les activités d’administration et d’optimisation de base de données spécifiques du domaine, qui sont critiques pour votre activité.

Détails du scénario

LzLabs Software Defined mainframe (SDM) est une plateforme de réhébergement de charges de travail et de modernisation d’applications mainframe. SDM permet aux applications mainframe héritées de s’exécuter sur des systèmes ouverts, sans modification de code source, recompilation ou conversion de types de données. SDM possède également des fonctionnalités qui permettent de moderniser des applications héritées en les adaptant aux langages et implémentations contemporains, sans compromettre l’intégrité ou le fonctionnement du système dans son ensemble.

SDM réduit considérablement les risques et la complexité inhérents au réhébergement de charges de travail héritées en éliminant le besoin de rechercher, modifier et recompiler le code source d’applications héritées. Cette approche permet aux programmes exécutables binaires z/Architecture d’opérer à des vitesses natives sur des ordinateurs d’architecture x86_64 exécutant une pile logicielle de systèmes ouverts, ouvrant la voie à la modernisation des ressources héritées.

Cas d’usage potentiels

  • Aucun code source. LzLabs est une solution pour les clients qui ont des charges de travail mainframe, mais n’ont pas le code source pour exécuter les applications. Cela peut se produire si la solution est une solution prête à l’emploi personnalisable (COTS ) achetée auprès d’un éditeur de logiciels indépendant qui n’a pas déposé le code source pour la propriété intellectuelle. En outre, la plupart de ces applications basées sur COBOL ayant été écrites il y a longtemps, le code source peut avoir été perdu ou égaré. LzLabs résout ce problème car tout ce dont il a besoin, ce sont les modules de charge (binaires) à exécuter dans SDM.
  • Le client dispose d’un code source et souhaite le réhéberger. Il se peut que le client dispose toujours du code source et souhaite simplement réhéberger ses charges de travail mainframe pour réduire les coûts et profiter des avantages d’une plateforme cloud telle qu’Azure. Le code COBOL peut être maintenu dans SDM, dans un environnement de DevOps moderne.
  • Basculement. Afin d’augmenter la disponibilité et d’éviter d’éventuelles interruptions de la continuité d’activité, les clients peuvent utiliser LzLabs SDM pour un environnement de basculement. Dans ce cas, les modules de charge sont chargés dans SDM et utilisés en tant qu’environnement secondaire si l’environnement de production devient in disponible.

Considérations

Les considérations suivantes, basées sur Azure Well-Architected Framework, s’appliquent à cette solution.

Disponibilité

La disponibilité de la couche application est fournie avec Site Recovery, comme indiqué dans le diagramme. Étant donné que LzLabs SDM utilise PostgreSQL pour la couche base de données, la disponibilité est fournie avec un journal des transactions à écriture anticipée. Cela garantit que la base de données secondaire est cohérente au niveau transactionnel avec la base de données de production.

Opérations

L’environnement Azure dans le diagramme est géré soit avec le portail Azure, soit avec des modèles Azure Resource Manager et des scripts. Cela permet d’effectuer l’administration des ressources (comme le redimensionnement), ainsi que la gestion de sécurité et des accès. La gestion de l’environnement SDM réel est assurée via l’outil d’administration LzWorkbench. Cela permet la création et la gestion d’environnements d’exécution dans SDM.

Efficacité des performances

Lors de la migration de charges de travail mainframe vers Azure, gardez à l’esprit que le ratio de MIPS par processeur virtuel est compris entre 50 et 150 MIPS par processeur virtuel. Cela peut varier en fonction du type de charge de travail. Vous devez profiler la charge de travail mainframe pour les environnements en ligne et de traitement par lots, puis dimensionner les ressources en conséquence.

Extensibilité

Actuellement, la solution de mise à l’échelle de SDM consiste à mettre à l’échelle les machines virtuelles en ajoutant des processeurs virtuels et de la mémoire.

Sécurité

L’accès aux ressources Azure est géré via le portail Azure et/ou Azure Resource Manager. La sécurité de SDM est gérée à l’aide du composant de coffre de SDM. Celui-ci migre la sécurité et les autorisations de RACF ou Top Secret vers un environnement basé sur LDAP à des fins de gestion dans Azure.

Optimisation des coûts

Pour estimer le coût des produits et configurations Azure, consultez la calculatrice de prix Azure.

Pour en savoir plus sur la tarification des produits mainframe définis par logiciel LzLabs et leurs services connexes, visitez le site web LzLabs.

Contributeurs

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

Auteur principal :

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

Étapes suivantes

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

Consultez les ressources suivantes de LzLabs :

Consultez la documentation suivante de Microsoft :

Consultez les articles suivants relatifs au Centre des architectures Azure :