[AIX Solaris HP-UX Linux Windows][IBM i]

Migration de cellules à l'aide des outils 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

Vérifiez les informations de planification de la migration en consultant la page suivante : 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.

[AIX Solaris HP-UX Linux Windows]Ce scénario couvre la migration des cellules sur le même hôte. Si vous prévoyez de migrer des cellules vers un hôte différent, voir Migration de cellules vers de nouvelles machines hôte à l'aide de l'outil de ligne de commande.

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.

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: Les produits suivants nécessitaient auparavant des outils de migration distincts ; à présent, ils sont migrés dans le cadre des procédures de migration standard :
  • WebSphere Extended Deployment Compute Grid ou Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise ou Intelligent Management
Pour plus d'informations sur ces changements, voir Nouveautés pour la migration.trns

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, à l'aide de la commande backupConfig. Pour plus d'informations, reportez-vous à la rubrique Commande backupConfig.

    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 : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV70/profiles/v70dmgr01/bin/backupConfig.sh /mybackupdir/v70dmgr01backupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
      [IBM i]
      /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/v70dmgr01/bin/backupConfig /mybackupdir/
      v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
    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 : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV70/profiles/v70node01/bin/backupConfig.sh /mybackupdir/
      v70node01backupBeforeV90migration.zip -username myuser -password mypass -nostop
      [IBM i]
      /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/v70node01/bin/backupConfig 
      /mybackupdir/v70node01rbackupBeforeV90migration.zip -username myuser -password mypass -nostop
  2. 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.

  3. 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.

    Eviter les incidents 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
    Exemple : [AIX Solaris HP-UX Linux Windows]
    /opt/WebSphereV90/bin/manageprofiles.sh -create -profileName v70toV90dmgr01 
    -templatePath /opt/WebSphereV90/profileTemplates/management -serverType 
    DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName 
    -hostName mydmgrhost.company.com
    [IBM i]
    /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
  4. 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.
    1. Exécutez la commande WASPreUpgrade. Par exemple :[AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile 70dmgr01
      [IBM i]
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/v70toV90dmgr01 
      /QIBM/UserData/WebSphere/AppServer/V9/ND/profiles/myCurrentDmgrProfile 
    2. 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.

  5. 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.

    1. Exécutez la commande WASPostUpgrade. Par exemple :[AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90dmgr01 -profileName 
      v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE 
      -includeApps TRUE -keepDmgrEnabled FALSE 
      -username myuser -password mypass
      [IBM i]
      /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
      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.

      [AIX Solaris HP-UX Linux Windows]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. La spécification d'une migration clone définit automatiquement -keepDmgrEnabled sur true.

      Eviter les incidents Eviter les incidents: Indiquez toujours les paramètres -oldProfile et -profileName lorsque vous exécutez la commande WASPostUpgrade.gotcha
    2. 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.

  6. 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 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
    1. Accédez au répertoire racine_profil_gestionnaire_déploiement/bin.
    2. Exécutez la commande backupConfig avec les paramètres appropriés. Exemple : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh /mybackupdir/
      v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
      [IBM i]
      /QIBM/UserData/WebSphere/AppServer/V9/ND/profiles/myCurrentDmgrProfile/bin/
      backupConfig.sh /mybackupdir/v70toV90dmgr01backupMigratedDmgrOnly.zip 
      -username myuser -password mypass
  7. 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.

    1. Accédez au répertoire bin du profil de gestionnaire de déploiement de la Version 9.0.
    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.
    4. 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.
  8. [AIX Solaris HP-UX Linux Windows]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 :
    1. 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.
    2. 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.
  9. 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.
  10. Faites migrer les installations de client d'application.

    Migrez les ressources client vers les ressources de niveau Version 9.0.

    1. Installez le client d'application WebSphere Version 9.0.

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

    2. 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
    3. 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 
  11. 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 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
    1. Vérifiez que le gestionnaire de déploiement de la Version 9.0 est en cours d'exécution.
    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 : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/manageprofiles.sh -create -profileName node1 
      -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
      [IBM i]
      /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
    3. 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 : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90node1 /opt/WebSphereV70 
      -oldProfile 70node1
      [IBM i]
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/
      v70toV90node1 /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/currentNode1Name  
    4. 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.

    5. 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.
    6. 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 : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 
      -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -username myuser -password mypass
      [IBM i]
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade /mybackup/v70toV90node1 
      -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -username myuser -password mypass
      [AIX Solaris HP-UX Linux Windows]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é.
      /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 
      -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
      -backupConfig TRUE -username myuser -password mypass
      -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
    7. 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.

    8. 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.
    9. Démarrez l'agent du noeud Version 9.0 migré.
    10. 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.
    11. Synchronisez la cellule.
    12. Arrêtez tous les serveurs d'applications sur le noeud Version 9.0 migré.
    13. Démarrez les serveurs d'applications appropriés sur le noeud Version 9.0 migré.
    14. [AIX Solaris HP-UX Linux Windows]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 Version 9.0 qui hébergent vos applications par lots fonctionnent correctement :
      1. 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.
      2. 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.
    15. Sauvegardez la configuration du profil Version 9.0 dans un fichier en exécutant la commande backupConfig avec les paramètres appropriés. Exemple : [AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/profiles/v70toV90node1/bin/backupConfig.sh /mybackupdir/
      v70toV90node1.zip -username myuser -password mypass -nostop
      [IBM i]
      /QIBM/UserData/WebSphere/AppServer/V9/profiles/v70toV90node1/bin/backupConfig 
      /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.
    16. 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 :[AIX Solaris HP-UX Linux Windows]
      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh /mybackupdir/
      v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
      [IBM i]
      /QIBM/UserData/WebSphere/AppServer/V9/profiles/currentDmgrName/bin/
      backupConfig.sh /mybackupdir/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      [AIX Solaris HP-UX Linux Windows]Remarque : Si vous effectuez la migration vers un hôte différent, reportez-vous aux informations sur la migration des noeuds dans Migration de cellules vers de nouvelles machines hôte à l'aide de l'outil de ligne de commande.

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.


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-mp&topic=tmig_migrate_cells_commandline
Nom du fichier : tmig_migrate_cells_commandline.html