ADSM-L

Re: [ADSM-L] Client-side dedup and (very) large databases

2015-11-27 03:27:04
Subject: Re: [ADSM-L] Client-side dedup and (very) large databases
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 27 Nov 2015 09:24:38 +0100
I don't know if this differs much from the way the filepool used to work
with client-side deduplication because I have not had a chance to play with
it but the filepool client-side dedup worked fine, but in smaller setups
the speed seemed to be limited by the random read speed from the disks that
were storing the data (assuming you have a SSD SP database).
When I increased the speed of the filepool luns (by adding more drives to
the pool) the backup speed increased, but not because of the writes,
because of the reads that deduplication caused with the use of the filepool.
It reads the data before discarding it to be 100% sure it is a duplicate
from what I understand.

But I think that if you have a very fast database (ssd or flash) and
sufficient random read speed from your container pool drives it should be
fine, just be warned for the smaller setups, the bottleneck was a strange
one in my testing.  :-)

Regards,
   Stefan




On Wed, Nov 25, 2015 at 3:56 PM, Loon, EJ van (ITOPT3) - KLM <
Eric-van.Loon AT klm DOT com> wrote:

> Hi all!
> I'm currently working on a new TSM/SP server design based on SP 7.1.3.
> I have one question about client-side deduplication which we currently do
> not use at all. All our data is deduplicated by the backend hardware (Data
> Domain). The manuals all talk about client-side dedup to be an option for
> slower LAN networks. This indicates that client-side dedup also has an
> performance penalty, which I can understand. But how about (very) large
> databases? For the majority of them about 70 or 80% of the data hasn't
> changed since the last backup. So there is no need to send it to the server.
> What is your experience? Will client-side dedup offer you better
> performance in this case or will the dedup penalty be larger than sending
> everything again over the LAN? We are going to connect the server to 10 Gb
> Ethernet, however most clients (also the larger ones) are expected to stay
> on 1 Gb. for quite a while.
> Thanks for your help in advance!!!
> Kind regards,
> Eric van Loon
> AF/KLM Storage Engineering
> ********************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
> employees shall not be liable for the incorrect or incomplete transmission
> of this e-mail or any attachments, nor responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
> Airlines) is registered in Amstelveen, The Netherlands, with registered
> number 33014286
> ********************************************************
>

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