To be honest, it doesnt really say. The information is from the Tivoli Storage
Manager Technical Guide:
Note: In terms of sizing Tivoli Storage Manager V6.1 deduplication, we currently
recommend using Tivoli Storage Manager to deduplicate up to 6 TB total of
storage pool
space for the deduplicated pools. This is a rule of thumb only and exists
solely to give an
indication of where to start investigating VTL or filer deduplication. The
reason that a
particular figure is mentioned is for guidance in typical scenarios on
commodity hardware.
If more than 6 TB of real diskspace is to be duplicated, you can either use
Tivoli Storage
Manager or a hardware deduplication device. The 6 TB is in addition to whatever
disk is
required by non-deduplicated storage pools. This rule of thumb will change as
processor
and disk technologies advance, because the recommendation is not an
architectural,
support, or testing limit.
http://www.redbooks.ibm.com/redbooks/pdfs/sg247718.pdf
I'm guessing it's server-side since client-side shouldnt use any resources @
the server. I'm also guessing you could do 8TB or 10, but not 60TB.
Best Regards
Daniel Sparrman
Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE
-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
Till: ADSM-L AT VM.MARIST DOT EDU
Från: Hans Christian Riksheim <bullhcr AT GMAIL DOT COM>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 09/28/2011 09:56
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file
systems for pirmary pool
This 6 TB supported limit for deduplicated FILEPOOL does this limit
apply when one does client side deduplication only?
Just wondering since I have just set up a 30 TB FILEPOOL for this purpose.
Regards
Hans Chr.
On Tue, Sep 27, 2011 at 8:44 PM, Daniel Sparrman
<daniel.sparrman AT exist DOT se> wrote:
> Just to put an end to this discussion, we're kinda running out of limits here:
>
> a) No VTL solution, neither DD, neither Sepaton, neither anyone, is a
> replacement for random diskpools. Doesnt matter if you can configure 50
> drives, 500 drives or 5000 drives, the way TSM works, you're gonna make the
> system go bad since the system is made from having random pools infront,
> sequential pools in the back. A sequential device is not gonna replace that,
> independent being a sequential file pool or a VTL (or, for that question, a
> tape library).
>
> b) VTL's where invented because most backup software (I've only worked with
> TSM, Legato & Veritas aka Symantec) is used to working with sequential
> devices. That havent changed, and wont change in the near future. VTL's (and
> the file device option) is just a replacement. Performance wise, VTL's are
> gonna win all the time compared to a file device, question you need to ask
> yourself is, do I need the VTL, or can I go along with using file devices.
> According to the TSM manual (dont have the link , but if you want i'll find
> it) the maximum supported file device pool for deduplication is 6TB... so if
> you're thinking of replacing a VTL with a seq. file pool, keep that in mind.
> The limit is because the amount of resources needed by TSM to do the file
> deduplication is limited, or as the manual says, "until new technologies are
> available".
>
> The discussion here where people are actually planning on just having a
> sequential pool (since noone is actually discussing that there's a random
> pool infront) is plain scary. No sequential device is gonna have their time
> of the life having a fileserver serving 50K blocks at a time.
>
> So my last 50 cents worth is:
>
> a) Have a random pool infront
>
> b) Depending on the size of your environment, you're either gonna go with a
> filepool and use de-dup (limit is 6TB for each pool, you might not want to
> de-dup everything), or you're gonna go with a fullscale VTL. Choice here is
> size vs costs.
>
> I've seen alot of posts here lately about the disadvantages with VTL's ..
> well, I havent seen one this far with mine. I have a colleague who bought a
> XXXX VTL and found out he needed another VTL just todo the de-dup, since one
> VTL wasnt a supported configuration to do de-dup. I have another colleague
> who bought a very cheap VTL solution (from a very mentioned name around here)
> and ended up with having same hashes, but different data, leaving him with
> unrestorable data.
>
> Comparing eggs to apples just isnt fair. Different manufactures of VTL's do
> different things, meaning both performance and availability is completely
> different.
>
> Just to sum up, we've had both 3584's and (back in the days) 3575, and I've
> never been happier with our VTL (and yes, we do restore tests).
>
> Best Regards
>
> Daniel
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparrman AT exist DOT se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
>
> -----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
>
>
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: Rick Adamson <RickAdamson AT WINN-DIXIE DOT COM>
> Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Datum: 09/27/2011 18:02
> Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary
> pool
>
> Interesting. Every VTL based solution, including data domain, that I looked
> at had limits on the amount of drives that could be emulated which were
> nowhere near a hundred let alone a thousand. Perhaps it's time to revisit
> this.
>
> The license is a data domain fee, and a hefty one at that.
>
> The bigger question I have is since the file based storage is native to TSM
> why exactly is using a file based storage not supported?
>
> ~Rick
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Daniel Sparrman
> Sent: Tuesday, September 27, 2011 10:30 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool
>
> Not really sure where the general idea that a VTL will limit the number of
> available mount points.
>
> I'm not familiar with Data Domain, but generally speaking, the number of
> virtual tape drives configured within a VTL is usually thousands. Not sure
> why you'd want that many though, I always prefer having a small diskpool
> infront of whatever sequential pool I have, and let the bigger files pass the
> diskpoool and go straightly to the seq. pool.
>
> As far as for LAN-free, the only available option I know of is SANergy. And
> going down that road (concerning both price & complexity) will probably make
> the VTL look cheap.
>
> Not sure what kind of licensing you're talking about concerning VTL, but I
> assume it's a Data Domain license and not a TSM license?
>
> Best Regards
>
> Daniel Sparrman
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparrman AT exist DOT se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
>
> -----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----
>
>
> Till: ADSM-L AT VM.MARIST DOT EDU
> Från: Rick Adamson <RickAdamson AT WINN-DIXIE DOT COM>
> Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> Datum: 09/27/2011 16:52
> Ärende: Re: [ADSM-L] vtl versus file systems for pirmary pool
>
> A couple of things that I did not see mentioned here which I experienced
> was.... for Data Domain the VTL is an additional license and it does
> limit the available mount points (or emulated drives), where a TSM file
> based pool does not. Like Wanda stated earlier depends what you can
> afford !
>
> I myself have grown fond of using the file based approach, easy to
> manage, easy to configure, and never worry about an available tape drive
> (virtual or otherwise). The lan-free issue is something to consider but
> from what I have heard lately is that it can still be accomplished using
> the file based storage. If anyone has any info on it I would appreciate
> it.
>
> ~Rick
> Jax, Fl.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Tim Brown
> Sent: Monday, September 26, 2011 4:05 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] vtl versus file systems for pirmary pool
>
> What advantage does VTL emulation on a disk primary storage pool have
>
> as compared to disk storage pool that is non vtl ?
>
>
>
> It appears to me that a non vtl system would not require the daily
> reclamation process
>
> and also allow for more client backups to occur simultaneously.
>
>
>
> Thanks,
>
>
>
> Tim Brown
> Systems Specialist - Project Leader
> Central Hudson Gas & Electric
> 284 South Ave
> Poughkeepsie, NY 12601
> Email: tbrown AT cenhud DOT com <<mailto:tbrown AT cenhud DOT com>>
> Phone: 845-486-5643
> Fax: 845-486-5921
> Cell: 845-235-4255
>
>
>
>
> This message contains confidential information and is only for the
> intended recipient. If the reader of this message is not the intended
> recipient, or an employee or agent responsible for delivering this
> message to the intended recipient, please notify the sender immediately
> by replying to this note and deleting all copies and attachments.
|