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

Stratégie du gestionnaire haute disponibilité appliqué au partitionnement

Les partitions utilisent une stratégie de type Une sur N avec l'option de quorum activée par défaut. Cette configuration signifie qu'elles peuvent être activées uniquement lorsque la majorité des membres du cluster susceptibles de les prendre en charge sont en ligne ou à l'état de quorum. Chaque application J2EE partitionnée qui crée un ensemble de partitions (voir la section suivante) crée un ensemble de groupes pris en charge par le gestionnaire haute disponibilité. Chaque partition est un groupe du gestionnaire haute disponibilité reconnu qui peut être géré séparément des autres groupes. Si vous devez associer des stratégies différentes pour chaque application ou partitions, vous en avez donc la possibilité. En outre, si l'on entre davantage dans les détails, chaque application J2EE partitionnée peut diviser un ensemble de partitions en sous-groupes et les gérer individuellement.

Par exemple, supposons que vous souhaitiez créer une application de courtage. Vous souhaitez disposer d'une application J2EE partitionnée qui prend en charge tous les types de titre mais vous souhaitez traiter les titres S&P 500 différemment en raison de leur volume d'échanges (charge). Au démarrage du serveur d'applications, toutes les partitions sont activées sur le groupe de serveurs disponibles lorsque le quorum est établi. A ce stade, l'administrateur peut définir une nouvelle stratégie et équilibrer les charges plus efficacement en utilisant l'infrastructure des stratégies du gestionnaire haute disponibilité.

Dans cet exemple, l'administrateur souhaite équilibrer les partitions dans l'ensemble du cluster en fonction du volume de transactions prévu. Il peut créer une stratégie qui équilibre les partitions S&P 500 de manière uniforme entre tous les membres du cluster et qui répartit ensuite de la même manière tous les autres titres entre les mêmes membres du cluster. Cette méthode permet de s'assurer que les transactions des titres S&P 500 sont réparties dans l'ensemble du cluster au lieu de répartir de manière aléatoire tous les titres entre les membres du cluster. Si les partitions étaient gérées comme un seul groupe comme c'est le cas ici, certains membres du cluster risqueraient de comporter un nombre anormal de partitions SP&500 chargées de traiter des volumes importants et donc beaucoup plus de transactions que d'autres serveurs. En outre, ces serveurs peuvent posséder un nombre important de titres qui représentent un volume de transactions quotidien faible et qui sont peu utilisés.

D'autres exemples, qui utilisent le support de stratégies du gestionnaire haute disponibilité, permettent de définir les serveurs favoris de partitions spécifiques, prédéfinir les serveurs à utiliser en cas de reprise sur incident ou déterminer si une partition doit être rétablie sur son serveur d'origine lorsque le serveur est de nouveau opérationnel. Beaucoup d'autres options sont disponibles et décrites dans les sections suivantes.




Related concepts
Gestionnaire haute disponibilité

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/cwpfhapartition_pdf.html

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