<html><body><p><font size="2">Hi<br></font><font size="2"><br></font><font size="2">You can enable QoS first to see the activity while on inf value to see the current values of usage and set the li is later on. Those limits are modificable online so even in case you have (not your case it seems) less activity times those can be increased for replication then and Lowe again on peak times. <br></font><font size="2"><br></font><font size="2">—<br></font><font size="2">SENT FROM MOBILE DEVICE<br></font><font size="2">Ystävällisin terveisin / Kind regards / Saludos cordiales / Salutations<br></font><font size="2">Luis Bolinches<br></font><font size="2">Consultant IT Specialist<br></font><font size="2">Mobile Phone: +358503112585<br></font><font size="2"><a href="https://www.youracclaim.com/user/luis-bolinches">https://www.youracclaim.com/user/luis-bolinches</a><br></font><font size="2"><br></font><font size="2">"If you always give you will always have" -- Anonymous<br></font><font size="2"><br></font><font size="2">> On 21 Aug 2018, at 1.21, david_johnson@brown.edu wrote:<br></font><font size="2">> <br></font><font size="2">> Yes the arrays are in different buildings. We want to spread the activity over more servers if possible but recognize the extra load that rebalancing would entail. The system is busy all the time. <br></font><font size="2">> <br></font><font size="2">> I have considered using QOS when we run policy migrations but haven’t yet because I don’t know what value to allow for throttling IOPS. We need to do weekly migrations off of 15k rpm pool onto 7.2k rpm pool, and previously I’ve just let it run at native speed. I’d like to know what other folks have used for QOS settings. <br></font><font size="2">> <br></font><font size="2">> I think we may leave things alone for now regarding the original question, rebalancing this pool. <br></font><font size="2">> <br></font><font size="2">> -- ddj<br></font><font size="2">> Dave Johnson<br></font><font size="2">> <br></font><font size="2">>> On Aug 20, 2018, at 6:08 PM, valdis.kletnieks@vt.edu wrote:<br></font><font size="2">>> <br></font><font size="2">>> On Mon, 20 Aug 2018 14:02:05 -0400, "Frederick Stock" said:<br></font><font size="2">>> <br></font><font size="2">>>> Note you have two additional NSDs in the 33 failure group than you do in<br></font><font size="2">>>> the 23 failure group. You may want to change one of those NSDs in failure<br></font><font size="2">>>> group 33 to be in failure group 23 so you have equal storage space in both<br></font><font size="2">>>> failure groups.<br></font><font size="2">>> <br></font><font size="2">>> Keep in mind that the failure groups should be built up based on single points of failure.<br></font><font size="2">>> In other words, a failure group should consist of disks that will all stay up or all go down on<br></font><font size="2">>> the same failure (controller, network, whatever).<br></font><font size="2">>> <br></font><font size="2">>> Looking at the fact that you have 6 disks named 'dNN_george_33' and 8 named 'dNN_cit_33',<br></font><font size="2">>> it sounds very likely that they are in two different storage arrays, and you should make your<br></font><font size="2">>> failure groups so they don't span a storage array. In other words, taking a 'cit' disk<br></font><font size="2">>> and moving it into a 'george' failure group will Do The Wrong Thing, because if you do<br></font><font size="2">>> data replication, one copy can go onto a 'george' disk, and the other onto a 'cit' disk<br></font><font size="2">>> that's in the same array as the 'george' disk. If 'george' fails, you lose access to both<br></font><font size="2">>> replicas.<br></font><font size="2">>> _______________________________________________<br></font><font size="2">>> gpfsug-discuss mailing list<br></font><font size="2">>> gpfsug-discuss at spectrumscale.org<br></font><font size="2">>> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br></font><font size="2">> _______________________________________________<br></font><font size="2">> gpfsug-discuss mailing list<br></font><font size="2">> gpfsug-discuss at spectrumscale.org<br></font><font size="2">> <a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br></font><font size="2">> <br></font><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 <BR>
Registered in Finland<BR>
<BR>
</body></html>