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
- 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 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é.
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.
- Exécutez une migration de noeuds incrémentielle du système existant.
- 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.
- 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.
- 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.
- 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.
- 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: 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.

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.
gotchaSi 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.
Foire aux questions
Puis-je simplement pointer vers les nouveaux fichiers de données WebSphere Application Server for z/OS Version 9.0 et redémarrer mes serveurs ?
Non. WebSphere Application Server for z/OS Version 9.0 requiert de faire migrer votre configuration de la Version 7.0 ou ultérieures vers le niveau de la Version 9.0.
La migration est-elle une activité noeud par noeud ?
Oui. Le processus de migration de la configuration implique l'exécution des utilitaires fournis sur chaque noeud de votre configuration.
Bien qu'un serveur d'applications autonome ne comporte qu'un seul noeud, celui-ci doit être migré. Les étapes de migration sont pour l'essentiel les mêmes que celles effectuées pour les autres noeuds, à la différence près qu'il n'est pas nécessaire d'avoir un gestionnaire de déploiement en cours d'exécution. Voir Liste de contrôle pour la migration d'un serveur d'applications autonome z/OS pour une liste de contrôle des activités relatives à la migration d'un noeud de serveur d'applications autonome.
Que font les utilitaires de migration ?
Les utilitaires de migration ont les rôles suivants :
Utilitaire | Objectif |
BBOWMG1B (migrations de serveurs d'applications autonomes) BBOWMG1F (migrations de noeud fédéré) |
Permet à tous les serveurs d'un noeud en cours de migration d'être
configurés pour démarrer en mode de traitement PRR (Peer Restart and Recovery). Une fois ce travail exécuté, vous devez démarrer tous les serveurs sur le noeud en cours de migration et attendre leur arrêt. Le mode de traitement PRR résout les transactions en attente, vide les journaux de transaction et arrête le serveur. Ce travail n'est pas nécessaire pour la migration d'un gestionnaire de déploiement. Il est de plus facultatif pour les configurations n'utilisant pas de connecteurs XA répartis. Ce travail n'est requis que lorsque vous utilisez des adaptateurs XA et que vous devez migrer les journaux XA. Vérifiez vos fournisseurs de ressources dans la console d'administration de la Version 7.0 ou ultérieures en accédant à Ressources > Fournisseurs JDBC et en vérifiant si vous avez choisi des fournisseurs XA tels que DB2, Apache Derby, etc. |
BBOWMG2B (migrations de serveurs d'applications autonomes) BBOWMG2F (migrations de noeud fédéré) |
Désactive le mode PRR et remet tous les serveurs en mode de
fonctionnement normal. Il n'est pas nécessaire de démarrer tous les serveurs une fois ces travaux terminés. Ce travail n'est pas nécessaire pour la migration d'un gestionnaire de déploiement. Il est de plus facultatif pour les configurations n'utilisant pas de connecteurs XA. Ce travail n'est requis que lorsque vous utilisez des adaptateurs XA et que vous devez migrer les journaux XA. Vérifiez vos fournisseurs de ressources dans la console d'administration de la Version 7.0 ou ultérieures en accédant à Ressources > Fournisseurs JDBC et en vérifiant si vous avez choisi des fournisseurs XA tels que DB2, Apache Derby, etc. |
BBOMBHFS ou BBOMBZFS (migrations de serveurs d'applications autonomes) BBOMDHFS ou BBOMDZFS (migrations de gestionnaire de déploiement) BBOMMHFS ou BBOMMZFS (migrations de noeuds fédérés) |
Facultatif : Crée un système de fichiers et un point de montage
pour la racine de configuration de la Version 9.0 et monte le système de fichiers. Si vous désirez utiliser un système de fichiers existant pour héberger la configuration de la Version 9.0, au lieu d'exécuter ce travail, vous devez créer manuellement le point de montage spécifié lorsque vous créez la définition de migration et vérifier que ce système de fichiers est monté. Dans tous les cas, le système de fichiers de configuration et le point de montage doivent être créés et le système de fichiers doit être monté avant de poursuivre la migration. |
Pour les migrations de serveurs d'applications autonomes, les utilitaires suivants :
Pour les migrations de gestionnaires de déploiement, les utilitaires suivants :
Pour les migrations de noeuds fédérés, les utilitaires suivants :
|
BBOWMG3x exécute la migration complète du noeud depuis la Version 7.0 ou ultérieures vers la Version 9.0. BBOWxPRO crée uniquement le répertoire de base et le profil par défaut de WebSphere Application Server. BBOWxPRE exécute uniquement le processus préalable à la migration. BBOWxPOS exécute uniquement les processus postérieurs à la migration et les processus de finalisation (droits de modification des fichiers). |
BBOMBCP (migrations de serveurs d'applications
autonomes) BBOMDCP (migrations de gestionnaire de déploiement) BBOMMCP (migrations de noeud fédéré) |
Copie les procédures JCL générées pour démarrer les serveurs dans la
bibliothèque de procédure indiquée. Si vous désirez que votre configuration de la Version 9.0 utilise des noms de procédure de démarrage JCL différents, cet utilitaire met à jour la nouvelle configuration de la Version 9.0 en remplaçant les noms existant dans votre configuration d'origine Version 7.0 ou ultérieures par les nouveaux noms JCL. |
Où exécuter les travaux de migration ?
Exécutez les tâches sur le système sur lequel le noeud réside.
Que se passe-t-il quand un noeud est migré ?
Les utilitaires de migration transforment le contenu de votre système de fichiers de configuration WebSphere Application Server Version 7.0 ou ultérieures et le fusionne dans un nouveau système de fichiers de configuration de la Version 9.0.
Ma configuration existante est-elle perdue lors de la migration ?
Pendant la migration, l'arborescence de configuration d'origine de WebSphere Application Server Version 7.0 ou ultérieures n'est pas affectée. Si pour une raison quelconque, la migration échoue avant la fin du processus, votre configuration précédente existe toujours.
Si mon noeud comporte plusieurs serveurs d'applications, ceux-ci sont-ils tous migrés ?
Oui. L'utilitaire détecte tous les serveurs et les migre tous, y compris les agents de noeud. Un appel des utilitaires de migration pour un noeud migre tous les serveurs de ce noeud.
Les serveurs d'un noeud doivent-ils être arrêtés avant le lancement de la migration ?
Oui. Dans une configuration multi-noeud, les autres noeuds peuvent continuer à fonctionner. Mais pour chaque noeud que vous souhaitez migrer, le serveur correspondant doit être arrêté.
Lorsqu'un noeud de serveur d'applications faisant partie d'une configuration WebSphere Application Server, Network Deployment est en cours de migration, le gestionnaire de déploiement de cette cellule migré au préalable vers la Version 9.0 doit être en cours d'exécution. Cela est nécessaire car une partie de la migration implique l'utilisation de la fonction de scriptage wsadmin pour synchroniser le noeud de serveur d'applications qui vient d'être migré avec le gestionnaire de déploiement. Le gestionnaire de déploiement doit être en cours d'exécution pour effectuer cette synchronisation.
Une cellule peut-elle fonctionner avec seulement certains des noeuds migrés ?
Oui, c'est possible. WebSphere Application Server Version 7.0 ou ultérieures peut coexister avec la Version 9.0 dans la même cellule et sur la même partition logique (LPAR).
Le gestionnaire de déploiement WebSphere Application Server for z/OS Version 9.0 récemment migré peut-il toujours communiquer avec les noeuds de la Version 7.0 ou ultérieures ?
Est-ce qu'il y a une séquence de mise en oeuvre de la migration multi-noeud ?
Est-il possible de faire coexister des cellules WebSphere Application Server for z/OS Version 9.0 avec d'autres cellules de la Version 7.0 ou ultérieures ?