Skip to main content

What's missing from current SAN solutions?

Today's SAN architecture promises "democratization" of data access, i.e., inexpensive, non-mediated, and shared access to centrally-managed storage. In existing SAN deployments, this promise is only partially met. What's missing?

  • Sharing – Typically, each logical unit (LU) is used by only a single host. The storage is partitioned among the hosts, and the hosts treat the storage as if it were directly attached.
  • Mediation – Sharing is typically accomplished by having a file server mediate access to the underlying storage.
  • Cost – Today's SANs are almost 100% based upon Fibre Channel, an expensive technology.


  • SAN file systems provide direct sharing – SAN file systems, such as Storage Tank, Lustre, and PanFS, truly attempt to deliver on the promise of SANs, by providing unmediated shared access to data.
  • IP-based SANs are cheaper – IP-based SANs like iSCSI are expected to have a lower cost than Fibre Channel-based SANs, due to the relatively lower cost of IP infrastructures (e.g., Ethernet), as compared to Fibre Channel.
  • Limitations – Inherent issues raised by SANs that are still unresolved:
    • Security and protection
    • End-to-end management at a meaningful semantic level
    • Scalability (in particular for allocation)

What is an Object Store and what does it offer?


  • Higher level abstraction – An object store appears as a collection of objects.
    • An individual object is akin to a simple byte stream file, presenting the abstraction of a sparsely allocated array of bytes, indexed from zero to infinity.
    • The object store replaces today's block devices that present the abstraction of a logical array of unrelated blocks, addressed by their index in the array (i.e., the logical block address, or LBA).
  • Interface – Users of an object store, e.g., the file system, operate on data by performing operations such as:
    • Creating an object.
    • Reading/writing at an offset from the start of the object.
    • Deleting the object.
  • Security – All operations carry a credential, and it is the responsibility of the object store to validate that the user's request credential is valid.
    • Enforces different access rights for different portions of a volume (i.e., on a per object basis).
    • Eliminates the need to rely on an independently administered physical security, e.g., zoning, masking, etc.
  • Allocation – In an object store environment, space is allocated by the storage controller (i.e., the object store itself), and not by overlaying software, such as a file system.
  • Data Container – An object is a storage container for both customer-data and attributes (including user-defined attributes). In an object store, meta-data is an integral part of the object. This meta-data is managed, stored persistently, and recoverable with the object's customer-data. This built-in mechanism at the storage level considerably reduces the efforts required to manage and store meta-data in a distributed application along with the customer data.
  • Advanced functionality – We expect future versions of OSDs to provide advanced functionality. Such functionality includes support for collections of objects, multi-object operations, snapshots, cloning, and space-management. When implemented close to the object device, such functionality can distribute the work that today takes place in the centralized file-server, resulting in improved performance and simplified management.

Current status

While there have been several years of research on object stores, and there is an ongoing standardization effort, object storage is still not widely accepted. Why?

An object store inherently entails a paradigm shift:

  • Change in Interface – Hosts no longer communicate with control units via SCSI block read and write requests, but rather ask for offsets in an object.
  • Space Management – A host no longer handles space management within a volume. This job is now administered by the lower-level storage controller. This entails changes to the structure of a file system.

What are the benefits?

As long as SANs were used as a means of essentially emulating direct-attached storage (i.e., no sharing) over private Fibre Channel networks, the benefits of an object store were insufficient to justify the cost of this paradigm shift. With the attempt to truly leverage a SAN's promise of non-mediated, shared, and inexpensive access to centrally-managed storage, an object store becomes essential.