Compaq ProLiant 2500 Compaq ProLiant Cluster HA/F100 and HA/F200 Administrator - Page 68
Failover/Failback Planning, Performance After Failover
View all Compaq ProLiant 2500 manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 68 highlights
Designing the Compaq ProLiant Clusters HA/F100 and HA/F200 2-37 In a clustered environment, IP addresses for the database are configured to fail over with the database application, making a backup IP address on the client unnecessary. When the database resources have failed over to the other server, the client can reconnect to the database using the same IP address as before the failure. This process may be automated if the client application software supports automatic connection retries. IMPORTANT: Examine these client configuration issues in a pilot and testing phase before implementing a clustered system. This will help you to identify any client reconfiguration requirements and understand how client applications will behave in a clustered environment, especially after a failure. Failover/Failback Planning The final section of this chapter addresses several factors to consider when planning for failover and failback events. s Performance of clustered servers after failover s Cluster server thresholds and periods s Failover of directly connected devices s Automatic vs. manual failover s Failover/failback policies Performance After Failover As applications or resources fail from one server to another, the performance of the clustered servers may change dynamically. This is especially obvious after a server failure, when all of the cluster resources may move to the other cluster node. Performance monitoring of server loads after a failure should be investigated prior to a full clustered system implementation. You may need additional hardware, such as memory or system processors, to support the additional workload incurred after a failover. It is also important to understand the performance impact when configuring server pairs in a failover cluster. If a business-critical database is already running at peak performance, requiring the server to take on the additional workload of a failed server may adversely affect business operations. In some cases, you may find it appropriate to pair that server with a low-load server, or even with a no-load server (as in an active/standby cluster configuration).