Storage terminologies have elevated themselves well into the media and video storage space becoming near household words used to generically describe storage architectures. Beyond the traditional RAID configurations, the two most familiar forms of network-based storage are storage area networks (SAN) and network attached storage (NAS) systems.
From an access and file system perspective, SANs utilize the SCSI block input and output (I/O) command set to provide high data throughout with high random access, and direct access to data at the level of the disk drive or as fibre channel. The NAS uses the network file systems (NFS) or the common Internet file systems (CIFS) command sets as the basis for its data access.
As the practices and deployment of file-based workflow become consistent and common, the necessity to retain and to couple the associated attributes, properties, descriptions and metadata elements becomes paramount.
With the interchange nature of media files permeating collaborative editorial processes, it is essential to contain, control, protect and manage all the elements of the media exchange and transmission.
No longer is it practical to carry separate databases or other components in disparate systems that must be continually linked or interrelated through secondary or other alternative interfaces. New means to manage this information has paved the way to advanced and somewhat nontraditional forms of storage architectures.
SO WHAT’S NEW?
Fig 1: Block-based vs. object-based disk structures. Objects are typically composed the object identifier (OID), attributes (inferred and user supplied), user metadata (creation date, time, etc.), and the actual data. An emerging form of storage architecture, at least in the domain of professional media server and storage technologies, is found in a development within the enterprise architecture community, which has been ongoing for the past five years or so. This technology, called Object-based Storage Devices (OSD), is structured such that a device utilizes a standard that addresses which data is organized and accessed as objects.
Objects, in principle, are not new in concept, yet the idea is relatively new when applied to storage. Objects are defined as an ordered set of bytes that are associated with a unique identifier—and, in a more general sense, can be any item that can be individually selected and manipulated.
In the context of storage system standards, the OSD interface is an extension to the SCSI protocol developed by a working group of the Storage Networking Industry Association (SNIA) for the T10 committee of INCITS—the International Committee for Information Technology Standards. The movement toward OSD-implementation may be viewed as important a change to the industry as object-based programming became over a decade ago; and promises to have similar impacts on all enterprise architectures going forward.
The object-based data access model is analogous to a logical unit, which is usually addressed as a ‘logical unit number’ (LUN) that, in current SCSI protocol, is a 64-bit identifier generally divided into four 16-bit pieces that reflects a multilevel addressing scheme.
The object-store in OSD allows access to data by means of storage ‘objects’—a virtual entity that groups together data that has been determined by the user to be logically related. (See Fig. 1.) Usually deployed as a device-oriented system, OSD is based on data objects that encapsulate user data, including user attributes and user metadata.
One underlying principle in object-based storage is that it allows for the combination of data, attributes and metadata to set up, and, in turn, determine the data layout or the quality of service (QoS) for the system on a per-object basis. Thus OSD improves manageability and flexibility for all of the data sets in a system.
To place OSD into perspective, compare the differences in block-based versus file-based methods of traditional storage system architectures. Block-based methods of storage include parallel SCSI, SAS, FCP, ATA, SATA; whereas file-based methods are composed of NFS and CIFS.
In OSD, there is a differing management structure than that of the traditional SCSI-3 Block Commands (SBC) structure. This principle difference is at the file-system storage management level, which is replaced by the OSD interface and OSD storage management. (See Fig. 2.)
Subsequently, the traditional sector or logical block addressing scheme is transformed and is now located just ahead of the block I/O manager for the storage (drive or tape) device itself.
OSD OR OBSD?
The physical components of OSD, i.e., the Object-based Storage Devices (OBSDs), are those storage components of the system that are to be shared (i.e., disk drives, RAID subsystems, tape drives, tape libraries, optical drives, jukeboxes, or other storage devices). More properly, an OBSD is that SCSI-device that implements the OSD standard.
As the industry and the enterprise reaches forward toward the concepts of virtualization; objects become those elemental structures that allow high-performance, intelligent storage systems to meld into the media environment.
Over time, the object-based disk may become the replacement for the block-based disk as it enables newer technologies that are essential to data management, protection and even collaborative operations’ success. Examples of where OSD technology is currently implemented include snapshots and error reporting.
Fig 2: Traditional model vs. object-based model for access per the T10 OSD-3 working group of INCITS. Object-based storage devices (under the OSD-2 version) enable the ‘snapshotting’ of storage systems to occur. Snapshots are a point-in-time copy of all the objects in a partition. Each snapshot can be placed into a new partition, moved to a central store or replicated to another site.
Using copy-on-write techniques, a space-efficient duplicate of the data set is created such that the two partitions can share objects that are unchanged between the snapshots. OSD might in turn physically copy the data to the new partition; however, the OSD standard also defines clones, a writeable snapshot that is created as a read-only partition that is also used in data protection functions.
Another application for OSD is called a ‘collection,’ which is often used for error reporting. The collection is a specific type of object that contains the identifiers of the other objects. Should an object become damaged due to a software error (within the OSD environment) or a media defect, its identifier is then placed into a separate error collection that can be queried independently for further corrective action.
As with any emerging and evolving technology, there are working groups that continue to produce documented changes to current implementations. The current status level of the standards development for Object-based Storage Devices, at the T10 Working Group in INCITS, is ‘OSD-3’ (a document titled “SCSI Object-Based Storage Device Commands-3”).
This SCSI command set is designed to provide for the efficient operation of input/output logical units that manage the allocation, placement and accessing of variable-size data-storage containers. Objects, in this application, are intended to contain operating system and application constructs.
You can expect to hear more about objects, OSD and OBSD in the coming years. In reality, some of this technology may already be implemented, quite possibly in systems you’ve already placed into service. There is significant technical and historical literature on this topic available at the T10 site (http://www.incits.org/) and from Sun Microsystems under their Solaris developer’s sites.
Karl Paulsen is chief technology officer for AZCAR Technologies, a provider of digital media solutions and systems integration for the moving media industry. Karl is a SMPTE Fellow and an SBE Life Certified Professional Broadcast Engineer. Contact him atkarl.paulsen@azcar.com.
