Implement high-availability solutions with HP Instant Capacity - easily and effectively
5
Upon a Serviceguard node failure, the Serviceguard packages protecting the applications on the failed node are failed
over to another node within the cluster as defined in the package configuration. The following list shows several models
for configuring Serviceguard clusters to handle package failovers:
• Active/Standby: one or more cluster nodes are reserved for failover use. Upon a failover, applications maintain their
level of performance by using the spare capacity provided by the standby node.
• Rotating standby: upon a failover, the standby system becomes the new production system, and the repaired system
becomes the new standby system.
• Active/Active: all nodes in the cluster run different applications. Upon a failover, you have three choices:
1. Executing at a reduced capacity while the failover and existing applications run on the same node
2. Shutting down less critical applications to allow more system resources for the failover application
3. Using technologies such as iCAP to deliver resource entitlements on the failover node
• Distributed active/active applications: all nodes in the cluster run an instance of the same application, such as Oracle
Real Applications Cluster (RAC), which depends on having shared read/write access to data. Upon a failure of a node
(or instance), there is no failover of the application as users are simply redirected to one of the remaining nodes.
In the active/standby and rotating standby failover models, the processing capacity requirements for the standby node
depend on the performance level required during active node downtime (that is, running at reduced performance for a
short time while the active node is down or running at the same performance level as during normal operation). One
advantage of this model is that you always have a node available when a downtime event occurs. However, one
disadvantage is the expense incurred by adding to the cluster another server resource only used during downtime.
In each of the above models, iCAP can be used to move resources from a failed node to increase the capacity of either
the failover node or the remaining nodes.
Determining high-availability requirements
While HP servers are designed for the highest possible availability and reliability, downtime is still inevitable
for planned maintenance and unexpected failures. In this paper, all types of downtime are referred to as
“failover situations.”
The goal of any high-availability solution design is to minimize planned and unplanned downtime associated with an
application so that the service maintains the highest level of availability required for the user. Availability and
performance goals must be established to help define the hardware requirements for a cost-effective high-availability
design. You should consider the following questions when designing a high-availability solution:
• What is the impact and cost of planned and unplanned downtime to the business or organization?
• What applications must remain operational in the event of a failure?
• What are the critical failures to protect against? What is the scope of the required redundancy to eliminate single
points of failure?
• Is a fully redundant system cost-effective, or can iCAP be used to help reduce total ownership costs?
• Do you need to provide automation for the failover/failback of specific applications?
• What level of performance is required after a failover?
Is additional processing capacity required after a failover to meet specific SLOs?