I recently came across a few issues configuring Network Load
Balancing (NLB) on two Windows 2008 R2 Hyper-V VMs running IIS and
MySql as a hosting solution for 100+ medium traffic WordPress sites
to be migrated over after testing.
Installation
and configuration of NLB went fine, and the cluster was
initially configured as multicast. This worked fine, until I
went to go test connectivity from the outside world - no
respone. Turns out, the gateway on this network was
(correctly) set to not relay multicast packets.
Unfortunately, creating static routes on this gateway was not
an option, so it was going to have to be unicast. Not a
problem - I shut the machines down, added another virtual ethernet
adapter, and reconfigured NLB to use the dedicated second
adapter. Windows 2008 R2 and 2012 Hyper-V hosts are now set
to block VM MAC address spoofing by default, so that needed to be
enabled for that second adapter.
All's well and good - WordPress sets up, everything works...
until I log into WordPress and find that it can't retrieve any
external info (themes, plugins, WordPress news, etc.) Because
of the way NLB works in unicast mode, each site was trying to use
the adapter it was bound to (the dedicated NLB adapter), which
because of the spoofed identical MAC addresses, couldn't guarantee
that the response would come back to the machine that generated
it.
The
following commands, courtsey of The Cable Guy, cleared this
issue up:
netsh interface ipv4 set interface {NLB adapter}
weakhostsend=enabled
netsh interface ipv4 set interface {NLB adapter}
weakhostreceive=enabled
netsh interface ipv4 set interface {NLB
adapter}ignoredefaultroutes=enabled
...in addition to going into Advanced Settings from the Network
Connections list and setting the Management adapter as a higher
priority than the NLB adapter.
The first two commands reenable weak binding, while the third
command allows outgoing traffic to go out over the non-load
balanced adapter, based upon the order of the connections (and
guaranteeing it would come back to that specific machine).
Upon further testing, this solution did not work for the
given scenario. NLB is an outdated solution with
flaws, but for a while it was the only game in town (on the cheap
end). As stated in the setup docs, NLB creates a massive
amount of multicast data in this mode. The network
configuration is unfortunately large and flat, and this
configuration generated multicast storms of each and every request.
On an isolated VLAN, this could work, but at that point, you
might as well have gone in another direction. Also, upload
speeds are hobbled because of how much traffic is created with
incoming packets.
Dedicated load
balancers and proxy servers are much better for keeping large
amounts of web data highly available.
Physical devices are expensive but well-designed. Even a
lightweight software solution
like Squid on quality hardware would fit the bill, plus you get
the added benefit of offloading caching and compression to the
proxy server, but you lose the ease
of a single-point SSL configuration that the better featured
physical devices include and instead have to pass encrypted traffic
straight-through. Luckily,
IIS >= 8 has that covered.