Migration de cellules à l'aide des outils de ligne de commande
Avant de commencer

Cet article traite de la migration de configuration de profil. Pour faire migrer vos applications vers la dernière version, utilisez le kit d'outils de migration de WebSphere Application Server. Pour plus d'informations, voir Migration Toolkit on WASdev.
sptcfgVérifiez les informations de planification de la migration en consultant la page suivante : Knowledge Collection: Migration planning for WebSphere Application Server.
Pourquoi et quand exécuter cette tâche
Vous pouvez utiliser les outils de ligne de commande pour migrer une cellule depuis une version précédente de WebSphere Application Server vers la Version 9.0. La configuration de cellule se compose d'un gestionnaire de déploiement avec un ou plusieurs noeuds, d'un serveur Web et d'un client d'application. Tous les ports sont migrés en aval dans la nouvelle configuration. Cette procédure suppose que la configuration précédente soit en cours d'exécution.

Procédure
- Sauvegardez le gestionnaire de déploiement et tous les anciens noeuds.
En cas d'incident lors de la migration, sauvegardez le gestionnaire de déploiement et la configuration de noeud en cours dans un fichier que vous pourrez utiliser ultérieurement à des fins de reprise, à l'aide de la commande backupConfig. Pour plus d'informations, reportez-vous à la rubrique Commande backupConfig.
- Accédez au répertoire racine_profil_gestionnaire_déploiement/bin.
- Exécutez la commande backupConfig avec les paramètres
appropriés et sauvegardez la configuration de profil en cours dans un fichier. Exemple :
/QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/v70dmgr01/bin/backupConfig /mybackupdir/ v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
- Pour chaque noeud de la configuration, accédez au répertoire racine_profil_noeud/bin.
- Exécutez la commande backupConfig avec les paramètres
appropriés et sauvegardez la configuration de profil en cours dans un fichier. Exemple :
/QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/v70node01/bin/backupConfig /mybackupdir/v70node01rbackupBeforeV90migration.zip -username myuser -password mypass -nostop
- Installez WebSphere
Application Server
Version 9.0 dans un nouveau répertoire sur chaque machine cible.
Pour plus d'informations, reportez-vous à la documentation d'installation.
- Créez le profil du gestionnaire de déploiement cible en exécutant la commande manageprofiles avec les paramètres appropriés.
Le profil de gestionnaire de déploiement cible est un nouveau profil qui sera la cible de la migration.
Exemple :Eviter les incidents: Les paramètres nodeName et cellName du profil de la Version 9.0 doivent correspondre à ceux de la Version 7.0 ou ultérieures précédente. Si les paramètres cellName ou nodeName du gestionnaire de déploiement de la Version 9.0 sont différents, la migration échoue. gotcha
/QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/manageprofiles -create -profileName currentDmgrProfileName -templatePath /QIBM/ProdData/WebSphere/AppServer/V9/ND/ profileTemplates/management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
- Sauvegardez la configuration de gestionnaire de déploiement en cours dans le répertoire de sauvegarde de migration en exécutant la commande WASPreUpgrade à partir du répertoire bin du nouveau profil de gestionnaire de déploiement.
La commande WASPreUpgrade ne modifie pas la configuration de la Version 7.0 ou ultérieures. Pour plus d'informations, reportez-vous à la rubrique Commande WASPreUpgrade.
Remarque : Si vous faites migrer la version 8.0 ou ultérieure vers la Version 9.0 et que votre profil est un gestionnaire de déploiement, le profil de version 8.0 s'arrête pendant que vous exécutez la commande WASPreUpgrade. Le gestionnaire de déploiement n'est démarré avant la fin de l'exécution de WASPreUpgrade que si vous indiquez -keepDmgrEnabled true sur la ligne de commande ou si vous spécifiez l'option correspondante dans l'assistant de migration.- Exécutez la commande WASPreUpgrade. Par
exemple :
/QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/v70toV90dmgr01 /QIBM/UserData/WebSphere/AppServer/V9/ND/profiles/myCurrentDmgrProfile
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et dans les journaux WASPreUpgrade.
Une fois l'exécution de la commande WASPreUpgrade terminée, recherchez les éventuels messages Failed with errors ou Completed with warnings dans la sortie de la console. Ensuite, recherchez les éventuels avertissements ou erreurs dans les fichiers journaux WASPreUpgrade.ancien_profil.horodatage.log et WASPreUpgrade.trace.
Si des erreurs se sont produites, corrigez-les, puis exécutez de nouveau la commande WASPreUpgrade. Vérifiez également si les avertissements auront une incidence sur les autres activités de migration d'exécution sous la Version 9.0.
Si la commande a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Exécutez la commande WASPreUpgrade. Par
exemple :
- Restaurez la précédente configuration de gestionnaire de déploiement que vous avez sauvegardée dans le répertoire de sauvegarde migration en exécutant la commande WASPostUpgrade.
Si vous utilisez les options indiquées dans l'exemple suivant, tous les ports sont conservés, l'ancien gestionnaire de déploiement est arrêté et désactivé, et toutes les applications sont installées.
Pour plus d'informations, reportez-vous à la rubrique WASPostUpgrade command.
- Exécutez la commande WASPostUpgrade. Par
exemple :
Lorsque vous créez des profils, un seul profil par installation est considéré comme le profil par défaut./QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade /mybackup/v70toV90dmgr01 -profileName myCurrentDmgrProfile -oldProfile myCurrentDmgrProfile -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -keepDmgrEnabled FALSE -username myuser -password mypass
Vous pouvez identifier les profils par défaut en examinant le fichier profileRegistry.xml se trouvant dans le répertoire WAS_HOME/properties. Le fichier profileRegistry.xml source est copié dans le répertoire de sauvegarde de la migration lors de l'exécution de la commande WASPreUpgrade.
Eviter les incidents: Indiquez toujours les paramètres -oldProfile et -profileName lorsque vous exécutez la commande WASPostUpgrade.gotcha
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et dans les journaux WASPostUpgrade. Une fois l'exécution de la
commande WASPostUpgrade terminée, recherchez les éventuels messages Failed with errors ou Completed with warnings dans la sortie de la console. Ensuite, recherchez les éventuels avertissements ou erreurs dans les fichiers journaux répertoire_sauvegarde_migration/logs/WASPostUpgrade.nom_profil_cible.horodatage.log et répertoire_sauvegarde_migration/logs/WASPostUpgrade.nom_profil_cible.trace. Si des erreurs se sont produites, corrigez-les,
puis exécutez de nouveau la commande WASPostUpgrade. Vérifiez également si les avertissements auront une incidence sur les autres activités de migration d'exécution sous la Version 9.0.
Si la configuration a été correctement migrée, mais des applications n'ont pas été installées, vous pouvez exécuter la commande WASMigrationAppInstaller pour installer uniquement les applications n'ayant pas été migrées. Pour plus d'informations, voir Commande WASMigrationAppInstaller.
Si la commande a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Exécutez la commande WASPostUpgrade. Par
exemple :
- Sauvegardez la configuration de gestionnaire de déploiement Version 9.0 dans un fichier en exécutant la commande backupConfig sur le gestionnaire de déploiement Version 9.0.
Eviter les incidents: Cela constitue une étape importante dans le plan de migration de cellules. En cas d'échec de migration de noeuds, vous pouvez restaurer la configuration de cellule antérieure à l'échec, appliquer des actions correctives et relancer la migration de noeuds.gotcha
- Accédez au répertoire racine_profil_gestionnaire_déploiement/bin.
- Exécutez la
commande backupConfig avec les paramètres appropriés. Exemple :
/QIBM/UserData/WebSphere/AppServer/V9/ND/profiles/myCurrentDmgrProfile/bin/ backupConfig.sh /mybackupdir/v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
- Démarrez le gestionnaire de déploiement Version 9.0.
Vérifiez que la version précédente du gestionnaire de déploiement n'est pas en cours d'exécution.
- Accédez au répertoire bin du profil de gestionnaire de déploiement de la Version 9.0.
- Exécutez la commande startManager.
- Lors de l'exécution du gestionnaire de déploiement, recherchez les
éventuels avertissements ou erreurs dans le fichier SystemOut.log. Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
- Recherchez d'éventuels avertissements ou erreurs dans les journaux du serveur d'applications et de l'agent de noeud du noeud. Si la fonction de synchronisation automatique est activée, vous pouvez autoriser la synchronisation du noeud et le redémarrage de l'application, puis rechercher les éventuels nouveaux avertissements ou erreurs dans les journaux.
- Faites migrer les plug-ins pour les serveurs Web.
- Vérifiez que le gestionnaire de déploiement de la Version 9.0 est en cours d'exécution.
- Mettez à niveau la version du plug-in de serveur Web utilisée dans la cellule.
- Consultez les informations de support qui s'appliquent au type et à la version de votre serveur Web.
- Faites migrer les installations de client d'application.
Migrez les ressources client vers les ressources de niveau Version 9.0.
- Installez le client d'application WebSphere Version 9.0.
Pour plus d'informations, reportez-vous à la documentation d'installation.
- Exécutez la commande Version 9.0
WASPreUpgrade pour sauvegarder les paramètres de sécurité du client d'application dans un répertoire de sauvegarde de migration. Par
exemple :
/opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup/v70clientToV90 /opt/AppClientV70
- Exécutez la commande Version 9.0
WASPostUpgrade pour restaurer les paramètres de sécurité du client d'application sur le nouveau client Version 9.0. Par
exemple :
/opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup/v70clientToV90
- Installez le client d'application WebSphere Version 9.0.
- Faites migrer les noeuds.
Utilisez les outils de migration pour faire migrer les versions de noeuds antérieures dans la configuration vers la Version 9.0. Procédez comme suit pour chaque noeud que vous comptez migrer vers la Version 9.0.
Eviter les incidents: Vous devez utiliser le même nom de noeud source, mais un nom de cellule temporaire différent pour chaque noeud que vous faites migrer vers Version 9.0. gotcha
- Vérifiez que le gestionnaire de déploiement de la Version 9.0 est en cours d'exécution.
- Créez le profil de noeud cible. Exécutez la commande manageprofiles
avec les paramètres appropriés pour créer un profil géré. Exemple :
/QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/manageprofiles -create -profileName currentNode1Name -templatePath /QIBM/ProdData/WebSphere/AppServer /V9/ND/profileTemplates/managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
- Exécutez la commande WASPreUpgrade pour sauvegarder les
informations de configuration de noeud en cours dans un répertoire de sauvegarde de la
migration. Choisissez un nouveau répertoire pour les fichiers de sauvegarde. Exemple :
/QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/ v70toV90node1 /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/currentNode1Name
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et dans les journaux WASPreUpgrade.
Recherchez dans la sortie de la console WASPreUpgrade les messages suivants : Failed with errors ou Completed with warnings.
Recherchez les avertissements ou erreurs dans les journaux suivants :- répertoire_sauvegarde_migration/logs/WASPreUpgrade.ancien_profil.horodatage.log
- répertoire_sauvegarde_migration/logs/WASPreUpgrade.trace
Si la commande WASPreUpgrade a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Arrêtez l'agent de noeud. Si des noeuds de la Version 7.0 ou ultérieures s'exécutent lors d'une migration vers la Version 9.0, vous devez arrêter l'agent de noeud sur le noeud qui est migré. Si vous ne l'arrêtez pas, il se peut que vous rencontriez des problèmes de corruption.
- Exécutez la commande WASPostUpgrade pour restaurer la configuration de noeud sauvegardée dans le nouveau profil géré de la Version 9.0. Exemple :
/QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade /mybackup/v70toV90node1 -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -username myuser -password mypass
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et dans les journaux WASPostUpgrade.
Recherchez dans la sortie de la console WASPostUpgrade les messages Failed with errors ou Completed with warnings.
Recherchez les erreurs ou avertissements dans les journaux suivants :- répertoire_sauvegarde_migration/logs/WASPostUpgrade.profil_cible.horodatage.log
- répertoire_sauvegarde_migration/logs/WASPostUpgrade.profil_cible.trace
Remarque : Si la commande WASPostUpgrade échoue, vous devrez éventuellement restaurer le gestionnaire de déploiement de la Version 9.0 à partir du fichier backupConfig. Si le traitement de la commande WASPostUpgrade a exécuté la commande syncNode, le gestionnaire de déploiement est informé de la migration du noeud. Le noeud ne peut pas être migré à nouveau tant que l'état antérieur à la migration du noeud n'a pas été restauré pour le gestionnaire de déploiement.Si la configuration a été correctement migrée, mais des applications n'ont pas été installées, vous pouvez exécuter la commande WASMigrationAppInstaller pour installer uniquement les applications n'ayant pas été migrées. Pour plus d'informations, voir Commande WASMigrationAppInstaller.
Si la commande a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Vérifiez l'absence d'avertissements et d'erreurs dans le fichier SystemOut.log du gestionnaire de déploiement de la Version 9.0. Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
- Démarrez l'agent du noeud Version 9.0 migré.
- Recherchez d'éventuels messages d'erreur et d'avertissement dans le fichier SystemOut.log du noeud et du gestionnaire de déploiement Version 9.0.
- Synchronisez la cellule.
- Arrêtez tous les serveurs d'applications sur le noeud Version 9.0 migré.
- Démarrez les serveurs d'applications appropriés sur le noeud Version 9.0 migré.
- Sauvegardez la configuration du profil Version 9.0 dans un fichier en exécutant la commande backupConfig avec les paramètres appropriés. Exemple :
Chaque fois que vous exécutez la commande backupConfig, utilisez un nouveau nom de fichier de sauvegarde./QIBM/UserData/WebSphere/AppServer/V9/profiles/v70toV90node1/bin/backupConfig /mybackupdir/v70toV90node1.zip -username myuser -password mypass -nostop
- Sauvegardez la configuration de gestionnaire de déploiement dans un fichier en exécutant la commande backupConfig avec les paramètres appropriés. Avant d'exécuter la commande, accédez au répertoire
racine_profil_gestionnaire_déploiement/bin sur l'hôte du gestionnaire de déploiement de la Version 9.0.Remarque : Pour chaque noeud migré, sauvegardez la configuration du gestionnaire de déploiement Version 9.0 dans un nouveau fichier de sauvegarde.Par exemple :
/QIBM/UserData/WebSphere/AppServer/V9/profiles/currentDmgrName/bin/ backupConfig.sh /mybackupdir/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
Résultats
La migration vers WebSphere Application Server Version 9.0 à partir d'une version antérieure à l'aide des outils de migration est terminée.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=tmig_migrate_cells_commandline
Nom du fichier : tmig_migrate_cells_commandline.html