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

Determining How to Deploy Applications

Some of your deployment decisions are dictated by the application you plan to deploy in the server cluster. Figure 7.3 displays the process for analyzing your application and determining the best way to deploy the application in a server cluster.

Figure 7.3: Determining How to Deploy Applications

Evaluating the Application

You need a thorough understanding of your application's installation needs before deploying the application in a server cluster. For every application that you intend to install in a server cluster, check the documentation or contact the software vendor about installation issues in general and clustering considerations in particular.

The information you need before deploying an application in a server cluster includes:

Setup information. How the application setup works, such as where the application is installed and where supporting data for the application is installed. When installing Microsoft Exchange 2000 Server on a server cluster, for example, the log files and database in each storage group must be on the cluster's shared disk. This allows the log files and the storage group databases to fail over to another node if the Exchange virtual server goes offline.

Upgrade information. When it is time to upgrade the application, can the application be upgraded online, or will the server cluster need to be taken offline?

Application behavior during failover. Anticipating application behavior during failover will also help to optimize your deployment. In Microsoft SQL Server™, Microsoft recommends making all transactions as small as possible because the startup process for SQL virtual servers includes going through the transaction log for each database and rolling transactions back or forward. Therefore, larger transactions, especially with a large volume of transactions, could result in slower failover time.

Choosing a Method for Deploying an Application on a Server Cluster

The best method for deploying an application on a server cluster depends greatly on what type of application it is. Applications running on a cluster can be characterized in two ways: single-instance and multiple-instance. The way your application behaves in a server cluster depends on which type (single-instance or multiple-instance) it is. This means that your deployment method can also vary by application type.

Deploying Single-Instance Applications

With single-instance applications, only one application instance is running on the cluster at any time, and the application typically has data sets that cannot be partitioned across multiple nodes. The Dynamic Host Configuration Protocol (DHCP) service is an example of a single-instance application. The set of leased IP addresses that the application provides is small, but would be complicated to replicate across a cluster. Therefore the DHCP instance exists as a single instance, and high availability is provided by failing over the instance to another node in the cluster.

Figure 7.4 illustrates a single-instance application, named "App," in a four-node cluster. Only one node is currently hosting the application. If that node fails, the application can fail over to one of the other three nodes (the failover options are represented by dotted lines). All four nodes are connected to the application data source, but only the node currently hosting the application can access the data source.

Figure 7.4: Single-Instance Application

Deploying Multiple-Instance Applications

With a multiple-instance application, either multiple instances of the same code, or different pieces of code that cooperate to provide a single service, can run on a cluster. In both cases, the client or end user sees only one partition of an application. Applications can be either cloned or partitioned to create multiple instances in a cluster.

Cloned Applications

In a cloned deployment, multiple instances of the same code are executed on the same data set. Cloned applications are more commonly deployed in Network Load Balancing clusters than in server clusters, because cloning is ideal for stateless applications, which are applications with data that is rarely updated or that is read-only. Server clusters are designed for applications such as databases and messaging systems that have frequently updated data. For more information about Network Load Balancing clusters, see "Designing Network Load Balancing" in this book.

Partitioned Applications

Server clusters are designed for stateful applications, which are applications with frequently updated data sets and long-running in-memory states. Most stateful applications can be partitioned. A large database, for example, can be partitioned so that names beginning with A through L are in one database partition, and those beginning with M through Z are in another database partition. In other applications, functionality — rather than data — is partitioned. After they are partitioned, the different functions are deployed across a set of nodes in a cluster.

In order to represent a single application instance to clients or end users, a partitioned application requires an application-dependent decomposition, routing, and aggregation mechanism that allows a single client request to be distributed across the set of partitions. Then the results from the partitions need to be combined into a single response back to the client. This mechanism depends on the type of application and type of data returned, and is therefore application-specific. The query engine in SQL Server performs this splitting and aggregating. In Exchange 2000 Server clusters, the Exchange front-end server uses the Active Directory directory service to perform this task.

Figure 7.5 shows an example of a partitioned application in which a database of customer names has been partitioned on a four-node cluster. The solid lines represent each node's connection to its partition of the database; the dotted lines represent the application's access to a given partition as needed.

Figure 7.5: Data Partitioning for an Application on a Cluster

When a client issues a query such as "return all records" across multiple instances, the request is split across the instances and — after results are collected — aggregated back into a single result, which is passed back to the client.

A deployment such as the one in Figure 7.5 allows for scalability, because more servers can be added to house additional partitions, but it does not provide high availability. If one of the nodes fails, that part of the data set is no longer accessible.

As mentioned above, an application can also be partitioned by functionality. Figure 7.6 shows a multiple-instance application deployment, where functionality, not data, is shared among the nodes.

Figure 7.6: Functional Partitions

When a client request is introduced to the server cluster in Figure 7.6, the request is directed to the appropriate node, depending on the nature of the request. A billing inquiry, for example, is handled by the node designated for that function. The billing node is the only node with access to the billing database.

The deployment of an application across a server cluster depends on the style of application (single-instance versus multiple-instance) and the number of applications that you plan to deploy in the same cluster.

The following sections describe the most common application deployment options.

One single-instance application One node in the cluster executes the application, servicing user requests. The remaining nodes are on standby, ready to host the application in the event of failover. This type of deployment is well suited for a two-node active-passive cluster in which one node runs the applications and the second node is on standby. This deployment is not typically used in clusters with three or more nodes, however, because of hardware costs. In a cluster of N nodes, only 1/N of total processing power is used. Although availability of the single application is high, even in a two-node cluster hardware costs are higher than with other deployment options because of the cost of purchasing standby servers. Some multiple-instance applications, such as SQL Server, can be deployed as a single instance. In the case of SQL Server, when a node in the cluster running SQL Server fails, the entire SQL Server workload is transferred to another, identically configured node.

Several single-instance applications Each application is independent from the others, and different applications can fail over to different nodes in the cluster. For more information about defining failover targets, see "Creating Failover Policies" later in this chapter. This type of deployment provides high availability for applications, but careful capacity planning is required to ensure that each node has sufficient processing capacity, memory, and bandwidth to accommodate additional loads in the event of failover.

One multiple-instance application The cluster supports only one application, with pieces of the application hosted on different nodes. When there is a failover with a partitioned application, a node can host multiple partitions until failback. In SQL Server and other multiple-instance applications, it is important to make sure that each node has the capacity to take on additional partitions in the event of failover.

Several multiple-instance applications Each node hosts one instance of each application. In such a deployment, both capacity planning and defining failover targets become increasingly important and complex.

Planning for Server Capacity

Before deploying your application on a high-availability server cluster, you need to answer some key business questions:

How many servers are available for your cluster and what is the capacity of each server?

In the case of a failover, what kind of performance is acceptable until failback returns the cluster to full processing capacity?

Given that it is possible for more than one node in a cluster to fail, how many failures do you want your cluster to be able to withstand before the application becomes unavailable?

The workload of a server both before and after failover is closely tied to your server resource planning. The way your application adapts to the server cluster depends on how much of the server resources it consumes. The consumption of server resources affects the number of servers you need to ensure high availability for the application, in addition to how many servers are required to pick up the workload for a given node in the event of a failover.

Consider a simple example: a two-node cluster, with Node A and Node B. If Node A fails over, Node B has to continue processing its own jobs in addition to processing the jobs that fail over from Node A. This means that prior to failover, both nodes can operate at a maximum of 50 percent capacity. After failover, Node B operates at 100 percent capacity. When any server operates at maximum capacity, performance is compromised. However, even reduced performance is preferable to completely losing Node A's workload, which is what would happen in a nonclustered environment. In this example, an organization would have to determine if this level of availability is sufficient for its needs, or if an expenditure on more hardware is warranted.

If you add a third node to the above example and all three nodes operate at 50 percent, the two remaining nodes can divide the workload of a failed node. If Node A fails over, Node B and Node C assume Node A's work and operate at 75 percent capacity, which provides better application performance than a single server operating at 100 percent capacity. However, if two nodes in this cluster were to fail over, the remaining node would not have sufficient capacity to assume the processing for the entire cluster.

Windows Server 2003 supports up to eight nodes in a cluster. With additional nodes, you have more options for distributing the workload in a cluster.

Cluster Server Capacity Examples

The following illustrations of a simple four-node cluster demonstrate how server load can be balanced across nodes. These examples also demonstrate the relationship between hardware resources, fault tolerance, and availability.

In Figure 7.7, all four nodes are operational, each running at 25 percent capacity.

Figure 7.7: Cluster Under Normal Operating Conditions

Figure 7.8 shows the cluster after one of the nodes fails. The remaining three nodes each receive a share of the failed node's work.

Figure 7.8: Cluster After a Single Node Failure

After two nodes fail, shown in Figure 7.9, the remaining two nodes are each operating at approximately 50 percent capacity.

Figure 7.9: Cluster After Two Failures

Finally, when three nodes fail, as shown in Figure 7.10, the remaining node has enough capacity to take over the clusters' entire workload (though application performance might be degraded somewhat with the server operating at 100 percent capacity).

Figure 7.10: Cluster After Three Failures

Deployment Considerations

When determining the appropriate size of your server cluster (the number of nodes and their capacity) and the failover policies for one or more applications, consider the following points:

The cluster configuration in Figure 7.7 through Figure 7.10 is able to tolerate three failures with no loss of availability for clients and users. The cost of this availability is the price of four servers of sufficient capacity. For example, if the above nodes were running at 50 percent or 75 percent capacity, the same amount of work could be done with fewer nodes (or the same number of nodes could do more work). However, the cluster would then be unable to accommodate three failures; the remaining nodes would already be at full capacity by the time the third node failed. If you don't need to anticipate three failures, you could use fewer nodes running at a higher capacity than 25 percent.

In Windows Server 2003, Cluster Administrator allows you to designate applications to fail over to specific nodes. If your application cannot afford to lose any performance when it fails over to another node, configure failover distribution so that the application fails over to a node with plenty of room (running at low capacity). Again, this requires a hardware investment in order to have a server standing by for the purpose of failover.

If some decline in performance is acceptable for your application, specifically during the time it takes to get the failed node restarted, you can fail over the application to a node that is operating at a higher capacity. This means you can use fewer nodes, but the chances are higher that performance on the new node will decrease after failover.

If some applications are a higher priority than others to your organization, you can use Cluster Administrator to fail over the high-priority applications before the others. This is useful in deployments where multiple failures cannot be tolerated due to capacity limitations. In this case, if both a high-priority application and a lower-priority application fail over and need to find room elsewhere in the cluster, the high-priority application always takes precedence.

In planning server capacity (and in all other aspects of cluster deployment planning), it is important that you consider scalability and future demands on your cluster. It is very likely that over time your applications will grow, or you will need to deploy more applications on a cluster, or both. When calculating how many servers you will need and how much capacity each server needs to have, a general IT principal is to increase your estimates by 30 percent, and then add capacity for anticipated future growth. The extra 30 percent provides a safety buffer against calculation error or unforeseen load additions.

Creating Failover Policies

To provide high availability, single-instance applications — and the individual partitions of multiple-instance applications — fail over from one cluster node to another. In a two-node cluster, failover involves transferring the resources of one node to the remaining node. As the number of nodes in a cluster increases, different failover policies are possible.

When you create failover policies, you must perform each of the following tasks:

Make key failover policy decisions.





Evaluate N+I failover policies.





Evaluate random versus customized failover control.

Making Key Decisions in Failover Policies

You need to make the following decisions when planning and configuring your failover policies:

How many nodes, such as standby servers, do you deploy for failover?

What resources do you fail over to which nodes?

Do you partition applications and services across cluster nodes, or do you distribute the load differently?

How do you consolidate resources into resource groups? A group is the indivisible unit (a collection of resources) that fails over from one node to another.

Many of the key decisions in failover policies involve weighing the benefits of implementing the best possible solution against the cost of purchasing and maintaining hardware. For example, do your applications and services need the highest level of availability, or is your organization willing to settle for a slightly lower level of availability at a greatly reduced cost? If you decide to purchase standby servers that are dedicated to receiving specific applications in the event of failover, be sure your budget can accommodate the additional cost.

Evaluating N+I Failover Policies

The most common modeling used for failover policies is N+I, where N nodes are hosting applications and I (idle) nodes are standing by as spares. The simplest method for providing failover is to match each node with its own idle failover node: in a three-node cluster that would be 3+3. This design achieves the highest level of availability, but requires an investment in hardware that remains idle much of the time.

A failure on a cluster might result in an impact on users that can range from slow performance to application unavailability. When deploying an N+I solution, extensive testing must be done to ensure that, in the case of a massive failure, one node can run all applications and services with little or no user impact.

N+I configurations are scalable and good for handling multiple failures. An example of an N+I configuration is shown in Figure 7.11.

Figure 7.11: N+I Configuration

The configuration shown in Figure 7.11 is a good configuration if your application must continue running without any decrease in performance after failover. This configuration guarantees that the application will fail over to a node with 100 percent available resources and not to a node already in use by another application or another partition (assuming there has not already been another failover in the same server cluster).

Exchange 2000 Server is a good example of an application suited for an N+I server cluster deployment. In a four-node cluster, Microsoft recommends three active nodes and one node on standby (3+1). Because Exchange can have large memory and processing requirements, it is better to have a resource group in an Exchange cluster fail over to a node with 100 percent available resources. The potential drawback is that only one node failure is supported in this scenario.

Standby Server

A variation of N+I, a standby server configuration has idle nodes prepared to take on the work of one or more active nodes. Standby servers are effective for maintaining a consistent performance level for your users even after failover. A three-node version of a standby server configuration is illustrated in Figure 7.12.

Figure 7.12: Standby Server Configuration

Standby servers are good for larger applications that require a lot of resources such as processing power, memory, and input/output (I/O) bandwidth. In the event of a failure on one node, all applications are still hosted on separate servers. In Figure 7.12, for example, App1 and App2 are large applications. Combining them on the same node might require more processing or capacity than a single node could provide. With a standby server configuration, if Node A were to fail, App1 would move to Node B and the applications would remain on separate nodes. It is easy to plan server capacity for this failover policy; the size of each node is based on the application that it will be running, and the capacity of the spare server is sized to the maximum of the other nodes.

The drawback of this failover policy is that there is a single point of failure. In Figure 7.12, for example, if Node A failed, and App1 moved to Node B, no failover could take place if Node B were to also fail. This type of configuration also does not support multiple failures well. For example, if both Node A and Node C were to fail, Node B would not have sufficient resources to run both applications. This example shows a three-node cluster, however. In larger clusters (up to eight nodes) you can configure a variety of standby combinations to eliminate a single point of failure.

Failover Pairs

Failover pairs are another common N+I variation. Failover pairs are often used in clusters with four or more nodes, and they are ideal for ensuring performance consistency after failover. Failover policies can be defined so that each application can fail over between two nodes, such as in the four-node cluster illustrated in Figure 7.13. Here, Node A is paired with Node B, and Node C is paired with Node D.

Figure 7.13: Failover Pair Server Configuration

Failover pairs are also good for larger, resource-intensive applications such as databases. For capacity planning, you must ensure that each node in the pair can accommodate the application in question. Compared to a standby server policy, failover pairs have the added benefit of being part of a larger cluster. If the failover node needs to be brought down for maintenance, for example, a different failover node for the application can be assigned dynamically.

The disadvantage of failover pairs is that in simpler configurations, such as the one illustrated in Figure 7.13, only 50 percent of the cluster resources are ever in use. Also, depending on the number of nodes and the specific failover policies configured on the nodes, multiple failures in this kind of cluster might require administrators to manually failback resources when nodes are restored.

Evaluating Random vs. Customized Failover Control

Depending on the size and complexity of your server cluster, and the resources at your disposal, you might want to enact precise control over failover policies. Alternatively, you can let Windows Server 2003 determine the failover location for an application randomly.

Random Failover Policies

In clusters that run several small application instances, where the capacity of any node is large enough to support several instances at a time, random failover policies work well. Random failover policies are not recommended for large clusters (four or more nodes) because, given the great number of combinations of nodes, resources, and failures, there is no way to prevent some nodes from becoming overloaded while other nodes are underused.

When a resource group has an empty preferred owners list, and the node hosting that group fails, Windows clustering randomizes the failover target for the group. Assuming there are sufficient resources and application instances in a cluster, random failover in a small cluster can actually load balance applications across cluster nodes. Random failover is also well able to handle multiple failures.

The disadvantage of random failover policies is that you might find it difficult to plan capacity because statistically there is no guarantee that applications will be equally divided across nodes. Similarly, the effect on the performance of an application after failover is also difficult to predict. Random failover policies are not recommended in clusters with large, resource-intensive applications.

Customized Failover Policies

Targeting specific applications to specific nodes gives the administrator full control over what happens when a failure occurs. It also makes capacity planning easy, because you know which application is going to run on which server.

Group affinity is an attribute of a dependency between groups that determines the groups' relative location in the server cluster. For resources and resource groups that have no requirements for specific hardware or configurations, it might not matter where the resource groups are hosted on the cluster. There are circumstances, however, where the location of one group can affect the location of other groups. Groups can be set up to have strong or weak affinity. With strong affinity, they will be placed together on the same node, if possible. They can also be set up to have strong or weak anti-affinity. With strong anti-affinity, groups will be kept apart if at all possible. Exchange virtual servers are an example of groups that use anti-affinity, because running more than one instance of Exchange on the same node is not recommended.

If you have multiple applications, defining good policies for each can be difficult. In the event of multiple failures, it is difficult to account for all the possible combinations of application and server failures. For more information about configuring group affinity, see article Q296799, "How to Configure Windows Clustering Groups for Hot Spare Support." To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.