RE: Autoscaling in haproxy with persistence sessions
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.ma...@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.tor...@apicasystem.commailto:erik.tor...@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
RE: Autoscaling in haproxy with persistence sessions
Will the persistence sessions used by appsession be cleared if I renamed the existing servers and then reloaded the config? If so I could make it just change the names of the backend servers slightly in order to clean existing sessions. Or is the session bound to backend IP and not the name? /E From: Erik Torlen [mailto:erik.tor...@apicasystem.com] Sent: den 7 november 2011 11:16 To: Vivek Malik Cc: haproxy@formilux.org Subject: RE: Autoscaling in haproxy with persistence sessions 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.ma...@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.tor...@apicasystem.commailto:erik.tor...@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
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.birds...@gmail.com Date: Mon, 7 Nov 2011 12:17:53 To: Erik Torlenerik.tor...@apicasystem.com Cc: Vivek Malikvivek.ma...@gmail.com; haproxy@formilux.orghaproxy@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.tor...@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.ma...@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.tor...@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
RE: Autoscaling in haproxy with persistence sessions
'hash-type' seems like it could work. It also depends on how persistence sessions is affected by the hash-type. Is the persistence sessions overriding this and still going to the same backend server or will it be redistributed? /E -Original Message- From: David Birdsong [mailto:david.birds...@gmail.com] Sent: den 7 november 2011 12:18 To: Erik Torlen Cc: Vivek Malik; 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.tor...@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.ma...@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.tor...@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
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.tor...@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.ma...@gmail.com [mailto:vivek.ma...@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.birds...@gmail.com Date: Mon, 7 Nov 2011 12:17:53 To: Erik Torlenerik.tor...@apicasystem.com Cc: Vivek Malikvivek.ma...@gmail.com; haproxy@formilux.orghaproxy@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.tor...@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.ma...@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.tor...@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
Re: Autoscaling in haproxy with persistence sessions
On 2011-11-07 21:32, Erik Torlen 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. You should take care to not overload your backend servers in the first place. The connection limits can be finely tunes your each backend server. Requests exceeding the limits are queued which will prevent your servers from getting overwhelmed and dieing, usually taking others with it. Generally, I think you should make sure that your service is not getting overwhelmed by starting new instances earlier so you can actually handle the traffic. But in the end, I think it depends on how important session locality is for your service, i.e. which of those you can accept earlier: broken session locality or slightly delayed responsed due to queing. --Holger
RE: Autoscaling in haproxy with persistence sessions
Thank you Baptiste, seems like it should work then out-of-the-box when using appsession. On Haproxy reload the sessions should be cleared and then clients would be replicated to new servers. /E -Original Message- From: Baptiste [mailto:bed...@gmail.com] Sent: den 7 november 2011 12:43 To: Erik Torlen Cc: vivek.ma...@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.tor...@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.ma...@gmail.com [mailto:vivek.ma...@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.birds...@gmail.com Date: Mon, 7 Nov 2011 12:17:53 To: Erik Torlenerik.tor...@apicasystem.com Cc: Vivek Malikvivek.ma...@gmail.com; haproxy@formilux.orghaproxy@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.tor...@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.ma...@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.tor...@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
Re: Autoscaling in haproxy with persistence sessions
On Mon, Nov 7, 2011 at 9:48 PM, Erik Torlen erik.tor...@apicasystem.com wrote: Thank you Baptiste, seems like it should work then out-of-the-box when using appsession. On Haproxy reload the sessions should be cleared and then clients would be replicated to new servers. Actually, the weakness of appsession seems to be a strengh for you... Wait, if you don't configure a peer on stick stable, they are also reseted :) So both should work in your case ;)
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:bed...@gmail.com] Sent: den 7 november 2011 12:43 To: Erik Torlen Cc: vivek.ma...@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.tor...@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.ma...@gmail.com [mailto:vivek.ma...@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.birds...@gmail.com Date: Mon, 7 Nov 2011 12:17:53 To: Erik Torlenerik.tor...@apicasystem.com Cc: Vivek Malikvivek.ma...@gmail.com; haproxy@formilux.orghaproxy@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.tor...@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.ma...@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.tor...@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
RE: Autoscaling in haproxy with persistence sessions
You should take care to not overload your backend servers in the first place Yes, that is what we are trying to achieve using autoscaling of the backend servers :) I would have like to use the maxconns against backend but we did not have time to tune this before the release. Generally, I think you should make sure that your service is not getting overwhelmed by starting new instances earlier We are actually scaling very aggressive plus that we have a lot of instances running. So we are using more of a scaling down concept currently. But you never know, big releases going mainstream tends to generate traffic so we need to make sure that scaling further up will work as expected. /E -Original Message- From: Holger Just [mailto:hapr...@meine-er.de] Sent: den 7 november 2011 12:45 To: haproxy@formilux.org Subject: Re: Autoscaling in haproxy with persistence sessions On 2011-11-07 21:32, Erik Torlen 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. You should take care to not overload your backend servers in the first place. The connection limits can be finely tunes your each backend server. Requests exceeding the limits are queued which will prevent your servers from getting overwhelmed and dieing, usually taking others with it. Generally, I think you should make sure that your service is not getting overwhelmed by starting new instances earlier so you can actually handle the traffic. But in the end, I think it depends on how important session locality is for your service, i.e. which of those you can accept earlier: broken session locality or slightly delayed responsed due to queing. --Holger
Re: Autoscaling in haproxy with persistence sessions
On Mon, Nov 7, 2011 at 10:05 PM, Erik Torlen erik.tor...@apicasystem.com wrote: 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? The hash algorithm based on source IP looks interesting, persistence will be lost on each reload and adapted to the farm size. Worst case, the stick table + peers to synchronise + clear table on reload... But there might be undesirable side effects: if clear table is not done synchronously, then new entries will be replicated... cheers
RE: Autoscaling in haproxy with persistence sessions
Is 'hash-type consistent' the way to go using hash algorithm? Map-based sounds pretty good as well? Consistent: In order to get the same distribution on multiple load balancers, it is important that all servers have the same IDs. Something like this? Balance source hash-type map-based /E -Original Message- From: Baptiste [mailto:bed...@gmail.com] Sent: den 7 november 2011 13:58 To: Erik Torlen Cc: vivek.ma...@gmail.com; David Birdsong; haproxy@formilux.org Subject: Re: Autoscaling in haproxy with persistence sessions On Mon, Nov 7, 2011 at 10:05 PM, Erik Torlen erik.tor...@apicasystem.com wrote: 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? The hash algorithm based on source IP looks interesting, persistence will be lost on each reload and adapted to the farm size. Worst case, the stick table + peers to synchronise + clear table on reload... But there might be undesirable side effects: if clear table is not done synchronously, then new entries will be replicated... cheers
