Cet article décrit une approche de migration pour changer la plateforme de vos charges de travail AIX et les envoyer vers le cloud. Vous pouvez utiliser Azure Functions pour une architecture serverless, ou utiliser Azure Virtual Machines pour conserver un modèle serverful.
Envisagez une stratégie de migration pour changer la plateforme des charges de travail AIX afin d’optimiser votre retour sur investissement (ROI) lorsque vous migrez des applications héritées vers Azure. Les migrations de changement de plateforme nécessitent peu de modifications, mais offrent des avantages natifs cloud similaires à une migration de refactorisation.
Les avantages d’une migration de changement de plateforme sont les suivants :
- Une réduction du coût total de possession (TCO).
- Une amélioration de l'agilité de l’entreprise.
- Une amélioration de la résilience opérationnelle.
Architecture (avec changement de plateforme)
Téléchargez un fichier Visio de cette architecture.
Workflow
Ce workflow correspond à l’architecture précédente.
Les requêtes des utilisateurs et les intégrations d’API entrantes sont transférées vers Azure Application Gateway sur TCP/443 (HTTPS), qui fournit une fonctionnalité de pare-feu d’applications web (WAF). Application Gateway envoie les requêtes en tant que requêtes de proxy inverse à différents services hébergés par Red Hat JBoss Enterprise Application Platform (EAP).
Java Web Services interroge la base de données Oracle (TCP/1521). Le temps de réponse de la requête web synchrone est inférieur à 50 millisecondes (ms).
Une requête asynchrone, telle que la planification d’une tâche de traitement par lots, place un enregistrement dans une table de base de données qui agit comme une file d’attente dans la couche d'application.
Remarque
À l’avenir, Stockage File d’attente Azure remplacera la table de base de données pour vous permettre de toujours avoir accès à des tâches d’analyse en cours d’exécution.
La tâche cron, écrite dans le script KornShell (ksh), est portée vers Bash et s’exécute sur un serveur Red Hat Enterprise Linux (RHEL) distinct dans les Virtual Machine Scale Sets d'Azure. La tâche cron s’exécute toutes les 15 minutes, y compris au démarrage du système, pour interroger la file d’attente de la base de données Oracle. Les tâches sont exécutées une à la fois pour chaque hôte. Virtual Machine Scale Sets parallélise les tâches d’analyse de longue durée. Cette solution ne requiert pas de traitement par lots en heures creuses pour limiter l’effet sur les performances du système pendant les heures de bureau.
Azure Communication Services envoie des alertes par e-mail via l’outil Azure CLI (docs). Les identités managées attribuées par le système Azure, telles que
az login --identity, authentifient la machine virtuelle.Les résultats de la tâche d’analyse sont envoyés à un partage Azure Files via un SMBv3 sécurisé (TCP/445), qui utilise également des identités managées attribuées par le système.
Composants
Microsoft Entra ID élimine l’approbation basée sur le réseau et fournit des identités managées attribuées par le système, ce qui améliore la sécurité.
Azure App Service élimine la nécessité d’administrer un système d’exploitation et un serveur, ce qui augmente l’efficacité opérationnelle et l'agilité de l’entreprise.
Application Gateway est un service entièrement managé et évolutif qui fournit un pare-feu d’applications web et une fonctionnalité de proxy inverse.
Azure Files fournit des rapports de données publiés via un service managé.
Azure Functions est une plateforme de calcul serverless basée sur les événements, qui permet de développer efficacement du code dans le langage de programmation spécifié.
Une machine virtuelle Azure est utilisée par la base de données Oracle et les nœuds d’analyse SAS.
Azure Compute Gallery crée et stocke des images pour la base de données Oracle et les nœuds d’analyse SAS. Il existe deux galeries : une dans la région primaire et une dans la région de récupération d’urgence.
Communication Services envoie des e-mails à l'aide d'un utilitaire CLI. Ce service remplace la commande
mailxsur AIX.
Autres solutions
Une autre solution est une architecture serverful complète qui conserve tous les composants intergiciels (middleware) tels qu’ils sont.
Cette solution est similaire à l’architecture d’origine, qui remplit un mandat « like for like » (identique) qui régit les opérations de nombreuses organisations informatiques. Cette solution alternative a un coût équivalent à l’architecture d’origine, mais ne fournit pas les avantages de l’architecture dont la plateforme a été changée. Par exemple :
Économies sur les licences : la solution alternative conserve WebSphere et ajoute d’autres nœuds RHEL.
Efficacité opérationnelle : la solution alternative conserve le même nombre de serveurs à gérer.
Agilité de l’entreprise : avec la solution alternative, la création de rapports s'effectue uniquement la nuit, sans analyse quotidienne basée sur la mise à l’échelle automatique durant la journée.
Détails du scénario
Choisissez un modèle serverless ou serverful en fonction de la portabilité de vos applications existantes, des préférences de workflow de votre équipe et de sa feuille de route technologique.
Comme l'architecture d'origine, l'architecture dont la plateforme a été changée possède une base de données Oracle, mais sa plateforme a été changée vers un système d’exploitation RHEL sur Azure Virtual Machines. Pour retrouver l’application entièrement managée Azure App Service dans l’architecture dont la plateforme a été changée, Red Hat JBoss EAP remplace l’application Java WebSphere.
Architecture (d’origine)
Téléchargez un fichier Visio de cette architecture.
Workflow
Ce workflow correspond à l’architecture précédente.
Les requêtes des utilisateurs et les intégrations d’API entrantes sont transférées vers l’équilibreur de charge F5 local sur TCP/443 (HTTPS), puis sont envoyées en tant que requêtes de proxy inverse vers différents Java Web Services hébergés par IBM WebSphere.
Java Web Services interroge la base de données Oracle via TCP/1521. Dans la plupart des cas, le temps de réponse de la requête web synchrone est inférieur à 1 seconde (s), mais supérieur à 300 ms selon les tests et l’analyse weblog.
Une requête asynchrone, telle que la planification d’une tâche de traitement par lots, place un enregistrement dans une table de base de données Oracle qui agit comme une file d’attente dans la couche d'application.
Une tâche cron, écrite dans un script ksh, interroge la file d’attente dans la base de données Oracle et récupère les tâches d’analyse SAS à exécuter. Le client doit effectuer un traitement par lots la nuit pour limiter l’effet sur les performances du système pendant les heures de bureau.
Les alertes par e-mail informent les utilisateurs et les administrateurs via SMTP (TCP/25) des heures de démarrage et d’achèvement de la tâche, ainsi que des résultats de réussite ou d’échec.
Les résultats de la tâche d’analyse sont transmis à un lecteur partagé via NFS (TCP+UDP/111,2049) pour la collecte via SMBv3 (TCP/445).
Détails du scénario
Cette architecture d’origine évalue une application Java monolithique qui s’exécute sur IBM WebSphere et évalue le traitement par lots à partir de SAS avec orchestration par les scripts ksh. Une base de données Oracle qui s’exécute sur un hôte AIX distinct prend en charge les charges de travail des applications.
Utilisez votre charge de travail d’origine exécutée sur AIX pour déterminer si une stratégie de migration en changeant de plateforme correspond à votre budget de migration. Travaillez à partir de vos résultats souhaités pour déterminer un chemin de migration transformatrice, centrée sur l'application, vers le cloud. Assurez-vous qu'une grande partie de votre code d’application est écrit dans un langage que les services natifs cloud, tels que les architectures serverless et les orchestrateurs de conteneurs, prennent en charge.
Dans ce scénario, Tidal Accelerator a analysé le code de l’application Java et déterminé sa compatibilité avec JBoss EAP. Au début du projet, Azure Pipelines (ou GitHub Actions) est utilisé pour reconstruire l’application en tant que pilote. Le client peut ensuite établir une agilité à partir de pipelines d’intégration et de livraison continues (CI/CD) dans un service managé, tel qu’Azure App Service. Le client ne peut pas obtenir cette fonctionnalité dans son environnement WebSphere local.
Cet exemple conserve la base de données Oracle dans cette phase en raison de la quantité de PL/SQL détectée par Tidal Accelerator pendant la phase d’analyse. Les futures initiatives du client incluent la migration de la base de données Oracle sur RHEL vers une base de données entièrement managée de Azure Database pour PostgreSQL, l’adoption du Stockage File d'attente Azure et l’exécution de tâches SAS entièrement à la demande. Ces efforts correspondent à la feuille de route technologique du client, aux cycles de développement et à la direction commerciale qui a été déterminée lors de l’entretien avec le propriétaire de l’application. La capture d’écran suivante montre un entretien dans Tidal Accelerator.
Cas d’usage potentiels
Vous pouvez utiliser cette architecture pour les migrations AIX vers Azure qui comportent l’analytique données, la gestion des relations client (CRM), les couches d’intégration mainframe dans une configuration cloud hybride et d’autres solutions logicielles personnalisées dans des scénarios de gestion des stocks et des entrepôts.
Vous pouvez utiliser cette architecture pour les charges de travail d’application traditionnelles avec des technologies telles que :
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
Cette architecture utilise Azure Site Recovery pour mettre en miroir les machines virtuelles Azure de la base de données dans une région Azure secondaire pour un basculement et une reprise d’activité rapides en cas de défaillance d’une région Azure entière. De même, Azure Files utilise le stockage géoredondant.
Les nœuds de traitement des données utilisent des disques managés redondants interzones (RA-ZRS) pour assurer la résilience en cas de panne de zone. Pendant une panne de région entière, vous pouvez reprovisionner des nœuds de traitement des données dans une région autre que celle de leur image de machine virtuelle dans la galerie Azure Compute Gallery redondante.
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 adopte une approche d’infrastructure immuable pour les déploiements d’applications et analyse de manière proactive le code dans les pipelines Azure pour sécuriser les données sensibles en production. Elle intègre une approche « shift left » (décalage vers la gauche) pour l’analyse de la sécurité et exécute fréquemment des déploiements de pipeline CI/CD pour améliorer l’adhésion actuelle des logiciels et réduire la dette technique.
Optimisation des coûts
L’optimisation des coûts consiste à examiner 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.
Cette solution supprime autant de composants serverful que possible, ce qui réduit les coûts d’exploitation de plus de 70 %. Cette architecture réduit les coûts des calculs et des licences logicielles.
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 la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.
L’équipe produit assure elle-même la prise en charge dans Azure, ce qui réduit le temps de résolution des tickets d’incidents signalés. En outre, la quantité de tickets non-remis, ou encore le nombre de tickets attribués d’un groupe à un autre, est égal(e) à zéro car une équipe produit prend en charge l’ensemble de la pile d'applications dans Azure.
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
En fonction de la situation, le client adopte Azure App Service afin de pouvoir effectuer automatiquement un scale-up et un scale-out de ses besoins de calcul pour s’aligner sur la demande d’application. Cette élasticité garantit des performances d’application cohérentes pendant les heures de pointe. Cette approche est également rentable.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
Richard Berry| Responsable de programme senior
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
Pour plus d’informations sur l’utilisation de la solution Tidal Accelerator, contactez l’équipe Microsoft Tidal Cloud.
Pour plus d’informations sur la migration vers Azure, contactez l’équipe Legacy Migrations Engineering.