Nas is an interesting topic when it comes to VMware. This is often a religious debate, many users of products that are better at file storage than block love to talk about using VMware on NAS. Now there is really nothing wrong with that, NAS is a great medium for VMware storage.

To start with, NAS, Network Attached Storage, is nothing more than allowing multiple client machines to share storage. Likely your PC has a shared drive, probably several, your public or departmental share is on a NAS using the windows SMB, Server Message Block, protocol.

In a VMware environment, we use the NFS, Network File System, a linux based protocol to connect the servers to the storage. Remember with VMware we want to use shared storage for High Availability and load distribution. The advantage to using NFS really comes down to simplicity. When we use NFS storage in VMware what we are doing is just creating a file rather than writing blocks. This was an early attraction when block based storage was not able to keep up with the writes coming from VMware. Since it was writing to an open file, there was no concept of writing and committing data, it was all just writing. This hasn’t changed, but block storage has gotten significantly better, but that is for another post.

The simplicity also comes from the ability to expand simply. If you have the space on the NFS server you can just grow the NFS share, no extents (joining multiple logical volumes together), just grow the file system. Really not much too it, and very simple to manage you also don’t worry about the file system. In a block based system you create a file system based on VMFS, the VMware File System, on NFS, it is it’s own file system, you are just a file living there.

So the plus side is this is pretty simple, and the performance is now about the same from block to file, so what is the downside?

The biggest issue on my side is multipathing. There are ways to get around this, mostly proprietary, and with proper networking you can actually use nic bonding to give you a sense of multiple paths, but this requires some planning outside of the VMware environment, and can be challanging. On that point you are bound by your IP network, remember this doesn’t run over Fiber Channel, so if you go this direction, you better be on a rock solid network.

The other major downside, from my perspective, is VMware typically releases the features first to the block systems and then to NAS. Now again this gap is closing, but it is there. If you are like me, you update your iPhone to the latest code the min it is released and the servers stop crashing. In my lab, I run bleeding edge code, and I am all about the coolest and flashy, so this is important to me.

At the end of the day, NAS is great in a VMware environment. I personally like to have both options available, and would never tell someone they are wrong for going either direction, just make sure you are able to justify your decision.

Continuing on with the theme from last week. Again this is just to get things started, I do intend to dig into some of these areas much deeper, and discuss specific products, but to assume that everyone knows the basics would be in opposition to my desire to make technology, specifically virtualizaiton, something we can all understand and work with.

I was first introduced to the concept of a SAN with the Apple X-Raid in 2004 by a software developer I worked with. We were at a small software startup in Sacramento, CA, and the concept seemed outrageous to me. Shortly after that I ended up moving to a Casino where I was handed a SAN and the VMware ISO images. I quickly learned the value of shared storage.

The concept behind a SAN is that rather than the islands of storage we talked about in part 1, we can logically divide a large pool of storage between multiple servers. This is important in a VMware environment to enable things such as High Availability and Load Balancing between hosts. Since all hosts have access to all shared storage (SAN), a Virtual Machine may reside on any host.

A critical design point when using a SAN in any environment, but especially in VMware, is multipathing. This is simply having more than one connection from the host server to the shared storage. This becomes particularly critical in a VMware environment. Remember we are dealing with consolidation, so I may be moving 5,10, or more workloads to a single VMware host. Not only does this increase risk but also the load carried by the storage connections. This is where your SAN vendor’s controller design can help or hurt you, but that is a topic for another day.

SAN’s come in many flavors, but the connectivity methods are generally iSCSI, Fiber Channel, and Fiber Channel Over Ethernet. Each of these has it’s own advantages and disadvantages. What I have found is generally speaking this is largely dependent on the environment. For smaller customers, iSCSI is often perfectly acceptable, and can provide a familiar medium for the networking team. In larger environments, Fiber Channel is often preferable since it offers a simple and low latency network which is designed to do one thing and one thing only.

One closing thought on storage networking, it is important to consider line speed. With the release of 16G Fiber Channel, and 10GbE becoming more affordable, it is often wise to step up and pay for the fastest storage network you can afford. As Solid State Drives continue to gain market share we are seeing more and more storage networks become saturated. Many storage array vendors are dropping support for slower speeds, 1GbE iSCSI in particular. Always wise to prevent bottlenecks wherever possible even if it does cost a little more up front.