All posts by wtarreau

Welcome Tim!


I’m realizing that it’s been a while since last post. We’ve been quite busy working on tons of cool stuff that you’ll discover soon and time flies fast.. very fast in fact. In the mean time our team was reinforced with Tim Hinds who will help me animate the blog and communicate on more general subjects than just bits and bytes, so I now have great hopes that many of our regular readers will more naturally share some links without the fear of looking like an alien who reads haproxy directives all the day 🙂

Welcome Tim, it’s really nice to have you on board, and stay tuned!


HAProxy Technologies offers free hardware load balancers to students / interns

How to start with load balancers ?

All of us playing with load balancers started the same way. First you prepare a configuration to alternate between two web servers returning different contents, and you verify with your browser that you indeed get a different response on each reload. This is the most basic load balancing setup one can imagine (and the worst one at the same time). Then you start all these “what if” questions. “What if a server dies”. You manage to address this by enabling health checks., but you feel like you’re cheating when you stop the server by killing the process. “What if now the cable is pulled off while transfering data”. This becomes difficult, you need to start a VM and you’re not completely sure you model the proper failure by stopping the VM, maybe the hypervisor will send some resets or ICMP messages.  Then “What if I the load balancer itself  fails”. Cheating with VMs that are started and stopped by hand doesn’t make you feel comfortable in that what you’re doing will work in real production. “What if someone by mistake configures two servers with the same IP address”. “What if I enable VRRP to cover hardware failures and my checks are wrong and I end up with two masters”. “What if I provoke a multicast loop”. “What if I setup multiple VRRP instances in multiple VLANs”.

All of these questions may sound very advanced to newcomers but are in fact quite common. In the world of load balancing, you definitely need to imagine a lot of failure cases and how to deal with them. Playing with pure software helps understand the basic concepts. Playing with VMs helps going a little bit further and already becomes quite painful. Add VLANs to the mix, asymmetric routing, DSR, transparent proxying and you’re quickly screwed.

Most of us started by plugging and pulling off cables , both network and power supply. I personally tortured a lot of Alteon AD3 in 2000-2001, but I was extremely lucky to have access to a lab where there were plenty of them (and they were really great devices to learn load balancing by the way).

But since it remains the best way to learn the concepts and to develop skills, HAProxy Technologies wanted to offer this opportunity to beginners again.

What if you could set up a complete load balancing lab on your desk, at school or at home  ?

load balancing on your desk
Complete Load Balancing platform on a desk

The photo above shows a complete load balancing platform deployed on a desk, with real machines and a real switch. And it’s just an example of what can be achieved. In order to make this possible, we ported our flagship product, the ALOHA load balancer, to a miniature MIPS-based platform which forms the ALOHA Pocket. This platform is designed and built by maker GL-Inet and is originally a WiFi router. But it has quite decent specs (2 FastEthernet ports, a 400 MHz 32-bit CPU, 64 MB of RAM, 16 MB of flash, and powered over USB), which are quite sufficient to run an ALOHA, is very convenient to manipulate, is rock solid and it is affordable. So it’s perfect to mass-produce an ALOHA that we can send around the world to interested participants. For now we have enough in stock to cover several tens of projects, we may order new ones if the stock goes away too quickly.

A box of 50 ALOHAs!
A box of 50 ALOHA Pocket Load balancers!

With this ALOHA Pocket, our goal is very simple : we want to introduce more people to load balancing., because we believe the future is there (load balancing, application delivery, content switching, function chaining, call it as you want, all these concepts are tightly coupled).  Thus we are willing to offer a couple of load balancers for free to any student or intern who can describe a project they are working on that involves load balancing, in exchange for their promise to regularly publish their progress, on a blog for example. We’re not going to verify who writes and when (though we welcome links), we bet that most participants will be honnest and will respect their engagement. We estimate that the more people who show what can be achieved using a load balancer, the more people will be attracted and will fall into that addiction in turn. It is even possible that some participants will face some bugs or will suggest improvements, we’re definitely willing to hear about this as well. Don’t be ashamed, suggest and criticize on your articles, we’re not asking people to send us flowers, just to be open! And maybe your comments will make some companies notice your skills and propose you a job after you finish your classes 🙂

This ALOHA Pocket is full-featured. It runs at quite a decent speed (around 450 connections per second with all features turned on, this is more than the vast majority of web sites). We could not put our anti-DDoS protection, PacketShield, in it because it requires more memory than this device contains. But we don’t consider that this is important for beginners. The devices will be shipped with the last version of our ALOHA platform, 8.0. We will intentionally not provide frequent software updates because we want to be sure that they will be used for educational purposes only and not to run production! But we’ll issue updates if users are facing bugs because we want them to learn in comfortable conditions.

Now, if you are interested, please send an email to contact at haproxy dot com with the subject “ALOHA Pocket”. Introduce yourself, what you intend to do (eg: load balance Apache/Nginx web servers, load balance Postfix mail servers, set up a cloud platform involving haproxy,  design a CDN involving HAProxy and Varnish, etc). Please provide enough details so that we may advise you if we detect some well-known traps in what you’re describing. Please indicate in what context you’re going to do this (at school, at university, for a company), and where you’re going to publish your progress, We don’t ask you to publicly disclose on your blog the name of the organization you’re working for, we know that some large ones still have problems with this. Indicate an estimated time frame for your project, and of course your shipping address. Try to be descriptive, as we consider that people not willing to write a few lines to get two free load balancers do not even deserve a response. By the way, if you believe you already have a compatible hardware and you’d only need the software image and procedure to flash it, contact us as well, we’ll welcome your demand as it means more people will be able to get one.

For logistics reasons, we’re going to send them in batches, so they will take a bit of time to arrive. Please bear with us, we’re handling all this by hand and installing all of them ourselves, just because we believe that this project is cool.

Let’s hope you’ll have as much fun using it as we had creating it 🙂

First HAProxy workshop at Zenika Paris was a success

HAProxy gets more and more contributors. That’s a good thing. There’s a side effect to this, which is that the maintainer (myself) spends quite some time reviewing submissions. I wanted to have the opportunity to exchange with various contributors to give them more autonomy, to present how haproxy works internally, how it’s maintained, what things are acceptable and which ones are not, and more generally to get their feedback as contributors.

Since I had never done this before, I didn’t want to force people to come from far away in case it would be a failure, so I wanted to contact only local contributors for this first round and that we talked french so that everyone would be totally at ease. A few of them couldn’t attend but no less than 8 people responded present! Given that our meeting room in Jouy-en-josas is too small for such a team, we started to consult a few partners. Zenika was kind enough to respond immediately (phone call in the evening, 3 proposals the next morning, who can beat that ?).

So Baptiste, Emeric, William, Thierry, Cyril, Christopher, Emmanuel and I met there in one of Zenika’s training rooms in Paris last Friday. The place was obviously much better than our meeting room, large, fully equipped, silent, and we could spend the whole day there chatting and presenting stuff.

I talked a lot. I’m always said to talk a lot anyway, so I guess nobody was surprized. I presented the overall internal architecture. It was not in great details, but I know the attendees are skilled enough to find their way through the code with these few entry points. What matters to me is that they know where to start from. Emeric talked a bit about the peers protocol. Cyril proposed that the HTML version of the doc be integrated into the official web site instead of as an external link. Then Christopher presented the filters, how they work, the choices he had to make. William explained some limitations he faced with the current design and there was a discussion on the best ways to overcome them. In short, some hooks need to be added to the filters, and proabably an analyzer mask as well. Then Thierry talked about various stuff such as lunch, Lua, lunch, maps, lunch, stats and how he intends to try to exploit the possibilities offered by the new filters. He also talked about lunch. He explained how he managed to implement some inter-process stats aggregation in Lua, which may deserve a rewrite in C.

It was also interesting to discuss the opportunity to use filters to develop the small stupid RAM-based cache that has been present in the roadmap for a few years (the “favicon cache” as I often call it). Thierry explained his first attempt at doing such a thing in Lua and the shortcomings he faced in part due to the Lua implementation and in part due to the uselessness of such a cache which ignored the Vary header. Also he complained about the limits he reached with such a permissive language when it comes to refactoring some existing code.

Emmanuel explained that for his use case (haproxy serves as an SSL offloader in front of Varnish), even a small object cache would bring very limited benefit and that he would probably not use it this way as he prefers to use it in plain TCP mode and deal with HTTP at a single place. He was suggested to run a test with HTTP multiplexing enabled between haproxy and Varnish (possible since 1.6) to estimate any possible performance gains compared to raw TCP. Emmanuel also discussed the possibility of exporting some histogram information for some metrics (eg: response sizes and times).

The question about how haproxy should make better use of the information it receives from the PROXY protocol header surfaced again, especially regarding SSL this time. It turns out that we almost froze the protocol some time ago and that everyone implemented it as it is specified, while haproxy skips the SSL parts. Something probably needs to be done, how is a different story.

The issue of external library dependencies was brought, such as Lua 5.3 and SLZ, which are not packaged in mainstream distros. There wasn’t a broad adoption of the principle of including them in the source tree, but rather to see them packaged and shipped by distros even if that’s in unofficial repos.

I explained how I intend to chain two layers of streams belonging to the same session with a protocol converter in the middle to implement HTTP/2 to HTTP/1 gatewaying, and some of the issues that will come from doing this.

We also discussed about what is still missing to go multithread. In short, still a lot but good practices are already mandatory if we want to make our life easier in the future.

Interestingly, for most users there, there are almost no more local patches except the usual few things that need to bake a bit before being submitted upstream. This is another proof that we need to make the code even easier to deal with for newcomers, to encourage users to develop their own code and submit it once they feel at ease with it.

Well, at the end of the day everyone seemed very satisfied and expressed interest for doing this again if possible at the same place (the place is nice, easily accessible and people were really nice with us).

We learned quite a bit for next rounds. First, everyone must participate and it seems that 10 persons is the maximum for a workshop. We need to make pauses as well. Next time we do it, we’ll have to be better organized (though everyone was good at improvising). We should prepare some rough presentations and ensure everyone has enough time to present their stuff. It’s also possible that we’d need a first part with everyone and a second part cut into small groups by centers of interests.

So thanks again to Zenika for helping us set this up, thanks to all participants for coming, now looking forward to doing this again with more people.

ALOHA Pocket is coming…

Well, this project is not really a secret anymore and people start to ask about it, so let me present the beast :

front_smThis is the ALOHA Pocket. Probably the smallest load balancer you have ever seen from any vendor. It is a full-featured ALOHA with layer 4/7, SSL, VRRP, the complete web interface with templates, the logs… It consumes less than a watt (0.75W to be precise) and is powered over USB.  It can run for about ten hours from a single 2200mAh battery. Still it achieves more than a thousand connections per second and forward 70 Mbps between the two ports. Yes, this is more than what some applications we’ve seen in field deliver on huge servers consuming 1000 times this power and running with 4000 times its amount of RAM. This is made possible thanks to our highly optimized, lightweight products which are so energy efficient and need so little resource that they can run on almost anything (and of course, they are magnified when running on powerful hardware).

Obviously nobody wants to run their production on this, it would not look serious! But we found that this is the ideal format to bring your machine everywhere, for demos, for tests, to develop in the train, or even just to tease friends. And it’s so cool that I have several of them  on my desk and others in my bag and am using them all the day for various tests. And while using it I found that it was so much more convenient to use than a VM when explaining high availability to someone that we realized that it’s the format of choice for students discovering load balancing and high availability. Another nice thing is that since it has two ports, it’s perfect for plugging between your PC and the LAN to observe the HTTP communications between your browser and the application you’re developing.

So we decided to prepare one hundred of them that we’ll offer to students and interns working on a load balancing project, in exchange for their promise to blog about their project’s progress.  If they need we can even send them a cluster of two.  And who knows, maybe among these, someone will have a great idea and develop a worldwide successful project, and then we’ll be very proud to have provided the initial spark that made this possible. And if it helps students get a career around load balancing, we’ll be quite proud to transmit this passion as well!

We still have a few things to complete before it can go wild, such as a bit of documentation to explain how to start with it. But if you think you’re going to work on a load balancing project or are joining a company as an intern and will be doing some stuff with web servers, this can be the perfect way to discover this new amazing world to design solutions which resist to real failures caused by pulling off a cable and not just the clean “power down” button pressed in a VM. Start thinking about it to reserve one (or a pair) when we launch it in the upcoming weeks. Conversely if you absolutely want one, you just have to find a load balancing project to work on 🙂

In any case, don’t wait too much to think about your project, because the stock is limited, so if there is too much demand, we’ll have to selective on the projects we’re going to support for  the last ones.

Stay tuned!

Quand le marketing dĂ©pense des sous qui ne vont pas Ă  l’innovation

Pas facile le load-balancing !

J’ai d’ordinaire un très grand respect pour nos concurrents, que je qualifie plutĂ´t de confrères et qu’il m’est mĂŞme dĂ©jĂ  arrivĂ© d’aider en privĂ© pour au moins deux d’entre eux. Etant Ă  l’origine du rĂ©partiteur de charge libre le plus rĂ©pandu qui donna naissance Ă  l’Aloha, je suis très bien placĂ© pour savoir Ă  quel point cette tâche est difficile. Aussi j’Ă©prouve une certaine admiration pour quiconque s’engage avec succès dans cette voie et plus particulièrement pour ceux qui parviennent Ă  enrichir leurs produits sur le long terme, chose encore plus difficile que d’en recrĂ©er un de zĂ©ro.

C’est ainsi qu’il m’arrive de rappeller Ă  mes collègues qu’on ne doit jamais se moquer de nos confrères quand il leur arrive des expĂ©riences très dĂ©sagrĂ©ables comme par exemple le fait de laisser traĂ®ner une clĂ© SSH root sur des appliances, parce que ça arrive mĂŞme aux plus grands, que nous ne sommes pas Ă  l’abri d’une boulette similaire malgrĂ© tout le soin apportĂ© Ă  chaque nouvelle version, et que face Ă  une telle situation nous serions Ă©galement très embarrassĂ©s.

Toutefois il en est un qui ne semble pas connaĂ®tre ces règles de bonne conduite, probablement parce qu’il ne connait pas la valeur du travail de recherche et dĂ©veloppement apportĂ© aux produits de ses concurrents. Je ne le nommerai pas, ce serait lui faire l’Ă©conomie d’une publicitĂ© alors que c’est sa seule spĂ©cialitĂ©.

En effet, depuis que ce concurrent a touchĂ© $16M d’investissements, il n’a de cesse de dĂ©biner nos produits ainsi que ceux de quelques autres de nos confrères auprès de nos partenaires, et ce de manière complètement gratuite et sans aucun fondement (ce que les anglo-saxons appellent le “FUD”), juste pour essayer de se placer.

Je pense que leur première motivation vient sans doute de leur amertume d’avoir vu leur produit systĂ©matiquement Ă©liminĂ© par nos clients lors des tests comparatifs sur les critères de facilitĂ© d’intĂ©gration, de performance et de stabilitĂ©. C’est d’ailleurs la cause la plus probable vu que ce concurrent s’en prend Ă  plusieurs Ă©diteurs Ă  la fois et que nous rencontrons nous-mĂŞmes sur le terrain des confrères offrant des produits de qualitĂ© tels que Cisco, et F5 pour les produits matĂ©riels, ou pour le logiciel. Bon et bien sĂ»r il y a aussi ce concurrent agressif que je ne nomme pas.

Il est vrai que cela ne doit pas ĂŞtre plaisant pour lui de perdre les tests Ă  chaque fois, mais lorsque nous perdons un test face Ă  un confrère, ce qui nous arrive comme Ă  tous, nous nous efforçons d’amĂ©liorer notre produit sur le critère qui nous a fait dĂ©faut, dans l’objectif de gagner la fois suivante, au lieu d’investir lourdement dans des campagnes de dĂ©sinformation sur le vainqueur.

A mon avis, ce concurrent ne sait pas par oĂą commencer pour amĂ©liorer sa solution, ce qui explique qu’il s’attaque Ă  plusieurs concurrents en mĂŞme temps. Je pense que ça relèverait un peu le dĂ©bat de lui donner quelques bases pour amĂ©liorer ses solutions et se donner un peu plus de chances de se placer.

DĂ©jĂ , il gagnerait du temps en commençant par regarder un peu comment fonctionne notre produit et Ă  s’en inspirer. Je n’ai vraiment pas pour habitude de copier la concurrence et je prĂ©fère très largement l’innovation. Mais pour eux ça ne devrait pas ĂŞtre un problème vu que dĂ©jĂ  ils ont choisi les mĂŞmes matĂ©riels que notre milieu de gamme, Ă  part qu’ils en ont changĂ© la couleur, prĂ©fĂ©rant celle des cocus. Les malheureux ne savaient pas qu’un matĂ©riel de bonne qualitĂ© ne fait pas tout et que le logiciel ainsi que la qualitĂ© de l’intĂ©gration comptent Ă©normĂ©ment (sinon les VM seraient toutes les mĂŞmes). C’est comme cela qu’ils se sont retrouvĂ©s avec un dĂ©calage dans la gamme par rapport Ă  nous : ils ont systĂ©matiquement besoin du boĂ®tier plus gros pour atteindre un niveau de performances comparable (je parle de performances rĂ©elles mesurĂ©es sur le terrain avec les applications des clients et les mĂ©thodologies de test des clients, pas celles de la fiche produit qu’on trouve sur leur site et qui n’intĂ©ressent pas les clients).

Et oui messieurs, il faudrait aussi se pencher un peu sur la partie logicielle, le vĂ©ritable savoir faire d’un Ă©diteur. DĂ©jĂ , utiliser une distribution Linux gĂ©nĂ©rique de type poste de travail pour faire une appliance optimisĂ©e rĂ©seau, ce n’Ă©tait pas très fin, mais s’affranchir du tuning système, ça relève de la paresse. Au lieu de perdre votre temps Ă  chercher des manuels d’optimisation sur Internet, prenez donc les paramètres directement dans notre Aloha, vous savez qu’ils sont bons et vous gagnerez du temps. Sans doute que certains paramĂ©trages n’existeront pas chez vous vu que nous ajoutons constamment des fonctionnalitĂ©s pour mieux rĂ©pondre aux besoins, mais ce sera dĂ©jĂ  un bon dĂ©but. Ne comptez quand mĂŞme pas sur nous pour vous attendre, pendant que vous nous copiez, nous innovons et conserverons toujours cette longueur d’avance :-). Mais au moins vous aurez l’air moins ridicules en avant-vente et Ă©viterez de mettre vos partenaires dans l’embarras chez le client avec un produit qui ne fonctionne toujours pas au bout de 6 heures passĂ©es sur un test simple.

Volontairement je vais publier cet article en français. Cela leur fera un petit exercice de traduction qui leur sera bĂ©nĂ©fique pour s’implanter sur le territoire français oĂą les clients sont très exigeants sur l’usage de la langue française que leur support ne pratique toujours pas d’ailleurs.

Ah dernier point, j’invite tous les lecteurs de cet article Ă  chercher “Exceliance” sur Google, par exemple en cliquant sur ce lien :

Vous noterez que notre concurrent prĂ©fĂ©rĂ© a mĂŞme Ă©tĂ© jusqu’Ă  payer des Google Adwords pour faire apparaĂ®tre ses publicitĂ©s lorsqu’on cherche notre nom, il faut croire qu’il nous en veut vraiment! C’est le seul Ă  dĂ©ployer autant d’efforts pour essayer de nous faire de l’ombre, comme si c’Ă©tait absolument stratĂ©gique pour lui. Vous ne verrez pas cela de la part d’A10, Brocade, F5 ou Cisco (ni mĂŞme Exceliance bien sĂ»r) : ces produits ont chacun des atouts sur le terrain et n’ont pas besoin de recourir Ă  des mĂ©thodes pareilles pour exister. Pensez Ă  cliquer sur leur lien de pub, ça leur fera plaisir, ça leur coĂ»te un petit peu Ă  chaque clic, et puis ça vous donnera l’occasion d’admirer leurs beaux produits :-).