Archiving or backing up large amounts of data to the cloud is very appealing until one starts to examine the mechanics of actually sending or retrieving that data from the cloud. Waiting minutes or hours to send or retrieve data is no longer acceptable to today’s end-users who are rapidly becoming accustomed to near-instant response times. In this fifth and final part of my interview series with BridgeSTOR’s CEO John Matze, he explains how sending or retrieving data in a piecemeal fashion to the cloud is the fastest and most effective way to do so.
Jerome: When an application writes to a BridgeSTOR cloud appliance, does it write to both the local cache and to the cloud at the same time? If so, are those writes going to take some time to complete?
John: I am glad you brought that up. Linux is not an asynchronous operating system so it took some work on our side to get writes to the cloud to work. So when the write completes, the file will go ahead and close so as far as the app is concerned, it thinks the file is closed and the write is complete.
In the background the IOs are actually going out to the cloud. Another piece of this is that we do block based IOs so you can set the blocks to whatever size you want. This is one of the reasons we get so much performance. Many of the object store guys have only a 4K buffer as that is all most file systems support. We can have a 100 MB or larger buffer.
The other piece that we do differently than the object store guys is not only can you have those buffers, but you can round robin between different ports. When the BridgeSTOR appliance uses in S3, it may use three or four different S3 connections. Then as IOs go out on one port, we can be ingesting data on another. In this way you have got not only random IOs going out, but you also have them going out different ports at the same time.
Jerome: It sounds like this gives an organization the flexibility to retrieve or a read data from the Amazon cloud without really disrupting the writes going out there at the same time.
John: Exactly. That is one of the reasons we broke up the object into sub-objects, if you will, or smaller blocks. This way we can handle a huge object up in the cloud but more efficiently as we store it and retrieve in little pieces instead of having to send or bring down the whole object at one time.
Jerome: By sending it or bringing it back in little pieces, can you do this across multiple different channels and reassemble it?
John: That is correct. If you just modify the front end of the object, just that front end piece gets saved up there, not the whole object again unless, of course, you want to replace the whole object. For video editing, this gives you the flexibility to just modify a small portion of the file so you do not need to bring the whole file back
Jerome: Where do you see yourself stacking up among the different cloud appliance players? Are you strictly going to go after the tape market initially with the cloud VTL appliance? Or do you see some other opportunities as well?
John: We are looking to come out with our own cloud service based on Amazon as the back end. That will differentiate us a little bit. Where everybody else is just trying to sell themselves out as a CAPEX type product, we are looking as an OPEX model. The service is going to be pretty straightforward with a low entry point as far as the dollars go.
In terms of the Cloud VTL appliance, we are looking at an OEM agreement but I think that’s is going to be a BridgeSTOR product as well as it is so unique that we should be able to drive the sales of that.
In part I of this interview series we take a look at some of the different gateways solutions available for accessing public storage clouds and how they differ.
In part II of this interview series we discuss the inner workings of the VTL interface that BridgeSTOR is making available on its cloud gateway appliance.
In part III of my interview series wwe discuss how using the BridgeSTOR VTL cloud gateway appliance organizations can move their tape museums into the cloud.
In part IV of this interview series, we examine the different methods that a cloud storage gateway might manage data it stores in the cloud.