[gpfsug-discuss] Experience with CES NFS export management

Mon Oct 23 13:20:47 BST 2017

Dear Chetan,

interesting. I’m running ISS 4.2.3-4 and it seems to ship with nfs-ganesha-2.3.2. So are you already using a future ISS version?

Here is what I see:
[root at datdsst102 pr74cu-dss-0002]# mmnfs export list
Path                             Delegations Clients
----------------------------------------------------------
/dss/dsstestfs01/pr74cu-dss-0002 NONE        10.156.29.73
/dss/dsstestfs01/pr74cu-dss-0002 NONE        10.156.29.72

[root at datdsst102 pr74cu-dss-0002]# mmnfs export change /dss/dsstestfs01/pr74cu-dss-0002 --nfschange "10.156.29.72(access_type=RW,squash=no_root_squash,protocols=4,transports=tcp,sectype=sys,manage_gids=true)"
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl stop nfs-ganesha.service
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl start nfs-ganesha.service
NFS Configuration successfully changed. NFS server restarted on all NFS nodes on which NFS server is running.

[root at datdsst102 pr74cu-dss-0002]# mmnfs export change /dss/dsstestfs01/pr74cu-dss-0002 --nfsadd "10.156.29.74(access_type=RW,squash=no_root_squash,protocols=4,transports=tcp,sectype=sys,manage_gids=true)"
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl stop nfs-ganesha.service
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl start nfs-ganesha.service
NFS Configuration successfully changed. NFS server restarted on all NFS nodes on which NFS server is running.

[root at datdsst102 ~]# mmnfs export change /dss/dsstestfs01/pr74cu-dss-0002 --nfsremove 10.156.29.74
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl stop nfs-ganesha.service
datdsst102.dss.lrz.de<http://datdsst102.dss.lrz.de>:  Redirecting to /bin/systemctl start nfs-ganesha.service
NFS Configuration successfully changed. NFS server restarted on all NFS nodes on which NFS server is running.

Best Regards,
Stephan Peinkofer
--
Stephan Peinkofer
Dipl. Inf. (FH), M. Sc. (TUM)

Leibniz Supercomputing Centre
Data and Storage Division
Boltzmannstraße 1, 85748 Garching b. München
Tel: +49(0)89 35831-8715     Fax: +49(0)89 35831-9700
URL: http://www.lrz.de

On 23. Oct 2017, at 13:56, Chetan R Kulkarni <chetkulk at in.ibm.com<mailto:chetkulk at in.ibm.com>> wrote:

Hi Stephan,

I observed ganesha service getting restarted only after adding first nfs export.
For rest of the operations (e.g. adding more nfs exports, changing nfs exports, removing nfs exports); ganesha service doesn't restart.

My observations are based on following simple tests. I ran them against rhel7.3 test cluster having nfs-ganesha-2.5.2.

tests:
1. created 1st nfs export - ganesha service was restarted
2. created 4 more nfs exports (mmnfs export add path)
3. changed 2 nfs exports (mmnfs export change path --nfschange);
4. removed all 5 exports one by one (mmnfs export remove path)
5. no nfs exports after step 4 on my test system. So, created a new nfs export (which will be the 1st nfs export).
6. change nfs export created in step 5

results observed:
ganesha service restarted for test 1 and test 5.
For rest tests (2,3,4,6); ganesha service didn't restart.

Thanks,
Chetan.

<graycol.gif>"Peinkofer, Stephan" ---10/23/2017 04:11:33 PM---Dear List, I’m currently working on a self service portal for managing NFS exports of ISS. Basically

From: "Peinkofer, Stephan" <Stephan.Peinkofer at lrz.de<mailto:Stephan.Peinkofer at lrz.de>>
To: "gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>" <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Date: 10/23/2017 04:11 PM
Subject: [gpfsug-discuss] Experience with CES NFS export management
Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>

________________________________

Dear List,

I’m currently working on a self service portal for managing NFS exports of ISS. Basically something very similar to OpenStack Manila but tailored to our specific needs.
While it was very easy to do this using the great REST API of ISS, I stumbled across a fact that may be even a show stopper: According to the documentation for mmnfs, each time we
create/change/delete a NFS export via mmnfs, ganesha service is restarted on all nodes.

I assume that this behaviour may cause problems (at least IO stalls) on clients mounted the filesystem. So my question is, what is your experience with CES NFS export management.
Do you see any problems when you add/change/delete exports and ganesha gets restarted?

Are there any (supported) workarounds for this problem?

PS: As I think in 2017 CES Exports should be manageable without service disruptions (and ganesha provides facilities to do so), I filed an RFE for this: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=111918

Many thanks in advance.
Best Regards,
Stephan Peinkofer
--
Stephan Peinkofer
Dipl. Inf. (FH), M. Sc. (TUM)

Leibniz Supercomputing Centre
Data and Storage Division
Boltzmannstraße 1, 85748 Garching b. München
Tel: +49(0)89 35831-8715 Fax: +49(0)89 35831-9700
URL: http://www.lrz.de<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lrz.de&d=DwMGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=uic-29lyJ5TCiTRi0FyznYhKJx5I7Vzu80WyYuZ4_iM&m=ghcZYswqgF3beYOogGGLsT1RyDRZrbLXdzp3Fbjmfrg&s=bUa2Eju3PnyQq3Dq27mogVtG7iadxCaEZEnOixz-qVw&e=>
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=uic-29lyJ5TCiTRi0FyznYhKJx5I7Vzu80WyYuZ4_iM&m=ghcZYswqgF3beYOogGGLsT1RyDRZrbLXdzp3Fbjmfrg&s=TUm7BM3sY75Nc20gOfhz9lvDgYJse0TM6-tIW8I1QiI&e=

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org<http://spectrumscale.org>
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20171023/3c635af8/attachment-0002.htm>