ADSM-L

Re: [ADSM-L] DataDomain and dedup per node

2012-04-23 10:46:52
Subject: Re: [ADSM-L] DataDomain and dedup per node
From: "Allen S. Rout" <asr AT UFL DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 23 Apr 2012 10:38:45 -0400
On 04/19/2012 10:04 AM, Schneider, Jim wrote:
The most serious problem we have encountered is the effect of
reclamation on backup throughput.  We have a 1 GB backup network that is
used for servers to write directly to the Data Domain, bypassing TSM.
When only one client is writing directly to the DD we see backup network
utilization around 85%.  When reclamation is running the client gets 5%
backup network utilization.  I've cancelled reclamation and watched the
client throughput increase, then drop again when autoreclamation
restarts.  We now only run reclamation when the client's 1 TB daily
backup is complete (a 4- to 5-hour process).


Another axis on which reclamation will affect your DD behavior is the
amount of dead space due to uncleaned snapshots.   You can think of this
as analogous to PENDING physical volumes.. Below I've included a
terribly contrived example, which I hope is at least a little clear.

The key is that there's a gap of formally unusued, but not-yet-available
space on the DD.  The size of this gap is related to the churn rate of
the files.  If you reclaim madly, you'll eventually make that gap grow,
a lot.

OTOH, some of that space will dedupe (I'd guess that copying 'most of' a
file from A to B on the DD ought to dedupe pretty darn well. :)

----

Say you run snapshots daily and keep 7.  You write one volume a day,
keep two weeks of them.  You've got REUSEDELAY set to 5, and we'll start
on a Sunday, Jan 1.

So, at day 14 two Sundays downrange, you've got files

/ddfiles/vol01  -> vol14   present in TSM, on the filesystem

On Monday the 15th, vol01 is PENDING to TSM, but still present on the
filesystem.

On Saturday the 20th, vol01 is deleted from the filesystem, but
referenced by the snapshot you took on the 19th.  Gotta keep it around.

On Friday the 26th, this is _still_ true.  vol01 is deleted but still
referenced by an active snapshot.  It's now in the company of
vol02-vol06.  Sometime that day, though the snapshot from the 19th will
expire.  BUT WAIT THERE'S MORE...

You don't get the space back from the expired snapshot until the cleanup
on (by default) the following Tuesday. So on January 30th, if all goes
well, you'll run the administrative process which returns to you the
space occupied by vol01.


We're accustomed to thinking in terms of volumes and reusedelays:  this
is really just another few iterations of that, but it's important to
keep in mind that they sum.


 - Allen S. Rout