Migration d’applications WebSphere vers Machines Virtuelles Azure

Ce guide décrit ce que vous devez savoir quand vous voulez migrez une application WebSphere Application Server (WAS) traditionnelle existante pour l’exécuter sur Machines Virtuelles Azure. Pour une présentation des solutions WAS traditionnelles disponibles sur Place de marché Azure, consultez Quelles sont les solutions permettant d’exécuter la famille de produits IBM WebSphere sur Azure ?

Prémigration

Pour garantir la réussite de la migration, avant de commencer, effectuez les étapes d’évaluation et d’inventaire décrites dans les sections suivantes.

Définir ce que vous entendez par « migration terminée »

Ce guide, ainsi que les offres correspondantes sur Place de marché Azure, sont un point de départ pour accélérer la migration de vos charges de travail WAS traditionnelle vers Azure. Il est important de définir l’étendue de vos efforts de migration. Par exemple, effectuez-vous un « lift and shift » strict de votre infrastructure existante vers les Machines virtuelles Azure ? Si c’est le cas, vous pourriez être tenté d’intégrer du « lift and improve » lors de la migration.

Il vaut mieux rester aussi proche que possible d’un « lift and shift » pur, en tenant compte des changements nécessaires indiqués dans ce guide. Définissez ce que vous entendez par « migration terminée » afin de savoir quand vous avez atteint cet objectif. Une fois la migration terminée, vous pouvez créer un instantané de vos machines virtuelles comme décrit dans Créer un instantané d’un disque dur virtuel. Après avoir vérifié que vous pouvez restaurer avec succès votre snapshot, vous pouvez procéder aux améliorations sans craindre de perdre les progrès réalisés jusqu’à présent en matière de migration.

Assurez-vous que la cible est la cible appropriée pour votre effort de migration.

La première étape d’une migration réussie d’une application WAS vers Azure consiste à sélectionner la cible de migration la plus appropriée.

WebSphere Application Server traditional fonctionne bien sur les machines virtuelles Azure. La cible machine virtuelle est le choix le plus facile, car elle ressemble le plus à un déploiement local. L’expérience d’administration et de déploiement des machines virtuelles est analogue à celle que vous avez sur place.

On peut également migrer vers des conteneurs en convertissant la charge de travail traditionnelle WAS en conteneurs d’applications. Vous pouvez exécuter la cible conteneur sur Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift. La contrepartie de cette facilité est le coût économique.

D’une manière générale, le coût par minute d’une solution basée sur une machine virtuelle est plus élevé que celui d’une solution avec des conteneurs. Bien qu’une solution basée sur des conteneurs soit moins coûteuse, vous devez limiter votre application pour qu’elle s’adapte aux exigences de la plateforme d’orchestration des conteneurs.

Si la minimisation des changements est le facteur le plus important pour votre effort de migration, envisagez une migration basée sur des machines virtuelles. Dans ce cas, consultez Migrer des applications WebSphere vers des Machines virtuelles Azure.

Si vous pouvez vous accommoder de la conversion de votre application pour qu’elle s’exécute dans des conteneurs et ainsi réduire les coûts d’exécution, envisagez une migration basée sur AKS ou Azure Red Hat OpenShift.

Pour la migration basée sur AKS, vous pouvez commencer avec le niveau Gratuit. Bénéficiez d’une gestion gratuite des clusters et payez uniquement les machines virtuelles, le stockage associé et les ressources réseau utilisées. Dans ce cas, consultez Migrer des applications WebSphere vers Azure Kubernetes Service.

Pour la migration basée sur Azure Red Hat OpenShift, en plus des coûts de calcul et d’infrastructure, les nœuds d’application ont un autre coût pour le composant de licence OpenShift. Celui-ci est facturé en fonction du nombre de nœuds d’application et du type d’instance. Utilisez une tarification à la demande ou des instances réservées, selon l’option la plus adaptée aux besoins de votre charge de travail et de votre entreprise. Dans ce cas, consultez Migrer des applications WebSphere vers Azure Red Hat OpenShift.

Les guides pratiques de la documentation Azure Red Hat OpenShift abordent certains aspects pertinents pour la migration. Pour consulter la liste complète des guides pratiques, consultez la documentation Azure Red Hat OpenShift.

Déterminez si les offres prédéfinies Place de marché Azure sont un bon point de départ

IBM et Microsoft se sont associés pour proposer un ensemble de modèles de solutions Azure sur Place de marché Azure afin de fournir un point de départ solide pour la migration vers Azure. Pour obtenir la liste des offres, consultez Exécutez la famille de produits WebSphere et Liberty sur Microsoft Azure, puis choisissez celle qui correspond le mieux à votre déploiement existant. Vous pouvez consulter la liste des offres dans l’article de présentation Quelles solutions permettent d’exécuter la gamme de produits IBM WebSphere sur Azure ?

Si aucune des offres existantes ne constitue un bon point de départ, vous devez reproduire le déploiement à la main en utilisant les ressources de la machine virtuelle Azure. Vous trouverez le guide pas à pas dans Tutoriel : Installer manuellement IBM WebSphere Application Server Network Deployment traditionnel sur des machines virtuelles Azure. Pour plus d’informations, consultez Qu’est-ce que l’IaaS ?

Déterminez si la version traditionnelle de WAS est compatible

Votre version WAS traditionnelle existante doit être compatible avec la version des offres IaaS. Vous trouverez les informations sur la version dans la page de présentation de IBM WebSphere Application Server Single Instance sur machine virtuelle Azure et de IBM WebSphere Application Server Cluster sur machines virtuelles Azure. Si votre version WAS traditionnelle existante n’est pas compatible avec cette version, vous devez reproduire le déploiement à la main en utilisant les ressources Azure IaaS. Pour plus d’informations, consultez Qu’est-ce que l’IaaS ?

Inventorier la capacité des serveurs

Documentez le matériel (mémoire, processeur, disque) du ou des serveurs de production actuels, ainsi que le nombre moyen et maximal de demandes et l’utilisation des ressources. Ces informations doivent indiquer le choix de la taille de la machine virtuelle. Pour plus d’informations, consultez Tailles de Cloud Services.

Répertorier tous les secrets

Avant l’avènement des technologies de « configuration en tant que service » comme Azure Key Vault, le concept de « secrets » n’était pas bien défini. Vous aviez plutôt un ensemble disparate de paramètres de configuration qui fonctionnaient en réalité comme ce que nous appelons maintenant des « secrets ». Avec les serveurs d’applications comme WAS, ces secrets se trouvent dans de nombreux fichiers de configuration et magasins de configurations différents. Recherchez les secrets et mots de passe dans l’ensemble des propriétés et fichiers de configuration présents sur le ou les serveurs de production. Vous pouvez également trouver des fichiers de configuration contenant des mots de passe ou des informations d’identification au sein de votre application. WAS stocke les données de configuration dans plusieurs documents dans une hiérarchie en cascade de répertoires. La plupart des documents de configuration ont du contenu XML. Pour en savoir plus, consultez documents de configuration et concepts de base d’Azure Key Vault.

Inventorier tous les certificats

Documentez tous les certificats utilisés pour les points de terminaison SSL publics. Vous pouvez voir tous les certificats présents sur les serveurs de production en exécutant la commande suivante :

keytool -list -v -keystore <path to keystore>

Pour en savoir plus, consultez le document IBM Gestion des certificats dans SSL

Valider le bon fonctionnement de la version Java prise en charge

L’utilisation de WAS sur des machines virtuelles Azure nécessite une version spécifique de Java. Vous devez donc vérifier que votre application s’exécute correctement avec cette version prise en charge.

IBM Java 8 est fourni avec la distribution WAS9. Nous vous recommandons d’utiliser le JRE Java fourni par IBM. Pour en savoir plus, consultez Java SE 8 dans WebSphere Application Server traditionnel V9.

Si vous souhaitez passer à un autre SDK Java, suivez les instructions du document IBM Changer le SDK Java dans WebSphere Application Server.

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. Par exemple, des sources de données telles que des bases de données peuvent avoir un nom JNDI associé qui permet à JPA de lier correctement des instances de à une base de données particulière. Pour en savoir plus sur les ressources JNDI et les bases de données, consultez WebSphere Data Sources dans la documentation IBM. D’autres ressources liées à JNDI, telles que les répartiteurs de messages JMS, peuvent nécessiter une migration ou une reconfiguration. Pour plus d'informations sur la configuration de JMS, consultez Utilisation des ressources JMS.

Inspecter la configuration de votre profil

L’unité de configuration principale dans WAS est le profil. C’est pourquoi le fichier resources.xml contient une multitude de configurations que vous devez prendre bien en considération pour la migration. Le fichier contient des références à des fichiers XML supplémentaires qui sont stockés dans des sous-répertoires. IBM conseille d’utiliser normalement la console IBM pour configurer les objets et services gérables de WAS et autoriser WAS à conserver le dossier profiles/profile-name. Pour en savoir plus, consultez Gestion de profils sur les systèmes d’exploitation distribués et IBM i.

Au sein de votre application

Inspectez le fichier deployment.xml et/ou le fichier WEB-INF/web.xml.

Déterminer si la réplication de session est utilisée

Si votre application s’appuie sur la réplication de session, vous disposez des options suivantes :

• Pour les sessions HTTP, en fonction du niveau de gestion de session, vous pouvez utiliser la mémoire ou une base de données pour stocker les données de session.
• Pour les sessions distribuées, vous pouvez stocker les sessions dans une base de données à l’aide de la persistance des sessions en base de données.
• Pour le Cache dynamique, vous pouvez gérer les données de session par réplication de mémoire à mémoire ou dans une base de données.
• Refactorisez votre application afin d’utiliser une base de données pour la gestion des sessions.
• Refactorisez votre application pour externaliser la session dans Azure Redis Service. Pour plus d’informations, consultez Azure Cache pour Redis.

Pour toutes ces options, il est judicieux de maîtriser la façon dont WAS effectue la réplication de l’état de session HTTP. Pour en savoir plus, consultez Administration des beans de session dans la documentation IBM.

Documenter les sources de données

Si votre application utilise des bases de données, vous devez capturer les informations suivantes :

• Quel est le nom de la source de données ?
• Quelle est la configuration du pool de connexions ?
• Où trouver le fichier JAR du pilote JDBC ?

Pour plus d'informations sur les pilotes JDBC dans WebSphere Application Server, consultez Utilisation des pilotes JDBC avec WebSphere Application Server.

Déterminer si WAS a été personnalisé

Déterminez quelles personnalisations parmi les suivantes ont été apportées et capturez ce qui a été fait.

• Est-ce que les scripts de démarrage ont changé ? Ces scripts incluent wsadmin, AdminControl, AdminConfig, AdminApp et AdminTask.
• Est-ce que des paramètres spécifiques ont été transmis à JVM ?
• Est-ce que des fichiers JAR ont été ajoutés au classpath du serveur ?
• Des mécanismes au niveau du système d’exploitation, tels que , ont-ils été utilisés pour que les composants WAS démarrent automatiquement après le redémarrage d’un serveur ?

Vous devez tenir compte des considérations relatives à la migration en fonction des réponses à ces questions.

Déterminer si une connexion à un service local est nécessaire

Si votre application doit accéder à vos services locaux, vous devez provisionner l’un des services de connectivité d’Azure. Pour plus d’informations, consultez Connecter un réseau local à Azure. Vous avez également besoin de refactoriser votre application pour qu’elle utilise les API publiques disponibles que vos ressources locales exposent.

Déterminer si les files d’attente ou les rubriques JMS (Java Message Service) sont en cours d’utilisation

Si votre application utilise des files d’attente ou des rubriques JMS, vous devez les migrer vers un serveur JMS hébergé en externe. Azure Service Bus et le protocole AMQP (Advanced Message Queuing Protocol) peuvent être une stratégie de migration pour ceux qui utilisent JMS. Pour en savoir plus, voir Utiliser Java Message Service 1.1 avec Azure Service Bus standard et AMQP 1.0.

Si vous avez configuré des magasins persistants JMS, vous devez capturer leur configuration et les appliquer après la migration.

Si vous utilisez IBM MQ, vous pouvez migrer ce logiciel vers des machines virtuelles Azure et l’utiliser tel quel.

Microsoft offre une solution pour intégrer IBM MQ à Logic Apps. Pour plus d’informations, voir Se connecter à un serveur IBM MQ à partir d’un flux de travail dans Azure Logic Apps.

Déterminer si vous utilisez vos propres bibliothèques Shared Java EE que vous avez créées

Si vous utilisez la fonctionnalité de bibliothèque Shared Java EE, vous avez deux options :

• Refactorisez votre code d’application pour supprimer toutes les dépendances de vos bibliothèques et incorporez plutôt la fonctionnalité directement dans votre application.
• Ajoutez les bibliothèques dans le classpath du serveur.

Déterminer si les bundles OSGi sont utilisés

Si vous avez utilisé des bundles OSGi ajoutés à WAS, vous devez ajouter les fichiers JAR équivalents directement à votre application web.

Déterminer si votre application contient du code propre au système d’exploitation

Si votre application contient du code avec des dépendances vis-à-vis du système d’exploitation hôte, vous devez la refactoriser pour supprimer ces dépendances. Par exemple, vous devrez peut-être remplacer toute utilisation de ou dans les chemins du système de fichiers par ou si votre application s’exécute sous Windows.

Déterminer si IBM Integration Bus est en cours d’utilisation

Si votre application utilise IBM Integration Bus, vous devez capturer la façon dont il est configuré. Pour en savoir plus, consultez la documentation d’IBM Integration Bus.

Déterminer si votre application est composée de plusieurs WAR

Si votre application est composée de plusieurs WAR, vous devez traiter chacun de ces WAR comme des applications distinctes et suivre ce guide pour chacun d’entre eux.

Déterminer si votre application est empaquetée en tant que fichier EAR

Si votre application est empaquetée en tant que fichier EAR, veillez à examiner les fichiers application.xml, ibm-application-bnd.xmi et ibm-application-ext.xmi et à capturer leur configuration. Pour en savoir plus, consultez Création de l’archive d’entreprise (EAR) dans WebSphere.

Identifier tous les processus et démons extérieurs exécutés sur les serveurs de production

Si vous avez des processus qui s’exécutent en dehors du serveur d’applications, comme les démons de supervision, vous devez les éliminer ou les migrer ailleurs.

Déterminer si le système de fichiers est utilisé et de quelle manière

Les systèmes de fichiers de machine virtuelle fonctionnent de la même façon que les systèmes de fichiers locaux au niveau de la persistance, du démarrage et de l’arrêt. Cela dit, il est important de connaître vos besoins en système de fichiers et de s’assurer que les machines virtuelles ont une taille de stockage et des performances adéquates.

Contenu statique en lecture seule

Si votre application sert actuellement du contenu statique, vous avez besoin d’un autre emplacement pour celui-ci. Vous devez envisager de déplacer du contenu statique vers stockage Blob Azure et d’ajouter Azure Front Door pour des téléchargements rapides globalement. Pour plus d’informations, consultez Hébergement de sites web statiques dans Stockage Azure et Intégrer un compte Stockage Azure à Azure Front Door.

Déterminer la topologie réseau

L’ensemble actuel d’offres Place de marché Azure est un point de départ pour votre migration. Si l’offre ne couvre pas les aspects de l’architecture que vous devez migrer, il faut capturer la topologie de réseau de votre déploiement existant. Ensuite, vous devez reproduire cette topologie de réseau dans Azure, même après avoir mis en place l’offre de base avec l’un des modèles de solution.

La topologie de réseau est un sujet très vaste, mais les références suivantes peuvent vous guider dans vos efforts de migration :

• Étant donné que les sources de données sont des serveurs distincts dans un système WAS, vous devez les prendre en compte dans le cadre de l’analyse de la topologie réseau. Pour en savoir plus, consultez Sources de données de WebSphere Application Server.
• Les sources de messagerie sont également des serveurs distincts. Pour en savoir plus, consultez Topologies de réseau : interopération à l’aide du fournisseur de messagerie WebSphere MQ.
• L’équilibrage de charge est un critère essentiel. La référence suivante couvre l’aspect WAS de l’équilibrage de charge : Cluster à équilibrage de charge de WebSphere Application Server Network Deployment.

Prendre en compte l’utilisation des adaptateurs JCA et des adaptateurs de ressources

Si votre application existante utilise des adaptateurs JCA ou d’autres adaptateurs de ressources pour se connecter à d’autres systèmes de l’entreprise, assurez-vous d’appliquer la configuration pour ces artefacts à WAS qui s’exécute sur les machines virtuelles Azure. Pour en savoir plus, consultez Adaptateurs de ressources relationnelles et JCA dans la documentation IBM.

Compte d’authentification et d’autorisation

La plupart des applications présente une forme d’authentification et d’autorisation. Si vous utilisez OpenID pour l’authentification, vous pouvez configurer l’authentification OpenID connect avec Microsoft Entra ID. Pour en savoir plus, consultez Authentification OpenID Connect avec Microsoft Entra ID.

Déterminer si le clustering WAS est utilisé

Probablement, vous avez déployé votre application sur plusieurs serveurs WAS pour obtenir une haute disponibilité. Vous pouvez migrer ces clusters directement de votre installation locale vers WAS exécuté sur des machines Virtuelles Azure. Pour en savoir plus, consultez WebSphere Application Server Network Deployment dans la documentation IBM.

Prendre en compte les exigences d’équilibrage de charge

L’équilibrage de charge est un élément essentiel du processus de migration de votre cluster WAS vers Azure. La solution la plus simple consiste à utiliser la prise en charge native de Azure Application Gateway ou de IBM HTTP Server fournie dans l’offre Place de marché Azure pour IBM WebSphere Application Server Cluster.

Pour un résumé des capacités d’Azure Application Gateway par rapport aux autres solutions d’équilibrage de charge Azure, consultez Options d’équilibrage de charge.

Déterminer si la fonctionnalité Java EE Application Client est utilisée

Si votre application utilise la fonctionnalité Java EE Application Client, celle-ci devrait continuer à fonctionner de la même manière après la migration vers des machines virtuelles Azure. Pour plus d’informations, consultez Utilisation des modules d’application client Java EE.

Migration

Sélectionnez une offre WAS traditionnelle sur des machines virtuelles Azure

Les offres suivantes sont disponibles pour WAS sur machines virtuelles Azure.

Lors du déploiement d’une offre, il vous sera demandé de choisir la taille de la machine virtuelle pour vos nœuds WAS. Il est important de prendre en compte tous les aspects de dimensionnement (mémoire, processeur, disque) dans le choix de la taille de machine virtuelle. Pour plus d’informations, consultez Tailles des services Cloud (classique).

• IBM WebSphere Application Server, instance unique sur machine virtuelle Azure

  Cette offre automatise la plupart des étapes classiques de provisionnement d’une seule instance WebSphere sur une machine virtuelle Azure. Elle crée un profil de serveur d’application avec la console d’administration WAS.

• IBM WebSphere Application Server Cluster sur machines virtuelles Azure

  Cette offre automatise la plupart des étapes classiques pour provisionner un cluster WebSphere sur des machines virtuelles Azure. Elle crée un gestionnaire de déploiement avec la console d’administration WAS sur une machine virtuelle Azure et le nombre requis d’agents de nœud sur des machines virtuelles Azure séparées.

Configurer l’offre

Une fois que vous avez sélectionné l’offre avec laquelle commencer, déployez cette offre en suivant les instructions de Déployer un cluster WebSphere Application Server (traditional) sur des machines virtuelles Azure.

Migrer les profils

Une fois que vous avez provisionné l’offre, vous pouvez examiner la configuration du profil. Pour plus d’informations, consultez Concepts de profil dans la documentation IBM.

Connecter les bases de données

Après avoir migré les profils, connectez les bases de données en suivant les instructions de la configuration de la source de données WebSphere Application Server dans la documentation IBM.

Compte pour les KeyStores

Vous devez prendre en compte la migration de tous les magasins de certificats et de clés SSL utilisés par votre application. Pour plus d’informations, consultez les configurations des fichiers de clés pour SSL dans la documentation IBM.

Connecter les sources JMS

Après avoir connecté les bases de données, configurez JMS en suivant les instructions de configuration de JMS dans IBM WebSphere Application Server dans la documentation IBM.

Compte pour l’authentification et l’autorisation

La plupart des applications présente une forme d’authentification et d’autorisation. Si vous utilisez OpenID pour l’authentification, vous pouvez configurer l’authentification OpenID connect avec Microsoft Entra ID. Pour en savoir plus, consultez Authentification OpenID Connect avec Microsoft Entra ID.

Tenir compte de la journalisation

Vous pouvez configurer Elastic Stack en suivant les instructions dans la documentation IBM, à la rubrique Analyse des journaux de WebSphere Application Server avec Elastic Stack. Azure offre un support pour Elastic. Pour en savoir plus, consultez Qu’est-ce que l’intégration d’Elastic à Azure ? Vous pouvez mettre à profit les informations contenues dans ces deux ressources pour obtenir une solution de journalisation optimisée pour Azure pour WAS sur des machines virtuelles.

Migration de vos applications

Les techniques utilisées pour déployer des applications de l’équipe de développement sur des serveurs de test, de préproduction et de production varient considérablement d’un cas à l’autre. Dans certains cas, une plateforme CI/CD très évoluée permet de déployer les applications sur WebSphere Application Server. Dans d’autres cas, le processus peut être plus manuel. L’un des avantages de l’utilisation des machines virtuelles Azure pour migrer les applications WAS traditionnelles vers le cloud est que vos processus existants continuent de fonctionner.

Vous devez configurer le groupe de sécurité réseau que l’offre prévoit pour autoriser l’accès depuis votre pipeline CI/CD ou votre système de déploiement manuel. Pour plus d’informations, consultez Groupe de sécurité réseau.

Test

Vous devez configurer tous les tests en conteneur sur les applications pour accéder aux nouveaux serveurs qui s’exécutent dans Azure. Comme pour CI/CD, vous devez vous assurer que les règles de sécurité réseau nécessaires permettent à vos tests d’accéder aux applications déployées sur Azure. Pour plus d’informations, consultez Groupes de sécurité réseau.

Post-migration

Une fois que vous avez atteint les objectifs de migration que vous avez définis à l’étape de pré-migration, effectuez des tests d’acceptation de bout en bout pour vérifier que tout fonctionne comme prévu. Pour obtenir des conseils sur certaines améliorations possibles après la migration, consultez les recommandations suivantes :

• Utilisez stockage Azure pour servir du contenu statique monté sur les machines virtuelles. Pour plus d’informations, consultez Attacher ou détacher un disque de données pour une machine virtuelle de laboratoire dans Azure DevTest Labs.

• Déployez vos applications sur votre cluster WAS migré avec Azure DevOps. Pour plus d’informations, consultez Bien démarrer avec la documentation Azure DevOps.

• Si vous avez déployé WAS traditionnel avec Azure Application Gateway, il se peut que vous souhaitiez configurer davantage Application Gateway. Pour plus d’informations, consultez Présentation de la configuration d’Application Gateway.

• Améliorer votre topologie réseau avec des services d’équilibrage de charge avancés. Pour plus d’informations, consultez Utilisation des services d’équilibrage de charge dans Azure.

• Utilisez Azure Managed Identities pour gérer les secrets et attribuer un accès basé sur les rôles aux ressources Azure. Pour plus d’informations, consultez Que sont les identités gérées pour les ressources Azure ?

• Intégrez l’authentification et l’autorisation Java EE de WAS avec Microsoft Entra ID. Pour plus d’informations, consultez le guide de démarrage de l’intégration de Microsoft Entra ID avec des applications.

• Utiliser Azure Key Vault pour stocker toutes les informations qui servent de « secrets ». Pour plus d’informations, consultez Concepts de base d’Azure Key Vault.