Red Hat Training

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

1.8.3.2. Routage direct

Le routage direct offre des performances supérieures par rapport au routage NAT. Le routage direct permet aux serveurs réels de traiter et router les paquets directement vers un utilisateur les demandant plutôt que de passer les paquets sortants à travers le routeur LVS. Le routage direct réduit les risques de problèmes de performance réseau en reléguant le travail du routeur LVS pour ne traiter que les paquets entrants.
LVS Implemented with Direct Routing

Figure 1.23. LVS Implemented with Direct Routing

Dans une configuration LVS classique de routage direct, un routeur LVS reçoit des requêtes serveur entrantes par l'intermédiaire d'une adresse IP virtuelle (VIP) et utilise un algorithme de programmation pour diriger les requêtes vers les serveurs réels. Chaque serveur réel traite les requêtes et envoie les réponses directement aux clients sans passer par les routeurs LVS. Le routage direct permet une plus grande évolutivité car les serveurs réels peuvent être ajoutés sans charge supplémentaire sur le routeur LVS pour router les paquets sortants du serveur réel vers le client.
S'il existe de nombreux avantages à l'utilisation du routage direct dans LVS, il existe aussi des limitations. Le problème le plus courant avec le routage direct et LVS est le Protocole de résolution d'adresses (ARP de l'anglais Address Resolution Protocol).
In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.
Le problème avec les requêtes ARP dans une configuration LVS de routage direct est que dans la mesure où l'adresse IP d'une requête client doit être associée à une adresse MAC pour être traitée, l'adresse virtuelle du routeur LVS doit également être associée à une adresse MAC. Cependant, parce que le routeur LVS et les serveurs réels ont la même adresse VIP, la requête ARP est diffusée à tous les noeuds associés à l'adresse VIP. Cela peut causer plusieurs problèmes, tels que l'adresse VIP associée directement à un des serveurs réels et traitant les requêtes directement, sans passer par le routeur LVS et ainsi allant à l'encontre du but de la configuration LVS. L'utilisation d'un routeur LVS avec un CPU puissant qui répond rapidement aux requêtes clients ne résout pas forcément ce problème. Si le routeur LVS est sous une charge élevée, il peut répondre à la requête ARP plus lentement qu'un serveur réel sous-utilisé répondant plus rapidement et qui se fait attribuer l'adresse VIP dans le cache ARP du client effectuant la requête.
Pour résoudre ce problème, les requêtes entrantes devraient uniquement associer l'adresse VIP au routeur LVS, qui traitera correctement les requêtes et les enverra au pool de serveurs réels. Ceci peut être fait en utilisant le pool de filtrage des paquets arptables.