Cette rubrique a pour objet de présenter les principales caractéristiques comportementales de l'algorithme de déploiement d'application pour vous permettre de mieux comprendre son impact en terme d'exploitation dans l'environnement WebSphere Extended Deployment. L'installation et la distribution d'une édition d'application d'une part et son activation d'autre part sont deux concepts distincts.
Il existe deux modèles de base de remplacement sans interruption. Lorsque vous sélectionnez un déploiement de groupe ou isolé dans la console d'administration, les opérations suivantes sont effectuées :
- Déploiement de groupe. Les opérations suivantes sont exécutées pour chaque noeud qui héberge un serveur d'applications appartenant au cluster sur lequel l'application est déployée :
- Le noeud est placé en mode maintenance.
- Les tâches de l'application sur ce noeud sont mises au repos.
- L'application est arrêtée sur ce noeud.
- La configuration du serveur sur ce noeud est modifiée pour refléter que l'édition de remplacement est active et que l'édition précédente est inactive.
- L'application est redémarrée sur ce noeud.
- Le noeud revient à son état normal.
- Déploiement isolé
- La moitié des noeuds où se trouvent les serveurs d'applications qui appartiennent au cluster du serveur sur lequel l'application est déployée sont placés en mode maintenance. Aucune nouvelle demande n'est envoyée à ces serveurs d'applications. Si le nombre de noeuds est impair, il est arrondi, mais est au moins égal au nombre total de noeuds hébergeant le cluster de serveurs d'applications moins un.
- Les tâches destinées à l'application sur ces noeuds sont mises au repos.
- L'application est arrêtée sur ces noeuds.
- La configuration du serveur sur ces noeuds est modifiée pour refléter que l'édition de remplacement est active et que l'édition précédente est inactive.
- L'application est redémarrée sur ces noeuds.
- L'étape a est exécutée sur les noeuds restants.
- L'étape b est exécutée sur les noeuds restants. Aucun serveur d'applications n'est disponible pour traiter les demandes d'une édition de l'application. Les demandes de cette application sont placées en file d'attente dans le routeur ODR (on demand router) pour assurer qu'elles ne sont pas perdues.
- Le premier ensemble de noeuds revient à son état normal. Les nouvelles demandes de nouvelle édition peuvent alors être traitées et toutes les demandes placées en file d'attente sont envoyées.
- Les étapes c, d et e sont effectuées sur les noeuds restants.
- Les noeuds restants sont placés en mode normal.
La console d'administration offre une sélection prédéfinie d'options de déploiement de groupe et isolé. Vous pouvez obtenir une plus grande souplesse de ces options au moyen d'une interface de scriptage. Les options de scriptage sont les suivantes :
- Stratégie de déploiement : Spécifie la méthode de déploiement, soit des groupes de noeuds mis à niveau en série ou la stratégie isolée de division et remplacement.
- Groupe : Spécifie que les éditions ancienne et nouvelle de l'application à la fois peuvent desservir les demandes pendant la période de déploiement. Vous pouvez spécifier la taille de groupe au moyen d'une sous-option. La taille de groupe indique le nombre de noeuds à traiter à la fois. Valeur par défaut : 1.
- Isolé : Spécifie que seule une édition de l'application peut desservir les demandes pendant la période de déploiement. Cela entraîne la mise au repos et à niveau de la moitié du cluster de serveurs d'applications, puis de l'autre moitié. Les demandes d'application reçues pendant le repos des deux moitiés du cluster sont mises en file d'attente par l'ODR.
- Stratégie de réinitialisation : Spécifie, par exemple, de recycler, d'arrêter et de redémarrer l'application ou l'ensemble du serveur d'application.
- Application : Active la nouvelle édition de chaque serveur d'applications en recyclant l'application. Le serveur d'applications continue de fonctionner.
- Serveur : Active la nouvelle édition de chaque serveur d'applications en recyclant le serveur lui-même. Cela est nécessaire si vous devez régénérer les connecteurs, les bibiothèques natives ou réinitialiser Java virtual machine.
- Intervalle de drainage : Spécifie la durée d'attente pour l'achèvement des demandes non traitées avant que l'application ou le serveur d'applications ne s'arrête. La valeur par défaut est 30 secondes.
Les options suivantes sont prédéfinies pour les opérations de déploiement dans la console d'administration :
- Déploiement de groupe :
- stratégie de déploiement = groupe, taille de groupe = 1
- stratégie de réinitialisation = application
- intervalle de drainage = 30 secondes
- Déploiement isolé :
- stratégie de déploiement = isolé
- stratégie de réinitialisation = application
- intervalle de drainage = 30 secondes