WebSphere Extended Deployment, Version 6.0.x     Systèmes d'exploitation : AIX, HP-UX, Linux, Solaris, Windows, z/OS

Fonctions d'un EJB chargé de traiter la charge de travail par la fonction de partitionnement

[zos platforms] Les partitions gérées par IIOP (Internet Inter-ORB Protocol) ne sont pas prises en charge pour z/OS.

L'administrateur peut adapter ce comportement à l'issue du lancement initial du bean pour répondre aux besoins opérationnels. Par exemple, dans le cas présenté ci-dessus, si la partition 2 et la partition 4 reçoivent des charges de travail très élevées et que les partitions 1 et 3 ne sont pas sollicitées, l'administrateur peut déplacer la partition 2 sur un autre serveur d'applications du cluster. Dans ce cas, l'équipe de programmation code l'implémentation du bean session sans état PSSB1 pour prendre en charge les méthodes partitionUnloadEvent(String) et partitionLoadEvent(String). Lorsque l'administrateur déplace la partition, la partition 2 reçoit un événement de déchargement. Toutes les références à la base de données ou à d'autres ressources de l'application J2EE sont supprimées de l'implémentation de mise en cache. A la suite de cette opération, la partition 2 est réactivée sur l'autre serveur d'applications et reçoit un événement de chargement pour permettre au développeur du bean de réinitialiser l'état et de traiter les transactions.

Cette technologie permet au client de contrôler intégralement le routage tout en permettant à l'administrateur du serveur de contrôler la destination finale de manière indépendante. Bien que les utilisateurs ne puissent pas accéder directement à ce composant, le gestionnaire haute disponibilité fournit à la fonction de partitionnement les mécanismes nécessaires pour détecter la défaillance d'un serveur d'applications. Le gestionnaire haute disponibilité établit immédiatement une corrélation entre les relations existant parmi les partitions du serveur et détermine les actions à exécuter pour s'assurer qu'elles sont activées sur d'autres systèmes.

Le schéma ci-dessous présente la reprise sur incident simple d'une application :

Dans le schéma ci-dessus, le serveur d'applications sur lequel se trouvent la partition 2 et la partition 4 connaît une défaillance. Le gestionnaire haute disponibilité détecte la défaillance et active deux autres instances de la partition 2 et de la partition 4 sur l'autre serveur d'applications. Ce n'est qu'un exemple de reprise pour des serveurs d'applications. Les autres scénarios pris en charge incluent l'arrêt d'un serveur d'applications pour maintenance, l'envoi d'un événement relatif à une partition réseau et d'autres scénarios de gestion ou de prise en charge d'unités physiques. Dans ce cas, la partition 2 et la partition 4 sont arrêtées pendant un bref moment mais les partitions restantes continuent à fonctionner comme si rien ne s'était passé. En outre, la partition 2 et la partition 4 peuvent mettre en oeuvre une procédure d'optimisation lors de la phase de reprise car l'implémentation reçoit l'événement de réactivation des partitions et peut rechercher les problèmes susceptibles d'apparaître lors de la reprise des transactions.

Le traitement du noeud final peut être effectué de différentes manières en fonction de l'architecture informatique utilisée. Si vous décidez d'utiliser une série de serveurs fiables et facilement gérables dans des clusters, davantage de ressources (LPAR) de partitions peuvent être allouées pour un serveur d'applications. Si vous utilisez des clusters répartis ou des infrastructures de type "blade center", vous pouvez déplacer une partition sur un autre système autonome qui n'est pas ou peu sollicité ou déplacer d'autres partitions contiguës et peu ou pas utilisées au sein du cluster. Ce mécanisme permet au serveur d'applications sur lequel se trouve la partition très sollicitée de mieux traiter la charge de travail. Pour une équipe informatique chevronnée, ces deux options offrent une grande souplesse pour répondre aux besoins de leurs infrastructures. L'association des fonctionnalités, des technologies de la structure WPF et du gestionnaire haute disponibilité sous-jacent permet de mettre en place une solution en cluster WebSphere Extended Deployment plus riche avec des fonctions hautes performances et des composants de gestion conçus pour répondre aux défis liés à l'utilisation des clusters.

En résumé, la fonction WPF offre à elle seule un modèle de demande client plus riche car le client peut explicitement indiquer où la demande doit être acheminée. En outre, il est non seulement possible de cibler un noeud final de manière unique mais également de mettre en place un noeud final hautement disponible. Si le serveur d'applications hébergeant le noeud final (partition) connaît une défaillance, le gestionnaire haute disponibilité fourni avec WebSphere Extended Deployment détecte l'incident et active l'instance de la partition sur un autre serveur d'applications du cluster, comme indiqué dans le schéma ci-après. Cette procédure est effectuée sans que les fonctions existantes ne soient désactivées.




Related concepts
Partitionnement de la charge de travail via des EJB
Restrictions z/OS dans WPF

Related information
Modèle de programmation WPF sous z/OS

Rubrique Concept    

Conditions d'utilisation | Commentaires Dernière mise à jour le : Mar 16, 2006 10:01:30 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/WPF51/cwpfejbadmin_pdf.html

© Copyright IBM 2005, 2006. All Rights Reserved.
Ce centre de documentation s'appuie sur la technologie Eclipse. (http://www.eclipse.org)