Server virtualization brings flexibility to the server and application layer of the data center. That same flexibility should also be available at the storage level, and this starts with protocol flexibility. While NAS via NFS may be the initial choice or the choice for most VMs, the situation can change. Flexibility is key. Look for a NAS solution that can also support the other popular protocols like Fibre Channel and iSCSI, just in case there is a need for them. Data centers that are larger than a few physical hosts should avoid being locked into a single protocol.

It may also make sense to consider a solution that leverages the virtual infrastructure itself. Products that provide storage as an application often have the ability to run as a VM within the infrastructure. This is ideal for new virtualization installations since the shared storage is needed for advanced VM functionality like live migration and dynamic resource management. As the environment grows this VM can be moved to a stand-alone appliance for greater performance and predictability.

When the storage intelligence is provided as software that gives the manager the flexibility to use storage hardware from a variety of suppliers, as well as a variety of types. For example, if there is a need for very high performance, then a specialized SSD supplier can be selected, allowing their expertise in that space to be leveraged. Alternatively, if low cost and a more archive-like capacity is needed, a vendor that's more focused on high value systems can be chosen. The key is to make sure that you can tap into the commodity hardware market, where prices for capacity, CPU and memory are often 90% less expensive than the same physical hardware sold by legacy storage providers.

The support for SSDs as a native part of your storage solution is particularly important. Virtualization takes synchronous I/Os and turns them into random I/Os. What that means in practice is an application performing well on bare metal deployments can start performing 1/10th as fast once it runs on a virtual machine. The reason is that storage systems, in general, are extremely bad at random I/O; they prefer synchronous I/O because this means that the heads on the disk drives do not have to move as frequently. SSDs change the equation fundamentally because there are no disk drive heads to move. Look for a solution that automatically takes the ‘hot’ data and puts it onto SSDs as read and write cache as otherwise it will be up to you, the storage administrator, to somehow create a tier of SSDs for particular data.


Using NAS for VMware moves its function well beyond the realm of simple file sharing. The NAS must be able to provide a high degree of availability and data reliability. In most cases hundreds of applications can be impacted if the virtualized servers cannot access storage. Downtime is simply not an option. NAS heads should be clustered in some way so that if the system providing the service fails then another NAS head or multiple NAS heads can take over the load.

The system should be able to address data loss culprits like silent data corruption which recent studies reported, as FAST and Usenix suggest, are increasing in frequency as disks become ever larger (see http://blogs.zdnet.com/storage/?p=822&tag=col2;topRated). And, when those disks fail, and they do fail, the system should be able to resilver quickly; you may also want to invest in a system that goes beyond standard single and double parity RAID, so called RAID 5 and RAID 6, and that is at least able to support triple parity RAID (see http://blogs.zdnet.com/storage/?p=822&tag=col2;topRated) Again, as drives increase in size but not in quality the rebuild time of a drive is increasing as well; studies suggest that the odds of having two drive failures, thereby breaking a double parity pool, is increasing as well leading storage administrators planning for future requirements to seriously consider systems with triple parity support available, or at least on the road map.

Part of the availability equation is leveraging the NAS' snapshot capabilities and how well the NAS vendor has integrated them into the virtualization layer. Nexenta's NexentaStor product, as an example, has integrated into the VMware, Xen and Hyper-V APIs and can have VM-level understanding of each snapshot. This ensures that the VM is in a quiesced state prior to the snapshot taking place and also allows for the use of NexentaStor to very efficiently template and clone VMs without impacting the virtualized host.

When it comes to snapshot support also consider the number of snapshots that the system supports. For example, many NAS products support 255 snapshots per volume. While this may sound like more than enough, and it is for one server, in a virtual environment it may fall short. For example, assume that there are three physical hosts each with 25 VMs on them. If you triggered just four snapshots per VM you would have hit the wall in the number of snapshots that the storage array can support. Look for products that offer near-unlimited snapshot capabilities.

Also, in availability, look for NAS appliances that can integrate with the virtualization software to trigger live migrations of the virtual machines. While it may seem unusual for a storage system to initiate a VM migration the use case is very realistic. An example would be if the NAS system determines the disk array that the virtual machine is on is failing. The NAS system can migrate the VM's server image to another volume, live, and then once complete, can migrate the virtual machine.

Finally, availability needs to include protection from a disaster that results in building loss. The NAS should be able to not only cover replication as part of its built-in core, it should also be able to manage VM migration across the WAN. Ideally, all these functions should be controlled through the VMware control center.

Cost often stops availability in its tracks. Customers cannot afford a second cluster locally and then a replicated version in the DR site. Many manufacturers require near-identical systems to be able to do this. Look for a NAS solution that will allow the use of different classes of both NAS heads and storage types to meet these requirements. While it may not be ideal to have a very low-cost system, using a lower performing system at a DR site is absolutely better than nothing. 

Space Optimization

Utilizing a NAS as the VMware data store should also bring with it the ability to efficiently store those images. NAS systems are unique in the number of approaches that are available to the VMware storage administrator for making sure data growth stays in check. The first of which, thin provisioning, allows a VM to be allocated its largest potential capacity but only consume the actual capacity when it's needed. Most NAS systems offer some form of thin provisioning. It's important to confirm that there is no significant performance impact as a result of using thin provisioning.

The second form of space optimization can come from the use of clones. Clones are essentially read-write snapshots. Basically a master VM image can be created for each Operating System (OS) and then snapshotted and fine-tuned as each additional VM is created. This can bring a tremendous space savings as each VM now only contains the net data that it needs to perform its specific task. Using thin provisioning without clones, each of the VMs would actually consume space because each VM would need its own copy of the OS and related core files. With clones they can leverage the data load of the master VM.

In addition to these two techniques a few NAS systems have the ability to compress and deduplicate data. Deduplication, the removal of redundant blocks of data on primary storage, often does not yield the same results this technology does on backups. There is simply not enough redundant data. One exception is OS images, like those that VMware would create. Adding deduplication to the process removes any redundancy that clones would not. You may want to consider true in-line deduplication that works as storage is written to disk automatically; this saves a time consuming post process step. Compression then optimizes the storage even further by space-reducing even non-redundant data, further optimizing data sets. The net result often shows a 90% reduction in capacity requirements, especially in virtualized environments.


In addition to flexibility, availability and space optimization, you may well want to consider whether your storage gives you the ability to “see” what you are doing. The role of a storage administrator has changed significantly thanks to virtualization. Physical servers that once had a single application on them now have several applications on them, each running within a virtual machine. What this means to a storage administrator is that they are generally blind to the application and lack the granularity of control necessary to establish storage policies on a per application basis. The result is inefficiency and frustration. Look for a solution that gives storage administrators visibility into their environment and enables point and click provisioning of storage policies. As the virtualized environment evolves it is important that storage administrators have visibility into VMware, Xen, and Hyper-V environments from a single interface. Look for a tool that provides the ability to provision storage policies, to migrate VMs and their storage, and to clone VMs as needed all from a single interface.

While there are other capabilities to consider, the decisions around flexibility, availability, space optimization and visibility are a good first start. In our next article we will cover more of what to look for in VMware based NAS: affordable performance, leveraging the cloud and addressing scalability.

George Crump, Senior Analyst

This Article Sponsored by Nexenta

- What to Look for