Correctly configuring a VTL setup to be "optimized", there's more than a
complicated answer out there... If I were you, I'd do something along
the lines of the following:
Assumptions, in this example you'd have 3 VTLs, 6 media servers...
- each individual VTL has roughly the same throughput capability (ie:
they can all sustain 400 MB/s simultaneously).
- you have an evenly distributed number of media servers you can assign
"per VTL" (ie: you have 3 VTLs and 6 generic media servers, whatever
type, you assign 2 media servers drives from 1 VTL). Each of these
media servers can pump through the same amount of data (ie: 200 MB/s
sustained)
- you don't need maximum drive availability, you need maximum drive
efficiency
- you're able to divvy up you "data types" in roughly equal amounts (ie:
In this example, you'd have x3 data types, like Exchange data, Unix
data, Windows data, structured data, unstructured, etc. Etc., however
you define it)
What I'd do,
- for each VTL, assign an equal amount of drives to the two media
servers that will be using it
- create one storage unit group per VTL, round-robin which storage unit
within the group gets assigned (so you'll flip-flop between media
servers)
- repeat for all your VTLs/media servers
- assign 1 data type "per storage unit group". So if your Exchange is
1/3 of your total full backup, assign your all NBU policies that backup
Exchange to the same storage unit group.
- make sure all media servers are busy an equal amount of time / are
pumping through roughly the same amount during a full backup window (I
like to "assume" incremental aren't my biggest problem, which is usually
the case)
Hopefully in this scenario, you'd have your best dedupe ratio per VTL
(so least amount of storage used), you'd have your best throughput per
VTL (because you've optimized your dedupe VTL for reading, not writing,
because most of your blocks are deduped and not actually written right?
;-) and your media servers should be roughly busy for an equivalent
amount of time, so you're not "idling" on any VTL throughout the
weekend.
Nice "problem" to have there, with the multiple VTLs.
Cheers.
-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
briandiven AT northwesternmutual DOT com
Sent: March 23, 2010 9:22 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] VTL Question - Distribution of Backups
We have multiple VTL's and chose to use them as a Storage Unit Group.
They are capable of deduplication. The vendor states that the amount of
data/VTL increases the dedupe time and we are struggling to complete
this process. Supposedly the time to dedupe has nothing to do with the
dedupe ratio - it is simply how much data that resides in a VTL (post
Dedupe + new data). I see 2 VTL management philosophies and would like
your ideas for a 3rd or a hybrid idea.
The easiest to manage is to spread the data across all VTL's using NBU's
balancing algorythms. However, even after dedupe processing, I expect
that over time the full backup will exist in every VTL. Since total
storage consumed has an impact on the dedupe process, I want to find an
alternative. That's where I need your help.
I've been thinking of the old college question of what is the best way
to fill a jar with rocks, pebbles, & sand. Spread out your 1 TB Rocks
equally, Fill with 500 GB pebbles, and then define where the remaining
sand goes?
Storage Unit Groups don't appear to be the best fit for VTL's if you
want efficiency.
I would love to hear your feedback and ideas !!
Brian
This e-mail and any attachments may contain confidential information of
Northwestern Mutual. If you are not the intended recipient of this
message, be aware that any disclosure, copying, distribution or use of
this e-mail and any attachments is prohibited. If you have received this
e-mail in error, please notify Northwestern Mutual immediately by
returning it to the sender and delete all copies from your system.
Please be advised that communications received via the Northwestern
Mutual Secure Message Center are secure. Communications that are not
received via the Northwestern Mutual Secure Message Center may not be
secure and could be observed by a third party. Thank you for your
cooperation.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
====================================================================================
La version française suit le texte anglais.
------------------------------------------------------------------------------------
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
------------------------------------------------------------------------------------
Le présent courriel peut contenir de l'information privilégiée ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
votre
ordinateur toute copie du courriel reçu.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
