Andy,
Just an opinion here. If you try to provide virtual sequential access mount
points for each client session you may need during client processing, you
will likely need much more system resources to complete nightly backups.
Managing mount points need only be done during daily server maintenance
processing. I would still be using a random access disk pool to provide
staging space for client backups. The L in VTL stands for Library and it
should be treated as such. For many years IBM has recommended that we back
up to a staging area to enhance client performance and reduce resource
needs. During server maintenance, data should be placed onto longer term
storage devices (libraries) for daily expiration and reclamation
processing.. I don't think that strategy changes with a VTL.
On another not I have a client with a VTL running in a Windows environment
with around 200 clients(not sure what you have). Their VTL vendor suggested
a volume size of 20Gb. This eventually created ~15000 volumes. When the TSM
server used the VTL, the overhead from mounting hoards of virtual volumes
brought their server to its knees. I mean it would not even respond to
session requests so it could not complete nightly client backups at all.
Not to mention the headaches of managing 15000 volumes from the TSM
interface (GUI or CLI). They too were trying to backup directly to the VTL
during nightly client backups. We had to return there management class
destinations back to a random access storage pool and process their data
during daily sever maintenance as TSM is designed to do. We set up the VTL
to emulate LTO2 (200GB volume size) and used the VTL like a library,
migrating the nightly backup data to the VTL. Large Oracle backups do
directly to the VTL but are limited in number. The client is fat and happy
now, backing up ~1.5TB nightly with plenty of time left and the TSM server
performance is stellar.
Regards,
Nicholas
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 07/07/2009
11:18:26 AM:
> [image removed]
>
> Re: [ADSM-L] VTL Tape Size
>
> John D. Schneider
>
> to:
>
> ADSM-L
>
> 07/07/2009 11:19 AM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
> Please respond to "ADSM: Dist Stor Manager"
>
> Andy,
> My experience may not map to the problem you are trying to solve, but
> I chose a relatively small VTL tape size (50GB) and have not regretted
> it. The trade-off is "total number of virtual tapes" vs "total number
> of anticipated simultaneous tape mounts".
> Say you have a 60TB VTL (usable), and you want to emulate LTO4 tapes.
> If you went with the default size (400GB) you would have about 150
> virtual tapes in your pool. Say also that there are 300 TSM clients to
> be backed up each night. Each one will need at least one virtual tape
> during their backups, and some of them might need 4 or 8 for performance
> reasons. You would have only 150 tapes for 300 clients? You could
> spread out their schedules, of course, but that will still be
> problematic. After a few weeks you might have a bunch of them full, but
> not ready to reclaim, or waiting on reusedelay, and not have enough
> available tapes for all the tape mounts you need.
> With 50GB tapes, you would have over 1200 virtual tapes. Tapes would
> fill up sooner, of course, but they could be reclaimed sooner, too, and
> be returned to scratch. Your overall disk utilization will go up.
> One thing to bear in mind is that if you have single files that are
> bigger than your virtual tape size, the file will have to span multiple
> virtual tapes. This is no problem for TSM, but it does mean that each
> of the virtual tapes involved in that one file will not be mountable
> until after that large file is finished backing up. We have seen the
> unusual situation where a single 300GB Exchange database was backing up,
> and happened to run over into our 'backup stgpool' window. The 'backup
> stgpool' was waiting on a tape mount of a certain volume, but when we
> checked we could see that the volume was not mounted or in use by
> anybody else. After some digging we noticed that the virtual volume in
> question had been mounted some hours earlier in a backup session for a
> single large Exchange file, and that backup was still going on. As soon
> as that file finished backing up, the virtual tapes mounted and the
> 'backup stgpool' continued.
>
> Another thing to think about is, have you sized the virtual library
> to have enough capacity for all your primary storage pool needs, or will
> the primary pool have to migrate to real tape? If so, that is another
> argument in favor of relatively small virtual tapes, because they won't
> migrate until they are full. In our case, using the migration
> threshhold to cause the migration to occur didn't work well because of
> how TSM calculates percent full, so we ended up writing a script that
> automatically migrates (using "move data") virtual tapes as they age, so
> that we are sure we always have enough scratch tapes for our next
> backups.
>
> Best Regards,
>
> John D. Schneider
> The Computer Coaching Community, LLC
> Office: (314) 635-5424
> Toll Free: (866) 796-9226
> Cell: (314) 750-8721
>
>
> -------- Original Message --------
> Subject: [ADSM-L] VTL Tape Size
> From: "Huebner,Andy,FORT WORTH,IT" <Andy.Huebner AT ALCONLABS DOT COM>
> Date: Tue, July 07, 2009 9:36 am
> To: ADSM-L AT VM.MARIST DOT EDU
>
> We are about to bring up new TSM servers and one of questions that has
> come up is how big to make the VTL tapes? We currently use 100GG and
> have tried 10GB with our test server.
> The question is what size it popular and why?
>
> Andy Huebner
>
>
>
> This e-mail (including any attachments) is confidential and may be
> legally privileged. If you are not an intended recipient or an
> authorized representative of an intended recipient, you are prohibited
> from using, copying or distributing the information in this e-mail or
> its attachments. If you have received this e-mail in error, please
> notify the sender immediately by return e-mail and delete all copies of
> this message and any attachments.
> Thank you.
|
