Migration d'un gestionnaire de déploiement z/OS

Après avoir généré les travaux JCL nécessaires pour migrer un gestionnaire de déploiement vers WebSphere Application Server for z/OS Version 9.0, vous pouvez effectuer la migration à proprement parler en exécutant ces travaux. 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 BBOMDINS du fichier CNTL utilisé pour la génération des travaux. Suivez ces instructions personnalisées pour procéder à la migration de votre gestionnaire de déploiement 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 poursuivre si vous n'avez pas généré les travaux de migration JCL.
  • Faites toujours migrer le noeud gestionnaire de déploiement en premier.
  • Respectez la configuration requise de votre système en matière de coexistence.
  • Le travail BBOWMG3D mentionné dans les présentes instructions doit être soumis par un ID utilisateur d'administrateur WebSphere.

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

  • Remarque sur le maintien de la haute disponibilité durant la migration de la Version 7.0 ou ultérieures à la Version 9.0 :

    La migration d'un gestionnaire de déploiement de la Version 7.0 ou ultérieures à la Version 9.0 redéploie tous les fichiers binaires d'application lorsque le gestionnaire de déploiement est redémarré. Le gestionnaire de déploiement recycle alors toutes les applications via le sysplex. Cela peut entraîner une indisponibilité dans un sysplex qui est défini pour une haute disponibilité si les paramètres de synchronisation ne sont pas désactivés.

    Pour garantir une haute disponibilité pendant la migration, arrêtez toutes les options de synchronisation des agents de noeud dans le sysplex avant de redémarrer le gestionnaire de déploiement.
    1. Ouvrez la console d'administration.
    2. Allez dans Administration du système > Agents de noeuds.
    3. Pour chaque agent de noeud du sysplex, allez dans nom_serveur_agent_noeud > Service de synchronisation de fichiers et désactivez toutes les synchronisations.
  • Astuce : Avant de faire migrer un gestionnaire de déploiement WebSphere Application Server Version 7.0 ou ultérieures, utilisez la commande backupConfig ou l'utilitaire de sauvegarde de votre choix pour effectuer une sauvegarde de votre configuration existante au cas où vous souhaiteriez la restaurer à son état antérieur après la migration. Pour plus d'informations, voir Commande backupConfig. N'oubliez pas de noter le nom et l'emplacement exacts de la sauvegarde de cette configuration.

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. Créez et montez un nouveau système de fichiers de configuration Version 9.0.

    Avant la migration, 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 BBOMDHFS ou BBOMDZFS 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.

    BBOMDHFS ou BBOMDZFS 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.

    Assurez-vous que vous avez attribué, créé et monté vos fichiers système de configuration, manuellement ou en utilisant BBOMDHFS ou BBOMDZFS avant de poursuivre. Le point de montage doit appartenir à l'ID d'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.

  2. Copiez les procédures JCL générées.

    L'utilitaire de migration BBOMDCP 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 BBOMDCP et vérifiez si le code de retour est 0.

  3. 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 du gestionnaire de déploiement Version 7.0 ou ultérieures est AZDCR, et que vous avez indiqué AZ1DCR 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 AZ1DCR.* STDATA(USER(AZDCRU) 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 différents noms de procédure pour ceux-ci implique donc un nouveau profil STARTED.
  4. Effectuez l'une des actions suivantes :
    1. Soumettez le travail BBOWMG3D.

      La migration d'un gestionnaire de déploiement ne nécessite pas la transition du noeud en mode de redémarrage et reprise sur système homologue (PRR) comme c'est le cas pour les migrations de serveur de noeud d'application autonome et de noeud fédéré. Il y a donc deux travaux en moins à soumettre pour la migration du gestionnaire de déploiement et vous êtes prêt à effectuer la migration physique.

      BBOWMG3D est le travail qui effectue la migration physique du gestionnaire de déploiement 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 BBOWMG3D. 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 et nnnnn, 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. L'emplacement par défaut du répertoire temporaire est /tmp/migrate.

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

        BBOWDPRO crée le répertoire de base et le profil par défaut de WebSphere Application Server.

      2. Soumettez le travail BBOWDPRE.

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

      3. Soumettez le travail BBOWDPOS.

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

  5. Vérifiez vos paramètres de contrôle de trace avant la migration.

    Certains paramètres de configuration doivent être modifiés manuellement en vue de la migration de WebSphere Application Server. Utilisez la console d'administration pour étudier la liste des variables d'environnement en procédant comme suit :

    1. Cliquez sur Environnement > Gestion des variables de WebSphere.
    2. Dans l'onglet Configuration, recherchez la variable ras_trace_outputlocation et prenez note de sa valeur, si elle est définie.

      Si ras_trace_outputlocation a pour valeur TRCFILE, vous devez modifier manuellement la procédure de démarrage du nouveau WebSphere Application Server afin d'inclure une instruction TRCFILE DD.

    Eviter les incidents Eviter les incidents: La modification manuelle de la procédure de démarrage doit être effectuée avant le démarrage du nouveau WebSphere Application Server et des démons associés.gotcha
  6. Fermez les anciens serveurs d'applications et le démon.

    Assurez-vous que tous les noeuds se trouvant dans la partition LPAR du gestionnaire de déploiement de la même cellule sont fermés.

  7. 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 Version 9.0 lors du lancement du gestionnaire de déploiement.

    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 de la Version 7.0 ou ultérieures vers la Version 9.0, le démon doit disposer d'une instruction STEPLIB incluant les fichiers SBBOLD2 et SBBOLPA de la version la plus récente.
    • Si une cellule Version 9.0 contient un serveur Version 9.0 qui communique avec un serveur Version 7.0 ou ultérieures dans une cellule Version 7.0 ou ultérieures située sur le même système que la cellule Version 9.0, vous devez également ajouter les fichiers SBBOLD2 et SBBOLPA version 7.0 à l'instruction STEPLIB du démon Version 9.0.
  8. Démarrez le nouveau gestionnaire de déploiement.

    Utilisez les commandes existantes 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 gestionnaire de déploiement, lorsque vous avez généré vos travaux de migration. Cette commande démarre le gestionnaire de déploiement 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 de BBODMGR :
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR

Que faire ensuite

After you verify a successful migration to Version 9.0 and are successfully running a migrated configuration, you should delete the following items:
  • Everything in the source configuration's file system
  • Everything in the target configuration's temporary_directory_location/nnnnn directory, where temporary_directory_location is the directory specified for the temporary directory location (/tmp/migrate by default) and nnnnn is the numeric value generated for the migration identifier when you created your migration jobs
  • The bbomigrt2.sh file

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_adm
Nom du fichier : tmig_z_adm.html