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 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
- 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.
- Sauvegardez et synchronisez vos noeuds.
- Indiquez les paramètres du déploiement. Cliquez sur . 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 :
- 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: 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
- 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).
- 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) :- 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.
- 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 . 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.