3. Creating an Application Deployment Plan
The
stateful applications that server clusters host usually have greater
capabilities than the stateless applications used on Network Load
Balancing clusters. This means that you have more flexibility in how
you deploy the applications on the cluster. Windows Server 2003 can
host the following two basic types of applications in a server cluster:
Single-instance applications
Applications that can run on no more than one server at a time, using a
given configuration. The classic example of a single-instance
application is the DHCP service. You can run a DHCP server with a
particular scope configuration on only one server at a time; otherwise,
you risk the possibility of having duplicate IP addresses on your
network. To run an application of this type in a cluster, the
application can be running on only one node, while other nodes function
as standbys. If the active node malfunctions, the application fails
over to one of the other nodes in the cluster.
Multiple-instance applications Applications in which duplicated (or cloned) code can run on multiple nodes in a cluster (as in an NLB cluster) or in which the code can be partitioned,
or split into several instances, to provide complementary services on
different cluster nodes. With some database applications, you can
create partitions that respond to queries of a particular type, or that
furnish information from a designated subset of the database.
Deploying Single-Instance Applications
Deploying
one single-instance application on a cluster is simply a matter of
installing the same application on multiple nodes and configuring one
node to be active, while the others remain passive until they are
needed. This type of deployment is most common in two-node clusters,
unless the application is so vital that you feel you must plan for the
possibility of multiple server failures.
When
you plan to run more than one single-instance application on a cluster,
you have several deployment alternatives. You can create a separate
two-node cluster for each application, with one active and one passive
node in each, but this requires having two servers standing idle. You
can create a three-node cluster, with two active nodes, each running
one of the applications, and one passive node functioning as the
standby for both applications. If you choose this configuration, the
passive node must be capable of running both applications at once, in
the event that both active nodes fail. A third configuration would be
to have a two-node cluster with one application running on each, and
each server active as a standby for the other. In this instance, both
servers must be capable of running both applications.
|
This
talk of running multiple applications on a server cluster introduces
one of the most important elements of cluster application deployment:
capacity planning. The servers in your cluster must have sufficient
memory and enough processing capabilities to function adequately in
your worst-case scenario.
For example,
if your organization is running five critical applications, you can
create a six-node cluster with five active nodes running the five
applications and a single passive node functioning as the standby for
all five. If your worst-case scenario is that all five active nodes
fail, the single passive node had better be capable of running all five
applications at one time with adequate performance for the entire
client load.
In this example, the
possibility of all five active nodes failing is remote, but you must
decide on your own worst-case scenario, based on the importance of the
applications to your organization.
|
Deploying Multiple-Instance Applications
In
a multiple-instance application, more than one node in the cluster can
be running the same application at the same time. When deploying
multiple-instance applications, you either clone them or partition
them. Cloned applications are rare on server clusters. Most
applications that require this type of deployment are stateless and
better suited to a Network Load Balancing cluster than to a server
cluster.
Partitioning
an application means that you split the application’s functionality
into separate instances and deploy each one on a separate cluster node.
For example, you can configure a database application on a four-node
server cluster so that each node handles requests for information from
one fourth of the database, as shown in Figure 5.
When an application provides a number of different services, you might
be able to configure each cluster node to handle one particular service.
Note
With
a partitioned application, some mechanism must distribute the requests
to the appropriate nodes and assemble the replies from multiple nodes
into a single response for the client. This mechanism, like the
partitioning capability itself, is something that developers must build
into the application; these functions are not provided by the
clustering capability in Windows Server 2003 by itself. |
Partitioning
by itself can provide increased application efficiency, but it does not
provide high availability. Failure of a node hosting one partition
renders part of the database or certain services unavailable. In
addition to partitioning the application, you must configure its
failover capabilities. For example, in the four-node, partitioned
database application mentioned earlier, you can configure each
partition to fail over to one of the other nodes in the cluster. You
can also add one or more passive nodes to function as standbys for the
active nodes. Adding a single passive node to the four-node cluster
would enable the application to continue running at full capacity in
the event of a single node failure. It would be necessary for servers
to run multiple partitions at once only if multiple server failures
occurred.
Planning
Here
again, you must decide what is the worst-case scenario for the cluster
and plan your server capacity accordingly. If you want the four-node
cluster to be able to compensate for the failure of three out of four
nodes, you must be sure that each server is capable of running all four
of the application’s partitions at once. |
If
you plan to deploy more than one multiple-instance application on your
cluster, the problem of configuring partitions, failover behavior, and
server capacity becomes even more complex. You must plan for all
possible failures and make sure that all the partitions of each
application have a place to run in the event of each type of failure.
