> 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?
Yes, same grace period on all nodes. > And the IP is removed+added by the HA facility, e.g. CTDB or Pacemaker HA? Yea, the actual IP address movement is done by CTDB or Pacemaker. And then Ganesha is informed on what is happening by EVENT_RELEASEIP and EVENT_TAKE_IP. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
