How Much Speed Does a Large Enterprise Need?

The storage industry is perpetually awash with a variety of performance measurements.  These statistics, commonly referred to as “speeds and feeds,” are essential to help the enterprise technologist determine which solutions are suitable for a given storage workload.  They allow for a semblance of apples-to-apples comparison across competing products, even if one must tweak the numbers to account for varying levels of vendor optimism.

Protection storage (i.e. backup disk, tape, or other media) performance is typically measured in data transfer rates.  These rates are commonly expressed in MB/sec or TB/hr.  Both aggregate speed and single stream performance are important to the backup workload.  Aggregate speed is indicative of the big picture; given x amount of data to backup, what is the minimum possible time that the storage system will require to complete all backups?  Single stream performance is an important consideration as well, especially for high-speed backup clients such as large, powerful database servers.  Ideally, both aggregate speed and individual stream speed will be very fast.  But how fast is fast enough, especially for the enterprise?

The answer as it turns out is not all that simple.  Storage vendors who compete on feeds and speeds have a tendency to focus the customer’s attention strictly on the characteristics of their own device, ignoring the fact that protection storage is a downstream element from what is often a very large and complex technology ecosystem.  Here are a few somewhat imperfect analogies that may help simplify and put things in perspective.

Pitching a Baseball (single-stream):  When a pitcher throws a baseball it reaches its maximum velocity upon release.  The baseball never accelerates on the way to home plate.  The catcher’s mitt doesn’t exert pull on the baseball.  Therefore, if you equate the storage device with the catcher’s mitt, you clearly need a mitt that can handle a 100mph fastball, but is there a material difference between mitts that can handle 150mph versus 200mph?  Conversely, if the catcher’s mitt can only handle a 70mph pitch then your catcher will be calling for knuckleballs and changeups all night long.  In a similar fashion, backup data never speeds up after it leaves the client, yet the backup storage device must be able to handle the fastest streams possible.  Backup storage devices do not exert pull.

Terminal Velocity or Backup to Null (aggregate):  Any collection of data residing in a data center has what I think of as a “terminal velocity.”  That’s the hypothetical transfer rate that would exist if all of the backup clients sent their data directly to a null device.  In other words, how fast can the existing backup clients (or other protocols and techniques) lift the data off of their provisioned storage and send it into an infinitely fast receptacle?  The goal here is to hypothetically remove network or fiber channel (i.e. transports), any other intermediary devices (backup servers), and of course the backup storage device itself.

Given these two ideas, it should be fairly clear that a backup storage device cannot be deployed as an accelerator.  It need only be thought of as a potential bottleneck.  The goal then is to avoid having the backup storage device slow down the backups, which coincidentally is also the goal of the transports (network or SAN), and the intermediaries (backup servers.)  The further upstream you push the backup bottleneck, the closer you come to achieving terminal velocity in your backup environment, which is exactly what you want to do.  The more successful enterprise shops are the ones who intuitively understand these principles and architect complete solutions instead of comparing storage device speeds and feeds in a vacuum.

So I still haven’t answered the question ‘how fast is fast enough for the enterprise?’  The answer lies in a compound question:  How fast must a storage solution be to complete backups within the time allotted *and* if you have such a solution, is the rest of the infrastructure up to the task?  Simply put, your backup storage should be fast enough to not be the bottleneck *unless* you are able to complete your backups comfortably within your backup window anyway, in which case you may not care.  At the highest level you can say that faster is always better, but only up to a certain point.
Now here’s how the performance question starts to get interesting with Data Domain and deduplication.  For years many vendors have been using speeds and feeds arguments, warranted or not, to position their solutions against Data Domain.  However, Data Domain Operating System 4.6 broke through an important inflection point in the evolution of deduplication.  As a result, the DD690 attained an amazing 750 MB/sec of aggregate throughput utilizing a very minimal number of disks.  This meant that for the first time it was almost as fast to backup straight to Data Domain’s deduplicated storage than it was to an “enterprise” post-process deduplication controller, or even to one of the many, non-deduplicating VTL systems. 

With the introduction of Data Domain’s new flagship product, the DD880, the ante has doubled.  The DD880 sports an outstanding 1,500 MB/sec, or 5.4 TB/hr of aggregate throughput, placing it clearly on top of the leader board across all backup storage targets, dedupe and non-dedupe alike.  By comparison, a single Data Domain DD880 controller ingests data faster than a 2-node NetApp 1400 (post-process dedupe), 2-node HP 9000 (post-process dedupe), or 2-node IBM 7650G (inline dedupe) active-active cluster.

Read this if you read nothing else:  Data Domain’s single-controller inline ingest speed is now faster than a 2-node active-active clustered post-process ingest speed.

With the introduction of the DD880, speeds and feeds are no longer an inline versus post-process argument.  In fact, the sole argument that supported post-process deduplication has just been obliterated.  Speeds and feeds are no longer a dedupe versus non-dedupe argument either.  The DD880 is the new standard in backup storage performance spanning all categories.  Now we can get back to the task at hand and select a solution based on what is really important – the business requirements and the other technological realities of the enterprise.  We can put the speeds and feeds arguments to rest.  The DD880 wins in an overwhelming landslide.

Comments

[generic propecia]

Now here’s how the performance question starts to get interesting with Data Domain and deduplication.

[Cheap Vibram Five Fingers]

How handy your blog is. But some pics may perhaps be missed as I can only see a number of. Is it my pc issues or anything at all else. I'm keen to view all the picutures.

[ugg 5815 boots]

There are many times in life where we're confronted with moral dilemmas. It seems like all of our options are bad--even sinful.