<div dir="ltr">Hi Chris,<div><br></div><div>Check with me in about a year.</div><div><br></div><div>After using Lustre for over 10 years to initially serve ~10 PB of disk and now serve 30+ PB with very nice DDN gear, later this year we will be installing 320 PB (250 PB useable) of GPFS (via IBM ESS storage units) to support Summit, our next gen HPC system from IBM with Power9 CPUs and NVIDIA Volta GPUs. Our current Lustre system is capable of 1 TB/s for large sequential writes, but random write performance is much lower (~400 GB/s or 40% of sequential). The target performance for GPFS will be 2.5 TB/s sequential writes and 2.2 TB/s random (~90% of sequential). The initial targets are slightly lower, but we are supposed to achieve these rates by 2019.</div><div><br></div><div>We are very familiar with Lustre, the good and the bad, and ORNL is the largest contributor to the Lustre codebase outside of Intel. We have encountered many bugs at our scale that few other sites can match and we have tested patches for Intel before their release to see how they perform at scale. We have been testing GPFS for the last three years in preparation for the change and IBM has been a very good partner to understand our performance and scale issues. Improvements that IBM are adding to support the CORAL systems will also benefit the larger community.</div><div><br></div><div>People are attracted to the "free" aspect of Lustre (in addition to the open source), but it is not truly free. For both of our large Lustre systems, we bought block storage from DDN and we added Lustre on top. We have support contracts with DDN for the hardware and Intel for Lustre as well as a large team within our operations to manage Lustre and a full-time Lustre developer. The initial price is lower, but at this scale running without support contracts and an experienced operations team is untenable. IBM is proud of GPFS and their ESS hardware (i.e. licenses and hardware are expensive) and they also require support contracts, but the requirements for operations staff is lower. It is probably more expensive than any other combination of hardware/licenses/support, but we have one vendor to blame, which our management sees as a value.</div><div><br></div><div>As I said, check back in a year or two to see how this experiment works out.</div><div><br></div><div>Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 1:53 AM, Christopher Samuel <span dir="ltr"><<a href="mailto:samuel@unimelb.edu.au" target="_blank">samuel@unimelb.edu.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi John,<br>
<span class=""><br>
On 15/02/17 17:33, John Hanks wrote:<br>
<br>
> So "clusters" is a strong word, we have a collection of ~22,000 cores of<br>
> assorted systems, basically if someone leaves a laptop laying around<br>
> unprotected we might try to run a job on it. And being bioinformatic-y,<br>
> our problem with this and all storage is metadata related. The original<br>
> procurement did not include dedicated NSD servers (or extra GPFS server<br>
> licenses) so we run solely off the SFA12K's.<br>
<br>
</span>Ah right, so these are the embedded GPFS systems from DDN. Interesting<br>
as our SFA10K's hit EOL in 2019 and so (if our funding continues beyond<br>
2018) we'll need to replace them.<br>
<span class=""><br>
> Could we improve with dedicated NSD frontends and GPFS clients? Yes,<br>
> most certainly. But again, we can stand up a PB or more of brand new<br>
> SuperMicro storage fronted by BeeGFS  that performs as well or better<br>
> for around the same cost, if not less.<br>
<br>
</span>Very nice - and for what you're doing it sounds like just what you need.<br>
<span class=""><br>
> I don't have enough of an<br>
> emotional investment in GPFS or DDN to convince myself that suggesting<br>
> further tuning that requires money and time is worthwhile for our<br>
> environment. It more or less serves the purpose it was bought for, we<br>
> learn from the experience and move on down the road.<br>
<br>
</span>I guess I'm getting my head around how other sites GPFS performs given I<br>
have a current sample size of 1 and that was spec'd out by IBM as part<br>
of a large overarching contract. :-)<br>
<br>
I guess I assuming that because that was what we had it was how most<br>
sites did it, apologies for that!<br>
<br>
All the best,<br>
<div class="HOEnZb"><div class="h5">Chris<br>
--<br>
 Christopher Samuel        Senior Systems Administrator<br>
 VLSCI - Victorian Life Sciences Computation Initiative<br>
 Email: <a href="mailto:samuel@unimelb.edu.au">samuel@unimelb.edu.au</a> Phone: <a href="tel:%2B61%20%280%293%20903%2055545" value="+61390355545">+61 (0)3 903 55545</a><br>
 <a href="http://www.vlsci.org.au/" rel="noreferrer" target="_blank">http://www.vlsci.org.au/</a>      <a href="http://twitter.com/vlsci" rel="noreferrer" target="_blank">http://twitter.com/vlsci</a><br>
______________________________<wbr>_________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>