There are pros and cons to running multiple protocols through a single array controller.
Multiprotocol arrays that support block- and file-based storage through a single controller give users the best of both worlds: NAS for file-based information, and Fibre Channel (FC) or iSCSI-attached block-based storage for databases and other transactional applications. "NetApp, EMC and Pillar Data Systems are seeing an increasing number of their arrays used in multiprotocol deployments," reports Roger Cox, research VP at Gartner.
Prior to SANs, storage resources were dedicated to a single server. It was only in the mid-1990s that FC SANs enabled the separation of server and storage, making a single storage pool accessible to more than one server. While a huge leap forward, FC SANs were - and mostly still are - complex and expensive, and they left a huge gap for a simpler and less-expensive technology.
NAS filled this void by offering storage services, and incorporating and controlling the file system within the storage system, presenting files and directories to hosts in the NFS and CIFS file-system protocols. A large percentage of installed storage stores files.
File-system protocols like CIFS and NFS treat files as a single entity. For example, when a user opens a file, it's opened in its entirety and then locked to prevent others from modifying it. This is ill-suited for apps where data is accessed at a sub-file level, such as databases where small pieces of information are continuously read and updated within a larger file. Without question, block-based storage protocols like SCSI, iSCSI and FC are superior to the file-based access methods of NAS when it comes to non-file-based data access.
You need to remember that information is stored in blocks - not as files - on the disk subsystem. Data is written in blocks to the disk volume, and block size is determined when the volume is formatted, typically ranging from 512 bytes to 2,048 bytes in size. A file, on the other hand, is a concatenation of data blocks managed by the file system. While the disk subsystem manages data in terms of blocks, the OS and humans manage information in terms of files and directories.
Block-based storage access protocols (SCSI, iSCSI, FC) are indispensable because they're native to storage systems and can deal with all types of data efficiently. NAS lets you do away with standard file servers by incorporating file-system protocols into the storage system, providing simpler management, a higher degree of scalability, and added storage services like snapshots and replication. Here's how multiprotocol arrays differ from single-protocol arrays in terms of performance, price, ease of management and other features.
Multiprotocol Arrays: Key considerations
Features. In many cases, array features are more important than performance. Application integration, snapshot, replication, backup options, thin provisioning and deduplication are at the top of most users' feature requirement lists.
Flexibility. Storage can be used or repurposed for all types of applications. The risk of a vendor product lock-in is lower than for block-based protocol arrays or NAS-only arrays.
Performance. Arrays with block and file-system protocol support are typically not the arrays of choice for very high-performance applications such as high-end databases and transactional applications.
Price. Arrays with NAS and SAN protocol support are significantly less expensive than two separate arrays; but depending on the vendor, additional protocols may not come free.
Storage management. Multiprotocol array management tools that ship with the array are simpler to use than third-party storage resource management apps, which vary widely regarding what arrays they support.
Performance
There are some performance issues with multiprotocol arrays when file-and block-based protocols compete for valuable disk I/Os. Large file access, copying a large number of files or NAS backup jobs may drag down SAN performance, especially in midsised and lower end multiprotocol arrays that are more likely to hit their performance limits.
The issue is aggravated in highly integrated arrays like those from NetApp where NAS and SAN share a single data path. In NetApp filers, file-and block-based protocols are passed through the NetApp Write Anywhere File Layout (WAFL) file-system layer, resulting in a higher degree of dependency between NAS and SAN. WAFL was initially conceived for NAS and, despite a commendable degree of optimisation, the WAFL translation overhead results in more CPU cycles for processing block-based protocols than a comparable single-protocol FC array.
Conversely, the gateway/dual-path approach in EMC Celerra or Pillar Axiom arrays don't have a WAFL-equivalent layer through which all data, regardless of protocol, must pass on the way to the disk subsystem. But the risk of NAS impacting SAN performance still exists for all multiprotocol arrays, as both NAS and SAN will eventually access the back-end storage.
To alleviate performance interdependencies, multiprotocol array vendors added quality of service to their arrays that enables users to set priorities and define the number of requests permitted for NAS and SAN. "A user can define a logical volume in our Axiom arrays that allocates 85% of resources to databases and 15% to file access," says a Pillar Data Systems spokesperson.
Practically, arrays that support both block- and file-based protocols aren't the arrays of choice for the performance required by high-end databases and transactional applications.
"If I am looking for the fastest block-based storage system, multiprotocol arrays like the ones from NetApp don't come to mind," says Greg Schulz, founder and senior analyst at StorageIO Group, a consulting firm in Stillwater, MN. "However, if I'm looking for the most feature-rich NFS/CIFS/block-based storage system, NetApp is at the top of the list."