That may be the issue. The DD880 does not reach peak performance until it has
5 shelves, or 80 total disks. Until that point it has more CPU than disk IO.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, Jim
Sent: Wednesday, January 02, 2013 10:46 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
I have a Data Domain 880 with 42 active disks, 6 spares, and 4 system disks.
Capacity is 64,678.1 GB.
Jim Schneider
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebner, Andy
Sent: Wednesday, January 02, 2013 8:41 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
My experience with DataDomain (VTL option) is different than Jim described. I
have 2 TSM servers (P6 hardware) using 1 DD. We have not seen a performance
difference no matter what is running beyond what you would expect as the 12Gb
(ISLs) of available bandwidth is used up.
Perhaps the specific DD and the number of disks it has should also be included
in the discussion. Mine is an DD880 with 84 active disks.
The only thing we stop during a large restore is any operation for the pool
that has the data to prevent contention.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Alex Paschal
Sent: Friday, December 28, 2012 4:31 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
Pierre, Jim, having read your observation of read performance impact with your
Data Domain and your DXi, do you guys have thoughts on how you might handle a
full server recovery or other large restore during your backup window? Do you
think you might be forced to stop all backups in order to get a large restore
done before 6am/8am/whatever production, or is there possibly a workaround?
On 12/27/2012 12:51 PM, Billaudeau, Pierre wrote:
> I noticed a serious performance drop when our backup primary tapes to
> copypool runs at night (VTL Quantum DXi8500 to TS1140 tapes). The throughput
> of backups to VTL drops when the DXi "rehydrates" the deduplicated/compressed
> virtual tapes. I can imagine the reclamation process does the same thing.
> There is a need to adjust maintanance schedules to avoid the situation.
>
> Pierre Billaudeau
> Analyste en stockage
> Livraison des Infrastructures Serveurs Société des Alcools du Québec
> 514-254-6000 x 6559
>
> -----Message d'origine-----
> De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part
> de Schneider, Jim Envoyé : 27 décembre 2012 11:18 À :
> ADSM-L AT VM.MARIST DOT EDU Objet : Re: [ADSM-L] Reclamation of Virtual Tapes
>
> Our primary (and only) storage is a Data Domain. Be careful when reclaiming
> virtual tapes. It works perfectly but servers backing up to the Data Domain
> have their bandwidth throughput drop from 85% to 5% during reclamation. This
> was determined by watching Windows Task Manager network utilization with
> reclamation running and then cancelled.
>
> Our reclamation threshold is set at 95% and runs for about 20 minutes. The
> SQL storage pool that holds 1.1 TB files is set at 99% to effectively prevent
> reclamation. We had a bad weekend where reclamation started Friday at 5 PM
> and was 60% complete Monday morning before being cancelled. All of those
> weekend backups were slowed and the database backup ran 5 hours instead of
> 1.75 hours.
>
> Don't make my mistakes!
>
> Jim Schneider
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Ehresman,David E.
> Sent: Tuesday, December 18, 2012 2:38 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
>
> We reclaim our virtual tapes. They have the same waste patterns as physical
> tape and are certainly as expensive.
>
> David
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Lee, Gary
> Sent: Tuesday, December 18, 2012 2:10 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
>
> Sounds like someone set the reclaim storage pool on the virtual tape pool to
> the physical tape pool.
>
> I know of no reason why not to reclaim virtual tapes.
>
> Wish I had one to play with.
>
>
> Gary Lee
> Senior System Programmer
> Ball State University
> phone: 765-285-1310
>
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Welton, Charles
> Sent: Tuesday, December 18, 2012 11:10 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Reclamation of Virtual Tapes
>
> Hello:
>
> We have a TSM instance that uses virtual tapes as our primary backup data
> pool. The data on the virtual tapes are eventually migrated to tape. We are
> currently down to 3 virtual scratch tapes and 6 physical scratch tapes. I
> noticed that we are not running any reclamation processes on our virtual tape
> pool. It seems we have a hand-full of under-utilized virtual tapes. I went
> ahead and ran a manual reclamation on the virtual tape pool and I noticed the
> output tape pool is a physical tape. I assumed that the virtual tape would
> reclaim to another virtual tape. Is that not the case?
>
> Could there be a reason why reclamation shouldn't be ran on a virtual tape
> pool?
>
> Thank you...
>
>
> Charles
>
> This email contains information which may be PROPRIETARY IN NATURE OR
> OTHERWISE PROTECTED BY LAW FROM DISCLOSURE and is intended only for the use
> of the addresses(s) named above. If you have received this email in error,
> please contact the sender immediately.
>
> **********************************************************************
> Information contained in this e-mail message and in any attachments thereto
> is confidential. If you are not the intended recipient, please destroy this
> message, delete any copies held on your systems, notify the sender
> immediately, and refrain from using or disclosing all or any part of its
> content to any other person.
>
> ------------------
>
>
> Information confidentielle : Le présent message, ainsi que tout fichier qui y
> est joint, est envoyé à l'intention exclusive de son ou de ses destinataires;
> il est de nature confidentielle et peut constituer une information
> privilégiée. Nous avertissons toute personne autre que le destinataire prévu
> que tout examen, réacheminement, impression, copie, distribution ou autre
> utilisation de ce message et de tout fichier qui y est joint est strictement
> interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser
> immédiatement l'expéditeur par retour de courriel et supprimer ce message et
> tout document joint de votre système. Merci.
>
|
