Managing Shared Disks

Replacing a server

If you need to relocate a virtual shared disk server and its secondary server to another node, do the following:

1. Archive the System Data Repository by entering SDRArchive on the command line. If you make a mistake or change your mind, this will permit you to undo the changes you make.
2. Bring down any applications that use the affected servers.
3. Stop the RVSD subsystem on the affected servers. For example:

   ha.vsd stop
   

   Note:

   If you stop RVSD on all the nodes you can skip the next step.

4. Suspend and stop all virtual shared disks involved on all the nodes. For example:

   suspendvsd vsd_name
   stopvsd vsd_name
   

5. Unconfigure all virtual shared disks involved on all the nodes. For example:

   ucfgvsd vsdname
   

6. If you need to remove or alter any of the original nodes, you can do so now. Refer to PSSP: Installation and Migration Guide for more information.
7. Recable the disks to attach them to the new servers.
8. Set up the volume groups on the new server nodes. For example:

   importvg -y volume_group_name hdiskx
   chvg -a n volume_group_name
   varyoffvg volume_group_name
   vsdvgts -a volume_group_name
   

9. Designate the new servers as virtual shared disk nodes. See Chapter 3, Understanding your Managing Shared Disks process for more information.
10. Change the System Data Repository to reflect the new nodes for the affected virtual shared disk volume group. From any node in the partition, or from the control workstation, issue the SDRGetObjects command to see the current settings.
    • For twin-tailed disks,

      SDRGetObjects VSD_Global_Volume_Group global_group_name==global_group_name \
      primary_node secondary_node
      

      You will see the current values of global_group_name attributes: primary_node, secondary_node. For example, you might see:

      1 3
      

      To change the System Data Repository, issue:

      SDRChangeAttrValues VSD_Global_Volume_Group global_group_name==global_group_name 
      primary_node=node_number secondary_node=node_number
      

      In this example, to change the primary and secondary nodes from 1 and 3 to 5 and 7, for global volume group "dummygvg", issue:

      SDRChangeAttrValues VSD_Global_Volume_Group global_group_name==dummygvg 
      primary_node=5 secondary_node=7
      

    • For concurrent disks,

      SDRGetObjects VSD_Global_Volume_Group global_group_name==global_group_name 
      primary_node secondary_node server_list
      

      You will see the current values of global_group_name attributes: primary_node, secondary_node, and server_list. For example, you might see:

      1 " " 1:3
      

      To change the System Data Repository, issue:

      SDRChangeAttrValues VSD_Global_Volume_Group global_group_name==global_group_name 
      primary_node=node_number server_list=server_list
      

      In this example, to change the server_list nodes from 1 and 3 to 5 and 7, for global volume group "dummygvg", issue:

      SDRChangeAttrValues VSD_Global_Volume_Group global_group_name==dummygvg 
      primary_node=5 server_list=5:7
      

      To verify the change, enter the SDRGetObjects command again.

11. Issue a reset to make all the virtual shared disks in the configuration active and to start the RVSD subsystem on the new servers. For example:

    ha_vsd reset
    

12. Refresh the RVSD subsystem so that all the nodes will become aware of the changed servers. This only needs to be done from one node where the RVSD subsystem is active, since it runs a protocol to all active RVSD subsystems. For example:

    ha.vsd refresh
    

13. To verify that the driver has a current list of the existing virtual shared disk nodes, issue lsvsd -i. Do this on every node before attempting any remote virtual shared disk requests to the node.