Partager via

Migration d’applications WebSphere vers Machines Virtuelles Azure

  • Article

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 vue d’ensemble des solutions traditionnelles WAS disponibles dans Azure Marketplace, consultez Quelles sont les solutions qui permettent 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 Azure Marketplace, 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, vous tenez-vous à un strict « lift-and-shift » entre votre infrastructure existante et les machines virtuelles Azure ? Si c’est le cas, vous pouvez être tenté d’apporter des améliorations au fur et à mesure de la migration.

Il est préférable de s’en tenir le plus possible à un « lift-and-shift » pur et dur, tout en tenant compte des changements nécessaires, comme détaillé dans ce guide. Définissez ce que vous entendez par « migration terminée » afin de savoir quand vous avez atteint cet objectif. Lorsque vous avez atteint votre « migration terminée », vous pouvez prendre 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.

WAS s’exécute correctement sur des 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 la section 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 la section 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 la section 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 obtenir la liste complète des guides pratiques, consultez la documentation Azure Red Hat OpenShift.

Déterminez si les offres prédéfinies Azure Marketplace 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 Azure Marketplace afin de fournir un point de départ solide pour la migration vers Azure. Pour obtenir la liste des propositions, consultez Exécuter la famille de produits WebSphere et Liberty sur Microsoft Azure, puis choisissez celle qui correspond le mieux à votre déploiement existant. Vous pouvez voir la liste des propositions dans l’article de vue d’ensemble Quelles sont les solutions qui permettent d’exécuter la famille 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 les instructions pas à pas dans le Tutoriel : Installer manuellement un déploiement réseau IBM WebSphere Application Server classique 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 de version sur la page de vue d’ensemble d’IBM WebSphere Application Server Single Instance sur une machine virtuelle Azure et IBM WebSphere Application Server Cluster sur des 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 en savoir plus, consultez la rubrique Tailles de services cloud.

Inventorier 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 traditional V9.

Si vous souhaitez basculer vers un autre SDK Java, lisez le document IBM Changer de SDK Java dans WebSphere Application Server.

Inventorier les ressources JNDI

Inventoriez toutes les ressources JNDI. Par exemple, des sources de données comme les bases de données peuvent avoir un nom JNDI associé qui permet à JPA de lier correctement des instances de EntityManager à une base de données en particulier. Pour en savoir plus sur les ressources et les bases de données JNDI, 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 en savoir plus 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 des profils sur les systèmes d’exploitation IBM i et distribués.

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, selon le niveau de gestion de session, vous pouvez utiliser la mémoire ou une base de données pour collecter des données de session.
  • Pour les sessions distribuées, vous pouvez enregistrer des sessions dans une base de données à l’aide de la persistance de session de base de données.
  • Pour le cache dynamique, vous pouvez gérer les données de session dans la réplication mémoire à mémoire ou 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 en savoir plus sur les pilotes JDBC dans WAS, consultez Utilisation de 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 installations au niveau du système d’exploitation, telles que systemd ont-elles été utilisées 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, consulter 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, consultez 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 pouvez avoir besoin de remplacer toute utilisation de / ou \ dans les chemins de système de fichiers par File.Separator ou Paths.get.

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 du package d’archive d’entreprise (EAR) sur 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 aurez besoin d’un autre emplacement pour lui. Vous pouvez envisager de déplacer du contenu statique vers le Stockage Blob Azure et d’ajouter Azure CDN pour accélérer globalement les téléchargements. Pour plus d’informations, consultez Hébergement de sites web statiques dans le service Stockage Azure et Démarrage rapide : Intégrer un compte de stockage Azure à Azure CDN. Vous pouvez également déployer directement le contenu statique dans une application du plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Contenu statique publié dynamiquement

Si votre application autorise le contenu statique chargé/produit par votre application mais immuable après sa création, vous pouvez utiliser le Stockage Blob Azure et Azure CDN comme décrit ci-dessus, avec une fonction Azure pour gérer les chargements et l’actualisation du réseau CDN. Nous avons mis à votre disposition un exemple d’implémentation dans Chargement et préchargement CDN de contenu statique avec Azure Functions. Vous pouvez également déployer directement le contenu statique dans une application du plan Azure Spring Apps Enterprise. Pour plus d’informations, consultez Déployer des fichiers statiques web.

Déterminer la topologie réseau

L’ensemble actuel d’offres Azure Marketplace 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 :

Compte pour 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.

Prendre en compte 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 la section Authentification OpenID Connect avec Microsoft Entra ID.

Déterminer si le clustering WAS est utilisé

Vous avez très probablement déployé votre application sur plusieurs serveurs WAS pour bénéficier d’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 intégrée d’Azure Application Gateway ou d’IBM HTTP Server fournie dans l’offre Azure Marketplace pour IBM WebSphere Application Server Cluster.

Pour un résumé des fonctionnalité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 Using Java EE Client Application Modules.

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 la section Tailles pour les services cloud (classique).

Provisionner l’offre

Une fois que vous avez sélectionné l’offre avec laquelle commencer, provisionnez-la en suivant les instructions fournies dans Déployer WebSphere Application Server (traditional) Cluster 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, vous pouvez connecter les bases de données en suivant les instructions dans la documentation IBM : Configuration de la source de données WebSphere Application Server.

Tenir compte des magasins de clés

Vous devez tenir compte de la migration des magasins de clés SSL utilisés par votre application. Pour en savoir plus, consultez Configurations d’un magasin de clés pour SSL dans la documentation IBM.

Connecter les sources JMS

Après voir connecté les bases de données, vous pouvez configurer JMS en suivant les instructions dans la documentation IBM : Configuration de JMS dans IBM WebSphere Application Server.

Prendre en compte 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 la section 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 : Analyse des journaux 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 combiner les connaissances de 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 Groupes 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.

Postmigration

Une fois que vous avez atteint les objectifs de migration que vous aviez définis dans 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 :