Migration d’applications WebSphere vers Machines Virtuelles Azure

  • Article

Ce guide décrit ce que vous devez savoir quand vous souhaitez migrer une application traditionnelle WebSphere Application Server (WAS) existante à exécuter sur Azure Machines Virtuelles. Pour obtenir une vue d’ensemble des solutions traditionnelles WAS disponibles dans 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 de Place de marché Azure correspondantes, constituent un point de départ pour accélérer la migration de vos charges de travail traditionnelles WAS 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. Une fois que vous avez atteint votre « migration terminée », vous pouvez prendre une instantané de votre Machines Virtuelles, comme décrit dans Créer un instantané d’un disque dur virtuel. Une fois que vous avez vérifié que vous pouvez effectuer une restauration à partir de votre instantané, vous pouvez effectuer les améliorations sans craindre de perdre la progression de la migration que vous avez obtenue jusqu’à présent.

Vérifiez 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 Azure Machines Virtuelles. La cible de machine virtuelle est le choix le plus simple, car elle ressemble le plus étroitement à un déploiement local. L’expérience d’administration et de déploiement pour les machines virtuelles est analogue à ce que vous avez en local.

Une autre option consiste à migrer vers des conteneurs en convertissant la charge de travail traditionnelle WAS en conteneurs d’applications. Vous pouvez exécuter la cible de conteneur sur Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift. Le compromis pour cette facilité est le coût économique.

En règle générale, le coût par minute d’une solution basée sur une machine virtuelle est plus élevé que les conteneurs. Bien qu’une solution basée sur un conteneur coûte moins cher d’être exécutée, vous devez contraindre votre application à s’adapter aux exigences de la plateforme d’orchestration de conteneurs.

Si la réduction du changement est le facteur le plus important pour votre effort de migration, envisagez une migration basée sur une machine virtuelle. Dans ce cas, consultez Migrer des applications WebSphere vers Azure Machines Virtuelles.

Si vous pouvez tolérer la conversion de votre application pour qu’elle s’exécute dans des conteneurs afin de 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 à utiliser le niveau Gratuit. Bénéficiez de la gestion gratuite des clusters et payez uniquement pour les machines virtuelles, le stockage associé et les ressources réseau consommé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. Ce coût est facturé en fonction du nombre de nœuds d’application et du type d’instance. Utilisez la tarification à la demande ou les instances réservées, selon les 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 couvrent certains aspects pertinents pour la migration. Pour obtenir la liste complète des guides pratiques, consultez la documentation Azure Red Hat OpenShift.

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

IBM et Microsoft ont collaboré pour apporter un ensemble de modèles de solution Azure à Place de marché Azure pour fournir un point de départ solide pour la migration vers Azure. Pour obtenir la liste des offres, consultez Exécuter la famille WebSphere de produits et Liberty sur Microsoft Azure, puis choisissez celle qui correspond le plus étroitement à votre déploiement existant. Vous pouvez voir la liste des offres dans l’article vue d’ensemble Quelles sont les solutions pour exécuter la famille de produits IBM WebSphere sur Azure ?

Si aucune des offres existantes n’est un bon point de départ, vous devez reproduire le déploiement à l’aide des ressources de machine virtuelle Azure. Vous trouverez les instructions pas à pas décrites dans le tutoriel : Installez manuellement ibm WebSphere Application Server Network Deployment traditionnel sur Azure Machines Virtuelles. Pour plus d’informations, consultez Qu’est-ce que l’IaaS ?

Déterminer si la version traditionnelle WAS est compatible

Votre version traditionnelle WAS existante doit être compatible avec la version dans les offres IaaS. Vous trouverez les informations de version dans la page 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 traditionnelle WAS existante n’est pas compatible avec cette version, vous devez reproduire le déploiement à l’aide de ressources IaaS Azure. 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 tels que WAS, ces secrets se trouvent dans de nombreux fichiers de configuration et magasins de configuration 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 plus d’informations, consultez les documents de configuration et les 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 plus d’informations, consultez la gestion des certificats de document IBM dans SSL

Valider le bon fonctionnement de la version Java prise en charge

L’utilisation de WAS sur Azure Machines Virtuelles nécessite une version spécifique de Java. Vous devez donc vérifier que votre application s’exécute correctement à l’aide de 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 plus d’informations, consultez Java SE 8 dans WebSphere Application Server traditionnel V9.

Si vous souhaitez basculer vers un autre SDK Java, suivez le document IBM Switch the Java SDK in 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 plus d’informations sur les ressources et bases de données JNDI, consultez la documentation IBM sur les sources de données WebSphere. 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. Par conséquent, le fichier resources.xml contient une grande quantité de configuration que vous devez prendre en compte avec soin pour la migration. Le fichier inclut des références à d’autres fichiers XML stockés dans des sous-répertoires. IBM vous conseille d’utiliser normalement IBM Console pour configurer les objets et services gérables de WAS et autoriser WAS à conserver le dossier profils/nom de profil. Pour plus d’informations, consultez Gestion des profils sur les systèmes d’exploitation IBM i 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 d’état de session HTTP. Pour plus d’informations, consultez Administration inscrire des haricots 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 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, Administration Control, Administration Config, Administration App et Administration Task.
  • 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 ?
  • Les installations au niveau du système d’exploitation comme systemd celles utilisées pour provoquer le démarrage automatique des composants WAS 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 Choisir une solution pour 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. Une stratégie pour ceux qui utilisent JMS consiste à utiliser Azure Service Bus et le protocole Advanced Message Queuing. Pour plus d’informations, consultez Utiliser JMS avec Azure Service Bus et AMQP 1.0.

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

Si vous utilisez IBM MQ, vous pouvez migrer ce logiciel vers Azure Machines Virtuelles et l’utiliser tel quel.

Microsoft a 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 au 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 configuration d’IBM Integration Bus. Pour plus d’informations, consultez la documentation 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 leurs configurations. Pour plus d’informations, 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 sur une application dans le 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 sur une application dans le 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 Place de marché Azure est un point de départ pour votre migration. Si l’offre ne couvre pas les aspects de votre architecture que vous devez migrer, vous devez capturer la topologie 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 une vaste rubrique, mais les références suivantes peuvent donner une direction à vos efforts de migration :

  • La référence suivante énumère les rubriques générales relatives à la migration de la topologie de réseau vers Azure : topologies de déploiement de réseau WebSphere Application Server.
  • Étant donné que les sources de données sont des serveurs distincts dans un système WAS, vous devez les considérer comme faisant partie de l’analyse de la topologie du réseau. Pour plus d’informations, consultez Les sources de données du serveur d’applications WebSphere.
  • Les sources de messagerie sont également des serveurs distincts. Pour plus d’informations, consultez Topologies réseau : interopérabilité à l’aide du fournisseur de messagerie WebSphere MQ.
  • L’équilibrage de charge est un critère essentiel. La référence suivante couvre le côté WAS de l’équilibrage de charge : clustering de déploiement de réseau webSphere Application Server.

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 vous connecter à d’autres systèmes d’entreprise, veillez à appliquer la configuration de ces artefacts à l’instance WAS exécutée dans Azure Machines Virtuelles. Pour plus d’informations, consultez les 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 plus d’informations, consultez OpenID Connecter l’authentification 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 à partir de votre installation locale vers WAS s’exécutant dans Azure Machines Virtuelles. Pour plus d’informations, consultez WebSphere Application Server Network Deployment dans la documentation IBM.

Prendre en compte les exigences d’équilibrage de charge

L’équilibrage de charge est une partie essentielle de la 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 Place de marché Azure pour le cluster IBM WebSphere Application Server.

Pour obtenir un résumé des fonctionnalités d’Azure Application Gateway par rapport à d’autres solutions d’équilibrage de charge Azure, consultez les 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électionner une offre WAS traditionnelle sur Azure Machines Virtuelles

Les offres suivantes sont disponibles pour WAS sur Azure Machines Virtuelles.

Pendant le déploiement d’une offre, vous êtes invité à 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 pour Services cloud (classique).

Provisionner l’offre

Une fois que vous avez sélectionné l’offre à commencer, provisionnez cette offre en suivant les instructions fournies dans Déployer le cluster WebSphere Application Server (traditionnel) sur Azure Machines Virtuelles.

Migrer les profils

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

Connecter les bases de données

Une fois que vous avez migré les profils, vous pouvez connecter les bases de données en suivant les instructions de la source de données WebSphere Application Server dans la documentation IBM.

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 plus d’informations, consultez les configurations keystore pour SSL dans la documentation IBM.

Connecter les sources JMS

Une fois que vous avez connecté les bases de données, vous pouvez configurer JMS en suivant les instructions de configuration de JMS dans IBM WebSphere Application Server 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 plus d’informations, consultez OpenID Connecter l’authentification avec Microsoft Entra ID.

Tenir compte de la journalisation

Vous pouvez configurer Elastic Stack en suivant les instructions de l’analyse des journaux WebSphere Application Server avec Elastic Stack dans la documentation IBM. Azure prend en charge Elastic. Pour plus d’informations, 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, il existe une plateforme CI/CD hautement évoluée qui entraîne le déploiement des applications sur le serveur d’applications WebSphere. Dans d’autres cas, le processus peut être plus manuel. L’un des avantages de l’utilisation d’Azure Machines Virtuelles pour migrer des applications traditionnelles WAS vers le cloud est que vos processus existants continuent de fonctionner.

Vous devez configurer le groupe de sécurité réseau que l’offre provisionne pour autoriser l’accès à partir de votre pipeline CI/CD ou du système de déploiement manuel. Pour en savoir plus, reportez-vous aux groupes de sécurité réseau.

Test

Vous devez configurer tous les tests en conteneur sur des applications pour accéder aux nouveaux serveurs s’exécutant 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 en savoir plus, reportez-vous aux 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 potentielles après la migration, consultez les recommandations suivantes :