Replacing a node in a two-node ServiceGuard Environment

[JIM NIU]

I need to replace a node in a two-node ServiceGuard environment. I would like to minimize system down time. What is the procedure to go about this?

[John Poff]

Hello,

It's possible to do it without bringing down the cluster. You can run all the packages on one node (the ones that will run there), delete the second node, add a new second node and bring the new node into the cluster. Keeping one node up should help minimize your downtime.


The link for all the HP High Availability books is:

http://docs.hp.com/hpux/ha/index.html


Here is a summary of the instructions for deleting a node and adding a node, taken from the HP "Managing MC/ServiceGuard" book:

Using MC/ServiceGuard Commands to Delete Nodes from the Configuration While the Cluster is Running

Use the following procedure to delete a node with HP-UX commands. For this example, nodes ftsys8, ftsys9 and ftsys10 are already configured in a running cluster named cluster1, and you are deleting node ftsys10.

Use the following command to store a current copy of the existing cluster configuration in a temporary file:
# cmgetconf -C temp.ascii

Specify the new set of nodes to be configured (omitting ftsys10) and generate a template of the new configuration:
# cmquerycl -C clconfig.ascii -c cluster1 -n ftsys8 -n ftsys9

Edit the file clconfig.ascii to check the information about the nodes that remain in the cluster.

Verify the new configuration:
# cmcheckconf -C clconfig.ascii

Apply the changes to the configuration and send the new binary configuration file to all cluster nodes:
# cmapplyconf -C clconfig.ascii
Use cmrunnode to start the new node, and, if desired, set the AUTOSTART_CMCLD parameter to 1 in the /etc/rc.config.d/cmcluster file to enable the new node to join the cluster automatically each time it reboots.


--------------------------------------------------------------------------------
If you are attempting to remove an unreachable node that has many packages dependent on it, especially if the dependent packages use a large number of EMS resources, you may see the following message:
The configuration change is too large to process while the cluster is running.
Split the configuration change into multiple requests or halt the cluster.
In this situation, you must halt the cluster to remove the unreachable node.


Using SAM to Add Nodes to the Configuration While the Cluster is Running

Use the Cluster Configuration area of SAM, and choose "Modify Cluster Configuration" from the Actions menu. Then select "Modify Cluster Name and Nodes." Highlight the name of the node you wish to add to the cluster in the list on the right of the screen, then click the Add button. When you are finished changing the node list, click OK.

Using MC/ServiceGuard Commands to Add Nodes to the Configuration While the Cluster is Running

Use the following procedure to add a node with HP-UX commands. For this example, nodes ftsys8 and ftsys9 are already configured in a running cluster named cluster1, and you are adding node ftsys10.

Use the following command to store a current copy of the existing cluster configuration in a temporary file:
# cmgetconf -C temp.ascii

Specify a new set of nodes to be configured and generate a template of the new configuration:
# cmquerycl -C clconfig.ascii -c cluster1 -n ftsys8 -n ftsys9 -n ftsys10

Edit the file clconfig.ascii to check the information about the new node.

Verify the new configuration:
# cmcheckconf -C clconfig.ascii

Apply the changes to the configuration and send the new binary configuration file to all cluster nodes:
# cmapplyconf -C clconfig.ascii
Use cmrunnode to start the new node, and, if desired, set the AUTOSTART_CMCLD parameter to 1 in the /etc/rc.config.d/cmcluster file to enable the new node to join the cluster automatically each time it reboots.


Have fun with this one! I'll be interested to know how it goes for you.

JP

[melvyn burnard]

Well most of it has been said in the previous reply.
The main thing is to remember that there are certain constraints in doing this, such as the OS must be the same release, as must the SG version you put onto the new node.
Also don't forget the patches.
You will also have to import your vg's etc, and check everything with a fine toothcomb before adding into the cluster, but with planning, it should go smoothly.