Mappage de configuration pendant la migration produit-configuration

Plusieurs applications sont mappées pendant la migration produit-configuration.

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

La migration implique toujours la migration d'un seul profil vers un autre profil sur le même serveur IBM i. Les outils de migration mappent les objets et les attributs existant dans la version de WebSphere Application Server depuis laquelle vous migrez vers les objets et attributs correspondants dans l'environnement de la Version 9.0.

De nombreux scénarios de migration sont possibles. Les outils de migration mappent les objets et les attributs existant dans la version à partir de laquelle vous migrez vers les objets et les attributs correspondants dans Version 9.0 l'environnement.

Port d'amorçage

Les outils de migration déplacent la valeur de l'ancienne version dans Version 9.0 l'environnement.

Si le paramètre -setPorts est réglé sur generateNew ou une valeur de port lors de l'appel à WASPostUpgrade, cependant, la valeur de port est attribuée à chaque serveur d'applications qui est migré vers Version 9.0.

Paramètres de lancement

Les outils de migration convertissent les paramètres de ligne de commande en paramètres JVM (Java™ Virtual Machine) dans la définition des processus serveur. La plupart des paramètres sont mappés directement. Certains paramètres ne migrent pas étant donné que leur rôle dans la configuration de WebSphere Application Server Version 9.0 n'existe pas, a une autre signification ou une portée différente.

Pour obtenir des informations sur la façon de modifier les paramètres de définition des processus, voir Paramètres de définition des processus. Pour toute information sur la procédure de modification des paramètres JVM, voir Paramètres de machine virtuelle Java.

Serveur générique
Dans la Version 7.0 ou ultérieures, un serveur générique possède son propre type appelé GENERIC_SERVER. La migration effectuera cette conversion, mais elle ne peut pas migrer avec précision les ressources externes référencées par le serveur générique. Une fois la migration des paramètres du serveur terminée, il peut s'avérer nécessaire d'effectuer des tâches supplémentaires. Si l'ancienne ressource qui était gérée par le serveur générique est située sous l'ancienne installation de WebSphere Application Server, procédez comme suit :
  1. Copiez tous les fichiers connexes vers la nouvelle installation.
  2. Exécutez toutes les configurations nécessaires pour rétablir l'état opérationnel de l'application externe.

    Il est préférable de réinstaller la ressource dans le nouveau répertoire WebSphere Application Server. Quelle que soit votre décision, l'étape finale consiste à réinitialiser la référence vers le nouvel emplacement de l'application.

Si l'ancienne ressource qui était gérée par le serveur générique n'est pas située sous l'ancienne installation de WebSphere Application Server, aucune autre action n'est requise.

Migration d'un noeud Version 7.0 ou ultérieures vers un noeud Version 9.0

Vous pouvez faire migrer un noeud WebSphere Application Server Version 7.0 ou ultérieures qui appartient à une cellule sans le retirer de la cellule.

Migrez d'abord le gestionnaire de déploiement, avant de migrer les noeuds de base de la cellule.

Important : Utilisez le même nom de cellule lorsque vous migrez WebSphere Application Server, Network Deployment de la Version 7.0 ou ultérieures vers la Version 9.0. Si vous utilisez un nom de cellule différent, les noeuds fédérés ne pourront pas migrer correctement vers la cellule WebSphere Application Server, Network Deployment Version 9.0.

La migration d'un noeud de base WebSphere Application Server rattaché à une cellule vers la Version 9.0 entraîne également la migration de l'agent de noeud vers Version 9.0. Une cellule peut posséder des noeuds Version 9.0 et d'autres noeuds au niveau de la Version 7.0 ou ultérieures.

Fichiers de stratégie
WebSphere Application Server Version 9.0 procède à la migration de tous les fichiers de règles qui sont installés avec la Version 7.0 ou ultérieures en fusionnant les paramètres dans les fichiers de règles Version 9.0 avec les caractéristiques suivantes :
  • Tous les commentaires situés dans les fichiers de règles de la Version 9.0 sont préservés. Tout commentaire éventuellement contenu dans les fichiers de règles de la Version 7.0 ou ultérieures n'est pas inclus dans le fichier Version 9.0.
  • La migration ne fusionne pas les droits ou permissions ; il s'agit d'une migration de type add. Si la permission ou le droit ne figure pas dans le fichier de la Version 9.0, la migration les transpose.
  • La sécurité est un composant essentiel, par conséquent, la migration ajoute les éléments à la fin des fichiers initiaux .policy directement après le commentaire MIGR0372I: Les droits d'accès migrés sont répertoriés ci-après. Cette liste aide les administrateurs à vérifier toute modification effectuée par la migration dans les fichiers de stratégie.
Répertoires de propriétés et de classes

La procédure de migration copie les fichiers des répertoires de la version précédente dans la configuration de WebSphere Application Server Version 9.0.

Fichiers de propriétés

WebSphere Application Server Version 9.0 procède à la migration de tous les fichiers de propriétés qui sont installés avec la Version 7.0 ou ultérieures en fusionnant les paramètres dans les fichiers de propriétés Version 9.0 :

Fichier RAR (Resource adapter archives) référencé par des ressources J2C

Les fichiers RAR référencés par des ressources J2C sont migrés s'ils figurent dans l'ancien répertoire d'installation de WebSphere Application Server. Dans ce cas, ils sont copiés vers l'emplacement correspondant dans le nouveau répertoire d'installation de WebSphere Application Server. Les fichiers RAR de l'adaptateur de ressources relationnelles ne sont pas migrés.

Migration de ressources de niveau cluster :
WebSphere Application Server version 6.0 a introduit le concept de ressources de niveau cluster. Ces dernières sont configurées dans les fichiers resourcexxx.xml dans les répertoires du cluster. Exemple :
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Si vous avez une ressource de niveau cluster, celle-ci doit se trouver au même endroit sur chaque membre (noeud) du cluster. Par conséquent, si l'on reprend l'exemple précédent, le fichier EAR de chaque membre de cluster doit être installé dans ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} est résolu sur chaque membre du cluster pour obtenir l'emplacement exact.

Au cours de la migration d'un gestionnaire de déploiement, les outils migrent les fichiers du cluster sur un gestionnaire de déploiement, y compris les fichiers resourcexxx.xml files.

Durant la procédure de migration d'un noeud fédéré, les outils traitent chaque adaptateur J2C.

Migration de fichiers RAR depuis une version 7.0 vers la Version 9.0 :

La migration depuis la version 7.0 vers la Version 9.0 copie les fichiers tels que les fichiers RAR depuis WAS_INSTALL_ROOT vers WAS_INSTALL_ROOT et depuis USER_INSTALL_ROOT vers USER_INSTALL_ROOT.

Lorsqu'un fichier RAR se trouve dans WAS_INSTALL_ROOT pour la version 7.0. par exemple, les outils de migration ne copient pas automatiquement le fichier de WAS_INSTALL_ROOT vers USER_INSTALL_ROOT. Cela permet de préserver l'intégrité des ressources J2C de niveau cluster.

Toutefois, si vous avez codé en dur le chemin d'un fichier RAR (archivePath="C:/WAS/installedConnectors/x2.rar", par exemple) dans la version 7.0, les outils de migration de la Version 9.0 ne peuvent pas modifier l'attribut archivePath en conséquence car ceci entraverait le fonctionnement de tous les autres membres du cluster n'ayant pas migré.
Exemples

La migration des exemples des versions précédentes n'est pas disponible. Il existe des exemples WebSphere Application Server Version 9.0 équivalents que vous pouvez installer.

Security

La sécurité Java 2 est activée par défaut lorsque vous activez la sécurité dans WebSphere Application Server Version 9.0. La sécurité Java 2 exige que vous octroyiez des droits de sécurité de manière explicite.

Vous pouvez recourir à plusieurs techniques pour définir différents niveaux de sécurité Java 2 dans la Version 9.0. L'une d'entre elles consiste à créer un fichier was.policy dans l'application pour activer tous les droits de sécurité. Les outils de la migration appellent la commande wsadmin pour ajouter le fichier was.policy du répertoire properties de Version 9.0 dans les applications d'entreprise au cours de leur migration.

Lors de la migration vers WebSphere Application Server Version 9.0, votre décision de préserver ou non la compatibilité des scripts débouche sur l'une des deux situations suivantes :
  • Si vous choisissez de préserver la compatibilité des scripts, votre configuration de sécurité est transposée telle qu'elle dans la Version 9.0.

    Valeur par défaut.

  • Si vous choisissez de ne pas préserver la compatibilité des scripts, votre configuration de sécurité est convertie pour celle par défaut de WebSphere Application Server Version 9.0. La configuration de sécurité par défaut de la Version 7.0 ou ultérieures se comporte presque comme celle des versions précédentes, mais avec quelques changements.

    Par exemple, les fichiers tiers de clés et les fichiers dignes de confiance existants sont déplacés hors du répertoire SSLConfig et de nouveaux objets fichier de clés et fichier de clés certifiées sont créés.

Pour toute information sur la migration de vos configurations de sécurité vers Version 9.0, consultez l'article "Migrating, coexisting, and interoperating – Security considerations" dans la documentation.

Stdin, stdout, stderr, répertoires de passivation et de travail

L'emplacement de ces répertoires est généralement le répertoire logs sous le répertoire des profils de WebSphere Application Server. Pour WebSphere Application Server Version 9.0, l'emplacement par défaut des fichiers stdin, stdout et stderr est le répertoire logs situé sous le répertoire de profil WebSphere Application Server, par exemple, le répertoire logs pour le profil par défaut est /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.

Les outils de migration tentent de migrer les répertoires de passivation et de travail. Sinon, des valeurs par défaut appropriées de la Version 9.0 sont utilisées.

Eviter les incidents Eviter les incidents: Dans un scénario où plusieurs versions coexistent, l'utilisation de répertoires communs peut générer des incidents.gotcha
Modules Web

Le niveau de spécification de Java EE (Java Platform, Enterprise Edition) mis en oeuvre dans WebSphere Application Server version 7.0 nécessitait des modifications de comportement dans le conteneur Web pour définir le type de contenu. Si le développeur du servlet par défaut ne définit pas le type de contenu, non seulement le conteneur Web n'utilise pas celui par défaut mais renvoie également la valeur "null" pour l'appel. Cette situation peut entraîner un affichage incorrect par certains navigateurs des balises de conteneur Web générées. Afin d'éviter que ce problème ne se produise, la procédure de migration affecte à l'extension IBM® autoResponseEncoding la valeur "true" pour les modules Web lors de la migration d'applications d'entreprise.


Icône indiquant le type de rubrique Rubrique de concept



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=cmig_configmap
Nom du fichier : cmig_configmap.html