WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Migration d'un cluster avec un temps d'arrêt minimal

Pour réaliser la migration d'un cluster avec un temps d'arrêt minimal, commencez par faire migrer environ la moitié des profils membres du cluster, puis faites migrer la seconde moitié. Exécutez les étapes supplémentaires requises pour la migration du cluster après avoir migré le premier ensemble de profils.

Avant de commencer

Vous devez disposer d'une cellule existante contenant au moins un cluster s'exécutant sur une version antérieure de WebSphere ESB (par exemple, version 6.0.x ou 6.1.x) que vous souhaitez migrer vers une version plus récente (par exemple, version 6.2). En outre, vous devez avoir installé la nouvelle version de WebSphere ESB.
Important : Dans un cluster, des membres de la version 6.0.x ou 6.1.x et des membres de la version 6.2 ne doivent jamais s'exécuter simultanément. Tous les membres de cluster de version version 6.0.x ou 6.1.x doivent être arrêtés avant le démarrage de la première version d'un membre de cluster version 6.2. En outre, après avoir lancé un membre de cluster de la version 6.2, ne lancez plus aucun autre membre de la version 6.0.2.x de ce cluster.

Pourquoi et quand exécuter cette tâche

En suivant ces étapes, vous serez certain que les fonctionnalités du cluster seront conservées dans la nouvelle version de WebSphere ESB avec un temps d'indisponibilité minimal.
Restriction : La procédure suivante est prise en charge uniquement si vous migrez de la version 6.1.x vers la version 6.2. Si vous migrez depuis la version 6.0.2.x et que vous souhaitez réduire au minimum le temps d'indisponibilité pendant la migration du cluster, vous d'abord devrez migrer vers la version 6.1.x, puis vers la version 6.2.
Procédure
  1. Faites migrer le gestionnaire de déploiement. Pour accomplir cette tâche, suivez l'un des jeux d'instructions énumérés à la section Migration d'un gestionnaire de déploiement.
  2. Assurez-vous que le nouveau gestionnaire de déploiement est en cours d'exécution.
  3. Identifiez les profils impliqués.
    1. Identifiez un profil d'ancienne version contenant des membres du cluster.
    2. Identifiez les autres clusters auxquels ce profil apporte sa contribution. En d'autres termes, si le profil définit des serveurs appartenant à d'autres clusters, identifiez ces clusters.
    3. Identifiez tous les autres profils contenus dans la même cellule qui apportent des membres de cluster à l'un des clusters identifiés à l'étape 3.b.
    4. Identifiez tous les agents de noeud et processus de serveur définis par l'un des profils identifiés à l'étape 3.c.
    Tous les profils identifiés à l'étape 3.c, et tous les agents de noeud et serveurs correspondants identifiés à l'étape 3.d seront impliqués dans la migration.
  4. Définissez deux groupes de profils à partir de l'ensemble complet des profils identifiés à l'étape 3. Répartissez globalement les profils en deux moitiés (si le nombre total de profils est un nombre impair, l'un des deux groupes comptera un profil de plus que l'autre). Vous procéderez à la migration d'un ensemble de serveurs pendant que l'autre ensemble sera toujours en cours d'exécution, de manière à réduire la durée pendant laquelle tous les serveurs du cluster seront arrêtés.
  5. Arrêtez tous les agents de noeud et les serveurs définis par le premier ensemble de profils dont vous effectuez la migration.
  6. Faites migrer un par un chaque profil du premier ensemble, mais ne démarrez aucun nouvel agent ou serveur de noeud. Suivez l'une des procédures répertoriées dans l'une des deux sections ci-après : Migration des membres d'un cluster à l'aide de l'assistant de migration ou Migration des membres d'un cluster à l'aide des outils de ligne de commande.
  7. Procédez à l'arrêt des agents de noeud et serveurs restants, c'est-à-dire ceux qui sont définis dans le second groupe de profils. Cette action débute la période d'indisponibilité des services du cluster.
  8. Sur le système qui héberge le profil du gestionnaire de déploiement WebSphere ESB version 6.2, accédez au répertoire rép_installation/util. Ce répertoire contient le script WBIProfileUpgrade, WBIProfileUpgrade.ant.
  9. Exécutez le script WBIProfileUpgrade pour chaque cluster défini dans les profils dont la migration a été effectuée jusqu'à présent. Pour cela, exécutez WBIProfileUpgrade pour chaque cluster défini à l'étape 3. Pour plus d'informations sur l'exécution de WBIProfileUpgrade, voir Script WBIProfileUpgrade.
  10. Démarrez tous les nouveaux agents de noeud et serveurs migrés, c'est-à-dire ceux qui correspondent aux profils migrés jusqu'à présent.
  11. Faites migrer chaque profil du second ensemble de profils Comme pour le premier ensemble, suivez l'une des procédures répertoriées dans l'une des sections Migration des membres d'un cluster à l'aide de l'assistant de migration ou Migration des membres d'un cluster à l'aide des outils de ligne de commande pour effectuer la migration. Cette fois-ci, vous pouvez démarrer les agents de noeud et serveurs migrés lors de la migration de chaque noeud géré.

Résultats

Le cluster est maintenant migré vers la nouvelle version de WebSphere ESB.

Que faire ensuite

Vérifiez que la migration s'est correctement terminée.

task Rubrique relative à une tâche

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tmig_vtv_migclust_min.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).