[gpfsug-discuss] AFM vs mmremotefs

[Glen Corneau]

Just a extra note: Multi-cluster (mmremotefs) does not always mean 
"network" for file system data transfer.  If both cluster(s) see the 
storage over the SAN then the data happens over that path.  This is common 
in a localized scenario for authorization reasons (i.e. nodes 1,2,3 can 
access file systems A & B, but not C; but nodes 4,5,6 in a separate 
cluster can access all 3 file systems)

------------------
Glen Corneau
Power Systems
Washington Systems Center
gcorneau at us.ibm.com





From:   Marc A Kaplan/Watson/IBM at IBMUS
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   03/30/2017 11:27 AM
Subject:        Re: [gpfsug-discuss] AFM vs mmremotefs
Sent by:        gpfsug-discuss-bounces at spectrumscale.org



I think you "got it" -  despite the name "remote" - mmremotefs is an 
access method and a way of organizing your data and machines into several 
clusters - which can work great if your network(s) are fast enough.   For 
example you can have one or more client clusters with no GPFS(Spectrum 
Scale) file systems stored "locally".  And one or several  clusters that 
are servers to those client clusters.  

AFM is about caching and replicating files...   You might do that because 
of "remote-ness" - or for other reasons...

--marc



From:        "Mark.Bush at siriuscom.com" <Mark.Bush at siriuscom.com>
To:        gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:        03/30/2017 12:09 PM
Subject:        [gpfsug-discuss] AFM vs mmremotefs
Sent by:        gpfsug-discuss-bounces at spectrumscale.org



When does it make sense to use mmremotefs vs AFM?  With mmremotefs the 
actual data lives on the remote cluster right so if you need data closer 
then AFM make more sense to use?  If the clusters get disconnected with 
mmremotefs I have not access to the data with AFM I do. 
 
Do I have these concepts right in my head?
 
 
 
 

Mark R. Bush| Storage Architect
Mobile: 210-237-8415 
Twitter: @bushmr| LinkedIn: /markreedbush
10100 Reunion Place, Suite 500, San Antonio, TX 78216
www.siriuscom.com|mark.bush at siriuscom.com
 
This message (including any attachments) is intended only for the use of 
the individual or entity to which it is addressed and may contain 
information that is non-public, proprietary, privileged, confidential, and 
exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any use, dissemination, 
distribution, or copying of this communication is strictly prohibited. 
This message may be viewed by parties at Sirius Computer Solutions other 
than those named in the message header. This message does not contain an 
official representation of Sirius Computer Solutions. If you have received 
this communication in error, notify Sirius Computer Solutions immediately 
and (i) destroy this message if a facsimile or (ii) delete this message 
immediately if this is an electronic communication. Thank you. 
Sirius Computer Solutions _______________________________________________
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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170330/549f0d82/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26117 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170330/549f0d82/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 8745 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170330/549f0d82/attachment.png>