ADSM-L

Re: [ADSM-L] tsm and data domain

2011-06-16 18:04:41
Subject: Re: [ADSM-L] tsm and data domain
From: Nick Laflamme <dplaflamme AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 16 Jun 2011 16:59:47 -0500
On Jun 16, 2011, at 2:49 PM, Tim Brown wrote:

> Any one use emc's data domain devices for storage pools and replication
> 
> Would like to here positive and negative issues.

My current employer has dozens of DataDomain DD690s and DD880s, all arranged in 
pairs in which one is primary and one is a DR replication target. (Each of our 
data centers is primary for some stuff and the DR site for other stuff, so 
there's no clear "DR site" vs. "main site.") We mostly use them as VTLs; it was 
an easier conversion that way than to overcome the resident anti-NFS bias and 
convert to FILE class devices while doing a migration to new hardware.

We like them. We keep them relatively small for each head unit (20-30 effective 
TB, well below maximum capacities), so our cost per GB might be a bit higher 
than it has to be, but it saves us from having nightmares about DR scenarios 
when everyone wants to do restores at once and it all grinds down. (Only two 
FBA adapters? Compared to EMC's older CDL's, that's distinctly smaller.)

We're just now converting from sometimes very large replication pools of 
"tapes" to replicate into several smaller pools of tapes to restore. We found 
out the hard way that when our WAN providers have bad days or when our 
long-haul switches start dropping packets, the restoration (and catch up) of 
the replication can be painfully slow when service is restored if you only have 
a couple of pools of volumes. Replication gets bound by housekeeping, not 
network bandwidth, if you have too few pools. 

Probably like any VTL technology, tape errors are almost completely a thing of 
the past. Capacity planning is a bit tricky; some workloads dedupe nicely, but 
some of our DDRs have dedupe ratios of 5 or less, 

We need to do a bake-off -- or study someone else's -- between using 
deduplication in a DataDomain box and using both client-side deduplication and 
server-side deduplication in TSM V6 and then writing to relatively inexpensive, 
relatively simple (but replicating) storage arrays. However, we keep pushing 
the limits of stability with our TSM V6 servers, so we haven't dared tried such 
a back-off yet. 

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