Moving network services from server to server can be a major administrative headache, particularly when clients go looking for resources at the old server’s address. One alternative is to use virtual servers with the Windows 2000 Cluster Service, which enables a new virtual server to masquerade with the name and address of an old server. And you can set up a virtual server on the same physical box as your current server, sparing yourself expense as well as frustration.

Installing a virtual server alongside an existing server is sometimes known as a “lonewolf” configuration (a reference to the Cluster Service’s original code name, “Wolfpack”), and it further proves that the Cluster Service provides benefits beyond traditional fault tolerance.

Prerequisite knowledge

This article assumes a basic understanding of the Windows 2000 Cluster Service. For introductory information on the Cluster Service, read:

Server consolidation with virtual servers
Although most would define a cluster as “two or more servers acting together,” Microsoft supports a single-server cluster configuration using virtual servers. Hardware costs are decreasing, but server license costs are on the rise, and tighter IT budgets demand lower administrative overhead. So, server consolidation is very popular right now. This also ties in with infrastructure changes, such as domain collapsing in preparation for Active Directory.

The problem with server consolidation isn’t usually moving the data to another server, but getting clients to connect to a different server. Clients often store server and share paths in multiple places, such as logon scripts, the Registry, and application configurations. Tracking down just where the references are, let alone globally editing them on all clients to redirect them to the new server, can often be a mess.

This is where the Cluster Service’s virtual servers can help out by binding multiple NetBIOS names to a single computer. You simply use the Cluster Service to create a virtual server with a network name and associated IP address that are the same as the original server’s.

Once you’ve installed the original server’s services along with associated data on the new server, you turn off the original server and bring online the new server. Clients continue to connect to their resources, unaware that they are no longer connecting to the original physical server, but to another machine altogether. The only temporary hiccup you may encounter is when the original Media Access Control (MAC) address has been stored on switches and not automatically updated with a gratuitous Address Resolution Protocol (ARP). (Remember, the server name and IP remain the same, but the MAC address will change.) However, this is no different than if the NIC in the original server failed and had to be replaced.

Configuring a virtual server with the Cluster Service
To set up this type of configuration for a single server, you should invest in external disk storage, although technically you could run these with a local Quorum (but this wouldn’t be a supported Microsoft solution). To create a virtual server with Cluster Administrator, you should have a spare external disk dedicated to this virtual server and the data it offers users. This disk should show up as an existing Disk Group and have specified within it the Physical Disk resource. If you have no spare external disk, create a new group (you should not add new resources to the Cluster Group).

Right-click on this new group and select Configure Application. After clicking Next, select Create A New Virtual Server. In the Resource Group for the Virtual Server page, select Use An Existing Resource Group, make sure your group is selected, and click Next. Provide an administrative name (e.g., Sales Database) that will replace your original group name in the Cluster Administrator MMC. Click Next and you’ll see the Virtual Server Access Information page, where you specify the network name and IP address for the server (this is where you supply the original server’s name and IP).

Click on Next twice, and you’ll see the Create Application Cluster Resource screen, where you’ll select No, I’ll Create A Cluster Resource For My Application Later. Click Next and then Finish. You should now see the new IP address and Network Name screen in the Cluster Administrator MMC, but with an accompanying yellow exclamation mark to denote that they are currently offline because you just created them.

To bring the group (and therefore the virtual server) online, make sure the original server is turned off, right-click the group, and select Bring Online. You’ll see the status information change to Online Pending, and eventually to Online. A failure to go online could mean the IP address and name you specified are incorrect (or already active on the network). You should then double-check that the original server is turned off.

Once the group is online, you should be able to connect to it by name and/or IP address. You’ll notice that by right-clicking on the group, you can take the virtual server offline for clients without having to stop services or shut down the server, which would affect other services.

If you check the properties of the two resources you just created—IP Address and Network Name—you’ll see four tabs: General, Dependencies, Advanced, and Parameters. Of interest here is the automatic Restart Of These Resources If Cluster Service Detects They Are No Longer Functioning, an option specified under the Advanced tab. The Network Name’s Dependencies tab will show the automatic dependency on the IP address, which means that the server name will not be available before the IP address is available. You can modify the name and IP address, and specify which adapter to use, on the Parameters tab.

Of course, as the budget becomes available, you can always add a physical server to this single-server cluster to provide the additional benefit of failover.

Another little-known benefit of the Cluster Service
Virtual servers are another lesser-known benefit of using the Cluster Service. They can be very useful for many administrators in consolidating services and simply moving services from one system to another.