Lohit,
 
What you are trying to achieve is a supported architecture, there are several limitations however
 
This is the list of limitations on setting up remote mount protocols
https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.2/com.ibm.spectrum.scale.v5r02.doc/bl1adv_limitationofprotocolonRMT.htm
 
This is the commended architecture
https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.2/com.ibm.spectrum.scale.v5r02.doc/bl1adv_protocoloverremoteclu.htm
 
This is the actual procedure
 
https://www.ibm.com/support/knowledgecenter/en/STXKQY_5.0.2/com.ibm.spectrum.scale.v5r02.doc/bl1adv_configprotocolsonremotefs.htm
 
 
Hope this helps,
 
Andrew Beattie
File and Object Storage Technical Specialist - A/NZ
IBM Systems - Storage
Phone: 614-2133-7927
 
 
----- Original message -----
From: [email protected]
Sent by: [email protected]
To: gpfsug main discussion list <[email protected]>
Cc:
Subject: [gpfsug-discuss] Exporting remote GPFS mounts on a non-ces SMB share
Date: Fri, Mar 8, 2019 5:17 AM
 
Hello All,
 
We are thinking of exporting “remote" GPFS mounts on a remote GPFS 5.0 cluster through a SMB share.
 
I have heard in a previous thread that it is not a good idea to export NFS/SMB share on a remote GPFS mount, and make it writable.
 
The issue that could be caused by making it writable would be metanode swapping between the GPFS clusters.
 
May i understand this better and the seriousness of this issue?
 
The possibility of a single file being written at the same time from a GPFS node and NFS/SMB node is minimum - however it is possible that a file is written at the same time from multiple protocols by mistake and we cannot prevent it.
 
This is the setup:
 
GPFS storage cluster: /gpfs01
GPFS CES cluster ( does not have any storage) : /gpfs01 -> mounted remotely . NFS export /gpfs01 as part of CES cluster
GPFS client for CES cluster -> Acts as SMB server and exports /gpfs01 over SMB
 
Are there any other limitations that i need to know for the above setup?
 
We cannot use GPFS CES SMB as of now for few other reasons such as LDAP/AD id mapping and authentication complications.

Regards,
Lohit
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
 

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

Reply via email to