Migration d'un noeud fédéré z/OS

Après avoir migré et redémarré le gestionnaire de migration, vous pouvez effectuer la migration des noeuds de son serveur d'applications fédéré en exécutant les travaux JCL que vous avez générés. Lorsque vous avez généré les travaux de migration personnalisés, vous avez également créé des instructions personnalisées pour préparer et exécuter les travaux de migration dans les membres BBOMMINS du fichier CNTL utilisé pour la génération des travaux. Suivez ces instructions personnalisées pour procéder à la migration de vos noeuds fédérés vers la Version 9.0.

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
  • Lisez les sections Présentation de la migration, de la coexistence et de l'interopérabilité et Considérations sur la migration.
  • Vous ne pourrez pas continuer si vous n'avez pas créé les travaux de migration JCL.
  • Les travaux BBOWMG1F, BBOWMG2F et BBOWMG3F mentionnés dans les présentes instructions doivent être soumis par un ID utilisateur de l'administrateur WebSphere.

    Tous les autres travaux doivent être soumis par l'ID utilisateur qui contrôle le système de fichiers.

  • Pour migrer un noeud fédéré dans une autre image MVS, assurez-vous que vous exécutez les travaux sur le même système où le noeud est situé.
  • Conseil : Lorsque vous migrez un noeud fédéré WebSphere Application Server Version 7.0 ou ultérieures, vous devez effectuer les actions suivantes si vous désirez pouvoir le restaurer à son état précédent après la migration :
    1. Sauvegardez votre configuration actuelle à l'aide de la commande backupConfig ou de l'utilitaire de sauvegarde de votre choix.
      • Exécutez la commande backupConfig ou l'utilitaire de sauvegarde de votre choix pour réaliser une sauvegarde de votre configuration de gestionnaire de déploiement Version 9.0.
      • Exécutez la commande backupConfig ou l'utilitaire de sauvegarde de votre choix pour réaliser une sauvegarde de votre configuration de noeud fédéré Version 7.0 ou ultérieures.
      Important : N'oubliez pas de noter le nom et l'emplacement exacts de la sauvegarde de cette configuration.

      Pour plus d'informations, voir l'article Commande backupConfig de la documentation.

    2. Migrez le noeud fédéré.

    Le cas échéant, vous pouvez annuler maintenant le noeud fédéré que vous venez de migrer. Pour plus d'informations, voir Restauration de l'ancienne version d'un noeud fédéré.

Pour obtenir de l'aide, voir Résolution des incidents de migration.

Pourquoi et quand exécuter cette tâche

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. Assurez-vous que tous les serveurs d'application et l'agent de noeud sont arrêtés pour le noeud fédéré qui est migré.

    Vous devez arrêter le noeud fédéré avant de poursuivre.

  2. Assurez-vous que le gestionnaire de déploiement récemment migré est en cours d'exécution.

    Pour que le noeud de serveur d'applications migre correctement, le gestionnaire de déploiement doit être en cours d'exécution. Il doit être opérationnel et à l'écoute de son port SOAP.

    Tableau 1. Le gestionnaire de déploiement est en cours d'exécution . Lorsque l'opération est terminée, vérifiez
    Pointage Elément
      Accédez à la console d'administration du gestionnaire de déploiement WebSphere Application Server Version 9.0. Cela permet de vérifier que le gestionnaire de déploiement est en cours de fonctionnement.
    Tableau 2. Le serveur d'applications est en cours d'exécution . Lorsque l'opération est terminée, vérifiez
    Pointage Elément
      Vérifiez que la copie du code de WebSphere Application Server Version 9.0 est en cours. La version est indiquée dans le panneau Bienvenue de la console d'administration.
  3. Créez et montez un nouveau système de fichiers de configuration Version 9.0.

    Avant la migration, la Version 9.0 requiert la présence d'un système de fichiers de configuration en vue de la nouvelle configuration. Vous pouvez exécuter BBOMMHFS ou BBOMMZFS pour créer et monter un nouveau système de fichiers de configuration, ou vous pouvez en monter un manuellement. Quelle que soit la méthode employée, un système de fichiers de configuration doit être créé et monté pour votre configuration Version 9.0 avant que vous ne puissiez poursuivre. Ce système de fichiers de configuration est la cible de la migration, sa source étant votre système de fichiers de configuration Version 7.0 ou ultérieures.

    BBOMMHFS ou BBOMMZFS crée un répertoire de point de montage, alloue le système de fichiers de configuration et le monte à l'emplacement que vous avez spécifié pour le point de montage lorsque vous avez créé vos travaux de migration.

    Avant de continuer, assurez-vous que vous avez attribué, créé et monté vos fichiers de système de configuration manuellement ou en utilisant BBOMMHFS ou BBOMMZFS avant de poursuivre. Le point de montage doit appartenir à l'ID utilisateur de l'administrateur WebSphere et posséder les droits minimum de 755. Les nouvelles structures de système de fichiers de configuration doivent être incluses dans BPXPARM pour qu'elles soient montées au prochain IPL.

  4. Soumettez BBOWMG1F et BBOWMG2F.
    Remarque : Si vous n'utilisez pas de connecteurs XA, la soumission de BBOWMG1B et BBOWMG2F est facultative. Néanmoins, soumettez les deux tâches pour que vos journaux de transaction soient vides.

    BBOWMG1F active tous les serveurs dans le noeud de serveur d'applications fédéré qui est migré pour démarrer le mode de traitement PRR (Peer Restart and Recovery). Le mode de traitement PRR résout les transactions en attente, vide les journaux de transaction et arrête le serveur. BBOWMG2F désactive le mode PRR et replace tous les serveurs en mode de fonctionnement normal.

    Suivez ces étapes pour effacer les journaux de transaction XA :
    1. Arrêtez le serveur d'applications.
    2. Soumettez le travail BBOWMG1F et vérifiez si le code de retour est 0.
    3. Redémarrez le serveur d'applications fédéré et attendez qu'il exécute le traitement PRR et qu'il se termine automatiquement.
      Conseil : Une fois les transactions résolues et le serveur arrêté, un code retour différent de 0 est attendu. Exemple de code de résultat acceptable provenant d'un processus de serveur :
      BBOO0035W TERMINATING THE CURRENT PROCESS, REASON=C9C218D5
    4. Soumettez le travail BBOWMG2F et vérifiez si le code de retour est 0.
  5. Copiez les procédures JCL générées.

    L'utilitaire de migration BBOMMCP copie vers la bibliothèque de procédure spécifiée les procédures JCL générées pour démarrer les serveurs. Votre configuration Version 9.0 doit utiliser des procédures JCL différentes de celles qui étaient utilisées par votre configuration Version 7.0 ou ultérieures. Cet utilitaire mettra à jour la nouvelle configuration Version 9.0, en remplaçant les noms de la configuration d'origine Version 7.0 ou ultérieures par les nouveaux noms JCL.

    Attention : Cet utilitaire copie le JCL généré vers votre bibliothèque de procédures. Si vous avez spécifié les mêmes noms que ceux utilisés dans la configuration Version 7.0 ou ultérieures lorsque vous avez généré vos travaux de migration, l'utilitaire remplacera les procédures existantes. Par conséquent, si vous utilisez les mêmes noms, veillez à sauvegarder les procédures Version 7.0 ou ultérieures existantes avant d'exécuter cet utilitaire pour le cas où vous auriez besoin de procéder à une rétromigration.

    Soumettez BBOMMCP et vérifiez si le code de retour est 0.

  6. Si vous avez indiqué de nouveaux noms de procédure, mettez à jour les profils RACF STARTED du contrôleur et du démon.
    Le profil STARTED utilisé par les régions du contrôleur repose sur le nom de la procédure et JOBNAME. Vous devez vous assurer qu'un profil STARTED s'applique pour que la bonne identité soit affectée à la tâche démarrée. Par exemple, si le nom de procédure JCL du contrôleur de la Version 7.0 ou ultérieures est AZACR, et que vous avez indiqué AZ1ACR pour la Version 9.0, vous devez créer un profil STARTED pour ce nouveau nom de procédure :
                  new controller      same identity used in
                     JCL name         V7.0 or later configuration
                        |                    |
     RDEFINE STARTED AZ1ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    Remarque :
    • N'utilisez pas un ID utilisateur différent pour démarrer. Certains éléments sont également liés à l'ID utilisateur ce qui nécessite des changements en cas de modification de l'ID utilisateur.
    • Si votre profil d'origine STARTED était générique, STARTED AZ*.* ... par exemple, vous n'avez pas besoin de créer un nouveau profil STARTED.
    • Les profils STARTED de région serviteur sont basés sur JOBNAME, pas sur le nom de la procédure. Ainsi, il n'y a pas de problème avec le serviteur lorsque vous utilisez un nom de procédure différent.
    • Les démons et les agents de noeud sont des contrôleurs : l'utilisation de noms de procédure différents pour ces derniers nécessite un nouveau profil STARTED.
  7. Supprimez et redéfinissez le flot de journalisation si nécessaire.
    Exécutez ces étapes uniquement si vous avez configuré auparavant le journal du partenaire XA de transaction ou le journal de compensation dans le serveur Version 7.0 ou ultérieures pour utiliser le flot de journalisation.
    1. Assurez-vous que le noeud est fermé.
    2. Supprimez et redéfinissez le flot de journalisation.

      Vous pouvez utiliser les travaux BBOLOGSD et BBOLOGSA qui ont été créés pendant la personnalisation Version 7.0 ou ultérieures si vous avez initialement configuré le serveur de sorte qu'il utilise le flot de journalisation.

      L'échantillon suivant fournit un exemple de ce type de tâche :
      //RLSP1A  JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
      //         CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
      //STEP1    EXEC PGM=IXCMIAPU
      //STEPLIB  DD   DSN=SYS1.MIGLIB,DISP=SHR
      //SYSPRINT DD SYSOUT=*
      //SYSIN    DD *
      
      DATA TYPE(LOGR) REPORT(YES) /* Default to show output of job */
       DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
       DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
              LOWOFFLOAD(20)
              HIGHOFFLOAD(79)
              STG_DUPLEX(YES)
              DUPLEXMODE(UNCOND)
              STG_DATACLAS(OPERLOG)
              STG_SIZE(5000)
              HLQ(Q10RRS)
              LS_SIZE(5000)
              LS_DATACLAS(OPERLOG)
              STRUCTNAME(WAS_LOGRLS)
      /*

    Si vous migrez des noeuds dans un sysplex, suivez cette procédure pour chaque noeud fédéré que vous migrez.

  8. Effectuez l'une des actions suivantes :
    1. Soumettez le travail BBOWMG3F.
      Avertissement : Dans un environnement z/OS, configuré avec plusieurs piles TCP/IP, vous devrez peut-être ajouter la variable d'environnement _BPXK_SETIBMOPT_TRANSPORT pour diriger le travail de migration vers la pile TCP/IP appropriée. Si vous utilisez la mauvaise pile, le résultat produit une exception java.net.UnknownHostException qui entraîne l'échec de la connexion wsadmin.
      Une instruction export _BPXK_SETIBMOPT_TRANSPORT=<stack.name> est requise dans le JCL afin d'identifier la pile appropriée. Voici un exemple de code JCL :
      //***************************************************************         
      //*                                                                       
      //* UPGRADE: Perform the migration to the new Profile                     
      //*                                                                       
      //***************************************************************         
      //*                                                                       
      //*                                                                       
      //UPGRADE EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE)                         
      //SYSTSPRT DD SYSOUT=*                                                    
      //STDENV DD * // _CEE_RUNOPTS=TRAP(ON,NOSPIE) //*                         
      //SYSTSIN  DD *                                                           
        BPXBATCH SH +                                                           
        export _BPXK_SETIBMOPT_TRANSPORT=TCP; +                                 
        /tmp/migrate/bbomigrt2.sh WASPostUpgrade +                              
            /tmp/migrate/28133744/_      +                                      
        1>> /tmp/migrate/28133744/BBOWMG3F.out +                                
        2>> /tmp/migrate/28133744/BBOWMG3F.err;                                 
      /*                         

      BBOWMG3F est le travail qui effectue la migration physique du noeud version Version 7.0 ou ultérieures vers la Version 9.0 en fonction des informations que vous avez fournies lorsque vous avez généré vos travaux de migration. Soumettez BBOWMG3F, vérifiez que les codes retour sont 0 et consultez les fichiers journaux dans le répertoire temporaire de migration du système de fichiers de configuration. Le répertoire temporaire de migration est emplacement_répertoire_temporaire/nnnnn, où emplacement_répertoire_temporaire est la valeur spécifiée pour l'emplacement du répertoire temporaire (/tmp/migrate par défaut) et nnnnn est la valeur numérique qui a été générée pour l'identificateur de migration lorsque vous avez généré vos travaux de migration.

    2. Soumettez les trois travaux suivants :
      1. Soumettez le travail BBOWMPRO.

        BBOWMPRO crée le profil de base et le profil par défaut de Websphere Application Server.

      2. Soumettez le travail BBOWMPRE.

        BBOWMPRE exécute le processus préalable à la migration.

      3. Soumettez le travail BBOWMPOS.

        BBOWMPOS exécute les processus postérieurs à la migration et les processus de finalisation (droits de modification des fichiers).

  9. Vérifiez que l'ancien démon est arrêté.

    Assurez-vous que tous les noeuds fédérés se trouvant dans la même cellule de cette partition logique sont arrêtés.

  10. Si nécessaire, mettez à jour la procédure JCL du démon.

    WebSphere Application Server for z/OS Version 9.0 requiert que le processus du démon soit au niveau de code le plus élevé de tous les serveurs dont il assure la gestion dans la même partition LPAR. Il sera au niveau de la Version 9.0 lors du lancement de ce noeud fédéré.

    Après avoir migré tous les noeuds vers la Version 9.0 et avant de supprimer les bibliothèques des versions précédentes de votre système, vous devez mettre à jour la procédure JCL du démon. Si ces consignes ne sont pas respectées, vous ne pourrez pas lancer le démon.

    Remarque :
    • Si vous migrez la version 6.1 vers la Version 9.0, le démon doit disposer d'une instruction STEPLIB incluant les fichiers SBBOLD2 et SBBOLPA de la version 6.1.
    • Si une cellule Version 9.0 contient un serveur Version 9.0 qui communique avec un serveur version 6.1 in a Version 6.1 dans une cellule située sur le même système que la cellule Version 9.0, vous devez également ajouter les fichiers SBBOLD2 et SBBOLPA version 6.1 à l'instruction STEPLIB du démon Version 9.0.
  11. Démarrez le nouveau noeud de serveur d'applications fédéré.
    1. Démarrez l'agent de noeud.
      Le message suivant s'affiche dans la console et dans le journal des travaux de BBON001 :
      BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBON001
    2. Démarrez le serveur d'applications fédéré.

      Utilisez la commande existante que vous utiliseriez pour démarrer un serveur d'applications Version 7.0 ou ultérieures, mais remplacez le nom de procédure RACF STARTED par la valeur que vous avez entrée pour le nom de procédure du contrôleur dans le panneau du noeud fédéré, lorsque vous avez généré vos travaux de migration. Cette commande démarre le serveur d'applications fédéré Version 9.0. Attendez que le serveur ait fini de s'initialiser avant de lancer le traitement.

      Le message suivant s'affiche dans la console et dans le journal des travaux BBOS001 :
      BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  12. Vérifiez que votre configuration et les applications ont été migrées correctement.

    Pour les applications Compute Grid ou Feature Pack for Modern Batch, vérifiez également que le planificateur de tâches a été migré correctement et que vous pouvez envoyer des travaux aux serveurs 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 qui hébergent vos applications par lots fonctionnent correctement :
    1. Vérifiez que les applications de traitement par lots sur le serveur migré sont démarrées. Examinez les journaux du serveur 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.

Que faire ensuite

Après avoir vérifié que la migration vers la Version 9.0 s'est bien déroulée et que la configuration migrée fonctionne correctement, vous devez supprimer les éléments suivants :
  • Tout le contenu du système de fichiers de la configuration source
  • Tout dans le répertoire emplacement_répertoire_temporaire/nnnnn de la configuration cible, où emplacement_répertoire_temporaire est la valeur spécifiée pour l'emplacement du répertoire temporaire (/tmp/migrate par défaut) et nnnnn est la valeur numérique qui a été spécifiée pour l'identificateur de migration lorsque vous avez créé vos travaux de migration.
  • Le fichier bbomigrt2.sh.

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