Client node proxy support [option: Asnodename]:

Backup time can be reduced and clustered configurations can store data with client node proxy support. Tivoli Storage Manager nodes, when authorized (grant proxynode, see 3.4.15, “Multiple Tivoli Storage Manager client nodes” on page 60) as agent nodes, can be directed to back up or restore data on behalf of another node (the target node). This enables concurrent operations from multiple nodes to store data to the same target node and file space in parallel. The concurrent operations can reduce backup and restore times in environments such as IBM GPFS. Client nodes can also be configured with proxy nodeauthority to support many of the systems that can be configured to support clustering failover. The asnodename option also allows data to be restored from a different system than the one which performed the backup. More details on this can be found in Appendix , “Comparison of options virtualnodename/fromnode/asnodename” on page 320.

Comparison of optionsvirtualnodename/fromnode/asnodenameHere we describe the differences between the client options virtualnodename,fromnode, and asnodename. Table A-1 illustrates the different functions availablewith each option.For more details for each option, please see the IBM Tivoli Storage Manager 5.3UNIX and Linux Backup-Archive Clients Installation and User's Guide.Table A-1 Functions available - virtualnodename, fromnode, and asnodename

Password required or notWith each option, authentication is handled differently:virtualnodename When the virtual node name is accepted by the server, apassword is required (assuming authentication is on), even ifthe passwordaccess option is generate.The advantage of using the virtualnodename option overchanging the nodename is that the password prompted for isnot saved on the system.fromnode The fromnode option permits one node to performcommands for another node. A user on another node mustuse the set access command to permit you to query,restore, or retrieve files or images for that other node.Because access has to be granted to a given node, you arenot prompted for a password. You limited to the query,restore, and retrieve operations which are non-destructive tothe original node data.asnodename Use the asnodename option to allow agent nodes to back upor restore data on behalf of another node (the target node).Your client node must be granted access to the target nodeby the Tivoli Storage Manager server grant proxynodecommand. Authentication is then based on the nodenameusing the asnodename option.Function virtualnodename fromnode asnodenameBackup X XArchive X XRestore X X XRetrieve X X XAppendix A. Hints and tips 321

Example scenarios of when to use which optionTo help you identify in which situation which option is appropriate, we now

describe some scenarios for which you might want to use the various options.virtualnodenameBefore selectively restoring data of another node on a workstation, or backing updata under a different node name, it was common practice to edit thedsm.opt/dsm.sys file and change the nodename. After performing the operation,the nodename was changed back. The downside to this is, that the password forthat node is saved locally (when passwordaccess generate is defined). So this iswhen virtualnodename should be used, because it prompts you for a passwordwithout saving it.fromnodeA scenario where you might use the fromnode option is when giving severalnodes access to your data, by using the set access command, and not having toworry about anything, because they only have the right to query, restore orretrieve the data.In a way, this could also be used as a vehicle to perform software distribution. Incombination with a script, you could start the setup after the restore.asnodenameThe following examples are also included in the UNIX documentation. Pleasenote that this multi-node design can only be exploited as described in a UNIXenvironment. The virtualmountpoint client option is not available to Windows orNetWare clients, and their filespace naming includes the UNC name of themachine making asnodename less practical in a Windows/Netware environment.Scheduling example for backing up a GPFS filesystem:An illustration of a GPFS cluster is shown in Figure A-1. The GPFS team haswritten a routine which performs the following functions on a GPFS file system: Itscans the entire file system for inode changes, creates a list of files that havechanged, and then parcels out the list of files to (1 - n) IBM Tivoli StorageManager Backup-Archive client nodes to move the data.

Appendix A. Hints and tips 321

Example scenarios of when to use which optionTo help you identify in which situation which option is appropriate, we nowdescribe some scenarios for which you might want to use the various options.virtualnodenameBefore selectively restoring data of another node on a workstation, or backing updata under a different node name, it was common practice to edit thedsm.opt/dsm.sys file and change the nodename. After performing the operation,the nodename was changed back. The downside to this is, that the password forthat node is saved locally (when passwordaccess generate is defined). So this iswhen virtualnodename should be used, because it prompts you for a passwordwithout saving it.fromnodeA scenario where you might use the fromnode option is when giving severalnodes access to your data, by using the set access command, and not having toworry about anything, because they only have the right to query, restore orretrieve the data.In a way, this could also be used as a vehicle to perform software distribution. Incombination with a script, you could start the setup after the restore.asnodenameThe following examples are also included in the UNIX documentation. Pleasenote that this multi-node design can only be exploited as described in a UNIXenvironment. The virtualmountpoint client option is not available to Windows orNetWare clients, and their filespace naming includes the UNC name of the

machine making asnodename less practical in a Windows/Netware environment.Scheduling example for backing up a GPFS filesystem:An illustration of a GPFS cluster is shown in Figure A-1. The GPFS team haswritten a routine which performs the following functions on a GPFS file system: Itscans the entire file system for inode changes, creates a list of files that havechanged, and then parcels out the list of files to (1 - n) IBM Tivoli StorageManager Backup-Archive client nodes to move the data.

Attention: Ensure that local filesystems of different systems are notaccidentally merged when using the ASNODENAME option. This would leadto unpredictable results when restoring a system.322 IBM Tivoli Storage Manager Version 5.3 Technical GuideFigure A-1 Cluster using GPFS and ASNODENAME

Each client node authenticates with the server as the same node name, forexample, node_gpfs. This is done by having a dsm.sys file on each machine withan entry:nodename node_gpfsThe problem with this solution is that the password expiration cannot bemanaged automatically. If there are three nodes in the GPFS cluster, each nodeknows the password to node_gpfs. If the server expires the password, then onenode will reset the password and the other two will no longer be able toauthenticate. The only solution to this is to either turn node authentication off atthe Tivoli Storage Manager server or to manually reset the password andmanually update all three nodes with the new password.The Tivoli Storage Manager scheduler is not currently used in this solution but itcan be easily seen that there could be a single schedule for node_gpfs whichexecutes the file system scan / workload creating from one client machine via amacro. This schedule would be associated with one of the three nodes only, forexample, node_1.A better solution can be realized with multi-node support. Using the example ofthree nodes in the GPFS cluster which would participate in the backup:IBM Tivoli Storage Managernode_1ASNODE:node_gpfs/fs1/fs2/fs3/fs1/fs2/fs3node_2 node_3GPFS-ClusterGPFSAppendix A. Hints and tips 3231. Define four nodes on the Tivoli Storage Manager server: node_1, node_2,node_3 and node_gpfs. node_1, node_2 and node_3 are only used forauthentication; all filespaces are stored with node_gpfs.REGISTER NODE node_1 mysecretpwREGISTER NODE node_2 mysecretpwREGISTER NODE node_3 mysecretpwREGISTER NODE node_gpfs mysecretpw2. Define a proxynode relationship between the nodes:GRANT PROXYNODE TARGET=node_gpfs AGENT=node_1, node_2, node_33. Define the node name and asnode name for each of the machines in theirrespective dsm.sys files:

nodename node_1asnodename node_gpfs4. Optionally define a schedule for only node_1 to do the work:DEFINE SCHEDULE STANDARD GPFS_SCHEDULE ACTION=MACROOBJECTS="gpfs_script"DEFINE ASSOCIATION STANDARD GPFS node_gpfs5. On node node_gpfs, execute the schedule:DSMC SCHEDAnother way to back up GPFS is to use Tivoli Storage Manager to look for theincremental changes. The GPFS file system can be divided into three branchesand each branch statically assigned to each node using the virtualmountpointoption. Assume a file system called /gpfs with three branches /gpfs/branch_1,/gpfs/branch_2, and /gpfs/branch_3:1. Define four nodes on the Tivoli Storage Manager server: node_1, node_2,node_3 and node_gpfs. node_1, node_2 and node_3 are only used forauthentication; all filespaces are stored with node_gpfs.REGISTER NODE node_1 mysecretpwREGISTER NODE node_2 mysecretpwREGISTER NODE node_3 mysecretpwREGISTER NODE node_gpfs mysecretpw2. Define a proxynode relationship between the nodes:GRANT PROXYNODE TARGET=node_gpfs AGENT=node_1,node_2,node_33. Define the node name (not the asnodename!), virtualmountpoint, and domainfor each of the three machines in their respective dsm.sys files:nodename node_1virtualmountpoint /gpfs/branch_1domain /gpfs/branch_1324 IBM Tivoli Storage Manager Version 5.3 Technical Guide4. Define a schedule for all nodes: node_1, node_2 and node_3DEFINE SCHEDULE STANDARD GPFS_SCHEDULEOPTIONS="-asnode=node_gpfs"DEFINE ASSOCIATION STANDARD GPFS node_1,node_2,node_35. Start the scheduler on the three nodes:DSMC SCHEDScheduling example for backing up an HACMP clusterConsider an example where HACMP is configured for two AIX hosts, host_a andhost_b. Along with their own local data, the hosts are sharing SSA storage whichhas two filespaces: /ssa1 and /ssa2.The CLUSTERNODE example shows how the CLUSTERNODE option is usedin a current HACMP environment (this is informational only to contrast theexample of using ASNODENAME below):1. Define three nodes on the Tivoli Storage Manager server: host_a, host_b,cluster_groupREGISTER NODE host_a mysecretpwREGISTER NODE host_b mysecretpwREGISTER NODE cluster_group mysecretpw2. Define a dsm.opt file on host_a and host_b (note that the opt files are differenton each host):NODENAME host_a (option can be left as default)DOMAIN /home /usr ... etc.3. Define a dsm.opt file located somewhere on one of the cluster disk groups,for example, /ssa1/tsm/dsm.opt,NODENAME cluster_groupDOMAIN /ssa1 /ssa2CLUSTERNODE YES

4. Define a schedule on the Tivoli Storage Manager server:DEFINE SCHEDULE STANDARD CLUSTER_BACKUP5. Define associations for each of the three nodes:DEFINE ASSOC STANDARD CLUSTER_BACKUP host_a,host_b,cluster_groupNote: The user does not want to define asnodename in the options file. Inthis case the asnodename must come on the schedule so that each one ofthe nodes can have it's own schedule associated with its real node name.Appendix A. Hints and tips 3256. At any one time, there are three instances of the Backup-Archive clientschedule running (with the scheduler for cluster_group being part of thecluster resources that will failover whenever the cluster group disk resourcesfailover. Thus, it would be running on either host_a or host_b but not bothsimultaneously)7. All three node names will contain data on the Tivoli Storage Manager serverThe ASNODE example shows how this can be configured without the use ofCLUSTERNODE; this is a generic solution which could be applied to UNIXcluster solutions, for example, Veritas Cluster Server for Solaris.1. Define 3 nodes on the Tivoli Storage Manager server: host_a, host_b,cluster_groupREGISTER NODE host_a mysecretpwREGISTER NODE host_b mysecretpwREGISTER NODE cluster_group mysecretpw2. Define a proxy node relationship between host_a and host_b to cluster_groupGRANT PROXYNODE TARGET=cluster_group AGENT=host_a,host_b3. Define 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.4. Define a dsm.opt file on the cluster resource to handle the backup of theclustered resources, for example, /ssa1/tsm/dsmcluster.opt (note thenodename will be the default nodename which will either be host_a or host_bdepending on which machine contains the cluster group at any given time):DOMAIN /ssa1 /ssa2ASNODE cluster_group5. Define a schedule on the Tivoli Storage Manager server:DEFINE SCHEDULE STANDARD CLUSTER_BACKUP6. Define associations for each one of the 3 nodes.DEFINE ASSOC STANDARD CLUSTER_BACKUP host_a,host_b,cluster_group7. At any one time, there are three instances of the Backup-Archive clientschedule running with the scheduler for node hacmp_cluster running oneither host_a or host_b but not both (it is included in the cluster resources thatwould failover). This scheduler would point to the dsmcluster.opt that isdefined on each host. The three instances would be started as:326 IBM Tivoli Storage Manager Version 5.3 Technical Guide[host_a] dsmc sched[host_b] dsmc sched[cluster_group] dsmc sched -optfile=/ssa/tsm/dsmcluster.opt8. All three node names will contain data on the Tivoli Storage Manager server

Note: The multiple node design as described above can only be exploited in aUNIX environment and not on Windows and Netware Systems. Theasnodename option is available on Windows systems, but there is not as muchbenefit in using this because of the filespace naming limitations inherent inWindows systems