RE: Autoscaling in haproxy with persistence sessions

What would you recommend if we wanted to have all our three haproxy instances loadbalance in the same way. And still make use of persistence when the client is using one of the haproxy instances?

E.g Having the client come to the same backend on both haproxy srv1, srv2 and srv3.

Could we make use of some hash-algorithm to achieve this? Balancing on source ip?

/E

-----Original Message-----
From: Baptiste [mailto:bedis9#gmail.com] Sent: den 7 november 2011 12:43
To: Erik Torlen
Cc: vivek.malik#gmail.com; David Birdsong; haproxy#formilux.org Subject: Re: Autoscaling in haproxy with persistence sessions

Hi Erik,

Let me give you a few information, I don't know if it will help. Appsession is not resilient on HAProxy reload. Which means that since you reload after updating configuration, then all session will be re-dispatched.
You can use stick-table too, sticking on cookie is doable easily with latest HAProxy.
Note that in HAProxy 1.5-dev7, there is also a "clear tabe" command available on the stats socket.
This page summarizes what's new in HAProxy 1.5-dev7 compared to 1.5-dev 6: http://blog.exceliance.fr/2011/10/03/whats-new-in-haproxy-1-5-dev7/

cheers

On Mon, Nov 7, 2011 at 9:32 PM, Erik Torlen <erik.torlen#apicasystem.com> wrote:
> If you get a burst against 3 active backend servers they will take care of all the request and connections. The clients that are active
> will then get a persistence sessions against 1 of these 3 servers. It will take ~5min to scale up a new server so during that period
> more clients could come in and the 3 backend would then be even more overloaded.
>
> It is that case that I would like to avoid by resetting the session so that existing plus new sessions are spread through all the existing
> plus new servers.
>
> /E
>
>
> -----Original Message-----
> From: vivek.malik#gmail.com [mailto:vivek.malik#gmail.com]
> Sent: den 7 november 2011 12:27
> To: David Birdsong; Erik Torlen
> Cc: haproxy#formilux.org
> Subject: Re: Autoscaling in haproxy with persistence sessions
>
> If the solution is intended for traffic burst, Isn't it safe to assume that most clients will be new which appsession/cookie doesn't know about?
>
> New clients will automatically be preferred to go to newly added servers as new servers will have least active connections.
>
> I don't think any special change is required in practice to handle burst of new traffic from say a premium ad buy or email blast (along with using maxidle)
>
> Vivek
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: David Birdsong <david.birdsong#gmail.com>
> Date: Mon, 7 Nov 2011 12:17:53
> To: Erik Torlen<erik.torlen#apicasystem.com>
> Cc: Vivek Malik<vivek.malik#gmail.com>; haproxy#formilux.org<haproxy#formilux.org>
> Subject: Re: Autoscaling in haproxy with persistence sessions
>
> This sounds like what balancing on a hashed value is intended for.
> 'hash-type consistent' will reduce the redistribution of keys when the
> pool is expanded, and when nodes are removed, only the removed nodes
> keys are redistributed.
>
> On Mon, Nov 7, 2011 at 11:15 AM, Erik Torlen
> <erik.torlen#apicasystem.com> wrote:
>> Interesting. In this case we are expecting a lot of burst traffic during a
>> very short period of time, 15-30min so I am not sure if we can rely on
>> scaling in a more proactive way to send traffic to the new servers. I would
>> be
>> more comfortable if we could just clean the existing sessions and let them
>> be spread over the new servers + existing servers.
>>
>>
>>
>> I had a look at stick-table and saw that it has methods to support being
>> deleted/cleared through the socket interface. Is it possible to do something
>> similar to clean appsessions? Or maybe store appsession in
>> a stick-table and clear the session through socket command?
>>
>>
>>
>> /E
>>
>>
>>
>> From: Vivek Malik [mailto:vivek.malik#gmail.com]
>> Sent: den 7 november 2011 11:05
>> To: Erik Torlen
>> Cc: haproxy#formilux.org
>> Subject: Re: Autoscaling in haproxy with persistence sessions
>>
>>
>>
>> I personally find it easier to use cookie instead of appsession. We use a
>> similar pattern of adding a new server. Keeping a low maxidle (like 10
>> minutes) helps us send traffic to new servers. Keeping maxidle helps us
>> maintain session affinity where required (like progress bars for uploads)
>>
>>
>>
>> Vivek
>>
>> On Mon, Nov 7, 2011 at 1:32 PM, Erik Torlen <erik.torlen#apicasystem.com>
>> wrote:
>>
>> Hi,
>>
>> We are currently having a system which runs haproxy in the amazon cloud. Our
>> system is also using autoscaling of backendservers
>> so when we reach a certain cpu usage during x min we will add more servers
>> to the backend and update the haproxy config + reloading haproxy.
>>
>> This works good as we have it now.
>>
>> What we would like is to add persistence to the backend in order to use the
>> caches on the backend servers more efficiently (a shared cache would have
>> been
>> better but is not the case now unfortunately).
>>
>> This makes the autoscaling a bit more complex because of the persistence.
>> When scaling up new servers the client would still stay on the "overloaded"
>> backend servers instead of start using the new ones.
>>
>> So I thought I would check with you if there is a way to "clear" persistence
>> session used by appsession in a good way without effecting the traffic to
>> servers?
>>
>> If we cleared all the persistence sessions we could let the client go into
>> the new backend servers and have "request-learn" in appsession learn the
>> cookie and set persistence to the existing and new servers for the client.
>>
>> Any ideas here?
>>
>> Cheers
>> E
>>
>>
>
>
Received on 2011/11/07 22:05