Second, no ne of the products provide advanced alerting. They all report to the NT event log, and some allow for a command file to be executed before, during or after a failover, but none provide other alerting features via e-mail, pager or Simple Network Management Protocol (SNMP) traps. The addition of custom alerting would not be too much to ask--especially considering the price tags of these products, which range from $3,000 for Octopus 2.0 with SASO to $5,000 for VERITAS FirstWatch. You expect a failed node to elicit red lights, sirens, SNMP traps, pager and e-mail alerts, and the lack of these severely limits the potential of these solutions.

Third, we were disappointed that none of the products--except for Microsoft Cluster Server--supports NT's Registry. Many apps make use of the Registry: SQL Server 6.5 uses it to store replication information, and Allaire Cold Fusion uses i t to track client state information. In Microsoft Clustering Server, parts of the Registry can be staged and copied to the backup node in the event of a failure.

So, which would we recommend for high-availability systems? Every product we tested has its strengths and weaknesses--and not one fits every scenario. In fact, most don't even compete directly. For instance, a high-availability hardware solution, Marathon Technologies' Endurance 4000, would satisfy the need for a very highly available node in a cluster or failover solution (see "A System With Muscle," on page 78), while Octopus' product could be used to mirror data in a VERITAS cluster.

Nevertheless, Octopus Server 2.0 with SASO would be our product of choice. It offers the greatest flexibility, allowing one system to be backed up by multiple systems or vice versa. It can run over any protocol on any hardware on a single network connection or multiple network connections. At $3,000, it was also the least expensive standalone product tested and earns our "Best Value" award.

Our second choice is VERITAS FirstWatch, which provides good failover capabilities. Its design let s administrators customize individual application agents easily. In addition, its architecture lets one system be failed over to another node while continuing to manage the original node. We also would keep an eye on Microsoft's Clustering Service. It provides the best administrative utility, supports the staging of Registry information and is well-integrated with NT.

Microsoft Wolfpack Clustering for Windows NT Server (Beta 2)
Regardless of how well other products perform or which features are coming down the pipe, Microsoft's Wolfpack, also known as Microsoft Cluster Server (MCS), will become the de facto solution.

First, it won't cost you an extra $3,000 to $4,000 per cluster--the price of the other products tested. Second, Microsoft enjoys the unbridled support of most hardware and s oftware vendors. Some vendors, including Vinca, support this product as well. We wouldn't dare say Microsoft has an unfair competitive advantage, but when you also make the operating system, the client software and the application software, you do have the upper hand.

Does that mean MCS, which will be bundled into NT Server (Enterprise Edition), is best? No. Would we recommend it for immediate implementation? No. Will it be the best product in two or three years? Probably, given Microsoft's deep pockets.

For a Beta 2 release (a general availability release is scheduled for later this summer), MCS is not a bad product, though we did experience enough problems to say it's best-suited for an evaluation lab until the next release or patch becomes available. Candidly, we would wait for MCS 1.x or 2.0. This product represents Phase 1, providing failover between just two nodes. Microsoft says Phase 2, coming later this year or in 1998, will provide clustering of up to 16 nodes for both availability and scalability. For this to happen, though, changes must occur not only in the NT OS, but also in network applications, if they are to fully exploit NT and MCS.