<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yes, read the documentation for the mmvdisk command to get a better idea of how this actually works. There’s definitely a small paradigmatic shift in thinking
that you’ll encounter between traditional NSDs and ECE. The mmvdisk command’s defaults handle just about everything for you and the defaults are sane.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The short answer is that in a 6-node ECE recoverygroup, each of the nodes will normally provide access to 2 NSDs and the system pool would therefore have 12 NSDs
total. If a node fails, each of its two NSDs will continue to be served each by a different one of the remaining servers. If you’ve used ESS before, then you can think about the RAID/spare/rebuild space similarly to that: all drives have some spare space
on them and erasure-code stripes are evenly distributed among all of the disks so that they are all used and fill at approximately the same rate.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> gpfsug-discuss-bounces@spectrumscale.org <gpfsug-discuss-bounces@spectrumscale.org>
<b>On Behalf Of </b>David Johnson<br>
<b>Sent:</b> Tuesday, July 30, 2019 9:04 AM<br>
<b>To:</b> gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
<b>Subject:</b> Re: [gpfsug-discuss] Building GPFS filesystem system data pool on shared nothing NVMe drives<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#CC0000">This message was sent by an external party.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">OK, so the ECE recovery group is the four NSD servers with the System storage pool disks, and somehow I have to read the docs
<o:p></o:p></p>
<div>
<p class="MsoNormal">and find out how to define pdisks that spread the replication across the four servers, but three disks at a time. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Three pdisks of 7 drives, three I can't do anything with, or are those for rebuilding space?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Can you provide me details of your six-node non-ECE configuration? Basically how the NSDs are defined...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The remainder of our new filesystem will have a fast pool of 12 nodes of excelero, and 2Pb of spinning disks, so another possibility<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">would be to license four more nodes and put the system pool under excelero. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> -- ddj<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jul 30, 2019, at 8:19 AM, Sanchez, Paul <<a href="mailto:Paul.Sanchez@deshaw.com">Paul.Sanchez@deshaw.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi David,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In an ECE configuration, it would be typical to put all of the NVMe disks in all 4 of your servers into a single recovery group. So in your case, all 24 NVMe
drives would be in one recovery group and the 4 servers would be “log group” servers in the recovery group, distributing the I/O load for the NSD/vdisks that are hosted on the RG. (The minimum disks for a single RG config is 12, and you meet that easily.)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://www.ibm.com/support/knowledgecenter/STXKQY_ECE_5.0.3/com.ibm.spectrum.scale.ece.v5r03.doc/b1lece_plan_recommendations.htm"><span style="color:purple">https://www.ibm.com/support/knowledgecenter/STXKQY_ECE_5.0.3/com.ibm.spectrum.scale.ece.v5r03.doc/b1lece_plan_recommendations.htm</span></a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">outlines the recommendations for raidCode protection. Your configuration (4 nodes) would use vdisks with 4+3P, which gives you a slightly better capacity yield
than RAID10 would, but with much better recovery characteristics:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">No
single failed node will result in a down system NSD.</span><o:p></o:p></p>
</div>
<div style="margin-left:.5in">
<p class="MsoNormal" style="text-indent:-.25in"><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D">·</span><span style="font-size:7.0pt;color:#1F497D"> <span class="apple-converted-space"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">No
single drive failure will require a critical priority rebuild, and can be handled in the background without killing performance.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">So from that perspective, ECE is a win here and avoids a problem with the non-ECE, shared-nothing designs: the manual “mmchdisk <fsname> start -a” operation that
is needed after any traditional shared-nothing metadata NSD goes offline to bring it back and protect against further failures.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Despite the operational challenges of the non-ECE design, it can sometimes survive two server failures (if replication factor is 3 and the filesystem descriptor
quorum wasn’t lost by the two failures) which a 4 node ECE cluster cannot. Given that the world is complex and unexpected things can happen, I’d personally recommend<span class="apple-converted-space"> </span><b>redistributing the 24 disks across 6 servers</b><span class="apple-converted-space"> </span>if
you can, so that the design could always survive 2 node failures. I’ve run this design and it’s fairly robust.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">In any event, you should of course test the failure scenarios yourself before going into production to validate them and familiarize yourself with the process.
And a special note on ECE: due to the cooperative nature at the pdisk level, the network between the servers in the RG should be as reliable as possible and any network redundancy should also be tested ahead of time.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Paul</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><span style="color:purple">gpfsug-discuss-bounces@spectrumscale.org</span></a><span class="apple-converted-space"> </span><<a href="mailto:gpfsug-discuss-bounces@spectrumscale.org"><span style="color:purple">gpfsug-discuss-bounces@spectrumscale.org</span></a>><span class="apple-converted-space"> </span><b>On
Behalf Of<span class="apple-converted-space"> </span></b>David Johnson<br>
<b>Sent:</b><span class="apple-converted-space"> </span>Tuesday, July 30, 2019 7:46 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org"><span style="color:purple">gpfsug-discuss@spectrumscale.org</span></a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [gpfsug-discuss] Building GPFS filesystem system data pool on shared nothing NVMe drives</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:9.0pt;font-family:"Verdana",sans-serif;color:#CC0000">This message was sent by an external party.</span><o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Can we confirm the requirement for disks per RG? I have 4 RG, but only 6 x 3TB NVMe drives per box.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Jul 29, 2019, at 1:34 PM, Luis Bolinches <<a href="mailto:luis.bolinches@fi.ibm.com"><span style="color:purple">luis.bolinches@fi.ibm.com</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi, from phone so sorry for typos. <span class="apple-converted-space"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I really think you should look into Spectrum Scale Erasure Code Edition (ECE) for this. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Sure you could do a RAID on each node as you mention here but that sounds like a lot of waste to me on storage capacity. Not to forget you get other goodies like end to end checksum and rapid rebuilds with ECE, among others. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Four servers is the minimum requirement for ECE (4+3p) and from top of my head 12 disk per RG, you are fine with both requirements. <br>
<br>
There is a presentation on ECE on the user group web page from London May 2019 were we talk about ECE. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">And the ibm page of the product <a href="https://www.ibm.com/support/knowledgecenter/STXKQY_ECE_5.0.3/com.ibm.spectrum.scale.ece.v5r03.doc/b1lece_intro.htm"><span style="color:purple">https://www.ibm.com/support/knowledgecenter/STXKQY_ECE_5.0.3/com.ibm.spectrum.scale.ece.v5r03.doc/b1lece_intro.htm</span></a><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">--<span class="apple-converted-space"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
El 29 jul 2019, a las 19:06, David Johnson <<a href="mailto:david_johnson@brown.edu"><span style="color:purple">david_johnson@brown.edu</span></a>> escribió:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">We are planning a 5.0.x upgrade onto new hardware to make use of the new 5.x GPFS features.<br>
The goal is to use up to four NSD nodes for metadata, each one with 6 NVMe drives (to be determined<br>
whether we use Intel VROC for raid 5 or raid 1, or just straight disks). <br>
<br>
So questions —<span class="apple-converted-space"> </span><br>
Has anyone done system pool on shared nothing cluster? How did you set it up?<br>
With default metadata replication set at 3, can you make use of four NSD nodes effectively?<br>
How would one design the location vectors and failure groups so that the system metadata is<br>
spread evenly across the four servers?<br>
<br>
Thanks,<br>
— ddj<br>
Dave Johnson<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at<span class="apple-converted-space"> </span><a href="http://spectrumscale.org/"><span style="color:purple">spectrumscale.org</span></a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><span style="color:purple">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Ellei edellä ole toisin mainittu: / Unless stated otherwise above:<br>
Oy IBM Finland Ab<br>
PL 265, 00101 Helsinki, Finland<br>
Business ID, Y-tunnus: 0195876-3<span class="apple-converted-space"> </span><br>
Registered in Finland<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at<span class="apple-converted-space"> </span><a href="http://spectrumscale.org/"><span style="color:purple">spectrumscale.org</span></a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><span style="color:purple">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</span></a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at<span class="apple-converted-space"> </span></span><a href="http://spectrumscale.org/"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">spectrumscale.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>