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
|
