Showing results for 
Search instead for 
Did you mean: 
Level 6

"The devil is in the details" is certainly true for multinode clustering. More and more enterprises are turning to multinode clustering for their high availability architectures to save on hardware costs, increase overall utilization, and reduce management headaches. But exactly how clustering is implemented makes a big difference in the value you get from it.

In a multinode cluster each standby or passive server can be the failover target for more than one active server. For example, an enterprise with three mission-critical applications could run them on a four-node cluster with three active servers (A, B, and C), each of which fails to the same passive server (D). The passive server is usually idle; it only becomes active when another server in the cluster fails.

It's not hard to see why this is an attractive option. With a two-node, active-passive architecture, six servers (three active, three passive) would be needed. That means three of the six servers are idle at any time—100% hardware overhead! With the four-node architecture, the overhead is just 33%.

Why the plus sign matters

Let's dig a little deeper into clustering technology. In a dedicated-spare (often referred to as "N-to-1") configuration a specific server (say D) must be chosen to be the dedicated standby server. This means that if server A fails its workload to server D, and then server A is repaired and put back on line, the application must be failed back to A to restore the clustering arrangement and create a spare once more (D). Server A can not become the "new spare". The result is more downtime—and another task for a busy IT administrator.

Veritas Cluster Server fully supports dedicated spare configurations; however, it also supports a more flexible approach known as roaming-spare (often referred to as "N+1"), meaning that the spare server (the +1) is free to roam around the cluster; it need not be a dedicated server. When active server A fails, passive server D takes over. When server A is repaired and put back on line, it becomes the new passive server—the application remains on D (see figure). As a result Veritas Cluster Server eliminates both the extra downtime and the extra task.

In summary. some clustering solutions use dedicated spares instead of roaming spares. The difference involves downtime and user intervention.

Smart failovers are the best failovers

There's more. Using the Intelligent Application Failover Policy of Veritas Cluster Server, you can configure a smaller application to fail over—not just to the standby server—but to another active server that has enough spare computing power to run it. In the example, if server B has enough spare CPU cycles to run the application on server A, server A can fail over to server B—keeping D available as a failover target for larger applications.

This highly granular active/active approach uses spare capacity instead of dedicated spares, and takes server utilization and hardware savings to new levels. Veritas Cluster Server has built-in policies to account for application compatibility, affinity, dependency, pre-requisites and more to ensure that applications intelligently fail over to the "best fit" server at that moment in time.

And the free, downloadable Veritas Cluster Server Simulator allows users to easily experiment with and tune their intelligent failover behavior before transferring the finished configuration to their real (not simulated) cluster.

Version history
Last update:
‎02-26-2009 03:06 PM
Updated by: