Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

Using Clusters to Increase Availability and Scalability

Different types of clusters provide different benefits. Network Load Balancing clusters are designed to provide scalability because you can add nodes as your workload increases. Server clusters increase availability of stateful applications, and they can also allow you to consolidate servers and save on hardware costs. Figure 6.6 shows the steps for planning cluster deployment.

Figure 6.6: Planning Cluster Deployment

Scaling by Adding Servers

Scaling by adding servers to a Network Load Balancing cluster is also known as scaling out. In Windows Server 2003, Network Load Balancing clusters can contain up to 32 nodes. Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, support server clusters containing up to eight nodes. For this reason, it is recommended that you use Network Load Balancing rather than server clusters to increase scalability. Additional servers allow you to meet increased demand on your Network Load Balancing clusters; however, not every organization has the budget to readily add hardware.

Table 6.2 summarizes the number of servers a cluster can contain, by cluster type and operating system.

Network Load Balancing Clusters also run on Windows Server 2003, Web Edition; the maximum number of nodes is 32.

Scaling by Adding CPUs and RAM

Your options for adding CPUs and RAM, also known as scaling up, depend on the server operating system. This is a less expensive scaling option than adding nodes, but you are limited by the capacity of the operating system.

Table 6.3 illustrates the CPU and RAM capacity in Windows 2000 and Windows Server 2003.

Availability and Server Consolidation with Server Clusters

While Network Load Balancing can meet your scaling needs, server clusters provide high availability for hosted applications by reducing the interruption of service due to unplanned outages and hardware failure.

Increasing the number of nodes in a server cluster proportionally increases the availability of the services and applications running on that server cluster. This is because spreading the workload over a greater number of nodes allows each node to run at a lower capacity. When failover occurs in a server cluster with many nodes, there are more servers available to accept the workload of the failed node. Similarly, when a server running at low capacity takes on additional processing after a failover, the failover is less likely to result in a decline in performance.

The hardware required for server cluster nodes is expensive, however. In some cases, it might be possible for you to save money on hardware by consolidating the number of servers or nodes you have deployed in your server clusters. You can still provide high availability of your mission-critical applications after server consolidation, but be aware that combining clusters to reduce the total number of nodes also reduces availability. This is a tradeoff that your organization should evaluate.

Figure 6.7 shows two clusters before consolidation, where two separate two-node clusters, each with one active and one passive node, provide service for a group of clients.

Figure 6.7: Two Server Clusters Before Consolidation

Two clusters, each dedicated to a separate application, generally have higher availability than one cluster hosting both applications. This is depends on, among other factors, the available capacity of each server, other programs that may be running on the servers, and the hosted applications themselves. However, if a potential loss in availability is acceptable to your organization, you can consolidate servers.

Figure 6.8 shows what the clusters in Figure 6.7 would look like if they were consolidated into a single three-node cluster. There is a potential loss in availability because in the event of a failure, both active clusters will fail over to the same passive node, whereas before consolidation, each active node had a dedicated passive node. In this example, if both active nodes were to fail at the same time, the single passive node might not have the capacity to take on the workloads of both nodes simultaneously. Your organization must consider such factors as the likelihood of multiple failures in the server cluster, the importance of keeping the applications in this server cluster available, and if potential loss in services is worth the money saved by server consolidation.

Figure 6.8: Consolidated Server Cluster

Evaluating Combining Cluster Technologies

You can use several Windows clustering solutions together, depending on the services and applications that you need to make highly available. Each cluster type performs a different role in a multicluster deployment. The most common scenario that combines all three clusters is an e-commerce Web site, where the front-end Web servers are configured in Network Load Balancing clusters that receive client requests, the middle-tier applications (such as the Microsoft BizTalk Server) use CLB clusters running on Windows Application Center 2000, and the back-end SQL database servers operate in a server cluster. Figure 6.9 illustrates a typical deployment, utilizing all three Windows clustering technologies.

Figure 6.9: E-Commerce Clustering Scenario

Evaluating Clustering Across Multiple Sites

Many organizations build disaster recovery and increased availability into their infrastructure by using multiple physical sites. Most designs involve a primary siteand one or more remote sites, where a remote site mirrors the primary site. The level at which components are mirrored between sites depends on the Service Level Agreement and the business requirements.

Geographically Dispersed Clusters

Geographically dispersed server clusters are possible in Windows Server 2003 by using virtual local area networks (VLANs)to connect SANs over long distances. Majority node set, a new type of quorum resource in Windows Server 2003, makes it easier for cluster servers to be geographically separated while maintaining consistency in the event of a node failure.

A geographically dispersed cluster is a combination of pieces supplied by hardware OEMs and software vendors. The configurations required can be complex, and the clusters must use only components supported by Microsoft. Geographically dispersed clusters should be deployed only in conjunction with vendors who provide qualified configurations.

For more information about geographically dispersed clusters and SANs, see "Designing and Deploying Server Clusters" in this book. For complete information on geographically dispersed clusters, see the Geographically Dispersed Clusters link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

MultiSite Network Load Balancing Clusters

Like geographically dispersed server clusters, Network Load Balancing clusters that span more than one physical site (sometimes known as stretch clusters) are intended to protect data in the event of a disaster. Additionally, multisite configurations can be used to provide local access to clients that are spread nationally or globally. For example, a Network Load Balancing cluster split between a data center on the East Coast and a data center on the West Coast can provide services to users in either location.

Unlike geographically dispersed server clusters, in most cases a single Network Load Balancing cluster is not deployed across multiple sites. Instead, multiple, independent Network Load Balancing clusters are deployed, typically with one cluster at each location. The sites are then combined into a single service using features such as DNS round robinto load balance client requests across the sites. Figure 6.10 illustrates a simple version of this scenario.

Figure 6.10: Multisite Network Load Balancing Configuration

In Figure 6.10, the client uses DNS to resolve the service name to an IP address. Depending on the IP address that the client receives, the request is sent to Site 1 or Site 2. In this type of configuration, the sites are essentially clones of each other, and the sites provide the same set of services. A Web site, for example, would be identical at either site, and clients receive the same response to a given query regardless of the site they are directed to. Not only are client requests load-balanced between the sites, but in the event that one site fails, the other site can continue responding to client requests. It is worth noting that when one site goes down, there is potential for a longer response time to individual requests, depending on geographical factors and network demand.