Hi Concering Gresham, you dont need to have multiple clientID for Gresham, you can use the same on for all cluster resources. CLIENTID is only when communicating with ACSLS.
Storage Agent should be installed locally on each cluster node. The Storage Agent is not bound to your cluster resources and their TSM node names. We have both a TSM server running HACMP and EDT, and client nodes running HACMP with EDT and the storage agent. You could see it something like this: 1 Non-cluster resources which should not be integrated into any HACMP resource groups: Gresham EDT, TSM Storage Agent 2 Resources which has to be included in your resource groups for correct fail-over functionality: TSM client(which really means dsm.opt/dsm.sys files and other configuration files needed by each TSM node name). Your defintion should look something like this: 1. EDT and TSM storage agent locally defined on each cluster node. For example, you have LAN-free agent Hnode1 and Hnode2. You have either EDT CLIENTID Hnode1and Hnode2, or just run same client ID on both machines, for example CLUSTER. EDT doesnt care which node that is connecting to it. It only communicates with the Storage Agent and ACSLS. The storage agent isn't bound to any node name that connects to it(either it's Hres1, Hres2, Hres3 or Hres3_ORA). Therefore, theese applications should be locallly installed, and not included in any resource groups. 2. One TSM node for each cluster node, which backs up data not stored in cluster resourcegroups(/var, /usr, /etc and so on). For example, Hnode1 and Hnode2. 3. One TSM node for each cluster resource group, plus a TSM node for the TDP for Oracle. For example, Hres1 and Hres2 will be backup/archive nodes, and Hres3 will be a TDP for Oracle node. If Hres3 also contains files which you want to backup(scripts, output files), then you will have to define two nodes for that cluster resourcegroup(Hres3 and Hres3_ORA). The configuration files should be located on disks belonging to the cluster resource group in question. The binaries should be installed locally on each cluster node. I hope this sums it all up. If not, please dont hesitate so send me any questions. Best Regards Daniel Sparrman ----------------------------------- Daniel Sparrman Exist i Stockholm AB Propellervägen 6B 183 62 TÄBY Växel: 08 - 754 98 00 Mobil: 070 - 399 27 51 "Bateman, Fred" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 2003-03-07 12:30 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: TSM - HACMP - EDT Configuration I hope I have provided enough detail to describe my problem. I did assume the reader has fairly detailed knowledge of HACMP and EDT. Hardware/Software Environment: 2 IBM p690s AIX 5.1 with ML03 HACMP 4.4.1 TSM 5.1.something(TBD) (on another machine) TSM Storage Agent TDP EDT 6.4.1 (Gresham Software) SAN 2 McData 6064 switches 6 McData ES-1000 switches 1 STK Silo (9310) 6 STK 9980 Tape Drives 1 HDS 9980 (using Sanergy would solve this problem but I would like the option of using tapes Lanfree) Various other software Legend: hnodeX == HACMP Node X (same as machine for this discussion) hresX == HACMP Resource X HACMP Configuration (simplified but hopefully adequate to describe problem): 1 Concurrent Resource (hres3) running Oracle 9.2/RAC. 1 Cascading Resource (hres1) normally on hnode1. Can fail over to hnode2 using IPAT. 1 Cascading Resource (hres2) normally on hnode2. Can fail over to hnode1 using IPAT. In summary: each machine can be running one, two or all three HACMP resources. Each cascading resource has a set of disks which moves with the resource and therefore must be backed up from either machine. The concurrent resource has raw devices accessible to both machines which do not "move". Using TDP, they can be backed up from either machine. Each hnodeX has data (e.g., rootvg and JFS type data belonging to the concurrent resource) which stays with the machine and must be backed up. Problem: How do I define TSM/EDT? (We currently use EDT to allow us to do Lanfree so we know the basics.) I need to be able to move hres1 and hres2 between hnodes without worrying about tapes being dismounted. We currently set CLIENTID to hostname. I do not believe that would work in this environment because 1) hres1 has tape(s) mounted using LANFREE 2) hres3 has tape(s) mounted using LANFREE 3) hres1 fails over from hnode1 to hnode2 for some reason 4) the tape(s) being used by hres1 would not be dismounted I then thought of using hresX as the CLIENTID. I thought of separate TSM Storage Agents for each hresX (possible?). I thought of separate stgpools for each hresX pointing to separate libraries so I could use hresX as the EDT CLIENTID (not very appealing! but I think it would work). Any help in this matter would be GREATLY APPRECIATED!