Examples of how to schedule a backup in a cluster environment

In the following example, IBM® PowerHA® SystemMirror is configured for two AIX® hosts, host_a and host_b. Along with their own local data, the hosts are sharing disk storage which has two file spaces: /disk1 and /disk2.

This example shows how to configure a scheduled backup in a current IBM PowerHA SystemMirror environment.

• The administrator defines 3 nodes on the IBM Storage Protect server: host_a, host_b, cluster_group, using the following commands: (1) REGISTER NODE host_a mysecretpa5s, (2) REGISTER NODE host_b mysecretpa5s, (3) REGISTER NODE cluster_group mysecretpa5s.
• The administrator defines a dsm.opt file on host_a and host_b (note that the opt files are different on each host), using the following commands: (1) NODENAME host_a (option can be left as default), (2) DOMAIN /home /usr ... etc..
• The administrator defines a dsm.opt file located somewhere on one of the cluster disk groups, for example, /disk1/tsm/dsm.opt, using the following commands: (1) NODENAME cluster_group, (2) DOMAIN /disk1 /disk2.
• The administrator defines a schedule on the IBM Storage Protect server, using the following command: DEFINE SCHEDULE STANDARD CLUSTER_BACKUP.
• The administrator defines associations for each of the 3 nodes, using the following command: DEFINE ASSOC STANDARD CLUSTER_BACKUP host_a,host_b,cluster_group. At any one time, there are three instances of the backup-archive client schedule running (with the scheduler for cluster_group being part of the cluster resources that failover whenever the cluster group disk resources failover. Thus, it would be running on either host_a or host_b but not both simultaneously).
• All three node names contain data on the IBM Storage Protect server.

The ASNODE example shows a generic solution which could be applied to UNIX cluster solutions to which we do not have support, for example: Veritas Cluster Server for Solaris.

• The administrator defines 3 nodes on the IBM Storage Protect server host_a, host_b, cluster_group:

  REGISTER NODE host_a mysecretpa5s 
  REGISTER NODE host_b mysecretpa5s 
  REGISTER NODE cluster_group mysecretpa5s

• The administrator defines a proxy node relationship between host_a and host_b to hacmp_cluster

  GRANT PROXYNODE TARGET=cluster_group AGENT=host_a,host_b

• The administrator defines a dsm.opt file on host_a and host_b to handle the local file systems:

  NODENAME 	host_a (option can be left as default) 
  DOMAIN  		/home /usr ... etc.
                                                                 
  NODENAME   host_b (option can be left as default)              
  DOMAIN  		/home /usr ... etc. 

• The administrator defines a dsm.opt file on the cluster resource to handle the backup of the clustered resources, e.g. /disk1/tsm/dsmcluster.opt (the nodename is the default nodename, which is either host_a or host_b, depending on which workstation contains the cluster group at any given time):

  DOMAIN 		/disk1 /disk2  
  ASNODE    cluster_group

• The administrator defines a schedule on the IBM Storage Protect server:

  DEFINE SCHEDULE STANDARD CLUSTER_BACKUP

• The administrator defines associations for each one of the 3 nodes.

  DEFINE ASSOC STANDARD CLUSTER_BACKUP host_a,host_b,cluster_group

• At any one time, there are three instances of the backup-archive client schedule running with the scheduler for node hacmp_cluster running on either host_a or host_b but not both (it is included in the cluster resources that would failover). This scheduler would point to the dsmcluster.opt that is defined on each host. The three instances would be started as:

  [host_a]  	 	   dsmc sched 
  [host_b]		   dsmc sched 
  [cluster_group] dsmc sched -optfile=/disk/tsm/dsmcluster.opt

• All three node names contain data on the IBM Storage Protect server.

For more information about the server scheduler commands, see the server documentation.