I have been working on implementing the new “Terminal Services Gateway” service that will be released with Server 2008. In order to cluster TS Gateways, we need to have a network load balancing solution in place. Hardware solutions are supported, but getting access to those would be a pain. Thus, I am back to looking at Microsoft Network Load Balancing services.
My last attempt as using NLB ran into some troubles… NLB-fronted Server 2003 terminal servers were pokey at best. This time, I thought I should look at the implications of running Microsoft NLB on ESX server, which is the platform I am using for the TS Gateways.
Unsurprisingly, I learned some new things…
- Microsoft NLB is not supported by VMWare:
(Configuration assistance is available only for “Microsoft Cluster Services” (MSCS)).
- When using NLB on ESX, it is recommended that you use “multicast” mode. This is mentioned several places:
Here, it is noted that if you are using NLB in Unicast mode, you will need to disable the NIC failover “notify switches” flag on your ESX VSwitch. This is uindesirable because it will increase the switch convergence time in the event of a failover (since the switches will have to rebuild their lookup tables following connection failures).
This document outlines the procedure for setting up NLB on Windows 2000/ESX Server 2.5. Here you are specifically instructed to use Multicast mode. No reason is given.
In this document, procedures for securing ESX server switch ports are outlined. It is recommended that you prevent the ability of an OS to change the MAC address of its adapter (specifically, to prevent network adapter impersonation that could be used in an attack). NLB multicast mode does not need to alter the NICs MAC address, and this is compatible with this hardening procedure
Thus, we will forgo the use of “IGMP Multicast mode” NLB config… Which is just as well as IGMP appears to break NLB on our ESX cluster!