Feuille de route : Migration et coexistence de serveurs d'applications

La migration implique la collecte des informations de configuration d'une version précédente de WebSphere Application Server et leur fusion dans la configuration d'une nouvelle version. La coexistence implique l'exécution simultanée d'une nouvelle édition et d'une édition antérieure de WebSphere Application Server sur la même machine.

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. Pour consulter les ressources destinées à vous aider à planifier et à réaliser la migration, accédez au site Knowledge Collection: Migration planning for WebSphere Application Server.

Succinctement, les outils de migration enregistrent les configurations WebSphere et les applications utilisateur existantes dans un répertoire de sauvegarde, puis traitent le contenu de ce répertoire pour migrer les configurations et les applications de versions WebSphere Application Server antérieures vers la version la plus récente.

Si vous disposez d'une version antérieure de WebSphere Application Server, vous devez déterminer s'il convient de migrer la configuration et les applications de la version antérieure vers la nouvelle version.

La migration ne désinstalle pas la version précédente.
  • Dans le cas de migrations de serveurs d'applications autonomes et de gestionnaires de déploiement pour lesquelles vous n'avez pas choisi de désactiver l'ancien gestionnaire de déploiement lors de la migration, la version précédente continue à être opérationnelle.
  • Dans le cadre de migrations de noeuds fédérés et de gestionnaires de déploiement pour lesquels vous avez choisi de désactiver le gestionnaire de déploiement précédent pendant la procédure, la version précédente est désactivée à l'issue de la migration. Vous pouvez réactiver la version précédente avec le script migrationDisablementReversal.jacl.

Si vous exécutez deux versions différentes du serveur d'applications simultanément, on dit que les deux versions coexistent. Par exemple, si la version 7.0 et la version 8.5 d'un serveur d'applications sont démarrées sur une même machine, les serveurs d'applications coexistent.

Pour assurer la coexistence des deux versions, vous devez utiliser les options -setPorts et -resolvePortConflicts lorsque vous migrez un profil ou résoudre manuellement les conflits entre les ports afin que les deux versions ne tentent pas d'utiliser les mêmes ports. Les ports liés lors du démarrage du premier profil empêche le démarrage du second profil car le port est en cours d'utilisation. Aucune modification de port n'est requise si une seule version du profil est active à un moment donné.

Pour diagnostiquer plus facilement les éventuels problèmes qui surviennent lors de la migration, lisez la section Résolution des incidents de migration.

Pourquoi et quand exécuter cette tâche

Pour plus d'informations sur la migration vers la Version 9.0, consultez la section Migration des configurations de produit. Pour plus d'informations sur la coexistence de versions différentes, lisez la section Exécution de serveurs d'applications coexistants.

Procédure

  1. Mettez à jour les composants prérequis et corequis du produit vers les versions prises en charge.

    Pour déterminer la configuration matérielle et logicielle requise, reportez-vous à la page Web IBM® WebSphere Application Server supported hardware, software, and APIs.

  2. Installez le produit Version 9.0.

    Après avoir installé WebSphere Application Server Version 9.0, vous pouvez être amené à créer une configuration de cellule WebSphere Application Server, Network Deployment complète et vouloir vérifier que celle-ci fonctionne correctement avant de tenter de migrer une cellule ou un noeud. Cette procédure permet de s'assurer que votre système dispose de tous les éléments prérequis et prend en charge le nouveau niveau de WebSphere Application Server.

    Pour plus d'informations, consultez l'article relatif à la présentation de tâche : Installation sur l'IBM i dans la documentation.

  3. Faites migrer votre configuration du produit WebSphere Application Server Version 7.0 ou ultérieures vers Version 9.0.

    Vous pouvez choisir entre la migration automatique de votre configuration à l'aide des outils de migration ou de la migrer manuellement.

    • Utilisez les outils de migration afin de migrer automatiquement votre configuration.

      Pour plus d'informations, voir Utilisation des outils de migration.

      Les deux scénarios suivants de migration de WebSphere Application Server, Network Deployment sont possibles :
      • Migration automatique avec la mise à jour de noeud

        Dans ce scénario, vous utilisez les outils de migration pour migrer le gestionnaire de déploiement, ainsi que tous ses noeuds fédérés.

        Cette approche présente les avantages et les considérations suivants :
        • Avantages
          • Vous copiez automatiquement l'ancienne configuration.

            Cela englobe toutes les définitions de ressource, les définitions d'hôte virtuel, les paramètres de sécurité, les définitions de cluster, etc.

          • Vous recréez exactement la même configuration que celle de la Version 7.0 ou ultérieures dans la Version 9.0, y compris les définitions de noeuds, les définitions de serveurs et les applications déployées par défaut.
          • Vous pouvez activer la prise en charge pour la compatibilité de script.

            Pour plus d'informations, voir WASPostUpgrade command.

        • Remarques
          • Vous devez savoir quelle sera la durée de la migration de la configuration avant de commencer.
          • Vous devez migrer dans une fenêtre de maintenance.
      • Migration automatique avec une utilisation à noeuds mixtes
        Ce scénario implique les activités suivantes :
        • Vous pouvez utiliser les outils de migration pour migrer le gestionnaire de déploiement uniquement.
        • Vous ajoutez des noeuds Version 9.0.
        • Vous déplacez vos applications vers la Version 9.0 après les avoir testées sous Version 9.0.
        • Vous supprimez des noeuds de Version 7.0 ou ultérieures de la cellule lorsqu'ils ne sont plus nécessaires.
        Cette approche présente les avantages et les considérations suivants :
        • Avantages
          • Vous copiez automatiquement l'ancienne configuration.

            Cela englobe toutes les définitions de ressource, les définitions d'hôte virtuel, les paramètres de sécurité, les définitions de cluster, etc.

          • Vous recréez exactement la même configuration que celle de la Version 7.0 ou ultérieures dans la Version 9.0, y compris les définitions de noeuds, les définitions de serveurs et les applications déployées par défaut.
          • Vous pouvez avoir une configuration à noeuds mixtes.
          • Vous pouvez activer la prise en charge pour la compatibilité de script.

            Pour plus d'informations, voir WASPostUpgrade command.

          • Vous pouvez supprimer des applications de façon itérative.
        • Remarques
          • Vous devez savoir quelle sera la durée de la migration de la configuration avant de commencer.
          • Vous devez migrer dans une fenêtre de maintenance.
    • Migrez manuellement votre configuration.
      La migration manuelle de votre configuration implique les activités suivantes :
      • Vous faites table rase et construisez un nouvel environnement pour la Version 9.0.
      • Dans l'idéal, vous devriez utiliser un ensemble de scripts d'administration existants pour configurer tout l'environnement de la Version 9.0.
      • Vous déplacez vos applications vers la Version 9.0 après les avoir testées sous Version 9.0.
      • Vous supprimez une cellule de Version 7.0 ou ultérieures lorsque celle-ci n'est plus nécessaire.
      Tenez compte des points suivants concernant la migration manuelle de votre configuration :
      • Avantages
        • Vous pouvez réutiliser les scripts pour la maintenance, la réplication et la reprise après incident.
        • Vous pouvez facilement propager la topologie si vous le souhaitez.
      • Remarques
        • Un ensemble complet de scripts d'administration est un investissement important.
        • Vous devez résoudre les incompatibilités de script et les modifications avant de migrer.
        • Vous ne pouvez pas avoir une configuration à noeuds mixtes.
  4. Migrez les plug-in de serveur Web, comme décrit dans la rubrique Migration des configurations de serveur Web.
  5. Facultatif : Configurez plusieurs versions de WebSphere Application Server afin qu'elles coexistent.

    Aucun conflit d'exécution ne doit exister entre plusieurs instances et versions de WebSphere Application Server si elles doivent opérer simultanément sur la même machine. Des conflits peuvent apparaître avec vos affectations de port. Pour plus d'informations, voir Paramètres de numéro de port.


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-iseries&topic=tmig_prev
Nom du fichier : tmig_prev.html