Blocks vs. Files: Which Approach is Better for Cloud Gateways?

There are two ways of establishing a gateway between a company’s local storage infrastructure and the cloud. The most common one is the block-based approach. Here, the gateway works directly with blocks, the 512-byte fundamental units of storage. Nearly every business-oriented cloud gateway is a block-based system. Nasuni took a different approach, and I’d like to explain why.

When my co-founder, Andres Rodriquez, and I started talking about building a cloud storage gateway for business, the blocks vs. files question was our first serious debate. Initially, Andres argued that blocks would be the right approach, mainly because I’d spent the last twenty years working in block storage for companies like EMC, Memorex-Telex, StorageTek, IBM and others.

Blocks are raw chunks of storage on a drive. Blocks can support any application and are typically accessed through standard interfaces like Fiber Channel and iSCSI. You can do anything with blocks. Blocks make up the foundation underneath file systems. Some applications bypass the file system and go directly to blocks in order to gain a performance edge.

Applications assume that blocks exist in local, fast storage.

Enter the cloud. When you start abstracting these blocks, taking them out of local storage, the connections between the applications and the storage can become strained. The apps weren’t designed to handle blocks with these new latencies. They’re built on the idea that blocks are fast, but when the cloud is involved, they are not. You’ll get weird timeouts, and there are no quick remedies. Normally, apps need to be certified to work with block-based systems, but you can’t certify every single app sitting on your system. This takes time. Finally, if things start to break, the company that sold you the app won’t want to help. It’s not their problem, since they didn’t design their application to work with a block-based cloud gateway. This is the challenge faced by vendors building block-based cloud storage gateways.

There are a couple of ways to mitigate the latency issues. The most ambitious approach, favored by companies like Cirtas, involves identifying critical blocks and throwing lots of disk-based storage at the problem. The gateway lives on a high capacity appliance that has several terabytes of space. The blocks will have predictable latency until the cache fills up, and some of the blocks need to be evicted. At that point the behavior of the storage could be unpredictable leading to application timeouts. It is important, in this approach, to select applications and use cases that can tolerate the additional latency gracefully (i.e. with no time-outs).

The second and more simplistic approach used in the block-based gateways is to avoid the cache altogether and just mirror to the cloud. This is an easy way to get data offsite but fails to leverage cloud storage as a way to extend your own storage. This way, data is always local, so there’s no latency. All those applications will work just as they did before, but elastic, unlimited storage is one of the best things utility storage has to offer.

Intelligent caching is really, really difficult when you’re dealing directly with blocks. I spent years developing algorithms that would try to figure out how different blocks were related to their neighbors, which blocks to fetch, and when to fetch them. Ultimately, though, with blocks you’re just guessing. The algorithms in systems like those in EMC Symmetrix are some of the most sophisticated in the world, but they are trivial compared to what is possible with files.

Files provide a clear picture of the relationships among the blocks that support them. I felt that in order to deliver a reliable cloud storage cache we were going to need better information and control than the blocks would give us. Files connect the dots among the blocks. You also know the file types and sizes which allows the cache to make more intelligent decisions. The goal is to maximize the cache hit rate and reduce the need to fetch data from the cloud.

Both block and file based gateways provide snapshots to the cloud. These snapshot are critical in order to restore your data to previous, consistent points in time in the event of accidental data loss or corruption. Block-based gateways restore at the volume level, essentially restoring the blocks in a volume to a previous point in time. This is only useful if an entire file system or host application store has become corrupted. File-based gateways provide restore capabilities at the file, directory, or complete file system level. This is far more practical if the goal of IT is to recover an older version of a particular file or set of files. A volume restore would require IT to find the volume snapshot at the right point in time, mount it, find the file, drag it out, then unmount the snapshot. That is a long and annoying process. If your business is files, file snapshots offer the easiest way to restore files.

We looked at all these potential problems, and realized that the block approach didn’t match our vision. We wanted a complete solution that solved IT pain and took advantage of all that the cloud has to offer. We wanted to deliver unlimited capacity, and do away with backup for files altogether.

Of course, we also knew there would be limitations to the file-centric approach. It would mean that we could only address the pain of unstructured data, not structured data. But after considering what has been happening in most companies today, we decided that limitation was worth it. The reality is that unstructured data is growing at a much faster rate than structured data. There’s more IT pain on the unstructured side. By focusing on files instead of blocks, we realized that we’d be able to hone in on a bigger problem.

After a few days, Andres and I settled our debate. That was two years ago. Nasuni is our answer to everything a cloud storage gateway should be: predictable caching from a smaller local footprint and super easy file-level restores.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.