Entretien avec Willy Tarreau

Dans le cadre des entretiens de LinuxFr.org, nous avons contacté Willy Tarreau pour un entretien. Il a eu la gentillesse de répondre aux 10 questions que nous avions sélectionnées parmi les propositions des lecteurs de LinuxFr.org.

Vous pouvez lire cet entretien dans la seconde partie de cette dépêche. Il est placé sous triple licence : GNU Free Documentation License (sans section invariante), Art Libre et Creative Commons By-Sa.

Pour ceux qui ne le connaissent pas, rappelons que Willy Tarreau est un contributeur de longue date du noyau Linux. Sa branche hotfix a connu un certain succès et depuis 2005, il est le mainteneur officiel de la branche 2.4 du noyau Linux. Il participe également au développement de la branche 2.6.

En dehors du noyau Linux, il est le développeur du répartiteur de charge HAProxy, a écrit un certain nombre d'outils pour faire des tests d'injection réseau et a créé sa distribution, Formilux, avec un ami.
Sur le noyau Linux

1. DLFP : Comment es-tu devenu développeur noyau ?

Willy Tarreau : Oh c'est une bien longue histoire. Quand j'étais gamin, mon outil préféré était DEBUG, l'outil DOS permettant d'assembler/désassembler et bricoler les I/O de mon PC. Je m'étais même fait un BIOS compatible PC pour une machine à base de 8088 qui ne l'était pas, ce qui m'a permis de la faire démarrer sous DOS. Bref, lorsque j'ai découvert Linux en 1994, tout ceci m'a beaucoup manqué. Linux fonctionnant en mode protégé, il n'était plus possible de faire n'importe quoi comme sous DOS et j'étais perdu. Un jour un copain m'a dit que j'avais les sources de mon noyau et que je pouvais même le recompiler. Ça me faisait bien peur mais j'ai fini par essayer. Je n'y comprenais vraiment pas grand chose au début, mais assez rapidement j'ai pu trouver mes marques (faut dire que le noyau 1.0 n'était pas très gros). Mes modifications étaient toujours en relation avec le matériel : un correctif pour faire du branchement à chaud en IDE, un pilote pour lire la température de ma carte mère, etc. Un peu plus tard, j'avais réécrit le code d'identification du processeur, qui ne détectait pas correctement mon processeur Cyrix. Je l'avais envoyé à Linus qui m'avait demandé de le refaire en C (ce n'était que de l'assembleur non maintenable), ce que je fis, et il l'avait aussitôt intégré. Et là j'ai réalisé à quel point le développement de ce système était ouvert, et qu'il était facile d'y participer. Une semaine après il a remplacé mon code par celui d'un autre, et j'ai compris qu'il ne fallait pas bosser dans son coin isolé mais rester toujours un peu informé de ce qui se faisait. Donc je me suis abonné à la liste de diffusion linux-kernel, je me suis intéressé à ce que je voyais passer. Je me suis fait des noyaux 2.0, 2.1 puis 2.2 plein de fonctionnalités additionnelles et de temps en temps je remontais un correctif ou deux. Plus tard, j'ai commencé à maintenir mes propres noyaux 2.4 et à envoyer de temps en temps des correctifs au mainteneur, Marcelo Tosatti. Puis comme il n'y avait qu'une branche 2.4 à l'époque, elle contenait à la fois des nouveautés qui ne marchaient pas toujours très bien, et des correctifs. À force de perdre du temps à faire le tri dans les correctifs, j'ai fini par créer une branche "hotfix" (2.4-hf) qui nous a fait gagner du temps à Marcelo et moi. Lui se préoccupait moins d'avoir des pre-publications stables, et moi je ne prenais plus que ses correctifs. Je lui renvoyais mes compilations de correctifs par petits lots lorsque son code s'était stabilisé et ça nous allait bien.

Un jour de Novembre 2005, Marcelo m'a proposé de me passer le flambeau progressivement. Au début ça m'a fait vraiment peur : cruel manque de compétence et de temps ! Je n'avais pas trop l'habitude de me planter et là j'avais l'impression d'y aller tout droit. Mais Marcelo a su être rassurant et surtout me donner plein de tuyaux, des scripts, m'expliquer l'outil de gestion de configuration GIT, qui n'existait que depuis 6 mois et que je n'arrivais pas à utiliser. Au final, je lui ai demandé du temps pour apprendre, et je suis progressivement monté en charge sur le 2.4.33, je lui envoyais les correctifs que je collectais, puis je tentais de les fusionner moi-même et de les lui renvoyer. Bon ça n'a pas été terrible au début, mais lorsque le 2.4.33 est sorti 8 mois plus tard, j'étais à peu près opérationnel. Au début je n'en menais pas large, j'avais toujours peur de tout casser par accident (notamment les dépôts sur kernel.org) et j'avais du mal à m'adapter aux habitudes très diverses des mainteneurs des différents sous-systèmes. Après m'être fait gronder 2 ou 3 fois par Alan Cox, j'ai compris qu'il surveillait du coin de l'œil et qu'il me servait de garde-fou. Je me suis donc un peu plus lâché. Une fois "mon" 2.4.34 sorti, ça allait beaucoup mieux, j'avais pu réaliser un cycle complet tout seul comme les grands :-)


2. DLFP : Quelles sont les évolutions qui tu aimerais y voir (ou y apporter) ?

Willy Tarreau : Au risque de faire dresser les cheveux sur la tête à certains, j'aimerais bien qu'on puisse faciliter le chargement de pilotes plus génériques, qu'ils soient propriétaires ou non. J'ai toujours été convaincu qu'il ne fallait pas aller à l'encontre des croyances des gens, et tenter de faire admettre aux constructeurs de matériel que c'est leur intérêt de faire de l'open-source, c'est une perte de temps. Il faut qu'ils y trouvent leur avantage eux-mêmes. Aujourd'hui, ce qui me désole, c'est que lorsque vous regardez l'emballage de n'importe quel composant connectable à un PC, vous voyez qu'il fournit un pilote pour toutes les versions de Windows, et de plus en plus souvent pour MacOSX. Et Linux ? très rarement… Mais soyons réalistes : on fait tout pour compliquer la distribution de pilotes par les constructeurs. L'API du noyau change sans cesse et le constructeur ne peut pas se contenter de payer un jeune à lui développer un pilote, il doit avoir cette personne à demeure pour assurer toutes les évolutions. On leur suggère de soumettre leur code pour l'intégrer dans le noyau officiel, mais très souvent on le rejette car c'est trop tôt, c'est trop tard, ce n'est pas beau, ce n'est pas comme ça qu'il fallait faire, ou bien il faut le refaire car le noyau a changé depuis. Jamais on ne pense que l'auteur du pilote a sans doute eu une mission de courte durée pour écrire ce pilote et qu'il n'y aura pas de nouvelle soumission. Le code est alors condamné à mourir de son côté. Et diffuser un pilote sous forme de sources pose des problèmes aux utilisateurs (tout le monde ne sait pas compiler un pilote pour son noyau). Sans compter que ce n'est pas compatible avec l'utilisation sur des machines en cours d'installation… Et qu'on ne me dise plus que les constructeurs se réveilleront lorsque Linux fera plus de parts de marché. Ils ont bien su se réveiller lorsque MacOSX en était au dixième des parts de Linux !

Le premier pas qui me semblerait positif, c'est le support du protocole Multiboot. Il permettrait de pré-charger des modules depuis Grub. C'est essentiel pour installer des machines récentes sur lesquelles les contrôleurs SCSI, SATA, RAID… ne sont pas reconnus par le disque de la distribution souhaitée. Avec ça on pourrait apporter le pilote sur disquette, clé USB ou autre et le pré-charger depuis Grub. Il y apparemment tout dans le noyau pour faire ça, mais il faut encore regarder. Et il faudrait aussi que ce soit accepté. Quand je vois comment certains se sont battus pour empêcher d'inclure les microgiciels dans les modules en restant sourds à tous les cas de problèmes que ça allait poser, des fois j'ai des doutes sur l'opportunité de travailler sur une telle fonctionnalité.


3. DLFP : Quel est ton avis de manière générale sur la branche 2.6 du noyau ?

Willy Tarreau : Linus a trouvé la recette miracle pour satisfaire tout le monde. Les développeurs participent beaucoup, mais ils passent plus de temps à créer qu'à corriger et stabiliser. Quand je dis "ils", je généralise, car il y a toujours des exceptions. Ils ont dans les mains un outil fantastique leur permettant de mettre leur créativité à profit en s'appuyant sur des mécanismes complexes déjà disponibles, mais ils oublient souvent qu'il y a de vrais utilisateurs derrière qui vont s'en servir en toute confiance… Je pense d'ailleurs que la source de ce problème vient du fait que beaucoup de développeurs n'ont jamais travaillé sur le terrain. Ils croient qu'on peut mettre à jour un serveur comme son poste de travail, sans aucune planification, et ne comprennent pas du tout qu'on ne puisse pas redémarrer une machine pendant trois mois lorsqu'ils demandent de tester des correctifs au hasard. J'ai mis des machines en production il y a plus de 5 ans qui n'ont subi qu'une mise à jour et redémarré seulement deux fois (mais il faut voir que c'est très difficile d'intervenir dessus). Comment je fais ça avec un 2.6 ?

Linus suggère de s'appuyer sur les noyaux des distributions. C'est bien gentil, mais je suis loin d'être convaincu que celles-ci seront beaucoup plus stables vu que leurs mainteneurs sont les mêmes que ceux qui font la branche officielle. La branche -stable de Greg & Chris était absolument nécessaire et elle fonctionne plutôt bien. Je leur tire mon chapeau car je sais le travail que cela représente. Dans la pratique, il est souhaitable de rester sur la dernière stable de la version N–1, afin de laisser le temps à la suivante de mûrir. D'ailleurs c'est vraiment bien que Greg ait accepté de gérer deux versions pendant une période de recouvrement. Mais même avec ça, quand on voit le nombre de correctifs qui sont intégrés à chaque version, je ne suis pas surpris que des gens me demandent toujours du 2.4 pour des systèmes destinés à partir sur le terrain sans possibilité de mise à jour.


4. DLFP : Comment ta participation au noyau entre-t-elle en relation avec ton travail ?

Willy Tarreau : Chez Exosec, nous installons des sondes chez nos clients pour pouvoir les superviser à distance et parfois prendre la main sur leurs équipements afin de régler des problèmes rapidement. Il ne serait pas concevable de passer notre temps à mettre tout le parc à jour toutes les semaines, sans compter les impacts sur la disponibilité générale des systèmes. Nos sondes tournent sous Linux avec notre distribution réduite Formilux qui fait une dizaine de Mo. Dans ces conditions-là, il est tout à fait indiqué d'installer un noyau 2.4 durci (PaX…) et de ne mettre à jour qu'en cas de réel besoin. Il n'est pas rare d'avoir des uptimes dépassant un an lorsque les sondes sont en salle machine.

En parallèle, nous avons aussi une activité de fabrication de répartiteurs de charge (ALOHA). Cette plate-forme évolue plus vite que la première puisque les besoins des clients évoluent. Mais là nous devons absolument fournir du code robuste car nous n'avons plus la main sur l'équipement une fois vendu, et le client est libre de télécharger les mises à jour ou pas. Nous ne pouvons bien entendu pas leur demander de mettre à jour tous les 6 mois, ils en auraient vite ras le bol. Donc là aussi on passe du temps à durcir des noyaux et à corriger des bogues rencontrés sur le terrain. Dernièrement par exemple, j'ai passé deux jours à déboguer le pilote réseau via-rhine pour des problèmes de négociation incorrecte. Le correctif est maintenant en 2.4.37-rc1. Dans le même style, il y a 5 ans, en intégrant un pare-feu pour un client, j'ai été amené à retravailler le window-tracking TCP de Netfilter qui était trop strict. Après quelques semaines de corrections, de mesures et d'échanges avec l'auteur, on a pu diviser le taux de drops par 10 et régler un problème de sécurité découvert dans le code. Et c'est cette refonte qui fut finalement intégrée en 2.6.

Donc au final, le noyau est un composant comme les autres pour mon travail. Lorsqu'un défaut est trouvé, nous le corrigeons et réintégrons le correctif dans la branche principale, ne serait-ce que pour ne plus avoir à penser à le répercuter partout. Je pense que beaucoup de sociétés procèdent de cette façon, même si ce n'est malheureusement pas le cas pour toutes.


5. DLFP : Est-ce que tu t'es intéressé au développement d'autres noyaux (Hurd, BSD, multidesk os) ?

Willy Tarreau : Non pas beaucoup. La curiosité m'a conduit à regarder un peu les noyaux miniatures pour micro-contrôleurs pour voir ce que des gens sont capables de faire avec si peu de ressources. Mais c'est tout.


Sur le répartiteur de charge HAProxy

6. DLFP : Est-ce que HAProxy a un rôle à jouer dans les architectures des sites web 2.0 ? Si oui, lequel et quels sont ses avantages par rapport aux autres solutions de load-balancing ?

Willy Tarreau : Aujourd'hui, je constate que les gens vont au-delà du load-balancing, ils veulent aussi un traitement spécifique en fonction du contenu, ce que l'on appelle du "content-switching". HAProxy leur permet de choisir les composants avec une plus grande flexibilité, dans la mesure où il devient facile d'utiliser Lighttpd pour les contenus statiques par exemple, tout en traitant certaines parties dynamiques en PHP, Java, Ruby ou autre sur des fermes de serveurs dédiées. HAProxy n'est pas encore ce qu'on fait de mieux pour traiter de l'AJAX, car par défaut il ignore le keep-alive, ce qui peut avoir tendance à augmenter un peu les temps de réponse sur ce type de technologie. En revanche, cela soulage les serveurs, et surtout à ce jour c'est le seul à pouvoir gérer une file d'attente pour sérialiser les requêtes vers les serveurs, ce qui en optimise les ressources et les protège contre des dénis de service triviaux. C'est d'ailleurs la raison pour laquelle il est très souvent utilisé avec Mongrel, qui ne supporte qu'une connexion à la fois par instance. Il convient de comparer objectivement HAProxy avec ce qui existe :

• LVS ne fait pas de niveau 7 donc pas d'aiguillage sur le contenu. Par contre, c'est un excellent load-balancer de niveau 3 à utiliser en complément de HAProxy.
  
• nginx est rapide et évolue vite mais n'est pas aussi riche que HAProxy en load-balancing. Aux dernières nouvelles, il ne supportait pas non plus le keep-alive. C'est un produit à surveiller.
  
• le load-balancing d'apache est une véritable farce : il ne fait pas de tests de bonne santé des serveurs ("health-checks"), donc il peut envoyer des requêtes vers des serveurs en panne ! Et à ma connaissance, il ne permet pas de fixer un poids à chaque serveur.
  
• pound fait tout (y compris le keep-alive), mais son modèle threadé le limite quand même aux sites de taille moyenne. Je le recommande toutefois aux gens qui veulent se lancer avec des petits besoins et qui ne savent pas vraiment comment s'y prendre, parce que c'est assez facile.
  

Tous ces produits ont leur place et leur usage, mais au final HAProxy ne se débrouille plutôt pas mal au milieu de ce lot, si l'on en juge par les retours d'expérience de plus en plus fréquents postés sous forme d'articles sur des blogs, parfois chiffres à l'appui. J'essaierai d'implémenter le keep-alive pour la version 1.3.17 une fois la ré-architecture de la 1.3.16 finie, et j'ai un collègue qui se bat avec différentes bibliothèques SSL pour voir si on finira par arriver un jour à en faire quelque chose ou non.

7. DLFP : Quels sont les utilisateurs d'HAProxy les plus connus ? Contribuent-ils à HAProxy sous quelque forme que ce soit : don de matériel, correctifs, retours d'expérience, publicité, autres ?

Willy Tarreau : Je vais décevoir beaucoup de lecteurs, mais la quasi-totalité des utilisateurs ne souhaite pas que ce type d'information soit publiée. Je pense que cela tient au fait que, tout comme le pare-feu, c'est un organe de sécurité sensible dans leur infrastructure, et qu'ils pensent la fragiliser en en dévoilant les composants. Mais bon, je peux donner des éléments tout de même, et si certains se reconnaissent et souhaitent se manifester, je les invite à le faire eux-mêmes :

• un gros fournisseur de services internet français en fait un usage assez conséquent (multi-gigabit). J'aime bien échanger avec ces personnes sur les aspects personnalisation système et optimisation du code. Les fournisseurs de services ont tendance à être assez transparents sur leur usage, leurs configurations, leurs soucis, etc. Du coup, on peut travailler ensemble sur les configurations et voir comment améliorer le produit. Ils acceptent volontiers de tester de nouvelles versions ou de nouveaux paramètres pour voir si les changements attendus sont bien au rendez-vous. Ils contribuent même du code quand ils arrivent à en trouver le temps.
  
• au moins deux grands comptes français dans le secteur banque/finance l'utilisent beaucoup en complément d'autres solutions. Pour donner une idée de ce qu'on peut rencontrer dans ce secteur, le nombre d'instances configurées se compte en milliers réparties sur plusieurs sites. Les grands comptes contribuent essentiellement du temps, ça leur permet aussi de ne pas être identifiés, ce qui est une volonté assez forte. Peut-être qu'un jour ça changera et que je pourrai inclure dans mes commits "développement sponsorisé par X ou Y". Quand ce sont des clients d'EXOSEC, je peux y aller en prestation et une partie de mon travail consiste alors à développer des fonctionnalités dont ils ont besoin. La gestion des poids dynamiques a été développée comme ça en quelques semaines. En contre-partie, ces grosses boîtes y trouvent l'avantage d'un produit répondant exactement à leurs attentes, et pour un coût et un délai très inférieurs à ce qu'il faudrait juste pour valider une nouvelle version d'un produit déjà en place. C'est quelque chose qui est totalement hors de la portée des gros éditeurs, et les grands comptes français en sont maintenant parfaitement conscients.
  
• Nokia l'utilise en interne depuis assez longtemps aux États-Unis d'Amérique. Ils ont des besoins très spécifiques et difficiles à satisfaire, mais sont capables de définir leur périmètre d'utilisation avec une très grande précision, ce qui fait qu'on arrive généralement à une solution assez générique répondant entre autres à leur besoin. Ils ont contribué du code et beaucoup de temps de tests. Les gars là-bas ont d'ailleurs travaillé avec une rigueur assez rare de nos jours, citant ça-et-là des extraits de la RFC pour documenter leur code. Il ne faut surtout pas qu'ils se privent de recommencer :-)
  
• un opérateur français de téléphonie mobile l'a utilisé pendant longtemps en remplacement d'une solution matérielle qui atteignait ses limites (un comble tout de même). D'ailleurs HAProxy arrive souvent comme ça dans les grosses sociétés : en sauvetage d'un composant qui lâche alors qu'on ne s'y attendait pas du tout. Et dès que le site est réparé, plus personne n'ose y toucher.
  
• plusieurs gros sites de téléchargement et de publications de photos/vidéos sur Internet l'utilisent. Les débits ici se comptent en téraoctets par jour sur chacun des sites, les plus gros saturant du gigabit pendant plusieurs heures par jour. C'est très impressionnant. Certains parfois demandent de l'assistance en optimisation et paient pour ça.
  
• et puis il reste les produits qui l'embarquent : notre load-balancer ALOHA bien sûr (dont certaines fonctionnalités sont ensuite réintégrées dans HAProxy), puis les produits de Loadbalancer.org et Barracuda, qui par contre ne contribuent pas de code, étant surtout des intégrateurs. Il m'arrive occasionnellement de dépanner ces éditeurs sur des problématiques d'intégration, personnalisation, etc., alors qu'ils pourraient être considérés comme concurrents directs de notre solution. Mais c'est justement dans ces cas-là qu'on peut mesurer notre avance. Le fait de créer des fonctionnalités et de contribuer du code nous donne toujours une longueur d'avance sur ceux qui tenteront plus tard de l'utiliser. C'est pour ça que le modèle open-source est viable même dans ce domaine concurrentiel.
  

Enfin, d'autres me contactent lorsqu'ils se font attaquer, et on peut alors faire des expérimentations de contres-mesures en direct. Là c'est très instructif. Le "tarpit" a été développé comme ça un soir, et a permis de stopper une attaque d'environ 7000 machines en quelques minutes. Ça fait plaisir :-)


Sur sa vie personnelle et ses motivations

8. DLFP : Qu'est-ce qui te plaît le plus dans le développement ?

Willy Tarreau : D'abord, me creuser la tête à résoudre des problèmes difficiles, comme créer des arbres 10 fois plus rapides que les rbtree, ou des parseurs capables de comprendre du texte à la vitesse du fil (logs, protocoles…). D'une certaine manière, ça consiste à repousser des limites. Mais s'il n'y a pas d'application directe, alors je reste un peu sur ma faim. Donc il faut que ça serve à quelque chose, et ça c'est le deuxième point important. Je suis ravi lorsque des gens me disent qu'ils ont remplacé leur load-balancer matériel saturé par un petit ordinateur avec HAProxy et que celui-ci se la coule douce. Si mon logiciel est plus rapide que certains matériels, c'est que mes algorithmes ne sont pas si mauvais ! Quand un gars stoppe un DDoS massif et qu'on peut compter le nombre d'attaquants dans la page de statistiques de HAProxy au nombre de sessions actives, c'est assez plaisant également car on sait que le code est mis à rude épreuve et qu'il tient bon. Et quand un type m'explique qu'il fabrique des terminaux pour diffuser des informations dans les gares, pré-installés en noyau 2.4 parce que comme ça il n'aura jamais à le mettre à jour dans la vie de la machine, et bien ça fait plaisir aussi. Je pense que c'est cette quête perpétuelle de fiabilité absolue et de performance qui me donne envie d'avancer dans ce domaine.


9. DLFP : Y a-t-il une vie après le noyau ?

Willy Tarreau : Le noyau ne me prend pas tant de temps que ça. J'ai tendance à accumuler les correctifs en retard, et quand j'en ai vraiment trop honte, j'essaie de trouver un moment pour faire une publication, et après je me sens soulagé. Le problème avec le noyau est plus d'arriver à trouver des créneaux de longue concentration pour bosser dessus. Par exemple, pour le 2.4.37-rc1, il m'a fallu un week-end entier de compilations, correctifs, tests de compatibilité de matériels… Ça c'est du temps difficile à trouver.


10. DLFP : Quelle est la vie d'un hacker comme toi ?

Willy Tarreau : Celle d'un hacker, je ne sais pas, mais la mienne est somme toute assez simplifiée. Déjà, j'évite de perdre mon temps. Je n'ai pas de télé, je déteste ça, ça vous garde captif et ça rend débile. Je suis sûr que ceux qui n'en ont pas non plus partagent ce sentiment lorsqu'ils entendent leurs collègues raconter les stupidités affligeantes dont ils se sont délectés la veille. :-)

Je ne vais pas non plus au cinéma, je n'aime pas ça. C'est bruyant, on vous gave de publicités pendant 20 minutes et quand ça se décide enfin à commencer, il ne faut pas plus de 5 minutes pour découvrir des scénarios creux pas du tout crédibles et des bogues partout. Des copains ont bien déjà essayé de me réconcilier avec, mais finalement ils ont abandonné après avoir été saoulés de mes commentaires en direct.

Je ne voyage pas non plus, je n'aime pas m'éloigner de chez moi, et en plus, partout où je vais il y a des gens et je n'aime pas ça non plus. Donc au final, il me reste du temps pour faire d'autres choses :-)

Je passe beaucoup de temps au boulot, je pars tôt le matin et rentre assez tard le soir. Le matin avant de partir, j'évacue des mails pendant une heure environ, et je tâche de parcourir rapidement les nouvelles sur la liste de diffusion linux-kernel. Quand je rentre, j'ai environ 3h de mails à traiter (avant il y en avait plus, mais le fait d'avoir créé la liste haproxy a permis aux participants de me délester en répondant eux-mêmes aux questions des autres ; ce fut une grande avancée). Et après ça, il est rare que je trouve encore l'énergie pour me mettre au code, donc généralement je vais me coucher. Quand j'ai vraiment des trucs à déboguer, alors je laisse traîner mes mails toute la semaine pour gagner du temps, et là j'arrive à avancer.

Sinon c'est le week-end que je réserve à mes créations et à la maintenance du noyau. Mais bon, des fois j'ai ma dose alors je passe à des sujets différents comme le paquetage de Formilux, de la recherche sur certains algorithmes qui pourraient m'être utiles, ou même parfois des montages électroniques. Et puis aussi la sieste pour récupérer le manque de sommeil de la semaine :-)

Au final, ce qui semble marcher le mieux, c'est encore de prendre des vacances en ne répondant pas aux mails. La dernière fois, en une semaine j'ai pu bien avancer. Je pense d'ailleurs que je vais réitérer, j'ai du code qui n'a pas avancé depuis une semaine ;-)

Aller plus loin

• Les propositions d'entretiens (21 clics)
• HAProxy, le répartiteur de charge fiable et performant (56 clics)
• Page perso de Willy Tarreau (112 clics)