1.3. Aperçu de la programmation LVS
Un des avantages de l'utilisation de LVS est sa capacité à effectuer une répartition de charge flexible, au niveau de l'adresse IP, sur le pool de serveurs réels. Cette flexibilité est due à la variété d'algorithmes de programmation à la disposition d'un administrateur lors de la configuration LVS. La répartition de charge LVS est supérieure à d'autres méthodes moins flexibles, telles que la méthode Round-Robin DNS où la nature hiérarchique du DNS et la mise en cache des machines client peuvent conduire à des déséquilibres de charge. De plus, le filtrage de bas niveau employé par le routeur LVS a des avantages par rapport à la transmission de paquets au niveau de l'application car la répartition de charge au niveau des paquets du réseau cause une surcharge minimale et permet une plus grande évolutivité.
Using scheduling, the active router can take into account the real servers' activity and, optionally, an administrator-assigned weight factor when routing service requests. Using assigned weights gives arbitrary priorities to individual machines. Using this form of scheduling, it is possible to create a group of real servers using a variety of hardware and software combinations and the active router can evenly load each real server.
Le mécanisme de programmation pour LVS est fourni par une collection de correctifs noyau appelés modules de serveur virtuel IP ou IPVS. Ces modules activent le changement de la couche de transport layer 4 (L4), qui est désignée pour fonctionner correctement avec plusieurs serveurs sur une adresse IP unique.
Pour tracer et diriger efficacement les paquets vers les serveurs réels, IPVS construit une table IPVS dans le noyau. Cette table est utilisée par le routeur LVS actif pour rediriger les requêtes d'une adresse de serveur virtuel entrant et sortant des serveurs réels du pool. Le tableau IPVS est constamment mise à jour par un utilitaire appelé ipvsadm — cet utilitaire ajoute et supprime des membres du cluster en fonction de leur disponibilité.
1.3.1. Algorithmes de programmation
The structure that the IPVS table takes depends on the scheduling algorithm that the administrator chooses for any given virtual server. To allow for maximum flexibility in the types of services you can cluster and how these services are scheduled, Red Hat Enterprise Linux provides the following scheduling algorithms listed below. For instructions on how to assign scheduling algorithms refer to Section 4.6.1, « La sous-section VIRTUAL SERVER ».
- Round-Robin Scheduling
- Distribue chaque requête consécutivement autour du pool de serveurs réels. En utilisant cet algorithme, tous les serveurs réels sont traités de la même manière, sans prendre en compte la capacité ou la charge. Ce modèle de programmation ressemble au modèle "round-robin DNS" mais il est plus granulaire car il est basé sur une connexion réseau et non sur un hôte. De plus, la programmation "LVS round-robin" ne souffre pas des déséquilibres causés par les requêtes DNS mises en cache.
- Weighted Round-Robin Scheduling
- Distributes each request sequentially around the pool of real servers but gives more jobs to servers with greater capacity. Capacity is indicated by a user-assigned weight factor, which is then adjusted upward or downward by dynamic load information. Refer to Section 1.3.2, « Programmation et charge des serveurs » for more on weighting real servers.L'algorithme de programmation Weighted round-robin est l'algorithme préféré lorsqu'il y a des différences sensibles entre la capacité des serveurs réels du pool. Cependant, si la charge des requêtes varie considérablement, un serveur très alourdi pourrait répondre à plus de requêtes qu'il ne devrait.
- Least-Connection
- Distribue davantage de requêtes aux serveurs réels ayant moins de connexions actives. Parce qu'il garde une trace des connexions aux serveurs réels à travers la table IPVS, "least-connection" est un algorithme de programmation de type dynamique. C'est une bonne option s'il y a un degré de variation important au niveau de la charge des requêtes. Il s'agit de l'algorithme qui correspond le mieux à un pool de serveurs où chaque noeud du serveur a approximativement la même capacité. Si les serveurs réels d'un pool ont des capacités différentes, la programmation weighted least-connection constitue un meilleur choix.
- Weighted Least-Connections (default)
- Distributes more requests to servers with fewer active connections relative to their capacities. Capacity is indicated by a user-assigned weight, which is then adjusted upward or downward by dynamic load information. The addition of weighting makes this algorithm ideal when the real server pool contains hardware of varying capacity. Refer to Section 1.3.2, « Programmation et charge des serveurs » for more on weighting real servers.
- Locality-Based Least-Connection Scheduling
- Distribue davantage de requêtes aux serveurs ayant moins de connexions actives en fonction de leur adresse IP de destination. Cet algorithme est dédié à une utilisation au sein d'un cluster de serveurs proxy-cache. Il achemine les paquets d'une adresse IP vers le serveur de cette adresse à moins que ce serveur soit au-delà de ses capacités et qu'il soit à plus de la moitié de sa charge, auquel cas il assigne l'adresse IP au serveur réel le moins chargé.
- Locality-Based Least-Connection Scheduling with Replication Scheduling
- Distribue davantage de paquets aux serveurs ayant moins de connexions actives en fonction de leur adresse IP de destination. Cet algorithme est également dédié à une utilisation au sein d'un cluster de serveurs proxy-cache. Il diffère de la programmation Locality-Based Least-Connection car il mappe l'adresse IP cible à un sous-groupe de noeuds de serveurs réels. Les requêtes sont ensuite routées vers le serveur de ce sous-groupe ayant le moins de connexions. Si tous les noeuds pour l'adresse IP de destination sont en-dessus de leurs capacités, il réplique un nouveau serveur pour cette adresse IP de destination en ajoutant le serveur réel ayant le moins de connexions à partir du pool entier de serveurs réels vers le sous-groupe de serveurs réels. Le noeud le plus chargé est ensuite retiré du sous-groupe de serveurs réels pour éviter les excès de réplication.
- Destination Hash Scheduling
- Distribue les requêtes vers le pool de serveurs réels en cherchant l'adresse IP de destination dans une table de hachage statique. Cet algorithme est dédié à une utilisation au sein d'un cluster de serveurs proxy-cache.
- Source Hash Scheduling
- Distribue les requêtes vers le pool de serveurs réels en cherchant l'adresse IP source dans une table de hachage statique. Cet algorithme est dédié aux routeurs LVS avec plusieurs pare-feu.
