<div dir="ltr">You could also set <i style="color:rgb(0,0,0);white-space:pre-wrap">osd_crush_initial_weight = 0 . </i><span style="color:rgb(0,0,0);white-space:pre-wrap">New OSDs will automatically come up with a 0 weight and you won't have to race the clock.</span><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">-Brett</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 4, 2018 at 3:50 AM Janne Johansson <<a href="mailto:icepic.dz@gmail.com">icepic.dz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Den tors 4 okt. 2018 kl 00:09 skrev Bruno Carvalho <<a href="mailto:brunowcs@gmail.com" target="_blank">brunowcs@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Cephers, I would like to know how you are growing the cluster.<br>
Using dissimilar hardware in the same pool or creating a pool for each<br>
different hardware group.<br>
What problem would I have many problems using different hardware (CPU,<br>
memory, disk) in the same pool?</blockquote><div> </div><div>I don't think CPU and RAM (and other hw related things like HBA controller card brand) matters</div><div>a lot, more is always nicer, but as long as you don't add worse machines like Jonathan wrote you</div><div>should not see any degradation.</div><div><br></div><div>What you might want to look out for is if the new disks are very uneven compared to the old</div><div>setup, so if you used to have servers with 10x2TB drives and suddenly add one with 2x10TB,</div><div>things might become very unbalanced, since those differences will not be handled seamlessly</div><div>by the crush map.</div></div><div><br></div>Apart from that, the only issues for us is "add drives, quickly set crush reweight to 0.0 before<div>all existing OSD hosts shoot massive amounts of I/O on them, then script a slower raise of</div><div>crush weight upto what they should end up at", to lessen the impact for our 24/7 operations.</div><div><br></div><div>If you have weekends where noone accesses the cluster or night-time low-IO usage patterns,</div><div>just upping the weight at the right hour might suffice.<br clear="all"><div><br></div><div>Lastly, for ssd/nvme setups with good networking, this is almost moot, they converge so fast</div><div>its almost unfair. A real joy working with expanding flash-only pools/clusters.</div><div><br></div>-- <br><div dir="ltr" class="m_3259247718011509024gmail_signature" data-smartmail="gmail_signature">May the most significant bit of your life be positive.<br></div></div></div>
_______________________________________________<br>
ceph-users mailing list<br>
<a href="mailto:ceph-users@lists.ceph.com" target="_blank">ceph-users@lists.ceph.com</a><br>
<a href="http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com" rel="noreferrer" target="_blank">http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com</a><br>
</blockquote></div>