On Tuesday 21 October 2003 07:41, Curt Watts wrote: > Alright, time to ask the experts! > > Essentially, I'm trying to have our remote TSM servers (satellite > locations) utilize the main TSM server as the next storage pool in it's > hierarchy. > > The hierarchy will eventually look like this: > > Remote Server (RS) Disk Cache > -Main Server (MS) Disk Cache > -MS Tape Pool > -MS Offsite Copy Pool > > Questions I have: > 1) Is this possible?
Yes, everything you describe is possible. Though some features would require DRM licensing, and network performance may be an issue. See below for details. > 2) Can I do this without the DR module? Yes and no. What you describe is migrating "primary pool" data, from RS disk to RS "virtual volumes" - that happen to be stored remotely on the MS server. You can do this without DRM. The DRM module is required when sending any "DR" related data across the server-to-server communications. Thus, you will need to license DRM if you wish to send "copy pool" data, TSM database backups, or "prepare" output via server-to-server communications. There are a couple of practical considerations too. :) First, when RS stores "primary" data on "virtual volumes" on the MS server, it needs to access those "virtual volumes" during reclamation. This causes significant network traffic during reclamation, as the "virtual volumes" need to be copied _back_ to the RS server, reclaimed, then sent _back_ to the MS server. This is not such an issue with copy pool virtual volumes. Also, the MS server stores these "virtual volumes" as "archive" objects, typically in the default management class of whatever policy domain the RS server's "client" account resides. Thus you might want to create a new policy domain for the RS server's client account, and a management class with (only) an archive copy group. The MS server ignores *all* the archive copy group parameters, except the storage pool destination. Thus you don't have to worry about the MS server expiring the RS server's data, it will _never_ expire the data (until the RS server says too...) And finally, since both the RS and MS server's need to retain the "virtual volumes", the potential exists that they get out of sync. Therefore you should consider scheduling "reconcile volumes" to run occassionally to fix any problems. > 3) How does the RS backup it's database - because it won't backup to > the local disk? As I stated in (2), you will require DRM if you wish to backup the TSM database directly to the remote TSM server. Perhaps you could backup up the database to the local RS disk, then copy the resultant file across the network, or even use the B/A client to backup the file to the remote TSM server. > 3b) Should the RS backup it's DB directly to tape? and if so, how is it > possible to share the tape library with no NAS? ( I think you mean, no SAN?) Again, as I state in (2), you need DRM to do this. Assuming that you don't use DRM, and instead backup to the local disk and then use the B/A client to backup to the remote server - then due to the size of the database backup, I'd probably want to send it "directly" to tape. > 4) Should I just break down and put some tape drives out there to > handle the DBs? That's probably not necessary; If you have the bandwidth to consider sending storage pool data between sites electonically, then copying the TSM database should be easy. :) Regards, Steven P. -- Steven Pemberton Senior Enterprise Management Consultant IBK, Senetas Group Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907 Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au