Vous pouvez migrer un profil de gestionnaire de travaux et son ensemble enregistré de serveurs
Version 7.0 ou ultérieures vers Version 9.0.
Pourquoi et quand exécuter cette tâche
Les profils de gestionnaire de travaux
peuvent avoir un ou plusieurs des types de serveur suivants enregistrés :
- Serveurs de gestionnaire de déploiement
- Serveurs d'applications de base gérés (lesquels sont également enregistrés auprès d'un agent d'administration)
Eviter les incidents: - Les serveurs d'applications de base gérés et les serveurs du gestionnaire
de déploiement ne peuvent pas accepter de travaux provenant d'un gestionnaire
de travaux d'une version précédente. Pour éviter des problèmes, migrez vos profils de gestionnaire de travaux vers la Version 9.0 avant de faire migrer des serveurs
d'applications de base gérés et des serveurs de gestionnaire de déploiement vers la
Version 9.0.
- Lors de la migration d'un serveur d'applications de base géré
ou d'un gestionnaire de déploiement géré dans un environnement de gestion flexible,
les noms de noeuds doivent être identiques dans la Version 9.0
et les versions antérieures.
- Vérifiez que le paramètre défini pour le
nombre maximal de fichiers ouverts est 10000 ou plus. Un nombre
trop peu élevé risque d'entraîner divers échecs de migration.
gotcha
Procédure
- Installez WebSphere
Application Server, Network Deployment
Version 9.0 dans un nouveau répertoire de l'hôte cible.
Pour plus d'informations, reportez-vous à la documentation d'installation.
- Créez un profil de gestionnaire de travaux Version 9.0 qui constituera la cible de la migration du gestionnaire de travaux.
Exécutez la commande manageprofiles
avec les paramètres appropriés pour créer un profil de gestionnaire de travaux.
Exemple :
C:\WebSphere\AppServer90\bin>manageprofiles.bat -create -profileName JobMgr01
-profilePath C:\WebSphere\AppServer90\profiles\JobMgr01 -templatePath C:\WebSphere\AppServer90\profileTemplates\management
-serverType JOB_MANAGER -nodeName JobMgr01Node01 -cellName JobMgr01Cell01 -hostName localhost
- Arrêtez l'ancien gestionnaire de travaux. Tous les travaux de la base
de données de l'ancien gestionnaire de travaux seront migrés.
- Sauvegardez la configuration de gestionnaire de travaux en cours dans le répertoire de sauvegarde de migration en exécutant la commande WASPreUpgrade à partir du répertoire bin situé à la racine de la nouvelle installation de WebSphere
Application Server.
La commande WASPreUpgrade ne
modifie pas l'ancienne configuration.
- Exécutez la commande WASPreUpgrade. Par exemple :
C:\WebSphere\AppServer90\bin>WASPreUpgrade.bat C:\WAS70JobMgrbackup C:\WebSphere\AppServer70 -oldProfile JobMgr01
-traceString *=all=enabled -tracefile C:\WAS70JobMgrbackup\logs\WASPreMigrationSummary.log
- Consultez les avertissements ou les erreurs dans la sortie de la console et 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. Recherchez ensuite les éventuels avertissements et erreurs suivants dans les fichiers journaux :
- rép_sauvegarde_migration/logs/WASPreMigrationSummary.log
- WASPreUpgrade.horodatage.log
- 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.
- Restaurez la configuration de gestionnaire de travaux précédente Utilisez la commande WASPostUpgrade à partir du nouveau répertoire bin de la racine d'installation de WebSphere
Application Server pour restaurer la configuration précédente du gestionnaire de travaux que vous avez enregistrée dans le répertoire de sauvegarde de la migration.
Eviter les incidents: Pour éviter des incohérences de base de données; exécutez
WASPostUpgrade dès que l'exécution de
WASPreUpgrade est terminée. Une sauvegarde de la base de données est créée dans le cadre de l'exécution de
WASPreUpgrade. Si vous redémarrez l'ancien gestionnaire de travaux avant d'exécuter
WASPostUpgrade, la base de données dans la sauvegarde et la base de données dans l'ancien gestionnaire de travaux seront désynchronisées.
gotcha
- Exécutez la commande WASPostUpgrade pour restaurer la configuration
de gestionnaire de travaux sauvegardée dans le nouveau profil d'agent d'administration
Version 9.0. Par exemple :
C:\IBM\WebSphere\AppServer90\bin>WASPostUpgrade.bat C:\WAS70JobMgrbackup -oldProfile JobMgr01 -profileName JobMgr01
-traceString *=all=enabled -tracefile C:\WAS70JobMgrbackup\logs\WASPostMigrationSummary.log -username myuser -password mypass
- Consultez les avertissements ou les erreurs dans la sortie de la console et les journaux WASPostUpgrade. Une fois l'exécution de la
commande WASPostUpgrade terminée, recherchez les messages de type Failed
with errors ou Completed with warnings.
Recherchez ensuite les éventuels avertissements et erreurs suivants dans les fichiers journaux :
- rép_sauvegarde_migration/logs/WASPostMigrationSummary.log
- WASPostUpgrade.nom_profil_cible.horodatage.log
- WASPostUpgrade.nom_profil_cible.trace
Si des erreurs se sont produites, corrigez-les,
puis exécutez de nouveau la commande WASPostUpgrade. Vérifiez si les avertissements ont une incidence sur les autres activités lors de la migration ou de l'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.
- Démarrez le gestionnaire de travaux Version 9.0 et vérifiez que la Version 7.0 ou ultérieures et Version 9.0 du gestionnaire de travaux sont toutes deux en exécution.
- Accédez au répertoire bin du nouveau profil de gestionnaire de travaux Version 9.0.
- Exécutez la commande startServer jobmgr.
- Vérifiez si le fichier SystemOut.log contient des avertissements ou des erreurs.
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.
- Migrez les serveurs enregistrés.
Le gestionnaire de travaux Version 9.0 peut gérer les serveurs Version 7.0 ou ultérieures enregistrés. Pour que la topologie Version 7.0 ou ultérieures
fonctionne avec le gestionnaire de travaux Version 9.0, il n'est pas nécessaire de migrer les serveurs enregistrés.
Pour chaque serveur enregistré que vous comptez migrer vers la version
Version 9.0, procédez comme suit :
Résultats
Vous avez migré un profil de gestionnaire de travaux et ses serveurs d'applications
de base gérés associés de WebSphere
Application Server Version 7.0 ou ultérieures vers Version 9.0 à l'aide des outils de migration.