NLB nightmare
Over the last couple of weeks, I've been helping the Windows admins run an issue with a website to ground. Unfortunately, the problem has involved Microsoft Network Load Balancing. So, during the course of my diagnostics, I ended up laking an NLB scenario at home and I published my Network Load Balancing to a single host article with some additional details on how I set NLB up.
Here are some of the problems that I've run in to over the last couple of weeks:
- NLB mis-configured with a service VIP on one node.
- Not all nodes in an NLB cluster having the same services installed and configured.
- Multiple NLBs listening on multiple interfaces in the same VLAN / subnet. (This one is particularly bad and I believe the root cause of many of our problems.
- Other people involved with the project that want to do such nasty things as rearchitect solutions at the 11th hour causing a lot of rework .... when it's not necessary.
- Other people wanting to change the port that services run on and cause end users from here on out to have to do something above and beyond what is normal. .... This is not at all necessary and is in my opinion rather uninformed.
The last two things really bother me. Causing a lot of rework, when it's not required, especially towards the end of a project is NEVER a good idea, much less received well. Causing users to have to change what they do that is above and beyond the norm, is never the solution, especially when it's not required. Further, causing end users (and their support staff) to have to do more work is NEVER the answer when it is simply to make things easier for the administrators to implement.
As a general rule, I like to consider the failure mode of things and make sure that I (we) handle it as gracefully as possible. Something that this NLB nightmare of a project has gone against at just about every turn.
Though to my credit, I did solve a problem that has been on going for three to six months in less than two weeks. :-)