Is it unified or un-unified storage?

Vendors are hyping converged block with file access arrays, calling them "unified storage." How unified (or un-unified) are they?

John Webster Special to CNET News
John, a senior partner at Evaluator Group, has 30 years of experience in enterprise IT storage, spanning mainframe and open systems environments. He has served as principal IT adviser at Illuminata and has held analyst positions at IDC and Yankee Group Research. He also co-authored the book "Inescapable Data Harnessing the Power of Convergence."
John Webster
3 min read

For years, storage vendors have been offering two types of disk storage: block and file. Block-based storage is commonly associated with SANs (storage area networks) while-file based storage is commonly referred to a NAS (network attached storage) and attached to Ethernet networks.

Lately, the vendors of either flavor have developed an interest in selling storage arrays that swing both ways--a storage system that provides both block and file access simultaneously. The moniker for these converged SAN/NAS systems is "unified storage."

With unified storage arrays, block access is accomplished through use of an interface to the array such as Fibre Channel, SAS, or iSCSI over Ethernet, while file-based access is to an array-resident file system using either CIFS or NFS over Ethernet.

So when a vendor says it's unified, the potential buyer should be asking whether or not it's really unified.

Here's way to approach the question: Storage vendors have come to market with very different implementations of "unified" storage and you have to look under the covers to make your own determination. For example, some say their storage array is "unified," but then only allow a customer to configure the array as one or the other at setup time. Call these "unified" if you want, but I'm not going to.

Some have placed a server or some other hardware element that differentiates between file and block out in front of one of their standard, off-the-shelf arrays. Some use separate element managers running in the array controller that require separate management interfaces. To me, these are borderline cases.

Here's why this is an important consideration.

The ability to configure a unified storage system for use as either block or file access gives the you flexibility to choose between one or the other, both at purchase time and after the array is installed. Deciding which storage to purchase becomes independent of block or file access. Later, if there is a change in the business or application environment such that a different type of storage is needed, you have the resources to meet the demand. Unified storage is like an insurance policy that protects you from a costly and time consuming reconfiguration of the storage environment when unexpected changes that may occur.

However, as usual, there are some caveats. You need to understand a unified array's underlying architecture to know whether or not one type of storage will potentially impact the other. For example, features such as data caching may operate differently between the two access types and cause one type of access to impact the other. Block access is more fine-grained than sequential file access and has a high locality of reference. This means that caching of file-based data not needed in cache may push least recently used (LRU) block data, thereby negatively impacting performance for applications accessing block data. In general, it is important to understand the design of the unified storage system to isolate any potential cross-usage impacts.

More importantly though, you need to keep in mind your reason for buying unified storage in the first place. As mentioned, unified storage gives you flexibility both at purchase time and after. A truly unified storage system provides a single user interface to manage both block and file system storage when the array is installed and later on in production. Storage that allows you to easily select between block and file access anytime within the life of the array provides a common pool of capacity that can be maximized for efficiency and reduced cost when the unexpected happens.