Some have accused this blog of being published too slowly for the fast-moving world of the blogosphere. It shouldn’t be a surprise then that after going dark for a year, I’m going to respond to some older thoughts about global deduplication offered by Curtis Preston here (updated for the DD880 a little here), also from a year ago. In the meantime, a lot has changed, including input from a new user poll by ESG that observed that most users don’t think it’s a high priority. As of last weekend, Curtis and Lauren Whitehouse both believe that Global Dedupe matters a lot. This week, we’re announcing our first Data Domain Global Deduplication Array, which settles the issue for EMC (and might have contributed to the recent spike in discussion activity on the topic.) We never said global dedupe was undesirable, we just said it was hard to build it right. It also may never be something most users ask for, since it should be invisible.
A lot of the historic debate depended on your assumptions about how fast and big a dedupe system is with a given controller, and then how easy is it to deal with if the backup load overcomes a single-controller system’s resources. Let’s start with sizing. In the first articles, Curtis suggested that if you require throughput faster than one dedupe controller can support, you really need global dedupe, or sharing dedupe across multiple controllers. His suggested throughput threshold a year ago was about 10 TB/day of backups, assuming a 12-hour backup window. A 10 TB backup over 12 hours suggests a max of about 250 MB/sec., or a little less than 1 TB/hour. The success of Data Domain without global dedupe historically argues that our enablement of larger single-controller systems has generally kept pace with the adoption curve of dedupe storage into larger enterprises.
It’s important to remember that the DD architecture is CPU-centric. DD systems are on a relentless march to be faster and bigger by riding the results of Moore’s law, benefits not enjoyed by most of our competitors who are disk-bound. In 2004, a DD system’s throughput was 150 GB/hour and stored 1.25 TB. Over 5 years (including the DD880, announced after Curtis’ first post), our systems became almost 40x faster and 60x bigger, a general trend that should continue based on Intel forecasts.
So if you have to set a threshold for the debate regarding DD systems, 10 TB / day isn’t a reasonable point of concern. If the concern starts at 12 hours of backup for a DD880, that’s a 65TB/day workload. 65 TB of backup policies are a big granule to manage, it’s not in the details anymore. This is as big as a lot of customers’ spans for an entire NetWorker data zone or a NetBackup master server (don’t attack me here, I know folks with bigger ones too). It’s worth 6 of whatever Curtis was evaluating at the time of the original post. In the subsequent post, he notes this and observes that he knows sites that are bigger still. OK.
How about migration if you outgrow a single-controller system’s footprint? This is easier than it might appear. For example, backup software policies target different groups of data to different targets. Some can even detect file-system full targets and automatically aim at a secondary target. Or, to expand or consolidate, because it’s backup, the simplest thing is just to start backing up to a new larger system and keep an older smaller system around for restores until its data’s retention period ends, at which point it can just be decommissioned. Data Domain systems (except the DD140) allow a user to start with a given capacity and add more later, so an expansion is not a migration. We also have a lot of ways to move easily from one single-controller system to another bigger one if a system is outgrown; e.g. on the DD690 to DD880 transition, existing disk shelves can stay in place and only the head needs to transition. Other techniques, such as replicating deduped data, can allow straightforward consolidation with a minimum of transition. If some think global dedupe is the only way to address these issues, as Chuck Hollis sometimes says, we may agree to disagree.
But let’s assume global dedupe across controllers is important. The key place where the notes above don’t apply is when there are groups of our largest systems in one place, so a single larger system isn’t available to provide a consolidative effect. Integrating them seamlessly into one bigger system does take a lot more work under the hood. After 5 years in the lab, we just announced our first multi-controller system, the Global Deduplication Array (GDA), which extends our SISL architecture to support global deduplication with dynamic load balancing. Here, we specifically focused on scale and simplicity, without sacrificing any of our well known properties: inline dedupe, with a design aimed at maximizing data invulnerability. You can read elsewhere for details. This system includes up to 2 controllers. Quick summary:
- Performance: up to 12.8 TB/hour aggregate backup throughput, or with Curtis’ 12-hour metric, 150 TB/day;
- Capacity: up to 285 TB addressable (post-RAID, spares etc.) for storing globally deduped info;
- (Comparison to 2004 DD flagship system, for those keeping track: 85x faster, 228x bigger.)
- Dynamic load balancing for throughput and capacity, but with global dedupe across all data.
- Unlike many systems promoting global dedupe, the GDA design compares all new data to all data stored across the system, regardless which client it was backed up from. Similar but different files with different names from different clients are deduped against each other.
- In the first release, it will support Symantec and EMC backup products only, leveraging software distributed to the backup server (Symantec OpenStorage now, and in the second half of 2010, a different/similar approach in EMC NetWorker.) Here, for extra credit, we also gave this product a global namespace.
Could we do an N-way (N>2) version of the GDA? Could we apply this technique to smaller systems? Yes architecturally. We’ll review these kinds of questions against other alternatives over time, and we’ll be very interested in customer feedback. The current GDA is >15x faster than 10 TB/day. Based on Intel roadmaps, we expect this 2-controller approach to keep growing to 5x-10x its current scale in a few years. At that point, while this is all hypothetical, it begs the question of the most appropriate eggs/baskets ratio. Also, the current GDA is already highly competitive with the largest concentration of multi-controller dedupe nodes (sometimes more-way) in products from our competitors that do global dedupe.
Does it have limitations in the first release? Sure. It’s doesn’t support all backup apps, we focused on the most advanced Enterprise apps. It doesn’t support archive apps the way other Data Domain systems do. Etc. It’s the first chapter in a long upcoming program. But we included the things first that our large customers wanted most, and watch this space.
Will people still buy multiple single-controller systems, with local deduplication and global management, DDX-style? Yes. The DD880 just doubled in size, so it now hosts 140 TB of addressable space. Per the above discussion, 65 TB of throughput per day is a pretty big granule. And it’s going to get bigger over time. Migration and consolidation after growth is already pretty easy. So what is the first priority for us with the GDA? Even simpler management when you need a lot of big systems in one place.
