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

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.

1. Sauvegardez le gestionnaire de déploiement et tous les anciens noeuds.

   En cas d'échec lors de la migration, enregistrez la configuration actuelle du gestionnaire de déploiement et des nœuds dans un fichier que vous pourrez utiliser ultérieurement à des fins de restauration à l'aide de la commande backupConfig commande.

   1. deployment_manager_profile_root/bin Accédez au répertoire.
   2. 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 de Windows peuvent adapter les exemples de cette rubrique pour les exécuter sur un ordinateur Windows. Par exemple, pour exécuter la backupConfig commande, utilisez backupConfig ou backupConfig.bat comme commande. Modifiez les chemins d'accès aux fichiers en fonction 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.
   3. Pour chaque nœud de la configuration, accédez au node_profile_root/bin répertoire.
   4. Exécutez la backupConfig commande avec les paramètres appropriés, puis 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

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

4. 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 du nouveau profil bin du gestionnaire de déploiement.

   La WASPreUpgrade commande ne modifie pas la configuration de Version 7.0 ou des versions ultérieures. Pour plus d'informations, consultez la commande « WASPreUpgrade ».

   Remarque : si vous effectuez une migration depuis la version 8.0 ou une version 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 désactivé 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.
   1. Exécutez la WASPreUpgrade commande en indiquant le répertoire de sauvegarde de la migration, le répertoire racine de l'installation de Version 7.0 ou une version ultérieure, ainsi que le nom du profil du gestionnaire de déploiement.

      /opt/WebSphereV90/bin/WASPreUpgrade.sh /mybackup/v70toV90dmgr01 
      /opt/WebSphereV70 -oldProfile v70dmgr01

   2. Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPreUpgrade les journaux.

      Une fois la WASPreUpgrade commande exécutée, vérifiez la sortie de la console pour voir siFailed with errorsouCompleted with warningsmessages. Si l'un ou l'autre de ces messages apparaît dans la sortie, vérifiez les WASPreUpgrade.old_Profile.timestamp.log fichiers journaux et WASPreUpgrade.trace 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 ces avertissements ont une incidence sur d'autres activités de migration ou d'exécution sur 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 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 ».

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

      Pour éviter tout problème : veillez à toujours indiquer les -oldProfile paramètres et -profileName lorsque vous exécutez la WASPostUpgrade commande.
   2. Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPostUpgrade les journaux.

      Une fois la WASPostUpgrade commande exécutée, vérifiez la sortie de la console pour voir siFailed with errorsouCompleted with warningsmessages. Si l'un ou l'autre de ces messages apparaît dans la sortie, vérifiez les migration_backup_dir/logs/WASPostUpgrade.target_profile_name.timestamp.log fichiers journaux et migration_backup_dir/logs/WASPostUpgrade.target_profile_name.trace 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 ces avertissements ont une incidence sur d'autres activités de migration ou d'exécution sur 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, consultez la 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 du gestionnaire de déploiement de Version 9.0 dans un fichier en exécutant la backupConfig commande sur le gestionnaire de déploiement de Version 9.0.
   Évitez les problèmes : il s'agit d'une étape importante du 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.
   1. deployment_manager_profile_root/bin Accédez au répertoire
   2. Exécutez la backupConfig commande en lui passant les paramètres appropriés.

      /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh 
      /mybackupdir/v70toV90dmgr01backupMigratedDmgrOnly.zip 
      -username myuser -password mypass

7. Lancez 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 des profils bin du gestionnaire de déploiement de la nouvelle version d' 9.0.
   2. Exécutez la startManager commande.
   3. Pendant l'exécution du gestionnaire de déploiement, vérifiez si le SystemOut.log fichier contient des avertissements ou des erreurs.
      Remarque : cette rubrique fait référence à un ou plusieurs fichiers journaux du serveur d'applications. À titre d'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 SystemOut.log les fichiers, SystemErr.log, trace.log, et activity.log sur les systèmes distribués et les systèmes de type « IBM® i ». Vous pouvez également utiliser HPEL en association avec les 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 en savoir plus sur l 'utilisation de HPEL, consultez les informations relatives à l'utilisation de HPEL pour le dépannage des 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. 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 installations de client d'application.

   Migrer les ressources client vers des 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.0WASPreUpgrade » 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

   3. Exécutez la commande « Version 9.0WASPostUpgrade » pour restaurer les paramètres de sécurité du client de l'application sur le nouveau client de la version 9.0.

      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup/v70clientToV90 

10. Faites migrer les noeuds.

    Utilisez les outils de migration pour faire passer les versions antérieures des nœuds de la configuration à la version 9.0. Suivez 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.
    1. Assurez-vous que le gestionnaire de déploiement Version 9.0 est en cours d'exécution.
    2. 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

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

    4. Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPreUpgrade les journaux.

       Vérifiez si la WASPreUpgrade sortie de la console contient des messages tels queFailed with errorsouCompleted with warnings. Si la commande ne s'est pas exécutée correctement, consultez les journaux suivants pour vérifier s'il y a des erreurs ou des 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 correctement, il n'est pas nécessaire de vérifier les journaux à la recherche d'erreurs ou d'avertissements.

    5. Arrêtez l'agent de noeud.
       Si des nœuds fonctionnant sous la version 7.0 ou une version ultérieure sont en cours d'exécution lors d'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.
    6. Exécutez la WASPostUpgrade commande pour restaurer la configuration du nœud enregistrée dans le nouveau profil géré de la version 9.0.

       /opt/WebSphereV90/bin/WASPostUpgrade.sh /mybackup/v70toV90node1 
       -profileName currentNode1Name -oldProfile 70node1 -resolvePortConflicts incrementCurrent 
       -backupConfig true -username myuser -password mypass

    7. Vérifiez les avertissements ou les erreurs dans la sortie de la console et WASPostUpgrade les journaux.

       Vérifiez la WASPostUpgrade sortie de la console pourFailed with errorsouCompleted with warningsmessages. Si l'un ou l'autre de ces messages apparaît dans la sortie, consultez les journaux suivants pour vérifier s'il y a des erreurs ou des avertissements.

       • 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 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, consultez la commande « WASMigrationAppInstaller ».

       Si la commande s'est exécutée correctement, il n'est pas nécessaire de vérifier les journaux à la recherche d'erreurs ou d'avertissements.

    8. Vérifiez si le fichier « Version 9.0 deployment manager SystemOut.log » contient des avertissements ou des erreurs.
       Remarque : cette rubrique 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 en savoir plus sur l 'utilisation de HPEL, consultez les informations relatives à l'utilisation de HPEL pour le dépannage des applications.
    9. Démarrez l'agent de nœud de la version 9.0 après la migration.
    10. Vérifiez si le gestionnaire de déploiement et le fichier de nœud SystemOut.log de Version 9.0 contiennent des avertissements ou des erreurs.
    11. Synchronisez la cellule.
    12. Arrêtez tous les serveurs d'applications sur le nœud migré de la version 9.0.
    13. Démarrez les serveurs d'applications appropriés sur le nœud migré de Version 9.0.
    14. 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 batch, 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. 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.
    16. 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.

        /opt/WebSphereV90/profiles/v70toV90dmgr01/bin/backupConfig.sh 
        /mybackupdir/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
        -username myuser -password mypass

        Si vous migrez un nœud vers un autre hôte, consultez les informations relatives à la migration des nœuds dans la section « Migration de cellules vers de nouvelles machines hôtes à l'aide de l'outil en ligne de commande ».

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

    1. Assurez-vous que le gestionnaire de déploiement Version 9.0 est en cours d'exécution.
    2. Mettez à jour la version du plug-in de serveur Web utilisé dans la cellule.
    3. 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.
       Pour plus d'informations sur la création de définitions de serveurs Web, consultez la section « Implémentation d'un plug-in de serveur Web ».