A Storage Technology Blog by a Technologist

Polls

Do you use a single storage protocol in your IT infrastructure?

View Results

Loading ... Loading ...

Sponsors

Categories

Archive

Blogroll

Meta

Subscribe in NewsGator Online

Tortoise and the Hare? (NFS vs. iSCSI and why this Apples to Broccoli)

January 24th, 2013 by Steven Schwartz

I regularly get asked about storage protocols, especially when it comes to the right protocol to use to virtualization.  There is not a single right answer here.  However, there are several less efficient ways to do it.

 

Boston - Copley Square: The Tortoise and the Hare

Boston – Copley Square: The Tortoise and the Hare (Photo credit: wallyg)

NFS vs. iSCSI vs. FCoE vs. CIFS vs. ATAoE

Ethernet based storage protocols all get lumped together for comparison and they shouldn’t!  You’ll find below a table of common storage protocols and some basics around them.  As it pertains to Ethernet based protocols, there are two basic types, and they can be divided into SAN(block) and NAS(file) protocols.  There is a very important distinction between the two, and this distinction becomes even more apparent based on the storage vendor and application.  Storage vendors really have two products (there are a very few exceptions to that rule), NAS devices and SAN devices.  There are SAN devices that have the ability to be front ended by a NAS gateway (i.e. Puts a file system on a block device and presents it out as NAS device), and NAS devices that have an ability to emulate a block device by manipulating a large file on its file system.

 

Protocol Type Transport Requires A File System Standards Based
FCP Block FC (Optical or Copper) YES YES
FCoE Block Ethernet* YES YES*
iSCSI Block Ethernet YES YES
NFS File Ethernet NO YES
CIFS File Ethernet NO YES
SMB File Ethernet NO* YES*
ATAoE Block Ethernet* YES NO

*Caveats Apply

Which is faster?

There is a difference between speed and throughput!  I’ve commonly used the garden hose vs. water main comparison for clients.  While at Equallogic the conversation of iSCSI vs. FC was the hottest topic, and the speed difference between GigE and 10GbE.  The common misunderstanding was that because 10 > 1 that 10GbE was of course faster!  So back to the water model.  If you need to pass a small pebble (one with a diameter smaller than the diameter of a garden hose), or even a consistent line of small pebbles (transactional data profile) a garden hose can move those pebbles at the same “speed” as a water main.  It is only when data sets that are boulders and multiple concurrent data sets, that would need to be broken down into smaller checks to fit in a garden hose that the water main exceeds the “throughput” of the garden hose.  As a physicist pointed out to me, light travels at the same speed regardless of it being a tiny laser, or a giant one.  So in many cases, we proved that GigE could actually compete with 2Gb & 4Gb Fibre Channel (iSCSI vs. FCP).  With today’s technologies we are comparing 10GbE to 8Gb FC, so the “pipe” is less of an issue.

 

VMWare – iSCSI, FCP, FCoE, or NFS?

The ongoing debate becomes what storage protocol to use with VMWare.  The history of feature support to storage protocol is important, because in the earlier days of VMWare, features were released for FCP based storage first, then iSCSI, and last NFS.  This is no longer the case with VMWare’s releases.  If you refer to the above table, FCoE, FCP and iSCSI require a file system on top of the protocol.  In the case of VMWare, it is typically VMFS, VMWare’s clustered/shared file system.  Keep in the back of your head that the most difficult thing to develop at scale is a clustered file system (usually because of distributed lock management which doesn’t really apply with vmdks).  NFS however, is already a POSIX compliant shared file system as a storage protocol.  This means that there is no mapping of LUNs to ESX hosts, no management of the VMFS, or multiple VMFS instances, and less overall management required.  NFS doesn’t require specialized networks beyond tuned traditional route/switch.  It doesn’t require any special commands or configuration to grow in size, and it is fully supported within ESX and VMWare!  So given the option of SAN vs. NAS, with the current state of support, I would choose NAS (NFS) for VMWare, however, make sure you choose an enterprise NAS storage solution!!!!

Enhanced by Zemanta

Posted in Clustered File Systems, FCoE, General, iSCSI, NFS, SAN and NAS, virtualization, VMWare | 4 Comments »

  • Pingback: The SAN Technologist » Blog Archive » VMWare NFS, iSCSI, FC, & FCOE – The Update

  • Pingback: The SAN Technologist » Blog Archive » e NFS vs. iSCSI in a VMWare environment

  • Matt Rotkis

    So, the topology of the day is NAS, eh? I kid, of course. While I think that is a perfectly legitimate choice for VMWare deployments, I think that you’ll still find that there are plenty of monolithic operating system + application stacks connecting to that storage, and NAS is just a sub-optimal choice for that. RDBMS, messaging, collaboration, etc. that aren’t virtualized should still be able to take advantage of a single topology to reduce the overall complexity in the data center. iSCSI reduces complexity, has the requisite bandwidth and performance, and is simpler to implement, manage and maintain than competing topologies like FC (separate everything), or FCoE (converged to a point, but more complexity, overhead and problems).

    and welcome back – I’ve missed reading this crappy blog.

  • thesantech

    Considering I was specifically talking about storage protocols for VMware, and specifically trying to minimize the overhead and complexity of VMFS with block level LUNS, of course I leaned to NFS. Actually, this especially applies when using NAS filers (something I don’t believe DELL has yet, and I don’t mean putting a windows server or NAS appliance in front of a block storage device).

    Otherwise, I would agree in some cases. With Oracle databases, using Pillar FCP or ZFSSA NFS will result in some very interesting performance enhancements because of the tuning done at the application layer for those storage platforms.

    As for RDBMS, it really depends on the use case. OLTP I would agree with, warehouse implementations, prob. not.