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
>
|
