Clustering d'IP et rpartiteur de charge

Le clustering d'IP permet de mettre en oeuvre un rpartiteur de charge entre diffrents serveurs. Ainsi, si l'on dispose de plusieurs machines, il est possible de les faire apparatre comme une seule et mme machine tout en quilibrant les ressources mais aussi en tant "impermable" au panne. Il est possible de monter des clusters bass sur peu prs n'importe quel protocole comme les protocoles HTTP, MySQL et SMTP par exemple. La mise en place de tels clusters est simple et nous allons voir comment installer le socle commun ces diffrents clusters puis leurs configurations.

1. 2. 3. 4. 5. 6. 7.

Logiciels ncessaires ipvsadm ldirectord Configuration d'un cluster HTTP Configuration d'un cluster MySQL Configuration d'un cluster SMTP Problmes rencontrs

Logiciels ncessaires
Les logiciels que nous allons installs sont tout fait commun dans le monde open source et tous disponibles en un seul package : UltraMonkey. Le problme du package UltraMonkey pour Debian est qu'il n'existe que pour l'architecture 32bits et que pour la compilation, la chose n'est pas aise. Cependant, il et tout fait possible de monter les clusters sans l'aide d'UltraMonkey mais en installant les logiciels un par un. Tout d'abord l'utilitaire de clustering en lui-mme : ipvsadm (du projet Linux Virtual Server (LVS) ). Ipvsadm permet de monter le cluster en ligne de commande. Parce que ipvsadm ne permet "que" de grer les clusters et les machines au sein de ces clusters, il est possible d'utiliser un logiciel permettant de veiller ce que les machines de ces clusters soient aptes rpondre aux requtes. Ce logiciel est ldirectord.

ipvsadm
Une fois ipvsadm install (via la commande apt-get install ipvsadm), il est dsormais possible de crer des clusters. La cration de cluster et de machine au sein de ces clusters se fait par ligne de commande : Cration du cluster :

1.ipvsadm -A -t 192.168.1.225:80 -s rr

Quelques explications :

La cration du cluster se fait via l'option -A (Add) L'option -t correspond au protocole TCP. Pour un service en protocole UDP, utilisez l'option-u. Il est possible de combiner les "redirections" avec iptables en utilisant l'option -f, auquel cas la fonctionnalit mark d'iptables sera utilise.

Puis vient la dfinition du cluster, plus exactement du service. Ici le cluster tournera sur l'adresse IP locale 192.168.1.225 et sur le port 80. La dernire option ici, -s correspond l'algorithme de rpartition de la charge entre les serveurs du cluster. Ici l'algorithme choisit est le Round-Robin (rr) mais il existe aussi leWeighted Round-Robin (wrr) le Least Connected (lc) et le Weighted Least Connected (wlc)

Ajout de machines :

1.ipvsadm -a -t 192.168.1.225:80 -r 192.168.1.203:80 -g

Quelques explications :

L'ajout d'un serveur dans un cluster se fait par l'option -a (add) Puis vient le type de service (ici TCP) Puis la dfinition du cluster (adresse IP et port) Suit la dfinition du serveur distant intgrer (adresse IP et port) avec l'option -r Et ici enfin le type de connexion : -g pour gate

Suppression d'un serveur d'un cluster :

1.ipvsadm -d -t 192.168.1.225:80 -r 192.168.1.203:80

Quelques explications :

L'option -d est le flag pour supprimer une machine d'un cluster L'option -t correspond au type de service dfinit lors de l'ajout du serveur dans le cluster 192.168.1.225:80 est ici le cluster impact -r dtermine le la machine retirer du cluster (pour remove)

Lister les clusters :

1.ipvsadm -ln
Quelques explications :

L'option -l permet de lister tous les clusters d'IP installs sur le serveur ainsi que les serveurs de chaque cluster

L'option -n permet de ne pas rsoudre le couple port / protocole (par exemple affichera 3306 au lieu de mettre le protocole mysql)

Suppression d'un cluster :

1.ipvsadm -D -t 192.168.1.225:80
Avec ces commandes, il est maintenant possible de grer un cluster d'IP. Mais ce n'est pas suffisant pour qu'il soit fonctionnel. En effet, la partie serveur / cluster est paramtrable mais il faut en plus configurer les machines qui seront dans le pool de connexion afin qu'elles puissent rpondre au cluster. Pour qu'une machine puisse intgrer un cluster efficacement, il faut :

Paramtrer le kernel soit dans le /etc/sysctl.conf ou ajouter dans un initscript au dmarrage des machines Pour le fichier /etc/sysctl.conf :

1.net.ipv4.conf.all.arp_ignore=1 2.net.ipv4.conf.all.arp_announce=2
Pour l'initscript :

1.echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore 2.echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce

Selon la mthode, il faudra soit executer les 2 commandes ou lancer un sysctl -p pour charger les paramtres. Ajouter dans le /etc/network/interfaces des machines intgrer au cluster

01.# Interface LoadBalancee 02.auto lo:225 03.iface lo:225 inet static 04.address 192.168.1.225 05.netmask 255.255.255.255 06.network 192.168.1.225 07.broadcast 192.168.1.225 08.up /sbin/route add -host 192.168.1.225 dev lo 09.down /sbin/route del -host 192.168.1.225

Puis monter la nouvelle interface rseau : ifup lo:225 Parce que la cration d'un cluster et l'ajout ou suppression d'un serveur l'intrieur n'est pas forcment pratique en ligne de commande et parce que si une machine tombe elle restera dans le cluster et ainsi provoquera des problmes, il convient d'utiliser une autre utilitaire : ldirectord.

ldirectord
ldirectord est diponible en tlchargement ( ici ) ou par package ( apt-get install ldirectord ). Cet utilitaire fournit des facilits pour la cration et la gestion de cluster. Il ne fonctionne que grce un fichier de configuration ( /etc/ha.d/ldirectord.cf ). Une version internet de la manpage de ldirectord est disponible ici. Le fichier de configuration de ldirectord se compose de 2 parties, la premire pour les paramtres gnraux puis une partie pour les clusters eux mmes. Premire partie :

1.checktimeout=5 2.checkinterval=10 3.autoreload=no 4.logfile="/var/log/ldirectord.log" 5.quiescent=no

Quelques explications :

checktimeout : la dure maximale d'attente pour dclarer une machine up en seconde checkinterval : la dure etre deux vrifications de la validit d'une machine d'un cluster en seconde autoreload : prendre les modifications chaud du fichier de configuration logfile : fichier de log de ldirectord (ajout / suppression de machines dans les clusters) quiescent : si cette option est yes, une machine dclare comme invalide (par exemple ne rpondant pas au ping) ne sera pas retire du cluster mais verra son poids mis 0 et ainsi n'acceptera plus de nouvelles connexions mais continuera de rpondre (si elle le peut) aux connexions dj ouvertes. Il existe bien d'autres options mais celles-ci me semble les plus importantes... Toute option dclare dans cette partie peut tre surcharge dans la dfinition d'un cluster. Seconde partie : les clusters

01.virtual=192.168.1.225:80 02.real=192.168.1.203:80 gate 1 03.real=192.168.1.204:80 gate 2 04.service=http 05.request="/index.html" 06.receive="OK" 07.scheduler=wrr 08.protocol=tcp 09.checktype=negotiate 10.fallback=192.168.1.205:80 gate
Quelques explications :

virtual : le cluster en lui-mme dfinit par l'adresse IP du cluster et son port / protocole

real : une machine intgrer au cluster dfinit par l'adresse IP du serveur, de son port / protocole puis le mode de communication. gate permet de mettre en relation directement le client avec le serveur, masq permet de faire du masquerading entre le serveur de cluster et le serveur rel ( activer avec iptables). Enfin, le dernier paramtre de cette ligne est le poids affect chaque serveur rel

service est le service utilis pour le cluster (par exemple http, mysql, smtp, ftp, ldap, etc...) request : la requte que le cluster doit effectuer pour savoir si le serveur rel est oprationnel receive : expression rgulire que ldirectord utilise sur le rsultat de request pour savoir si le serveur rel est oprationnel scheduler : le type de rpartiteur de charge (rr, wrr, lc, wlc, etc...) protocol : protocole utilis (tcp, udp) checktype : type de vrification : negociate pour l'utilisation de request et receive, pingpour... un ping, external pour l'utilsation d'un script externe (par exemple un script bashpersonnalis) en combinaison avec checkcommand

fallback : dtermine un serveur rel qui n'entre dans le cluster si et seulement le cluster est vide (tous les autres serveurs ont t dtects comme inactifs). Cette option est pratique pour mettre par exemple une webapp de maintenance indiquant qu'un problme technique est survenu d la surcharge par exemple... Ci dessous des exemples de la seconde partie pour des clusters fonctionnels utiliss en production.

Configuration d'un cluster HTTP

Utilis pour le searcher SOLr

01.virtual=192.168.200.225:80 02.real=192.168.200.201:80 gate 03.real=192.168.200.203:80 gate 04.service=http 05.request="/solr_blogs/admin/ping" 06.receive="OK" 07.scheduler=wrr 08.protocol=tcp 09.checktype=negotiate

Configuration d'un cluster MySQL

2 serveurs rels dans le cluster plus un serveur pour le cas o les deux premiers sortiraient. Les deux premiers serveurs sont en rplication du dernier. Dans ce cluster, le script /root/scripts/check_mysql.sh fait une vrification d'accessibilit aux bases de donnes et vrifie que le retard de la rplication n'est pas trop important. Le cluster :

1.virtual=192.168.1.152:3306 2.real=192.168.1.102:3306 gate 100

3.real=192.168.1.103:3306 gate 100 4.fallback=192.168.1.101:3306 gate 1 5.service=mysql 6.scheduler=wrr 7.checktype=external 8.checkcommand="/root/scripts/check_mysql.sh"

Le script :

01.#!/bin/bash 02. 03.VIRTUAL_SERVER=$1 04.VIRTUAL_PORT=$2 05.REAL_SERVER=$3 06.REAL_PORT=$4 07. 08.MAX_LATE=200 09. 10.OK=0 11.KO=1 12. 13.PID=$$ 14.FILE=/tmp/mysql_${3}.${PID} 15. 16.RETURN=$KO 17. 18.RES=$(mysql -umonitoring -pmonitoring -h${REAL_SERVER} -N -e "SELECT 1;") 19. 20. 21.if [ "$RES" == "1" ]; 22.then 23.LATE=$( mysql -umonitoring -pmonitoring -h$3 -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master | awk '{print $2}') 24. 25.if [ $LATE -lt $MAX_LATE ]; 26.then 27.RETURN=$OK 28. 29.fi 30.fi 31. 32.if [ $RETURN -eq $OK ]; 33.then 34.echo "$REAL_SERVER OK" >> /tmp/cluster.sql 35.else 36.echo "$REAL_SERVER NOK" >> /tmp/cluster.sql 37.fi 38. 39.exit $RETURN

Une deuxime possibilit de cluster ne faisant pas intervenir de script externe mais une simple requte SQL :

01.virtual=192.168.1.152:3306 02.real=192.168.1.102:3306 gate 100 03.real=192.168.1.103:3306 gate 100 04.fallback=192.168.1.101:3306 gate 1 05.service=mysql 06.login="monitoring" 07.passwd="monitoring" 08.scheduler=wrr 09.checktype=negociate 10.request="SELECT 1;" 11.receive="1" 12.database="pavnay"

Configuration d'un cluster SMTP

Ce cluster ressemble au cluster MySQL par l'utilisation d'un script externe mais qui envoie un mail. Le cluster :

01.virtual=192.168.1.153:25 02.real=192.168.1.50:25 gate 03.real=192.168.1.51:25 gate 04.real=192.168.1.53:25 gate 05.checkinterval=30 06.scheduler=wrr 07.protocol=tcp 08.checktype=external 09.checkcommand="/root/scripts/check_smtp.sh"
Le script :

01.#!/bin/bash 02. 03.VIRTUAL_SERVER=$1 04.VIRTUAL_PORT=$2 05.REAL_SERVER=$3 06.REAL_PORT=25 07. 08.PID=$$ 09.FILE=/tmp/smtp_${REAL_SERVER}.${PID} 10. 11.echo -n -e "HELO pavnay\r\nMAIL FROM: <webmaster@pavnay.fr>\r\nRCPT TO: <webmaster@pavnay.fr>\r\nDATA\r\nFrom: nc\r\nTo: me\r\nSubject: $3 $(date)\r\n$(date)\r\n.\r\nQUIT\r\n" | nc -t $REAL_SERVER $REAL_PORT>$FILE 12. 13.COUNT=$(tail -3 $FILE | egrep -c -e "250 ok .+ qp" ) 14. 15.if [ "$COUNT" == "1" ];

16.then 17.RETURN=0 18.else 19.RETURN=1 20.fi 21. 22.echo "CHECK MX - $3 - $(date) $COUNT / $RETURN" >> /tmp/cluster.mx 23. 24.rm $FILE 25.exit $RETURN

Problmes rencontrs

Mode gate et les ports : Nous avons tenter de mettre plusieurs serveurs HTTP sur un mme serveur physique en les faisant tourner sur des ports diffrents et de mettre ces serveurs d'application dans un cluster. En mode gate, il n'est pas possible de jouer sur plusieurs ports vers une mme adresse IP. En effet, seul le protocole dfinit pour le cluster est pris en compte (par exemple le protocole httpdessert le port 80 et par consquent, tous serveurs au sein de ce type de cluster seront interrogs sur le port 80. Une possibilt est d'utiliser le mode masq mais plus compliquer mettre en place...

Cluster MySQL et pool de connexion : Nous utilisons couramment Tomcat et le pool de connexion JDBC. Le problme qui est survenu est la dure de vie des connexions entre le pool et le cluster. Une possibilt est d'augmenter la dure de vie des connexions du cluster grce l'option persistent et une dure en seconde.