Règles d'équilibrage de la charge

L'équilibrage de la charge permet d'améliorer les performances du service évolutif, tant en matière de temps de réponse que de rendement. Il existe deux classes de services de données évolutifs.

• Pur

• Sticky

Un service pur est à même de faire répondre l'une de ses instances aux demandes d'un client. Un service sticky est à même de demander à un client d'envoyer des demandes à la même instance. Ces dernières ne sont pas redirigées vers d'autres instances.

Un service pur utilise une règle d'équilibrage de la charge pondérée. Sous cette règle, les requêtes du client sont réparties de manière uniforme entre les instances de serveur du cluster. Supposons par exemple que chaque nœud d'un cluster à trois nœuds ait un poids de 1. Chaque nœud traitera 1/3 des demandes d'un client pour le compte de ce service. L'administrateur peut à tout moment changer les poids par le biais de l'interface de contrôle scrgadm(1M) ou de l'interface utilisateur graphique de Gestionnaire SunPlex.

Il existe deux types de services sticky : sticky ordinaire et sticky joker. Les services sticky permettent à plusieurs sessions d'application simultanées utilisant plusieurs connexions TCP de partager la mémoire d'état (état de la session d'application).

Les services sticky ordinaires permettent à un client de partager l'état entre plusieurs connexions TCP simultanées. Le client est dit « sticky » envers l'instance du serveur écoutant sur un port unique. Le client a la garantie que toutes ses requêtes vont vers la même instance de serveur, sous réserve que cette instance soit active et accessible et que la règle d'équilibrage de la charge ne soit pas modifiée alors que le service est en ligne.

Par exemple, un navigateur Web du client se connecte à une adresse IP partagée sur le port 80 à l'aide de trois connexions TCP différentes. Toutefois, les connexions échangent, au niveau du service, les informations de session mises en cache.

Une généralisation d'une règle sticky s'étend à plusieurs services évolutifs qui échangent des informations de session à l'arrière-plan et au niveau de la même instance. Le cas échéant, le client est dit « sticky » envers plusieurs instances de serveur sur le même nœud écoutant des ports différents.

Prenons l'exemple d'un client sur un site d'e-commerce, qui remplit son panier d'achat en utilisant le protocole HTTP sur le port 80. Le client bascule ensuite sur le protocole SSL sur le port 443 pour envoyer des données sécurisées afin de payer par carte de crédit les articles contenus dans le panier.

Les services sticky joker utilisent des numéros de port assignés de manière dynamique, mais attendent toujours des demandes du client qu'elles se dirigent vers le même nœud. Le client est dit « sticky joker » sur les ports qui ont la même adresse IP.

Un bon exemple de cette règle est le protocole FTP en mode passif. Par exemple, un client se connecte à un serveur FTP sur le port 21. Le serveur demande ensuite au client de se reconnecter à un serveur de ports d'écoute dans la plage des ports dynamiques. Toutes les demandes relatives à cette adresse IP sont transférées sur le même nœud par le biais duquel le serveur a informé le client des informations de contrôle.

La règle d'équilibrage de charge pondérée est appliquée par défaut pour chacune de ces règles sticky. Ainsi la requête initiale d'un client est dirigée vers l'instance imposée par l'équilibreur de charge. Une fois que le client a établi une affinité pour le nœud sur lequel l'instance s'exécute, les demandes futures sont dirigées sous conditions vers cette instance. Le nœud doit être accessible et la règle d'équilibrage de charge ne doit pas avoir été modifiée.

D'autres informations sur les règles d'équilibrage de charge spécifiques sont indiquées ci-dessous.

• Pondérée. La charge est répartie entre les différents nœuds en fonction de valeurs spécifiées. Cette règle est définie via l'utilisation de la valeur LB_WEIGHTED pour la propriété Load_balancing_weights. Si la charge d'un nœud n'est pas explicitement définie, elle sera par défaut égale à 1.

  La règle pondérée redirige un certain pourcentage du trafic provenant des clients vers un nœud particulier. Soit X=le poids et A=le total des poids de tous les nœuds actifs : un nœud actif peut s'attendre qu'environ X/A de toutes les nouvelles connexions soient dirigées vers lui. Toutefois, le nombre total de connexions doit être suffisamment important. Cette règle ne s'applique pas à des requêtes individuelles.

  Notez qu'elle ne fonctionne pas à tour de rôle. Si on utilisait une règle à tour de rôle (circulaire), chaque demande d'un client irait toujours vers un nœud différent. Par exemple, la première demande irait vers le nœud 1, la seconde, vers le nœud 2, etc.

• Sticky. Avec cette règle, le jeu de ports est connu au moment de la configuration des ressources d'application. Cette règle est définie via l'utilisation de la valeur LB_STICKY pour la propriété de ressource Load_balancing_policy.

• Sticky joker. Cette règle est un sur-ensemble de la règle « sticky » ordinaire. S'il s'agit d'un service évolutif identifié par l'adresse IP, les ports sont assignés par le serveur (et ne sont pas connus à l'avance). Les ports peuvent varier. Cette règle est définie via l'utilisation de la valeur LB_STICKY_WILD pour la propriété de ressource Load_balancing_policy.