- Cluster Design Guidelines
- Creating a Failover Matrix
- Application-Specific Design Guidelines
- Clustering Without Shared Storage
Creating a Failover Matrix
When a failover occurs, your cluster resources will be loaded on another node in the cluster. The order in which the resource will fail over to other nodes is predefined in the cluster resource. By default, the list of servers to which the resource will fail over is populated with all the nodes in the cluster, in alphabetical order. This means that a resource loaded on OESNW1 will fail over to OESNW2. When OESNW2 is not available, it is loaded on OESNW3, and so on. When OESNW2 holds the resource and crashes and OESNW1 is not online, it will also go to OESNW3. If OESNW1 is online at the time of the OESNW2 crash, the resource will be loaded on OESNW1.
With the default scenario all resources will be moved to the same server. Therefore, it is a good idea to set up a failover matrix to design the failover paths. With such a matrix a basic level of load balancing is possible. Table 3.1 contains an example of a three-node cluster with six resources that will all follow a different path when the server they are assigned to fails. You implement these failover paths by assigning a different load order, or priority, for each cluster resource.
Table 3.1. An Example of a Cluster Failover Matrix
Resource |
Prio 1 |
Prio 2 |
Prio 3 |
Data volume |
OESNW1 |
OESNW3 |
OESNW2 |
Apache/MySQL |
OESNW2 |
OESNW1 |
OESNW3 |
GroupWise |
OESNW3 |
OESNW2 |
OESNW1 |
DNS/DHCP |
OESNW1 |
OESNW2 |
OESNW2 |
iFolder |
OESNW2 |
OESNW3 |
OESNW3 |
CIFS Server |
OESNW3 |
OESNW1 |
OESNW1 |