[AIX Solaris HP-UX Linux Windows][z/OS]

Exécution d'un déploiement sur une édition

Un déploiement sur une édition remplace une édition active par une nouvelle édition. La nouvelle édition peut consister en une simple modification de l'application ou en une modification plus importante. Si la nouvelle édition est compatible avec les versions précédentes, il est possible de la déployer pour remplacer l'édition active en cours sans que cela ait un impact sur les clients existants. Pour déployer une nouvelle édition, vous devez d'abord installer l'édition d'application en tenant compte des nouvelles informations d'édition.

Avant de commencer

Une édition d'application doit être installée et démarrée et vous devez disposer des privilèges de configurateur ou d'administrateur pour effectuer un déploiement.
  • Le déploiement échoue lorsque deux ID utilisateur dans deux consoles d'administration tentent le processus simultanément.
  • Réglez les propriétés du connecteur SOAP pour définir la valeur de délai d'expiration des demandes pour le gestionnaire de déploiement de façon à ce qu'elle soit supérieure à la durée totale requise pour effectuer un déploiement sur votre système, puis redémarrez le gestionnaire de déploiement. L'absence de réglage de la propriété peut entraîner l'échec du processus de déploiement au moment de l'expiration de la valeur requestTimeout. La formule permettant d'estimer la valeur à définir est nombre-de-groupes-à-déployer * (intervalle-de-drainage + délai-expiration-au-repos-interne-environ-5minutes + durées-de-redémarrage-application-ou-serveur-environ-10minutes). Vous pouvez également définir la valeur sur zéro pour désactiver le délai d'expiration.
    • Si vous effectuez le déploiement à l'aide de l'outil wsadmin, ajustez la valeur de délai d'attente de demande en définissant la propriété com.ibm.SOAP.requestTimeout se trouvant danssoap.client.props dans le profil de gestionnaire de déploiement. La valeur par défaut est 180 secondes et doit être augmentée de manière appropriée.
    • Si vous effectuez le déploiement à l'aide de la console d'administration, ajustez la valeur de délai d'attente de demande en cliquant sur Administration système > Gestionnaire de déploiement > Services d'administration > Connecteurs JMX > Connecteur SOAP > Propriétés personnalisées > requestTimeout. La valeur par défaut est 600 secondes et doit être augmentée de manière appropriée.

      Pour plus d'informations, consultez la rubrique relative aux propriétés de connecteur Java™ Management Extensions.

  • Si vous effectuez un déploiement dans la console d'administration, définissez l'expiration de la session pour la console d'administration sur une valeur supérieure à la durée requise pour mettre fin à l'ensemble du processus de déploiement. Multipliez la valeur de délai d'expiration par le nombre de groupes traités lors du déploiement. Pour plus d'informations sur l'expiration de session pour la console d'administration, consultez la rubrique relative à la modification de l'expiration de la session de console.
  • Vous devez définir une stratégie de routage multi-cluster pour chaque nouvelle édition que vous installez avant de pouvoir effectuer un déploiement. Ajoutez des stratégies de routage multi-cluster à vos nouvelles éditions à l'aide des tâches d'administration. Pour plus d'informations sur les stratégies de routage multicluster, consultez les rubriques relatives aux règles pour les tâches d'administration des stratégies de routage ODR.

Pourquoi et quand exécuter cette tâche

Vous pouvez également utiliser le gestionnaire d'édition d'application si vous souhaitez effectuer un déploiement sur les applications par lots. Il s'agit d'applications Java Enterprise Edition 5 (Java EE 5) conformes à l'un des modèles de programmation de traitement par lots.

Procédure

  1. Installez la nouvelle édition. Suivez la procédure décrite dans l'installation d'une édition d'application, mais en indiquant les informations relatives à votre nouvelle édition. Par exemple, entrez 2.0 dans la zone Edition de l'application et Deuxième édition dans la zone Description de l'application. Sélectionnez les mêmes cibles de déploiement que pour l'édition active.
  2. Sauvegardez et synchronisez vos noeuds.
  3. Indiquez les paramètres du déploiement. Cliquez sur Applications > Centre de contrôle d'édition > nom_application. Sélectionnez la nouvelle édition, par exemple 2.0, et cliquez sur Déployer.

    Indiquez les paramètres suivants pour les applications d'entreprise et les autres applications middleware :

    1. Sélectionnez le type de déploiement Isolé ou Groupé.

      Utilisez le déploiement de groupe pour remplacer les éditions sur les membres du cluster cible dans un groupe. Le déploiement de groupe est le choix le plus courant et le mieux adapté lorsque le cluster contient au moins quatre membres. Une autre solution consiste à effectuer un déploiement de groupe dont la taille est spécifiée par scriptage. Pour plus d'informations sur le déploiement de groupe, consultez la rubrique relative aux tâches d'administration de gestion d'édition d'application. Lorsque la nouvelle édition devient disponible au cours du déploiement de groupe, toutes les demandes sont acheminées vers la nouvelle édition.

      Utilisez le déploiement isolé pour remplacer une édition par une autre par moitié de cluster à la fois. Ce type de déploiement dessert toutes les demandes des utilisateurs au moyen d'une édition cohérente de l'application. Cependant, ceci réduit de moitié les capacités d'exécution du cluster. Si votre cluster possède au moins quatre membres, envisagez de le diviser en petits groupes à l'aide d'un déploiement de groupe. Le mode isolé peut également être utilisé pour une cible de déploiement de type cluster unique. Avec une cible de déploiement de type cluster unique, les actions effectuées sur la deuxième partie du cluster sont omises. Si vous arrêtez vos cibles de déploiement avant de démarrer un déploiement isolé, celles-ci démarreront dès l'instant où la nouvelle édition remplacera l'édition active, quelque soit la stratégie de réinitialisation choisie. La présente procédure offre une meilleure disponibilité pour les demandes traitées lors de la période de déploiement.

      Eviter les incidents Eviter les incidents: Avant de procéder à un déploiement isolé, déterminez la capacité de charge du cluster du serveur cible. Un déploiement isolé commence par activer la nouvelle édition sur une moitié du cluster, puis il active l'édition sur l'autre moitié. Tandis que la première moitié du cluster est hors ligne et mise à jour, les demandes d'application sont acheminées vers la seconde moitié de cluster. Vérifiez que la moitié du cluster peut traiter l'ensemble de la charge lors de la période de déploiement.gotcha
    2. Sélectionnez la stratégie de réinitialisation. La stratégie de réinitialisation donne des consignes au gestionnaire d'édition d'application sur le chargement par chaque cible de déploiement de la nouvelle édition sur le serveur en cours d'exécution.

      Pour réinitialiser l'application, adoptez une stratégie de réinitialisation à chaud lors de l'arrêt et du redémarrage de l'application sur tous les serveurs du cluster, au fur et à mesure que la nouvelle édition remplace l'ancienne sur chaque serveur. La réinitialisation à chaud est le choix le plus courant et le plus performant pour les applications, car elle permet de charger la nouvelle édition en recyclant l'application dans le serveur d'applications en cours d'exécution. Le serveur reste actif pendant ce processus. Lors d'une réinitialisation à chaud, les bibliothèques natives ne sont pas déchargées de la mémoire. Cette méthode est généralement fiable pour les applications qui n'utilisent pas de bibliothèques natives. Lorsque la réinitialisation souple est utilisée dans un environnement de production, contrôlez le processus du serveur d'applications afin de vérifier que la mémoire virtuelle est suffisante.

      Une stratégie de réinitialisation rapide recycle l'ensemble du serveur d'applications du cluster, lorsque une édition suivante remplace une édition antérieure sur le serveur, en régénérant à la fois la mémoire de processus et les bibliothèques natives utilisées par l'application. Cette stratégie évite les insuffisances de mémoire virtuelle et permet de charger de nouvelles versions des bibliothèques natives. Sélectionnez la stratégie de réinitialisation rapide lorsque vous déployez une édition qui dépend des nouvelles versions des bibliothèques ou est associée à d'autres dépendances régénérées uniquement par le recyclage complet du serveur d'applications, ou si vous avez des applications lourdes qui consomment une grande quantité de mémoire pour la compilation JIT (just-in-time).

    3. Définissez l'intervalle de drainage en secondes. L'intervalle de drainage laisse le temps aux sessions HTTP d'achever le traitement avant la réinitialisation de l'application ou du serveur. L'intervalle de drainage indique le délai d'attente du gestionnaire d'édition d'applications avant le démarrage d'une stratégie de réinitialisation.

      Ces affinités, de type transaction, activité, portée de compensation et activité non répertoriée par Gestion intelligente augmentent l'intervalle de drainage nécessaire, car le serveur ne s'arrête que lorsque ces unités de travail sont terminées. Les applications dont les activités ne sont pas répertoriées par la fonction Gestion intelligente peuvent utiliser la notification de mise au repos lancée par le bean géré (MBean) AppEditionManager pour déclencher le processus d'arrêt et utiliser l'intervalle de drainage pour l'arrêt du système. Ce processus n'est pas nécessaire pour les sessions persistantes, par exemple, celles qui sont sauvegardées dans la base de données ou répliquées via DRS, mais est important pour les sessions transitoires (en mémoire).

      L'objectif de l'intervalle de drainage est d'autoriser la fin des demandes ayant des affinités et des demandes en cours. Pour empêcher la perte de sessions transitoires, définissez un intervalle de drainage supérieur à l'intervalle spécifiant le délai d'attente pour la session d'application. Lorsque le déploiement commence, à chaque mise à niveau d'un serveur, ce dernier est signalé inéligible pour que toute nouvelle session puisse être lancée. Indiquez la valeur 0 pour attendre la fin des sessions pour toutes les demandes en cours. Pour attendre la fin de l'intervalle de drainage ou des sessions pour toutes les demandes en cours, indiquez une valeur supérieure à 0 pour l'intervalle de drainage.

      Le gestionnaire de mise au repos de l'édition d'application peut ne pas attendre pendant la durée complète de l'intervalle de drainage. Les statistiques de l'infrastructure PMI (Performance Monitoring Infrastructure) permettent au gestionnaire de mise en attente de déterminer si toutes les demandes actives ont été mises au repos sur un serveur. Si toutes les demandes sont mises au repos avant l'intervalle de drainage, le gestionnaire de mise au repos de l'édition d'application n'est pas obligé d'attendre pendant la durée complète de l'intervalle de drainage. Pour forcer une réinitialisation à chaud à attendre pendant la durée complète de l'intervalle de drainage, vous pouvez définir la propriété système appedition.rollout.softreset.fulldrainageinterval sur true dans le gestionnaire de déploiement.

      L'intervalle de drainage permet aux sessions existantes de s'arrêter. Cependant, à la fin de l'intervalle de drainage, il existe une période de temps durant laquelle les demandes en cours peuvent encore arriver. Dans ce cas précis, le routeur On Demand (ODR) fournit une valeur de délai d'exécution de 60 secondes pour terminer l'opération de mise au repos. Si les demandes se terminent dans les 60 secondes ou que les 60 secondes expirent, l'application ou le serveur est arrêté en cas de réinitialisation à froid. Ensuite, si les demandes en cours ne sont toujours pas terminées, WebSphere Application Server Network Deployment fournit une du durée de mise au repos de 60 secondes avant l'arrêt de l'application ou de l'instance de serveur. Pour les stratégies de réinitialisation à froid, WebSphere Application Server Network Deployment fournit une durée de mise au repos de 180 secondes avant l'arrêt de l'instance du serveur. Vous pouvez utiliser la propriété personnalisée com.ibm.ws.webcontainer.ServletDestroyWaitTime pour définir la durée d'attente du conteneur Web avant l'achèvement des demandes. Pour plus d'informations, consultez la rubrique relative aux propriétés personnalisées du conteneur Web.

      Vous pouvez utiliser la propriété personnalisée com.ibm.ejs.sm.server.quiesceTimeout pour définir la durée d'attente de l'instance de serveur pour l'achèvement des demandes avant l'initiation de l'arrêt. Pour plus d'informations sur cette propriété de délai d'attente, consultez la rubrique relative aux propriétés personnalisées de la machine virtuelle Java. Vous devez définir les propriétés personnalisées com.ibm.ws.webcontainer.ServletDestroyWaitTime et com.ibm.ejs.sm.server.quiesceTimeout sur toutes les instances de serveur où sont déployées les éditions d'application.

    Indiquez les paramètres suivants pour les applications SIP (Session Initiation Protocol) :
    1. Choisissez une stratégie de mise au repos. La stratégie de mise au repos indique le mode de suppression des serveurs ou des membres de cluster antérieurs qui hébergent l'édition active. Ce paramètre n'affecte pas la nouvelle édition déployée.
      Mettre au repos les serveurs ou les membres de cluster une fois que toutes les sessions actives et les dialogues sont terminés :
      Supprime le serveur ou le membre de cluster lorsque toutes les sections actives et les dialogues associés sont terminés.
      Mettre au repos les serveurs ou les membres de cluster selon l'intervalle défini :
      Supprime le serveur ou le membre de cluster lorsque le délai indiqué expire. Indiquez une durée en secondes, minutes ou heures.
      Avertissement : Le déploiement n'est pas pris en charge pour les applications SIP qui sont déployées dans un cluster dynamique converti à partir d'un cluster statique.
  4. Lancez le déploiement. Cliquez sur OK. Cette action lance le remplacement sans interruption de l'édition antérieure par la nouvelle édition.

Résultats

Si l'édition n'est pas en mode validation, la nouvelle édition remplace l'édition active une fois le déploiement terminé. Une édition en mode validation est déployée sur la cible de déploiement d'origine et l'environnement cloné est supprimé. Les stratégies de routage sont mises à jour en vue de l'acheminement vers votre nouvelle édition.

Lors du déploiement de l'application, les erreurs qui se produisent dans le premier groupe de cibles ne sont pas gérées de la même manière que les erreurs qui se produisent dans les groupes suivants. Dans les déploiements autonomes, le premier groupe est la première moitié des cibles où est activée la nouvelle édition. Dans les déploiements de groupe, le premier groupe est le premier groupe des cibles où la nouvelle édition est activée. Si une erreur se produit lors du déploiement dans le premier groupe des cibles (par exemple, une application ou un serveur ne démarre pas), le déploiement échoue. L'édition d'application en cours reste active. Si une erreur se produit après le déploiement dans le premier groupe de cibles, le déploiement aboutit. La nouvelle édition d'application est maintenant active. L'ancienne édition d'application devient inactive.

Que faire ensuite

Pour valider les résultats, cliquez sur Applications > Centre de contrôle d'édition > nom_application. La nouvelle édition doit être l'édition active sur la cible de déploiement. La nouvelle édition démarre automatiquement car elle remplace une édition en cours d'exécution.

Lorsque vous effectuez un déploiement sur une édition en mode validation, les noms de liens sont remis à leurs valeurs d'origine. Par exemple, /clusters/cluster1-validation/jdbc/CustomerData est modifié en /clusters/cluster1/jdbc/CustomerData.


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