Executive Summary

The primary goal of virtually every file-based production or broadcast workflow is to improve efficiency. Advanced media storage solutions, now capable of supporting media workflows from end-to-end, play a critical role in helping content producers and owners realize this goal. The most significant change in media storage deployments lies in the shift toward centralized storage, which provides a single shared resource available to every application, as opposed to the conventional model in which independent storage systems serve different application areas. The centralized model not only eliminates the time-consuming transfer of media between discrete storage systems, but also facilitates workflows in which multiple applications can access media concurrently. While there are many network storage solutions in the market, many have failed to deliver the promise of centralized storage. Two primary reasons for this have been poor performance and lack of media specific capabilities.

Omneon MediaGrid is an Ethernet-based network storage solution specially designed to provide users of media applications with massive bandwidth and consistently low latency without interruption or bottlenecks. Scalable bandwidth accommodates a growing volume of large media files and supports a large number of concurrent users. Low latency ensures that content can be accessed quickly and simultaneously by applications such non-linear editors while maintaining the feel of a local storage.

MediaGrid is also media aware. Unlike generic IT storage, MediaGrid can perform simple media processing functions such as re-wrapping and EDL-based hi-res conforming in the storage system itself when instructed to do so via applications that support the Omneon Media API. In addition, it offers extra CPU resources for media tasks, such as transcoding and QC. This makes content available when and where it’s needed, in the appropriate format and quality, dramatically reducing the need for a separate media processing infrastructure. For quick-turn workflows, such as News, MediaGrid offers “ActiveTransfers,” allowing content to be accessed while they are still being written.

This white paper includes technical details about how MediaGrid provides many of the world’s largest content producers and distributors a foundation for optimizing their file-based workflows.

1. Omneon MediaGrid File System Architecture and Components

The MediaGrid storage system utilizes a distributed file system designed to scale from a few terabytes to multiple petabytes in capacity and from one Gigabyte per second to tens of Gigabytes per second in bandwidth. It presents a single namespace to access a file system that spans many discrete hardware devices.

The MediaGrid file system contains two types of data, the actual file data and the metadata associated with the files (a description of files and their locations.) File data stored on MediaGrid is further divided into slices ranging from 256KB to 8MB. Slice size is configurable by file type at a folder level or even as granular as at the level of a single file.

Figure 1 shows the three primary components of the MediaGrid--the File System Driver, ContentDirectors, and ContentServers--and the optional ContentBridge.

Figure 1. Omneon MediaGrid Architecture Components

• File System Driver: The File System Driver (FSD) is a software agent running on one or more clients that performs the function of breaking up and reassembling files as slices are written to or read from the MediaGrid. The FSD requests the set of ContentServers it can read from or write to from the ContentDirectors, opens multiple parallel connections to that set of ContentServers and performs the transfer. This parallel access to data is unique and delivers close to the theoretical bandwidth limits of each client. The FSDs also intelligently cache data in the client memory to reduce latency. The amount of client memory used by the FSDs can be tuned. This combination of high bandwidth access with low latency not only helps large file transfers but also high-performance editing applications that are extremely sensitive to both bandwidth and latency. FSDs are available for all primary operating systems used by applications in broadcast and media facilities such as Windows, Linux, and Mac OS X. To the application and operating system on the client, the FSD makes the MediaGrid file system appear as a single large network drive. By installing FSDs on each client that needs access to data stored on the MediaGrid, clients have high-bandwidth and low-latency connectivity without using accelerators or gateways found in other storage systems. These clients can use single or multiple 1GbE or 10GbE interfaces to access the network.

• ContentServer: ContentServers are disk storage devices that store and serve the file slices to FSD clients. File slices are stored in multiple ContentServers, which comprise the bulk of a MediaGrid deployment. As mentioned before, the slices for a single file are distributed across different ContentServers by the FSDs. Such a distribution prevents an entire file from residing in a single ContentServer. While writing slices to its disks, a ContentServer simultaneously writes a copy of the slice, or replica, to another ContentServer. This replica acts as backup for the primary slice in case of a ContentServer or disk failure. There can be more than one replica created for added protection as explained in section 3. In addition to serving data, ContentServers can be used as processing nodes in a grid processing framework to perform media processing functions such as Transcoding and Quality Control (QC). This is explained in more detail in section 6.

• ContentDirector: ContentDirectors are devices that provide file metadata services such as directory lookups. In addition, they track the slices stored on various ContentServers and provide this mapping information to FSDs. At least two ContentDirectors maintain constant communication and synchronization to create a high availability cluster. Each ContentDirector takes turns providing services in a round robin manner. The metadata is stored in each ContentDirector locally and is kept synchronized across ContentDirectors using a journaling scheme. Periodic checkpoints of the metadata are also taken and stored on ContentServers to help roll back to a previous state, if necessary.

• ContentBridge (Optional): The ContentBridge is an optional appliance that functions similarly to a network attached storage head in a traditional NAS system and provides standard network file access interfaces to MediaGrid for access from clients where it may not be feasible to install FSDs. The supported protocols are Common Internet File System (CIFS), File Transfer Protocol (FTP), Network File System (NFS) and Apple File Protocol (AFP). The ContentBridge runs the MediaGrid FSD for its own connectivity to the MediaGrid. The standard ContentBridge appliance has two 1GbE ports on it for client connectivity. The High Bandwidth Content Bridge (HBCB) provides 10GbE connectivity for handling larger number of transfers. Multiple ContentBridges, or HBCBs, can be deployed to support larger number of connections or transfers allowing NAS access to scale without increasing storage capacity, assuming there is a sufficient number of ContentServers available to serve up the required bandwidth.

1.1 Omneon MediaGrid File I/O Life Cycle

Another approach to understand the architecture of Omneon MediaGrid is to follow the lifecycle of an I/O. Figure 2 shows a simplified enumeration of the steps involved in reading a file from MediaGrid.

Figure 2. Omneon MediaGrid File Read Steps

1. Client application makes a file open request. The FSD maps and forwards this open request to a ContentDirector.
2. The ContentDirector responds with a file handle.
3. The application read request along with the byte range is forwarded by the FSD to the ContentDirector.
4. The ContentDirector returns a map of sliceIDs belonging to the file and the list of host ContentServers the slices are stored on, to the FSD.
5. The FSD then reads the slices directly from the list of ContentServers and delivers it to the application.

Similarly, the steps required to write a file to Omneon MediaGrid are shown in Figure 3:

Figure 3. Omneon MediaGrid File Write Steps

1. Client application makes a file write request. The FSD then requests and gets a list of ContentServers and SliceID’s available for write from the ContentDirectors.
2. The FSDs write the slices to the respective ContentServers.
3. Upon receiving a write request, a ContentServer updates the slice locally and simultaneously writes a copy of the slice to another ContentServer from the list it received from the ContentDirectors.
4. Once the original and the replica are written to disks, the ContentServer sends a commit to the ContentDirector and an acknowledgement to the client FSD.

1.2 Omneon MediaGrid Network Configuration and Topology

Communication between clients and the MediaGrid (as well as inter-communication between MediaGrid components) uses an IP over Ethernet network fabric, as shown in Figure 4.

Figure 4. Omneon MediaGrid Network Topology

The main advantage of Ethernet over other technologies is its widespread acceptance and availability. This advantage results in lower hardware costs, wider familiarity by operations and support personnel, and faster innovation in the application layers.

Aggregated 1GbE or 10GbE links are used to achieve connectivity between MediaGrid and the existing network. No special host adapters are required on any client device, as all access to the system is via standard Ethernet connectivity. This allows the Omneon MediaGrid to provide the connectivity and performance required and to seamlessly integrate into existing environments.

Networking within the MediaGrid is comprised of three subnets/VLANs; two private and one public. The ContentDirectors connect to each other through two private VLANs for redundancy, while the public VLAN is used to connect to the clients and Omneon MediaGrid ContentServers. Each ContentDirector has four 1GbE interfaces. Two are used for the two private VLANs and the other two for the public VLAN. The ContentDirectors provide a resilient DHCP service for the management of the public VLAN, including the assignment of IP addresses to ContentServers and ContentBridges. The ContentServers have multiple 1GbE interfaces, depending on the type of ContentServer, while the ContentBridges have two 1GbE interfaces, or a single 10GbE interface in the case of the High Bandwidth ContentBridge (HBCB). These interfaces are configured as part of the public VLAN. Sufficient networking ports on qualified switches must be allocated for both internal MediaGrid and external client communications.

Client connectivity is provided by way of additional VLANs, often referred to as the Client VLANs. The connectivity to the MediaGrid is achieved via a Layer 3 VLAN hop between the Client VLAN and the Omneon MediaGrid public VLAN. This separation ensures that the MediaGrid only processes essential client and inter-component traffic, and that no external traffic inhibits overall performance.

2.0 Performance and Capacity Scaling

The distributed design of MediaGrid combined with FSD-enabled parallel access paths to the clients delivers the ability to scale both performance and capacity to tens of Gigabytes per second and Petabytes of storage capacity.

The unique benefits of the MediaGrid approach to scaling are:

• Pay-as-you-go expansion: This ability to start small and scale as your business needs grow in small increments (as small as one ContentServer at a time) enables just-in-time upgrades and avoids locking up capital in storage that may not be used immediately. • Investment protection: The ability to scale storage capacity and I/O bandwidth protects the initial investment from forced “forklift” upgrades to achieve desired higher levels of performance or capacity.

• Non-disruptive capacity expansion: Online expansion delivers a way to expand storage without interrupting clients reading from and writing to the file system. Simply add new ContentServers into the network to expand. New ContentServers are automatically recognized by the MediaGrid and can be on-line in less than a minute.

• Increased performance for existing and new data: Existing data on an expanded MediaGrid is automatically rebalanced across newly added ContentServers thus providing higher read bandwidth access even for existing data. Any new data written to Omneon MediaGrid after the expansion is written and distributed across all ContentServers, old and new.

• Leveraging latest generation ContentServers and hard drives: Every year, advances are made in server hardware and hard drive technology. Customers can utilize the latest server hardware and hard drives available from Omneon for capacity expansion, thus allowing users to invest in the latest technology and not be locked into using legacy offerings.

• Shared bandwidth across applications: By having a single volume and name space, all applications and users share in the additional capacity and bandwidth, eliminating allocation of additional storage to a specific application or user. • Grid processing performance scales along with Omneon MediaGrid: As new ContentServers are added, the resources become available for grid processing applications (explained in section 6), scaling not just storage capacity and performance, but also grid processing performance.

3.0 Data Protection and Recovery

3.1 Protection using Dynamic Replication


Omneon MediaGrid protects data and its availability from any hardware failures by automatically writing one or more copies, or replicas, of slices onto different set of ContentServers. This data protection scheme, called Dynamic Replication, allows users to control the level of protection on a file-by-file, folder-by-folder or whole-system basis. The number of replicas is controlled by a parameter called Replication Factor (RF). The default RF is 2. This is the lowest value that can be used. Any data with RF equal to 2 is protected from a single drive failure, multiple drive failures within a ContentServer or failure of any one Content Server. See the table below for the degree of protection offered by three different RF values.

3.2 Group-Based Protection for Disaster Recovery

MediaGrid also provides a construct called Groups. A Group is a collection of three or more ContentServers where replicated slices are always stored in another group. This replicates and protects data across physically separated ContentServers housed either in different racks (with isolated power circuits), different rooms or even different data centers in a building or campus. So if one group fails as a result of power failure, MediaGrid continues to operate without any impact because a replica of the data is available in another group. This provides an elegant disaster recovery solution under a single name space, which does not require any client-side configuration changes or disruptions in the event of a failure. To support this functionality, the number of groups in MediaGrid must be a multiple of the Replication Factor and it is recommended that all groups have equal ContentServer capacity.

3.3 Automatic Recovery to a Protected State

Omneon MediaGrid also automatically manages the process of maintaining data protection. The loss of any individual disk, ContentServer, or even a whole group results in a notification of the loss and an automatic initiation a re-replication process in order to return the data protection level to the pre-failure state. The loss of an individual disk drive results in re-replication of only the slices that were on that drive. This operation is automatic and dynamic, and is generally invisible to the user. The re-replication begins immediately after the detection of the loss requires no administrator intervention or installation of a replacement drive. On replacement of the drive (if ever), the system automatically recognizes the new drive as available storage. The re-replicated data is already elsewhere in the system. The loss of a complete ContentServer results in a similar operation. Re-replication starts for all lost slices without intervention or replacement.

3.4 Recovery from ContentDirector Failures

ContentDirectors are in an active cluster arrangement with regular communication between them. When a ContentDirector is lost, the impact is minimal as the redundant active ContentDirectors continue to provide metadata services. Any replacement ContentDirector connects to the cluster, identifies itself and requests a file system update. This update populates the new ContentDirector with the current state of the MediaGrid cluster and file system metadata. Content Directors also include two disk drives in a mirrored configuration so the loss of a single drive does not take down a ContentDirector. As an added safeguard, checkpoints of the metadata in ContentDirectors are taken at regular intervals and written to the ContentServers.

4.0 Authentication and Access Control

Both ContentServers and ContentDirectors act primarily as servers, processing requests from clients and returning results although they do communicate with each other. In view of this, MediaGrid supports comprehensive authentication and access control capabilities to ensure that only authorized clients can submit requests, and that they can only submit approved requests.

Omneon MediaGrid supports both Active Directory (AD) and Domain Controller (DC) for authentication for Windows clients. For Linux clients, Lightweight Directory Access Protocol (LDAP) is supported. For Macintosh clients, Active Directory, LDAP and Apple Open Directory are all supported.

The Omneon ContentManager (a windows based application) allows administrators to set user-level and group-level security for the various MediaGrid files and directories by using Access Control Lists (ACLs). File access by users is checked against these ACLs for each file. The Omneon MediaGrid system receives User and Group IDs when it joins a directory server such as domain controller or active directory system and stored in the ContentDirectors. ContentManager receives the ACLs when it mounts an Omneon MediaGrid file system, and contacts the domain controller or directory server to resolve user names.

5.0 Media Awareness

Traditional IT-focused storage systems treat media data no differently than any other type of data. This oblivious approach to a highly specialized file type limits their ability to support media applications successfully. Omneon MediaGrid is media aware—it knows that the data being stored is media. MediaGrid makes use of the Omneon Media API, which gives it knowledge of related files—video and audio tracks for example—the ability to construct coherent media files while recording is still in progress.

Omneon MediaGrid also has the ability to tune read and write performance based on the media file type. For example, the system can automatically segment relatively small AIFF audio files into 256KB slices while Apple ProRes 422 video files would be segmented into 4 MB slices. These files might be associated with the same piece of content.

6.0 Grid Processing Framework and Application Hosting

In addition to being a storage solution, MediaGrid also acts as a distributed computing platform for media processing applications that can run directly within the system. MediaGrid enables this functionality with the Grid Processing Framework, a software interface that makes use of the spare processing power within ContentServers. Two applications that currently leverage this processing framework are:

• Omneon ProXchange Transcoding Application
• Interra Baton Automated Content Verification (QC) Application

By leveraging the grid processing capability of the MediaGrid, these two applications provide significantly better transcoding and QC throughput compared to traditional single-server-based solutions. Taking advantage of spare CPU horsepower within the MediaGrid storage system can not only make file intensive operations run quicker, it can also be used to drastically reduce the amount of data moving over a network. Running applications directly on the MediaGrid storage system makes moving content between digital islands unnecessary, while also speeding-up media workflows.

7.0 Omneon MediaGrid Compared to Alternative File Storage Architectures

There are a number of different approaches to centralized file storage. They fall into two main categories: Clustered NAS and SAN file systems.

7.1 Clustered NAS Systems

A clustered NAS (Network Attached Storage) system uses a distributed file system running simultaneously on multiple servers connected via an Ethernet network. The key difference between a clustered and traditional NAS is the ability to distribute, or stripe, data and metadata across the cluster nodes or storage devices. Clustered NAS, like a traditional NAS, still provides unified access to the files from any of the cluster nodes by providing a global name space.

The key difference between Omneon MediaGrid and clustered NAS solutions is in the area of throughput and latency. As discussed earlier, in the Omneon MediaGrid case, metadata requests to ContentDirectors are handled out-of-band via file data access. Once a ContentDirector forwards a list of ContentServers storing file slices for the pertinent file, the client requests the file slices via the FSD driver directly and in parallel to optimize latency and throughput.

In comparison, in clustered NAS systems, metadata requests are handled in-band. Each node in the cluster is responsible for providing both metadata and data services to clients and each client request to the storage system involves resolving metadata requests which in turn increases overall latency. In addition, each cluster node is responsible for satisfying file data access requests, which include communicating with other nodes in the cluster to aggregate data prior to responding to a client. This indirect data hop negatively impacts overall bandwidth and latency for file access.

7.2 SAN File Systems

A shared disk SAN file system uses a fibre channel storage area network (FC SAN) to provide direct disk access from multiple computers at the block level. Clients must use fibre channel Host Bus Adapters (HBA) to translate from application-generated file-level requests into block-level operations used by the SAN.

What differentiates MediaGrid from SAN file systems is the total cost of ownership. The use of an all-Ethernet infrastructure by Omneon MediaGrid lowers overall cost due to the broad ecosystem of Ethernet equipment suppliers. In addition, Omneon MediaGrid can leverage a breadth of client network interface options ranging from built-in Ethernet ports on the client system to optional 10Gb add-in interface cards.

In comparison, SAN file systems require expensive fibre channel SAN infrastructure including switches and HBAs. These additional HW components increase the points of failure and negatively impact the overall reliability. In addition, FC SAN tools and administrators with FC SAN management skills are relatively expensive, which results in a higher operational expense for FC SAN infrastructure.

Beyond equipment cost, Ethernet infrastructure is easier and more efficient to manage from a cost standpoint due to the range of tools available as well as the vast number of network administrators who have an Ethernet skill set.

8.0 Conclusion

The Omneon MediaGrid system is a clustered storage solution designed specifically for file-based digital media workflows. Its industry leading performance and scalability combined with built-in media intelligence allows it to play a central role as the active hub in media production workflows.