Le clustering avec LVS de Red Hat Enterprise Linux utilise une machine Linux appelée le routeur actif, pour envoyer des requêtes provenant de l'Internet vers un groupe de serveurs. Pour ce faire, les clusters LVS se composent de deux classifications de machines de base — les routeurs LVS (un actif et un de secours) et un groupe de serveurs réels qui fournissent les services critiques.
Le routeur actif joue un double rôle dans le cluster :
il répartit la charge sur les serveurs réels ;
il contrôle l'intégrité des services sur chacun des serveurs réels.
La tâche du routeur de secours est de surveiller le routeur actif et de prendre sa place en cas de panne.
La Figure 9-1 montre un simple cluster LVS organisé sur deux niveaux. Le premier niveau est composé de deux routeurs LVS — un routeur actif et un routeur de secours. Chacun des routeurs LVS a deux interfaces réseau par machine, une interface sur l'Internet et une interface sur le réseau privé. Une telle configuration leur permet de répartir le trafic entre les deux réseaux. Dans notre exemple, le routeur actif utilise Network Address Translation ou NAT pour diriger le trafic venant de l'Internet vers un nombre variable de serveurs réels composant le deuxième niveau, qui eux, fourniront les services nécessaires. Les serveurs réels dans notre exemple sont connectés au segment d'un réseau privé dédié et font passer tout le trafic public dans les deux sens, à travers le routeur actif LVS. Vu de l'extérieur, le cluster de serveurs apparaît comme une seule entité.
Les requêtes de service arrivant au cluster LVS sont envoyées vers une adresse IP virtuelle ou VIP (de l'anglais, Virtual IP address). Cette dernière, communiquée sur un réseau publique, est l'adresse que l'administrateur du site associe à un nom de domaine pleinement qualifié tel que www.example.com et qui est assignée à un ou plusieurs serveurs virtuels[1]. Notez qu'une adresse IP virtuelle émigrera d'un routeur LVS vers l'autre lors d'une situation de failover, maintenant par là-même une présence à cette adresse. Dans ce sens, ces adresses sont considérées comme des adresses IP flottantes.
Il est possible de créer pour ces adresses IP virtuelles des alias renvoyant au même périphérique que celui connectant le routeur LVS à l'Internet. Par exemple, si eth0 est connecté à l'Internet, de multiples serveurs virtuels peuvent avoir eth0:1 comme alias. Il est également possible d'associer chaque serveur virtuel à un périphérique séparé pour chaque service. Par exemple, le trafic HTTP peut être traité sur eth0:1 et le trafic FTP sur eth0:2.
Seulement un routeur LVS n'est actif à un moment donné. Le rôle du routeur actif est de ré-aiguiller les requêtes de service des adresses IP virtuelles vers les serveurs réels. Le ré-aiguillage est basé sur un des huit algorithmes de répartition de charge supportés et décrits plus loin dans la Section 9.3.
Le routeur actif surveille également de façon dynamique la santé générale des services spécifiques sur les serveurs réels au moyen de simples scripts envoyer/attendre : send/expect scripts. Pour l'aider à détecter la santé des services nécessitant des données dynamiques, comme HTTPS ou SSL, l'administrateur peut également faire appel à des exécutables. Si un service sur un serveur réel ne fonctionne pas correctement, le routeur actif arrête d'envoyer des tâches à ce serveur jusqu'à ce qu'il reprenne une activité normale.
Le routeur de secours assume le rôle d'un système en mode hot-standby. Périodiquement, les routeurs LVS échangent des messages de pulsations (heartbeat) via l'interface primaire publique externe et, dans le cas d'une situation de failover, via l'interface privée. Si le noeud de secours ne reçoit pas de message heartbeat dans le laps de temps imparti, il engendre une procédure de failover et assume le rôle du routeur actif. Pendant une procédure de failover, le routeur de secours adopte l'adresse IP virtuelle servie par le routeur défaillant en utilisant une technique d'usurpation d'adresse appelée ARP spoofing — c'est-à-dire que le routeur de secours LVS s'annonce en tant que destination des paquets IP adressés au noeud en panne. Lorsque le noeud défaillant ré-établit un service actif, le noeud de secours assume à nouveau de façon active, son rôle de secours.
La configuration simple à deux niveaux illustrée dans la Figure 9-1 est le meilleur choix pour les clusters servant des données qui ne changent pas très fréquemment — comme par exemple des pages Web statiques — parce que les serveurs réels individuels ne synchronisent pas automatiquement les données entre chaque noeud.
Puisque dans un clustering LVS il n'y a pas de composants intégrés pour partager les mêmes données entre serveurs réels, l'administrateur dispose de deux options de base :
Synchronisation des données à travers l'ensemble des serveurs réels
Ajout d'un troisième niveau à la topologie pour un accès aux données partagées
La première option représente un meilleur choix pour des serveurs qui ne permettent pas à un grand nombre d'utilisateurs de télécharger ou de changer des données sur les serveurs réels. En revanche, si le cluster permet à de nombreux utilisateurs de modifier des données, comme un site Web e-commerce, la deuxième option est alors préférable.
Un administrateur dispose de nombreuses options pour synchroniser des données à travers un groupe de serveurs réels. Par exemple, il est possible d'utiliser des scripts du shell pour s'assurer que lors de la mise à jour d'une page Web par un ingénieur, cette dernière soit envoyée simultanément à tous les serveurs. L'administrateur du cluster peut également utiliser des programmes comme rsync pour répliquer à travers tous les noeuds et à intervalle déterminé, des données qui ont été modifiées.
Néanmoins, ce type de synchronisation des données ne fonctionne pas très bien si le cluster est extrêmement occupé parce que de nombreux utilisateurs téléchargent des fichiers ou émettent des transactions de base de données en permanence. Dans le cas d'un cluster avec une charge élevée, la meilleure topologie est la topologie à trois niveaux.
[1] | Un serveur virtuel est un service configuré pour répondre à une adresse IP virtuelle spécifique. Pour obtenir des informations supplémentaires sur la configuration d'un serveur virtuel utilisant Outil de configuration de Piranha, consultez la Section 12.6. |
Précédent | Sommaire | Suivant |
Configurations de base | Niveau supérieur | Configuration LVS à trois niveaux |