Modifier

Refactoriser les systèmes informatiques mainframe qui exécutent Adabas & Natural

Azure Kubernetes Service (AKS)
Azure ExpressRoute
Azure Disques managés
Azure NetApp Files

Software AG fournit une plateforme mainframe 4GL populaire basée sur le langage de programmation Natural et la base de données Adabas. Cet article fournit une architecture aux organisations qui utilisent des ordinateurs mainframe exécutant Adabas & Natural, et qui cherchent comment moderniser les charges de travail et les déplacer vers le cloud.

Architecture mainframe

Ce diagramme illustre un exemple de mainframe intégrant l’installation des modules Adabas & Natural de Software AG, avant la migration vers Azure. Cet exemple montre une architecture IBM z/OS.

Diagram that shows a mainframe architecture that uses Software AG's Adabas & Natural, before migration to Azure.

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

Workflow

R. L’entrée s’effectue via TCP/IP, notamment TN3270 et HTTP(S). L’entrée dans le mainframe utilise des protocoles mainframe standard.

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

C. Les langages Natural, COBOL, PL/I, assembleur ou autres langages compatibles s’exécutent dans un environnement activé à cette fin.

D. Les services de données et de base de données couramment utilisés sont les systèmes de base de données hiérarchiques/réseau et les types de base de données relationnelle.

E. 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.

F. 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.

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

H. 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 Azure

Ce diagramme vous montre comment migrer l’architecture héritée vers Azure à l’aide d’une approche de refactorisation pour moderniser le système :

Diagram that shows the legacy architecture after migration to Azure.

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

Workflow

  1. Entrée. L’entrée s’effectue généralement via Azure ExpressRoute à partir de clients distants, ou via d’autres applications exécutant Azure. Dans les deux cas, les connexions TCP/IP constituent le moyen principal de se connecter au système. Le port TLS 443 permet d’accéder aux applications web. Vous pouvez laisser la couche présentation des applications web pratiquement inchangée pour réduire les besoins en renouvellement de formation des utilisateurs. Vous pouvez également mettre à jour cette couche avec des frameworks d’expérience utilisateur modernes selon vos besoins. 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. Accès dans Azure. Dans Azure, l’accès aux clusters de calcul d’application est fourni via un équilibreur de charge Azure. Cette approche permet un scale-out des ressources de calcul pour traiter le travail d’entrée. Des équilibreurs de charge de niveau 7 (niveau de l’application) et de niveau 4 (niveau du protocole réseau) 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. Clusters de calcul d’application. L’architecture prend en charge les applications qui s’exécutent dans un conteneur pouvant être déployé dans un orchestrateur de conteneurs tel que Kubernetes. Les composants Adabas & Natural peuvent s’exécuter dans le cadre d’une technologie de conteneur qui fonctionne sur un système d’exploitation Linux. Vous pouvez remanier l’architecture de vos applications héritées en fonction d’architectures modernes basées sur des conteneurs, et vous en servir sur Azure Kubernetes Service.

  4. Émulation de terminal ApplinX (Software AG). ApplinX est une technologie serveur qui fournit une connectivité web et une intégration aux applications système principales sans nécessiter l’apport de changements aux applications. Natural Online permet aux utilisateurs en ligne de se connecter aux applications Natural via un navigateur web. Sans ApplinX, les utilisateurs doivent se connecter au logiciel d’émulation de terminal via SSH. Les deux systèmes s’exécutent dans des conteneurs.

  5. EntireX (Software AG). EntireX vous permet de connecter facilement des services qui s’exécutent sur Integration Server à des programmes stratégiques écrits dans des langages tels que COBOL et Natural. Natural Business Services permet aux fonctions métier programmées en Natural d’accéder aux API. Les deux systèmes s’exécutent dans des conteneurs.

  6. Adabas (Software AG). Adabas est un système de gestion de base de données NoSQL haute performance. Natural batch (Software AG) est un composant dédié à l’exécution de traitements par lots. Les traitements par lots, qui sont planifiés par le système de planification de traitements par lots de votre choix, doivent s’exécuter sur le même nœud que la base de données Adabas pour éviter tout impact sur les performances.

  7. Stockage. Les services Data Services combinent le stockage haute performance (SSD Ultra/Premium), le stockage de fichiers (NetApp) et le stockage standard (objet blob, archivage, sauvegarde), qui peut être localement redondant ou géoredondant, selon l’utilisation. Les systèmes d’exploitation basés sur des nœuds utilisent le stockage sur disque managé. Toutes les données persistantes, par exemple les fichiers de base de données, les journaux de protection, les données d’application et les sauvegardes, utilisent Azure NetApp Files. AKS gère les volumes hébergeant un système d’exploitation et qui sont stockés sur des disques managés. Toutes les données critiques pour l’entreprise en provenance des bases de données, notamment les fichiers ASSO, DATA, WORK et les journaux de protection Adabas, doivent être écrites sur des volumes distincts pouvant être fournis par Azure NetApp Files.

  8. CONNX. Le module CONNX pour Adabas fournit un accès en lecture/écriture en temps réel hautement sécurisé aux sources de données Adabas sur OS/390, z/OS, VSE, Linux, Solaris, HP-UX, AIX et Windows via .NET, ODBC, OLE DB et JDBC. Les connecteurs CONNX permettent d’accéder aux sources de données Adabas et de les exposer à des bases de données plus courantes, par exemple Azure SQL Database, Azure Database pour PosgreSQL et Azure Database pour MySQL.

Composants

  • Azure ExpressRoute étend vos réseaux locaux au cloud Microsoft 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 Office 365.

  • Azure Kubernetes Service est un service Kubernetes complètement managé, qui permet de déployer et de gérer des applications conteneurisées. AKS offre une expérience d’intégration continue et de livraison continue (CI/CD) Kubernetes serverless ainsi que des fonctionnalités de sécurité et de gouvernance de niveau entreprise.

  • 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. Divers types sont disponibles : disques Ultra, SSD Premium, SSD Standard et HDD standard. Les disques SSD sont utilisés dans cette architecture.

  • Azure NetApp Files fournit des partages de fichiers Azure de classe entreprise, basés sur NetApp. Azure NetApp Files facilite la migration et l’exécution d’applications complexes basées sur des fichiers sans changement du code.

Détails du scénario

Les applications s’exécutant sur des ordinateurs mainframe sont au cœur de la plupart des opérations métier depuis près de 50 ans. Bien que ces systèmes mainframe aient démontré une fiabilité remarquable au fil des ans, ils sont devenus quelque peu problématiques, car ils sont rigides voire, dans certains cas, difficiles à entretenir et coûteux à exploiter.

De nombreuses organisations cherchent des moyens de moderniser ces systèmes. Elles cherchent des moyens de libérer les ressources restreintes nécessaires à la maintenance de ces systèmes, de contrôler leurs coûts et d’améliorer la flexibilité des interactions avec de tels systèmes.

Software AG fournit une plateforme mainframe 4GL populaire basée sur le langage de programmation Natural et la base de données Adabas.

Deux modèles vous permettent d’exécuter des applications Adabas & Natural sur Azure : réhéberger et refactoriser. Cet article explique comment refactoriser une application à l’aide de conteneurs managés dans AKS (Azure Kubernetes Service). Pour plus d’informations, consultez Approche basée sur les conteneurs, plus loin dans cet article.

Cas d’usage potentiels

Cette architecture s’applique à toute organisation qui utilise des ordinateurs mainframe exécutant Adabas & Natural, et qui prévoit de moderniser ces charges de travail en les déplaçant vers le cloud.

À propos de l’installation

Approche basée sur les conteneurs

Pour tirer le meilleur parti de la flexibilité, de la fiabilité et des fonctionnalités d’Azure, vous devez remanier l’architecture des applications mainframe. Nous vous recommandons de réécrire les applications monolithiques en tant que microservices, et d’utiliser une approche de déploiement basée sur les conteneurs. 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. Les applications conteneurisées sont rapides à déployer. Elles prennent en charge les pratiques DevOps populaires telles que l’intégration continue (CI) et le déploiement continu (CD).

Les conteneurs Adabas & Natural s’exécutent dans des pods, qui effectuent chacun une tâche spécifique. Les pods sont des unités d’un ou de plusieurs conteneurs qui restent ensemble sur le même nœud et qui partagent des ressources telles que le nom d’hôte et l’adresse IP. Dans la mesure où ils sont découplés de la plateforme sous-jacente, les composants des pods se mettent à l’échelle indépendamment et prennent en charge une plus haute disponibilité. Une application conteneurisée est également portable : elle s’exécute de manière uniforme et cohérente sur n’importe quelle infrastructure.

Les services conteneurisés ainsi que les composants réseau et de stockage associés doivent être orchestrés et managés. Nous recommandons AKS, un service Kubernetes managé qui 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.

Le diagramme d’architecture de cet article montre une implémentation basée sur un conteneur d’Adabas & Natural. Quand vous configurez AKS, vous spécifiez la taille des machines virtuelles Azure de vos nœuds, c’est-à-dire que vous définissez les processeurs, la mémoire et le type de stockage, par exemple des disques SSD haute performance ou des disques durs HDD classiques. Dans cet exemple, Natural s’exécute sur trois instances de machine virtuelle (nœuds) pour améliorer la scalabilité et la disponibilité de l’interface utilisateur (Natural Online plus ApplinX) et de la couche API (Natural Services plus EntireX).

Dans la couche Données, Adabas s’exécute au sein du cluster AKS, qui effectue un scale-in et un scale-out de manière automatique en fonction de l’utilisation des ressources. Vous pouvez exécuter plusieurs composants d’Adabas dans le même pod ou, pour une mise à l’échelle améliorée, AKS peut les répartir sur plusieurs nœuds du cluster. Adabas utilise Azure NetApp Files, un service de stockage de fichiers haute performance et facturé à l’usage, pour toutes les données persistantes, par exemple les fichiers de base de données, les journaux de protection, les données d’application et les sauvegardes.

Operations

La refactorisation permet une adoption plus rapide du cloud. Elle 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

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. Il effectue un monitoring du serveur d’API de métriques toutes les 10 secondes à la recherche de changements à apporter au nombre de nœuds. Si l’autoscaler de cluster détermine qu’un changement est nécessaire, le nombre de nœuds de votre cluster AKS augmente ou diminue selon le cas. 

Sécurité

Cette architecture repose principalement sur Kubernetes, qui comprend des composants de sécurité tels que les secrets et les standards de sécurité des pods. Azure offre des fonctionnalités supplémentaires telles que Microsoft Entra ID, Microsoft Defender pour les conteneurs, Azure Policy, Azure Key Vault, des groupes de sécurité réseau et des mises à niveau de cluster orchestrées.

Contributeurs

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

Auteur principal :

  • Marlon Johnson | Responsable de programme technique senior

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

Étapes suivantes

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

Voici quelques ressources supplémentaires :