I agree, block-based I/O in/out of the cloud does seem to be a problem due to latency (and of course integrity). I suspect that it is being used today because our current access models don’t understand anything else. The appliances being put together by Cirtas etc I would expect move away from direct block access and use clever caching techniques to get best performance. There is of course the integrity trade off there because should the onsite appliance fail or be lost, then data is also lost from the cloud copy.

Chris

Good article. But I fail to understand the typical use cases for accessing a block device over the cloud – something that a typical cloud based block-storage vendor would give. I can think of remote replication as the only a possible use case. A replication is usually a one way write traffic under normal circumstances in which the data being replicated is not required to be processed any further.

Using a cloud based block storage like a general purpose storage for reads cannot not be the case – since the IO latencies would dent the performance of the application which is supposed to read the data.
Think of a cloud based block storage which is being used by as database from the cloud’s customer side. In this case the database engine would be starved because of huge latencies involved in reading from the cloud store.

A cloud block storage would help if a file system is mounted on it and the need is to access these files distinctly and discreetly.

I agree this kind of approach will be necessary. As you point out, cloud storage isn’t aware of the underlying technology, so has to be “helped”.

Chris

I believe that storing block level data in the cloud is a much easier task if you accept hybrid approaches.

You could, for example, build a kind of proxy device (either as software or as appliance), that provides local access via e.g. iSCSI on a block level. This device could do regular snapshots of the LUN and store these as single objects in the cloud. You’d do a snapshot every x megabytes or every y seconds. With this kind of “aggregation” of small IO requests to larger snapshots one solves the latency problem, for the price of not having realtime access to the data in the cloud.

I admit that this is a pretty different service than a direct block-level access, but from my point of view this is much more viable. And it can still deliver the single most important feature of block-level storage virtualization: Compatibility to applications that are not cloud-aware.