Today Marc Staimer of Dragon Slayer Consulting posted the article “Pros and cons of using NAS NFS with VMware.” on SearchStorage.com.
I’d like to compliment Marc on his post; I thought it was well balanced and clearly communicated. As I read the article I felt compelled to expand upon his suggestion that NAS may possibly be the optimal form of interconnect with VMware.
Let’s begin with the Three Types of Storage with VMware
I wonder how many of you thought I was going to say VMFS, NFS, and RDM? While those are three storage options with VMware I’d like to suggest a different classification of storage: Legacy Interconnect, Shared Storage Pools, and Isolated Datasets.
Virtual Data Centers are comprised of physical, ESX, servers and virtual servers. Each type requires a different form of storage, so let’s consider how each of the types I’ve classified above best function.
Legacy Interconnect
Physical ESX servers require access to traditional or legacy storage devices in order to boot and operate. This storage could be direct attached storage, or alternatively it could be a FC or an iSCSI LUN.
So which one, FC (or FCoE), iSCSI, or NAS?
FC and iSCSI are the viable technologies as physical servers require access to a traditional storage device, or LUN, in order to boot and operate.
Shared Storage Pools
As you know, Virtual Machines are comprised of files and in order to leverage the dynamic management features in VMware like HA, VMotion, etc these files must reside on a shared storage architecture.
VMware did it right with this design; they made connecting to a FC or iSCSI VMFS datastore or an NFS datastore easy. One storage admins have provisioned storage the VMware admins have the ability to provision virtual disks to virtual machines at their discretion. As long as there’s capacity available within the pool this can be accomplished without requiring assistance from the storage admin or storage networking team.
VMware admins consider Virtual Disks (VMDKs) storage. This may not be what be the same view as the traditional storage admin, but it is the reality of today.
I would like to highlight that the number of VMs that one can store in the shared storage pool has a direct impact on many operational functions including (but not necessarily limited to):
Physical storage provisioning and zoning
VMware storage connectivity and multipathing
Backup performance and architectures
Replication schedules
Because of the impact in these areas VMware recommends 10 to 15 VMs per VMFS datastore.
With NetApp’s enterprise class NFS we recommend up to 250 VMs per NFS datastore.
So which one, FC (or FCoE), iSCSI, or NAS?
The answer is based on the size and architecture of your environment. With that said, I would suggest that if you have to deploy 500 or more VMs you might save a large amount of operational management by deploying your shared storage pools over NFS.
Isolated Datasets
As customers virtualize more and more servers they eventually have to design configurations in order to address the resource requirements of more demanding applications. Examples of demanding applications are Microsoft SQL Server or Oracle Database Server.
These types of application require their data to be isolated from the data of other systems. These design considerations are the same whether the application is deployed as a physical or a virtual server.
The operating system can be stored in a shared storage pool, but VMware & NetApp both highly recommend that an application with high I/O requirements or one which is sensitive to latency should be isolated form other datasets.
So which one, FC (or FCoE), iSCSI, or NAS?
Again the answer is based on your environment and or application requirements. Does your application require 100 MBs or less? If so, then iSCSI or NFS over 1 GbE will work well. If your application is more demanding then you will need more bandwidth which means you must deploy of FC.
Summarizing My Points
Earlier in this post I introduced three types of storage: Legacy Interconnect, Shared Storage Pools, and Isolated Datasets and I’d like to summarize each.
Legacy interconnect is required to boot the physical infrastructure.
Shared Storage Pools are where one stores the majority of their Virtual Machines and have management implications.
Isolated Datasets are required for demanding applications and can be limited by the bandwidth available in a storage network link.
Unified Data Center Virtualization
As Cisco’s Unified Fabric becomes more mainstream and is paired up with VMware & NetApp’s Unified Storage it will usher in a refined best in class solution.
For purposes of this discussion I’m going to skip the discussion around the savings provided by Unified fabric in the areas of port and cable reduction, and operational simplicity. I believe this information is well understood.
Instead I’d ask you to consider the impact of Data Center Ethernet or Converged Enhanced Ethernet with the three storage types I defined.
I’d like to suggest that the ideal VMware architecture is comprised of Cisco’s Unified Fabric and NetApp’s Unified Storage would be leverage FCoE to boot ESX Servers, NFS for shared storage pools due to its operational simplicity and scalability, and either FCoE or NFS for access to isolated datasets.
You may ask why I didn’t select a protocol for the isolated datasets. It’s simple, as the infrastructure is comprised of 10 GbE I don’t have concerns around bandwidth constraints. The choice is up to the VMware and Storage Admin teams; provision LUNs or create a VMDKs, the choice is theirs.
Marc Thanks for the Article
I look forward to reading more from you. I’ve shared my thoughts on this topic here (as in the past), and I look forward to watching the Virtual Data Center evolve.
Re: “if you have to deploy 500 or more VMs you might save a large amount of operational management by deploying your shared storage pools over NFS”…..