Clusters for Everyone

SITUATION 7
Schedule Upgrades to Your System
Problem: You would rather not spend all your nights and weekends upgrading your systems.

Solution: By putting your servers into a cluster group, you can manually fail over a node during working hours. Remember, the users are still working on the remaining node. Now you can apply a service pack, test it, and pray.

Once you are satisfied that the service pack changes are working, you can manually fail back the node and the workload. Any NT clustering solution currently available will work in this scenario.

SITUATION 8
Manually Load Balancing Your System
Problem: You have too many applications running on one server while another server is barely used.

Solution: Ordinarily, you have to take down both servers, change their configuration, and restart. If the servers are part of an active/active cluster group, you can manually fail over a single application without taking down an entire node. This approach effectively moves the application from one server to another.

You must make sure the solution supports application failover (as opposed to system failover). Application failover lets you fail over a single application without taking down the entire node, instead of failing over the entire system. For example, even though Octopus is active/active, it supports only system failover today, which requires taking down the node. However, soon after you read this article, Octopus SASO 3.0 will be shipping, and it supports application-level failover.

SITUATION 9
Two SQL Servers
Problem: You need high availability for users accessing two independent SQL Server databases, each running on a separate server.

Solution: You need an active/active application clustering solution so that both nodes can be running SQL Server simultaneously. This requirement eliminates Wolfpack from your list of choices, because it can run only one instance of SQL Server per cluster. However, Digital Equipment's Wolfpack clustering add-on pack and NCR's LifeKeeper let you run two copies of SQL Server in the same cluster, allowing each server to be the fallback for the other and thus increasing availability.

SITUATION 10
Scaling Exchange Problem: You want to scale Exchange to run faster and have high availability. You have a dual Pentium Pro server.

Solution: Adding two CPUs to your server configuration would be nice, but unfortunately, Exchange scales effectively to only two CPUs (for more information about Exchange's ability to scale, see Joel Sloss, "Optimizing Exchange to Scale on NT," November 1996). In fact, the next release of Exchange (version 6.0) has been dubbed the "performance release" and will address this scalability problem. Wolfpack won't address scalability until phase 2, which isn't due until 1998. So are we stuck?

Valence Research's Convoy Cluster claims to add availability and scalability for TCP/IP applications and to provide load balancing among nodes in a cluster. This product is primarily aimed at intranet applications. Convoy Cluster was not available when we tested solutions for this issue. If this solution can scale, it will leapfrog Wolfpack by a year.

Future Trends
As these scenarios demonstrate, Wolfpack is not the appropriate solution in every case. Even so, Wolfpack is having a huge effect on hardware and software vendors.

When Wolfpack phase 2 starts shipping in 1998, developers can use the Wolfpack APIs to create applications that will let cluster nodes work in parallel. The issue of scalability will start a heated debate among system vendors: Is a cluster of 4-way SMP systems better than 8-, 12-, and 16-way SMP systems? If the answer is yes, NT will never have to scale beyond four CPUs in a single system. As long as you can cluster 4-way systems and scale performance, NT will have a price and performance unrivaled in the marketplace.

In the early adoption phase, companies will want to buy complete cluster-in-a-box configurations, hoping to eliminate as many problems as possible. However, as clustering moves mainstream, users will demand the ability to mix and match components. Keeping up with NT's HCL is hard enough, and keeping up with the WHCL will be even harder. Octopus has been on the leading edge for more than two years, by letting users mix and match components easily. Other vendors will need to do the same.

As more system vendors support Wolfpack, additional features will provide a competitive advantage. For example, Digital supports Wolfpack, but also offers a cluster add-on package that lets both nodes of a cluster run SQL Server and gives existing users of Digital NT Cluster a migration wizard. Compaq, Tandem, and Dell will enhance their Wolfpack offerings by supporting ServerNet, a high-speed interconnect. NCR supports Wolfpack, but also supports LifeKeeper, which allows three-node clusters, compared with Wolfpack's two-node limitation.

Finally, look for other vendors to solve the scalability problem before Wolfpack. For example, Oracle Parallel Servers lets two or more Oracle database server nodes work on the same database, running queries in parallel on multiple nodes. Oracle will try to one-up Microsoft by shipping this level of scalability on NT before Microsoft can release the parallel version of SQL Server (version 8.0).