BVLog Bryan Voss’ mental synchronization point


Windows Network Load Balancing: easier than I thought

Several months ago, we had a vendor come in to implement a Windows failover cluster for our document imaging system MS SQL server. The implementation failed. The vendor tech who was attempting to set up the cluster attributed the failure to an underscore character in our internal domain name. Not sure whether that was the cause of the problem, but we ended up reverting back to our single server setup after 30 hours of downtime. The whole experience left me wary of Windows clustering in general.

We are now in the process of implementing a Windows Network Load Balancing cluster for a 3-node term. server setup on a new app. Both myself and a fellow sysadmin came into the situation expecting problems. Since it's a new application that is not yet live, we figured we could weather any problems without having to worry about downtime. As it turns out, NLB clustering is almost dead simple.

The vendor tech who was supposed to be assisting us with the cluster setup joined us on a conference call 30 minutes late, mumbled his way through some email looking for something, then emailed us some documentation and basically said, "Here, read this and call me back in an hour so we can set up the cluster." I looked at my coworker, we both shrugged, and hung up the phone. We naively expected the vendor to be a lot more helpful.

After going to lunch, we came back and skimmed through the documentation a few minutes before calling the tech back. He tried walking us through manually configuring each server's network adapters, but we ran into problems with trying to do the setup with a single adapter on each server connected to the switch. It was obvious that the tech was not familiar with clustering and was just reading through the documentation and telling us what to do. After fumbling around for an hour or so, we told the tech we would call him back after connecting the second network adapter on all three servers.

I had been reading ahead a bit and discovered that Microsoft provides a Network Load Balancing Manager app as part of its Server 2003 admin pack. We removed all the mess and got the servers back to a clean network config, then used NLB Manager to build the cluster from scratch. Once we realized the difference between the primary cluster IP and the dedicated IP (hint: the primary cluster IP is the same on all nodes; the dedicated IP is a second unique IP assigned to each node to allow them to talk to each other), we got the whole thing set up in just a few minutes.

We called the vendor tech back and said, "Ok, it's working now." He assumed he was responsible for getting it going and we just let him bumble happily on with that assumption as we got off the phone. We proceeded to test the cluster by making RDP connections from several PCs to the cluster name. The first server in the cluster accepted around four connections before the second server began picking up new connections. The whole thing worked pretty much flawlessly from that point on.

We had originally built the cluster with two servers while the primary users worked on building the app using the third term. server. We later added the third server to the cluster without problems. After promoting it to priority 1, we were able to connect via RDP and it immediately started sharing the load. Nice!

We're looking at how easy it was to set up and coming up with all sorts of uses for this new tool in our kit. Now, I'm not so wary about Windows clustering. I may even build a couple of virtual machines and attempt to put together a test failover cluster myself. If all goes well, I'll just implement the failover cluster on our document imaging system myself. With the level of "assistance" we're getting from vendors, we should probably just plan on implementing future changes ourselves.

Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.