Service WS-Notification dans un environnement avec cluster

WebSphere Application Server permet de regrouper les serveurs dans un cluster afin de protéger l'application contre l'éventuelle défaillance d'un serveur (haute disponibilité) ou de répartir la charge de travail de l'application sur plusieurs serveurs équivalents (équilibrage de la charge de travail). En outre différentes configurations du bus d'intégration de services sont possibles dans le cluster du serveur d'applications, selon que le cluster permet la haute disponibilité et/ou la gestion de la charge de travail. Vous pouvez, par exemple, choisir le nombre de moteurs de messagerie configurés dans le cluster (de 1 au nombre de serveurs du cluster) et le serveur (éventuel) vers lequel un moteur de messagerie peut basculer en cas d'échec de son serveur principal.

L'un des modèles courants consiste à configurer une règle de groupe central "Une sur N" pour un moteur de messagerie : le cluster comporte un seul moteur de messagerie qui peut basculer sur n'importe quel serveur du cluster en cas d'échec de son serveur hôte. Ainsi, l'état associé au moteur de messagerie (par exemple les notifications d'événements et les abonnements) reste disponible pour les applications en cas de défaillance d'un élément matériel.

Topologie avec équilibrage de charge

Dans cette topologie, l'administrateur a pour objectif de partager les demandes de l'application client entre plusieurs serveurs dans la cellule sans surcharger un serveur particulier. Par conséquent, tous les points de service WS-Notification du service WS-Notification doivent être considérés comme étant identiques ; et en particulier, tous les espaces de noms de sujet doivent être disponibles à tous les points de service WS-Notification du courtier.

WebSphere Application Server-specific WS-Addressing dans le proxy permet d'envoyer les demandes de service ayant une affinité avec un moteur de messagerie (par exemple, flux d'abonnement Resume ou Destroy) au serveur sur lequel se trouve le moteur de messagerie.

L'illustration suivante montre une configuration d'environnement groupé définie pour l'équilibrage de charge. Les demandes de trois applications client différentes sont reçues par un serveur proxy WebSphere Application Server et chaque demande est envoyée à un serveur d'applications différents. Les informations concernant chaque demande sont stockées par chaque moteur de messagerie dans une base de données distincte. Le code d'adressage WS du serveur WebSphere Application Server dans le proxy enregistre le serveur qui a reçu la demande et route chaque demande suivante vers le serveur d'applications approprié.

Figure 1. Exemple de topologie d'équilibrage de charge
Cette illustration décrit la topologie d'équilibrage de charge.

Topologie avec haute disponibilité

Dans cette topologie, l'administrateur crée un cluster de serveurs contenant un seul moteur de messagerie et point de service WS-Notification afin de garantir qu'en cas de panne du serveur contenant le moteur de messagerie, les ressources qu'il gère (abonnements, notifications d'événements) restent disponibles pour les applications éloignées. Le moteur de messagerie est configuré pour prendre le relais des différents serveurs du cluster afin d'assurer un fonctionnement haute disponibilité.

Le point de service WS-Notification est déployé sur chaque serveur du cluster. Les ressources (abonnements, enregistrements de diffuseur de publications et points d'extraction) sont conservées dans le moteur de messagerie. Pour exécuter une demande, le point de service crée donc une connexion au serveur sur lequel le moteur de messagerie est en cours d'exécution.

Le WebSphere Application Server serveur proxy est un type particulier de serveur d'applications, qui constitue le point d'entrée des demandes dans l'entreprise. Pour WS-Notification, un serveur proxy est généralement utilisé comme front-end pour un cluster de serveurs d'applications où il équilibre la charge des demandes initiales (telles que les notifications d'événement) entre les serveurs du cluster. Etant donné que certaines demandes WS-Notification (telles que la création d'un abonnement) créent une affinité avec un moteur de messagerie spécifique, lorsque les demandes suivantes relatives à cette ressource sont reçues par le serveur proxy, elles sont acheminées vers le serveur hébergeant le moteur de messagerie en question (même si ce serveur a changé suite à un incident postérieur à la création de la ressource).

WebSphere Application Server-specific WS-Addressing dans le proxy permet d'envoyer les demandes de service ayant une affinité avec un moteur de messagerie (par exemple, flux d'abonnement Resume ou Destroy) au serveur sur lequel se trouve le moteur de messagerie.

L'illustration suivante montre une configuration d'environnement groupé défini pour la haute disponibilité. La demande des applications client est reçue par un serveur proxy WebSphere Application Server et envoyées à un serveur d'applications dans un cluster. Le code d'adressages WS du serveur WebSphere Application Server dans le proxy enregistre le serveur qui a reçu la demande. Les informations relatives à la demande sont stockées dans une base de données par le moteur de messagerie du cluster. Si le serveur d'applications est défaillant, il est remplacé par un autre serveur du cluster. Le code WS-Addressing du proxy réachemine les demandes suivantes vers le serveur d'applications de substitution.

Figure 2. Exemple de topologie haute disponibilité
Cette illustration décrit la topologie haute disponibilité.

Topologie avec équilibrage de charge et haute disponibilité

Cette topologie est une combinaison de la topologie d'équilibrage de charge et de la topologie à haute disponibilité. Dans cette topologie, le cluster contient plusieurs moteurs de messagerie (dont le nombre est inférieur ou égal au nombre de serveurs). Les demandes initiales reçues par le serveur proxy sont partagées entre les serveurs dans le cluster qui héberge les points de service WS-Notification. Les demandes ultérieures pour une ressource qui est créée par cette requête (c'est-à-dire un abonnement) sont redirigées vers le moteur de messagerie d'affinité, même en cas de panne d'un des différents serveurs du cluster.

Ce modèle peut également inclure le cas où plusieurs moteurs de messagerie se trouvent sur un seul serveur du cluster suite à une reprise en ligne. Dans ce cas, il est important que le point de service se connecte au moteur de messagerie approprié.

L'illustration suivante montre une configuration d'environnement groupé défini pour la haute disponibilité et l'équilibrage de charge. Ce cluster contient trois serveurs d'applications. Deux d'entre eux utilisent le même moteur de messagerie et le troisième utilise un autre moteur de messagerie. Une demande d'une application client est reçue par un serveur proxy WebSphere Application Server et acheminée vers un des serveurs d'applications qui partagent le même moteur de messagerie. Le code d'adressages WS du serveur WebSphere Application Server dans le proxy enregistre le serveur qui a reçu la demande. Lors de l'échec du serveur d'applications, un des deux autres serveurs le remplace. Le code WS-Addressing du proxy achemine les demandes suivantes, portant sur une ressource créée par la demande initiale (un abonnement), vers le serveur d'applications de remplacement qui partage le moteur de messagerie.

Figure 3. Exemple de topologie haute disponibilité et d'équilibrage de charge
Cette illustration décrit une topologie haute disponibilité et une topologie d'équilibrage de charge.

Icône indiquant le type de rubrique Rubrique de concept



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=cjwsn_scen456
Nom du fichier : cjwsn_scen456.html