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. 2.

INTRODUCTION ....................................................................................................................................................................................... 3 TOPOLOGIE DE LA TABLE N°5 ......................................................................................................................................................... 4 2.1 2.2 EXPLICATION .................................................................................................................................................................................. 4 SCHEMA D’ARCHITECTURE .................................................................................................................................................... 4

3.

MANIPULATIONS .................................................................................................................................................................................... 5 3.1 3.2 3.3 3.4 3.4.1 3.4.2 CONFIGURATION DES MACHINES ....................................................................................................................................... 5 SCRIPTS POUR LA REPARTITION DES CHARGES ........................................................................................................ 6 TEST DE LA MANIPULATION.................................................................................................................................................. 8 LIMITATION DE VITESSE ET GESTION DE QOS............................................................................................................ 8 SCRIPTS DE MISE EN ŒUVRE AUTOMATIQUE ........................................................................................................ 9 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 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 Puisque nous ne disposions pas de deux connexions internet 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 cidessous :

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 10.0.0.4 0.0.0.0 10.0.0.3 0.0.0.0 172.16.0.0 0.0.0.0 10.0.0.0 0.0.0.0 10.0.0.0 0.0.0.0 127.0.0.0 0.0.0.0 0.0.0.0 172.16.0.205 Genmask 255.255.255.255 255.255.255.255 255.255.255.0 255.0.0.0 255.0.0.0 255.0.0.0 0.0.0.0 Flags UH UH U U U U UG Metric 0 0 0 0 0 0 0 Ref 0 0 0 0 0 0 0 Use 0 0 0 0 0 0 0 Iface eth2 eth1 eth0 eth1 eth2 lo 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 iptables iptables iptables iptables iptables -F -t –t -P -P -P

nat –F mangle -F INPUT ACCEPT OUTPUT ACCEPT 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 ":" teth21=`ifconfig eth2 | grep RX.*TX | cut -d ":" sleep 10 teth12=`ifconfig eth1 | grep RX.*TX | cut -d ":" teth22=`ifconfig eth2 | grep RX.*TX | cut -d ":" if test $((($teth12-$teth11)-($teth22-$teth21))) then /root/LoadBalancing/script2 else /root/LoadBalancing/script1 fi

-f 3 | cut -d " " -f 1` -f 3 | cut -d " " -f 1` -f 3 | cut -d " " -f 1` -f 3 | cut -d " " -f 1` -gt 0

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

Sign up to vote on this title
UsefulNot useful