Re: Hardware requirements

From: Patrick Viet <patrick.viet#gmail.com>
Date: Sun, 28 Sep 2008 20:37:07 +0200


Hello Guillaume,

I suppose you missed the "reply all" to include the list. I will post my reply to the list.

About session sharing : I'll first give a short answer : I simply don't do it.

Now the long answer : session tracking is a very complex thing, and since HAProxy uses native UNIX sockets with plain old rock-solid UNIX syscalls, that would mean some kind of kernel-level interaction between the servers, between the server and HAProxy, ... So patched kernel + patched HAProxy : this is super dangerous, imagine how many dozens of bugs could hop in there !!

My experience has shown me that trying to be too redundant/transparent had horrible side effects. Basically such a modification would be more prone to fail itself than the risk is is supposed to cover. Keep it simple, stupid. That's how any good architecture works.

As a multi-million euro loss example, I remember a major blackout on July 12th 2006 at a major French ISP : the routing to their recursive DNS servers was so redundant that they didn't even bother to do the proper thing : keep the backup servers fully independent to avoid failure leaking. And it crashed for several hours when a datacenter went down because of some weird Cisco bug ...

In my setup, there is a +/- 30 seconds blackout when a HAProxy load balancer goes down. Considering how solid the hardware is (DELL, Sun, ...), this happens usually before the hardware fails : every couple of years when one of the datacenters has an electrical failure... So rather than session tracking, I made it multi-datacenter and it shifts to one of our three other datacenters.

The details of implementation (how it is transparently multi-datacenter) are kind of confidential since I sell this service for quite a big amount of money to my hosted customers, so if you want to discuss it lets go off list.

With kind regards,

Patrick

On Sun, Sep 28, 2008 at 6:14 PM, Guillaume Bourque <Guillaume.Bourque#gmail.com> wrote:
> Hi Patrick
>
> very interesting your configuration. Could you tell us how you share your
> sessions from 1 haproxy to another, in case one of you're haproxy machine
> goes down ?
>
> With this traffic volume you must have some failed over facility to maintain
> already open session from a running haproxy server to it's backup ?
>
> Thanks
>
> Patrick Viet a écrit :
>>
>> On Sun, Sep 28, 2008 at 1:42 PM, Marcus Herou
>> <marcus.herou#tailsweep.com> wrote:
>>
>>
>>>
>>> Talking to you guys makes my performance questions seem small and
>>> pityable
>>> and damn we are the #4 site reach wise in Sweden reaching 3.5 million UB
>>> each week. What kind of sites are you guys really running ?
>>>
>>
>> I work for a French web hosting company that specialises in
>> performance. We have several customers shared our load balancer pool.
>> With high traffic websites (we host some among top #20), this can add
>> up pretty quickly to many thousands of hits/sec. But I haven't reached
>> the haproxy limits with only one website yet : nothing over 5000/sec
>> or a few hundred mbit/s for a single one.
>>
>> Since you seem to like numbers, here are a few : with careful work on
>> PHP code, caching (APC) and nginx or lighttpd tools, one single
>> Core2duo webserver can output about 400-500 hits/sec of dynamic pages,
>> and way over 4000 hit/sec of static content - provided we have enough
>> RAM and gigabit uplinks. That's over 100 million hits/day/server for
>> just pictures (considering average use one half).
>>
>> Anyway if you have further questions about performance, don't hesitate
>> to post on the list. And if you need more specific professionnal
>> advice, I'm sure Willy's company (EXOSEC) or mine would be willing to
>> provide some...
>>
>> Patrick
>>
>>
>
>
> --
> Guillaume Bourque, B.Sc.,
> consultant, infrastructures technologiques
> Logisoft Technologies inc.
> 514 576-7638
> http://www.logisoftech.com
> Pour mes recherches j'utilise un site très efficace:
> http://www.katapulco.com/ca/
>
Received on 2008/09/28 20:37

This archive was generated by hypermail 2.2.0 : 2008/09/28 20:47 CEST