<div dir="ltr">I can't compare it to Lustre currently, but in the theme of general, we have 4 major chunks of storage:<div><br></div><div>1. (~500 TB) DDN SFA12K running gridscaler (GPFS) but without GPFS clients on nodes, this is presented to the cluster through cNFS.</div><div><br></div><div>2. (~250 TB) SuperMicro 72 bay server. Running CentOS 6.8, ZFS presented via NFS</div><div><br></div><div>3. (~ 460 TB) SuperMicro 90 dbay JBOD fronted by a SuperMIcro 2u server with 2 x LSI 3008 SAS/SATA cards. Running CentOS 7.2, ZFS and BeeGFS 2015.xx. BeeGFS clients on all nodes.</div><div><br></div><div>4. (~ 12 TB) SuperMicro 48 bay NVMe server, running CentOS 7.2, ZFS presented via NFS</div><div><br></div><div>Depending on your benchmark, 1, 2 or 3 may be faster. GPFS falls over wheezing under load. ZFS/NFS single server falls over wheezing under slightly less load. BeeGFS tends to fall over a bit more gracefully under load.  Number 4, NVMe doesn't care what you do, your load doesn't impress it at all, bring more.</div><div><br></div><div>We move workloads around to whichever storage has free space and works best and put anything metadata or random I/O-ish that will fit onto the NVMe based storage. </div><div><br></div><div>Now, in the theme of specific, why are we using BeeGFS and why are we currently planning to buy about 4 PB of supermicro to put behind it? When we asked about improving the performance of the DDN, one recommendation was to buy GPFS client licenses for all our nodes. The quoted price was about 100k more than we wound up spending on the 460 additional TB of Supermicro storage and BeeGFS, which performs as well or better. I fail to see the inherent value of DDN/GPFS that makes it worth that much of a premium in our environment. My personal opinion is that I'll take hardware over licenses any day of the week. My general grumpiness towards vendors isn't improved by the DDN looking suspiciously like a SuperMicro system when I pull the shiny cover off. Of course, YMMV certainly applies here. But there's also that incident where we had to do an offline fsck to clean up some corrupted GPFS foo and the mmfsck tool had an assertion error, not a warm fuzzy moment...</div><div><br></div><div>Last example, we recently stood up a small test cluster built out of workstations and threw some old 2TB drives in every available slot, then used BeeGFS to glue them all together. Suddenly there is a 36 TB filesystem where before there was just old hardware. And as a bonus, it'll do sustained 2 GB/s for streaming large writes. It's worth a look.</div><div><br></div><div>jbh<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 14, 2017 at 10:02 AM, Jon Tegner <span dir="ltr"><<a href="mailto:tegner@renget.se" target="_blank">tegner@renget.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    BeeGFS sounds interesting. Is it possible to say something general
    about how it compares to Lustre regarding performance?<span class="HOEnZb"><font color="#888888"><br>
    <br>
    /jon</font></span><div><div class="h5"><br>
    <br>
    <div class="m_3078335498160632666moz-cite-prefix">On 02/13/2017 05:54 PM, John Hanks
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">We've had pretty good luck with BeeGFS lately
        running on SuperMicro vanilla hardware with ZFS as the
        underlying filesystem. It works pretty well for the cheap end of
        the hardware spectrum and BeeGFS is free and pretty amazing. It
        has held up to abuse under a very mixed and heavy workload and
        we can stream large sequential data into it fast enough to
        saturate a QDR IB link, all without any in depth tuning. While
        we don't have redundancy (other than raidz3), BeeGFS can be set
        up with some redundancy between metadata servers and mirroring
        between storage. <a href="http://www.beegfs.com/content/" target="_blank">http://www.beegfs.<wbr>com/content/</a>
        <div>
          <div>
            <div><br>
            </div>
            <div>jbh</div>
          </div>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Mon, Feb 13, 2017 at 7:40 PM Alex Chekholko
            <<a href="mailto:alex.chekholko@gmail.com" target="_blank">alex.chekholko@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you
            have a preference for Free Software, GlusterFS would work,
            unless you have many millions of small files. It would also
            depend on your available hardware, as there is not a 1-to-1
            correspondence between a typical GPFS setup and a typical
            GlusterFS setup. But at least it is free and easy to try
            out. The mailing list is active, the software is now mature
            ( I last used GlusterFS a few years ago) and you can buy
            support from Red Hat if you like.<br class="m_3078335498160632666gmail_msg">
            <br class="m_3078335498160632666gmail_msg">
            Take a look at the RH whitepapers about typical GlusterFS
            architecture.<br class="m_3078335498160632666gmail_msg">
            <br class="m_3078335498160632666gmail_msg">
            CephFS, on the other hand, is not yet mature enough, IMHO.<br class="m_3078335498160632666gmail_msg">
            <div class="gmail_quote m_3078335498160632666gmail_msg">
              <div dir="ltr" class="m_3078335498160632666gmail_msg">On Mon, Feb 13, 2017 at
                8:31 AM Justin Y. Shi <<a href="mailto:shi@temple.edu" class="m_3078335498160632666gmail_msg" target="_blank">shi@temple.edu</a>> wrote:<br class="m_3078335498160632666gmail_msg">
              </div>
              <blockquote class="gmail_quote m_3078335498160632666gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div dir="ltr" class="m_3078335498160632666gmail_msg">Maybe you would
                  consider Scality (<a href="http://www.scality.com/" class="m_3078335498160632666gmail_msg" target="_blank">http://www.scality.com/</a>) for
                  your growth concerns. If you need speed, DDN is faster
                  in rapid data ingestion and for extreme HPC data
                  needs.</div>
                <div dir="ltr" class="m_3078335498160632666gmail_msg">
                  <div class="m_3078335498160632666gmail_msg"><br class="m_3078335498160632666gmail_msg">
                  </div>
                  <div class="m_3078335498160632666gmail_msg">Justin </div>
                </div>
                <div class="gmail_extra m_3078335498160632666gmail_msg"><br class="m_3078335498160632666gmail_msg">
                  <div class="gmail_quote m_3078335498160632666gmail_msg">On Mon, Feb 13,
                    2017 at 4:32 AM, Tony Brian Albers <span dir="ltr" class="m_3078335498160632666gmail_msg"><<a href="mailto:tba@kb.dk" class="m_3078335498160632666gmail_msg" target="_blank">tba@kb.dk</a>></span> wrote:<br class="m_3078335498160632666gmail_msg">
                    <blockquote class="gmail_quote m_3078335498160632666gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_3078335498160632666gmail_msg">On
                        2017-02-13 09:36, Benson Muite wrote:<br class="m_3078335498160632666gmail_msg">
                        > Hi,<br class="m_3078335498160632666gmail_msg">
                        ><br class="m_3078335498160632666gmail_msg">
                        > Do you have any performance requirements?<br class="m_3078335498160632666gmail_msg">
                        ><br class="m_3078335498160632666gmail_msg">
                        > Benson<br class="m_3078335498160632666gmail_msg">
                        ><br class="m_3078335498160632666gmail_msg">
                        > On 02/13/2017 09:55 AM, Tony Brian Albers
                        wrote:<br class="m_3078335498160632666gmail_msg">
                        >> Hi guys,<br class="m_3078335498160632666gmail_msg">
                        >><br class="m_3078335498160632666gmail_msg">
                        >> So, we're running a small(as in a small
                        number of nodes(10), not<br class="m_3078335498160632666gmail_msg">
                        >> storage(170TB)) hadoop cluster here.
                        Right now we're on IBM Spectrum<br class="m_3078335498160632666gmail_msg">
                        >> Scale(GPFS) which works fine and has
                        POSIX support. On top of GPFS we<br class="m_3078335498160632666gmail_msg">
                        >> have a GPFS transparency connector so
                        that HDFS uses GPFS.<br class="m_3078335498160632666gmail_msg">
                        >><br class="m_3078335498160632666gmail_msg">
                        >> Now, if I'd like to replace GPFS with
                        something else, what should I use?<br class="m_3078335498160632666gmail_msg">
                        >> It needs to be a fault-tolerant DFS,
                        with POSIX support(so that users<br class="m_3078335498160632666gmail_msg">
                        >> can move data to and from it with
                        standard tools).<br class="m_3078335498160632666gmail_msg">
                        >><br class="m_3078335498160632666gmail_msg">
                        >> I've looked at MooseFS which seems to
                        be able to do the trick, but are<br class="m_3078335498160632666gmail_msg">
                        >> there any others that might do?<br class="m_3078335498160632666gmail_msg">
                        >><br class="m_3078335498160632666gmail_msg">
                        >> TIA<br class="m_3078335498160632666gmail_msg">
                        >><br class="m_3078335498160632666gmail_msg">
                        ><br class="m_3078335498160632666gmail_msg">
                        <br class="m_3078335498160632666gmail_msg">
                      </span>Well, we're not going to be doing a huge
                      amount of I/O. So performance<br class="m_3078335498160632666gmail_msg">
                      requirements are not high. But ingest needs to be
                      really fast, we're<br class="m_3078335498160632666gmail_msg">
                      talking tens of terabytes here.<br class="m_3078335498160632666gmail_msg">
                      <span class="m_3078335498160632666m_-1164830425095355951m_-6847030932552244759HOEnZb m_3078335498160632666gmail_msg"><font class="m_3078335498160632666gmail_msg" color="#888888"><br class="m_3078335498160632666gmail_msg">
                          /tony<br class="m_3078335498160632666gmail_msg">
                        </font></span><span class="m_3078335498160632666m_-1164830425095355951m_-6847030932552244759im
m_-1164830425095355951m_-6847030932552244759HOEnZb m_3078335498160632666gmail_msg"><br class="m_3078335498160632666gmail_msg">
                        --<br class="m_3078335498160632666gmail_msg">
                        Best regards,<br class="m_3078335498160632666gmail_msg">
                        <br class="m_3078335498160632666gmail_msg">
                        Tony Albers<br class="m_3078335498160632666gmail_msg">
                        Systems administrator, IT-development<br class="m_3078335498160632666gmail_msg">
                        Royal Danish Library, Victor Albecks Vej 1, 8000
                        Aarhus C, Denmark.<br class="m_3078335498160632666gmail_msg">
                        Tel: <a href="tel:%2B45%202566%202383" value="+4525662383" class="m_3078335498160632666gmail_msg" target="_blank">+45 2566 2383</a> / <a href="tel:%2B45%208946%202316" value="+4589462316" class="m_3078335498160632666gmail_msg" target="_blank">+45 8946 2316</a><br class="m_3078335498160632666gmail_msg">
                      </span>
                      <div class="m_3078335498160632666m_-1164830425095355951m_-6847030932552244759HOEnZb m_3078335498160632666gmail_msg">
                        <div class="m_3078335498160632666m_-1164830425095355951m_-6847030932552244759h5 m_3078335498160632666gmail_msg">______________________________<wbr>_________________<br class="m_3078335498160632666gmail_msg">
                          Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" class="m_3078335498160632666gmail_msg" target="_blank">Beowulf@beowulf.org</a>
                          sponsored by Penguin Computing<br class="m_3078335498160632666gmail_msg">
                          To change your subscription (digest mode or
                          unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" class="m_3078335498160632666gmail_msg" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br class="m_3078335498160632666gmail_msg">
                        </div>
                      </div>
                    </blockquote>
                  </div>
                  <br class="m_3078335498160632666gmail_msg">
                </div>
                ______________________________<wbr>_________________<br class="m_3078335498160632666gmail_msg">
                Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" class="m_3078335498160632666gmail_msg" target="_blank">Beowulf@beowulf.org</a> sponsored by
                Penguin Computing<br class="m_3078335498160632666gmail_msg">
                To change your subscription (digest mode or unsubscribe)
                visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" class="m_3078335498160632666gmail_msg" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br class="m_3078335498160632666gmail_msg">
              </blockquote>
            </div>
            ______________________________<wbr>_________________<br class="m_3078335498160632666gmail_msg">
            Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" class="m_3078335498160632666gmail_msg" target="_blank">Beowulf@beowulf.org</a> sponsored by
            Penguin Computing<br class="m_3078335498160632666gmail_msg">
            To change your subscription (digest mode or unsubscribe)
            visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" rel="noreferrer" class="m_3078335498160632666gmail_msg" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a><br class="m_3078335498160632666gmail_msg">
          </blockquote>
        </div>
      </div>
      <div dir="ltr">-- <br>
      </div>
      <div data-smartmail="gmail_signature">
        <div dir="ltr">
          <div>‘[A] talent for following the ways of yesterday, is not
            sufficient to improve the world of today.’</div>
          <div> - King Wu-Ling, ruler of the Zhao state in northern
            China, 307 BC</div>
        </div>
      </div>
      <br>
      <fieldset class="m_3078335498160632666mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
Beowulf mailing list, <a class="m_3078335498160632666moz-txt-link-abbreviated" href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit <a class="m_3078335498160632666moz-txt-link-freetext" href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank">http://www.beowulf.org/<wbr>mailman/listinfo/beowulf</a>
</pre>
    </blockquote>
    <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></div></div>