back to article Looking closely at HP's object storage: Questions Answered

Looking closely at HP's StoreServ and StoreAll announcements at HP Discover we wondered if the object storage was simply an object access method layered on the base StoreAll file system. It isn't, being a real object deal as the Q and A session below shows. We talked to Patrick Osborne, the Director of Product Management in HP …

COMMENTS

This topic is closed for new posts.
  1. Jim O'Reilly
    Pint

    What is an object store?

    One of Chris's comments - "Is this an object store or just an access method?" - raises the issue of what object storage really is. Object stores consist of three things, an access method such as SOAP, a database type file system, and an underlying data integrity method for distributing data over drives and nodes.

    To me, we've reached this point by conflating all three, but in reality these are three independent issues, and denial of that is holding back the convergence of the storage industry. We could use SOAP and REST with a standard file system, but it would be clumsy. We do use NFS and CIFS with object stores. A database file system would work as well as a standard file system, and either files or objects could be stored on either RAID or replication.

    This conflation began in the 'early days' of object storage, with, for example, the Replicus model. Acknowledging that we have three separate degrees of freedom here will allow us to move ahead on converging NAS and Object. BlockIO will fade away of its own volition, in the way that direct writing to disk, without a file system, faded away.

    1. Anonymous Coward
      Anonymous Coward

      Re: What is an object store?

      I'd argue that you shouldn't be able to access objects in a store with general file access protocols like NFS/CIFS/FTP/etc. a file should always be checked in and out through an API of some sort, otherwise you've just got yourself a fancy NAS device.

      An object store needs to have something as a header or access node processing requests, distribution of files, replication, retention etc. which makes it more than a NAS.

      1. Jim O'Reilly
        Pint

        Re: What is an object store?

        I think the second part of your comment is very correct. In many ways, Object storage is a superset of NAS. A major weakness of standard NAS is that it doesn't deliver multinode data protection, nor does it inherently service remote replicas. I like Object stores for solving these problems.

        But if you look at Object storage this way, assimilating legacy protocols should be a part of the package. It's certainly possible to do so.

        Databases work with objects too. These are record elements. As we look at Hadoop, the elements can be very large objects such as video files and such. I think this will speed up convergence to Object storage as the mainstream storage method.

    2. sapidmolecules
      Meh

      Re: What is an object store?

      I am in for the convergence.

      However I am displeased these systems defuse one of the reasons modern object storage is used: economics of scalability.

  2. random_graph

    What is actually implemented here?

    It looks to me like Storeall is merely the marriage of Autonomy and the iBrix file system. But there's no reason to believe the integration goes any deeper than physical. They are merely running index, search, and the RestFul API on the iBrix segment servers. Ibrix is no more object or metadata aware than a Netapp filer.

    In regards to what constitutes "Object", There's no reason Object and NAS need to be distinctly defined. The most popular object storage in the world is Isilon, which uses Reed Solomon and distributed placement algorithms with self-healing. Ok, the fact that it's accessed through a heirarchical FS puts it in the NAS camp. But even the file system interface can be merely an expression of object metadata. For example, Sun's Honeycomb could provide an NFS export whose heirarchy was purely a virtualization of a metadata schema...N file systems could be exported with N arrangements of the schema.

    I fully expect to see future NAS (and SAN) leveraging more and more object capabilities, and the availability of RESTful APIs representing "the new converged" regardless of underlying architecture.

This topic is closed for new posts.

Other stories you might like