Thank you for your reply.
It is pretty much a verification of what we thought this end.
Ill go back to the customer and let them know what Microsoft suggest
is not possible.
+1 888 867 9504 / +44 (0)330 380 1064
Leave a Review | Deployment Guides | Blog
On 14 February 2018 at 17:55, Shawn Heisey <hapr...@elyograg.org> wrote:
> On 2/13/2018 7:49 AM, Andrew Smalley wrote:
>> We have had a request and not sure if there is any way to implement this.
>> Simply think of two real servers being loadbalanced. one fails all the
>> connections are moved to the remaining server overloading it.
>> What we want is for the traffic from the failed real server to be
>> moved to the remaining real server without overloading it. IE Move a
>> few connections at a time so the last server is not overloaded.
> The following is my understanding of how things work and what you have
> said. If I have made any errors, I hope somebody will point them out.
> As far as I am aware, there is no way to "move" an existing connection
> from one backend server to another. That would require special support
> from both haproxy and the back end software. To my knowledge, that
> capability does not exist. So existing connections at the moment of
> failure are going to get closed down and the application (which may be a
> browser) will need to try again.
> There isn't anything gradual about load shifting in the event of a
> failure. Existing connections will be dropped and new connections will
> be sent to whatever servers remain.
> When planning your capacity, it's prudent to take failures into account.
> Failures *are* going to happen. They might be unplanned, such as a
> motherboard failure or a datacenter outage, or they may be planned, so
> you can upgrade software on the back end.
> If one server failing means that there is not enough remaining capacity
> to handle the load, then you need more capacity, which may require more
> servers. Ideally the remaining servers would handle the load without
> users ever noticing any change, but in many environments it is
> acceptable for performance to be a little worse until the failed server
> is returned to service.