Considérations sur la migration
Avant de lancer la procédure de migration vers WebSphere Application Server Version 9.0, vous devez prendre en compte certaines considérations.

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.
sptcfgRemarques relatives aux systèmes d'exploitation AIX, HP-UX, IBM® i, Linux, Solaris et Windows
Prenez en compte les informations suivantes avant de faire migrer le serveur d'applications :- Avant d'effectuer la migration, évaluez les éléments obsolètes dans WebSphere
Application Server
Version 9.0.
Pour plus d'informations, voir Fonctions obsolètes, stabilisées, remplacées ou retirées.
- Les fonctionnalités de gestionnaire de haute disponibilité
(HAM) et de groupe central sont incluses dans WebSphere
Application Server
Version 7.0 ou ultérieures.
Pour lire les remarques concernant la topologie et la configuration de groupe central susceptibles d'avoir un impact sur votre migration depuis la Version 7.0 ou ultérieures vers la Version 9.0, consultez Remarques sur la migration de groupe central.
Remarque : Dans la plupart des cas, le nombre de serveurs dans le groupe central ne doit pas dépasser 50. Un message d'avertissement s'affiche lorsque les outils de migration ajoutent un serveur dépassant la limite maximale recommandée. - Les outils de migration de configuration ne convertissent pas les applications ni ne les rendent compatibles avec un nouveau niveau de SDK Java. Avant de migrer vers un nouveau SDK Java, utilisez WebSphere Application Server Migration Toolkit pour évaluer vos applications pour toute modification que vous pourriez avoir à apporter, et testez vos applications après avoir effectué toutes les mises à jour requises. Voir Migration
Toolkit on WASdev.
Pour plus d'informations, voir Migration des API et des spécifications.
- Les outils de migration créent un répertoire de sauvegarde de migration qui contient une copie de la configuration de l'ancienne version qui est la taille du répertoire de configuration et des applications provenant du profil antérieur plus les fichiers de trace. En outre, votre système doit disposer d'un espace pour le profil cible, qui, après la migration sera de la même taille que le profil source.
Le volume d'espace de stockage requis par le système pour le répertoire de sauvegarde dépend de votre environnement ainsi que de l'outil de migration que vous utilisez.
- Emplacement : répertoires de sauvegarde spécifiés comme paramètres des commandes WASPreUpgrade et WASPostUpgrade
- Espace disque : pour estimer l'espace disque nécessaire
lors de l'utilisation de ces commandes, ajoutez les quantités suivantes.
- Taille des éléments suivants pour tous les profils de
votre ancienne configuration :
- Répertoire racine_profil/installableApps
- Répertoire racine_profil/installedApps
- Répertoire racine_profil/config
- Répertoire racine_profil/properties
- Bibliothèques partagées référencées dans les fichiers de configuration libraries.xml
- Fichiers RAR (Resource adapter archive) référencés dans les fichiers de configuration resources.xml
- Si la trace est activée, prévoyez suffisamment d'espace pour les fichiers de trace, ce qui dépend de la taille et de la complexité de votre configuration.
- Taille des éléments suivants pour tous les profils de
votre ancienne configuration :
- Si vous utilisez des référentiels de données isolés, en particulier des référentiels de données non partagés, tels que les journaux de transactions pour les bases de données SIB et Apache Derby, et que vous effectuez une migration depuis une édition précédente, vos bases de données et vos journaux de transactions existants sont enregistrés lorsque la commande WASPreUpgrade est exécutée. Les modifications de base
de données que vous effectuez après l'exécution de la commande WASPreUpgrade ne sont pas reflétées dans
l'environnement migré.
- Si vous possédez des informations vitales stockées dans ces référentiels de données locaux, vous devez par mesure de sécurité arrêter tous les serveurs qui interagissent avec ces référentiels avant de tenter la migration. Ces serveurs doivent rester hors ligne jusqu'à ce que la migration ait été terminée ou annulée.
- Si vous tentez plusieurs fois une migration, en raison d'une annulation inattendue ou pour appliquer des correctifs, réexécutez la commande WASPreUpgrade de sorte que toutes les modifications apportées à vos référentiels de données isolés soient reflétées dans l'environnement migré.
- Avant de migrer une base de données Apache Derby, assurez-vous que tous les serveurs d'applications hébergeant des applications qui utilisent cette base de données sont arrêtés. Sinon, la migration de la base de données Apache Derby échouera.
- Vous devez prendre en compte les règles suivantes relatives à la migration des domaines de sécurité :
- Si vous migrez un gestionnaire de déploiement qui possède un domaine de
sécurité avec une portée de niveau cellule, les outils de migration effectuent
les actions suivantes :
- La migration crée un domaine dans la nouvelle configuration, PassThroughToGlobalSecurity, s'il n'existe pas déjà.
- La migration ajoute un mappage des clusters à la nouvelle configuration pour tous les clusters
qui existaient dans l'ancienne configuration.
- Les mappages à PassThroughToGlobalSecurity des clusters qui n'existaient que dans la configuration du gestionnaire de déploiement Version 9.0 avant la migration ne sont pas modifiés.
- Si des mappages existaient pour les clusters Version 9.0 avant la migration, ces mappages existent toujours après la migration.
- S'il n'existait pas de mappages pour les clusters de la Version 9.0 avant la migration, il n'en existe toujours pas après la migration.
- Si un cluster existe à la fois dans la configuration précédente et dans celle de la Version 9.0 avant la migration, celui de la nouvelle configuration est ajouté au domaine PassThroughToGlobalSecurity et se comporte comme celui de la version précédente.
- Les mappages à PassThroughToGlobalSecurity des clusters qui n'existaient que dans la configuration du gestionnaire de déploiement Version 9.0 avant la migration ne sont pas modifiés.
- La migration ajoute un mappage des bus pour les bus qui existent dans une configuration migrée de la version
6.1.x.
Les mappages de bus sont mis à jour en suivant les mêmes règles que celles relatives au mappage de clusters.
- Les serveurs d'administration (gestionnaire de déploiement) ne sont pas ajoutés au domaine PassThroughToGlobalSecurity.
- Si vous migrez un noeud fédéré qui possède un domaine de
sécurité avec une portée de niveau cellule, les outils de migration effectuent
les actions suivantes :
- La migration crée un domaine dans la nouvelle configuration, PassThroughToGlobalSecurity, s'il n'existe pas déjà.
- La migration ajoute un mappage au niveau serveur au domaine PassThroughToGlobalSecurity
pour tous les serveurs qui ne sont pas en cluster dans l'ancienne configuration du noeud.
- Les serveurs du noeud migré qui appartiennent à un cluster ne reçoivent pas
les entrées du domaine PassThroughToGlobalSecurity car cela a été effectué via
un mappage de clusters au cours de la migration du gestionnaire de déploiement.
Si vous avez supprimé ce mappage, la migration conserve ce comportement.
- Les serveurs d'administration (agents de noeud) ne sont pas ajoutés au domaine PassThroughToGlobalSecurity.
- Les serveurs du noeud migré qui appartiennent à un cluster ne reçoivent pas
les entrées du domaine PassThroughToGlobalSecurity car cela a été effectué via
un mappage de clusters au cours de la migration du gestionnaire de déploiement.
Pour plus d'informations, voir la section relative aux domaines de sécurité dans un environnement multiversion de la rubrique Domaines de sécurité multiples.
- Si vous migrez un gestionnaire de déploiement qui possède un domaine de
sécurité avec une portée de niveau cellule, les outils de migration effectuent
les actions suivantes :
- Le processus de désactivation de l'invite de saisie des données d'identification a changé.
Pour désactiver l'invite de saisie des données d'identification dans Version 9.0, configurez ipc.client.props afin de désactiver l'invite de saisie des données d'identification avant la migration depuis la version 6.1 vers Version 9.0.
- Lors de la migration, il se peut que les valeurs par défaut de certaines métadonnées de votre application soient restaurées ce qui entraîne un fonctionnement de l'application différent du comportement prévu.
Si vous avez installé une application dans votre ancien environnement avec l'option Utiliser les métadonnées des fichiers binaires associée à la valeur true et que pendant cette installation ou une mise à jour ultérieure de l'application, vous avez modifié les métadonnées de l'application (par exemple les références de ressource JNDI ou les entrées de base de données), il se peut que votre modification soit perdue lors de la migration.
Si l'option Utiliser les métadonnées des fichiers binaires est associée à la valeur true, le code d'administration ne met à jour que les métadonnées du fichier EAR binaire. Cette option n'est pas prise en charge dans les cellules mixtes ; par conséquent, elle est automatiquement associée à la valeur false lors du processus de migration. Si tel est le cas, les métadonnées étendues qui figurent dans les répertoires de la configuration prévalent sur les valeurs indiquées dans le fichier EAR binaire. Ainsi, les valeurs provenant de l'installation du fichier EAR d'origine prévalent sur toute mise à jour que vous pouvez appliquer.
Effectuez l'une des opérations suivantes pour résoudre cet incident :- Avant de procéder à la migration, mettez à jour vos applications dans l'ancien environnement et associez Utiliser les métadonnées des fichiers binaires à la valeur false. Vérifiez que les applications fonctionnent correctement avec ce nouveau paramètre, puis procédez à nouveau à la migration.
- Après la migration, mettez à jour vos applications et corrigez les métadonnées si nécessaire pour que les applications fonctionnent correctement.
- Après avoir utilisé les outils de migration pour migrer vers WebSphere
Application Server
Version 9.0, vous pouvez être amené à effectuer certaines actions qui ne sont
pas exécutées automatiquement par ces outils.
- Examinez les paramètres de sécurité Lightweight Third-Party
Authentication (LTPA) que vous avez éventuellement utilisés dans WebSphere
Application Server
Version 7.0 ou ultérieures et vérifiez que la sécurité de la Version 9.0 est définie de manière appropriée.
Pour plus d'informations, voir Authentification LTPA.
- Vérifiez le fichier WASPostUpgrade.log dans le répertoire logs
pour obtenir des détails sur tous les objets JSP que les
outils de migration n'ont pas fait migrer.
Si Version 9.0 ne prend pas en charge un niveau pour lequel des objets JSP ont été configurés, les outils de migration les identifient dans le résultat et les consignent au journal.
- Vérifiez les résultats de la migration automatique des bases de données Apache Derby et faites migrer manuellement
celles que les outils n'ont pas fait migrer automatiquement.
Pour plus d'informations, voir Migration de bases de données Apache Derby.
- Examinez les paramètres de sécurité Lightweight Third-Party
Authentication (LTPA) que vous avez éventuellement utilisés dans WebSphere
Application Server
Version 7.0 ou ultérieures et vérifiez que la sécurité de la Version 9.0 est définie de manière appropriée.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=cmig_pre
Nom du fichier : cmig_pre.html