Migration des cellules vers de nouvelles machines hôtes à l'aide de l'outil de ligne de commande

Avant de commencer

Configurations prises en charge Configurations prises en charge:

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.

sptcfg

Examinez les informations relatives à la planification de la migration. Voir Knowledge Collection: Migration planning for WebSphere Application Server.

Conseil : Plutôt que de spécifier des paramètres individuels sur les commandes de migration, vous pouvez spécifier le paramètre -properties file_name.properties pour saisir un fichier de propriétés. Pour plus d'informations, voir Définition de votre migration à travers les propriétés.

Ces informations décrivent la migration des cellules vers une machine différente. Pour obtenir des informations sur la migration des cellules sur la même machine, voir Migration de cellules à l'aide des outils de ligne de commande.

Pourquoi et quand exécuter cette tâche

Cette tâche explique comment faire migrer chaque profil dans une configuration de cellule à partir d'une version précédente de WebSphere Application Server vers une installation WebSphere Application Server Version 9.0 hébergée sur une machine différente. 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. Les machines hôte source et cible n'ont pas besoin d'exécuter le même système d'exploitation.

Si WebSphere Application Server Version 9.0 n'est pas installé sur la machine hôte source, vous devez générer un fichier .jar de migration distante sur la machine hôte cible, qui correspond au système d'exploitation de la machine source. Le fichier .jar de migration distante fournit à l'hôte source l'outil WASPreUpgrade de la Version 9.0 que vous utilisez pour créer le répertoire de sauvegarde pour le profil.

La commande WASPreUpgrade doit être exécutée à partir de l'édition WebSphere Application Server cible. La machine source ne disposera pas de la nouvelle version de la commande WASPreUpgrade. Vous devez effectuer l'une des actions suivantes :
  • OPTION 1 : Installer la version du produit cible sur la machine source
  • OPTION 2 : Créer le fichier .jar de migration distante (en réalité, la commande WASPreUpgrade et les fichiers requis pour prendre en charge l'exécution, y compris Java, collectés à partir de l'installation cible)
Dès lors que vous disposez du fichier .jar de migration distante, vous pouvez l'exécuter sur la machine source.
Remarque : L'option 2 est plus facile à utiliser car elle ne nécessite pas d'installation complète. Dès lors que l'archive est créée, elle peut être utilisée pour de nombreuses machines source. Toutefois, si les machines cible et source figurent sur des architectures de système d'exploitation différentes, l'option 1 est requise car l'archive de migration distante est spécifique de l'architecture du système d'exploitation.

Lorsque les machines source ont toutes la même architecture de système d'exploitation et que celle-ci est différente de celle de la machine cible, l'installation de l'édition cible est nécessaire sur une seule machine source. A partir de cette machine source, le fichier JAR de migration distante peut être créé et utilisé sur les autres machines source.

Cette procédure suppose que la configuration précédente est en cours d'exécution et que vous migrez tous les profils vers une machine hôte différente.

Eviter les incidents Eviter les incidents: 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
Pour les utilisateurs en transition Pour les utilisateurs en transition: WebSphere Virtual Enterprise et Intelligent Management nécessitaient auparavant des outils de migration distincts ; à présent, ils sont migrés dans le cadre des procédures de migration standard.trns
Restriction : La migration distante d'IBM® i ou z/OS n'est pas prise en charge.

Procédure

  1. 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.
    1. Accédez au répertoire racine_profil_gestionnaire_déploiement/bin.
    2. Exécutez la commande backupConfig avec les paramètres appropriés et sauvegardez la configuration de profil en cours dans un fichier. Exemple :
      [Windows]
      previous_version_app_server_root\v70dmgr01\bin\
      backupConfig.bat \mybackup_old_host\v70dmgr01backupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70dmgr01/bin/backupConfig.sh 
      /mybackup_old_host/v70dmgr01backupBeforeV90migration.zip -username 
      myuser -password mypass -nostop
      mon_ancien_hôte_sauvegarde est l'emplacement où les points de restauration de la configuration sont stockés.
    3. Pour chaque noeud de la configuration, accédez au répertoire racine_profil_noeud/bin.
    4. Exécutez la commande backupConfig avec les paramètres appropriés et sauvegardez la configuration de profil en cours dans un fichier. Exemple :
      [Windows]
      previous_version_app_server_root\v70node01\bin\backupConfig.bat 
      \mybackup_old_host\v70node01backupBeforeV90migration.zip -username
       myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70node01
      /bin/backupConfig.sh /mybackup_old_host/v70node01rbackupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
  2. Installez WebSphere Application Server, Network Deployment Version 9.0 dans un nouveau répertoire sur chaque hôte cible.

    Pour plus d'informations, reportez-vous à la documentation d'installation.

  3. Créez le fichier .jar de migration distante. Ce fichier .jar contient les fichiers nécessaires à l'exécution de la commande WASPreUpgrade sur un système sur lequel WebSphere Application Server Version 9.0 n'est pas installé.
    Eviter les incidents Eviter les incidents: Vous devez créer le fichier .jar de migration distante sur le même système d'exploitation et la même architecture que pour l'installation de la source. Etant donné que l'archive générée contient du code spécifique au système d'exploitation, celle-ci s'exécute uniquement sur cette architecture.gotcha
    1. Identifiez le système d'exploitation et l'architecture du profil source. Si le système d'exploitation et l'architecture du profil source et du profil cible diffèrent, vous devez installer WebSphere Application Server Version 9.0 sur un système qui correspond au profil source avant de créer le fichier JAR de migration. Une fois que vous avez généré le fichier JAR de migration distante, il s'exécutera sur tout système dont le système d'exploitation et l'architecture correspondent.
    2. Créez le fichier JAR de migration distante.
      1. A l'invite de commande, entrez :cd $WAS_HOME/bin/migration/bin
      2. Pour créer le fichier .jar, exécutez : createRemoteMigrJar.bat(sh) -targetDir <rép pour le fichier jar de migration distante> . Le fichier suivant est créé : WAS_V90_OS.arch_RemoteMigrSupport.jar. Par exemple, WAS_V90_windows.amd64_RemoteMigrSupport.jar.
    3. Préparez le système distant pour la commande WasPreUpgrade.
      1. Envoyez le fichier .jar au système sur lequel votre profil source réside.
      2. Extrayez le fichier dans un emplacement temporaire.
      3. Accédez au répertoire bin dans l'emplacement temporaire.

      Vous êtes maintenant prêt à exécuter la commande WASPreUpgrade sur le profil source, mais, n'exécutez pas cette commande tant que vous n'y aurez pas été invité dans une étape ultérieure.

  4. Créez le profil de gestionnaire de déploiement cible. Le profil de gestionnaire de déploiement cible est un nouveau profil constituant la cible de la migration.
    Eviter les incidents Eviter les incidents: Les noms de cellule et de noeud de la Version 9.0 doivent correspondre à ceux de la configuration précédente. Si vous créez des cellules et noeuds en leur affectant de nouveaux noms, la migration échoue.gotcha

    Pour créer un profil de gestionnaire de déploiement, exécutez la commande manageprofiles avec les paramètres appropriés.

    Exemple :
    [Windows]
    version_9_install_root\bin\manageprofiles.bat -create 
    -profileName v70toV90dmgr01 -templatePath \opt\WebSphereV90\profileTemplates\
    management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName 
    -cellName currentCellName -hostName mydmgrhost.company.com
    [AIX][HP-UX][Linux][Solaris]
    version_9_install_root/bin/manageprofiles.sh -create 
    -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/
    management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName 
    -cellName currentCellName -hostName mydmgrhost.company.com
  5. Sauvegardez la configuration de gestionnaire de déploiement en cours dans le répertoire de sauvegarde de la migration. Pour sauvegarder la configuration de gestionnaire de déploiement en cours, exécutez la commande WASPreUpgrade. La commande WASPreUpgrade ne modifie pas l'ancienne configuration.
    1. Exécutez la commande WASPreUpgrade avec le paramètre -machineChange true pour sauvegarder la configuration du gestionnaire de déploiement en cours dans un répertoire de sauvegarde de la migration. Par exemple :
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90dmgr01 
      \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90dmgr01 
      /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      mon_ancien_hôte_sauvegarde est le répertoire vers lequel les fichiers de configuration de profil sont copiés en préparation de la migration vers le nouvel hôte.

      Si vous effectuez une migration de la version 8.0 vers la Version 9.0 et que votre profil est un gestionnaire de déploiement, le profil de la version 8.0 est arrêté pendant l'exécution de 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 indiquez l'option correspondante dans l'assistant de migration.

      Eviter les incidents Eviter les incidents: Si vous spécifiez -machineChange true, vous devez mettre à jour l'URL du gestionnaire de travaux pour toutes les ressources (telles que les autres gestionnaires de déploiement ou les serveurs d'application) qui sont gérés par la fonction du gestionnaire de travaux du gestionnaire de la version 8.0 du gestionnaire de déplacement après la migration. gotcha
    2. 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 :
      • mybackup_old_host/v70toV90dmgr01/logs/WASPreMigrationSummary.log
      • mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.timestamp.log
      • mybackup_old_host/v70toV90dmgr01/logs/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.

  6. Archivez le répertoire de sauvegarde créé par la commande WASPreUpgrade.
    Eviter les incidents Eviter les incidents: N'utilisez pas l'outil d'archivage Windows car il est incompatible avec une migration de WebSphere Application Server.gotcha
    1. Utilisez l'outil d'archivage de votre choix pour créer un fichier compressé du répertoire de sauvegarde. Exemple :
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
    2. Déplacez le fichier archivé vers la machine cible.
    3. Créez un répertoire sur la machine cible et extrayez le fichier archivé dans le nouveau répertoire. Par exemple :
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      mon_nouvel_hôte_sauvegarde est le répertoire vers lequel vous migrez vos fichiers.
  7. Restaurez la configuration du gestionnaire de déploiement précédente.

    Exécutez la commande WASPostUpgrade depuis le répertoire bin du nouveau profil de gestionnaire de déploiement pour restaurer la configuration de gestionnaire de déploiement précédente, que vous avez sauvegardée dans le répertoire de sauvegarde de la migration. Si vous utilisez les options présentées dans l'exemple, tous les ports sont conservés et toutes les applications sont installées.

    1. Exécutez la commande WASPostUpgrade pour restaurer la configuration de gestionnaire de déploiement enregistrée dans le nouveau profil de gestionnaire de déploiement de la Version 9.0. Par exemple :
      [Windows]
      version_9_install_root\bin\WASPostUpgrade.bat \
      mybackup_new_host\v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 
      70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE
      -keepDmgrEnabled TRUE -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_install_root/bin/WASPostUpgrade.sh /
      mybackup_new_host/v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile
       70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE
      -keepDmgrEnabled TRUE -username myuser -password mypass
      mon_nouvel_hôte_sauvegarde est le répertoire depuis lequel les fichiers de configuration de profil source sont migrés.

      Si vous voulez continuer à utiliser l'ancien profil après sa migration, spécifiez le paramètre -clone TRUE. Si vous spécifiez une migration clone pour le gestionnaire de déploiement, vous devez également cloner tous ses noeuds fédérés.

    2. 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 é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 :
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostMigrationSummary.log
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.timestamp.log
      • mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.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.

    Eviter les incidents Eviter les incidents: Une fois la commande WASPostUpgrade exécutée, ne redémarrez pas le nouveau gestionnaire de déploiement. Vous devez exécuter quelques autres étapes avant de procéder à ce redémarrage.gotcha
  8. Sauvegardez la configuration migrée 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 Eviter les incidents: En cas d'échec de la migration du noeud, vous pouvez rétablir le point précédant cet échec. Vous pouvez exécuter des actions correctives et relancer l'opération de migration.gotcha
    1. Accédez au répertoire racine_profil_gestionnaire_déploiement/bin.
    2. Exécutez la commande backupConfig avec les paramètres appropriés et sauvegardez la configuration de profil Version 9.0 dans un fichier. Exemple :
      [Windows]
      version_9_profile_root\profiles\v70toV90dmgr01\
      bin\backupConfig.bat \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrOnly.zip 
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/profiles/v70toV90dmgr01/bin/backupConfig.sh /
      mybackup_new_host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username 
      myuser -password mypass
      mon_ancien_hôte_sauvegarde est l'emplacement où les points de restauration de la configuration sont stockés.
  9. Arrêtez et désactivez le gestionnaire de déploiement se trouvant sur l'ancien hôte.
    1. Arrêtez le gestionnaire de déploiement se trouvant sur l'ancien hôte.
    2. Désactivez le gestionnaire de déploiement se trouvant sur l'ancien hôte. Pour désactiver ce gestionnaire de déploiement, vous devez renommer le fichier serverindex.xml associé comme indiqué dans les informations suivantes :
      Ancien nom
      $PROFILE_ROOT/config/cells/nom_cellule/nodes/nom_noeud_gestionnaire_déploiement/serverindex.xml
      Nouveau nom
      $PROFILE_ROOT/config/cells/nom_cellule/nodes/nom_noeud_gestionnaire_déploiement/serverindex.xml_disabled
  10. Démarrez le gestionnaire de déploiement Version 9.0 sur le nouvel hôte.
    1. Accédez au nouveau répertoire Version 9.0 deployment_manager_profile_root/bin.
    2. Exécutez la commande startManager.
    3. 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.
      Consultez les avertissements pour voir s'ils ont un impact sur les activités de migration ou d'exécution de noeud lorsque le gestionnaire de déploiement Version 9.0 a démarré.
    4. Vérifiez que le gestionnaire de déploiement de la Version 9.0 démarre correctement.
  11. Synchronisez manuellement les anciens noeuds vers le nouveau gestionnaire de déploiement Version 9.0.

    Vérifiez que le gestionnaire de déploiement Version 9.0 se trouvant sur le nouvel hôte est en cours d'exécution. Vous devez vous connecter à la machine qui contient les anciens noeuds et exécuter la commande syncNode.

    1. Arrêtez l'agent de noeud.
    2. Obtenez les numéros d'hôte et de port du gestionnaire de déploiement et mettez à jour le fichier racine_profil_agent_noeud/properties/wsadmin.properties. Remplacez la valeur de com.ibm.ws.scripting.host par le nouvel hôte. Remplacez la valeur de com.ibm.ws.scripting.port par le nouveau port.
    3. Exécutez la commande syncNode à partir du répertoire bin. Exemple :
      [Windows]
      node_agent_install_root\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      node_agent_install_root/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
    4. Si la synchronisation se déroule correctement, démarrez l'agent de noeud.
  12. Faites migrer les plug-ins pour les serveurs Web.
    1. Vérifiez que le gestionnaire de déploiement de la Version 9.0 est en cours d'exécution.
    2. Mettez à niveau la version du plug-in de serveur Web utilisée dans la cellule.
    3. Consultez les informations de support qui s'appliquent au type et à la version de votre serveur Web.
  13. Faites migrer les installations de client d'application.

    Si la version du client WebSphere Application est la version 7.0, vous devez également exécuter les commandes WASPreUpgrade et WASPostUpgrade pour faire migrer les paramètres de sécurité existants.

    1. Identifiez tous les hôtes client que vous devez migrer.
    2. Installez le client d'application WebSphere Version 9.0.
    3. 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 la migration. Par exemple :
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
    4. Exécutez la commande Version 9.0 WASPostUpgrade pour restaurer les paramètres de sécurité de client d'application dans le nouveau client Version 9.0. Par exemple :
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90 
  14. Faites migrer les noeuds.
    Important : Ces étapes s'appliquent uniquement aux migrations entre des machines différentes. Si la migration ne se fait pas entre des machines différentes, voir les informations sur la migration des noeuds dans Migration de cellules à l'aide des outils de ligne de commande. Vérifiez que le gestionnaire de déploiement de la Version 9.0 est en cours d'exécution. Pour chaque noeud que vous comptez migrer vers la Version 9.0, procédez comme suit.
    Eviter les incidents Eviter les incidents: Pour que la migration aboutisse, 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 ou une version ultérieure.gotcha
    1. Installez WebSphere Application Server Version 9.0 sur chaque hôte cible. Pour plus d'informations, voir la documentation sur l'installation d'un environnement de traitement des applications.
    2. 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 :
      [Windows]
      version_9_install_root\bin\manageprofiles.bat 
      -create -profileName node1 -templatePath \opt\
      WebSphereV90\profileTemplates\managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
      [AIX][HP-UX][Linux][Solaris]
      version_9_install_root/bin/manageprofiles.sh 
      -create -profileName node1 -templatePath 
      /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. Utilisez le fichier .jar de migration distante que vous avez créé pour la migration du gestionnaire de déploiement pour rendre la commande WASPreUpgrade disponible sur la machine du noeud en cours.
      Remarque : Cette étape doit être effectuée uniquement si le noeud source et le gestionnaire de déploiement ne sont pas sur la même machine, et ne peut être exécutée que si la architecture de la machine est la même.
      Pour plus d'informations, voir l'étape 3 de ce scénario, Créez le fichier .jar de migration distante.
    4. Exécutez la commande WASPreUpgrade avec le paramètre -machineChange true pour sauvegarder la 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 :
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90node1 
      \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90node1 
      /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
    5. Recherchez d'éventuels messages d'erreur et d'avertissement dans la sortie de la console WASPreUpgrade. Les messages suivants peuvent s'y trouver : "Failed with errors" ou "Completed with warnings". Recherchez également les messages d'erreur ou d'avertissement dans les fichiers journaux suivants :
      • myback_old_host/v70toV90node1/logs/WASPreMigrationSummary.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.timestamp .log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.trace

      Si la commande WASPreUpgrade s'exécute correctement, il n'est pas nécessaire de rechercher les messages d'erreur ou d'avertissement dans les fichiers journaux.

    6. Utilisez l'outil d'archivage de votre choix pour créer un fichier compressé du répertoire de sauvegarde qui a été créé par la commande WASPreUpgrade. Exemple :
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
    7. Déplacez le fichier archivé vers la machine cible.
    8. Créez un répertoire sur la machine cible et extrayez le fichier archivé dans le nouveau répertoire. Par exemple :
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      mon_nouvel_hôte_sauvegarde est le répertoire depuis lequel les fichiers de configuration de profil sont migrés.
    9. Arrêtez les serveurs d'application se trouvant sur l'ancien noeud, puis l'agent de noeud se trouvant sur le même noeud.
    10. Arrêtez et désactivez le noeud sur l'ancien hôte. Vérifiez que vous n'utilisez pas ce noeud. Pour désactiver ce noeud, vous devez renommer le fichier serverindex.xml associé comme indiqué dans les informations suivantes :
      Ancien nom
      $PROFILE_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml
      Nouveau nom
      $PROFILE_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml_disabled
    11. 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 :
      [Windows]
      version_9_install_root\bin\WASPostUpgrade.bat \
      mybackup_new_host\v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE 
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_install_root/bin/WASPostUpgrade.sh /
      mybackup_new_host/v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE 
      -username myuser -password mypass

      Si vous avez cloné le gestionnaire de déploiement, vous devez également cloner tous les noeuds fédérés. Spécifiez le paramètre -clone TRUE et le nouveau nom d'hôte du gestionnaire de déploiement et le port SOAP ou RMI. Ne clonez pas les noeuds fédérés à moins que le gestionnaire de déploiement n'ait été cloné.

      [Windows]
      version_9_install_root\bin\WASPostUpgrade.bat \
      mybackup_new_host\v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -includeApps TRUE 
      -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
      [AIX][HP-UX][Linux][Solaris]
      version_9_install_root/bin/WASPostUpgrade.sh /
      mybackup_new_host/v70toV90node1 -profileName v70toV90node1 
      -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig 
      TRUE -includeApps TRUE 
      -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
    12. Recherchez les messages suivants dans la sortie de la console WASPostUpgrade : Les messages suivants peuvent s'y trouver : "Failed with errors" ou "Completed with warnings". Recherchez également les messages d'erreur ou d'avertissement suivants dans les fichiers journaux suivants :
      • mybackup_new_host/v70toV90node1/logs/WASPostMigrationSummary.log
      • mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.timestamp.log
      • mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.trace
      Remarque : Si la commande WASPostUpgrade échoue, vous devrez peut-être restaurer le gestionnaire de déploiement Version 9.0 à partir du fichier de configuration de la sauvegarde. 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.

    13. Recherchez d'éventuels messages d'erreur ou d'avertissement 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.
    14. Démarrez l'agent du noeud Version 9.0 migré.
    15. 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.
    16. Facultatif : Synchronisez la cellule si le processus de synchronisation automatique n'est pas activé.
    17. Démarrez les serveurs d'applications appropriés sur le noeud Version 9.0 migré.
    18. Exécutez la commande backupConfig et sauvegardez la configuration de profil Version 9.0 dans un fichier. Exemple :
      [Windows]
      version_9_profile_root\v70toV90node1\bin\backupConfig.bat 
      \mybackup_new_host\v70toV90node1.zip -username myuser 
      -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/v70toV90node1/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90node1.zip -username myuser 
      -password mypass -nostop
      Utilisez un nouveau nom de fichier de sauvegarde à chaque exécution de la commande backupConfig.
    19. Sauvegardez la configuration du gestionnaire de déploiement à l'aide de la commande backupConfig. Sur l'hôte de gestionnaire de déploiement Version 9.0, accédez au répertoire deployment_manager_profile_root/bin. Exécutez la commande backupConfig et sauvegardez la configuration de profil Version 9.0 dans un fichier. Par exemple :
      [Windows]
      version_9_profile_root\v70toV90dmgr01\bin\backupConfig.bat 
      \mybackup_new_host\v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/v70toV90dmgr01/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      Remarque : Pour chaque noeud migré, sauvegardez la configuration du gestionnaire de déploiement de la Version 9.0 dans un nouveau fichier de sauvegarde.
    20. Répétez ces étapes pour les noeuds supplémentaires.

Résultats

Vous avez utilisé les outils de migration pour faire migrer des configurations de cellule à partir d'une version précédente de WebSphere Application Server vers de nouvelles machines hôte qui exécutent WebSphere Application Server Version 9.0.


Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_migrate_remote_commandline
Nom du fichier : tmig_migrate_remote_commandline.html