Hi,
during the RC stage of Ontap 9.12.1 it was mentioned that it finally supported NFS 4.1 multipathing. However, now that 9.12.1 has been released I can’t find NFS 4.1 multipathing support in the release notes.
Am I missing something?
Please file a doc feedback. https://docs.netapp.com/us-en/ontap-cli-9121//vserver-nfs-modify.html#parameters it's here in 9.12. Not sure why it's not in the release notes.
Thanks, I submitted the feedback. But how about this:
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/ESXi_NFS4.1_VMDK_inaccessible_after_takeover#
is this still valid for 9.12.1? In here NetApp states you shouldn’t use NFS 4.1 with ESXi at the current time.
I got a reply from the documentation team. They state:
NFSv4.1 session trunking is expected to be released as a General Availability feature of ONTAP 9.12.1 in an upcoming patch release. The ONTAP 9 Release Notes will be updated to include this feature at that point.
I don’t know why this is marked as accepted solution, but according to Netapp it’s not in 9.12.1, it will be an available in a patch release later.
Ontap 9.13.1 is released today but I still can’t find anything about NFS 4.1 multipathing. Will this feature ever be released?
You sure that Session Trunking is not yet in ONTAP?
Still need to try it out, but I've seen docs (partner-facing) where this has been used (for AI workload from NVIDIA DGX combined with an AFF A800 and FlexGroups).
well, according to the information in this thread it should be released in one of the upcoming patch releases of 9.12.1. Since then I watch the release notes for every release, but I can't find any info on sessiontrunking in there. Also the NFS documentation doesn't list it as an option and in the GUI of System Manager it's not available also, while iSCSI multipathing is available there.
@jtownsen any ideas?
We have gone through similar questions and experienced the same confusion, but got no straight answer from NetApp.
Unbelievable, isn't it? This was a highly anticipated feature during the 9.12 RC stage, but no word on it since.
Anyone? Still no information about this to be found.
For some reasons, NetApp didn't want to broadcast the feature, my feeling.
In any event, how much performance could be improved by using the new feature? This may be a real question. They seem to be hesitated to address.
We now have iSCSI luns, but from vSphere management perspective we prefer to use NFS, but since that has no redundant links (we can't use trunking since our switches don't support cross stack LACP) we have to use multipathing. With iSCSI this works fine, but since NFS 4.1 also supports this, we want to use this highly anticipated feature. It was promoted by NetApp during the 9.12 testing phase as one of the top features, but now they have gone completely silent about this.
Are you already on 9.12? Have you thought of experimenting it?
@FrankWest depending on your use case you may very well still want to keep iSCSI MPIO as you can have it configured will a full mesh across the NetApp controllers. I am sure there will be a limitation with NFS multipathing where it can only multipath across ports within the same controller (single node) reference https://whyistheinternetbroken.wordpress.com/2022/11/11/behind-the-scenes-episode-347-netapp-ontap-9-12-1-overview/
00;32;38;21 – 00;32;46;08Justin ParisiCan I do this across data LIFs on different nodes in the cluster? Is it going to work that way or is it only on a single nodes, data LIFs.
00;32;46;16 – 00;32;49;28Keith AasenSingle node. I came across that one in testing.
So if you are trying to look at NFS multipathing for fast NFS failover between controllers I am not sure this solution will meet your requirements.
Maybe @ChanceBingen can shed some more light on the operation.
I apologise for the necropost on this thread, but it seems NetApp didn't make much of an announcement when this became fully supported, and as this thread comes up fairly high on the google searches for ONTAP session trunking I thought it might help some folk to find the relevant information.This became fully supported in ONTAP 9.14 - As documented here https://docs.netapp.com/us-en/ontap/nfs-trunking/index.html#how-to-use-trunking
There are also a number of KB articles on best practice and troubleshooting related to session trunking such as https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/What_is_the_maximum_number_of_trunked_connections_for_NFS_in_ONTAP_9.it can be used in combination with nconnect, and it has tested interoperability with Linux and ESXi. Please check on the latest documentation for the most complete information.
Fun fact, it's used in our AI Pod solution: NVA-1173 NetApp AIPod with NVIDIA DGX Systems - Deployment Details 👍
Thanks, nice to see a step-by-step configuration example. In response to some of the questions above regarding session trunking across controllers, it looks like they're looking for session trunking to replicate SCSI style MPIO, which seems closer to what I'd expect pNFS to provide rather than session trunking, though I figure they could be used together. With pNFS and network outage (more common but highly unlikely in a trunking / LACP setup) or a node-down situation, a read or write failure would make the client query the metadata server for a new optimal path to the data, or it could use the layout data it already has to try an alternate path, or it could just wait for a LIF failover and find that on retry (not unlike NPIV in the SAN world)All of those seem pretty analogous to a SCSI style MPIO stack, and while I wouldn't expect the same kind of detection and resolution times we've seen in the block world in things like ASA, with some reasonable level of timeout and retry settings it could get remarkably close.
All our client connections, mostly NFS volumes or NFS datastores, a handful CIFS are running on the top of 2x100GbE LACP setup on each node within the cluster Both "nconnect" and "session trunking" should address issues caused by networking bottleneck, upon my understanding. We don't have such issues. Even though we had, "neconnect" would be the first thing we should try, because it is easy to set up, and can provide multiple TCP sessions over a LIF, but essentially all over the LACP. We don't have plan or wouldn't set up extra NIC's or LACP group's, setting up session trunking and then making sure all failover/takeback would work as expected is not so straightforward, and plus, session trunking only work on a single node, essentially over the LACP as well, same as "nconnect".
Weighing in on those considerations, it is good to know such option, but we wouldn't really benefits too much from "session trunking" in our case, correct?
