Cloud Storage with Enterprise Compatibility

 

In order for a cloud storage service to be a viable option to host enterprise data sets, it must be accessed like traditional storage.The solution should appear just like any other traditional NAS filer on your network. Then you can instantly extend your existing environment into the cloud without any modifications to your existing enterprise application infrastructure.

 

Zetta Storage Service is:

 

Mounted like any existing network share

You mount a Zetta volume as a Unix or Windows network share exactly as if it were on your network inside your firewall.

 

Accessed via a full-featured, distributed file system

Zetta Storage Service is built as a full-featured file system. Volumes are accessed over existing paths, directories, permissions, and commands, and seamlessly integrate with external systems (e.g. LDAP), while delivering all the capabilities of a traditional session including ACLs and strong consistency.

 

Served up over traditional protocols across all operating systems

Zetta volumes are accessed over the protocols that your applications and operating systems use today (and have for many years) — mount the storage as a file share over HTTP-optimized WebDAV or access it as an FTP server for large file transfers.

 

POSIX compatible

Enterprise usage requires compatibility with the POSIX command set. Virtually all enterprise applications are written with the expectation that the POSIX command set will be available. One key piece of this is strong consistency — POSIX compatibility ensures that any read from the data set will yield the data from the most recent write. Without this, the applications must be modified to manage cases where a read is yielding out-of-date data.

 

Contrast this with the current generation of HTTP-centric object stores:

 

• HTTP object stores are not “mounted” like an existing network share, with a robust set of commands available, they are accessed using GET/PUT/POST/DELETE Web APIs, and your enterprise applications would need an overhaul to support that change.

 

• HTTP object stores lack the file system semantics your applications expect, instead using a simplified bucket/object storage paradigm.

 

• HTTP object stores leverage (often proprietary) Web APIs (either REST or SOAP), not the NFS/WebDAV/FTP open protocols your operating systems are made to use.

 

• HTTP object stores implement an “eventual consistency” model that violates POSIX and does not ensure that your applications will read back the most-recently writen data. Your applications would require costly modification to adapt to this deficiency.

 

For more information, read Chris Schin's blog entries including “Accessed Like Traditional Storage.”