<div dir="ltr">Hi Rob,<div><br></div><div>Some things to think about from experiences a year or so ago...</div><div><br></div><div>If you intend to perform any HPC workload (writing / updating / deleting files) inside a cache, then appropriately specified gateway nodes will be your friend:</div><div><br></div><div>1. When creating, updating or deleting files in the cache, each operation requires acknowledgement from the gateway handling that particular cache, before returning ACK to the application. This will add a latency overhead to the workload - if your storage is IB connected to the compute cluster and using verbsRdmaSend for example, this will increase your happiness. Connecting low-spec gateway nodes over 10GbE with the expectation that they will "drain down" over time was a sore learning experience in the early days of AFM for me.</div><div><br></div><div>2. AFM queues can quickly eat up memory. I think around 350bytes of memory is consumed for each operation in the AFM queue, so if you have huge file churn inside a cache then the queue will grow very quickly. If you run out of memory, the node dies and you enter cache recovery when it comes back up (or another node takes over). This can end up cycling the node as it tries to revalidate a cache and keep up with any other queues. Get more memory!</div><div><br></div><div>I've not used AFM for a while now and I think the latter enormity has some mitigation against create / delete cycles (i.e. the create operation is expunged from the queue instead of two operations being played back to the home). I expect IBM experts will tell you more about those improvements. Also, several smaller caches are better than one large one (parallel execution of queues helps utilise the available bandwidth and you have a better failover spread if you have multiple gateways, for example).</div><div><br></div><div>Independent Writer mode comes with some small danger (user error or impatience mainly) inasmuch as whoever updates a file last will win; e.g. home user A writes a file, then cache user B updates the file after reading it and tells user A the update is complete, when really the gateway queue is long and the change is waiting to go back home. User A uses the file expecting the changes are made, then updates it with some results. Meanwhile the AFM queue drains down and user B's change arrives after user A has completed their changes. The interim version of the file user B modified will persist at home and user A's latest changes are lost. Some careful thought about workflow (or good user training about eventual consistency) will save some potential misery on this front.</div><div><br></div><div>Hope this helps,</div><div>Luke</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 23 Nov 2020 at 15:19, Robert Horton <<a href="mailto:robert.horton@icr.ac.uk">robert.horton@icr.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We're thinking about deploying AFM and would be interested in hearing<br>
from anyone who has used it in anger - particularly independent writer.<br>
<br>
Our scenario is we have a relatively large but slow (mainly because it<br>
is stretched over two sites with a 10G link) cluster for long/medium-<br>
term storage and a smaller but faster cluster for scratch storage in<br>
our HPC system. What we're thinking of doing is using some/all of the<br>
scratch capacity as an IW cache of some/all of the main cluster, the<br>
idea to reduce the need for people to manually move data between the<br>
two.<br>
<br>
It seems to generally work as expected in a small test environment,<br>
although we have a few concerns:<br>
<br>
- Quota management on the home cluster - we need a way of ensuring<br>
people don't write data to the cache which can't be accomodated on<br>
home. Probably not insurmountable but needs a bit of thought...<br>
<br>
- It seems inodes on the cache only get freed when they are deleted on<br>
the cache cluster - not if they get deleted from the home cluster or<br>
when the blocks are evicted from the cache. Does this become an issue<br>
in time?<br>
<br>
If anyone has done anything similar I'd be interested to hear how you<br>
got on. It would be intresting to know if you created a cache fileset<br>
for each home fileset or just one for the whole lot, as well as any<br>
other pearls of wisdom you may have to offer.<br>
<br>
Thanks!<br>
Rob<br>
<br>
-- <br>
Robert Horton | Research Data Storage Lead<br>
The Institute of Cancer Research | 237 Fulham Road | London | SW3 6JB<br>
T +44 (0)20 7153 5350 | E <a href="mailto:robert.horton@icr.ac.uk" target="_blank">robert.horton@icr.ac.uk</a> | W <a href="http://www.icr.ac.uk" rel="noreferrer" target="_blank">www.icr.ac.uk</a> |<br>
Twitter @ICR_London<br>
Facebook: <a href="http://www.facebook.com/theinstituteofcancerresearch" rel="noreferrer" target="_blank">www.facebook.com/theinstituteofcancerresearch</a><br>
<br>
The Institute of Cancer Research: Royal Cancer Hospital, a charitable Company Limited by Guarantee, Registered in England under Company No. 534147 with its Registered Office at 123 Old Brompton Road, London SW7 3RP.<br>
<br>
This e-mail message is confidential and for use by the addressee only.  If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer and network.<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
</blockquote></div>