All posts by wtarreau

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 :-).