Migration d'un cluster HCL Digital Experience vers IBM WAS 9.0.5

Vous pouvez migrer votre profil HCL Digital Experience vers WebSphere Application Server 9.0.5. Deux options existent pour ce processus de migration : locale ou distante.

Avant de commencer

Assurez-vous de migrer votre collection de recherche avant de migrer votre serveur HCL Digital Experience. Une fois que vous avez migré votre collection de recherche, connectez-vous à la console Deployment Manager WebSphere Integrated Solutions Console et désactivez la synchronisation automatique.

Une fois que vous avez migré votre collection de recherche, connectez-vous à la console Deployment Manager  WebSphere® Integrated Solutions Console et désactivez la synchronisation automatique.

Pourquoi et quand exécuter cette tâche

Pour rédiger ces instructions, les termes suivants sont utilisés :
v85_dmgr_profile_name
Ce terme fait référence au profil DMGR d'origine sur l'installation WebSphere® Application Server 8.5.5 ou version ultérieure.
v90_dmgr_profile_name
Ce terme fait référence au nouveau profil DMGR sur l'installation WebSphere® Application Server 9.0.5 ou version ultérieure.
v85_dmgr_profile_path
Ce terme fait référence au chemin complet d'installation du gestionnaire de déploiement de WebSphere® Application Server 8.5.5.5 ou version ultérieure.
v90_dmgr_profile_path
Ce terme fait référence au chemin complet d'installation du gestionnaire de déploiement de WebSphere® Application Server 9.0.5 ou version ultérieure.
v85_wp_profile_name
Ce terme fait référence au profil HCL Digital Experience d'origine sur le serveur WebSphere Application Server.
v85_wp_profile_path
This term refers to the full path to the v85 profile.
v90_wp_profile_path
Ce terme fait référence au chemin complet vers le profil v90.
v85_was_root_path
Ce terme fait référence au chemin complet d'installation de WebSphere Application Server 8.5.5.5 ou version ultérieure.
v90_was_root_path
Ce terme fait référence au chemin complet d'installation de WebSphere Application Server 9.0.0.2 ou version ultérieure.
Important :
  • La migration de WebSphere® Application Server 9.0.5 est différente de la migration d'HCL Digital Experience standard, car les références dans l'environnement source sont mises à jour pour pointer vers l'environnement WebSphere® Application Server 9.0.5 cible.

Procédure

  1. Installez WebSphere® Application Server 9.0.5 sur le serveur de migration cible DMGR.
    Conseil : Assurez-vous qu'HCL Digital Experience 9.0 et que les fichiers binaires WebSphere de chaque noeud de cluster sont également installés.
    Important : Pour une migration à distance uniquement : utilisez le même chemin de répertoire d'installation WebSphere® Application Server que le serveur source.
  2. Effectuez les étapes suivantes procéder à une migration du gestionnaire de déploiement ::
    1. Sur le serveur de migration cible DMGR, créez un profil DMGR à l'aide de l'option de ligne de commande manageprofiles.
      Important :
      • Utilisez le même nom de cellule et le même nom de nœud que ceux utilisés pour l'installation DMGR WebSphere® Application Server 8.5.5 ou version ultérieure.
      • Si vous exécutez cette commande sur IBM® i, vous devez ajouter le paramètre -serverName WebSphere_Portal.
      • AIX® : ./manageprofiles.sh -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      • Linux™ : ./manageprofiles.sh -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      • Windows™ : manageprofiles.bat -create -profileName v90_dmgr_profile_name -profilePath v90_dmgr_profile_path -templatePath v90_was_root_path/profile Templates/management -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault
      Où les valeurs suivantes sont définies :
      source_node_name
      Le nom du nœud sur l'installation source.
      source_cell_name
      Le nom de cellule sur l'installation source.
      host_name
      Le nom d'hôte de l'environnement.
    2. Ouvrez une invite de commande.
      Remarque : Si vous êtes invité à ouvrir un fichier de propriétés, il s'agit de fichiers ASCII qui doivent être ouverts avec l'outil approprié.
    3. Copiez le fichier PortalServer/filesForDmgr/filesForDmgr.zip depuis le nœud principal HCL Digital Experience vers le serveur DMGR WebSphere® Application Server 9.0 et extrayez-le dans le répertoire v90_was_root_path.
    4. Assurez-vous que le cache OSGi a été effacé de la nouvelle installation WebSphere® Application Server 9.0 en exécutant la commande suivante à partir du répertoire v90_dmgr_profile_name/bin :
      • AIX® : ./osgiCfgInit.sh -all
      • Linux™ : ./osgiCfgInit.sh -all
      • Windows™ : osgiCfgInit -all
    5. Pour une migration à distance uniquement : Sur le serveur DMGR WebSphere® Application Server 9.0, exécutez la commande suivante pour créer le fichier WAS_V90_RemoteMigrSupport.jar.
      • AIX® : cd v90_was_root_path/bin/migration/bin ./createRemoteMigrJar.sh -targetDir remote_zip_dir -includeJava -allPlugins
      • Linux™ : cd v90_was_root_path/bin/migration/bin ./createRemoteMigrJar.sh -targetDir remote_zip_dir -includeJava -allPlugins
      • Windows™ : cd v90_was_root_path\bin\migration\bin createRemoteMigrJar.bat -targetDir remote_zip_dir -includeJava -allPlugins

      Où remote_zip_dir est un répertoire existant utilisé pour contenir le fichier généré. Veillez à indiquer le chemin d'accès complet au répertoire. Copiez le fichier WAS_V90_RemoteMigrSupport.jar du serveur cible DMGR WebSphere® Application Server 9.0 vers le serveur source DMGR WebSphere® Application Server. Extrayez le fichier JAR dans un répertoire de travail. Par exemple, exécutez unzip WAS_V90_RemoteMigrSupport.jar.

      Linux only : Vérifiez que les droits en lecture et d'exécution sont définis sur les fichiers extraits. Par exemple, exécutez chmod -R 755 supp_dir.
    6. Les commandes WASPreUpgrade et WASPostUpgrade utilisées dans la migration d'HCL Digital Experience utilisent trop de mémoire et peuvent entraîner une exception OutOfMemoryException. Pour éviter ce problème, procédez comme suit :
      1. Vérifiez que vous utilisez une taille de segment de mémoire suffisamment grande. En règle générale, l'utilisation d'une taille de segment de mémoire de 2 Go est suffisante. Elle est spécifiée à l'aide de la variable -javaoption -Xmx2048m lors de l'exécution des commandes WASPreUpgrade ou WASPostUpgrade. Augmentez la taille de segment de mémoire en augmentant la variable -Xmx2048m. -Xmx4096m est une valeur possible.
      2. Vérifiez que la taille du profil du gestionnaire de déploiement a été réduite en supprimant les fichiers inutiles. Dans la plupart des cas, le profil du gestionnaire de déploiement (Dmgr01) ne doit pas dépasser 2 Go. Rechercher les fichiers de plus de 10 Mo pour trouver tous les fichiers qui peuvent expliquer la taille volumineuse du profil est une bonne méthode.
        Par exemple:
        • Sous Linux™, la commande suivante vous permet de trouver les fichiers dont la taille est supérieure à 10 Mo : > find . -type f -size +10000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'.
        • Sous Windows™, vous pouvez lancer la recherche suivante dans Windows™ Explorer : *.* size:> 10MB
    7. Affectez au minimum la valeur 20480 à la limite de descripteur de fichier. 
      ulimit -n 20480
    8. Affectez au minimum la valeur 65536 à la limite de pile. 
      ulimit -s 65536
    9. AIX® uniquement : Utilisez les étapes suivantes pour augmenter la longueur maximale de la ligne de commande avec des variables d'environnement :
      1. Exécutez la commande suivante pour interroger les attributs système :
        lsattr -EH -l sys0 | grep ncargs
        La commande renvoie une valeur semblable à celle de l'exemple illustré ci-dessous :
        ncargs  256  ARG/ENV list size in 4K byte blocks  True
      2. Si la valeur ncargs est inférieure à 512, exécutez la commande suivante pour augmenter la valeur :
        chdev -l sys0 -a ncargs=1024
    10. Arrêtez le serveur du gestionnaire de déploiement avant d'exécuter la commande WASPreUpgrade.
    11. Pour une migration locale uniquement : exécutez la commande WASPreUpgrade à partir du répertoire v90_was_root_path/bin. Pour une migration à distance uniquement : exécutez la commande WASPreUpgrade à partir du répertoire working_directory/bin contenant le package de migration à distance copié précédemment. Pour une migration à distance uniquement : ajoutez le paramètre supplémentaire -machineChange true.
      • AIX® : ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
      • Linux™ : ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
      • Windows™ : WASPreUpgrade.bat temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd
      Où les valeurs suivantes sont définies :
      temp_dir
      Répertoire temporaire dans lequel la sauvegarde est stockée.
      Remarque :
      • Pour Windows™, Windows™, le chemin de temp_dir ne peut pas contenir d'espace.

      Par exemple, votre commande sur pourrait ressembler à : ./WASPreUpgrade.sh /opt/HCL/wasMigrateBackup /opt/HCL/WebSphere/AppServer -javaoption -Xmx2048m -oldProfile v85_dmgr_profile_name -username was_admin_user -password was_admin_user_pswrd

    12. Pour une migration à distance uniquement : compressez et copiez la sauvegarde créée par la commande WASPreUpgrade du serveur source DMGR vers le serveur cible DMGR. Pour une migration locale uniquement : utilisez l'image de sauvegarde créée avec WasPreUpgrade sur le serveur local. Depuis le répertoire v90_was_root_path/bin, exécutez la commande WASPostUpgrade pour migrer le profil source sauvegardé vers le nouveau profil :
      Remarque : Si la sécurité est activée sur votre profil, ajoutez les paramètres -username was_userid -password was_userid_password à votre tâche WASPostUpgrade.
      • AIX® : ./WASPostUpgrade.sh temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
      • Linux™ : ./WASPostUpgrade.sh temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
      • Windows™ : WASPostUpgrade.bat temp_dir -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
      Par exemple, votre commande pourrait ressembler à : ./WASPostUpgrade.sh /opt/HCL/wasMigratedBackup -profileName v90_dmgr_profile_name -oldProfile v85_dmgr_profile_name -javaoption -Xmx2048m
      Si WASPreUpgrade réussi, mais que la commande WASPostUpgrade entraîne une erreur, procédez comme suit :
      1. Vérifiez qu'un seul profil se trouve dans le profil de sauvegarde.
      2. Pensez à supprimer la collection de recherche pour réduire la taille des données.
      3. Déplacez les données JCR pendant la migration.
        Remarque : Java™ Content Repository peut stocker des fichiers liés à l'index dans des sous-répertoires du profil WebSphere®, tels que jcr, qui peuvent utiliser beaucoup d'espace. Ces données ne sont pas modifiées par le processus de migration, elles peuvent donc être temporairement retirées de l'ancien profil ou du répertoire de sauvegarde en vue de la migration. Déplacez le répertoire vers le nouveau profil une fois la migration terminée.
      4. Assurez-vous qu'aucun chemin ne contient le caractère :. Ce caractère peut provoquer des problèmes pour les commandes WASPreUpgrade et WASPostUpgrade.
      Important : Après l'exécution de WASPostUpgrade sur le nœud Deployment Manager ou HCL Digital Experience, connectez-vous à la console WebSphere®Integrated Solutions Console et vérifiez que la synchronisation automatique est désactivée.
    13. Ouvrez une invite de commande et accédez au répertoire v90_dmgr_profile_path/bin/.
    14. Exécutez la commande suivante pour lancer le gestionnaire de déploiement : .
      • AIX® : ./startManager.sh
      • Linux™ : ./startManager.sh
      • Windows™ : startManager.bat
  3. Effectuez les étapes suivantes pour chaque nœud HCL Digital Experience dont vous disposez dans votre cluster.
    1. Sur l'installation du serveur de migration cible WebSphere® Application Server 9.0, créez un nouveau profil de base à l'aide de l'option de ligne de commande manageprofiles. Pour une migration à distance uniquement : commencez par supprimer le profil wp_profile existant, qui a été créé lors de l'installation complète d'HCL Digital Experience 9.0 sur le serveur de migration cible.
      • AIX® : ./manageprofiles.sh -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      • Linux™ : ./manageprofiles.sh -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      • Windows™ : manageprofiles.bat -create -defaultPorts -enableAdminSecurity false -profileName v90_wp_profile_name -profilePath v90_wp_profile_path -templatePath v90_was_root_path/profileTemplates/managed -nodeName source_node_name -cellName source_cell_name -hostName host_name -isDefault -omitAction samplesInstallAndConfig default AppDeployAndConfig
      Où les valeurs suivantes sont définies :
      source_node_name
      Le nom du nœud sur l'installation source.
      source_cell_name
      Le nom de cellule sur l'installation source.
      host_name
      Le nom d'hôte de l'environnement.
      Important :
      • Utilisez le même nom de cellule et le même nom de nœud que ceux utilisés pour l'installation d'HCL Digital Experience et de WebSphere® Application Server 8.5.5 ou version ultérieure.
      • Si vous exécutez cette commande sur IBM® i, vous devez ajouter le paramètre -serverName WebSphere_Portal.
    2. Ouvrez une invite de commande.
      Remarque : Si vous êtes invité à ouvrir un fichier de propriétés, il s'agit de fichiers ASCII qui doivent être ouverts avec l'outil approprié.
    3. Pour une migration locale uniquement : exécutez la commande install-wp-migration-files suivante depuis le répertoire v85_wp_profile_path/ConfigEngine pour installer les fichiers propres à HCL Digital Experience dans l'installation de WebSphere® Application Server 9.0.
      Remarque : Vérifiez que le dossier de fichiers qui contient les fichiers binaires source est activé en mode lecture/écriture. Si le dossier est en lecture seule, la commande install-wp-migration-files échoue.
      • AIX® : ./ConfigEngine.sh install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      • Linux™ : ./ConfigEngine.sh install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      • Windows™ : ConfigEngine.bat install-wp-migration-files -DNewWasLocation=v90_was_root_path -DWasPassword=password
      Remarque :
      • Si cette étape échoue, ConfigEngine peut ne pas fonctionner. Pour corriger cette erreur, restaurez le fichier ConfigEngine.migration.bak créé dans le répertoire racine ConfigEngine. Remplacez ConfigEngine.migration.bak par ConfigEngine.sh ou ConfigEngine.bat, selon votre système d'exploitation.
        Remarque : Si ConfigEngine.migration.bak n'a pas été créé, l'échec s'est produit avant la modification du fichier. Par conséquent, ConfigEngine doit fonctionner.
    4. Pour une migration locale uniquement : copiez le fichier jndi.properties depuis le répertoire v85_was_root_path/properties vers le répertoire v90_was_root_path/properties spécifié par la commande DNewWasLocation.
    5. Assurez-vous que le cache OSGi a été effacé de la nouvelle installation WebSphere® Application Server 9.0 en exécutant la commande suivante à partir du répertoire v90_wp_profile_path/bin :
      • AIX® : ./osgiCfgInit.sh -all
      • Linux™ : ./osgiCfgInit.sh -all
      • Windows™ : osgiCfgInit -all
    6. Pour une migration à distance uniquement : Sur le serveur HCL Digital Experience 9.0, exécutez la commande suivante pour créer le fichier PORTAL_V8.5.0.0_WAS_V90_OS.arch_RemoteMigrSupport.jar. Par exemple, le fichier peut être PORTAL_V8.5.0.0_WAS_V90_windows.x86_RemoteMigrSupport.jar.
      • AIX® : cd PortalServer_root/bin ./genRemMigPkg.sh remote_zip_dir
      • Linux™ : cd PortalServer_root/bin ./genRemMigPkg.sh remote_zip_dir
      • Windows™ : cd PortalServer_root\bin genRemMigPkg.bat remote_zip_dir

      Où remote_zip_dir est un répertoire existant utilisé pour contenir le fichier généré. Veillez à indiquer le chemin d'accès complet au répertoire. Copiez le fichierPORTAL_V8.5.0.0_WAS_V90_OS.arch_RemoteMigrSupport.jar depuis le serveur cible HCL Digital Experience 9.0 vers le serveur source HCL Digital Experience 9.0. Extrayez le fichier JAR dans un répertoire de travail. Par exemple, extrayez PORTAL_V8.5.0.0_WAS_V90_linux.amd64_RemoteMigrSupport.jar.

    7. Complete the following steps to prepare the HCL Digital Experience profile for the WASPreUpgrade command.
      1. Désinstallez toutes les applications inutiles.
      2. Supprimez les applications de sauvegarde et désinstallées.
      3. Supprimez les éventuels fichiers de journalisation ou fichiers temporaires qui occupent beaucoup d'espace et dont vous n'avez plus besoin. Si nécessaire, arrêter le serveur HCL Digital Experience. Les emplacements de fichiers temporaires courants sont :
        • v85_wp_profile_path/temp/
        • v85_wp_profile_path/wstemp/
        • v85_wp_profile_path/config/temp/
    8. Les commandes WASPreUpgrade et WASPostUpgrade utilisées dans la migration d'HCL Digital Experience utilisent trop de mémoire et peuvent entraîner une exception OutOfMemoryException. Pour éviter ce problème, procédez comme suit :
      1. Vérifiez que vous utilisez une taille de segment de mémoire suffisamment grande. En règle générale, l'utilisation d'une taille de segment de mémoire de 2 Go est suffisante. Elle est spécifiée à l'aide de la variable -javaoption -Xmx2048m lors de l'exécution des commandes WASPreUpgrade ou WASPostUpgrade. Augmentez la taille de segment de mémoire en augmentant la variable -Xmx2048m. -Xmx4096m est une valeur possible.
      2. Vérifiez que la taille du profil du gestionnaire de déploiement a été réduite en supprimant les fichiers inutiles. Dans la plupart des cas, le profil du gestionnaire de déploiement (Dmgr01) ne doit pas dépasser 2 Go. Rechercher les fichiers de plus de 10 Mo pour trouver tous les fichiers qui peuvent expliquer la taille volumineuse du profil est une bonne méthode.
        Par exemple:
        • Sous Linux, la commande suivante vous permet de trouver les fichiers dont la taille est supérieure à 10 Mo : > find . -type f -size +10000k -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'.
        • Sous Windows, vous pouvez lancer la recherche suivante dans Windows Explorer : *.* size:> 10MB
    9. Affectez au minimum la valeur 20480 à la limite de descripteur de fichier. 
      ulimit -n 20480
    10. Affectez au minimum la valeur 65536 à la limite de pile. 
      ulimit -s 65536
    11. AIX® uniquement : Utilisez les étapes suivantes pour augmenter la longueur maximale de la ligne de commande avec des variables d'environnement :
      1. Exécutez la commande suivante pour interroger les attributs système :
        lsattr -EH -l sys0 | grep ncargs
        La commande renvoie une valeur semblable à celle de l'exemple illustré ci-dessous :
        ncargs  256  ARG/ENV list size in 4K byte blocks  True
      2. Si la valeur ncargs est inférieure à 512, exécutez la commande suivante pour augmenter la valeur :
        chdev -l sys0 -a ncargs=1024
    12. Stop the HCL Digital Experience server before you run the WASPreUpgrade command.
    13. Pour une migration locale uniquement : exécutez la commande WASPreUpgrade à partir du répertoire v90_was_root_path/bin. Pour une migration à distance uniquement : exécutez la commande WASPreUpgrade à partir du répertoire working_directory/bin contenant le package de migration à distance copié précédemment. Pour une migration à distance uniquement : ajoutez le paramètre supplémentaire -machineChange true.
      • AIX® : ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
      • Linux™ : ./WASPreUpgrade.sh temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
      • Windows™ : WASPreUpgrade.bat temp_dir v85_was_root_path -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd
      Où les valeurs suivantes sont définies :
      temp_dir
      Répertoire temporaire dans lequel la sauvegarde est stockée.
      Remarque :
      • Pour Windows™, Windows™, le chemin de temp_dir ne peut pas contenir d'espace.

      Par exemple, votre commande sur pourrait ressembler à : ./WASPreUpgrade.sh /opt/HCL/wasMigrateBackup /opt/HCL/WebSphere/AppServer -javaoption -Xmx2048m -oldProfile v85_wp_profile_name -username was_admin_user -password was_admin_user_pswrd

    14. Pour une migration à distance uniquement : compressez et copiez la sauvegarde créée par la commande WASPreUpgrade du serveur source vers le serveur cible. Extrayez la sauvegarde dans un répertoire temporaire tel que temp_dir.
    15. Pour une migration à distance uniquement : mettre à jour les paramètres du gestionnaire de déploiement

      Si le nom d'hôte ou le port SOAP du gestionnaire de déploiement a changé, mettez à jour le nom d'hôte et le port SOAP du gestionnaire de déploiement source avec le nom d'hôte et le port SOAP du gestionnaire de déploiement cible dans serverindex.xml et wsadmin.properties dans le profil de sauvegarde aux emplacements /tmp/wp_profile_bak/profiles/wp_profile/config/cells/CellName/nodes/dmgr/serverindex.xml et /tmp/wp_profile_bak/profiles/wp_profile/properties/wsadmin.properties.

    16. Pour une migration locale uniquement : exécutez la commande WASPostUpgrade à partir du répertoire v90_was_root_path/bin. Pour une migration à distance uniquement : exécutez la commande WASPostUpgrade à partir du répertoire v90_was_root_path/bin sur le serveur cible distant. La commande WasPostUpgrade migre le profil source sauvegardé vers le nouveau profil.
      Remarque : Si la sécurité est activée sur votre profil, ajoutez les paramètres -username was_userid -password was_userid_password à votre tâche WASPostUpgrade.
      • AIX® : ./WASPostUpgrade.sh temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
      • Linux™ : ./WASPostUpgrade.sh temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
      • Windows™ : WASPostUpgrade.bat temp_dir -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
      Par exemple, votre commande pourrait ressembler à : ./WASPostUpgrade.sh /opt/IBM/wasMigratedBackup -profileName v90_wp_profile_name -oldProfile v85_wp_profile_name -javaoption -Xmx2048m
      Si WASPreUpgrade réussi, mais que la commande WASPostUpgrade entraîne une erreur, procédez comme suit :
      1. Vérifiez qu'un seul profil existe dans le profil de sauvegarde.
      2. Pensez à supprimer la collection de recherche pour réduire la taille des données.
      3. Déplacez les données JCR pendant la migration.
        Remarque : Java™ Content Repository peut stocker des fichiers liés à l'index dans des sous-répertoires du profil WebSphere®, tels que jcr, qui peuvent utiliser beaucoup d'espace. Ces données ne sont pas modifiées par le processus de migration, elles peuvent donc être temporairement retirées de l'ancien profil ou du répertoire de sauvegarde en vue de la migration. Déplacez le répertoire vers le nouveau profil une fois la migration terminée.
      4. Assurez-vous qu'aucun chemin ne contient le caractère :. Ce caractère peut provoquer des problèmes pour les commandes WASPreUpgrade et WASPostUpgrade.
      Important : Après l'exécution de WASPostUpgrade sur le nœud Deployment Manager ou HCL Digital Experience, connectez-vous à la console WebSphere®Integrated Solutions Console et vérifiez que la synchronisation automatique est activée. Accédez à Administration système > Nœuds. Confirmez que le nœud en cours de migration est synchronisé. Si ce n'est pas le cas, effectuez une synchronisation de ce nœud et attendez qu'elle se termine.
    17. Ouvrez une invite de commande et accédez au répertoire v90_wp_profile_path/bin/.
    18. Exécutez la commande suivante pour démarrer l'agent de noeud :
      • AIX® : ./startNode.sh
      • Linux™ : ./startNode.sh
      • Windows™ : startNode.bat
    19. Connectez-vous à WebSphere® Integrated Solutions Console.
    20. Confirmez que le nœud en cours de migration est synchronisé. Si ce n'est pas le cas, effectuez une synchronisation complète de ce nœud et attendez qu'elle se termine.
    21. Si les noms de profil source et cible ne sont pas identiques, exécutez la tâche action-copy-ce-script-native-encoding dans le chemin d'accès ConfigEngine cible :
      Remarque : Le chemin d'accès ConfigEngine cible doit se trouver dans le même chemin d'accès que les chemins PortalServer et AppServer. N'exécutez pas cette commande à partir du chemin ConfigEngine situé dans le profil cible.
      • AIX® : ./ConfigEngine.sh -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
      • Linux™ : ./ConfigEngine.sh -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
      • Windows™ : ConfigEngine.bat -profileName v90_wp_profile_name action-copy-ce-script-native-encoding
    22. Désactivez la syndication et la recherche Portal dans votre environnement source.
    23. Créez une copie de la base de données source d'HCL Digital Experience. Refer to your database documentation for instructions on how to create the backup.
    24. Modifiez le fichier wkplc_dbdomain.properties sur le serveur cible HCL Digital Experience 9.0 afin qu'il pointe vers la copie de la base de données.
    25. Modifiez les fichiers de propriétés suivants afin que les paramètres pointent vers les nouveaux emplacements de répertoire d'HCL Digital Experience 9.0 :
      1. Depuis le répertoire v90_wp_profile_path/ConfigEngine/properties :
        • Vérifiez que le paramètre DbLibrary du fichier wkplc_dbtype.properties pointe vers la classe de pilote JDBC correcte. La valeur est .zip ou .jar. Par exemple: /derby/lib/derby.jar.
        • Verify that the WpsInstallLocation parameter in the wkplc.properties file points to the correct installation location of HCL Digital Experience.
        • Vérifiez que les mots de passe administratifs du fichier wkplc_dbdomain.properties n'ont pas été supprimés par le groupe de correctifs.
        • Vérifiez que les propriétés WasRemoteHostName, WasSoapPort, WpsHostName dans wkplc.properties sont définies sur les valeurs correctes.
      2. Pour une migration locale uniquement : depuis le répertoire /PortalServer, modifiez les paramètres suivants dans le fichier wps.properties :
        • WasRootDir=v90_was_root_path/
        • ProfileDirectory=v90_wp_profile_path
      3. Pour une migration à distance uniquement : depuis le répertoire v90_wp_profile_path/ConfigEngine/properties, modifiez les paramètres suivants dans le fichier wkplc.properties :
        • WasRemoteHostName=host name of the Deployment Manager target server
        • WpsHostName=host name of the HCL Digital Experience target server
    26. Open a command prompt and change to the v90_wp_profile_path/ConfigEngine directory.
    27. Exécutez la commande suivante :
      • AIX® : ./ConfigEngine.sh validate-database -DWasPassword=password -DPortalAdminPwd=password
      • Linux™ : ./ConfigEngine.sh validate-database -DWasPassword=password -DPortalAdminPwd=password
      • Windows™ : ConfigEngine.bat validate-database -DWasPassword=password -DPortalAdminPwd=password
    28. Exécutez la commande suivante pour recréer vos sources de données :
      • AIX® : ./ConfigEngine.sh connect-database -DWasPassword=password -DPortalAdminPwd=password
      • Linux™ : ./ConfigEngine.sh connect-database -DWasPassword=password -DPortalAdminPwd=password
      • Windows™ : ConfigEngine.bat connect-database -DWasPassword=password -DPortalAdminPwd=password
    29. Plusieurs environnements en cluster uniquement : Exécutez la commande suivante sur le deuxième cluster (cluster B) pour lequel vous effectuez la migration. Exécutez la tâche uniquement si les domaines de base de données de chaque cluster utilisent un utilisateur et un mot de passe différents pour la base de données. To learn how to create the custom theme, go to the Roadmaps section and find Roadmap: Clusters multiples.
      • AIX® : ./ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
      • Linux™ : ./ConfigEngine.sh create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
      • Windows™ : ConfigEngine.bat create-alias-multiple-cluster -DauthDomainList=release,jcr,community,customization,feedback,likeminds -DWasPassword=password -DPortalAdminPwd=password
    30. Connectez-vous à Deployment Manager / WebSphere Application Server Integrated Solution Console dans l'environnement nouvellement migré.
    31. Accédez à Environnement > Variables WebSphere.
    32. Inspectez et validez les valeurs WCM_HOST et WCM_PORT pour chaque serveur Portail, afin de voir si elles correspondent à votre environnement nouvellement migré. Mettez à jour les valeurs si elles sont incorrectes.
    33. Exécutez la commande post-was-migration-update suivante :
      • AIX® : ./ConfigEngine.sh post-was-migration-update -DWasPassword=password -DPortalAdminPwd=password -DoldProfileLocation=v85_wp_profile_path
      • Linux™ : ./ConfigEngine.sh post-was-migration-update -DWasPassword=password -DPortalAdminPwd=password -DoldProfileLocation=v85_wp_profile_path
      • Windows™ : ConfigEngine.bat post-was-migration-update -DWasPassword=password -DPortalAdminPwd=password -DoldProfileLocation=v85_wp_profile_path
      Si la tâche post-was-migration-update échoue, recherchez des erreurs dans le fichier v90_wp_profile_path/logs/WebSphere_Portal/SystemOut.log. Recherchez le code d'erreur CWPKI0428I. Si le mesage suivant s'affiche, suivez les instructions fournies dans le fichier journal pour ajouter le certificat de signataire. Une fois le certificat ajouté, redémarrez l'agent de noeud et réexécutez la tâche post-was-migration-update.
  4. Pour une migration à distance uniquement : procédez comme suit pour mettre à jour les ports du gestionnaire de déploiement et sur chaque nœud :

    Vous pouvez laisser vos serveurs source en cours d'exécution et de diffusion des services au sein de votre réseau. Après la migration, le nom du gestionnaire de déploiement reste inchangé par exemple. Pour éviter des conflits avec le nouvel environnement cible du serveur et des services pour lequel vous devez définir des ports uniques. Si vous n'exécutez pas cette tâche, il est possible que les environnements source et cible soient endommagés.

    En règle générale, augmentez de 100 le numéro de port d'origine. Vous devez toujours vérifier que les mêmes ports ne sont pas utilisés dans l'environnement source.

    1. Connectez-vous à WebSphere® Integrated Solutions Console.
    2. Cliquez sur Administration système > Gestionnaire de déploiement > Ports.
    3. Mettez à jour les ports suivants pour le noeud :
      • CELL_DISCOVERY_ADDRESS
      • DCS_UNICAST_ADDRESS
    4. Cliquez sur Administration système > Agents de nœud > node_agent > Ports.
    5. Mettez à jour les ports suivants pour le noeud :
      • DCS_UNICAST_ADDRESS
      • NODE_DISCOVERY_ADDRESS
      • NODE_IPV6_MULTICAST_DISCOVERY_ADDRESS
      • NODE_MULTICAST_DISCOVERY_ADDRESS
    6. Cliquez sur Serveurs > Types de serveurs > Serveurs d'applications WebSphere > application_servers > Ports.
      Remarque : La valeur par défaut de application_servers est WebSphere_Portal, mais vous pouvez disposer de plusieurs serveurs définis. Mettez à jour les ports sur tous les serveurs d'applications répertoriés.
    7. Mettez à jour le port suivant pour le noeud :
      • DCS_UNICAST_ADDRESS
    8. Cliquez sur Administration système > Nœuds pour resynchroniser le noeud principal.
    9. Cochez la case du noeud principal.
    10. Cliquez sur Resynchronisation complète.
      Remarque : Pour la resynchronisation du nœud principal, l'agent de nœud du nœud principal doit être en cours d'exécution.
    11. Attendez 30 minutes avant de passer à l'étape suivante. La synchronisation prend plusieurs minutes. WebSphere® Integrated Solutions Console peut indiquer que la synchronisation est terminée. Cependant, attendez 30 minutes avant de passer à l'étape suivante. Si vous commencez l'étape suivante avant la fin de la synchronisation, les applications peuvent ne pas être déployées correctement sur les nœuds.
    12. Redémarrez le gestionnaire de déploiement et tous les agents de noeud après avoir mis à jour les ports de chaque noeud et terminé la resynchronisation.
    13. Continuez à exécuter le gestionnaire de déploiement et l'agent de noeud du noeud mis à jour. Cependant, arrêtez tous les autres agents de noeud avant de passer à l'étape suivante.
      Important : Si vous mettez à jour le port SOAP du gestionnaire de déploiement cible, alors vous devez mettre à jour la valeur WPS_SOAP_PORT dans le fichier wpscript.sh. Le fichier wpscript.sh se trouve dans le répertoire wp_profile_root/PortalServer/bin/ et PortalServer_root/bin pour chaque nœud.
      Les environnements source et cible peuvent désormais s'exécuter simultanément.
  5. Démarrez le serveur HCL Digital Experience.
    Si la migration de WebSphere® Application Server échoue, consultez les journaux pour résoudre les erreurs de migration. Ensuite, réexécutez la commande install-wp-migration-files.
  6. Connectez-vous à WebSphere® Integrated Solutions Console et activez AutoSync.
  7. Une fois la migration de votre profil dans WebSphere®Application Server 9.0.0.2 terminée, vous pouvez toujours utiliser l'assistant de configuration dans le répertoire v85_AppServer root/profiles/cw_profile. If you want to have the wizard also running on WebSphere® Application Server 9.0.0.2, run the following command from the /ConfigEngine directory.
    • AIX® : ./ConfigEngine.sh create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password
    • Linux™ : ./ConfigEngine.sh create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password
    • Windows™ : ConfigEngine.bat create-config-wizard -DWizardUserid=userID -DWizardPassword=password -DWasPassword=password