<div dir="ltr">A couple of things I see in this thread:<div><br></div><div>1. Metadata performance!  A lot of bioinformatics code uses metadata searches. Anyone doing these kinds of workloads should tune/spec for metadata separately from data storage. In Spectrum Scale there is a choice of dedicated, fully distributed or partially distributed metadata. Most bio houses I know choose to through really good flash dedicated to the metadata. </div><div>Not familiar with the options for BeeFS, but do know superior distributed metadata performance was a key target for the Fraunhofer team. Sounds like they are hitting it. My limited history with Ceph & Gluster suggests they could not support bioinformatic metadata requirements. It wasn't they were built to do.</div><div><br></div><div>2. Small files!  Small file performance is undoubtedly a big gain in IBM dev from GPFS v 3.x to IBM Spectrum Scale 4.x - Don't compare the old performance with the new. Spectrum Scale look into the client side caching for reads and/or writes. A local SSD could be a great boon for performance. There are lots of tuning options for Scale/GPFS. Small file performance and simplified install were also target for BeeFS when they started development.</div><div><br></div><div>3. Spectrum Scale (GPFS) is absolutely fundamental to IBM. There is a lot of focus now on making it easier to adopt & tune. IBM dev has delivered new GUI, monitoring, troubleshooting, performance counters, parameterization of tuning in the last 18 months. </div><div><br></div><div>4. IBM Spectrum Scale does differentiate with multi-cluster, tiered storage support, migrate data to cloud by policy, HDFS support, etc.  These may be overkill for a lot of this mailing list, but really useful in shared settings. </div><div><br></div><div>Sorry about the guy with the suit. IBM also has a good set of Scale/GPFS people who don't own ties. Passing along your feedback on the client license costs to guys with ties.  </div><div><br></div><div>doug</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 8:43 AM, Scott Atchley <span dir="ltr"><<a href="mailto:e.scott.atchley@gmail.com" target="_blank">e.scott.atchley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>Scott</div></font></span></div><div class="HOEnZb"><div class="h5"><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><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><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><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="m_-7815947386494368447HOEnZb"><div class="m_-7815947386494368447h5">Chris<br>
--<br>
 Christopher Samuel        Senior Systems Administrator<br>
 VLSCI - Victorian Life Sciences Computation Initiative<br>
 Email: <a href="mailto:samuel@unimelb.edu.au" target="_blank">samuel@unimelb.edu.au</a> Phone: <a href="tel:%2B61%20%280%293%20903%2055545" value="+61390355545" target="_blank">+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" target="_blank">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/mailman<wbr>/listinfo/beowulf</a><br>
</div></div></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div>