How to patch a TMG array– some thoughts on NLB high availability

How to patch a TMG array– some thoughts on NLB high availability

  • Comments 4
  • Likes

One of the reasons for using an array is the availability of NLB, which is known to provide fault tolerance and load balancing.

NLB relies on heartbeats to determine whether the cluster nodes are alive. The nodes divide the potential client IP addresses among each other (in fact actually the hashes of the IPs) and send each other heartbeats, thereby notifying the other members that they are up and running.

As soon as a node is down (fails to send the heartbeats), the remaining nodes take ownership over the failing node’s IP hashes, providing coverage for all the clients normally served by the broken node.

How does this all relate to patching?

For new connections, the above behavior is straightforward, but what if we just “unplug” one of our TMG machines? What happens to existing connections served by this box? No other node will be aware of the state of these connections, so essentially they will simply fail.

This is exactly what happens if you just all of a sudden patch and reboot one of your TMG nodes.

How can we circumvent this? Is there any workaround?

In general, NLB supports what is called “drain mode”.

When your “drainstop” a node, NLB will still serve existing connections owned by that node but it won’t accept new connections. New connections will be handled by the other available nodes in the array.

With that, If you are intentionally taking a node offline then you can use drainsstopping to service all the active connections before you take the node offline for patching.

Therefore, when patching a particular TMG node, Ideally you will :

1. drain the node, wait until the session count drops to zero (sessions tab)

2. suspend it (so that NLB won’t be automatically started on next reboot)

3. patch the node

4. make sure the system operates properly with the patch

5. start NLB again to make the node join the array again

Here is a screenshot of the NLB options available in the TMG Management console:

clip_image001

Reference:

http://technet.microsoft.com/en-us/library/cc725691.aspx

Authors
Balint Toth
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team

Comments
  • The described procedure doesn't work out! when draining and stoping, TGM will disconnect ipsec s2s tunnel and will not reconnect on remaining node. additionally sessions NEVER drop to 0 !!! I tried draining over one week and -besides the TMG own connections - there were still other old and NEW!! sessions.

  • Drainstopping is stil the best method for intentionally taking an NLB node out of service; however, I have noticed that with persistent TCP connections (such as from Outlook Anywhere / ActiveSync clients), the node will never completely drain.  The idea is to allow all non-persistent connections to drain off (which should not take very long), and then you can stop the NLB completely.  Persistent connections will be cut off, but those clients should attempt to re-establish, and will end up on the other active NLB nodes.

  • quick Information, when you drain-stop the NLB on a TMG Server and reboot the server or restart the Firewall Service afterwards, the NLB will be automatically started again.

  • Thats why you should set the NLB service to suspend before you reboot the server.

    Like the article say, reboot the server and verify that everything looks ok (in eventvwr etc) and after this start the service.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment