<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Marc,
<div class=""><br class="">
</div>
<div class="">But the limitation on GPFS replication is that I can set replication separately for metadata and data, but no matter whether I have one data pool or ten data pools they all must have the same replication, correct?</div>
<div class=""><br class="">
</div>
<div class="">And believe me I *love* GPFS replication \u2026 I would hope / imagine that I am one of the few people on this mailing list who has actually gotten to experience a \u201cfire scenario\u201d \u2026 electrical fire, chemical suppressant did it\u2019s thing, and everything
in the data center had a nice layer of soot, ash, and chemical suppressant on and in it and therefore had to be professionally cleaned. Insurance bought us enough disk space that we could (temporarily) turn on GPFS data replication and clean storage arrays
one at a time!</div>
<div class=""><br class="">
</div>
<div class="">But in my current hypothetical scenario I\u2019m stretching the budget just to get that one storage array with 12 x 1.8 TB SSD\u2019s in it. Two are out of the question.</div>
<div class=""><br class="">
</div>
<div class="">My current metadata that I\u2019ve got on SSDs is on RAID 1 mirrors and has GPFS replication set to 2. I thought the multiple RAID 1 mirrors approach was the way to go for SSDs for data as well, as opposed to one big RAID 6 LUN, but wanted to get
the advice of those more knowledgeable than me.</div>
<div class=""><br class="">
</div>
<div class="">Thanks!</div>
<div class=""><br class="">
</div>
<div class="">Kevin</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 19, 2017, at 3:49 PM, Marc A Kaplan <<a href="mailto:makaplan@us.ibm.com" class="">makaplan@us.ibm.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><font size="2" face="sans-serif" class="">As I've mentioned before, RAID choices for GPFS are not so simple. Here are a couple points to consider, I'm sure there's more. And if I'm wrong, someone will please correct me - but I believe the
two biggest pitfalls are:</font><br class="">
<ul class="">
<li class=""><font size="2" face="sans-serif" class="">Some RAID configurations (classically 5 and 6) work best with large, full block writes. When the file system does a partial block write, RAID may have to read a full "stripe" from several devices, compute
the differences and then write back the modified data to several devices. This is certainly true with RAID that is configured over several storage devices, with error correcting codes. SO, you do NOT want to put GPFS metadata (system pool!) on RAID configured
with large stripes and error correction. This is the Read-Modify-Write Raid pitfall.<br class="">
</font></li><li class=""><font size="2" face="sans-serif" class="">GPFS has built-in replication features - consider using those instead of RAID replication (classically Raid-1). GPFS replication can work with storage devices that are in different racks, separated by
significant physical space, and from different manufacturers. This can be more robust than RAID in a single box or single rack. Consider a fire scenario, or exploding power supply or similar physical disaster. Consider that storage devices and controllers
from the same manufacturer may have the same bugs, defects, failures. <br class="">
<br class="">
</font></li></ul>
<br class="">
_______________________________________________<br class="">
gpfsug-discuss mailing list<br class="">
gpfsug-discuss at <a href="http://spectrumscale.org" class="">spectrumscale.org</a><br class="">
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" class="">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<br class="">
<div class="">
<div class="">\u2014</div>
<div class="">Kevin Buterbaugh - Senior System Administrator</div>
<div class="">Vanderbilt University - Advanced Computing Center for Research and Education</div>
<div class=""><a href="mailto:Kevin.Buterbaugh@vanderbilt.edu" class="">Kevin.Buterbaugh@vanderbilt.edu</a> - (615)875-9633</div>
<div class=""><br class="">
</div>
<br class="Apple-interchange-newline">
</div>
<br class="">
</body>
</html>