Suite de cluster de Red Hat: Configuration et gestion d'un cluster | ||
---|---|---|
Précédent | Chapitre 9. Aperçu du Serveur Virtuel Linux (LVS) | Suivant |
L'un des avantages d'un cluster LVS est sa capacité à effectuer des opérations de répartition de charge au niveau de l'adresse IP sur le parc de serveurs réels, et ce de façon flexible. Cette flexibilité est due aux différents algorithmes d'ordonnancement parmi lesquels un administrateur peut choisir lors de la configuration du cluster. La répartition de charge avec LVS est supérieure à celle utilisant des méthodes moins flexibles, comme par exemple DNS Round-Robin dans laquelle la nature hiérarchique du serveur de noms de domaines (DNS) et la mise en cache par les machines clientes peuvent entraîner des déséquilibres de charge. En outre, le faible niveau de filtrage employé par les routeurs LVS a un certain nombre d'avantages par rapport à la transmission de requêtes basée sur le niveau d'application ; en effet, la répartition de charge au niveau des paquets réseau entraîne un minimum de frais informatiques et permet une plus grande modulabilité.
Grâce à l'ordonnancement, le routeur actif peut, lors du routage des requêtes de services, prendre en compte l'activité du serveur réel et, de façon optionnelle, un facteur poids assigné par l'administrateur. L'utilisation de poids assignés donne des priorités arbitraires aux machines individuelles. Il est par conséquent possible de créer un groupe de serveurs réels utilisant une variété de combinaisons matérielles et logicielles permettant au routeur actif de charger chaque serveur réel de façon égale.
Le mécanisme d'ordonnancement pour un cluster LVS est fourni par un ensemble de correctifs (patches) du noyau appelés modules Serveur Virtuel IP ou IPVS (de l'anglais IP Virtual Server). Ces modules permettent des fonctionnalités de commutation de couche transport layer 4 (L4), un processus conçu pour bien fonctionner avec des serveurs multiples sur une seule adresse IP.
Pour pister et router efficacement les paquets vers les serveurs réels, IPVS établit une table IPVS dans le noyau. Cette table est utilisée par le routeur LVS actif pour re-diriger les requêtes provenant de l'adresse d'un serveur virtuel vers les serveurs réels du parc et pour renvoyer la réponse au demandeur initial. La table IPVS est constamment mise à jour par un utilitaire nommé ipvsadm — qui ajoute et supprime des membres du cluster selon leur disponibilité.
La structure de la table IPVS dépend de l'algorithme d'ordonnancement choisi par l'administrateur pour chaque serveur virtuel. Pour disposer d'un maximum de flexibilité aussi bien au niveau des types de services pouvant être clusterisés qu'au niveau de l'ordonnancement de ces derniers, Red Hat Enterprise Linux fournit les algorithmes d'ordonnancement énumérés ci-dessous. Pour obtenir des informations sur la manière d'assigner des algorithmes d'ordonnancement, consultez la Section 12.6.1.
L'ordonnancement Round-Robin distribue chaque requête de façon séquentielle parmi un parc de serveurs réels. Avec cet algorithme, tous les serveurs réels sont traités de la même manière, indépendamment de leur capacité ou de leur charge. Ce modèle d'ordonnancement ressemble au DNS round-robin mais est plus granulaire dans la mesure où il est basé sur une connexion réseau et non sur un hôte. L'ordonnancement round-robin LVS ne subit pas les déséquilibres de charge provoqués par des demandes DNS mises en cache.
L'ordonnancement round-robin pondéré distribue chaque requête de façon séquentielle parmi un groupe de serveurs réels mais attribue plus de tâches aux serveurs disposant d'une plus grande capacité. La capacité, déterminée par un facteur poids assigné par l'utilisateur, est ensuite révisée à la hausse ou à la baisse par les informations dynamiques de charge. Pour obtenir de plus amples informations sur la pondération de serveurs réels, consultez la Section 9.3.2.
L'ordonnancement round-robin pondéré est le choix le plus adéquat s'il existe des différences importantes de capacité parmi les serveurs réels du parc. Ceci étant, dans le cas d'une variation considérable de la charge des requêtes, il se peut que le serveur auquel le poids le plus élevé a été attribué, réponde à plus que sa part de requêtes.
Ce type d'ordonnancement distribue plus de requêtes aux serveurs réels qui ont un nombre inférieur de connexions actives. Parce qu'il suit la progression des connexions établies avec les serveurs réels grâce à la table IPVS, le least-connection est un d'algorithme d'ordonnancement dynamique parfaitement approprié aux situations caractérisées par un haut degré de variation dans la charge des requêtes. Ce type d'ordonnancement est idéal dans un parc de serveurs au sein duquel chaque noeud membre a plus ou moins la même capacité. Si un parc est composé de serveurs ayant des capacités différentes, l'ordonnancement least-connections pondéré figurant ci-dessous est un meilleur choix.
L'ordonnancement Least-Connections pondéré distribue un plus grand nombre de requêtes aux serveurs gérant le moins de connexions établies par rapport à leur capacité. La capacité est indiquée par un poids attribué par l'utilisateur qui est ensuite révisée à la hausse ou à la baisse par les informations dynamiques de charge. En raison de ce facteur poids, cet algorithme est idéal dans un environnement où le groupe de serveurs réels contient du matériel à capacité variée. Pour obtenir de plus amples informations sur la pondération des serveurs réels, consultez la Section 9.3.2.
L'ordonnancement Least-Connection basé sur la localité distribue un plus grand nombre de requêtes aux serveurs gérant peu de connexions actives par rapport à leurs IP de destination. Cet algorithme est conçu pour être utilisé dans un cluster de serveurs munis d'un cache de proxy. Il aiguille les paquets d'une adresse IP vers le serveur correspondant à cette adresse, à moins que ce dernier ne fonctionne déjà au-dessus de sa capacité et qu'un autre serveur n'utilise seulement la moitié de sa capacité ; dans ce cas, il assignera l'adresse IP du serveur gérant la moindre charge.
Distribue un plus grand nombre de requêtes aux serveurs gérant peu de connexions actives par rapport à leurs IP de destination finale. Cet algorithme est conçu pour être utilisé dans un cluster de serveurs munis d'un cache de proxy. Il diffère de l'ordonnancement Least-Connections basé sur la localité dans le sens où il mappe l'adresse IP cible vers un sous-groupe de noeuds de serveurs réels. Les requêtes sont alors routées vers le serveur de ce sous-groupe gérant le moins de connexions. Si tous les noeuds de l'IP de destination finale fonctionnent au-dessus de leur capacité, il reproduit un nouveau serveur pour cette IP de destination finale. Pour ce faire, il ajoute au sous-groupe de serveurs réels de cette IP de destination finale le serveur du parc gérant le moins de connexions. Le noeud le plus chargé est alors enlevé du sous-groupe de serveurs réels afin d'éviter une réplication excessive.
Ce type d'ordonnancement par hachage de la destination distribue les requêtes au groupe de serveurs réels en cherchant l'IP de destination finale dans une table de hachage statique. Cet algorithme est conçu pour une utilisation dans un cluster de serveurs munis d'un cache de proxy.
Ce type d'ordonnancement par hachage de la source distribue les requêtes au groupe de serveurs réels en cherchant la source IP dans une table de hachage statique. Cet algorithme est conçu pour des routeurs LVS munis de multiples pare-feu.
L'administrateur d'un cluster LVS peut assigner un poids à chaque noeud du parc de serveurs réels. Ce poids est une valeur entière qui est mise en facteur dans tout algorithme d'ordonnancement basé sur un facteur poids (comme l'ordonnancement Least-Connection pondéré) et aide le routeur LVS à charger du matériel à capacités différentes de façon plus équilibrée.
Le système de poids établit une relation dynamique entre les serveurs, une sorte de rapport. Par exemple, si un serveur réel a un poids correspondant à 1 et un autre serveur un poids fixé à 5, le serveur ayant un poids de 5 recevra 5 connexions pour chaque connexion reçue par le serveur de poids 1. La valeur par défaut pour le poids d'un serveur réel est 1.
Bien que l'utilisation de poids dans des configurations matérielles variables au sein d'un parc de serveurs réels puisse aider à mieux équilibrer la charge du cluster, cette option peut également créer des déséquilibres temporaires ; c'est le cas lorsqu'un serveur réel est introduit dans le parc de serveurs réels et que le serveur virtuel fonctionne selon un ordonnancement least-connections pondéré. Pour illustrer ce point, supposons qu'il y ait trois serveurs dans le parc de serveurs réels. Les serveurs A et B ont un poids de 1 et le troisième serveur, serveur C, un poids de 2. Si pour quelque raison que ce soit le serveur C est défaillant, les serveurs A et B prendront le relais. Mais une fois que le serveur C est de nouveau opérationnel, le routeur LVS, remarquant qu'il n'a aucune connexion, lui enverra toutes les requêtes entrantes jusqu'à ce qu'il ait une charge comparable à celle des serveurs A et B.
Afin d'éviter ce phénomène, l'administrateur peut faire du serveur virtuel un serveur quiesce — chaque fois qu'un nouveau noeud de serveur réel se connecte, la table de least-connections est réinitialisée à zéro, de sorte que le routeur LVS aiguille les requêtes comme si tous les serveurs réels venaient juste d'être ajoutés au cluster.
Précédent | Sommaire | Suivant |
Configuration LVS à trois niveaux | Niveau supérieur | Méthodes de routage |