Migration d'un profil d'agent d'administration et de son jeu de serveurs d'applications de base gérés enregistré

Les profils d'agent d'administration gèrent de multiples serveurs d'applications de base dans des environnements tels que l'environnement de développement, de test d'unité ou la partie d'un parc de serveurs qui réside sur une machine unique. Avant de pouvoir faire migrer des serveurs d'applications de base gérés depuis Version 7.0 ou ultérieures vers Version 9.0, vous devez tout d'abord faire migrer l'agent d'administration.

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.

Pourquoi et quand exécuter cette tâche

Un serveur d'applications de base devient géré lorsqu'il est enregistré avec un seul agent d'administration. Un agent d'administration peut gérer un ou plusieurs serveurs d'applications de base et doit être au même niveau de version et se trouver sur la même machine que les serveurs d'applications de base qu'il gère. En raison de cette restriction, les gants d'administration de l'ancienne comme de la nouvelle version s'exécutent simultanément jusqu'à ce que tous les serveurs d'applications de base gérés aient migré. La migration d'un agent d'administration ne transpose pas ses anciennes valeurs de ports. Cependant, toutes les autres données de configuration sont migrées.

Accédez à la console de l'agent d'administration Version 9.0 à l'aide des ports sécurisés WC_ adminhost ou WC_ adminhost_ définis dans le nouveau fichier serverindex.xml de l'agent d'administration Version 9.0. L'agent d'administration Version 7.0 ou ultérieures ne doit pas être fermé ou désactivé lors de cette procédure.

Pour effectuer la migration du serveur d'applications de base géré dans un environnement de gestion flexible, assurez-vous que les noms de noeud sont identiques sur la Version 9.0 et les éditions antérieures.

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

Procédure

  1. Installez WebSphere Application Server Version 9.0 dans un nouveau répertoire de l'hôte cible.

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

  2. Créez un profil d'agent d'administration Version 9.0 qui constituera la cible de la migration de l'agent d'administration.

    Exécutez la commande manageprofiles avec les paramètres appropriés pour créer un nouveau profil d'agent d'administration.

    Exemple :
    /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/manageprofiles -create -profileName AdminAgent01 -templatePath /QIBM/ProdData/WebSphere/AppServer/V9/ND/profileTemplates/management 
    -serverType ADMIN_AGENT-nodeName AdminAgentNode01 -cellName AdminAgentCell01 -hostName mydmgrhost.company.com
  3. Vérifiez que tous les travaux en cours sont terminés sur les profils gérés.
  4. Arrêtez d'interroger le gestionnaire de travaux sur les profils obtenant des travaux du gestionnaire de travaux.

    Avant de commencer à interroger le gestionnaire de travaux, exécutez les commandes WASPreUpgrade et WASPostUpgrade pour le profil géré. Pour plus d'informations, reportez-vous à la section relative au groupe de commandes ManagedNodeAgent pour l'objet AdminTask à l'aide du script wsadmin.

  5. Sauvegardez la configuration d'agent d'administration en cours 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.

    1. Exécutez la commande WASPreUpgrade.

      Pour obtenir des informations sur les paramètres de commande, voir Commande WASPreUpgrade.

      Par exemple :
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/WAS70AdminAgentbackup
      /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/AppServer70 
      -traceString *=all=enabled -tracefile /mybackup/logs/WASPreMigrationSummary.log
    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 :
      • 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.

  6. Restaurez la configuration précédente de l'agent d'administration en exécutant la commande WASPostUpgrade à partir du nouveau répertoire WebSphere Application Server install root bin.
    1. Utilisez la commande WASPostUpgrade pour restaurer la configuration de l'agent d'administration dans le nouveau profil d'agent d'administration Version 9.0. Par exemple :
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade /mybackup/WAS70AdminAgentbackup 
      -profileName AdminAgent01 -backupConfig TRUE -includeApps TRUE -keepDmgrEnabled FALSE 
      -username myuser -password mypass
    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 :
      • 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 é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.

  7. Démarrez l'agent d'administration Version 9.0 et veillez à ce que les deux agents d'administration Version 7.0 ou ultérieures et Version 9.0 sont en cours d'exécution.
    1. Accédez au répertoire bin du nouveau profil d'agent d'administration Version 9.0.
    2. Exécutez la commande startServer adminagent.
    3. 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.
  8. Migrez les serveurs d'applications de base gérés.
    Eviter les incidents Eviter les incidents: Pour que la migration aboutisse :
    • Les serveurs d'applications de base gérés doivent résider sur la même machine que l'agent d'administration associé.
    • Les noms de noeuds dans la Version 9.0 et les versions antérieures doivent être identiques.
    gotcha

    Pour chaque serveur d'applications de base géré que vous comptez migrer vers la Version 9.0, procédez comme suit :

    1. Créez le profil du serveur d'applications de base cible. Exécutez la commande manageprofiles avec les paramètres appropriés pour créer un profil géré. Exemple :
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/manageprofiles -create -profileName 
      AppSrv01 -templatePath /QIBM/ProdData/WebSphere/AppServer/V9/ND/profileTemplates/default 
      -nodeName AppSrv01Node01 -cellName AppSrv01Cell01 -hostName mynode1host.company.com
    2. Exécutez la commande WASPreUpgrade pour enregistrer les informations du serveur d'applications de base géré actuel dans un répertoire de sauvegarde de la migration. Choisissez un nouveau répertoire pour les fichiers de sauvegarde. Exemple :
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/
      WAS70Appserver01backup /QIBM/UserData/WebSphere/AppServer/V7/ND/profiles/AppSrv01
    3. 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.

    4. Exécutez la commande WASPostUpgrade pour restaurer la configuration du profil de serveur d'applications géré enregistré dans le nouveau profil de serveur d'applications de base de la Version 9.0.
      Eviter les incidents Eviter les incidents: Cette commande requiert des paramètres supplémentaires. L'exemple ci-après suppose que la sécurité est activée sur les deux agents d'administration.gotcha
      Exemple :
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade 
      /mybackup/WAS70Appserver01backup -profileName AppSrv01 
      -oldAdminAgentProfilePath /QIBM/UserData/WebSphere/AppServer
      /V7/ND/profiles/AdminAgent01 -oldAdminAgentHostname myhostname 
      -oldAdminAgentSoapPort 8879 -oldAdminAgentUsername myusername 
      -oldAdminAgentPassword mypassword -newAdminAgentProfilePath 
      /QIBM/UserData/WebSphere/AppServer/V9/ND/profiles/AdminAgent01 
      -newAdminAgentHostname myhostname -newAdminAgentSoapPort 8887
      -newAdminAgentUsername myusername1 -newAdminAgentPassword mypassword1
    5. 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 :
      • 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 é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. Démarrez le serveur d'applications géré Version 9.0 migré.
    7. Recherchez d'éventuels messages d'erreur ou d'avertissement dans le fichier SystemOut.log du serveur d'applications géré 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.

Résultats

Vous avez migré un profil d'agent d'administration 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. Vous pouvez arrêter l'agent d'administration Version 7.0 ou ultérieures et vous pouvez affecter les ports Version 7.0 ou ultérieures à l'agent d'administration 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-iseries&topic=tmig_migrate_admin_agent
Nom du fichier : tmig_migrate_admin_agent.html