I was asked a great question about cloud, file system access, clustered file systems, etc. This is my response to that question/comment on one of my last posts. Note that there are two parts here. The first is about what I would call the content cloud and the second will be on the block storage cloud.
Content Cloud for Storage
Philosophically, I think that object stores are a correct approach for large scale systems and more modern Internet style applications. After all many of the things that as an industry we are trying to work into file system offerings (networked, clustered, scale up, scale out, etc.) are already there when you think about more “modern” access to things like Amazon S3 and HCAP. (Now you discover part of the reason for our purchase of Archivas in the first place. It is kind of like a wolf in sheep’s clothing because it was ultra-modern REST based system that we first deployed as a compliance and archive offering. Now, we look prescient — yes Barry I read Dune too!) For example, MS-DFS and NFSv4 offer redirection and market thinks this is a really cool thing, well it is, but HTTP has had redirection for a really long time already. If you need the ability for arbitrary metadata expressions then you can use CIFS named pipes or NFSv4 extended attributes, well again REST/HTTP allows one to express (some would say pollute) the HTTP headers as you see fit or even put items on the URL string to encode information. I could go on and on, but the important point is that REST/HTTP were designed for the Internet and NFS/CIFS weren’t.
The issue that I think all vendors continue to run into is: inertia. The fact is that the POSIX file system API has been around for decades and there are a lot of applications that have grown to depend upon it. In fact most of the business applications in existence today and a lot of the applications in the High Performance Computing segment are all oriented towards the POSIX file system APIs. In some cases the companies or organizations behind applications that rely on the POSIX file system API have themselves been around for decades and are loathe to change because of their investment and recurring revenue/maintenance stream for their existing product. What does this mean? I think it means we need bridging technology. Already Hitachi has this with our HNAS to HCAP migration which has gotten better with the most recent release of the HNAS software. Basically HNAS has only had a the ability to target Fibre Channel LUNs, we added NFSv3 targets late last year, and we are now adding REST targets — HCAP specifically. (Note I say we because it is the HDS engineers in the UK at BlueArc that have done this.)
Other vendors are repurposing their existing offerings notably NetApp (OnTap with AWFL, err WAFL), HP (Polyserve) and IBM (GPFS). Only Hitachi and EMC have recognized that there is a entirely different class of product required for these modern applications. We have also recognized that due to the inertia a first class CIFS/NFS bridge to the REST based object stores are required. This was one of the reasons why Hitachi invested in the HNAS to HCAP migration feature set and I would say continue to “stay tuned” to Hitachi for things on this topic.
Block Cloud for Storage
Not just content to think that the Content Cloud is the only solution our customers were looking for, Hitachi long ago recognized that a consolidated block storage infrastructure can also provide a major boost to people looking at building these infrastructures out internally — welcome to the party EMC. That is one of the hidden reasons behind the joint white paper between Microsoft and Hitachi with respect to Hyper-V (note I cannot go into too many details here). We feel that the predominate approach here is to bind VM images to a highly scalable block storage infrastructure with value added services. We take this approach already internally at Hitachi with a couple of different business units and have been working closely with customers/partners to make this happen for them as well. Capabilities like multi-tenancy, HDP, virtualization, migration, snapshots and a hyper energy efficient storage system all make our storage well suited to cloud. Here, however, a file system is not required at the storage layer. We are offering value added block storage services in a scalable package, and being copied by our competition. (While we only need to do the solutions and services work leading to white papers our competition needs to man a multiyear development effort to build an entirely new platform.) Capable of solving complex use cases such related to rapid OS/VM image provisioning, alignment with array based copy features, matching virtual servers and server containers with storage partitions, etc.
So I hope that this answers the question which was posed to me already, of course I’m open to further discussion and debate.
Comments (0)
