Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

3.2. LVS via le routage direct

As mentioned in Section 1.4.2, « Routage direct », direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
Structure du réseau
Dans une configuration LVS de routage direct, le routeur LVS doit recevoir les requêtes entrantes et les router vers le serveur réel approprié en vue de leur traitement. Les serveurs réels doivent ensuite router la réponse directement au client. Par exemple, si le client est sur l'Internet et qu'il envoie le paquet par l'intermédiaire du routeur LVS à un serveur réel, le serveur réel doit être capable d'aller directement vers le client via l'Internet. Ceci est possible en configurant une passerelle pour le serveur réel afin de transmettre les paquets sur l'Internet. Chaque serveur réel du pool de serveurs peut avoir sa propre passerelle (et chaque passerelle doit avoir sa propre connexion à l'Internet), ce qui permet un débit maximal et une grande évolutivité. Toutefois, pour les configurations LVS typiques, les serveurs réels peuvent communiquer par l'intermédiaire d'une seule passerelle (et donc une seule connexion réseau).

Important

Nous ne vous recommandons pas d'utiliser le routeur LVS comme passerelle pour les serveurs réels, étant donné que cela ajoute une complexité de configuration inutile et une charge réseau sur le routeur LVS qui réintroduisent le goulet d'étranglement réseau existant avec le routate NAT.
Matériel
Les besoins matériels d'un système LVS utilisant le routage direct sont similaires aux autres topologies LVS. Alors que le routeur LVS a besoin d'exécuter Red Hat Enterprise Linux pour traiter les requêtes entrantes et effectuer la répartition de charge pour les serveurs réels, les serveurs réels n'ont pas besoin d'être des machines Linux pour fonctionner correctement. Les routeurs LVS doivent avoir une ou deux NIC chacun (cela dépend s'il y a un routeur de sauvegarde). Vous pouvez utiliser deux NIC pour alléger la configuration et séparer distinctement le trafic — les requêtes entrantes sont traitées par une NIC et les paquets routés vers les serveurs réels par l'autre.
Étant donné que les serveurs réels contournent le routeur LVS et envoient les paquets sortants directement au client, une passerelle vers l'Internet est requise. Pour des performances et une disponibilité maximales, chaque serveur réel peut être connecté à sa propre passerelle qui dispose de sa propre connexion au réseau porteur auquel le client est connecté (par exemple l'Internet ou un Intranet).
Logiciel
There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using LVS via direct routing. Refer to Section 3.2.1, « Routage direct et arptables_jf » or Section 3.2.2, « Routage direct et iptables » for more information.

3.2.1. Routage direct et arptables_jf

In order to configure direct routing using arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
En utilisant la méthode arptables_jf, les applications peuvent se lier à chaque adresse VIP ou port individuel que le serveur réel sert. Par exemple, la méthode arptables_jf permet à plusieurs instances du Apache HTTP Server en cours d'exécution d'être liées explicitement à différentes adresses VIP sur le système. Il y a également des avantages significatifs au niveau des performances liés à l'utilisation de arptables_jf avec l'option IPTables.
Cependant, en utilisant la méthode arptables_jf, les adresses VIP ne peuvent pas être configurées afin d'être lancées au démarrage en utilisant les outils de configuration système de Red Hat Enterprise Linux.
Afin de configurer chaque serveur réel de manière à ignorer les requêtes ARP pour chacune des adresses IP virtuelles, effectuez les étapes suivantes :
  1. Créez les entrées de la table ARP pour chaque adresse IP virtuelle sur chaque serveur réel (real_ip est l'adresse IP que le "director" utilise pour communiquer avec le serveur réel ; souvent il s'agit de l'adresse IP liée à eth0) : 
    arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    Cela forcera les serveurs réels à ignorer les requêtes ARP pour les adresses IP virtuelles et à modifier toute réponse ARP sortante contenant l'adresse IP virtuelle par l'adresse IP réelle du serveur. Le seul noeud qui devrait répondre aux requêtes ARP pour une des adresses VIP est le noeud LVS actif en cours.
  2. Une fois que cela est terminé pour chaque serveur réel, enregistrez les entrées de la table ARP en saisissant les commandes suivantes sur chaque serveur réel :
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    La commande chkconfig fait en sorte que le système recharge la configuration arptables au démarrage — avant que le réseau ne soit démarré.
  3. Configurez l'adresse IP virtuelle sur tous les serveurs réels en utilisant ifconfig pour créer un alias IP. Par exemple : 
    # ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
    Ou en utilisant l'utilitaire iproute2 ip, par exemple : 
    # ip addr add 192.168.76.24 dev eth0
    Comme noté précédemment, les adresses IP virtuelles ne peuvent pas être configurées pour être lancées au démarrage en utilisant les outils de configuration du système Red Hat. Une façon de contourner ce problème est de placer ces commandes dans /etc/rc.d/rc.local.
  4. Configure Piranha for Direct Routing. Refer to Chapitre 4, Configurer le routeur LVS avec l'Piranha Configuration Tool for more information.