Chapitre 10. Équilibrage de charge sur plusieurs interfaces

Il existe plusieurs manières pour le faire. Une des plus faciles et des plus directes est TEQL (True (or Trivial) Link Equalizer. Comme la plupart des éléments en relation avec la gestion de file d'attente, l'équilibrage de charge est bidirectionnel. Les deux équipements terminaux du lien ont besoin de participer pour obtenir une efficacité optimale.

Imaginez la situation suivante :

                 +-------+   eth1   +-------+
                 |       |==========|       |
 'réseau 1' -----|   A   |          |   B   |---- 'réseau 2'
                 |       |==========|       |
                 +-------+   eth2   +-------+

A et B sont des routeurs dont nous supposerons qu'ils fonctionnent avec Linux pour le moment. Si le trafic va du réseau 1 vers le réseau 2, le routeur A a besoin de distribuer les paquets sur les deux liens allant vers B. Le routeur B a besoin d'être configuré pour l'accepter. On retrouve la même chose dans le sens inverse, pour les paquets allant du réseau 2 vers le réseau 1. Le routeur B a besoin d'envoyer les paquets à la fois sur eth1 et eth2.

La répartition est faite par un périphérique TEQL, comme ceci (cela ne pouvait pas être plus simple) :

# tc qdisc add dev eth1 root teql0
# tc qdisc add dev eth2 root teql0
# ip link set dev teql0 up

N'oubliez pas la commande ip link set up !

Ceci a besoin d'être fait sur les deux hôtes. Le périphérique teql0 est basiquement un distributeur tourniquet au-dessus de eth1 et eth2 pour l'envoi des paquets. Aucune donnée n'arrive jamais à travers un périphérique teql, mais les données apparaissent sur eth1 et eth2.

Nous n'avons pour le moment que les périphériques et nous avons également besoin d'un routage correct. L'une des possibilités pour réaliser cela est d'assigner un réseau /31 sur chacun des liens, ainsi que sur le périphérique teql0 :

FIXME: Avons nous besoin de quelque chose comme nobroadcast ? Un /31 est trop petit pour contenir une adresse réseau et une adresse de diffusion. Si cela ne marche pas comme prévu, essayez un /30, et ajustez les adresses IP. Vous pouvez même essayer sans attribuer d'adresses à eth1 et eth2.

Sur le routeur A:

# ip addr add dev eth1 10.0.0.0/31
# ip addr add dev eth2 10.0.0.2/31
# ip addr add dev teql0 10.0.0.4/31

Sur le routeur B:

# ip addr add dev eth1 10.0.0.1/31
# ip addr add dev eth2 10.0.0.3/31
# ip addr add dev teql0 10.0.0.5/31

Le routeur A devrait maintenant être capable de lancer un ping vers 10.0.0.1, 10.0.0.3 et 10.0.0.5 à travers les deux liens physiques et le périphérique « égalisé ». Le routeur B devrait maintenant être capable de lancer un ping vers 10.0.0.0, 10.0.0.2 et 10.0.0.4 à travers les liens.

Si cela marche, le routeur A peut prendre 10.0.0.5 comme route vers le réseau 2 et le routeur B 10.0.0.4 comme route vers le réseau 1. Pour le cas particulier où le réseau 1 est votre réseau personnel et où le réseau 2 est l'Internet, le routeur A peut prendre 10.0.0.5 comme passerelle par défaut.

10.1. Avertissement

Rien n'est aussi simple qu'il y paraît. Les interfaces eth1 et eth2 sur les deux routeurs A et B ne doivent pas avoir la fonction de filtrage par chemin inverse activée. Dans le cas contraire, ils rejetteront les paquets destinés à des adresses autres que les leurs :

# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter

Il y a un sérieux problème avec le réordonnancement des paquets. Supposons que six paquets aient besoin d'être envoyés de A vers B. Par exemple, eth1 peut traiter les paquets 1, 3 et 5 et eth2 les paquets 2, 4 et 6. Dans un monde idéal, le routeur B devrait recevoir ces paquets dans l'ordre 1, 2, 3, 4, 5, 6. Mais il est plus probable que le noyau les recevra comme ceci : 2, 1, 4, 3, 6, 5. Ce problème va perturber TCP/IP. Alors qu'il n'y a pas de problèmes pour les liens transportant différentes sessions TCP/IP, vous ne serez pas capable de regrouper plusieurs liens et obtenir par ftp un simple fichier beaucoup plus rapidement, à moins que le système d'exploitation envoyant ou recevant ne soit Linux. En effet, celui-ci n'est pas facilement perturbé par de simples réordonnancements.

Cependant, l'équilibrage de charge est une bonne idée pour de nombreuses applications.