Dave Graham's Blog

In part one of this series, we discussed the nature of content within the cloud. After determining the nature of the content being stored, it is important to understand how this unstructured and structured content will be stored. The mechanism for storage has significant impact on a provider’s Service Level Agreement (SLA) to the end user and can also promote the concept of tiered storage within the cloud as well.

To evaluate this storage mechanism, you need to pull apart the storage path to determine what influences it has on the content being stored.  Technologies such as encryption, de-duplication, compression, object-model storage (a la XAM), and even the underlying file system can have a large part in storage and the subsequent retrieval.

COSS Part 2: How is Content being Stored?

Filesystems

One of the first paths to evaluate is the role of the underlying file system within the Cloud Optimized Storage System (COSS) environment. Hooks within the cloud storage environment typically dictate the use of open IP protocols such as NFS (Network File System) or CIFS (Common Internet File System) as an underlying method of storage.  These filesystem types are easily portable and have wide-spread adaptability and connectivity to a variety of host types and operating systems. Other types of filesystems that might be present within a COSS environment are what would be considered as “Open File Systems.”  These can be best represented by NTFS, XFS, ZFS, EXT3, ReiserFS, etc. and can also be vendor or client specific and proprietary.  Additional file systems that could be utilized would fall under the label of “Closed File Systems” and would include HP-UX, AIX, mainframe system storage, and the like.

Objects

Another method of content storage is using Object-based storage placement, best represented by XAM. Within the object method of storage, content is identified by meta-data and placed within a general pool of storage, similar to an open volume. This type of storage allows for data placement anywhere within the storage device with dependencies only on a hashing or metadata index to point to the actual physical storage location. The flexibility with this model of storage is that it truly could be “storage anywhere,” a key tenet of cloud computing.  By localizing an index to a physical device with knowledge (or awareness) of a remote system, the meta-data or hash could be in one location (or many based on intrinsic replication) and the object in multiple locations.  This type of model would be particularly effective in “edge” devices which serve simply as access points to geographically localized data.