VMware NFS HA & multipathing without LACP

[radek_kubka]

Hi all,

In a LAN environment without cross-stack LACP (EtherChannel) functionality - can NFS load-balancing potentially use two stand-alone ports on each NetApp controller on two different subnets?

I found this in TR-3749:

*If* we remove vifs on the NetApp side, so only 2x stand-alone port is used per each controller - what happens on the ESX host when, let’s say, “green” port on FAS1 goes down – business as usual, “blue” path is used and data store doesn’t lose connectivity? Or does it??

Thanks,

Radek

[aborzenkov]

No. NFS is associated with IP address. If this address is unavailable, you cannot access NFS server. The only rather rude workaround is to failover when port lost connectivity (NFO).

Or switch to cDOT which implements transparent IP address failover between multiple physical ports

[radek_kubka]

Hi Andrey,

Many thanks for your response.

So two things which still puzzle me:

- if we ignore NetApp side for a moment, on that picture above there would be no link redundancy between ESX host and switches? (just two NICs on two different subnets)

- this joint post about NFS from Vaughan Steward and Chad Sakac seems to suggest vmkernel routing table may deliver fail-over capability between multiple NFS subnets:

http://virtualgeek.typepad.com/virtual_geek/2009/06/a-multivendor-post-to-help-our-mutual-nfs-customers-using-vmware.html

Further thoughts?

Thanks,

Radek

[aborzenkov]

I do not see anything about failover in this post, sorry. What they say - you may need to explicitly configure route to data store, to overcome single default route. As long as you use single interface per link, this configuration is not high-available when considering single ESXi server. But nothing prevents you from adding more interfaces to each subnet and pool them.

[aborzenkov]

- if we ignore NetApp side for a moment, on that picture above there would be no link redundancy between ESX host and switches? (just two NICs on two different subnets)

Well, I can't speak for TR author, but picture is titled "Storage side ..." so ESX side should not be considered as authoritative guideline. Also, different logical subnets do not yet imply different physical broadcast domains (VLANs).

I view it more as conceptual outline. But I agree that it makes things confusing. You have access to fieldportal, right? Go to TR and submit comment ...

[nicholaf]

If you setup the NFS mount/datastore using hostnames & each subnet had access to a DNS server that could resolve the hostname to the IP then yes that should work. I would test that setup in a lab environment first & once you have it working then take a maintenance window to implement it on your production systems.

Regards,

Nicholas Lee Fagan

[HENRYPAN2]

Saluting Nicholas,

Like your brief response.

Would you please also advice the advantage of use NFS vs SAN for EEX on filer?

Thanks in advance + Happy Sunday

Henry

[nicholaf]

This is always the big debate. NFS, CIFS, iSCSI, or FCP. Most people would say setup a LUN & use FCP for best performance. I say go with what you feel most comfortable/confident setting up & managing.

Regards,

Nicholas Lee Fagan

[aborzenkov]

It depends on your objective. It is easier to build redundant failure tolerant and load balanced connection to storage using SAN than NFS. OTOH NFS is easier to integrate with NetApp features (you have one layer less).

[aborzenkov]

DNS is evaluated during mount request only, so it does not help when connectivity to data store is lost. Even if ESX can transparently remount, it still means anything running off this data store had crashed. Not to mention that DNS server has no idea of interface connectivity on ESX, so it can return the same non-working address.

DNS is for load balancing, not for failover.