<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 4:47 AM Artem Russakovskii <<a href="mailto:archon810@gmail.com">archon810@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>We currently have an 8TB 4-brick replicated volume on our 4 servers, and are at 80% capacity. The max disk size on our host is 10TB. I'm starting to think about what happens closer to 100% and see 2 options.</div><div><br></div><div>Either we go with another new 4-brick replicated volume and start dealing with symlinks in our webapp to make sure it knows which volumes the data is on, which is a bit of a pain (but not too much) on the sysops side of things. Right now the whole volume mount is symlinked to a single location in the webapps (an uploads/ directory) and life is good. After such a split, I'd have to split uploads into yeardir symlinks, make sure future yeardir symlinks are created ahead of time and point to the right volume, etc).</div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div>The other direction would be converting the replicated volume to a distributed replicated one <a href="https://docs.gluster.org/en/latest/Administrator%20Guide/Setting%20Up%20Volumes/#creating-distributed-replicated-volumes" target="_blank">https://docs.gluster.org/en/latest/Administrator%20Guide/Setting%20Up%20Volumes/#creating-distributed-replicated-volumes</a>, but I'm a bit scared to do it with production data (even after testing, of course), and having never dealt with a distributed replicated volume.</div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>This is the idea behind calling gluster as a 'scale-out' storage, and we expect our users to not bothering change of application for scale-out operations. But you are right, such things are 'not' day-to-day activity. But rebalance has been tried over all these gluster versions, and a lot of fixes have gone in to stabilize the feature.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><ol><li>Is it possible to convert our existing volume on the fly by adding 4 bricks but keeping the replica count at 4? </li></ol></div></div></div></div></div></div></div></div></div></blockquote><div>Yes, technically possible. All you have to use is 'add-brick' CLI.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><ol><li>What happens if bricks 5-8 which contain the replicated volume #2 go down for whatever reason or can't meet their quorum, but the replicated volume #1 is still up? Does the whole main combined volume become unavailable or only a portion of it which has data residing on replicated volume #2?</li></ol></div></div></div></div></div></div></div></div></div></blockquote><div>Portion of it. This is similar situation as one of 2 subvols of DHT going down (without any replica). Volume will serve data from available nodes. But be warned that depending the hash of the file, file creations also may not work 50% of the time in that case.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><ol><li>Any other gotchas?</li></ol></div></div></div></div></div></div></div></div></div></blockquote><div>You have to do a minimum of `rebalance fix-layout` if you don't want to move data. But if you don't move data, if the current files may grow and consume storage in node (if its like logs or something). Else, it should be fine.</div><div><br></div><div>-Amar</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div>Thank you very much in advance.<br></div></div><div dir="ltr"><br>Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8px" target="_blank">APK Mirror</a><span style="font-size:12.8px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR<br></a><br></div></div></div></div></div></div></div></div></div>
________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/441850968" rel="noreferrer" target="_blank">https://bluejeans.com/441850968</a><br>
<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">--<div><a href="https://kadalu.io" target="_blank">https://kadalu.io</a></div><div>Container Storage made easy!</div><div><br></div></div></div></div>