Clusters et gestion de la charge de travail

Les clusters sont des ensembles de serveurs gérés ensemble et participant à la gestion de la charge de travail. Les clusters permettent aux applications d'entreprise de mettre à l'échelle la quantité de rendement qu'il est possible d'obtenir avec un seul serveur d'applications. Ils permettent également aux applications d'entreprise d'être hautement disponibles car les requêtes sont automatiquement acheminées vers les serveurs en opération en cas d'incident. Les serveurs membres d'un cluster peuvent se trouver sur des machines hôte différentes. A l'inverse, les serveurs qui font partie du même noeud doivent se trouver sur la même machine hôte. Une cellule peut comporter un ou plusieurs clusters, ou aucun.

Les serveurs appartenant à un cluster sont membres de ce cluster et les mêmes composants d'application doivent être déployés sur chacun d'eux. Les applications configurées sur les serveurs mises à part, les membres d'un cluster n'ont pas besoin de partager d'autres données de configuration. Un membre de cluster peut être exécuté sur un système de serveur d'entreprise multi-processeur conséquent alors qu'un autre membre du même cluster peut être exécuté sur un système plus petit. Les paramètres de configuration du serveur pour ces deux membres du cluster sont très différents, sauf en ce qui concerne les composants d'application installés. Cette zone de configuration est identique. Cela permet de répartir le travail client entre tous les membres d'un cluster au lieu de soumettre la totalité de la charge de travail à un seul serveur d'applications.

Lorsque vous créez un cluster, vous faites des copies d'un modèle de serveur d'applications existant. Le plus souvent, ce modèle est un serveur d'applications que vous avez déjà configuré. Vous avez la possibilité de faire de ce serveur un membre du cluster. Cependant, il est conseillé de le conserver à l'état de modèle, car le seul moyen de retirer un membre du cluster est de supprimer le serveur d'applications. Lorsque vous supprimez un cluster, vous éliminez également les serveurs d'applications qui en étaient membres. Il est impossible de conserver un membre de cluster. Conserver le modèle original intact vous permet de le réutiliser si vous devez reconstruire la configuration.

Un cluster est vertical lorsque ses membres sont installés sur le même noeud, ou machine physique. Un cluster est horizontal lorsque ses membres sont installés sur plusieurs noeuds, c'est-à-dire sur de nombreuses machines dans une cellule. Vous pouvez configurez l'un ou l'autre de ces types de cluster ou créer une combinaison de clusters verticaux et horizontaux.

[AIX Solaris HP-UX Linux Windows][IBM i]La mise en clusters de serveurs d'applications hébergeant des conteneurs Web active automatiquement la gestion de la charge de travail des plug-ins pour les serveurs d'applications et les servlets qu'ils hébergent. Le routage des demandes de servlet intervient entre le plug-in de serveur Web et les serveurs d'applications en clusters utilisant les transports HTTP ou les canaux de transport HTTP.

[AIX Solaris HP-UX Linux Windows][IBM i]
La mise en clusters de serveurs d'applications hébergeant des conteneurs Web active automatiquement la gestion de la charge de travail des plug-ins pour les serveurs d'applications et les servlets qu'ils hébergent. Le routage des demandes de servlet intervient entre le plug-in de serveur Web et les serveurs d'applications en clusters utilisant les transports HTTP ou les canaux de transport HTTP.

[AIX Solaris HP-UX Linux Windows][IBM i]Ce routage repose sur les poids associés aux membres du cluster. Si tous les membres de cluster sont de poids identiques, le plug-in envoie des demandes égales à tous les membres du cluster en l'absence de configurations d'affinité forte. Si les poids s'étalent dans un intervalle de 0 à 20, le plug-in achemine généralement les demandes aux membres de cluster dont le poids est le plus élevé.

La console d'administration permet de spécifier le poids d'un membre de cluster. Le poids que vous affectez à un membre de cluster est déterminé en fonction de sa capacité approximative et proportionnelle à exécuter le travail. La valeur de poids spécifiée pour un membre spécifique n'est significative que dans le contexte des poids que vous spécifiez pour les autres membres du cluster. Les valeurs de poids n'indiquent pas une capacité absolue. En cas de non disponibilité d'un membre de cluster, le module d'extension du serveur Web achemine temporairement les requêtes en contournant ce membre.

Par exemple, si un cluster comporte deux membres, l'affectation des poids 1 et 2 signifie que le premier membre reçoit environ 1/3 de la charge de travail et que le second en reçoit environ les 2/3. Toutefois, si vous ajoutez un troisième membre au cluster et que vous lui affectez un poids égal à 1, environ 1/4 de la charge de travail revient alors au premier membre, environ 1/2 au deuxième membre, et environ 1/4 au troisième membre. En cas d'indisponibilité du premier membre du cluster, le deuxième membre reçoit environ 2/3 de la charge de travail et le troisième membre environ 1/3 de la charge de travail.

Les valeurs de poids ne donnent qu'une valeur approximative de vos objectifs d'équilibre de charge. Il existe d'autres dépendances d'application, comme l'accès concurrent d'unités d'exécution, les préférences régionales, l'affinité et la disponibilité des ressources qui sont également des facteurs permettant de déterminer où est envoyée une requête spécifique. Par conséquent, n'utilisez pas le modèle exact de requêtes pour déterminer l'affectation de poids pour des membres de cluster spécifiques.

La gestion de la charge de travail des conteneurs d'EJB peut s'effectuer en configurant le conteneur Web et les conteneurs d'EJB sur des serveurs d'applications distincts. Plusieurs serveurs d'applications peuvent être configurés en cluster avec les conteneurs d'EJB afin de distribuer les demandes de bean enterprise entre les conteneurs d'EJB installés sur des serveurs d'applications différents.

Dans cette configuration, les requêtes client EJB sont routées vers des conteneurs EJB disponibles selon la technique de permutation circulaire basée sur des poids de serveur attribués. Les clients EJB peuvent être des servlets fonctionnant à l'intérieur d'un conteneur Web, des programmes Java autonomes utilisant RMI/IIOP ou d'autres EJB.

Dans cette configuration, les requêtes client EJB sont routées vers des conteneurs EJB disponibles selon la technique de permutation circulaire basée sur des poids de serveur attribués. Les clients EJB peuvent être des servlets fonctionnant à l'intérieur d'un conteneur Web, des programmes Java™ autonomes utilisant RMI/IIOP ou d'autres EJB.

La règle de routage à permutation circulaire pondérée de serveur assure une distribution de routage équilibrée basée sur le jeu de poids serveur ayant été attribués aux membres d'un cluster. Par exemple, si tous les serveurs du cluster sont de même poids, on s'attend à ce que ceux-ci reçoivent le même nombre de requêtes. Si les poids des serveurs sont différents, le mécanisme de distribution envoie plus de requêtes aux serveurs à valeur pondérale élevée qu'aux autres. La règle garantit la distribution de votre choix en fonction des poids qui sont affectés aux membres de cluster.

[z/OS]Vous pouvez configurer la gestion de la charge de travail pour équilibrer les tâches entre les différents clusters.

Vous pouvez choisir que les requêtes soient adressées de préférence au noeud sur lequel réside le client. Dans ce cas, seuls les membres de cluster de ce noeud sont choisis (suivant la méthode de pondération à permutation circulaire). Les membres du cluster situés sur des noeuds distants ne sont choisis que si un serveur local n'est pas disponible.

Le fait que ces serveurs multiples puissent répondre aux mêmes requêtes client constitue également une base pour la prise en charge de la fonction de reprise après incident. Si l'exécution d'un serveur échoue lors du traitement d'une requête client, cette dernière peut être acheminée vers n'importe quel autre membre du cluster. Même si plusieurs serveurs sont arrêtés, les demandes des client peuvent être traitées, à condition qu'au moins un membre du cluster soit actif.

[AIX Solaris HP-UX Linux Windows][IBM i]Le cluster de secours continue de fonctionner même si tous les membres du cluster principal ne sont pas disponibles.


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