Cubix Carries the Load: Balanced Cluster Service - Software Review - Evaluation

Administrators deploying Microsoft Corp.'s Windows NT Server 4.0, Terminal Server Edition, face a significant challenge to ensure that they provide adequate capacity and fault tolerance to support their users. By concentrating multiple user logons onto a single machine, Terminal Server decreases a number of costs, but increases the risk that a machine outage can disable a significant number of users.

Using only Terminal Server, an administrator could address this problem by deploying multiple servers and assigning each user to a server for their access. They also could institute rudimentary balancing with a round-robin entry in the organization's DNS tables. Neither of these approaches, however, addresses the problems of dynamic allocation of resources or system outages.

Cubix Corp. steps neatly into this gap with Balanced Cluster Service (BCS), a product designed to work in a niche environment, rather than be everything to all people.

We tested BCS in conjunction with our review of Windows Terminal devices. To do so, we added a second Terminal Server to our test network and reconfigured the various Windows Terminal Devices to the BCS specifications.

The basic requirements are not particularly onerous. First, the environment must be purely Windows Terminal Server. BCS does not support environments using Terminal Server add-ons, such as Citrix Systems Inc.'s MetaFrame. Second, the network must support at least one instance of the Windows Internet Name Service (WINS). Third, client workstation must be able to support name resolution via WINS if it is to take advantage of the cluster balancing. Finally, all of the servers participating in the cluster must be on the same subnet, though clients may connect from any point as long as they can receive appropriate WINS resolution.

BCS has two basic components. The most critical component is the BCS service module, which runs on each Terminal Server in a cluster. This module monitors statistics about connections and CPU utilization on the server where it runs and communicates that information to the other servers in the cluster. Installing the BCS service module took about five minutes using standard InstallShield procedures familiar to almost any administrator.

The second component is an administration module, which may be run on any server or workstation in the network under Win95/98 or Windows NT Server or Workstation. The administration module is used to assign servers to clusters, names to clusters, an optional fictitious name to the "best" server in a cluster, and designate a master server in each cluster. The administration utility does not provide much function beyond this, nor is much function required.

Once active, the BCS services begin to communicate between the servers in a cluster, using broadcast messages to share information about the number of users connected and the CPU load at each server. Whichever server is designated as the master for that cluster then uses that information to compute which server in the cluster is best able to handle the additional load. If the designated master is off-line for any reason, the remaining servers elect a temporary master to perform these duties. The best server value is recomputed periodically, with the default being every 60 seconds. The algorithm used to decide which server is best at any given moment is embedded in the program and is not adjustable by the administrator.

After a decision is made as to the best server, that information is broadcast back to the various servers. More important, though, is the information broadcast to the WINS server in the network. When installing BCS, a fictitious server name was assigned to the entire cluster; the administrator can set this name to whatever is desired. Whenever the cluster balance is recomputed, an entry is made to WINS identifying that fictitious name with the IP address of whichever server is currently best. The use of broadcasts for these decision conversations is the reason all servers in a cluster must be on the same subnet.

Because of the fictitious entry in the WINS database, the client workstations must use WINS resolution to identify IP addresses. In our testing, we did this by assigning a default WINS server and terminal type in the information handed out by DHCP to our various Windows Terminal Devices. Once configured, we set our terminals to connect to the server using the fictitious name we selected. Each terminal checked the WINS server, found an IP address and connected properly. As expected, the IP address, and thus the server contacted, varied from one connection attempt to the next, based on the server loads at that moment.

We experimented with several sorts of loads, using standard office products such as Microsoft Word, Outlook and Excel, to see what BCS did depending on what was running. Under normal circumstances, we found the distribution of new connections depended largely on the number of connections over any other factor. It was only when we introduced more intensive processes, such as significant database operation, that the load balancing determination began to move away from connection count.

It was at this point, however, that we uncovered what seems to be the only peculiarity of load-based connections. One of the most useful applications of Terminal Server is the ability to run tasks while a user is disconnected. Connect from a desktop to a terminal server, start that large month-end closing program, then disconnect and let it process without you. This works quite well in a determinate environment, but breaks down when dynamic load balancing is in place. The very fact that your large job is running on that server may work to force your connection elsewhere when you wish to reconnect.

In all, we found that the ease of installation, combined with the almost total absence of significant options for configuration and tweaking, pushes BCS firmly into that class of software best described as so straightforward that it's boring. In simple terms, BCS does what Cubix claims it will: load balancing. It's a no-frills product, but at a basic cost of $2,385 for a two-server cluster configuration, plus $695 for each additional server in a cluster, BCS compares quite favorably with higher-priced alternatives.

Balanced Cluster Service

Cubix Corp.

Carson City, Nev.

(800) 953-0155 www.cubix.com

Price: $2,385 for two-server cluster; $695 for each additional server in a cluster.

+ A "set-it-and-forget-it" product.

+ Easily handles standard office applications such as Word, Excel

and Outlook.

+ Compares favorable to higher-priced alternatives.

- Does not function with Terminal Server add-ons such as Citrix's MetaFrame.

- Network must support Windows Internet Name Service.

- All network servers in cluster must be on same subnet.

COPYRIGHT 1998 Boucher Communications, Inc.
COPYRIGHT 2000 Gale Group