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é.

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.

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.

Prenez en compte les points suivants lors de la migration vers la Version 9.0:
  • Toute variable appartenant à des applications ou à des produits autres que WebSphere Application Server n'est pas migrée mais est transposée telle qu'elle dans le nouvel environnement. Par conséquent, avant de procéder à la migration, vérifiez toutes les mises à niveau des autres produits afin de vous assurer que toutes ces variables sont toujours exactes après la migration.
  • Avant de procéder à la migration depuis la Version 7.0 ou ultérieures vers la Version 9.0, vérifiez qu'aucune contrainte de région n'est en vigueur (comme des limites IEFUSI). Ces contraintes peuvent générer des erreurs imprévisibles liées à la machine virtuelle Java™ (JVM).
Quel est le processus de migration de base ?
  1. Installez le code SMP/E pour WebSphere Application Server for z/OS Version 9.0.
    • Le code SMP/E code contient Installation Manager. L'installation du code SMP/E vous donne l'autorisation de récupérer le référentiel WebSphere et de construire le code produit sur votre système.
  2. Utilisez l'outil z/OS Migration Management Tool ou la commande zmmt pour créer les utilitaires de migration dont vous aurez besoin.
  3. Exécutez ces travaux.

    Une nouvelle configuration de la Version 9.0 est créée, distincte de votre configuration existante Version 7.0 ou ultérieures, basée sur les informations de configuration de la Version 7.0 ou ultérieures.

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.

Graphique illustrant 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 :

Tableau 1. Utilitaires de migration et leurs objectifs . Le tableau répertorie les utilitaires de migration et leurs objectifs.
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 :
  • BBOWMG3B
  • BBOWBPRO
  • BBOWBPRE
  • BBOWBPOS
Pour les migrations de gestionnaires de déploiement, les utilitaires suivants :
  • BBOWMG3D
  • BBOWDPRO
  • BBOWDPRE
  • BBOWDPOS
Pour les migrations de noeuds fédérés, les utilitaires suivants :
  • BBOWMG3F
  • BBOWMPRO
  • BBOWMPRE
  • BBOWMPOS

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 ?

Oui. Un gestionnaire de déploiement ayant migré vers le niveau de code de la Version 9.0 peut gérer un noeud de la Version 7.0 ou ultérieures. Les modifications effectuées via la console d'administration sont appliquées au noeud. Prenez en compte les points ci-dessous :
  • Lorsqu'un gestionnaire de déploiement migre vers la Version 9.0, une nouvelle configuration principale est créé sous la Version 9.0. La configuration principale de la Version 7.0 ou ultérieures continue à exister. Mais lorsque le gestionnaire de déploiement de la Version 9.0 apporte des modifications à la configuration, celles-ci affectent la nouvelle configuration principale sous la Version 9.0. Par conséquent, bien qu'il soit toujours possible d'utiliser le code de la Version 7.0 ou ultérieures, les modifications apportées dans la Version 9.0 ne sont pas visibles lorsque l'ancien code est restauré.
  • Un gestionnaire de déploiement de la Version 7.0 ou ultérieures ne peut pas gérer un noeud de la Version 9.0.

Est-ce qu'il y a une séquence de mise en oeuvre de la migration multi-noeud ?

Oui. Effectuez la migration dans l'ordre suivant :
  1. Migrez toujours le gestionnaire de déploiement en premier.
  2. Les noeuds de serveurs d'applications se trouvant sur le même système que le gestionnaire de déploiement ou sur d'autres images MVS peuvent ensuite être migrés.

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 ?

Oui. Il est 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 pour un sysplex ou une image MVS. Les restrictions suivantes s'appliquent :
  • Une cellule peut contenir des serveurs niveau Version 7.0 ou ultérieures.
  • Une cellule peut contenir des noeuds z/OS et des noeuds d'autres types ; le gestionnaire de déploiement doit quant à lui correspondre au niveau de version le plus élevé dans la cellule et les noeuds sur les plateformes autres que celle sur laquelle réside le gestionnaire de déploiement doivent être de Version 7.0 ou ultérieures.
  • Un serveur sur un noeud z/OS ne peut pas être en cluster avec un serveur sur un noeud autre que z/OS.
  • Une LPAR peut contenir plusieurs noeuds de la même cellule.
  • Chaque LPAR dispose au plus d'un démon par cellule disposant de serveurs sur cette LPAR indépendamment du nombre de noeuds de la cellule configurés pour cette LPAR.
  • Pour une LPAR donnée, un démon doit avoir le même niveau, ou un niveau supérieur, que tous les serveurs de la LPAR qui se trouvent dans la cellule du démon, quel que soit le noeud.
  • Tous les serveurs d'un même noeud doivent avoir le même niveau de version.
  • Le gestionnaire de déploiement doit avoir le même niveau ou un niveau supérieur à celui du serveur de la cellule.
  • Le contrôleur et ses servants doivent avoir le même niveau de version.
  • Deux cellules ne peuvent pas avoir le même nom court.
  • D'autres éléments doivent être pris en compte pour des cellules distinctes, même si la version de leur code est différente. Par exemple, vous devez avoir un point de montage du système de fichiers de configuration distinct et des procédures JCL distinctes.

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-zos&topic=cmig_overview
Nom du fichier : cmig_overview.html