vsphere on nas design considerations

Design Considerationsfor vSphere on NFSDiscussing some design considerationsfor using vSphere with NFS

Scott Lowe, VCDX 39vExpert, Author, Blogger, Geek

http://blog.scottlowe.org / Twitter: @scott_lowe

Before we start

•Get involved! Audience participation is encouraged and requested.

• If you use Twitter, feel free to tweet about this session (use hashtag #VMUG or handle @SeattleVMUG)

• I encourage you to take photos or videos of today’s session and share them online

•This presentation will be made available online after the event

Your name is familiar...

•Some NFS basics

•Some link aggregation basics

•NFS bandwidth

•Link redundancy

•NFS and iSCSI interaction

•Routed NFS access

•Other considerations

Agenda

•All versions of ESX/ESXi use NFSv3 over TCP

•NFSv3 uses a single TCP session for data transfer

•This single session originates from one VMkernel port and terminates at the NAS IP interface/export

•vSphere 5 adds support for DNS round robin but still uses single TCP session and only resolves DNS name once

Some NFS Basics

•Requires unique hash values to place flows on a link in the bundle

• Identical hash values will always result in the same link being selected

•Does provide link redundancy

•Doesn’t increase per-flow bandwidth, only aggregate bandwidth

•Need special support to avoid single point of failure (SPoF)

Some Link Aggregation Basics

•Can’t use link aggregation to increase per-datastore bandwidth

•Can’t use DNS round robin to increase per-datastore bandwidth

•Can’t use multiple VMkernel NICs to increase per-datastore bandwidth

•Must move to a faster network transport (from 1Gb to 10Gb Ethernet, for example)

•That being said, most workloads are not bandwidth constrained

NFS Bandwidth

•No concept of multipathing; link redundancy must be managed at the network layer

•No concept of multiple active “paths” per datastore

•Link aggregation helps but is not required

Link Redundancy

• iSCSI traffic is generally “pinned” to specific uplinks via port binding/multipathing configuration; not so for NFS traffic

•Traffic could “cross” uplinks under certain configurations

•Need to keep separate with:

•Per-port group failover configurations

•Separate vSwitches

•Separate IP subnets for iSCSI and NFS traffic

NFS and iSCSI Interaction

Routed NFS Access

•Supported as of vSphere 5.0 U1

•Be sure to use FHRP (HSRP or VRRP) for gateway redundancy and apply QoS where needed

•Can’t use IPv6 or vSphere Distributed Switch (VDS)

•Be sure latency won’t be an issue (WAN routing not supported)

•More information available at http://blogs.vmware.com/vsphere/2012/06/vsphere-50-u1-now-supports-routed-nfs-storage-access.html

•Thin provisioned VMDKs: need VAAI-NFS plugin to do thick provisioned VMDKs

•Datastore sizing: SCSI locking not an issue, but still need to consider:

•Underlying disk architectures/layout and IOPS requirements

•Ability to meet RPO/RTO

•Jumbo frames: can be useful, but not necessarily required

•ESXi configuration recommendations: follow vendor-provided recommended practices

Other Considerations

Questions &Answers

One more thing...

Coming to VMworld?

• If you’re coming to VMworld(and you should be!), considerbringing your spouse/partnerwith you!

•Spousetivities will be offeringplanned, organized activities for spouses/partners/friends traveling with VMworld conference attendees

•See http://spousetivities.com for more information

Thank you!