Traffic Manager Redundancy (Unexpected drops)

[mattwater]

Just a quick question regarding Traffic Manager redundancy.

Let’s say you have an STM cluster servicing, as an example 5000 connections, 2500 each.

Why is it then when you reboot one of those STM’s most of the 2500 connections running through it drop, not all but most of them.

I have seen this multiple times in production and cannot figure out why it is behaving this way.

To my understanding there is no ‘drain STM’ functionality you simple have no choice but to hard reboot an STM when required.

My impression was the STM cluster supports stateful failover and should seamlessly move the active load from one STM to another.

This does not seem to be the case and I would like to get to the bottom of it.

I understand some connections will drop, the amount I see however is unacceptable.

Any feedback is appreciated.

[owen · Accepted solution]

Hi Mathew,

Stingray Traffic Manager does not support stateful failover.  If a traffic manager machine fails or is shut down, any TCP connections established with that machine will be dropped.  In many cases, protocols are robust to dropped connections or the end-user effect is minimal, which may be why it appears that not all connections are dropped.

This new document (Connection mirroring and failover with Stingray Traffic Manager) describes this in more detail.

If connections are far too valuable to drop, then you could consider using VMware Fault Tolerance as described in the document. 

regards

Owen

[mattwater]

Thanks Owen that is a very clear and concise explanation.