WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Mappage de configuration pendant la migration de configuration produit

Différentes configurations sont mappées pendant la migration de configuration produit.

La migration implique toujours de faire migrer un profil particulier vers un autre profil, sur le même système ou sur un autre. Les exemples incluent un gestionnaire de déploiement WebSphere ESB version 6.1 migrant vers un profil de gestionnaires de déploiement version 6.2 et un serveur autonome version 6.1 migrant vers un profil de serveur autonome version 6.2.
Remarque : Seul un profil de serveur autonome peut être migré vers un autre système.

De nombreux scénarios de migration sont possibles. Les outils de migration mappent les objets et les attributs existants de la version à partir de laquelle vous migrez avec les objets et attributs correspondants dans l'environnement de la version plus récente.

Port d'amorçage
Les outils de migration mappent une valeur qui n'est pas une valeur par défaut directement dans l'environnement version 6.2. Lors de la migration depuis la version 6.0.2.x, si le paramètre -portBlock est indiqué pendant l'appel de WBIPostUpgrade, une nouvelle valeur de port est donnée à chaque serveur migré vers la version 6.2.
Paramètres de ligne de commande

Les outils de migration convertissent les paramètres du ligne de commande appropriés en paramètres JVM (Java™ Virtual Machine) dans la définition du processus serveur. La plupart des paramètres sont mappés directement. Certains paramètres ne font pas l'objet d'une migration parce qu'ils n'ont pas de rôle dans la configuration WebSphere ESB version 6.2 ou bien leur rôle a une signification ou une portée différente.

Pour plus d'informations sur la modification des paramètres de définition de processus, consultez la rubrique Paramètres des définitions de processus dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1. Pour plus d'informations sur la modification des paramètres JVM (Java Virtual Machine), consultez la rubrique Paramètres JVM (Java Virtual Machine) dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1.

Taille de pile Java pour la migration des fichiers EAR

Lors de la migration de tous les fichiers EAR WebSphere ESB vers la version 6.2 à l'aide de l'outil wsadmin, l'outil WBIPostUpgrade utilise, pour installer les fichiers EAR, la taille maximale par défaut (64 Mo) du tas Java.

Si un fichier EAR n'est pas installé lors de la migration parce que la taille de pile Java n'est pas assez importante, un message similaire à celui-ci s'affiche :
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Augmentez la taille maximale de pile Java et suivez l'exemple ci-après pour installer l'application.

Exemple d'installation d'une application sur WebSphere ESB version 6.2

Supposons que :
Racine d'installation
C:\WebSphere\DeploymentManager
Signes dièses (###)
Valeur de taille de pile maximum
<nom_fichier_EAR>
Nom du fichier EAR
nom_app
Nom de l'application
nom_cluster
Nom du cluster sur lequel le fichier EAR doit être installé.
La commande est affichée sur plus d'une ligne pour des raisons de clarté.
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:\\WebSphere\\ProcServer
                   <nom_fichier_EAR> 
        {-nodeployejb 
         -appname nom_app 
         -cluster nom_cluster}"
Migration d'un noeud version 6.0.x ou 6.1.x vers un noeud version 6.2

Vous pouvez migrer un noeud WebSphere ESB version 6.0.x ou 6.1.x qui appartient à une cellule vers un noeud WebSphere ESB version 6.2 sans retirer le noeud de la cellule.

Faites migrer le gestionnaire de déploiement en premier, avant de faire migrer les noeuds de base de la cellule.

Utilisez le même nom de cellule lors de la migration de version 6.0.x ou 6.1.x vers version 6.2. Si vous utilisez un nom de cellule différent, les noeuds fédérés ne peuvent pas migrer vers la cellule WebSphere ESB version 6.2.

Faire migrer un noeud WebSphere ESB de base situé à l'intérieur d'une cellule vers version 6.2 fait également migrer l'agent de noeud vers version 6.2.

Une cellule peut avoir des noeuds mixtes, ce qui signifie qu'elle peut contenir des noeuds de la version 6.2 et des noeuds de la version 6.1.x.
Remarque : Les noeuds mixtes ne sont pas pris en charge si vous migrez depuis la version 6.0.2.x.
Fichier de règles
WebSphere ESB version 6.2 migre tous les fichiers de règles installés avec les fichiers de règles version 6.0.x ou 6.1.x ayant les caractéristiques suivantes :
  • Tout commentaire contenu dans le fichier de règles version 6.2 sera préservé. Tout commentaire contenu dans le fichier de règles version 6.0.x ou 6.1.x ne sera pas inclus dans la version 6.2.
  • La migration ne cherchera pas à fusionner les droits d'accès ou les autorisations ; il s'agit uniquement d'une migration de type ajout. Si l'autorisation ou le droit d'accès ne se trouve pas dans le fichier, version 6.2 la migration l'y apportera.
  • La sécurité étant un élément extrêmement important, toute addition effectuée au cours de la migration est placée à la fin du fichier .policy d'origine, immédiatement après le commentaire MIGR0372I: Migrated grant permissions follow. Les administrateurs peuvent ainsi vérifier tout changement apporté au fichier de règles par la migration.
Répertoires Properties et lib/app

La migration copie les fichiers issus des répertoires de version antérieure dans la configuration WebSphere ESB version 6.2.

Fichiers de propriétés

WebSphere fait migrer tous les fichiers de propriétés qui sont installés avec la version 6.0.x ou 6.1.x en fusionnant les paramètres dans les fichiers de propriétés de la version 6.2.

La migration ne superpose pas les fichiers de propriété.

Archives RAR (Resource Adapter Archives) référencées par les ressources J2C

Les fichiers RAR et JAR qui sont utilisés par des ressources de l'architecture J2EE Connector sont migrés comme suit :

Migration de ressources de niveau cluster

Les ressources de niveau cluster sont configurées dans les fichiers resourcexxx.xml sous les répertoires de cluster. Par exemple :
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_racine_installation}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Si vous avez une ressource de niveau cluster, cette ressource doit être au même endroit sur chaque membre du cluster (noeud). Par conséquent, dans l'exemple ci-dessus, pour chaque membre du cluster, le fichier RAR doit être installé à l'emplacement ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar. ${WAS_INSTALL_ROOT} est résolu sur chaque membre du cluster pour obtenir un emplacement exact.

Dans la migration d'un gestionnaire de déploiement, les outils fournis créent les fichiers du cluster sur le gestionnaire de déploiement, y compris les fichiers resourcexxx.xml.

Au cours de la migration d'un noeud géré, les outils traitent chaque adaptateur J2C. Les fichiers tels que les fichiers RAR sont migrés comme suit de la version 6.0.x ou 6.1.x vers la version 6.2 :
  • Migration de la version 6.0.2.x vers la version 6.2 : la migration copie les fichiers tels que les fichiers RAR ou JAR de WAS_INSTALL_ROOT vers WAS_INSTALL_ROOT et de USER_INSTALL_ROOT vers USER_INSTALL_ROOT.
  • Migration de la version 6.1.x vers la version 6.2 : la migration copie les fichiers de configuration comme suit :
    • Si vous installez RAR ou JAR dans le cadre de l'installation de WebSphere ESB, les fichiers de configuration sont migrés vers le profil cible de la migration et mis à jour pour désigner la nouvelle version des fichiers RAR et JAR.
    • Si vous installez des fichiers RAR ou JAR après l'installation de WebSphere ESB, le déroulement est le suivant :
      • Si vous installez les fichiers RAR ou JAR sous l'installation WebSphere ESB précédente, seuls les fichiers de configuration sont migrés et vous devez copier ou bien installer ces fichiers RAR ou JAR sur le profil cible de la migration et vérifier que la configuration est correcte avant de démarrer le serveur.
      • Si vous installez les fichiers RAR ou JAR en dehors de l'installation de WebSphere ESB précédente (ce qui est recommandé), les fichiers de configuration sont migrés et vous n'avez rien d'autre à faire après la migration.

Si vous avez codé en dur un chemin vers un fichier RAR (archivePath="C:/WAS/installedConnectors/x2.rar" par exemple) dans la version 6.0.x ou 6.1.x, les outils de migration de la version 6.2 ne peuvent cependant pas modifier l'attribut archivePath pour en tenir compte sinon tous les autres membres du cluster qui n'ont pas été migrés seraient supprimés.

Exemples

Pendant la migration d'un profil autonome, aucun exemple de WebSphere ESB n'est migré. Des exemples de version 6.2 équivalents sont disponibles pour tous les exemples de version 6.2.

Sécurité
Remarque : Les informations de sécurité suivantes s'appliquent uniquement si vous migrez depuis version 6.0.2.x

La sécurité Java 2 est activée par défaut lorsque vous activez la sécurité dans WebSphere ESB version 6.2. Pour utiliser la sécurité Java 2, vous devez avoir des permissions de sécurité explicites.

Plusieurs techniques permettent de définir les différents niveaux de sécurité Java 2 dans version 6.2. L'une d'elle consiste à créer un fichier was.policy en tant que partie de l'application pour activer toutes les autorisations de sécurité. Les outils de migration appellent la commande wsadmin pour ajouter un fichier was.policy existant au répertoire properties de la version 6.2 aux applications d'entreprise lorsqu'elles sont migrées.

Lors de la migration de WebSphere ESB version 6.0.2.x vers la version 6.2, deux résultats sont possibles selon que vous choisissez d'effectuer ou non la migration en vue de prendre en charge la compatibilité de script.
  • Si vous choisissez de migrer pour supporter la compatibilité de script, votre configuration de sécurité est copiée vers la version 6.2, sans changement.

    C'est la valeur par défaut.

  • Si vous choisissez de ne pas effectuer de migration en vue de prendre en charge la compatibilité de script, la configuration de la sécurité est convertie en configuration par défaut pour WebSphere ESB version 6.2. La configuration de sécurité par défaut de version 6.2 agit presque de la même manière que dans les versions précédentes, mis à part quelques changements.

    Par exemple, les fichiers de clés (keyfiles) et fichiers de clés certifiées (trustfiles) existants sont supprimés du répertoire SSLConfig et de nouveaux objets de fichiers de clés (keystore) et de fichier de clés certifiées (truststore) sont créés.

Pour conserver les mêmes paramètres de sécurité, vous devez faire migrer les paramètres de sécurité de WebSphere Application Server qui définis pour la version 6.0.2.x. Pour plus d'informations sur la migration de vos configurations de sécurité vers la version 6.2, reportez-vous la rubrique Migration, cohabitation et interopération - Remarques de sécurité dans le centre de documentation de WebSphere Application Server Network Deployment, version 6.1.

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

Ces répertoires sont généralement situés dans le répertoire d'installation d'une version précédente. L'emplacement par défaut pour stdin, stdout et stderr correspond au répertoire logs de la racine d'installation WebSphere ESB version 6.2.

Les outils de migration cherchent à migrer les répertoires de travail et de passivation existants. Sinon, les valeurs par défaut appropriées de la version 6.2 sont utilisées.

Pour plus d'informations sur les répertoires de passivation, reportez-vous à la rubrique Paramètres du conteneur EJB. Pour davantage d'informations sur les répertoires de travail, voir Paramètres des définitions de processus.

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

Ports de transfert

Les outils de migration font migrer tous les ports. Les outils journalisent un avertissement de conflit de port si un port est déjà défini dans la configuration. Vous devez résoudre tous les conflits de port avant de pouvoir exécuter les serveurs simultanément.

si le paramètre -portBlock est spécifié dans la commande WBIPostUpgrade, une nouvelle valeur de port est attribuée à chaque serveur d'applications migré.

Pour davantage d'informations sur la commande WBIPostUpgrade, voir Utilitaire de ligne de commande WBIPostUpgrade.

Pour davantage d'informations sur les chaînes de transport et les canaux, voir Chaînes de transport.

Vous devez ajouter manuellement les entrées d'alias d'hôte virtuel pour chaque port. Pour davantage d'informations, voir Configuration d'hôtes virtuels.

Modules Web

Le niveau de spécification de J2EE (Java 2 Platform, Enterprise Edition) mis en oeuvre dans WebSphere ESB version 6.0.x ou 6.1.x a nécessité des changements de comportement dans le conteneur Web pour définir le type de contenu. Si un programme d'écriture de servlet par défaut ne définit pas le type de contenu, non seulement le conteneur Web ne l'utilise plus comme valeur par défaut mais retourne en outre l'appel comme étant "null." Cette situation peut amener certains navigateurs à afficher incorrectement les balises de conteneur Web. Pour contourner ce problème, la migration définit l'extension IBM® autoResponseEncoding comme étant vraie pour que les modules Web, à mesure que les applications d'entreprise sont migrées.


concept Rubrique concept

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cmig_vtv_configmap.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).