Vous pouvez utiliser les outils en ligne de commande pour migrer une cellule d'une version antérieure d' WebSphere® Application Server vers la version 9.0.
A propos de cette tâche
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.
Pour migrer une configuration de cellule, vous exécutez WASPreUpgrade, WASPostUpgrade, manageprofiles, et d'autres commandes de migration décrites dans la section Utilisation des outils de migration. Vous pouvez spécifier des paramètres individuels dans les commandes de migration ou spécifier le -propertiesfile_name.properties paramètre pour saisir un fichier de propriétés.
Pour les utilisateurs en transition : les produits suivants nécessitaient auparavant des outils de migration distincts, mais sont désormais migrés dans le cadre des procédures de migration standard :
- WebSphere Extended Deployment Compute Grid ou Feature Pack pour Modern Batch
- WebSphere Virtual Enterprise ou Gestion intelligente
Procédure
- Sauvegardez le gestionnaire de déploiement et tous les anciens noeuds.
En cas d'échec pendant la migration, enregistrez la configuration actuelle du gestionnaire de déploiement et du nœud dans un fichier que vous pourrez utiliser ultérieurement à des fins de récupération à l'aide du fichier backupConfig commande.
- Passez au répertoire deployment_manager_profile_root/bin .
- Exécutez la backupConfig commande avec les paramètres appropriés et enregistrez la configuration actuelle du profil du gestionnaire de déploiement dans un fichier.
/opt/WebSphereV70/profiles/v70dmgr01/bin/backupConfig.sh
/mybackupdir/v70dmgr01backupBeforeV90migration.zip
-username myuser -password mypass -nostop
Conseil : les utilisateurs Windows peuvent modifier les exemples présentés dans cette rubrique afin de les exécuter sur un ordinateur Windows. Par exemple, pour exécuter la
backupConfig commande, utilisez
backupConfig ou
backupConfig.bat pour la commande. Modifiez les chemins d'accès aux fichiers selon les besoins de votre environnement. Les lignes de commande Windows prennent généralement en charge la barre oblique (
/) dans les chemins d'accès aux fichiers, ainsi que la barre oblique inversée (
\).
previous_version_app_server_root\v70dmgr01\bin\backupConfig.bat
\mybackup_old_host\v70dmgr01backupBeforeV90migration.zip
-username myuser -password mypass -nostop
Remplacez
mybackup_old_host par l'emplacement de votre sauvegarde de configuration.
- Pour chaque nœud de la configuration, passez au node_profile_root/bin répertoire.
- Exécutez la backupConfig commande avec les paramètres appropriés et enregistrez la configuration actuelle du profil du nœud dans un fichier.
/opt/WebSphereV70/profiles/v70node01/bin/backupConfig.sh
/mybackupdir/v70node01backupBeforeV90migration.zip
-username myuser -password mypass -nostop
- Installez WebSphere Application Server Version 9.0 sur chaque machine cible dans un nouveau répertoire.
Pour plus d'informations, reportez-vous à la documentation d'installation.
- Créez le profil du gestionnaire de déploiement cible en exécutant la manageprofiles commande 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.
/opt/WebSphereV90/bin/manageprofiles.sh -create -profileName v90dmgr01
-templatePath /opt/WebSphereV90/profileTemplates/management -serverType DEPLOYMENT_MANAGER
-nodeName currentDmgrNodeName -cellName currentCellName
-hostName mydmgrhost.company.com
- Enregistrez la configuration actuelle du gestionnaire de déploiement dans le répertoire de sauvegarde de migration en exécutant la WASPreUpgrade commande à partir du répertoire bin du nouveau profil du gestionnaire de déploiement.
La WASPreUpgrade commande ne modifie pas la configuration de la version 7.0 ou ultérieure. Pour plus d'informations, consultez la commande WASPreUpgrade.
Remarque : si vous effectuez une migration de la version 8.0 ou ultérieure vers la version 9.0 et que votre profil est celui d'un gestionnaire de déploiement, le profil de la version 8.0 est arrêté lorsque vous exécutez la WASPreUpgrade commande. 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 WASPreUpgrade commande en spécifiant le répertoire de sauvegarde de la migration, le répertoire racine de l'installation de la version 7.0 ou ultérieure, et le nom du profil du gestionnaire de déploiement.
/opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90dmgr01
/opt/WebSphereV70 -oldProfile v70dmgr01
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPreUpgrade les journaux.
Une fois la WASPreUpgrade commande terminée, vérifiez la sortie de la console pourFailed with errorsouCompleted with warningsmessages. Si la sortie contient l'un ou l'autre de ces messages, vérifiez les fichiers WASPreUpgrade.old_Profile.timestamp.log journaux WASPreUpgrade.trace et pour voir s'il y a des avertissements ou des erreurs.
Si des erreurs se sont produites, corrigez-les,
puis exécutez de nouveau la commande WASPreUpgrade. Vérifiez si les avertissements affectent d'autres activités de migration ou d'exécution sur Version 9.0.
Si la commande a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Restaurez la configuration précédente du gestionnaire de déploiement que vous avez enregistrée dans le répertoire de sauvegarde de migration en exécutant la WASPostUpgrade commande.
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, consultez la commande WASPostUpgrade.
- Exécutez la WASPostUpgrade commande.
/opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90dmgr01 -oldProfile v70dmgr01
-profileName v90dmgr01 -resolvePortConflicts incrementCurrent -backupConfig true
-includeApps true -keepDmgrEnabled false -username myuser -password mypass
Lorsque vous créez des profils, un seul profil par installation est
considéré comme le profil par défaut.
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.
Évitez les problèmes : spécifiez toujours les paramètres -oldProfile -profileName et lorsque vous exécutez la WASPostUpgrade commande.
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPostUpgrade les journaux.
Une fois la WASPostUpgrade commande terminée, vérifiez la sortie de la console pourFailed with errorsouCompleted with warningsmessages. Si la sortie contient l'un ou l'autre de ces messages, vérifiez les fichiers migration_backup_dir/logs/WASPostUpgrade.target_profile_name.timestamp.log journaux migration_backup_dir/logs/WASPostUpgrade.target_profile_name.trace et pour voir s'il y a des avertissements ou des erreurs. Si des erreurs se sont produites, corrigez-les,
puis exécutez de nouveau la commande WASPostUpgrade. Vérifiez si les avertissements affectent d'autres activités de migration ou d'exécution sur 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, consultez la commande WASMigrationAppInstaller.
Si la commande a abouti, il n'est pas nécessaire de rechercher les erreurs ou avertissements dans les journaux.
- Sauvegardez la configuration du gestionnaire de déploiement de la version 9.0 dans un fichier en exécutant la backupConfig commande sur le gestionnaire de déploiement de la version 9.0.
Évitez les problèmes : il s'agit d'une étape importante dans le plan de migration cellulaire. 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.
- Passez au répertoire deployment_manager_profile_root/bin
- Exécutez la backupConfig commande avec les paramètres appropriés.
/opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh
/mybackupdir/v70toV90dmgr01backupMigratedDmgrOnly.zip
-username myuser -password mypass
- Démarrez le gestionnaire de déploiement de l' 9.0.
Vérifiez que la version précédente du gestionnaire de déploiement n'est pas en cours d'exécution.
- Passez au nouveau répertoire bin de profil du gestionnaire de déploiement 9.0.
- Exécutez la startManager commande.
- Pendant que le gestionnaire de déploiement est en cours d'exécution, vérifiez le SystemOut.log fichier pour voir s'il contient des avertissements ou des erreurs.
Remarque : ce sujet fait référence à un ou plusieurs fichiers journaux du serveur d'applications. Comme alternative recommandée, vous pouvez configurer le serveur pour qu'il utilise l'infrastructure de journalisation et de traçage HPEL (High Performance Extensible Logging) au lieu d'utiliser les
activity.log fichiers
SystemOut.log ,
SystemErr.log,
trace.log et sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctionnalités de journalisation natives d' z/OS®. 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
HP EL, consultez les informations relatives à l'utilisation de HPEL pour le dépannage des 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.
- Pour les applications Compute Grid ou Feature Pack for Modern Batch, vérifiez que le planificateur de tâches a été migré correctement et que vous pouvez envoyer des travaux aux serveurs de version précédente qui hébergent vos applications de traitement par lots.
Pour vérifier la migration du planificateur de travaux, après le redémarrage du gestionnaire de déploiement, accédez à la console de gestion de travaux par le biais d'un navigateur Web.
Pour vérifier que les serveurs de version précédente qui hébergent vos applications par lots fonctionnent correctement :
- Vérifiez que les applications de traitement par lots sur le serveur ou le cluster migré sont démarrées. Examinez les journaux du serveur ou du cluster pour rechercher les erreurs éventuelles.
- Vérifiez que vous pouvez envoyer des travaux par lots au serveur migré en soumettant un travail à partir du serveur du planificateur de travaux migré. Vous pouvez soumettre le travail à l'aide de la console de gestion des tâches, l'utilitaire WSGrid, l'interface EJB, ou l'interface de services Web.
- Faites migrer les installations de client d'application.
Migrer les ressources client vers des ressources de niveau version 9.0.
- Installez le client de l'application 9.0 de la version d' WebSphere.
Pour plus d'informations, reportez-vous à la documentation d'installation.
- Exécutez la commande Version WASPreUpgrade9.0 pour enregistrer les paramètres de sécurité du client de l'application dans un répertoire de sauvegarde de migration.
/opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup/v70clientToV90 /opt/AppClientV70
- Exécutez la commande Version WASPostUpgrade 9.0 pour restaurer les paramètres de sécurité du client de l'application sur le nouveau client Version 9.0.
/opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup/v70clientToV90
- Faites migrer les noeuds.
Utilisez les outils de migration pour migrer les versions précédentes des nœuds de la configuration vers la version 9.0. Effectuez la procédure suivante pour chaque nœud que vous prévoyez de migrer vers la version 9.0.
Évitez les problèmes : vous devez utiliser le même nom de nœud source, mais un nom de cellule temporaire différent pour chaque nœud que vous migrez vers la version 9.0.
- Assurez-vous 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 manageprofiles commande avec les paramètres appropriés pour créer un nouveau profil géré.
/opt/WebSphereV90/manageprofiles.sh -create -profileName node1
-templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name
-cellName tempCellName -hostName mynode1host.company.com
- Exécutez la WASPreUpgrade commande pour enregistrer les informations de configuration du nœud actuel dans un répertoire de sauvegarde de migration. Indiquez un nouveau répertoire pour les fichiers de sauvegarde, le répertoire racine de l'installation et le profil de nœud.
/opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90node1 /opt/WebSphereV70
-oldProfile 70node1
- Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPreUpgrade les journaux.
Vérifiez la sortie WASPreUpgrade de la console pour voir si des messages tels queFailed with
errorsouCompleted with warningsSi la commande n'a pas abouti, consultez les journaux suivants pour rechercher les erreurs ou les avertissements.
- migration_backup_dir/logs/WASPreUpgrade.old_profile.timestamp.log
- migration_backup_dir/logs/WASPreUpgrade.trace
Si la WASPreUpgrade commande s'est exécutée avec succès, il n'est pas nécessaire de vérifier les journaux pour détecter d'éventuelles erreurs ou avertissements.
- Arrêtez l'agent de noeud.
Si vous disposez de nœuds fonctionnant sous la version 7.0 ou ultérieure pendant une migration vers la version 9.0, vous devez arrêter l'agent de nœud sur le nœud en cours de migration. Si vous ne l'arrêtez pas, il se peut que vous rencontriez des problèmes de corruption.
- Exécutez la WASPostUpgrade commande pour restaurer la configuration du nœud enregistrée dans le nouveau profil géré de l' 9.0.
/opt/WebSphereV90/bin/WASPostUpgrade.sh /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 WASPostUpgrade les journaux.
Vérifiez la sortie WASPostUpgrade de la console pourFailed with errorsouCompleted with warningsmessages. Si le résultat contient l'un ou l'autre de ces messages, recherchez les erreurs ou les avertissements dans les journaux suivants.
- migration_backup_dir/logs/WASPostUpgrade.target_profile.timestamp.log
- migration_backup_dir/logs/WASPostUpgrade.target_profile.trace
Remarque : si la WASPostUpgrade commande échoue, vous devrez peut-être restaurer le gestionnaire de déploiement 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, consultez la commande « WASMigrationAppInstaller ».
Si la commande s'est exécutée avec succès, il n'est pas nécessaire de vérifier les journaux pour détecter d'éventuelles erreurs ou avertissements.
- Vérifiez le fichier Version SystemOut.log9.0 deployment manager pour voir s'il y a des avertissements ou des erreurs.
Remarque : ce sujet fait référence à un ou plusieurs fichiers journaux du 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 répartis 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
HP EL, consultez les informations relatives à l'utilisation de HPEL pour le dépannage des applications.
- Démarrez l'agent de nœud de la version migrée 9.0.
- Vérifiez le fichier Version SystemOut.log9.0 deployment manager and node pour voir s'il y a des avertissements ou des erreurs.
- Synchronisez la cellule.
- Arrêtez tous les serveurs d'applications sur le nœud migré de la version 9.0.
- Démarrez les serveurs d'application appropriés sur le nœud migré de la version 9.0.
- Pour les applications Compute Grid ou Feature Pack for Modern Batch, vérifiez que le planificateur de tâches a été migré correctement et que vous pouvez envoyer des travaux aux serveurs migrés qui hébergent vos applications de traitement par lots.
Pour vérifier la migration du planificateur de travaux, après le redémarrage des serveurs ou des clusters d'applications migrés, accédez à la console de gestion de travaux par le biais d'un navigateur Web.
Pour vérifier que les serveurs
d' 9.0 s de version qui hébergent vos applications batch fonctionnent correctement :
- Vérifiez que les applications de traitement par lots sur le serveur ou le cluster migré sont démarrées. Examinez les journaux du serveur ou du cluster pour rechercher les erreurs éventuelles.
- Vérifiez que vous pouvez envoyer des travaux par lots au serveur migré en soumettant un travail à partir du serveur du planificateur de travaux migré. Vous pouvez soumettre le travail à l'aide de la console de gestion des tâches, l'utilitaire WSGrid, l'interface EJB, ou l'interface de services Web.
- Enregistrez la configuration du profil d' 9.0 s de version dans un fichier en exécutant la backupConfig commande avec les paramètres appropriés.
/opt/WebSphereV90/profiles/v70toV90node1/bin/backupConfig.sh
/mybackupdir/v70toV90node1.zip -username myuser -password mypass -nostop
Chaque fois que vous exécutez la commande backupConfig, utilisez un nouveau nom de fichier de sauvegarde.
- Enregistrez la configuration du gestionnaire de déploiement dans un fichier en exécutant la backupConfig commande avec les paramètres appropriés.
Avant d'exécuter la commande, accédez au
deployment_manager_profile_root/bin répertoire sur l'hôte du gestionnaire de déploiement
Version 9.0.
Remarque : pour chaque nœud migré, sauvegardez la configuration du gestionnaire de déploiement Version 9.0 dans un nouveau fichier de sauvegarde.
- Faites migrer les plug-ins pour les serveurs Web.
Le produit prend en charge plusieurs serveurs Web différents, comme indiqué dans la configuration système requise. Pour plus d'informations sur l'installation, consultez la documentation relative au type et à la version de votre serveur Web.
- Assurez-vous que le gestionnaire de déploiement de la version 9.0 est en cours d'exécution.
- Mettez à jour la version du plug-in de serveur Web utilisé dans la cellule.
- Pour tous les serveurs d'applications de la cellule qui doivent être servis par le serveur Web, créez une nouvelle définition de serveur Web pour le plug-in de serveur Web.
Résultats
Vous avez migré d'une version précédente vers la version 2012 d' WebSphere Application Server9.0 à l'aide des outils de migration.