ADSM-L

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

2016-03-18 12:08:02
Subject: Re: [ADSM-L] Real world deduplication rates with TSM 7.1 and container pools
From: Ken Bury <kenbury1 AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 18 Mar 2016 16:06:20 +0000
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