Will clustering help NT overcome its scalability challenge?
Is Windows NT ready for the enterprise? Windows NT Magazine continually examines this question. Rather than debate NT's readiness for business applications, in this article I'll examine scalability, a key component in making NT the right solution for enterprise applications. I'll discuss what NT clusters provide today and what the future holds for NT clusters in the areas of availability, systems management, and scalability.
Availability
How important is uptime to your enterprise environment? Do you know that the difference between 99 percent and 99.999 percent availability is the difference between 4 days and 5 minutes a year? Can you afford to be down 4 days a year, or is even 5 minutes of downtime too much? Your answers to these questions will help you determine how important availability is to your organization, and how much you are willing to spend to get it. If you have mission-critical applications (I define a mission-critical application as any application that can't be down during business hours) and your business runs 24 hours a day, 7 days a week, you must have maximum availability.
Clustering lets you link separate computers (or nodes) to work as a single system. For example, you can configure a cluster in which one server functions as a backup for another server. If one of the two clustered servers fails, the functioning server picks up the load. Currently, Microsoft Cluster Server (MSCS) handles two-node configurations, whereas Octopus and ArcServe Replication can handle eight-node clusters. The more nodes you have in a cluster, the more sophisticated the cluster's configuration can be. In my companion article, "NT Clustering Solutions Are Here," on page 125, I detail eight examples of cluster configurations currently in use.
Future MSCS and other clustering solutions will handle up to 16 nodes, which is a practical limit for most situations. Today, generic failover lets almost any application restart on a surviving node in a cluster in which a node fails. As developers engineer applications to become more cluster-aware, the availability of applications that restart on functioning nodes will increase. This restart capability is key in your consideration of NT as a platform for mission-critical applications.
Systems Management
Are you tired of waiting until after hours to upgrade your servers? Wouldn't you love to be able to take servers down in the middle of the day, when it's convenient for you? With clusters, you can. For example, say you have a clustered Web server with six nodes, and you want to add a service pack to one of the servers. You can manually fail over the node on which you intend to perform the upgrade, letting the other servers pick up the failed-over server's load. Then, you can perform the upgrade, test it, and manually fail the server back into the cluster. What's more, you can do all this work while your users access the cluster as usual.
Suppose you want to view the nodes in your cluster as a single image. With the proper clustering solution, a single-image view of multiple nodes is easy to accomplish. A single-image view will let you make changes affecting the entire cluster once, instead of making changes one node at a time.
In the future, you can perform all kinds of systems and network management of clustered nodes. Systems management software such as CA-Unicenter is already cluster-aware. Eventually, all systems management packages must become cluster-aware to compete effectively.
Scalability
If you've used NT, you've undoubtedly heard that NT doesn't scale. In fact, Microsoft's fate rests on how well the company answers the scalability challenge. If Microsoft can't change the widespread perception that NT doesn't scale, customers won't deploy mission-critical applications on NT and therefore won't buy BackOffice. Fortunately for Microsoft, almost every vendor with an enterprise solution is vying for NT-enterprise business. Most vendors with existing scalability solutions on other platforms are porting them to NT. This fact makes predicting the direction of NT scalability over the next few years easier, because we know how the existing solutions work today.
In some ways, the scalability issue is like US politics. The two primary parties are large symmetric multiprocessing (SMP) and clustering. These parties have been debating for years over who has the best solution to the scalability challenge. The SMP party believes the answer is building larger SMP machines: 8 CPUs, 16 CPUs, 32 CPUs, and so on. The primary benefit to building larger SMP machines, the SMP party says, is that application software doesn't need to change--the operating system (OS) does the work. In addition, the SMP party believes maintaining one system is easier than maintaining a bunch of smaller systems. Isn't it better to throw all your applications on one machine?
Large-scale SMP
The SMP camp has many hurdles to overcome. The first is that applications written for NT Server don't behave well together. Windows NT Magazine's Web master, T.J. Harty, tried a simple experiment (see "Web Structure and Infrastructure," November 1997) that illustrates this problem. He ran Internet Information Server (IIS) and SQL Server on one 4-way SMP machine, then he ran them separately on two 2-way SMP machines. When he compared performance, T.J. found that running these applications on separate machines resulted in far better performance than running them together on a single machine did. Why? Because BackOffice and other NT Server-based applications contend for control of the system they're running on. These applications were designed to run on separate machines, not to run together on the same server. Microsoft almost always recommends running server-based applications on separate NT servers. The exception is Small Business Server (SBS), and with SBS you can accommodate a maximum of only 25 users.
A second hurdle is that large-scale SMP machines are expensive. As you increase the number of CPUs, the complexity that results from keeping the caching systems synchronized increases exponentially. This increased complexity will drive up the cost of manufacturing large-scale SMP machines. The newest trend in manufacturing these machines is to link two 4-way SMP motherboards with a Corollary bridge to create an 8-way motherboard. Intel has started production on units that follow this trend, and most server vendors are now shipping these systems. The solution is to get the cost of one 8-way system down to the cost of two 4-way systems, which isn't a likely possibility. Sequent Computer Systems, for example, is working on 16- and 32-way systems using its shared-memory model, NUMA-Q. Although several manufacturers will build 16- or 32-way systems, the cost of these systems will be prohibitive for most organizations.
A third hurdle to large-scale SMP is NT's thread scheduler and its limitations. Mark Russinovich has pointed out (see "Inside the Windows NT Scheduler, Part 2," August 1997) that NT's scheduler experiences performance problems when the number of CPUs increases. This limitation might explain the challenge NT Server-based applications such as SQL Server and Exchange face in scaling past 4 CPUs. Some vendors would have you believe that an 8-way SMP machine can run SQL Server, for example, twice as fast as a 4-way machine can. But NT Server applications don't scale in a linear fashion. Instead of producing 100 percent improvement by adding 4 additional CPUs, going from 4 to 8 CPUs might represent only a 60 percent to 75 percent improvement in throughput and performance.
There's another challenge to building large-scale SMP systems: NT's 4GB of RAM limit. When you increase the number of CPUs, you simply move the bottleneck to the overall system memory. Currently, only Digital's Alpha-based systems can overcome this problem when they're paired with the beta version of NT 5.0's 64-bit very large memory (VLM). This configuration lets an Alpha-based system address up to 32GB of RAM. Until Intel's Merced chip is available, most hardware server vendors will not achieve the desired level of scalability on their 8-way or higher SMP machines.
Here's a final problem: Having one SMP machine doesn't resolve the need for availability. If you have one large SMP machine and it fails, you're hosed.