<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 3:44 PM, Patrick <span class="" id=":1bo.1" tabindex="-1">Zwahlen</span> <span dir="ltr"><<a href="mailto:paz@navixia.com" target="_blank"><span class="" id=":1bo.2" tabindex="-1">paz</span>@<span class="" id=":1bo.3" tabindex="-1">navixia</span>.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear list (sorry for the rather long e-mail),<br>
<br>
I'm looking for someone who has successfully implemented the "exportfs" RA with NFSv4 over TCP (and is willing to share some information).<br>
<br>
The final goal is to present NFS datastores to ESXi over 2 "head" nodes. Both nodes must be active in the sense that they both have an NFS server running but they export different file systems (via exports and floating IPAddr2).<br>
<br>
When moving an export to another node, we move the entire "filesystem/export/ipaddr" stack but we keep the NFS server running (as it might potentially be exporting some other file systems via other IPs).<br>
<br>
Both nodes are sharing disks (JBOD for physical and shared VMDKs for testing). Disks are only accessed by a single "head" node at any given time so a clustered file system is not required.<br>
<br>
To my knowledge, this setup has been best described by Florian Haas over there:<br>
<a href="https://www.suse.com/documentation/sle_ha/singlehtml/book_sleha_techguides/book_sleha_techguides.html" rel="noreferrer" target="_blank">https://www.suse.com/<wbr>documentation/sle_ha/<wbr>singlehtml/book_sleha_<wbr>techguides/book_sleha_<wbr>techguides.html</a><br>
(except we're not using DRBD and LVM)<br>
<br>
Before going into more details, I mention that I have already read all those posts and examples as well as many of the NFS related questions in this list for the past year or so.<br>
<br>
<a href="http://wiki.linux-nfs.org/wiki/index.php/Nfsd4_server_recovery" rel="noreferrer" target="_blank">http://wiki.linux-nfs.org/<wbr>wiki/index.php/Nfsd4_server_<wbr>recovery</a><br>
<a href="http://wiki.linux-nfs.org/wiki/index.php/NFS_Recovery_and_Client_Migration" rel="noreferrer" target="_blank">http://wiki.linux-nfs.org/<wbr>wiki/index.php/NFS_Recovery_<wbr>and_Client_Migration</a><br>
<a href="http://oss.clusterlabs.org/pipermail/pacemaker/2011-July/011000.html" rel="noreferrer" target="_blank">http://oss.clusterlabs.org/<wbr>pipermail/pacemaker/2011-July/<wbr>011000.html</a><br>
<a href="https://access.redhat.com/solutions/42868" rel="noreferrer" target="_blank">https://access.redhat.com/<wbr>solutions/42868</a><br>
<br>
I'm forced to use TCP because of ESXi and I'm willing to use NFSv4 because ESXi can use "session trunking" or some sort of "multipath" with version 4 (not tested yet)<br>
<br>
The problem I see is what a lot of people have already mentioned: Failover works nicely but failback takes a very long time. Many posts mention putting /var/lib/nfs on a shared disk but this only makes sense when we failover an entire NFS server (compared to just exports). Moreover, I don't see any relevant information written to /var/lib/nfs when a single Linux NFSv4 client is mounting a folder.<br>
<br>
NFSv4 LEASE and GRACE time have been reduced to 10 seconds. I'm using the exportfs RA parameter "wait_for_leasetime_on_stop=<wbr>true".<br>
<br>
>From my investigation, the problem actually happens at the TCP level. Let's describe the most basic scenario, ie a single filesystem moving from node1 to node2 and back.<br>
<br>
I first start the NFS servers using a clone resource. Node1 then starts a group that mounts a file system, adds it to the export list (exportfs RA) and adds a floating IP.<br>
<br>
I then mount this folder from a Linux NFS client.<br>
<br>
When I "migrate" my group out of node1, everything correctly moves to node2. IPAddr2:stop, then the exportfs "stop" action takes about 12 seconds (10 seconds LEASE time plus the rest) and my file system gets unmounted. During that time, I see the NFS client trying to talk to the floating IP (on its node1 MAC address). Once everything has moved to node2, the client sends TCP packets to the new MAC address and node2 replies with a TCP RESET. At this point, the client restarts a NEW TCP session and it works fine.<br>
<br>
However, on node 1, I can still see an ESTABLISHED TCP session between the client and the floating IP on port 2049 (NFS), even though the IP is gone. After a short time, the session moves to FIN_WAIT1 and stays there for a while.<br>
<br>
When I then "unmigrate" my group to node1 I see the same behavior except that node1 is *not* sending TCP RESETS because it still has a TCP session with the client. I imagine that the sequence numbers do not match so node1 simply doesn't reply at all. It then takes several minutes for the client to give up and restart a new NFS session.<br>
<br>
Does anyone have an idea about how to handle this problem ? I have done this with iSCSI where we can explicitly "kill" sessions but I don't think NFS has something similar. I also don't see anything in the IPAddr2 RA that would help in killing TCP sessions while removing a floating IP.<br></blockquote><div><br></div><div>This is a known problem ... have a look into the <span class="" id=":1bo.4" tabindex="-1">portblock</span> RA - it has the feature to send out <span class="" id=":1bo.5" tabindex="-1">TCP</span> tickle <span class="" id=":1bo.6" tabindex="-1">ACKs</span> to reset such hanging sessions. So you can configure a <span class="" id=":1bo.7" tabindex="-1">portblock</span> resource that blocks the <span class="" id=":1bo.9" tabindex="-1">tcp</span> port before starting the VIP and another <span class="" id=":1bo.10" tabindex="-1">portblock</span> resource that unblocks the port afterwards and sends out that tickle <span class="" id=":1bo.11" tabindex="-1">ACKs</span>. </div><div><br></div><div>Regards,</div><div>Andreas</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Next ideas would be to either tune the TCP stack in order to reduce the FIN_WAIT1 state or to synchronize sessions between the nodes (using conntrackd). That just seems an overkill.<br>
<br>
Thanks for any input! Patrick<br>
<br>
<br>
******************************<wbr>******************************<wbr>**************************<br>
This email and any files transmitted with it are confidential and<br>
intended solely for the use of the individual or entity to whom they<br>
are addressed. If you have received this email in error please notify<br>
the system manager. "<a href="mailto:postmaster@navixia.com">postmaster@navixia.com</a>"      Navixia SA<br>
******************************<wbr>******************************<wbr>**************************<br>
<br>
______________________________<wbr>_________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/<wbr>mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/<wbr>doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</blockquote></div><br></div></div>