1.3.2. Programmation et charge des serveurs

L'administrateur LVS peut assigner une charge à chaque noeud du pool de serveurs réels. Cette charge correspond à une valeur entière qui est prise en compte par les algorithmes de programmation weight-aware (par exemple l'algorithme weighted least-connections) et qui permet au routeur LVS de partager la charge entre du matériel n'ayant pas les mêmes capacités.

Les charges sont en rapport les unes par rapport aux autres. Par exemple, si un serveur réel a une charge de 1 et que l'autre serveur possède une charge de 5, le serveur avec une charge de 5 obtiendra 5 connexions pour chaque connexion reçue par l'autre serveur. La valeur par défaut d'un serveur réel est 1.

Bien que l'utilisation de la charge (weight) pour des configurations matérielles variées dans un pool de serveurs réels puisse aider à répartir la charge du cluster efficacement, cela peut également causer des déséquilibres temporaires lorsqu'un serveur réel est introduit dans le pool de serveurs réels et qu'il est programmé pour utiliser une connexion weighted least-connections. Par exemple, supposez qu'il y ait trois serveurs dans le pool de serveurs réels. Les serveurs A et B ont une charge de 1 et le troisième, le serveur C, a une charge de 2. Si le serveur C échoue pour une raison ou une autre, les serveurs A et B distribuerons équitablement la charge abandonnée. Cependant, lorsque le serveur C est à nouveau disponible, le routeur LVS s'aperçoit qu'il n'a pas de connexion et l'inonde avec toutes les requêtes entrantes jusqu'à ce qu'il soit au même niveau que les serveurs A et B.

Pour empêcher ce phénomène, les administrateurs peuvent faire du serveur virtuel un serveur quiesce — à chaque fois qu'un serveur réel est à nouveau disponible, la table least-connections est remise à zéro et le routeur LVS dirige les requêtes comme si tous les serveurs réels venaient d'être ajoutés au cluster.