OVH Community, votre nouvel espace communautaire.

[How To] Load Balancing avec HA Proxy


thierry78
09/09/2008, 11h25
Je penses honetement que ton serveur à un probleme de tunning, peut etre même un problème hard. haproxy n'est pas loin d'atteindre le 10Gbps avec des machines achetées rue montgallet (sauf les cartes reseau bien sur). Un fichier de 3Mo doit bien sur faire monter un tout petit la conso CPU mais pendant un temps ridicule.

je viens de faire un test rapide, dans des condition qui ne correspondent pas ivraiment à la realité, mais qui sont plus ou moins similaires:

un haproxy, un client/serveur rudimentaires, sur une meme machine, j'atteint un debit de 7Gbps sur la loopback. Sur un linux, la loopback fait toutes les operation liées a la pile IP, sa seule acceleration est qu'elle n'est pas limité par le matériel.

j'ai fait le test sur mon portable, c'est un intel core2duo 2.4Ghz. bien sur le cpu est saturé (10% systeme et 80% user) la version de haproxy est: 1.3.15.1

voila le script de demarrage haproxy avec sa conf:
# cat test.sh
haproxy -p $PIDFILE -f /dev/stdin < global
log 127.0.0.1:4000 local0 debug

listen proxy 127.0.0.1:4001
log global
mode http
option httpclose
option httplog
balance roundrobin
contimeout 500000
clitimeout 500000
srvtimeout 500000
server serveur 127.0.0.1:8002
EOF

le serveur:
(echo -ne "HTTP/1.0 200 OK\r\n\r\n" ; cat /dev/zero) | nc -lp 8002 >/dev/null

le client:
( echo -ne "POST / HTTP/1.0\r\nHost: www\r\n\r\n" ) | nc 127.0.0.1 4001 >/dev/null

le client fait un POST et le serveur repond un flux illimité de 0. (il faut rediriger les sortie vers /dev/null sinon c'est le terminal qui limite le debit reseau)

je ne suis pas en mesure de donner un manip pour degonfler le CPU. sans possibilité de diagnostic ce n'est pas simple. par contre je peux garantir que 5Mbps pour 100% de CPU, c'est un comportement tout a fait anormal ! lors d'un transfert de fichier de grosse taille, pendant le passage des datas, haproxy ne fait que copier du buffer reseau coté serveur vers son buffer interne et copier de son buffer interne vers le buffer reseau coté client, ces opérations ne prennent pas de temps, la conso CPU doit d'ailleur consommer plus système que de user.

Le haproxy que je connais qui consomme le plus est sur un serveur de jeu videos qui fournit des mises a jour pour WoW, le debit est aussi monstrueux que la taille des fichier fournis par le serveur, il y a un seul haproxy pour tout ça. Tu peux te faire une idée ici de ce qui est attendu en focntion du materiel: http://www.exceliance.fr/ahcaract.htm (les perfs annoncées sont largement sous estimés par rapport aux tests effectués). Pour ces machines les processeurs ne sont pas donnés, mais ce sont tous du x86 ils vont du geode LX800 pour la plus petite au P4 2,??GHz pouyr la plus grosse, les machines n'ont qu'un seul processeur. Bien evidement ces appliances sont basées sur du haproxy.

pour resoudre le souci:

- regarde si tu n'a pas des erreurs sur tes interface reseaux (netstat -ni)

- si la negociation est OK (ethtool ethx) (j'ai souvent vu des problemes de négo, notament avec des machines forcés en gigabit face a des switchs cisco),

- la version du kernel, dans les kernels 2.6 le sheduleur à été réécrit, il a mis du temps à se stabiliser. ont trouve donc des kernel 2.6 catastrophiques. toutes les appliance citées plus haut sont en 2.4. les tests rapides que j'ai fait plus haut, sont sur un 2.6.23.14

- il peut aussi y avoir l'utilisation de netfilter qui impacte les perfs. Lorsque el conntrack est activé, les perfs chutent, mais pas à ce point.

- tu peux eventuellement faire un strace sur le binaire haproxy pendant les tests, peut etre y aura t il quelque chose de flagrant.

- regarder le type des cartes reseau (j'ai deja vu un constructeur de firewalls français mettre des cartes realtek à 5 euros pieces dans leurs équipements - LA HONTE !!!)

- pour faire des tests unitaires, tu peux utiliser TUX, c'est un serveur web directement implementé dans la kernel. il arrache !

- pour des tests de debits, netcat est parfait, il faut forger la requete, mais c'est peanuts.

...

je n'ai plus d'idées, si tu souhaite une aide au debug, n'hésite pas.

Ethaniel
09/09/2008, 09h37
Oui Oui Oui...
Mais à chacun son utilisation Nous on s'en sert pour le hosting de site web critique. Mais en local dans notre société... J'y ai bossé 3 mois sur cet appli, et la Thithi me dit que "Ce qui compte pour la consu cpu de la machine ce n'est pas le débit ou les trames traités, mais le nombre de requetes", qui capote toute ma théorie, alors j'en profite pour vraiment apprendre quelque chose sur ce forum

Meskalyn
09/09/2008, 09h06
Cette configuration restait simple et avait pour but de montrer ce que ça pouvait faire.
Pour info mon HAProxy sert 2000 requetes/s et le load ne monte qu'à 3% (dual core +2Go de RAM) (si bien que j'ai rajouté un lighttpd sur le serveur du HAProxy en BACKUP.
Le HAProxy ne me sert qu'à servir 3 petits fichiers php.

Je l'installe aussi lors de mes changements de DNS pour tout ce qui est mail + web.

@Ethaniel, pour les gros fichiers, je n'ai jamais testé...

Ethaniel
09/09/2008, 01h06
Thierry78, tu t'inscris et répond uniquement pour ce post, c'est une bénédiction on dirait.
Alors j'ai été très surpris, car moi de notre coté, c'est simple :
- Mon serveur Haproxy est un P4 HT 3Ghz / 2Go RAM, et on fait 700/1200 requetes / sec (charge à 30%), et il suffit qu'un client télécharge un fichier de 3Mo pour saturer le serveur de tête. (On a testé : un load à vide, 1 serveur telecharge fichier de 700Mo, on arrive a du 5 Mo/sec CPU à 100%). Alors je serais très interessé par ton fichier de config, ou une manip, pour arriver à dégonfler la charge CPU car nous nous sommes arrivés au point de consacrer 3 serveurs en Load Balacing Haproxy pour un gros client.

thierry78
09/09/2008, 00h43
Bonjour,

haproxy ne fait pas de NAT à proprement parler. Le NAT est un concept reseau qui consiste à modifier un adresse IP dans un flux tcp/ip sans intervenir plus que ça dans le protocole tcp/ip.

Comme son nom l'indique haproxy est un proxy, il fait une rupture protocolaire complète. c'est a dire que la session tcp/ip et la couche http établie avec le client n'est pas la même que celle établie entre haproxy et les serveurs.

depuis quelques version, haproxy sais focntionner en mode proxy transparent, c'est à dire qu'il presente une requete au serveur ayant pour source l'ipdu client. Cette fonctionnalité est fortement liée au système, elle demande un kernel linux patché avec cttproxy (http://www.balabit.com/support/commu...oducts/tproxy/), certainement la recompilation d'haproxy avec cette option activée. et bien sur haproxy doit être le routeur par defaut de la ferme de serveurs (il doit se trouver en coupure sur les flux de reponses). tout est détaillé dans la doc.

je ne connais pas le terme IPU, toutefois, nous arrivons a plus de 1500 hits/s (avec des objets de taille null) sur des machines avec des des processeurs geode LX800 (si mes souvenirs ne me trahissent pas) qui ne consomment rien et ne chauffent pas. Ce qui compte pour la consu cpu de la machine ce n'est pas le débit ou les trames traités, mais le nombre de requetes. Une fois les headers traités, haproxy ne fait que transférer les datas, ceci ne consomme quasiment pas de CPU. lors des bench, on sature le CPU avec des requetes sur des fichiers de tailles nulle, et on sature les liens reseaux avec des requetes vers des fichier de grandes taille.

pour le nombre de sessions simultanées, tout depend de la ram disponible, il faut rechercher les chiffres exacts, mais il faut compter environs 26ko de ram par session (de manièere sure, mais il me semble que c'est moins que ça) donc avec 1Go, on tiens 40000 sessions simultanées.

concernant l'option "nbproc 2" elle n'est pas forcement interressante, pour en etre sur, l'idéal est de proceder a des tests de perfs. Il parait logiqe que si l'on met deux process l
es deux cpu seront utilisés et si l'on met n process, les n processeurs seront utilisés. seulement, généralement, il n'y a qu'un processeur qui reçoit les interruptions de(s) la carte(s) réseau. Les processeurs passent donc leur temps a se synchroniser et a s'interrompre mutuellement pour echanger des infos (l'explication est grossière, malheureusement, je ne me rapelle plus des détails mais seulement des conclusions). une chose est sure: utiliser deux process ne multiplie pas les perfs par deux, loin de là. Une autre remarque a ce sujet, s
i vous avez des processeur intel hyperthreading, il faut desactivier l'hyperthreading, les prefs sont moindres avec ce système;

La remarque concernant la repartition de charge en fonction de la source est tout a fait juste à un seule condition, les clients doivent provenir de reseaux ip vastes, dans des cas particuliers ou ce serait des proxys d'etreprises qui se connectent (par exemple) il se peut que la repartition soit totalement innégale.

une remarque sur les regex: haproxy sais employer le moteur de regex standard fourni par la libC, et le pcre. Le pcre est bien plus rapide. Il est fortement conseillé de l'utiliser.

Ethaniel
31/08/2008, 03h19
Je rectifi / optimise ton tutot concernant Haproxy

Déja il faut savoir que Haproxy est une solution de cluster la plus simple à mon sens que je connaisse. Le très gros défaut de Haproxy, c'est qu'il fait une répartition en NAT.
Schéma :
client <-> load1 <-> Web1 / Web2 / WebX


Exemple de Requete :
client envoi requete a (->) load1, load1 fait le balancing, -> Web1 (par exemple), Web1 traite la requete et retourne le résultat à load1, puis load1 au client

Vous l'aurez compris, si par exemple load1 débite 20Mbps de trafic, cela signifie que Web1 et Web2 débite également 10Mbps chacun.
Donc conclusion : Haproxy est très bien pour un cluster en "local". Donc à déconseiller sur un réseau type OVH par exemple.

HAProxy nécessite un très petit serveur. Un RPS devrait largement faire l'affaire.
As tu essayé de mettre des fichiers, ou image en DDL ? Tu verras que à haute charge, ton RPS explosera. Je donne a titre d'exemple, un site de 50 000 IPU, avec page avec 10 images de 20ko / page, nécessitera un serveur load1 Core2duo minimum. (Normal, car haproxy se charge de réécrire les trames, + y'a de débits + y'a de trames + y'a de calcul.
D'ou dans la rubrique global, ajouter : nbproc 2
qui permet de déclarer à haproxy que le serveur a 2 processeurs/core. (4 pour un quad etc...)

balance roundrobin
Attention, très dangereu, tout dépend du contexte. le roundrobin fera comme tu l'as dit en effet, mais se basera sur le cookie client. Ainsi si le client a la bonne idée de refuser tout cookie, ton load1 enverra le client aléatoirement X fois (X = nombre de pages vues par client).
Si le/les sites que vous hebergez sont statique, sans sessions par exemple, alors c'est conseillé. Sinon : balance source

Enfin, il faut savoir que la fonctionphp $REMOTE_ADDR donnera l'adresse de load1, et non celui du client. Pour remédier à cela, 2 solutions :
- Utiliser HTTP_X_FORWARDED_FOR (pas top si c'est pour de l'hebergement mutualisé client)
- Installer sur chaque serveur Apache le mod_rpaf

server serv2 2.2.2.2:80 cookie n1 check inter 2000 fall 3 : On défini un serveur. On lui donne un nom. On défini son IP, son port. On le numérote (n1). On le vérifie (check). ??? (inter). Le nombre maximum de connection sur ce serveur (A ajuster en fonction de la puissance en cas de serveurs différents.). 3 tentatives avant de le déclarer down (fall 3) à vérifier.
Il est possible de spécifier l'intervalle (en millisecondes) séparant deux
tests du serveur par le paramètre "inter", le nombre d'échecs acceptés par le
paramètre "fall", et le nombre de succès avant reprise par le paramètre "rise".

Meskalyn
16/08/2008, 22h39
Petit rajout pour une protection "assez simpliste" contre les injections et le XSS :

Dans
Code:
listen	OVH 1.1.1.1:80
vous pouvez rajouter
Code:
reqideny        ^[^:\ ]*\ .*script
reqideny        ^[^:\ ]*\ .*phpmyadmin
reqideny        ^[^:\ ]*\ .*union
Ce ne sont que des exemples, mais cela pourra éviter pas mal de tentatives d'injections....

Geoffroy
29/07/2008, 03h59
Citation Envoyé par Meskalyn
Gentoo (à vérifier)
Code:
emerge haproxy
Confirmé, à quelques nuances près:
- haproxy est bien dans Portage, mais archtildé (marqué ~arch). Donc pour tous les systèmes en "arch", il faut le démasquer avant de l'emerger. /etc/portage/package.keywords est là pour ça.
Code:
echo "net-proxy/haproxy" >> /etc/portage/package.keywords
* net-proxy/haproxy
Available versions: (~)1.3.14.4 (~)1.3.14.5 (~)1.3.14.6 (~)1.3.15 (~)1.3.15.1 (~)1.3.15.2 {pcre}
Homepage: http://haproxy.1wt.eu
Description: A TCP/HTTP reverse proxy for high availability environments
- Apparemment, le fichier de configuration d'haproxy est /etc/haproxy.cfg sous Gentoo
Extrait du postinst de l'ebuild :
pkg_postinst() {
if [[ ! -f "${ROOT}/etc/haproxy.cfg" ]] ; then
einfo "You need to create /etc/haproxy.cfg before you start haproxy service."
....

Meskalyn
29/07/2008, 02h36
Le but de ce How To est de vous permettre l'installation d'un serveur HA Proxy, permettant de faire du load balancing (http dans ce tuto, mais HAProxy permet aussi de faire ça pour les emails).

Pré requis :
Vous devez avoir au moins 2 serveurs dédiés, mais 3 pour que ce soit réaliste.

Infos pour le tuto:
Code:
Serveur 1 : IP: 1.1.1.1 Hostname serv1.ovh.com
Serveur 2 : IP: 2.2.2.2 Hostname serv2.ovh.com
Serveur 3 : IP: 3.3.3.3 Hostname serv3.ovh.com
Le serveur 1 sera le load balanceur, les deux autres serveurs seront les serveurs Web.

Le nom de domaine devant être load balancé doit pointé vers le load balanceur.

HAProxy nécessite un très petit serveur. Un RPS devrait largement faire l'affaire.


Installation :
Debian
Code:
apt-get update && apt-get upgrade && apt-get dist-upgrade
apt-get install haproxy
FreeBSD
Code:
portsnap fetch && portsnap extract && portsnap update
cd /usr/ports/net/haproxy/
make install clean
Gentoo (cf ci-dessous post de Geoffroy [Merci])
Code:
emerge haproxy
Configuration :
Nous allons maintenant configurer le HA Proxy (serv1) en mode round robin.
Les utilisateurs tomberont de façon aléatoire afin d'équilibrer les deux serveurs Web (serv2 et serv3).

Votre nom de domaine devant être load balancé pointe vers serv1.ovh.com, rendez vous dans le répertoire de HAProxy (/etc/haproxy/)
Code:
cd /etc/haproxy/ #Ce chemin peut différer en fonction des distributions.
nano haproxy.conf
Fichier de configuration haproxy.conf

Partie 1 : Global
Code:
global
	log 127.0.0.1	local0
	log 127.0.0.1	local1 notice
	#log loghost	local0 info
	maxconn 4096
	chroot /usr/share/haproxy
	uid 99
	gid 99
	daemon
	#debug
	#quiet
On défini le nombre maximum de connection (4096) global pour le load balanceur. Nous pourrons par la suite définir domaine par domaine.

Partie 2 : Defaults
Code:
defaults
	log	global
	mode	http
	option	httplog
	option	dontlognull
	option 	redispatch
	option	forwardfor
	option  httpclose
	retries	3
	maxconn	2000
	contimeout	5000
	clitimeout	50000
	srvtimeout	50000
	stats enable
	stats realm HA\ Proxy\ Pass\ zone
	stats auth login:mot_de_passe_en_clair
	stats uri /haproxy?stats
On défini ici le nombre de tentative avant de déclarer l'un des deux serveurs Web HS (3).
On active les statistiques, elles seront disponibles sur votre www /haproxy?stats avec le login et le mot de passe défini en clair.

Partie 3 : Health
Code:
listen	health 0.0.0.0:31300
	mode	health
	option  httpchk
	clitimeout	1500
	srvtimeout	1500
	maxconn 6000
	grace 0
Il me semble que cette section permet de load balancer les load balanceur (du fait de mon budget je n'ai jamais eu à m'en servir). Peut-être qu'un membre du forum pourra apporter des précisions.

Partie 4 : Serveur Web
Il s'agit de la configuration de vos serveurs Web se trouvant dérrière le load balanceur.
Code:
listen	OVH 1.1.1.1:80
	bind	1.1.1.1:80
	option	httpchk
	mode	http
        contimeout      180000
        clitimeout      180000
        srvtimeout      180000
        retries 5
	maxconn 4000
	balance roundrobin
	cookie  SERVERID rewrite
	rsprep	^Server.* Server:\ Lighttpd
	server serv2 2.2.2.2:80 cookie n1 check inter 2000 fall 3
	server serv3 3.3.3.3:80 cookie n2 check inter 2000 fall 3
        capture cookie vgnvisitor= len 32
Le serveur HA Proxy écoute l'IP 1.1.1.1 sur le port 80. La vérification se passe par httpchk (vérification par http)
Exemple de Logs du serv2:
Code:
1.1.1.1 - - [29/Jul/2008:02:28:32 +0200] "OPTIONS / HTTP/1.0" 200 0 "-" "-"
1.1.1.1 - - [29/Jul/2008:02:28:34 +0200] "OPTIONS / HTTP/1.0" 200 0 "-" "-"
1.1.1.1 - - [29/Jul/2008:02:28:36 +0200] "OPTIONS / HTTP/1.0" 200 0 "-" "-"
retries 5 : 5 tentatives sont nécessaires avant de déclarer un serveur down.

maxconn 4000 : Le nombre maximum de connection sur le HAProxy pour ce load balancing

balance roundrobin : On équilibre les sessions en fonction du nombre (25 sessions sur chaque serveur web par exemple)

cookie SERVERID rewrite : On réécrit le cookie afin de ne pas afficher les noms des serveurs dérrière le load balanceur.

rsprep ^Server.* Server:\ Lighttpd : ???

server serv2 2.2.2.2:80 cookie n1 check inter 2000 fall 3 : On défini un serveur. On lui donne un nom. On défini son IP, son port. On le numérote (n1). On le vérifie (check). ??? (inter). Le nombre maximum de connection sur ce serveur (A ajuster en fonction de la puissance en cas de serveurs différents.). 3 tentatives avant de le déclarer down (fall 3) à vérifier.

capture cookie vgnvisitor= len 32 : On essaye de dispatcher le visiteur en fonction de ses cookies (pas sûr que cela fonctionne, pas d'utilisation de cookie dans mon cas.).

Configuration des serveurs web :
Le plus simple reste à faire, vous devez aller sur vos deux serveurs web (serv2 et serv3) et les configurer normalement pour recevoir des requetes pour serv1.ovh.com. En écoutant leur propre IP 2.2.2.2 et 3.3.3.3 pour le vhost serv1.ovh.com (si c'est ce domaine que vous souhaitez load balancer).


Site officiel : http://haproxy.1wt.eu/
Aide FR : http://haproxy.1wt.eu/download/1.3/doc/haproxy-fr.txt

Documentation globale : http://haproxy.1wt.eu/#docs

Ce tuto n'a pas vocation à être complet, n'hésitez pas à faire des tests par vous même.

Si vous avez un serveur SQL qui ne sert qu'à ça, vous pouvez configurer HAProxy pour qu'il load balance sur un seul serveur Web, et configurer votre serveur SQL en serveur de backup http.

S'il y a des détails que vous pouvez clarifier, rectifier, n'hésitez pas. Si vous ne comprenez pas certains points, n'hésitez pas.