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.
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 :
Téléchargez un fichier Visio de cette architecture.
Workflow
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.
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. Vous pouvez utiliser soit des équilibreurs de charge de niveau 7 (niveau application) ou de niveau 4 (niveau protocole réseau). Cependant, le type d’équilibreur de charge que vous utilisez dépend de la manière dont les entrées de l’application atteignent le point d’entrée du cluster de calcul. Nous vous recommandons d’utiliser Azure Application Gateway avec des capacités de pare-feu pour applications web pour le trafic de niveau 7.
Clusters de calcul d’application. L’architecture prend en charge des applications s’exécutant dans un conteneur déployable sur Azure Kubernetes Service (AKS). Les composants Adabas & Natural peuvent s’exécuter dans des conteneurs basés sur Linux. Vous pouvez ré-architecturer vos applications héritées vers des architectures modernes basées sur des conteneurs et les exploiter sur AKS.
É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.
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.
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.
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 des bases de données, y compris les fichiers ASSO, DATA, WORK et les journaux de protection Adabas, doivent être écrites sur des volumes séparés dans Azure NetApp Files.
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. CONNX fournit une couche de virtualisation des données qui utilise des connecteurs vers Adabas et d’autres sources de données comme Azure SQL Database, Azure Database for PostgreSQL et Azure Database for 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. Alternativement, ou comme solution de secours, vous pouvez établir des connexions avec Azure VPN Gateway. Cependant, nous vous recommandons d’utiliser ExpressRoute pour vous connecter à l’environnement Azure via une connexion privée à haut débit avec sécurité renforcée.
AKS 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. Dans ce scénario, les conteneurs Adabas & Natural sont déployés sur AKS.
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. Dans ce scénario, tous les volumes du système d’exploitation sont stockés sur des disques managés Azure.
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. Dans ce scénario, toutes les données persistantes, comme les fichiers de base de données, les journaux de protection, les données d’application et les fichiers de sauvegarde, utilisent Azure NetApp Files.
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 des modèles de rationalisation cloud vous permettent d’exécuter des applications Adabas & Natural sur Azure : rehost et refactor. Cet article explique comment refactoriser une application à l’aide de conteneurs managés dans AKS. 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. Natural doit s’exécuter sur trois instances VM ou plus (nœuds) pour augmenter l’évolutivité et la disponibilité de l’interface utilisateur (Natural online et ApplinX) et de la couche API (Natural services et 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.
Placez les pods batch Natural dans la même zone de disponibilité (centre de données) que les pods Adabas. Vous devez utiliser des proximity placement groups pour placer les pods batch Adabas et Natural dans le même groupe de nœuds dans la même zone de disponibilité.
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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la 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. Les conteneurs refactorisés doivent être déployés sur un cluster AKS privé avec accès entrant via un serveur API privé et des adresses IP internes. Tout le trafic sortant doit être routé via une couche de pare-feu de sortie.
Optimisation des coûts
L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer les efficacités opérationnelles. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.
Utilisez le cluster autoscaler et le horizontal pod autoscaler pour ajuster le nombre de pods et de nœuds en fonction des conditions de trafic. Les pods Adabas peuvent utiliser l’*horizontal pod autoscaler* pour optimiser les coûts.
Utilisez le vertical pod autoscaler pour analyser et définir les ressources CPU et mémoire nécessaires aux pods. Cette approche optimise l’allocation des ressources.
Choisissez la taille de VM appropriée pour les groupes de nœuds, en fonction des besoins de charge de travail.
Créez plusieurs pools de nœuds avec différentes tailles de VM pour des charges de travail spécifiques. Utilisez des étiquettes de nœuds, des sélecteurs de nœuds et des règles d’affinité pour optimiser l’allocation des ressources.
Choisissez les niveaux de service et la taille du pool de capacité appropriés pour Azure NetApp Files. Pour obtenir des recommandations de gestion des coûts, consultez le modèle de coût pour Azure NetApp Files.
Utilisez la capacité réservée pour Azure NetApp Files.
Pour surveiller et optimiser les coûts, utilisez des outils de gestion des coûts tels que Azure Advisor, Azure Reservations et les plans d’économies Azure.
Pour estimer les coûts d’utilisation, utilisez le calculateur de coûts Azure.
Pour améliorer le suivi et la gestion des coûts, utilisez les tags Azure pour associer les ressources AKS à des charges de travail spécifiques.
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.
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
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'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.
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
Contributeur :
- Francis Simy Nazareth | Spécialiste de la technologie
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 :
- Adabas & Natural
- Azure Kubernetes Service
- Documentation Azure NetApp Files
- Réhébergement de mainframe sur des machines virtuelles Azure
- Déplacer le calcul mainframe vers les machines virtuelles Azure