The OSD model is designed to allow performance characteristics of objects to be attributes of the object itself and independent of the OSD where it resides. An HD video file on an OSD may have an attribute that specifies an 80MB/s delivery rate as well as a certain quality of service (i.e. a consistent 80MB/s). Similarly, there could be different attributes for the same object that describe delivery performance for editing rather than playback. In editing mode, the OSD may skip around to many different frames, thus changing the way the OSD does caching and read-ahead. Similarly, for latency and transaction rates, an OSD can manage these more effectively than DAS and SAN because it has implicit and explicit knowledge of the objects it is managing.
Just to put the performance question to bed, one of the cool things about OSD is how it handles zone bit recording. Because discs spin at a constant rate, the transfer rate more than doubles from short inner tracks to long outer tracks. OSD provides a simple method of offering the fastest part of the disc to the data that needs it most while still making the rest of the disk available for other data. In addition, the inherent drawback/advantage that an object cannot be overwritten makes versioning automatic and provides a consistent data state.
Transcoding and confectioneering are both compute-bound, highly automated processes. The ease with which OSD provides access to distributed objects can only improve these workflows.
Playout can certainly profit from the abstraction of the storage from the application, allowing for automated staging of items in the playout list with a minimum of overhead. As the location of all assets is automatically tracked, a misapplied file pointer will become a thing of the past.
One of the major hurdles to monetizing existing content is the tremendous amount of storage required to keep that content online. Estimates show that the cost of managing storage resources is at least seven times the cost of the actual hardware over the operational life of the storage subsystems. This is independent of the type of storage (i.e. DAS/SAN/NAS). The illusion that falling disc prices will actually reduce costs in mission-critical applications does not account for the costs of keeping the data available for on-demand applications.
Storage resource management has been identified as the most important problem to address in the coming decade. The DAS and SAN architectures rely on external storage resource management that is not always entirely effective and has never been standardized. The NAS model has some management built in, but it too lacks standards. The OSD management model relies on self-managed, policy-driven storage devices that can be centrally managed and locally administered. The execution of the management functions (i.e. backup, restore, mirror, etc.) can be carried out locally by each of the OSDs without having to move data through an external managing device.
DAS was designed for direct attachment to a single system. All the management functions are done from the single system to which these devices are attached. The difficulty arises when more systems attempt to address the same storage. Because the management is distributed among all the systems that the storage devices are attached to, complicated coordination is required, and there is no central management instance.
A SAN system has access to all of the storage devices and thus management can be centralized on any one of the hosts. However, implementing self-management in a heterogeneous environment has proved difficult. NAS devices have more “intelligence” built into them by their very nature (i.e. there is an OS with a file system, a communications stack, etc.). This extra intelligence lends itself to the idea of self-managed storage, making the overall task of managing storage resources somewhat easier. This architecture implies increased complexity when more granular performance requirements are to be met or increased performance achieved.
To achieve the requirements for PASS while at the same time reducing TOC, the OSD architecture is designed to be self-managed using the OSD intelligence built into each OSD. Devices know how to manage each of several resources individually or through an aggregation of OSDs. These resources include availability of capacity, requested bandwidth, latency requirements per session, IOPs and user-definable PASS requirements.
Finally, OSD defines the concept of “object aggregation” whereby a hierarchy of OSDs can be made to appear as a single larger OSD. The resource management of this large aggregated OSD is done either through a single or multiple redundant OSDs at the top of the aggregation or can be assigned to each of the individual OSD devices to achieve maximum resource management flexibility.
Don’t object; get objective.
—Christopher Walker is a consulting engineer for Sony DADC Austria.