[gpfsug-discuss] AFM vs mmremotefs

[Simon Thompson (Research Computing - IT Services)]

We are just planning to deploy AFM as a cache tier for our HPC cluster and bulk data storage. So whilst they are locally connected etc, I can use a different type of storage for performance for HPC work. Bulk data has two copies over two data centres, so the AFM cache would ACK the write to the HPC client and then "push it as soon as possible" to the home (bulk data storage and do the two copies).

Similarly for ingest systems, for example streaming data off instruments, you might want to do really really fast (to a flash system) and then have the AFM write to home at some point. (of course your cache capacity needs to be sufficiently large that you are able to push writes/expel).

On the flip side, I don't think AFM has remote identity mapping (someone might correct me on that of course)

So I don't think its just about data location/connectivity.

Simon

From: <gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>> on behalf of "Mark.Bush at siriuscom.com<mailto:Mark.Bush at siriuscom.com>" <Mark.Bush at siriuscom.com<mailto:Mark.Bush at siriuscom.com>>
Reply-To: "gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>" <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Date: Thursday, 30 March 2017 at 17:09
To: "gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>" <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Subject: [gpfsug-discuss] AFM vs mmremotefs

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?




[id:image001.png at 01D2709D.6EF65720]
Mark R. Bush| Storage Architect
Mobile: 210-237-8415
Twitter: @bushmr<https://twitter.com/bushmr> | LinkedIn: /markreedbush<https://www.linkedin.com/in/markreedbush>
10100 Reunion Place, Suite 500, San Antonio, TX 78216
www.siriuscom.com<http://www.siriuscom.com/> |mark.bush at siriuscom.com<mailto: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<http://www.siriuscom.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170330/d5b6fdfd/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8745 bytes
Desc: image001.png
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170330/d5b6fdfd/attachment-0002.png>