If you are working with greater than two-node clusters, consider logical host availability when planning your upgrade. Depending on the cluster configuration, it might not be possible for all logical hosts to remain available during the upgrade process. The following configuration examples illustrate upgrade strategies that minimize downtime of logical hosts.
Table 4-1 shows a four-node cluster with four logical hosts defined. The table shows which physical nodes can master each of the four logical hosts.
To upgrade this configuration, you can remove nodes 1 and 3 from the cluster and upgrade them without losing access to any logical hosts. After you upgrade nodes 1 and 3 there will be a brief service outage while you shut down nodes 2 and 4 and bring up nodes 1 and 3. Nodes 1 and 3 can then provide access to all logical hosts while nodes 2 and 4 are upgraded.
Table 4-1 Four Nodes With Four Logical Hosts
|
Logical Host 1 |
Logical Host 2 |
Logical Host 3 |
Logical Host 4 |
Node 1 |
X |
X |
|
|
Node 2 |
|
X |
X |
|
Node 3 |
|
|
X |
X |
Node 4 |
X |
|
|
X |
In an N+1 configuration, one node is the backup for all other nodes in the cluster. Table 4-2 shows the logical host distribution for a four-node N+1 configuration with three logical hosts. In this configuration, upgrade node 4 first. After you upgrade node 4, it can provide all services while nodes 1, 2, and 3 are upgraded.
Table 4-2 Three Nodes With Three Logical Hosts
|
Logical Host 1 |
Logical Host 2 |
Logical Host 3 |
Node 1 |
X |
|
|
Node 2 |
|
X |
|
Node 3 |
|
|
X |
Node 4 |
X |
X |
X |