ADSM-L

Re: [ADSM-L] Real world deduplication rates with TSM 7.1 and container pools

2016-03-21 07:11:27
Subject: Re: [ADSM-L] Real world deduplication rates with TSM 7.1 and container pools
From: Hans Christian Riksheim <bullhcr AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 21 Mar 2016 12:08:46 +0100
We are also getting around 60% in dedup savings. When I compare similar
data going to tape I find that simple compression saves us about 40%.

Hans Chr.

On Mon, Mar 21, 2016 at 8:54 AM, PAC Brion Arnaud <
Arnaud.Brion AT panalpina DOT com> wrote:

> Michael, Ken and Stephan,
>
> Thanks a lot for valuable input !
>
> Based on your feedback, I believe that IBM is effectively overselling it's
> product  : best value announced is around 65 %, which means dedup factor
> around 2.5 ...
>
> Reason why I asked is that we are currently making use of Data Domain
> VTL's in our shop, which at present time have a dedup factor of 7.7, but
> are aging and should soon be retired.
> I was wondering if their replacement with a combination of cheap disk
> storage and TSM deduped container would be a good idea ...
> So far I still need to be convinced : disk (IBM, Hitachi ...) is way
> cheaper than a VTL, but TSM dedup rates are seeming to be less than
> expected : this will probably force us to buy more disks, thus making such
> a solution less attractive.
>
> Cheers.
>
> Arnaud
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Stefan Folkerts
> Sent: Friday, March 18, 2016 5:32 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Real world deduplication rates with TSM 7.1 and container
> pools
>
> We see around 50-65% deduplication savings on the fileclass storagepools,
> most common seems to be around 55%.
> It requires what I call "deep reclaims" with very low values that need a
> lot of time.
> We are seeing 60-70% on containerpools but on average it is more like 65%
> but that is based on a much smaller install base.
> Both in heterogeneous environments.
>
>
> On Fri, Mar 18, 2016 at 5:06 PM, Ken Bury <kenbury1 AT gmail DOT com> wrote:
>
> > I have two 7.1.4 servers, one with devclass file with dedupe, and the
> other
> > is using containers. The two servers are in a node replication pair so
> the
> > data on each server is exactly the same. The workload is almost
> exclusively
> > vmware backups with datamover dedupe and compression. The data reduction
> > for both pools is 89%. I like what I am getting from container pools and
> > replication.
> > On Fri, Mar 18, 2016 at 11:35 Ryder, Michael S <
> michael_s.ryder AT roche DOT com>
> > wrote:
> >
> > > Hi Arnaud
> > >
> > > If IBM made that commitment in black and white, then you should hold
> > their
> > > feet to the fire.  But I am willing to bet this was a salesman
> promising
> > > "similar performance."
> > >
> > > There is no technology I know where any deduplication factor can be
> > > guaranteed.  Perhaps "UP to 4" for certain kinds of data...  And
> overall
> > > reduction of storage is what you should be comparing, not simply the
> > > deduplication percentage.
> > >
> > > Here, try reading at least the introduction of this document, "
> Effective
> > > Planning and Use of TSM V6 and V7 Deduplication"
> > >
> > >
> > >
> >
> http://www.ibm.com/developerworks/community/wikis/form/anonymous/api/wiki/f731037e-c0cf-436e-88b5-862b9a6597c3/page/82e361b4-8e96-42cf-b559-0b77df9aed2c/attachment/5cf980b3-807f-464b-a1c0-b896b0cec7e6/media/TSM%20Dedup%20Best%20Practices%20-%20v2.1.pdf
> > >
> > > We haven't adopted the directory-container pools yet due to their
> lacking
> > > of support for important features like migration and copy pools, but I
> > have
> > > no doubt that IBM will be delivering those abilities soon; otherwise,
> > there
> > > are very limited use-cases for directory-containers.
> > >
> > > Best regards,
> > >
> > > Mike
> > > RMD IT Client Services
> > >
> > > On Fri, Mar 18, 2016 at 10:41 AM, PAC Brion Arnaud <
> > > Arnaud.Brion AT panalpina DOT com> wrote:
> > >
> > > > Hi All,
> > > >
> > > > We are currently testing TSM 7.1 deduplication feature, in
> conjunction
> > > > with container based storage pools.
> > > > So far, my test TSM instances, installed with such a setup are
> > reporting
> > > > dedup percentage of 45 %, means dedup factor around 1.81, using a
> > sample
> > > of
> > > > clients which are representative of our production environment.
> > > > This is unfortunately pretty far from what was promised by IBM (dedup
> > > > factor of 4) ...
> > > >
> > > > I'm wondering if anybody making use of container based storage pools
> > and
> > > > deduplication would be sharing his deduplication factor, so that I
> > could
> > > > have a better appreciation of real world figures.
> > > > If you would be so kind to share your information (possibly with the
> > kind
> > > > of backed-up data  i.e. VM, DB, NAS, Exchange, and retention values
> > ...)
> > > I
> > > > would be very grateful !
> > > >
> > > > Thanks in advance for appreciated feedback.
> > > >
> > > > Cheers.
> > > >
> > > > Arnaud
> > > >
> > > >
> > > >
> > >
> >
> ******************************************************************************************************************************
> > > > Backup and Recovery Systems Administrator
> > > > Panalpina Management Ltd., Basle, Switzerland,
> > > > CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
> > > > Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
> > > > Direct: +41 (61) 226 19 78
> > > > e-mail: arnaud.brion AT panalpina DOT com<mailto:arnaud.brion AT 
> > > > panalpina DOT com
> >
> > > > This electronic message transmission contains information from
> > Panalpina
> > > > and is confidential or privileged. This information is intended only
> > for
> > > > the person (s) named above. If you are not the intended recipient,
> any
> > > > disclosure, copying, distribution or use or any other action based on
> > the
> > > > contents of this information is strictly prohibited.
> > > >
> > > > If you receive this electronic transmission in error, please notify
> the
> > > > sender by e-mail, telephone or fax at the numbers listed above. Thank
> > > you.
> > > >
> > > >
> > >
> >
> ******************************************************************************************************************************
> > > >
> > > >
> > >
> > --
> > Ken
> >
>

<Prev in Thread] Current Thread [Next in Thread>