The first part of this series discussed shared storage options for your virtual infrastructure, why shared storage is needed with virtualization and how to choose a shared storage
More storage resources
In pursuit of affordable options for a shared storage system
SAN vs. NAS: What's the difference?
Shared storage model faces challenges from virtual servers
Learn about health care storage virtualization at Health IT Exchange
Before getting started, it's important to note that the comparisons made below -- storage area network (SAN) versus network-attached storage (NAS), and Internet Small Computer System Interface (iSCSI) versus Fibre Channel (FC) versus Network File System (NFS) -- are the subject of long-time "religious debates." Vendors and storage admins alike have jumped on the bandwagon of these different solutions and have fought hard. I've tried to be as unbiased as possible in these comparisons because, in the end, any of these storage solutions would work. The point is to try to choose the best shared storage system -- which will likely be different for everyone.
A look at SAN options: iSCSI versus Fibre Channel
Before comparing SAN to NAS, first understand that there are two SAN options used with vSphere and Hyper-V. They are iSCSI and Fibre Channel. As both of these are storage area network options, they create block-based storage, over a network, such that your servers see the shared storage as locally attached SCSI logical unit numbers (LUNs).
However, iSCSI and Fibre Channel aren't created equal. Here's how they compare:
- iSCSI uses your existing Ethernet network (or a separate dedicated Ethernet network you create) and carries SCSI commands over IP. The iSCSI storage arrays connect to the iSCSI SAN using standard Ethernet connections. Because iSCSI uses off-the-shelf Ethernet switches and Ethernet NIC cards, its upfront cost is going to be lower. However, if you do mix your critical iSCSI traffic with your regular network traffic then you could be asking for quality of service issues for your storage traffic. The iSCSI traffic on a Gigabit Ethernet (GbE) network will have 1Gb of bandwidth, but most production iSCSI SANs will bond multiple 1Gb connections together or use 10 GbE.
- Fibre Channel, unlike iSCSI, requires its own networking hardware including FC switches, FC cables and FC host bus adaptors (HBAs) that go in each server and FC storage arrays. FC SANs use the FC protocol to transport SCSI commands, not IP. Because of dedicated, non-commodity SAN components, FC SANs have a much more significant upfront cost. However, as FC SANs are known for their bullet-proof reliability – primarily derived from the fact that you are forced into creating a dedicated network (versus sharing your production network with iSCSI traffic, as too many companies do). FC SANs run as 4, 8, or 16Gb.
In the past, FC was chosen for enterprise-grade networks and iSCSI for lower-priority traffic. However, today, iSCSI networks have increased in their performance and reliability while offering an increasingly lower price tag. FC's popularity, on the other hand, is being slowly eroded because of lower-cost but increasingly better options offered by iSCSI and NFS.
Understanding the differences between iSCSI and Fibre Channel is important, but now you need to choose whether to use SAN or NAS.
Whether to use SAN or NAS for your shared storage system
When looking at a SAN, the choice is between iSCSI and Fibre Channel (FC). When looking at a NAS option (for virtualization) you'd be looking at NFS (yes there are SMB and AFP NAS options but you wouldn't use those with vSphere).
The point is to try to choose the best shared storage system -- which will likely be different for everyone.
When deciding between SAN and NAS, the primary decision is whether you want a block-based solution (the SAN) or a file-based solution (the NAS). In vSphere, for example you won't see a huge difference between the features available (for a feature comparison see VMware Storage – NFS, Fibre Channel, and iSCSI). All the major advanced vSphere features will be available by choosing either SAN or NAS. In the past, Fibre Channel's bandwidth and dedicated infrastructure created a huge difference between iSCSI and NFS. However, today iSCSI and NFS can perform just as well (and be as reliable) as the FC, if the design is done properly.
I should also mention that there are hybrid SAN/NAS solutions now. That means that you can buy a SAN that has a "NAS head" and use the same SAN for both.
Is NFS the best option for a shared storage system?
As so many vSphere admins come from the Windows admin side of the data center, using file-based storage (just like a Windows file share) is familiar. Creating a NFS NAS is a simple concept. For a lab environment, you could even enable NFS services in Windows Server 2008 to store VMs running on an ESXi host. Connecting an ESXi host to a NFS NAS is easy (much easier than connecting an iSCSI or FC SAN to vSphere).
NFS offers the easiest setup and the lowest cost for shared storage -- however, if the network configuration and design aren't done right, NFS will provide slow performance when VMs power up.
Which option should I choose for my shared storage system?
While researching the good and bad options for these shared storage systems may be interesting, in the end, you may just want to know which one to choose.
Personally, I would recommend to start by following my 5 steps to choosing a shared storage system. My candid advice to someone I might talk to at a local VMware user group is to start with a lower-cost option (like iSCSI or NFS), ensure that you design the shared storage infrastructure properly and see if one of those options works well for you.
David Davis is a contributing writer and author of the best-selling VMware vSphere video training library from Train Signal. He has written hundreds of virtualization articles on the Web, is a vExpert, VCP, VCAP-DCA, and CCIE #9369 with more than 18 years of enterprise IT experience. His personal website is VMwareVideos.com. Let us know what you think about the story; email firstname.lastname@example.org or contact @SearchHealthIT on Twitter.
This was first published in April 2012