So now that I have my cluster on 3.7.14 and sharded and working I am of course looking for what to break next. Currently each of 3 nodes is on a 6 disk (WD Red 1TB) raidz6 (zil on mirrored ssd), which I am thinking is more protection than I may need with a 3 way replica. I was going to one by one change them to basically raid10 letting it heal in between. Is best way to do that a systemctl stop glusterd, should I just kill the brick process to simulate a brick dying, or is their an actual brick maintenance command? If /etc/glusterfs is unchanged and /var/lib/glusterd is unchanged will doing a heal full after reboot or restarting glusterd take care of everything if I recreate the expected brick path first? Are the improvements in 3.8 for sharding significant enough I should first look at updating to 3.8.2 when released in few days? *David Gossage* *Carousel Checks Inc. | System Administrator* *Office* 708.613.2284 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160808/42ced51f/attachment.html>
On 9/08/2016 6:39 AM, David Gossage wrote:> Currently each of 3 nodes is on a 6 disk (WD Red 1TB) raidz6 (zil on > mirrored ssd), which I am thinking is more protection than I may need > with a 3 way replica. I was going to one by one change them to > basically raid10 letting it heal in between.Wouldn't RAID10 be more protection than Raidz6? not that there is anything wrong with that, all my bricks are on top of a RAIDZ10 pool, as much for the improved IOPS as the redundancy, though it does ease the maintance of bricks quite a bit. Have had two drive failures where I just hotswapped the drive, 0 downtime. As a matter of curiosity what SSD's are you using for the ZIL and what size are they? Do you have compression enabled? lz4?> > Is best way to do that a systemctl stop glusterd, should I just kill > the brick process to simulate a brick dying, or is their an actual > brick maintenance command?There is a gluster replace brick command: volume replace-brick <VOLNAME> <SOURCE-BRICK> <NEW-BRICK> {commit force} One annoyance is the new brick mount can't be the same as the old one. If you can I'd setup a test volume and try it out first. -- Lindsay Mathieson
On 08/08/2016 01:39 PM, David Gossage wrote:> So now that I have my cluster on 3.7.14 and sharded and working I am > of course looking for what to break next. > > Currently each of 3 nodes is on a 6 disk (WD Red 1TB) raidz6 (zil on > mirrored ssd), which I am thinking is more protection than I may need > with a 3 way replica. I was going to one by one change them to > basically raid10 letting it heal in between. > > Is best way to do that a systemctl stop glusterd, should I just kill > the brick process to simulate a brick dying, or is their an actual > brick maintenance command?Just kill (-15) the brick process. That'll close the TCP connections and the clients will just go right on functioning off the remaining replica. When you format and recreate your filesystem, it'll be missing the volume-id extended attributes so to start it you'll need to force it: gluster volume start $volname start force> > If /etc/glusterfs is unchanged and /var/lib/glusterd is unchanged will > doing a heal full after reboot or restarting glusterd take care of > everything if I recreate the expected brick path first?Once started, perform a full heal to re-replicate.> > Are the improvements in 3.8 for sharding significant enough I should > first look at updating to 3.8.2 when released in few days?Yes.> > > */David Gossage/*/* > */ > //*Carousel Checks Inc.| System Administrator* > *Office*708.613.2284 > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160808/08fd000a/attachment.html>