GestaltIT TFD - Day 2: Wind instruments and data deduplication

By Renegade on Wednesday 18 November 2009 16:58 - Comments (7)
Category: Gestatl IT, Views: 6.139

Excuse me if I'm going back and forth in the GestaltIT Tech Field Days timeline, but I wanted to start the series of articles with a post of one of two presentations that made the biggest impact on me.

So, let's get things started with a company that shares it's name with an "ancient flute-like wind instrument" and instead of being a windbag actually does some pretty nifty things:

Ocarina Networks logo

Ocarina Networks, or Ocarina as they are usually called are a company that specialize in a thing called data deduplication and compression. Basically you can think of it as removing all the data that you find more than once and replacing all duplicates with a pointer to just one original version of the data. This can be done on multiple levels, and the most 'simple' version would be to use a corporate mailbox as an example.
Say you would send out a mail to 5 colleagues with a Powerpoint presentation you want them to review. Normally each recipient will have a copy of this file in his or her mailbox and consume the space for the attached file. A deduplication solution could for example look and find that the same file exists 5 times. It saves one version and has the others just point to this one file.

Now, you could try and do the same thing on different layers. One of those layers is for example the storage system. There the various vendors look for similar chunks of data and see if there are comparable patterns and then use the same pointer technique. There is one drawback of doing it at that level though. As soon as you have the same presentation and one of the people changes it, the disk footprint of the file changes in a way that avoids deduplication. That is quite odd considering that they probably just edited some small things and a lot of slides, logos and pictures will remain unchanged.

Ocarina actually found a way around that by working on a different layer. This also provides some other benefits, and fortunately one of the other attendees, Simon Seagrave of TechHead brought along his Flip camera (I forgot mine) and recorded Ocarina's CTO Goutham Rao as he explained what their product does and where the advantage in their product can be found.



Now, as you have heard, this is actually an optimizer that is content aware. To pick up on the example above, the optimizers created by Ocarina look at the files. They will actually go into files and check their content for duplicate chunks. Think of the example that Goutham mentioned of a corporate logo that appears in various unrelated files. The Ocarina optimizers are actually able to find such examples and effectively reduce the total footprint by combining deduplication and compression.

For a rough drill down in the areas of compression and deduplication I would recommend you bring some time and watch the following video, but be sure I warned you since it's roughly 40 minutes long. It's absolutely worth it though!



And yes, you did hear that right. One of the first compression algorithms was the Morse code. For more information on that and a further intro in to compression you can find some more information here.

Now, all of this technology is packed into two rack mountable housings called "optimizers". You will currently find two versions of these optimizers. The first one is the 2400 and you can find the 3400. Main differences include the amount of CPU's which is only natural when you take the amount of number crunching that is being done into account. Other differences are among others the amount of RAM, the size (1U vs. 2U) and the built in disks.

http://tweakers.net/ext/f/KMobBq5sdscX8Ee7gE2D0cK7/full.jpgNow, Ocarina actually makes some pretty big claim as to how they perform. If you read along on Twitter you will have seen the following picture already that shows the dedupe and compressed dedupe results when compared to a NetApp FAS. My apologies about the bad quality of the picture by the way. I didn't bing a decent camera along and only had my cellphone handy at the time.

All of the above was crammed in to a few hours, combined with some hand on and a challenge which I already wrote about. The challenge actually showed us some interesting things about the optimizers.

First and foremost, this stuff actually works, and works quite good! Because you reduce the footprint of the data going over the line, you actually use less space in all areas. I have seen a reduction in footprint of up to 70% which can make a lot of people very happy. Your storage, network and backup admins will probably be first in line to thank you for using such a product.

Second, it does have it's weaknesses. Depending on the existence of for example duplicate files, encryption and the dictionary used, your results may vary. One of the attendees brought along a small USB stick with 2GB of data on it consisting of ESX install iso files. The compression rate on them? None whatsoever.
Yes, that's right. None at all. But that might be due to the fact that we did not have duplicate files, and we just simply didn't have a dictionary for iso files. One of the advantages is that since we are dealing with software, the chances of Ocarina adding such support is not too bad. Especially since they will probably mull on the results of our datasets.

All in all I have to say that this was one of the best presentations during the GestaltIT Tech Field Days, and it's probably something that can be used as an example for future similar events.

My guess is we will be seeing a lot more from Ocarina networks in the future, and since this technology allows us to save on almost all fronts, I would assume that it won't be too long before we will be seeing similar systems that were created by other companies. I'm looking forward to see the potential of this technology unfold further and would love to see some of your comments on the product.

Oh, and last but not least a big thank you to Simon for letting me use his footage! :)

Volgende: GestaltIT TFD - Day 2: Top secret at Data Robotics? 11-'09 GestaltIT TFD - Day 2: Top secret at Data Robotics?
Volgende: GestaltIT Tech Field: Day 0 - It started with a haiku. 11-'09 GestaltIT Tech Field: Day 0 - It started with a haiku.

Comments


By Tweakers user himlims_, Wednesday 18 November 2009 18:40

Sound too good to be true, but if they could for fill their claims it could have quite some impact on current systems. What is this going to cost? And how about the de-compressing (time)?

By Tweakers user Floort, Wednesday 18 November 2009 22:23

I wonder what you gain by running a "content aware" dedup system versus a "block based" dedup system.

I currently use a simple block based dedup system for my personal backups and I really like it. I get a full filesystem snapshot of all my systems for just a few megabytes a day. Now ZFS has gained block based dedup capabilities you cen even get this build in your own filesystem.

Why would you go to all the trouble of writing software to scan the contents of a huge variety of filetypes. This makes the software massively more complex (and expensive).

By Tweakers user iceheart, Thursday 19 November 2009 00:27

Why would you go to all the trouble of writing software to scan the contents of a huge variety of filetypes. This makes the software massively more complex (and expensive).
well, many corporate storage systems will have to deal with lots and lots of, right, documents. endless numbers of powerpoint presentations, for example. now for a 20-head office, no biggie. but a 1000-head office (multiple locations, central storage or something alike) could save quite a bit of room by being even a bit more efficient in dedupping every .ppt that comes by. now do this for lots of different filetypes, and you have saved quite a bit of space on the storage systems already.

now take into account the cacheing of these parts of files. less reads on the disks and more on, say, memory or SSD buffers, makes for a lot of added throughput. if this would save 25.000 on a storage system (quite a high figure, I suppose, but that doesn't matter here, it's about the ratio) a company would gladly pay 20.000 for a product like this, because, well, it's still a 5.000 saving.

now if, for example, in times of financial crisis, you'd be faced with having to do a massive upgrade to your storage infrastructure, software like this would extend the economic lifetime of the old systems a bit further - and you could always transfer the licence to the new system a year from now anyway :)

(disclaimer: I'm no expert, but since that hardly seems to matter here on tweakblogs most of the time (:+) I thought I'd put in my $0.02)

By Tweakers user Floort, Thursday 19 November 2009 02:00

I meant the benefit of the content aware dedup versus block based dedup. I understand the fact that dedup itself can save a lot of space.

But the savings of block based dedup are huge by itself. You can improve it even better by adding a smarter chunking algorithm. But writing a bunch of content aware algorithms for each type of file you need to store can add a huge amount of code to your system. And this in turn increases the cost and possibly the reliability.

To demonstrate how effective "dumb" block-based dedup is, here is the output of my small testserver that just finished it's backup:

====== Backing up /var =====
files & dirs: 555
read size: 5960780
compressed size: 6049
shas: 780
unique shas: 9
dedup size: 5922147
total written size: 6654
dedup reduction ratio: 100%
compression reduction ratio: 16%
overal reduction ratio: 99%
====== Backing up /etc =====
files & dirs: 250
read size: 3350122
compressed size: 0
shas: 376
unique shas: 0
dedup size: 3350122
total written size: 0
dedup reduction ratio: 100%
compression reduction ratio: 0%
overal reduction ratio: 100%
====== Backing up /home =====
files & dirs: 64
read size: 6272860
compressed size: 0
shas: 426
unique shas: 0
dedup size: 6272860
total written size: 0
dedup reduction ratio: 100%
compression reduction ratio: 0%
overal reduction ratio: 100%

By Tweakers user Renegade, Thursday 19 November 2009 09:32

Please note that it's important to check what kind of solution you are using. If you are using a NetApp for example, you don't use any compression, and the NetApp uses it's WAFL environment to dedupe in 4k block increments. The Ocarina optimizers can selectively use deduplication, compression or both.

So, to try and answer your question, a block only dedupe will have problems in finding similarities that cross blocks. Take the example of a powerpoint file which has been changed. A block level dedupe will dedupe the blocks that make up each file which will probably get you some good results, but actually checking which files (or parts of files) are there multiple times will get you way better results because you avoid even having to write the deduped blocks to begin with.

Say for example:
  • You have a file with 8K, since you mailed it around you will see similar chunks on disk which can be deduped.
  • Now someone edits the file on one page and sends it back.
  • You get to save a second file with changed chunks and the pointers for the other people who received this new file.
Now, in this scenario we already have two files which probably still contain the same logo's and headers, footers and all and will usually just have some minor changes. The charm of the Ocarina solution (or a general content aware dedupe solution) is that it will know that there are large unchanged parts.

So, using the example above:
  • You have a file with 8K, since you mailed it around you will see similar chunks on disk which can be deduped.
  • Now someone edits the file on one page and sends it back.
  • Content aware dedupe finds that there is just one new page and just saves the new information on this page and uses pointers for everything else.
Basically this content aware dedupe solution should run before you actually save the file to disk because it could save you on actual blocks that need to written to disk.

And you still have the fact that this solution would still allow you to use storage based dedupe from any vendor like for example EMC, NetApp or BlueArc. A further example of the Ocarina benefits would be that you can use policies (which files to dedupe, define minimum/maximum sizes, control over block and compression sizes, etc).

You can check the outcome of a test where an Ocarina optimizer was compared to a NetApp box here.

In regards to the price of the optimizers I can't say too much since I don't have any product pricing, but I know some people from Ocarina are also reading and might be able to add something to the discussion. One tip I can give you is the ROI calculator which can be found here: http://www.ocarinanetworks.com/calculator/index.html

By Tweakers user Floort, Thursday 19 November 2009 20:25

I found the answer in the pdf you linked to: The gain in my situation (Backups) would be tiny.

By Mike Davis, Tuesday 1 December 2009 02:08

Thanks everyone for the great comments. Apologies for not jumping in here sooner. I'll see if I can address the main comments.

@himlims_: Part of our differentiation over say DataDomain is the fact that we invest in content expertise (smart algorithm PhD's), and we've solved a lot of the problems around integrating compression and dedupe into a single solution (these algorithms tend to pull against each other). Although we started life focusing on Petabyte-scale customers with dedicated multi-core solutions, we've started opening up our solution to small customers. Our smallest customer is in the 20TB range today, and our pricing is inline with that kind of deployment. Definitely not SOHO, but we have designs for that as well.

@Floort: I should clarify that we don't run code on your system. We are not a "WinZIP replacement". We run as an out-of-band solution that works under-the-covers in your NAS appliance (either SW or HW depending on the vendor). With this approach, we run transparently with no visible change to the file types for your end-users or applications. Although policies mitigate local CPU impact, you probably still wouldn't want to run the compression code on your laptop (although running decompression code there might be attractive to some).

It's also worth pointing out that we are focused on the harder problem of primary storage, not backup. Even grade-school dedupe works wonders when taking full-backup after full-backup. So living in the primary storage world with less data redundancy we have to advance the state-of-the-art a bit. And if we do ship something for backup it will be wayyy better than existing technologies ;-)

We use specific and generic, open and proprietary algorithms depending on what the input logic tells us about the data. it's a simple matter of ROI; if adding an algorithm shrinks data better, then it's worth adding it. Adding algorithms doesn't add complexity or technology risk per se because a buggy algorithm is simply an algorithm that doesn't shrink data well, and our context engine will ignore it. But without some of these content-specific algorithms we would not provide the benefits we have today for vertical applications like photos, videos, DNA sequencing, seismic interpretation, etc.

@Renegade: All good points. Dedupe comes primarily in 3 flavors; fixed block, sliding block, file single instancing. Ocarina uses a sliding block algorithm that is informed by our delayering algorithms. In other words we have good hints as to how to make a more efficient sliding block.

One of the problems we see with Microsoft Office 2007+ formats is that they are compressed by default, and that completely foils traditional dedupe schemes. If your editor changes a single letter in that Powerpoint, then *all* the bytes in the file change, and dedupe goes to 0%. But if you first unwrap the file, identify the image and text sub-objects in that document, dedupe then compress them with the ideal algorithms, then you can achieve fantastic results. We're even pretty good at doing this for files we've never seen before.

Comments are closed