Hi,
There is already an IP-based recovery solution provided by nfs-ganesha
(except for one small issue with the 'clustered' config option which I
shall mention below) and yes, we are currently using the same for our HA
cluster solution.
By default, if not provided any event in the input to the d-bus grace
command, the event maps to EVENT_TAKE_IP and looks for
'/var/lib/nfs/ganesha/${IP}' directory to load the clientIDs to be
recovered.
On 09/17/2015 10:56 PM, Malahal Naineni wrote:
> IBM actually uses RELEASE_IP and TAKENODE (instead of TAKE_IP). Don't
> know the reason for takenode event, but it doesn't sound right to me
> in all cases.
>
> Soumya reported an issue with the recovery directory having nodeid
> rather than ip based. Any progress there?
The issue was with 'clustered' config option. If this option is set,
nfs-ganesha writes the clients state to '/var/lib/nfs/ganesha/node{id}'
directory. Since we need IP based solution, we had to turn off this
config option though we have a cluster of nfs-ganesha nodes.
If I remember from the discussion we had, you had agreed to de-couple
this option from node-id so that this option can in general be used by
anyone planning to have a cluster (and not using node-IDs). And sorry I
have't got time to check on that later, but shall be able to look it (in
a couple of weeks time) if you would like me to work on it.
Thanks,
Soumya
>
> Regards, Malahal.
>
>
> Frank Filz [[email protected]] wrote:
>>> We've previously used node-based recovery, which is basically what's
>>> implemented right now in Ganesha. However, for a number of reasons we
>>> need an IP-based recovery solution. Malahal told me that Redhat wants an
>>> IP-based solution as well. Soumya (or anyone else), have you been working
>>> on this? Do you have anything to show yet?
>>
>> I thought the recovery was IP based already...
>>
>> There are basically three scenarios of interest:
>>
>> 1. Node goes down and IPs are moved to other nodes
>> 2. Interface on Node goes down and IP is moved to another node
>> 3. Actually there's just two scenarios, because failback when a node or
>> interface comes back online is just scenario 2...
>>
>> This means there are three main actions to manage the transfer of state:
>>
>> 1. RELEASE_IP, if an interface goes down, the node that is losing that IP
>> needs to release state associated with that IP
>>
>> 2. TAKE_IP, whichever node is acquiring an IP address (whether from a failed
>> node, failed interface, or failback) must notify v3 clients and then accept
>> reclaims from the appropriate v3 and v4 cleints.
>>
>> 3. Somewhere in there all nodes need to cooperate to enforce grace period.
>>
>> Frank
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
>> _______________________________________________
>> Nfs-ganesha-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>>
>
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
