During last week’s HP Discover 2011 event, Nigel Poulton (@nigelpoulton) raised a very interesting point regarding the way VMware potentially intend to control the storage space through VMFS and the apparent contradiction in terms of also pushing off tasks to the storage array through VAAI. I thought it worth expanding on these discussions in more detail as the difference and separation may not always be that clear.
Firstly, let’s look at the VMware storage options. You can choose to use block storage, in which case your LUN is formatted with the VMware proprietary VMFS file system. Alternatively you can use NFS, in which case the NFS server manages the file system natively. The VMFS option has a number of benefits; it allows VMware to tightly control the interaction of individual virtual machines and hypervisors, managing locking, thin provisioning and so on. However there are also disadvantages. Most storage arrays see LUNs as the smallest unit of presentable storage and perform operations (such as replication and cloning) at that level. On non-virtualised environments multiple LUNs are usually presented to a host, so there’s no problem with those functions. However with VMware the best practice is to use a smaller number of larger LUNs that encompass more than one virtual machine. In effect this is a complete reverse of the physical host LUN model and can lead to issues when replicating or cloning on the array.
NFS provides a different approach. NFS shares are presented to the hypervisor and virtual guests accessed simply as files. NFS provides the locking mechanism and any additional functions, such as snapshots and replication. As an extra bonus, the file system can still be accessed by traditional methods, making it possible to copy, edit and backup virtual machines away from the control of the hypervisor. The trade-off between NFS and VMFS is seen as one of flexibility over performance but this is probably unfair and somewhat simplistic.
Where does VAAI come into this? VAAI pushes some of the “heavy lifting” work required to clone virtual machines down to the array. It also enables sub-LUN locking, improving performance. In the discussion with Nigel he questioned why VMware were wanting to retain control via VMFS yet pushing functionality towards the array with VAAI. I see this as a separation of control over execution. VMware undoubtedly want to retain control of key storage functions within VMFS and the hypervisor. If they do, they can charge for them. It also makes sense for the hypervisor to be in control of tasks that directly affect the status of a running guest. If VMware manages the replication process then data integrity can more easily be maintained. However, copying data to and from the array through the hypervisor takes CPU cycles and network bandwidth. It also doesn’t allow the array to execute in the most efficient manner. By comparison, allowing the array to perform copy functions independently, data is not traversing the storage network, additional host cycles are not being used and the array can both schedule and execute the copy function much more efficiently as it is aware of the entire requirement, rather than seeing things in a sequential fashion.
Therefore we can see a dual benefit to VAAI; firstly the work is offloaded from the hypervisor, but second it is executed more efficiently. In comparison to NFS, it seems that by implementing VAAI features, VMware are looking to retain even more control over the storage layer than before.
