HP ProLiant 4500 Compaq ProLiant Cluster HA/F100 and HA/F200 Administrator Gui - Page 68

Failover/Failback Planning, Performance After Failover

Get HP ProLiant 4500 PDF manuals and user guides View all HP ProLiant 4500 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).

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
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.
■
Performance of clustered servers after failover
■
Cluster server thresholds and periods
■
Failover of directly connected devices
■
Automatic vs. manual failover
■
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).