Wednesday, August 11, 2010

Consider NAS For Most Of The VMs

VMware Virtual Machines (VM) are all stored as files called VMDKs. The files are large repositories that make up the all the components of that VM. To enable the more advanced features of VMware, like VMotion and Distributed Resource Manager, requires that the files be shared between multiple servers. VMware first created its own ‘shareable’ file system, VMFS, to accomplish this task and later added NFS support. By using NFS the burden of managing a shared file system is removed from the VMware Hypervisor. Also, NFS is more accessible than VMFS, it can be logged into and browsed just like any other NAS file system. That means that the data protection capabilities that are standard in many NAS systems, like snapshots and replication, are readily available to the VMware environment.

Using a NAS appliance to host VMware images greatly reduces the complexity of a ‘shared everything’ environment. First, NAS runs on the standard IP Ethernet network. It requires no special cards or even software drivers and most OSs, and now VMware, support NFS natively. While most environments will evolve into a physically separate or virtual LAN for their storage traffic, doing so still retains the cost savings that standard Ethernet provides, like cheaper network interface cards and less expensive switch ports. Second, NAS via NFS was designed from the ground up to have multiple systems gaining access to the same files on a controlled basis. Standard block-based SAN technology was not.

The Simplicity Of One

When it comes to IT systems, the fewer points of management that have to be administered the better and that point of management in storage is the controller or NAS head. This is especially true when it comes to VMware storage. While some NAS systems allow you to view and monitor multiple heads and others use a global file system to seamlessly move files around, these are of little value when it comes to the management of VMware storage. Most of these management tasks need to be done on a per-NAS or per-storage-controller basis. For example, if a new VM needs to be provisioned each storage controller or NAS head has to be inspected to see which one has enough capacity and isn’t overburdened with I/O contention. If there’s only one file system and it has appropriate capabilities to handle the ever increasing demands of VMware infrastructure growth then it’s going to be significantly easier to decide how to provision storage and I/O resources.

This is counter to the legacy NAS expansion model where separate independent NAS heads are added when performance or capacity limits of the current NAS are reached. While this might have been acceptable in the standard file sharing use case it becomes problematic in the virtual environment, where every physical host needs to be mapped to any storage that houses a virtual machine. If it takes ten to fifteen NAS heads to host the VM environment then it’s fifteen mappings that need to be made on each physical host, as well as fifteen different storage areas that need to be managed.

The ideal solution is to reduce the number of storage management points to one without creating a performance bottleneck. There are two ways to accomplish this: implement one large system that will never need to be replaced or implement a smaller system that can be expanded as the environment scales, often called ‘scale-out’ storage.

The scale-out model is interesting because every time capacity is added to the system storage processing power and storage I/O are added as well. Since most VMs have a common initial capacity requirement, it stands to reason that capacity and I/O will scale somewhat linearly. If not, then the scale-out storage system will need to have the ability to add I/O-only nodes to meet those demands. This linear scaling of capacity, storage processing power and I/O reduces the complexity caused by the ‘I/O blender’ as mentioned in our prior article “The Complexity of VMware Storage Management”.

Scale-out storage systems, like Isilon, typically have the ability to stripe the file system across all the nodes in that storage system. This allows for a single, large file system that becomes a single point of management for the entire storage component of the virtualized infrastructure.

Traditional NAS had limitations on how many VMs could be supported per storage controller, which lead to the growth in the number of NAS heads found in a NAS-hosted VMware environment. More modern NAS architectures address these limitations and can scale the number and type of supported VMs further than before. That said NAS may not be appropriate for every virtual machine. There are a few VMs that may have special block requirements. In this case iSCSI can be leveraged, either within the NAS or as a second unit for those few cases. This keeps the transport medium, Ethernet, the same, while at the same time keeping costs down.

VMware storage can be simplified. While shifting to a NAS can ease much of that burden, the ability to contain storage growth into a single, manageable unit may be even more important, since managing dozens of NAS heads can be the most difficult task of all.

George Crump, Senior Analyst