Rapport d’AIR

Load balancing & Netfilter avancé

Benhammadi Wiam
Wastiaux Fabian
3éme R (11) 2008

AIR – Load Balancing Page 1

 TABLE DES MATIÉRES

1. INTRODUCTION ....................................................................................................................................................................................... 3
2. TOPOLOGIE DE LA TABLE N°5 ......................................................................................................................................................... 4
2.1 EXPLICATION .................................................................................................................................................................................. 4
2.2 SCHEMA D’ARCHITECTURE .................................................................................................................................................... 4
3. MANIPULATIONS .................................................................................................................................................................................... 5
3.1 CONFIGURATION DES MACHINES ....................................................................................................................................... 5
3.2 SCRIPTS POUR LA REPARTITION DES CHARGES ........................................................................................................ 6
3.3 TEST DE LA MANIPULATION.................................................................................................................................................. 8
3.4 LIMITATION DE VITESSE ET GESTION DE QOS............................................................................................................ 8
3.4.1 SCRIPTS DE MISE EN ŒUVRE AUTOMATIQUE ........................................................................................................ 9
3.4.2 RESULTATS DE LA MANIPULATION........................................................................................................................... 10
4. REFERENCES .......................................................................................................................................................................................... 10

AIR – Load Balancing Page 2

 1. INTRODUCTION
Load Balancing en quelques mots :

En français : répartition de charge. Consiste à distribuer une tâche à un pool de machines ou de

périphériques afin
de :

• lisser le trafic réseau, c'est-à-dire de répartir la charge globale vers différents équipements ;

• s'assurer de la disponibilité des équipements en n'envoyant des données qu'aux équipements en

mesure de répondre, voire à ceux offrant le meilleur temps de réponse.

Premiers essais :

Nous avions tout d’abord pensé à permettre à plusieurs machines de se connecter sur internet et, de manière
invisible (à l’aide d’un bridge), utiliser en fait deux connexions internet différentes. Cela aurait permis de
tester plusieurs choses telles que :

1. Faire du load balancing, c'est-à-dire dans ce cas-ci répartir le débit utilisé sur les deux connexions.
2. Utiliser la deuxième connexion comme connexion de secours au cas où la première ne répondrait plus.
3. Garder une des deux connexions pour certains services (afin d’assurer une bonne qualité de service).

Nous avons donc mis en place une machine avec trois cartes Ethernet que nous avons configurées avec ce
script :

#!/bin/bash Puisque nous ne disposions pas de deux connexions internet

ifconfig eth0 0.0.0.0 promisc up
ifconfig eth1 0.0.0.0 promisc up
ifconfig eth2 0.0.0.0 promisc up
brctl addbr bridge
brctl addif bridge eth0
brctl addif bridge eth1
brctl addif bridge eth2
ifconfig bridge up
nous avons connecté la Gateway au bridge, et les deux autres
sorties du bridge à un hub, lui-même connecté au réseau de
Belenos pour accéder à internet. Malheureusement on s’est
rapidement rendu compte que le hub couplé au bridge posait
problème car cela créait des boucles… Les seuls moments où
cela fonctionnait c’était si on coupait une des deux interfaces
connecté au réseau de Belenos. Impossible donc de faire le
point 1 ou le point 3 cité plus haut…
Après quelques essais infructueux avec ebtables et iptables
pour stopper ces boucles nous avons décidé de changer de
projet.

AIR – Load Balancing Page 3

Évolution du projet :

Nous sommes restés dans l’idée de faire du load balancing, mais cette fois-ci du côté serveur. L’idée était de
mettre deux serveurs web sur deux machines différentes (avec un contenu identique) et de répartir la
charge sur chacun des serveurs. Dans notre exemple la « charge » est basée sur la bande passante (de
l’upload) utilisée sur l’un et l’autre des serveurs. On pourrait donc considérer qu’il s’agit de serveurs de
téléchargement. Mais on pourrait très bien imaginer, via un principe similaire, répartir par exemple la
charge de travail d’un programme multithreads sur différente des machines.

Nous avons aussi décidé aussi de faire de la limitation de bande passante et de la gestion de QoS à l’aide du
marquage avec iptables et des files d’attente.

2. TOPOLOGIE DE LA TABLE N°5

2.1 EXPLICATION

Les manipulations s'effectuent sur notre répartiteur qui relie notre passerelle « Karnaugt » sur l'interface
eth0 et nos deux serveurs web sur l'interface eth1 et eth2. Tous les détails sont repris sur le schéma ci-
dessous :

2.2 SCHEMA D’ARCHITECTURE

AIR – Load Balancing Page 4

 3. MANIPULATIONS

3.1 CONFIGURATION DES MACHINES

• Configuration du répartiteur :

Script configCartes :

Comme indiqué sur le schéma d’architecture plus haut, nous avons configuré les différentes cartes
réseaux. Il a été nécessaire de rajouter des routes pour les adresses 10.0.0.1 et 10.0.0.2 car, les deux
cartes ethernet se trouvent dans le même réseau et il faut qu’il sache par quelle carte passer :

#!/bin/bash

#attribution des addresses ip

ifconfig eth0 172.16.0.105 netmask 255.255.255.0
ifconfig eth1 10.0.0.1 netmask 255.0.0.0
ifconfig eth2 10.0.0.2 netmask 255.0.0.0

#ajout des routes nécessaires

route add -net 10.0.0.3 netmask 255.255.255.255 eth1
route add -net 10.0.0.4 netmask 255.255.255.255 eth2
route add default gw 172.16.0.205

#activation de l’ip forward

echo "1" > /proc/sys/net/ipv4/ip_forward

Nous obtenons cette table routage à l’aide de la commande « route –n »

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.4 0.0.0.0 255.255.255.255 UH 0 0 0 eth2
10.0.0.3 0.0.0.0 255.255.255.255 UH 0 0 0 eth1
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 172.16.0.205 0.0.0.0 UG 0 0 0 eth0

AIR – Load Balancing Page 5

 • Configuration des machines serveurs

Afin de permettre aux serveurs web de répondre aux requêtes qui leur seront envoyées, il faut modifier leur
passerelle par défaut pour l’adresse de celle du répartiteur (10.0.0.2) pour la machine de Wiam et 10.0.0.1
pour celle de Fabian

3.2 SCRIPTS POUR LA REPARTITION DES CHARGES

Script defaultPolitique :

Premièrement, nous allons mettre toutes les politiques d’iptable à Accept par défaut et nous effaçons les
règles actuelles :

#!/bin/bash

iptables -F
iptables -t nat –F
iptables –t mangle -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

Nous allons lancer un script qui permet de regarder sur 10 secondes quelle est la carte réseau qui envoie le
plus de données entre eth1 et eth2. Pour se faire elle enregistre la valeur de TX de la carte eth1 et eth2, on
patiente 10 secondes et enregistre à nouveau cette valeur pour les deux cartes. On fait pour chaque carte la
soustraction entre la seconde valeur enregistrée et la première. Ensuite on regarde laquelle obtient la plus
grande différence : c’est celle qui émet le plus de trafic. En fonction de la carte qui a le plus de trafic, on lance
le script 1 ou le script2

Script trafic :

#!/bin/sh
teth11=`ifconfig eth1 | grep RX.*TX | cut -d ":" -f 3 | cut -d " " -f 1`
teth21=`ifconfig eth2 | grep RX.*TX | cut -d ":" -f 3 | cut -d " " -f 1`
sleep 10
teth12=`ifconfig eth1 | grep RX.*TX | cut -d ":" -f 3 | cut -d " " -f 1`
teth22=`ifconfig eth2 | grep RX.*TX | cut -d ":" -f 3 | cut -d " " -f 1`
if test $((($teth12-$teth11)-($teth22-$teth21))) -gt 0
then /root/LoadBalancing/script2
else /root/LoadBalancing/script1
fi

AIR – Load Balancing Page 6

Les scripts qui suivent vont permettre de faire du nat de manière à ce que les requêtes http dirigées vers le
répartiteur soient, de manière invisible, redirigées vers l’une des deux machines.

Script Script1

#!/bin/sh
#Fichier script1
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp -d 172.16.0.105 --dport 80 -j DNAT --to-destination
10.0.0.3
iptables -t nat -A POSTROUTING -o eth1 -s 10.0.0.3 -j SNAT --to-source 172.16.0.105

Script Script2

#!/bin/sh
#Fichier script2
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp -d 172.16.0.105 --dport 80 -j DNAT --to-destination
10.0.0.4
iptables -t nat -A POSTROUTING -o eth2 -s 10.0.0.4 -j SNAT --to-source 172.16.0.105

Le script boucle va permettre de lancer en boucle, à une seconde d’intervalle, le script trafic. On aura donc à
chaque seconde, un équilibrage de la charge sur les 10 secondes antérieures.

Script boucle

while true; do
sleep 1
/root/LoadBalancing/trafic &
done

AIR – Load Balancing Page 7

 3.3 TEST DE LA MANIPULATION

Pour tester le bon fonctionnement des scripts, nous avons utilisé deux serveurs web avec du contenu
différent. Lorsqu’on actualise plusieurs fois la page d’index sur laquelle on atterrit, elle change. Si on lance un
téléchargement sur l’un des serveurs et qu’on continue à actualiser la page d’index, on n’atterrit plus que sur
le serveur sur lequel il n’y a pas le téléchargement en cours. Une fois le téléchargement terminé les deux
pages s’affichent à nouveau.

3.4 LIMITATION DE VITESSE ET GESTION DE QOS

Nous avons mis en place 3 files d’attente configurées selon les modalités suivantes :

• Une file de discipline SFQ avec un trafic limité à 2mb/s et un trafic normal à 2mb/s
• Une file de discipline SFQ avec un trafic limité à 40 mb/s et un trafic normal à 40 mb/s
• L’ensemble de ces files sont limitées à 60 mb/s au total, toutes files confondues. La discipline de cette
file de sortie est HTB.

Par conséquent, le trafic sortant de la machine sera limité à 60 mb/s au total, et le traitement par files
d’attentes séparées permettra de répartir le trafic selon son importance.

Quelques définitions :

HTB :
Hierarchical Token Bucket :HTB permet de gérer des files
d’attente pour une connexion donnée. Il est une alternative
plus simple et intuitive que les listes de type CBQ (Class based
queuing).
SFQ :
Stochastic Fairness Queueing : Va permettre un partage
équitable (même priorité) entre les données des différentes
files.

Rate :
Le débit moyen.
Ceil :
Le débit maximal autorisé.

AIR – Load Balancing Page 8

Afin de vérifier le fonctionnement de ces séries de files d’attente, et la façon dont les paquets sont priorisés
en cas d’engorgement, il faut créer un script de configuration automatique pour configurer iptables et tc.

3.4.1 SCRIPTS DE MISE EN ŒUVRE AUTOMATIQUE

Jusqu'à maintenant, nous avons vu comment iptables travaille, et netfilter a été mentionné plusieurs fois.
Netfilter nous permet de filtrer les paquets. Une de ses fonctionnalités particulières est de pouvoir marquer
un paquet avec un nombre, grâce à l'option --set-mark. Les files d’attente peuvent lire cette marque et agir en
conséquence.

Script FileAttente
#!/bin/sh

./no_firewall

## Effacer ancienne config

tc qdisc del dev eth1 root 2>/dev/null

##je crée ma file d'attente principale

##====================================
tc qdisc add dev eth1 root handle 100: htb

#Creation des files

##==================

tc qdisc add dev eth1 parent 100:10 handle 54: sfq

tc qdisc add dev eth1 parent 100:20 handle 60: sfq

##j'utilise Iptables pour marquer les paquets selon mes choix

==============================================================

iptables -t mangle -A FORWARD -i eth2 -j MARK --set-mark 5

iptables -t mangle -A FORWARD -i eth0 -j MARK --set-mark 6

##Je définie des classes, une par type de connexion ;

##====================================================

tc class add dev eth1 parent 100: classid 100:1 htb rate 60000Kbit
tc class add dev eth1 parent 100:1 classid 100:10 htb rate 2000Kbit ceil 2000Kbit
tc class add dev eth1 parent 100:1 classid 100:20 htb rate 40000Kbit ceil 40000Kbit

## Filtrage suivant les marques des paquets

##Avec ces commandes on affecte les paquets marqués aux files d'attentes correspondantes,
et bien sûr ils seront gérés suivant les paramètres de flux définis.
##====================================================

tc filter add dev eth1 protocol ip handle 5 fw flowid 100:10

tc filter add dev eth1 protocol ip handle 6 fw flowid 100:20

AIR – Load Balancing Page 9

 3.4.2 RESULTATS DE LA MANIPULATION

Nous avons modifié ce script pour limiter la vitesse à 20 kbits et 40 kbits et nous l’avons lancé sur la
gateway . Nous avons ensuite téléchargé un fichier se trouvant sur le serveur web (en local donc) depuis la
machine client et depuis la dmz pour vérifier que la limitation fonctionnait bien. L’utilitaire iptraff nous a
permis de voir avec précision que les limites étaient bien effectives.

Il suffit maintenant de manipuler iptables pour marquer les paquets pour certains services particuliers
(voir résumé sur iptables du premier bi-mestre) et de les affecter à des classes qui répondront aux besoins
de ceux-ci (priorité, débit minimal, etc …).

4. REFERENCES

Nous citons nos sources ci-dessous.

- http://www.netfilter.org/
- http://www.nbs-system.com/dossiers/howto-iptables.html
- http://www.linux-sottises.net/iptables/iptables
- http://www.linux-france.org/
- http://lea-linux.org/cached/index/Reseau-secu-iptables.html#
- http://fr.wikipedia.org/

AIR – Load Balancing Page 10