Pour ceux d'entre vous qui souhaiteraient en savoir plus, je vous conseille l'article intitulé Making applications scalable with Load Balancing. Cette introduction aux techniques de répartition de charge a été écrite par Willy Tarreau, qui n'est autre que le mainteneur officiel du noyau Linux 2.4 et l'auteur de HAProxy.
Si après la théorie, vous souhaitez passer à la pratique, HAProxy est particulièrement recommandé : c'est un répartiteur de charge logiciel sous licence GPLv2.
HAProxy est une solution libre, fiable et très performante de répartition de charge de niveau 4 (TCP) et 7 (HTTP). Elle est particulièrement adaptée aux sites web fortement chargés qui nécessitent de la persistance ou du traitement au niveau 7.
La fiabilité est l'un, sinon le point fort d'HAProxy. Il est par exemple utilisé par des sociétés apparaissant au classement Fortune 500 pour servir des millions de pages chaque jour.
Cette fiabilité ne s'est pas faite au détriment des performances : HAProxy requiert peu de ressources, et son architecture évènementielle mono-processus lui permet facilement de gérer plusieurs milliers de connexions simultanées sur plusieurs relais sans effondrer le système.
Enfin, la sécurité est au rendez-vous : pas une seule vulnérabilité en 4 ans. De plus, HAProxy est capable de se chrooter et de diminuer ses privilèges au lancement.
Aller plus loin
- HAProxy (1384 clics)
- L'article de Willy Tarreau (1002 clics)
# Varnish
Posté par Maxime Ritter (site web personnel) . Évalué à 4.
Par contre puisqu'on parle (entre autres) de clusters de serveurs webs, en matière de reverse-proxy, il y a un projet très récent et intéressant à suivre par là : http://varnish.projects.linpro.no/
# 128kbs d'uplink....
Posté par cedric . Évalué à 4.
moins pire que slashdotté, mais 128k ca fait pas beaucoup meme pour de l'adsl ;)
la connection ne sert qu'a mettre a jour les données du proxy mais quand meme.
[^] # Re: 128kbs d'uplink....
Posté par FRLinux (site web personnel) . Évalué à 1.
[^] # Re: 128kbs d'uplink....
Posté par cedric . Évalué à 1.
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . Évalué à 10.
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
Willy
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . Évalué à 2.
s'il y'en a qui veulent de l'info, c'est vachement simple :
- une ligne ADSL 512/128 chez nerim (fiabilité et IPv6)
- un firewall linux/netfilter + quelques règles TC pour calmer un peu le HTTP sortant (limité à 110 kbps) + limitation du MSS TCP à 512 octets pour améliorer la latence d'un facteur 3 (appréciable quand on travaille en SSH à distance). Le temps de ping est monté de 45 à 80-90 ms pendant que les curieux gloutonnaient le site :-)
- un haproxy en DMZ sur un pauvre vieux VAX gonflé à 24 Mo de RAM, et qui doit tourner aux alentours de 30 MHz. Il joue surtout le rôle de régulateur de trafic, car j'en avais marre qu'apache se ramasse à chaque fois que des gens cliquaient sur une image ISO même petite. Là, vous êtes montés en pointe à 38 connexions simultanées seulement, ce qui est très petit sachant que sur des GROS sites, on a déjà atteint les 10000 (mais pas sur le même matériel).
- serveur web apache sur une autre DMZ sur une vieille station PARISC 712/60 (60 MHz), gonflée elle à 96 Mo et en NFSROOT (diskless)
Tout ça, ça plafonne à 5-6 hits/s tout de même ! Mais au moins, ça consomme rien, ça fait pas de bruit et c'est totalement increvable comme matos. Quand ça a déjà tourné 10 ans non stop, ça peut bien encore en faire 10 de plus ! Là, le problème, c'est que mes pages sont lourdes, et l'article est découpé en 10 pages complètes, donc ça fait du volume sur le lien, ce qui rend le site assez lent (enfin, mes stats web haproxy répondent en moins de 5 secondes lors des consultations à distance, donc je ne me plains pas).
Ironie du sort, l'article désigné traitait de la répartition de charge alors dans ce dont on parle là, il n'y en a même pas. Comme quoi il y a bien un gros boulot de tuning avant même de se lancer dans le load balancing !
Voila, comme quoi y'a pas forcément besoin d'un P4/2GHz pour héberger un site en ADSL ;-)
Willy
[^] # Re: 128kbs d'uplink....
Posté par tarreau willy (site web personnel) . Évalué à 4.
willy
[^] # Re: 128kbs d'uplink....
Posté par JereMe . Évalué à 4.
# config maitre / esclave
Posté par oops (site web personnel) . Évalué à 1.
Si oui est-il possible de garder les connections ( VRRP ? ) ?
[^] # Re: config maitre / esclave
Posté par tarreau willy (site web personnel) . Évalué à 4.
Pour la première question, oui on peut faire ça avec du VRRP. Mais si possible, on évite de mettre des disques dans des machines qui assurent ce genre de fonctions lorsqu'elles sont vitales.
Pour la seconde question, oui et non :
- on ne peut pas garder les connexions TCP vu qu'elles sont établies par une machine et que l'autre ne les a pas dans sa table, et ne connait pas les données, les numéros des séquence TCP, tailles de fenêtres, etc...
- par contre, pour la persistance niveau 7, ça ne pose pas de problème lorsqu'on utilise des algorithmes déterministes comme l'insertion de cookie. Les deux répartiteurs ont la même conf, et lorsque le client présente son cookie désignant le serveur 2, les deux comprennent de quel serveur il s'agit.
Sur du HTTP, d'une manière générale, on ne se soucie pas de la reprise de sessions TCP, les sessions sont bien trop éphémères, et leur contenu rejouable, parfois même par le navigateur lui-même. De plus, le surcoût lié à la synchronisation (p.ex sur des firewalls) est énorme sur des sites à fort trafic.
Si vous voulez expérimenter avec le VRRP, je recommande keepalived ( http://www.keepalived.org/ ) (en particulier la version 1.1.13, à laquelle j'ai ajouté des fonctionnalités de tests de process locaux et de priorités flottantes précisément pour mieux le coupler à haproxy). En plus, son auteur (Alex Cassen) est français également, et bien que peu bavard sur son produit, a créé un excellent framework le rendant très extensible.
Willy
# Forte charge
Posté par Frederic Bourgeois (site web personnel) . Évalué à 0.
Tout d'abord merci pour HAProxy c'est vraiment un excellent logiciel.
Dans l'article «sociétés apparaissant au classement Fortune 500 pour servir des millions de pages chaque jour ». Quelqu'un a un exemple plus précis sur ce type d'architecture ? une comparaison avec des switch du genre nortel alteon/passport ? Difficile de se lancer dans un test en situation réelle pour ce genre d'application,
Je serrais aussi particulièrement intéressé par un retour d'expérience sur un pool de proxy squid.
Je cherche pour ma part à utiliser un maximum de logiciel libre pour un très gros réseau.
J'ai déja (modestement je ne suis pas dev) modifié vrrpd pour l'adapter à mes besoins, infos http://www.traceroot.fr.
[^] # Re: Forte charge
Posté par tarreau willy (site web personnel) . Évalué à 3.
Je ne peux bien entendu pas donner de détails et encore moins de noms, mais ce que je peux dire, c'est que c'est rentré sur un très gros site bancaire ainsi qu'un gros opérateur de téléphonie mobile pour sauver dans l'urgence des alteon à l'agonie sur la prod. A chaque fois, l'alteon était configuré pour traiter le niveau 7, et à chaque fois, les symptômes ont été les mêmes : ralentissements sensibles sur l'ensemble des applis, puis impossibilité subite pour les clients d'établir des connexions, retour à la normale après un reboot puis dégradation à nouveau après quelques minutes...
En fait, y'a pas de mystère, si les applis commencent à ramer un peu, le pauvre powerpc de management qui traite également le niveau 7 n'a pas assez de RAM pour stocker les données relatives à toutes les sessions en attente, donc commence à perdre des paquets, aggravant du coup les temps de réponse, d'où l'effet d'avalanche. C'est donc une erreur de l'utiliser pour faire ça, mais il faut se faire piéger en prod pour le comprendre. D'autres constructeurs comme Foundry ont bien compris le problème et séparé très clairement les fonctions L4 (ASIC) et L7 (processeurs monstrueux rackables pour s'adapter au besoin).
Bref, du coup, on racke deux PC 1U pour faire le boulot, et l'alteon se met à bosser en niveau 4 uniquement (c'est l'ASIC qui travaille et ça va vite) et assure ainsi le LB et la HA entre les PC avec des tests simples mais efficaces. Le résultat est surprenant de stabilité et scalabilité, et fournit des infos d'une richesse inégalée auparavant grâce aux logs. Même avec 2 bons vieux AD3 et 2 PC P3 1GHz, on peut assez facilement monter à 8000 hits/s en niveau 7. Avec des AAS 3408 et deux opteron 2.6 GHz, compter environ 30000 hits/s, ce qui est souvent bien au-delà des besoins même pour de très gros sites, même si on divise par deux pour compter avec une panne.
L'autre avantage, c'est que les équipes réseau n'ont plus à se soucier des détails applicatifs, et se content d'affecter et de gérer des adresses et ports, ce qui se rapproche plus de leur métier d'origine que les bricolages de headers HTTP pour faire marcher les applis.
Le dernier schéma d'architecture dans mon article représente en fait une approximation simplifiée à l'extrème (mais fonctionnelle) de ce qu'on fait sur le terrain, en mettant "alteon" à la place de "L4LB". Y'a plus qu'à imaginer la même archi répliquée sur plusieurs étages avec des firewalls à chaque fois entre les étages pour avoir une meilleure idée.
Pour faire des tests sans casser la prod, rien de plus simple : comme ça marche en proxy, on positionne le haproxy à côté des applis, on lui fait sa conf, et au début on teste en se connectant directement sur le haproxy depuis un navigateur. On regarde aussi les logs de l'appli, etc... Une fois que ça fonctionne, on crée un real serveur et une VIP (ou juste un nouveau port) sur l'alteon qui référence le haproxy, et on vérifie depuis un navigateur que la VIP de l'alteon fournit bien le même service. On peut alors tester depuis plusieurs endroits, valider la persistance, l'absence de croisements de sessions, etc... Après, y'a plus qu'à échanger les deux services dans l'alteon (l'ancien et le nouveau) et le tour est joué sans prendre de gros risques avec un retour arrière facile en cas de pépin. Faut quand même faire gaffe au tuning (timeouts, nb sessions, ...) mais ça peut se faire de manière réfléchie et propre. Ensuite, l'alteon qui ne fait plus de niveau 7 va tellement mieux qu'il se découvre une nouvelle jeunesse et peut traiter 5 fois plus d'applis qu'avant !
Mais bon, l'article est avant tout une présentation de principes généraux à respecter, et absolument pas une recommandation pour tel ou tel produit, d'où la raison pour laquelle aucun nom de produit n'est cité. De plus, rien ne dit que pour de nouveaux déploiements avec de nouveaux besoins, les mêmes choix de produits seraient faits.
Willy
[^] # Re: Forte charge
Posté par Frederic Bourgeois (site web personnel) . Évalué à 1.
Il me faudra planifier un test.
# libevent
Posté par herodiade . Évalué à 3.
Cette lib fournis une API unifiée (et portable sous Linux, *BSD, Windows, Mac OS X et Solaris) pour la gestion des évènements, et sait tirer parti de façon transparente de la meilleur API système présente (par ex. epoll sous Linux, kqueue sous *BSD, etc.). C'est très robuste aussi (utilisé par memcached et par les serveurs osfp, ifstated et le proxy ftp d'OpenBSD).
Voilà, ça permet de faire des choses dans l'esprit de HAProxy (je veut dire : pas forcément d'aussi bon logiciels, mais des logiciels utilisant les bonnes API de gestion d'event pour encaisser de grosses charges) sans être un caïd de la prog système :)
Le site de Niels Provos (l'auteur de cette lib) indique aussi un papier très pertinent sur le sujet dont on parle : http://www.kegel.com/c10k.html , qui compare les diverses approches (choix des api d'event et/ou pour les threads, utilisation de sendfile()/zerocopy, ...) pour programmer des serveurs performants et qui tiennent la charge.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.