VMware

September 03, 2008

VMFS vs. NFS for VMware Infrastructure?

     The dynamic, flexible environment that we call VMware Infrastructure requires shared, coordinated storage between ESX servers. There are two families of storage technologies that can meet this requirement today, SAN-based block storage (e.g. Fibrechannel or iSCSI) and NAS. VMware supports both forms of storage access for our customers.

    VMFS is VMware’s technology for managing block storage. It is a clustered file system used by multiple ESX Servers to coordinate and share access to the underlying block storage. It was explicitly designed to enhance the performance and reduce the complexity of block storage as it relates to virtual infrastructure. VMFS is responsible for two broad functions in the ESX storage subsystem.

  1. Structured data layout – VMFS defines the structure and layout of data on the block devices. VMFS is optimized for virtual disk storage, but as is common to most file systems, VMFS brings a file and directory structure to the on-disk data. Most importantly, VMFS handles the layout of individual vmdk files (these are the virtual disks that are eventually presented to the VMs). VMFS also has some basic layout or volume management functions – presenting and managing combinations of multiple block storage devices (LUNs) as a single VMFS volume.
  2. Clustering - The second and vitally important feature of VMFS is support for sharing or clustering. VMFS is responsible for the coordination of multiple independent ESX servers safely reading and writing to the same block device. It is VMFS which handles the basic safe transfer of ownership of data from server to server during high level VI activities such as vmotion, DRS, storage vmotion, HA, etc.

    NFS is a NAS (Network Attached Storage) or file based protocol and is used to establish a client-server relationship between the ESX hosts and the NAS device. As opposed to block storage, a NAS system itself is responsible for managing the  layout and structure of the files and directories on the physical storage.  It also handles some of the aspects of shared access and provides primitives that can be used for coordinated access from multiple servers. ESX uses these primitives to provide similar shared access for VMware Infrastructure as is provided by VMFS in the block storage case.

    So which to use? The first criteria is to continue to use the type of storage infrastructure you are familiar with. If your organization uses block based storage – use VMFS.  If NAS is in use, it may make more sense to deploy VMware Infrastructure with NFS. Other aspects of storage management, such as the basic virtualization of storage on behalf of the VM or the internal structure of the virtual disk files (VMDK) are handled independently of this choice.  You get the same high level VI functionality regardless.

    For new deployments, there are the traditional storage tradeoffs. SAN or block based storage is a well understood infrastructure choice, has a great deal of existing physical management tools and may offer optimal performance. NAS-based storage has a reputation for less complexity and is in many ways easier to manage and setup than block based storage. And for some VM workloads, the performance of NAS is comparable to SAN.  Individual NAS and SAN products may offer advanced data management features that become even more valuable with Virtual Infrastructure such as data de-duplication and thin provisioning.

   

As with many of VMware's virtualization features, we place a great deal of emphasis on the encapsulated VM abstraction. Consistent with this philosophy, the virtual disks that are presented to virtual machines are an idealized and highly portable view of storage which is independent of the backing storage implementation. ESX handles both storage technologies in a fashion that continues to maintain this portability of the VM. With ESX and VMware Infrastructure, one can move VMs between storage technologies quite easily and now with Storage Vmotion, that portability even applies to live running workloads, offering customers the freedom to readily switch between NAS or block storage as they see fit.

________________________________________


July 21, 2008

VMware's "Proprietary" Clustered File System

There has been some discussion lately from some of our competitors on their storage architectures or lack there of. Their boast is that VMware has a “proprietary clustered file system” that forces you to change your storage management practices while they preserve your physical storage management. They’re right, they do completely preserve the complexity of physical storage management. What they fail to mention is that this is a problem, not a solution. Physical SAN management is overly complex and a headache for most customers. And in the virtual world, the status quo is compounded! Instead of managing dedicated LUNs for every physical server, if you buy their argument you’ll be managing separate dedicated LUNs for every virtual machine! 

VMware doesn’t have a vested interested in preserving physical complexity. That’s why VMware invented VMFS and our hypervisor-based storage stack. Virtualization is all about abstracting the physical world to ease management burdens and reduce complexity. VMFS is very special purpose clustered file system that is largely transparent to our customers. It is used by VMware’s ESX Hypervisor to abstract and share LUNs used to store Virtual Machines and their Virtual Disks. 

The result? Great customer benefits, such as:

  1. VMware’s instant one click provisioning, including storage. Quick, easy provisioning of a new VM, OS and application that does not require physical storage LUN provisioning.
  2. Mobility/Portability. i.e Vmotion and storage Vmotion. In a virtual world, workloads should be abstracted from, not beholden to, physical storage. Just like they should be abstracted from physical servers.
  3. Encapsulation and HW Independence. VMs should be entirely encapsulated from the physical world. This simple, but critically important facet of virtualization unleashes the power of virtual infrastructure. For an example, look at VMware’s new Site Recovery Manager that enables DR solutions that no longer require identical hardware (and software) configurations at each site.
  4. Reduced complexity. SAN management is hard, complicated work. Why shouldn’t it be simplified?

Now is VMFS good for absolutely every use case? No, sometimes it’s important to preserve a physical LUN format for a given workload. That’s why VMware supports RDMs (Raw Disk Maps) which allows a customer to directly map an entire LUN into the guest OS while still maintaining virtual infrastructure benefits. The trade off with RDMs is more LUNs to provision and manage, but direct access from the VM to a native physical LUN.

What our competitors fail to mention is that not only does VMware support all the use cases they claim to provide, but we also bring all the benefits of virtualization to the entire data center, storage included. And that’s something worth touting!


Welcome

Welcome to the VMware Storage Blog, a blog dedicated to all aspects of storage in the virtual environment.
We get a lot of questions about Storage Architecture in VMware Virtual Infrastructure. It is a complex topic with many options and design trade-offs to consider. In this blog we will attempt to demystify the topic. Please let us know how we are doing! Thanks.