SQL Server Magazine

Always-On Design Guidelines
High availability isn't a product that you can buy—it's a goal. High availability is the result of carefully blended technologies, support services, and human processes. More important, high availability is about attention to detail and the discipline to manage every aspect of your environment. (For an overview of the high-availability goal, see David Chernicoff, "Components of a High-Availability System," November 2000.) At its simplest, high availability means increasing the time between failures and decreasing the time to recovery. Using the following basic guidelines, you can begin to take specific steps to improve your system availability:

• Use redundant components and automatic failover to eliminate single points of failure. Each redundant component should also be highly reliable. Possible single points of failure are sometimes obvious. When you're designing a high-availability system, the reliability of the power supply, the connection to the Internet, the disk drives, and the network components should be your primary concerns. Sometimes, however, you find potential single points of failure in unexpected places. For example, microsoft.com, msn.com, expedia.co.uk, and msnbc.com recently were unavailable for long periods of time. The rumor is that the root cause was a configuration change to a router at the edge of Microsoft's DNS network. Even the best sites can suffer from unexpected single points of failure.
• Comprehensively test new hardware and software. Maintain separate environments for production, development, and testing. You should document, justify, and fully test all proposed changes to the production environment.
• Reliable components are essential. Even when you configure a system as a redundant cluster node, be sure to configure the system to minimize the likelihood of failure. Consider implementing RAID 1 (i.e., duplex) mirroring on the boot partition. That way, if a controller fails, both halves of the mirror don't go down. Use redundant, hot-swappable power supplies, hot-swappable SCSI disks, error-correcting memory, and redundant fans.
• Reduce chances for human error. Minimize unstructured human contact with the system. Create processes that minimize the chance of failure and the time to recover. Use scripts to automate routine tasks. Use systems management tools to identify trends, conduct root-cause analysis, and trigger automatic responses to error conditions and events. Record the entire production infrastructure in a configuration management database (CMDB)—a centralized and comprehensive record of configurable items (CIs) in your IT infrastructure.

The primary goal of the Windows Datacenter Program is to use Win2K to host mission-critical applications that must be highly available and highly scalable. Remember that high availability isn't a Datacenter feature—that line of thinking is similar to believing that a great golf score is a feature of great golf clubs. High availability is a result of disciplined processes, only some of which are part of the Windows Datacenter Program.

Datacenter or Win2K AS?
In terms of OS stability, Win2K is a tremendous step beyond NT 4.0. One question you need to answer is whether you need Datacenter or Win2K AS. Table 4 shows obvious surface differences between the OSs. (For more information, see Greg Todd, "Windows 2000 Datacenter Server," December 2000, and "Microsoft Clustering Solutions," November 2000.)

Is Datacenter the answer for your application? Win2K AS provides many excellent and affordable improvements, including 2-node Cluster service clusters, 32-node Network Load Balancing (NLB) clusters, 16-node Component Load Balancing (CLB) clusters, and reliable restart in Microsoft Internet Information Services (IIS) 5.0. If you combine Win2K AS's features with disciplined backup, recovery, and change management, you can achieve two or even three nines of availability.

Reasons for choosing Datacenter over Win2K AS include the following:

• A memory requirement of greater than 8GB. Large databases and applications that you write specifically to take advantage of a large amount of memory (using Address Windowing Extensions—AWE) are good candidates for Datacenter.
• A stateful application that requires the extra availability that 3-node or 4-node clustering provides (compared with the 2-node clustering that Win2K AS provides). Cluster service clustering will enhance the availability of stateful applications. (For information about stateless versus stateful applications, see the sidebar "Scaling Up vs. Scaling Out.")
• A network-performance requirement for Winsock Direct (WSD). Using WSD, some vendors have boasted Gigabit speeds. (These claims are fairly controversial, considering Microsoft's recent removal of Giganet cards from the Data-center Hardware Compatibility List—HCL.)
• The need for a GUI-based process-control tool. A process-control tool lets network administrators easily enforce the terms of service level agreements (SLAs) with their customers. For example, an administrator can limit the amount of memory, number of processors, or amount of time available to any group of processes. Datacenter has such a tool; Win2K AS doesn't.
• The desire to access the Joint Support Queue's technical support resources, which are available only with the Windows Datacenter Program. The Windows Datacenter Program also provides change-management functions in the form of stress testing, signing, and certifying kernel-mode drivers; certifying hardware changes; and certifying application software.

Evaluate Applications
Now that you've worked through the costs associated with your downtime and reviewed the general guidelines for keeping systems available, the next step is to determine which of your applications can benefit from a Datacenter implementation. This assessment will depend on your current application architecture. Today, the applications that work most smoothly with Datacenter are n-tiered, COM-based, line of business (LOB) applications that store and retrieve data from a back-end data store (e.g., Microsoft SQL Server 2000).

At a basic level, an application has three functions:

• It interacts with the user to collect input and display output (i.e., a UI).
• It applies some transformation to collected input (i.e., business rules or logic).
• It stores information for later use or retrieval (i.e., data storage).

Prev. page     1 [2] 3 4     next page