<div dir="ltr"><div><div><div><div><div><div>> This locking is much more elegant in NFSv4. So in clustered NFS Server you<br>> should use v4. See the resource agent description for locking timeouts.<br><br></div><div>OK, I follow your advice.<br></div><div><br><br>> Obviously you'll need to tune this for your use case.<br>><br>> So a floating service IP address. Client mount options are just<br>> "rw,hard,intr", with a DNS name associated to this service IP address.<br><br></div>Thank you Colin for your example.<br></div>A comment about NFSv4, with RHCS on CentOS 6 I have error when I use ressource "nfsexport". It seems that "nfsserver" is better in that case.<br><br><br>> How are you managing the failover?  If you are doing failover of the<br>> file system (e.g., via SAN), then I'd expect the HA service manager<br>> (rgmanager, pacemaker, etc.) to handle the export, since you don't<br>> want to do the export until the file system is mounted.  If you are<br>> exporting a replica file system, then I believe it has to be a block<br>> level replica (e.g., DRDB)--a file system replica via rsync or such<br>> will have different inode numbers, and AIR the inode number shows up<br>> in the NFS file handle.<br><br></div>I was on the second case (file system replica) so that's why I have the error about the ID.<br></div>Thank you very much for your light !<br></div>I use a centralized file system to resolve this.<br></div>I think it's the only way to permit transparent NFS failover ?<br><div><div><div><div><br><br></div></div></div></div></div>