On 07/27/2016 11:54 AM, Frank Filz wrote: >>> That is why we have the release_IP dBus command, it signals the >>> Ganesha that is giving up clients to drop their locks. >> >> Thanks a lot Frank. Right now in our HA solution, we do not send any > event. >> So by default I guess it takes "EVENT_TAKE_IP". Will try out >> "EVENT_RELEASE_IP". >> >> So IIUC, the only difference between "EVENT_TAKE_IP" and >> "EVENT_RELEASEIP" is that TAKE_IP just loads nfsv4 clients in memory to >> validate them during recovery where as release IP shall expire all the > existing >> clients of that IP (which involves releasing open and lock >> state) and then loads them in memory for recovery validation? > > The intent of EVENT_RELEASEIP is in the following scenario: > > On Node 1: > > IP address 10.0.0.1 is removed > Start cluster grace period > Issue EVENT_RELEASE_IP > Wait for grace period to expire > End cluster grace period > > On Node 2: > > IP address 10.0.0.1 is added > Start cluster grace period > Issue EVENT_TAKE_IP > Send SM_NOTIFY to NFS v3 clients talking to 10.0.0.1 > Allow recovery > End cluster grace period >
I think I missed something. This is the same grace period on both/all nodes, right? Not multiple discrete, sequential grace periods? And the IP is removed+added by the HA facility, e.g. CTDB or Pacemaker HA? Thanks -- Kaleb ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
