No changes necessary to the cluster configuration.
Every affected package will need to modify the FAILOVER_POLICY parameter to be MIN_PACKAGE_NODE . This can be done while the package is running.
With a Rolling Standby configuration, it is a good idea but not necessary for all nodes in the cluster to have a similar hardware configuration, especially in terms of CPU and memory. This is a good idea because any node in the cluster could potentially run any application, and if we had a dissimilar hardware configuration between nodes, we may experience different levels of performance. Even in a Rolling Standby configuration, some nodes may end up running multiple applications. It is a good idea to consider configuring a tool such as PRM or WLM to ensure that the appropriate resources are allocated to individual applications in the event of multiple applications running on the same node.
A2:
Serviceguard maintains the MAC address of all configured LAN cards in the cluster binary configuration file. As such, we will need to rerun the cmapplyconf file using the existing ASCII configuration file. In doing so, Serviceguard will store the new MAC address and redistribute the binary configuration file to all nodes in the cluster. No other changes are necessary.
A3:
It is not necessarily safe to use the found ASCII file. It is always safe to use the cmgetconf command to extract the cluster configuration from the cluster binary configuration file. cmgetconf will create an ASCII file with the most up-to-date cluster configuration.
A4:
The checklist will not remove the package from the cluster configuration. Because the package will still be registered in the cluster binary configuration file, cmclconfig , the checklist should look like this:
Halt the package.
Remove the package definition from the cluster binary configuration file using the cmdeleteconf command.
Ensure that the package was removed successfully by using the cmviewcl command and reviewing the syslog.log file.
Review remaining cluster activity with the cmviewcl command.
A5:
The node can be deleted from the cluster even though it is down. This is possible because the binary cluster configuration file will list only the remaining nodes and these nodes will be sent the new binary cluster configuration file. Because the deleted node plays no part in the cluster, there is no need for the Serviceguard daemons to contact this node.
Because we have gone from a four-node to a three-node cluster, it may be worth considering utilizing a Cluster Lock technology such as a cluster lock disk or a Quorum server. With a three-node cluster, this is optional but is worthwhile considering in the event that a subsequent node is down, due to urgent maintenance, leaving a two-node cluster where a Cluster Lock is required.
