Présentation de la migration, de la coexistence et de l'interopérabilité

La migration vers une nouvelle version de WebSphere Application Server nécessite un examen attentif des facteurs tels que l'édition du produit, les types de profil, la configuration du serveur, et le déploiement d'applications. Cette vue d'ensemble présente les concepts, la terminologie, les outils et stratégies pour vous aider à migrer le produit avec succès.

Terminologie courante relative à la migration

Les termes suivants sont fréquemment utilisés pour traiter de la migration :
  • Version ou édition : mise à jour du produit qui comprend une nouvelle fonction importante.
  • Edition : dans une version, conditionnement du produit qui comprend certains ensembles de fonctionnalités. Par exemple, Network Deployment.
  • Profil : ensemble de fichiers qui définit l'environnement d'exécution d'un processus de serveur d'applications, comme un gestionnaire de déploiement ou un serveur d'applications. Les profils contiennent la configuration de la façon dont le serveur d'application se comporte et où les applications sont déployées.
  • Source : origine des données et des objets de la migration, telle que profil source ou machine source.
  • Cible : destination des données et des objets de la migration, telle que profil cible ou machine cible.
  • Noeud : regroupement de serveurs gérés ou non gérés ou de clusters de serveurs. Chaque nœud qui est géré par une cellule peut avoir une configuration unique
  • Cellule: groupe contenant un gestionnaire de déploiement qui gère un ou plusieurs noeuds ou configurations. Les noeuds dans la cellule sont fédérés dans le gestionnaire de déploiement. La configuration du niveau de la cellule est commune à tous les nœuds.
  • Environnement de cellules mixtes : lorsque l'édition d'au moins un noeud fédéré est plus ancienne que l'édition du gestionnaire de déploiement qui gère la cellule. Les nœuds ne peuvent pas être antérieurs au gestionnaire de déploiement de plus de trois éditions.

Concepts essentiels de la migration

La migration est le processus de déplacement de la configuration à partir d'une ancienne édition vers une nouvelle édition, de telle sorte que la nouvelle configuration se comporte autant que possible comme l'ancienne configuration. L'unité principale pour une migration est le profil, qui est migré en 3 étapes essentielles :
  1. Prendre un instantané du profil source à partir de l'ancienne installation.
  2. Créer un profil cible compatible dans la nouvelle installation.
  3. Fusionner les données de l'instantané dans le profil cible.

La migration d'une cellule, qui contient le gestionnaire de déploiement et les noeuds fédérés, nécessite une attention particulière. Étant donné que le gestionnaire de déploiement contrôle la configuration dans la cellule, chaque nœud doit être synchronisé avec le nouveau gestionnaire de déploiement lorsqu'il est migré.

Stratégies de migration

Lorsque vous planifiez votre migration, examinez les stratégies de migration possibles suivantes :
Migration standard et migration clone
  • Standard : la configuration source est désactivée après sa migration vers la configuration cible.
  • Clone : la configuration source reste fonctionnelle après sa migration vers la configuration cible.
Migration locale et migration distante
  • Locale : la configuration est migrée sur la même machine. Pour les migrations clones, le résultat est deux environnements coexistants.
  • Distante : la configuration est migrée vers une nouvelle machine.

Outils de migration

Les outils que vous utilisez pour migrer votre configuration de produit doivent être exécutés à partir de la nouvelle installation sur l'édition cible. Si possible, mettez à jour la nouvelle installation vers le dernier groupe de correctifs disponible avant de commencer votre migration. Les outils de migration WebSphere Application ServerVersion 9.0 prennent en charge la migration uniquement à partir de Version 7.0 ou ultérieures et ne prennent pas en charge la migration dans la même édition, par exemple de Version 9.0 vers Version 9.0. Pour répliquer votre configuration sur les machines de la même version ou édition, consultez les informations sur la configuration basée sur les propriétés ou utilisez la commande exportWasprofile wsadmin de scriptage dans le groupe de commandes ConfigArchiveOperations pour l'objet AdminTask.

La migration utilise les principaux outils de ligne de commande suivants :
WASPreUpgrade
Prend un instantané du profil source à partir de l'ancienne installation et le place dans un répertoire de sauvegarde. Pour les migrations distantes, la commande WASPreUpgrade recueille des artefacts supplémentaires qui sont référencés par votre configuration dans le répertoire de sauvegarde.
manageprofiles
Crée le profil cible. Le profil cible doit être du même type que le profil source ; par exemple, vous ne pouvez pas migrer un profil de gestionnaire de déploiement vers un profil de serveur d'applications autonome. Selon le type de profil, vous devez également faire correspondre le nom de cellule, le nom de noeud, ou les deux du profil source.
WASPostUpgrade
Fusionne les données du répertoire de sauvegarde de la migration dans le profil cible. Vous pouvez spécifier des options supplémentaires pour contrôler si l'ancienne configuration est désactivée, si différer l'installation des applications, et plus encore.

L'outil de gestion de migration des configurations ou l'assistant de migration, est un outil d'interface utilisateur graphique (GUI) qui vous guide dans l'exécution des outils de ligne de commande.

Les outils de migration de configuration déploient sur le profil cible vos applications, telles qu'elles existaient dans le profil source. Avant de migrer votre configuration, testez vos applications dans un environnement WebSphere Application Server Version 9.0 de non production. Apportez toutes les modifications requises pour leur exécution dans cet environnement. Pour identifier rapidement les modifications nécessaires, vous pouvez analyser vos applications à l'aide de Migration Toolkit for Application Binaries et WebSphere Application Server Migration Toolkit. Pour plus d'informations, voir Migration Toolkit on WASdev.

Vous pouvez exécuter la commande WASMigrationAppInstaller autant de fois que nécessaire pour installer des applications qui ne sont pas installées par la commande WASPostUpgrade.

Pour les migrations distantes, vous pouvez utiliser la commande createRemoteMigrJar pour créer un fichier .jar qui vous permet d'exécuter la commande WASPreUpgrade sur un système qui ne dispose pas de WebSphere Application Server.

Utilisez les outils de migration pour migrer les applications et les informations de configuration vers la nouvelle version, comme indiqué à la rubrique Migration des configurations de produit. Pour plus d'informations, voir Utilisation des outils de migration.

Environnements à cellules mixtes

Une cellule peut contenir des noeuds provenant de différentes versions de WebSphere Application Server. Une cellule mixte WebSphere Application Server Version 9.0 peut contenir des noeuds prenant en charge WebSphere Application Server Version 9.0 et Version 7.0 ou ultérieures. Dans un environnement de cellules mixtes, si un membre d'une cellule est antérieur à la version 7.0, les outils ne peuvent pas migrer le gestionnaire de déploiement. L'administrateur doit migrer les noeuds vers la version 7.0 minimum ou les supprimer de la cellule.

Vous pouvez créer un environnement de cellules mixtes de deux façons :
  1. Exécutez une migration de noeuds incrémentielle du système existant.
    1. Faites migrer le gestionnaire de déploiement vers Version 9.0. Le responsable du déploiement doit être au niveau de la version de noeud la plus élevée. Si vous disposez de noeuds de la version précédente, cette migration du gestionnaire de déploiement crée une cellule mixte sous la version la plus élevée de WebSphere Application Server.
    2. Ensuite, lorsque vous faites migrer un noeud à la fois vers cette version, la cellule devient une cellule de la version la plus élevée de WebSphere Application Server.
      Remarque : La version de cette cellule ne peut pas être supérieure à celle du gestionnaire de déploiement.
  2. Faites migrer le gestionnaire de déploiement vers Version 9.0, puis fédérez les noeuds de l'ancienne version avec le gestionnaire de déploiement de la nouvelle version . Cette forme de migration est prise en charge uniquement pour les noeuds de la version Version 7.0 ou ultérieures.
    1. Faites d'abord migrer le gestionnaire de déploiement vers Version 9.0. Le responsable du déploiement doit être au niveau de la version de noeud la plus élevée.
    2. Vous pouvez ensuite fédérer des noeuds de la Version 7.0 ou ultérieures avec la dernière version du gestionnaire de déploiement.
    Eviter les incidents Eviter les incidents: Cette méthode de migration incrémentielle installe sur votre système un environnement de cellules mixtes dont les noeuds sont administrés par un gestionnaire de déploiement de la Version 9.0. Votre planification de la migration doit en fin de compte inclure la migration de tous les noeuds vers le niveau de la Version 9.0 afin de permettre une administration cohérente des noeuds.gotcha

Les fonctions existantes fonctionnent dans un environnement de cellules mixtes. Vous devriez pouvoir exécuter des opérations courantes telles que l'exécution d'applications existantes et d'opérations de gestion, telles que addNode, la création d'un cluster mixte, la configuration du système, l'appel de Mbeans et le déploiement d'applications. Le support de nouvelles fonctions dans un environnement de cellules mixtes peut être décidé au cas par cas, selon les fonctions, les priorités et les ressources disponibles.

Eviter les incidents Eviter les incidents: Dans un environnement de cellules mixtes, il peut arriver que dans ces clients, les informations de port relatives aux membres du cluster cible deviennent périmées. Cette situation survient le plus fréquemment lorsque tous les membres de cluster ont des ports dynamiques et sont redémarrés pendant une période durant laquelle aucune demande n'est envoyée. Le processus client peut tenter d'accéder à l'agent de noeud afin de recevoir les nouvelles données de port pour les membres de cluster puis utiliser ces dernières pour accéder à nouveau aux membres du cluster.

Si des problèmes surviennent qui empêchent le client de communiquer avec l'agent de noeud ou qui empêchent les nouvelles données de port d'être propagées entre les membres de cluster et l'agent de noeud, les demandes peuvent échouer sur le client. Dans certains cas, ces échecs sont temporaires. Il peut également être nécessaire de redémarrer un ou plusieurs processus pour résoudre une situation d'échec.

Pour éviter les problèmes d'acheminement client, vous pouvez configurer des ports statiques sur les membres de cluster. Avec des ports statiques, les données de port ne changent pas lorsqu'un processus client obtient des informations sur les membres du cluster. Même si ces derniers sont redémarrés ou s'il existe des problèmes de communication ou de propagation des données entre les processus, les données de port conservées par le client sont toujours valides. Il n'est pas toujours possible de résoudre les problèmes de communication ou de propagation des données sous-jacents, cependant les symptômes des décisions d'acheminement client inappropriées ou inattendues sont supprimés.

gotcha

Si vous n'optez ni pour la migration, ni pour la coexistence avec une version antérieure de WebSphere Application Server, vous ignorez dans ce cas l'installation précédente et vous ne pouvez exécuter qu'une seule version à la fois en raison de conflits d'affectation de ports par défaut. Les deux versions peuvent être exécutées simultanément sans conflit si, dans l'une des deux, vous utilisez des ports autres que ceux par défaut.

Problèmes de migration potentiels

Prenez en compte les points suivants dans un scénario de migration ou de coexistence :
  • Conflit entre les racines de contexte lors de la tentative de partage d'un même serveur Web.

    Suivez la procédure décrite dans la rubrique Migration des configurations de serveur Web pour déterminer comment configurer le partage d'un serveur Web entre plusieurs versions de WebSphere Application Server.

  • Si le gestionnaire de déploiement est configuré pour s'exécuter sous un profil autre que la racine, pour modifier la propriété et le droit d'accès du fichier des répertoires du gestionnaire, suivez les instructions fournies dans Migration de configurations non root vers root après avoir exécuté la commande WASPostUpgrade.

    Cette tâche doit être réalisée avant le démarrage du gestionnaire de déploiement de WebSphere Application ServerVersion 9.0.

    Pour plus d'informations, voir WASPostUpgrade command.

  • Si l'agent de noeud ou le serveur d'applications est configuré pour s'exécuter sous un profil autre que root, pour modifier la propriété et le droit d'accès du fichier des répertoires de noeud, suivez les instructions fournies dans Migration de configurations non root vers root après avoir exécuté la commande WASPostUpgrade.

    Cette tâche doit être réalisée avant le démarrage de l'agent de noeud ou du serveur d'applications WebSphere Application Server Version 9.0.

    Pour plus d'informations, voir WASPostUpgrade command.

Autres informations

WebSphere Application Server Version 9.0 peut coexister avec Version 7.0 ou ultérieures. En fonction de la version précédente de WebSphere Application Server, des conflits de port peuvent survenir qu'il vous faudra alors résoudre. Voir Exécution de serveurs d'applications coexistants et Configuration des paramètres de port pour plus d'informations.

WebSphere Application Server exploite la configuration et les applications existantes en les modifiant afin de les rendre compatibles avec l''environnement de WebSphere Application Server Version 9.0. Les composants d'applications et les paramètres de configuration existants sont appliqués à l'environnement de la Version 9.0 au cours du processus de migration.

Si vous disposiez d'une version antérieure de WebSphere Application Server, il se peut que l'administrateur système ait ajusté divers paramètres d'application et du serveur en fonction de cet environnement. Il est important de disposer d'une stratégie pour migrer ces paramètres avec une efficacité maximale.

Vous pouvez effectuer une migration incrémentielle de votre configuration WebSphere Application Server Version 7.0 ou ultérieures en exécutant les outils de migration à plusieurs reprises, en spécifiant à chaque fois un ensemble de profils différent. La migration incrémentielle du serveur WebSphere Application Server concerne généralement l'utilisation du système sous une édition destinée à un environnement de cellules mixtes. La migration dans cet environnement implique des migrations de noeuds à différents moments, et peut, par conséquent, entraîner l'exécution de cellules mixtes pendant de longues durées, jusqu'à la fin de la migration.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=cmig_overview
Nom du fichier : cmig_overview.html