Odd number of nodes -> prevent split brain situations. For example imagine that vh1-4 see each other but don't see vh5-8. Same happens to vh5-8 -> they don't see vh1-4.<div>How should the cluster react ? It has to pick a partition that should work and usually for a partitiont to work we need 50%+ 1 node.</div><div>In your case you don't need a Hypervisor to be part of the Gluster TSP, so vh5-8 are not needed.</div><div><br></div><div>You need all nodes to be up in order to make changes in the volume (like shrinking/adding bricks, setting options), so it is a best practice to bring vh5 up or remove it forcefully.</div><div><br></div><div>If you have redhat developer account (which is free), you can take a look at <a id="linkextractor__1646631754320" data-yahoo-extracted-link="true" href="https://access.redhat.com/articles/1433123" class="lEnhancr_1646631755149">https://access.redhat.com/articles/1433123</a></div><div><br></div><div>Also, it's worth mentioning that you are not using the 'virt' volume group of settings which is optimized for VMs and live migration of VMs between the nodes.Take a look at it:  /var/lib/glusterd/groups/virt and consider setting it. Some oVirt users report that using libgfapi brings better performance, so consider that too .</div><div><br></div><div>WATNING: The virt group enables sharding and once this option is enabled , you should never disable it !</div><div><br></div><div> Best Regards,</div><div>Strahil Nikolov<br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Sun, Mar 6, 2022 at 23:31, Todd Pfaff</div><div><pfaff@rhpcs.mcmaster.ca> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> On Sun, 6 Mar 2022, Strahil Nikolov wrote:<br clear="none"><br clear="none">> It seems that only vh1-4 provide bricks, so vh5,6,7,8 can be removed.<br clear="none"><br clear="none"><br clear="none">Right, that was the point of my question: how to properly shutdown any one <br clear="none">of vh1-4 for maintenance without disrupting any VMs that may be running on <br clear="none">any of vh1-8.<br clear="none"><br clear="none">When I had done a test of taking vh1 offline several days ago, all of the <br clear="none">VMs on vh4 went root-fs-read-only, which suprised me.  I suppose it's <br clear="none">possible that there was something else at play that I haven't realized, <br clear="none">and that taking the vh1 gluster peer offline was not the root cause of the <br clear="none">vh4 VM failure.  I haven't yet tried another such test yet - I was holding <br clear="none">off until I'd gotten some advice here first.<br clear="none"><br clear="none"><br clear="none">> First check why vh5 is offline. Changes to all modes are propagated and in<br clear="none">> this case vh5 is down and won't receive the peer detach commands.<br clear="none"><br clear="none"><br clear="none">Ok, interesting, but I have to admit that I don't understand that <br clear="none">requirement.  I knew that vh5 was offline but I didn't know that I'd have <br clear="none">to bring it back online in order to properly shutdown one of vh1-4.  Are <br clear="none">you certain about that?  That is, if vh5 stays offline and I take vh4 <br clear="none">offline, and then I bring vh5 online, will the quorum of peers not set vh5 <br clear="none">straight?<br clear="none"><br clear="none"><br clear="none">> <br clear="none">> Once you fix vh5, you can safely 'gluster peer detach' any of the nodes that<br clear="none">> is not in the volume.<br clear="none"><br clear="none"><br clear="none">Ok, I'll try peer detach to take any of vh1-4 offline in a controlled <br clear="none">manner.<br clear="none"><br clear="none">I take this to mean that if any one of the vh1-4 replica members were to <br clear="none">go offline in a uncontrolled manner, gluster peers may have a problem <br clear="none">which could lead to the sort of VM behaviour that I experienced.  Frankly <br clear="none">this suprises me - I expected that my setup was more resilient in the face <br clear="none">of losing gluster replica members as long as there was still a quorum of <br clear="none">members operating normally.<br clear="none"><br clear="none"><br clear="none">> <br clear="none">> Keep in mind that it's always best practice to have odd number of nodes in<br clear="none">> the TSP (3,5,7,9,etc).<br clear="none"><br clear="none"><br clear="none">Do you know why that's the case?  I understand that 3 or more are <br clear="none">recommended (could be 2 and a arbiter) but why an odd number?  What <br clear="none">benefit does 3 provide that 4 does not?<br clear="none"><br clear="none">Thanks,<br clear="none">Todd<div class="yqt5934426548" id="yqtfd21636"><br clear="none"><br clear="none"><br clear="none">> <br clear="none">> Best Regards,<br clear="none">> Strahil Nikolov<br clear="none">><br clear="none">>       On Sun, Mar 6, 2022 at 4:06, Todd Pfaff<br clear="none">> <<a shape="rect" ymailto="mailto:pfaff@rhpcs.mcmaster.ca" href="mailto:pfaff@rhpcs.mcmaster.ca">pfaff@rhpcs.mcmaster.ca</a>> wrote:<br clear="none">> [<a shape="rect" ymailto="mailto:root@vh1" href="mailto:root@vh1">root@vh1</a> ~]# gluster volume info vol1<br clear="none">> <br clear="none">> Volume Name: vol1<br clear="none">> Type: Replicate<br clear="none">> Volume ID: dfd681bb-5b68-4831-9863-e13f9f027620<br clear="none">> Status: Started<br clear="none">> Snapshot Count: 0<br clear="none">> Number of Bricks: 1 x 4 = 4<br clear="none">> Transport-type: tcp<br clear="none">> Bricks:<br clear="none">> Brick1: vh1:/pool/gluster/brick1/data<br clear="none">> Brick2: vh2:/pool/gluster/brick1/data<br clear="none">> Brick3: vh3:/pool/gluster/brick1/data<br clear="none">> Brick4: vh4:/pool/gluster/brick1/data<br clear="none">> Options Reconfigured:<br clear="none">> transport.address-family: inet<br clear="none">> nfs.disable: on<br clear="none">> performance.client-io-threads: off<br clear="none">> <br clear="none">> <br clear="none">> [<a shape="rect" ymailto="mailto:root@vh1" href="mailto:root@vh1">root@vh1</a> ~]# gluster pool list<br clear="none">> UUID                                    Hostname        State<br clear="none">> 75fc4258-fabd-47c9-8198-bbe6e6a906fb    vh2            Connected<br clear="none">> 00697e28-96c0-4534-a314-e878070b653d    vh3            Connected<br clear="none">> 2a9b891b-35d0-496c-bb06-f5dab4feb6bf    vh4            Connected<br clear="none">> 8ba6fb80-3b13-4379-94cf-22662cbb48a2    vh5            Disconnected<br clear="none">> 1298d334-3500-4b40-a8bd-cc781f7349d0    vh6            Connected<br clear="none">> 79a533ac-3d89-44b9-b0ce-823cfec8cf75    vh7            Connected<br clear="none">> 4141cd74-9c13-404c-a02c-f553fa19bc22    vh8            Connected<br clear="none">> <br clear="none">> <br clear="none">> On Sat, 5 Mar 2022, Strahil Nikolov wrote:<br clear="none">> <br clear="none">> > Hey Todd,<br clear="none">> ><br clear="none">> > can you provide 'gluster volume info <VOLUME>' ?<br clear="none">> ><br clear="none">> > Best Regards,<br clear="none">> > Strahil Nikolov<br clear="none">> ><br clear="none">> >      On Sat, Mar 5, 2022 at 18:17, Todd Pfaff<br clear="none">> > <<a shape="rect" ymailto="mailto:pfaff@rhpcs.mcmaster.ca" href="mailto:pfaff@rhpcs.mcmaster.ca">pfaff@rhpcs.mcmaster.ca</a>> wrote:<br clear="none">> > I have a replica volume created as:<br clear="none">> ><br clear="none">> > gluster volume create vol1 replica 4 \<br clear="none">> >   host{1,2,3,4}:/mnt/gluster/brick1/data \<br clear="none">> >   force<br clear="none">> ><br clear="none">> ><br clear="none">> > All hosts host{1,2,3,4} mount this volume as:<br clear="none">> ><br clear="none">> > localhost:/vol1 /mnt/gluster/vol1 glusterfs defaults<br clear="none">> ><br clear="none">> ><br clear="none">> > Some other hosts are trusted peers but do not contribute bricks, and<br clear="none">> > they<br clear="none">> > also mount vol1 in the same way:<br clear="none">> ><br clear="none">> > localhost:/vol1 /mnt/gluster/vol1 glusterfs defaults<br clear="none">> ><br clear="none">> ><br clear="none">> > All hosts run CentOS 7.9, and all are running glusterfs 9.4 or 9.5<br clear="none">> from<br clear="none">> > centos-release-gluster9-1.0-1.el7.noarch.<br clear="none">> ><br clear="none">> ><br clear="none">> > All hosts run kvm guests that use qcow2 files for root filesystems<br clear="none">> that<br clear="none">> > are stored on gluster volume vol1.<br clear="none">> ><br clear="none">> ><br clear="none">> > This is all working well, as long as none of host{1,2,3,4} go<br clear="none">> offline.<br clear="none">> ><br clear="none">> ><br clear="none">> > I want to take one of host{1,2,3,4} offline temporarily for<br clear="none">> > maintenance.<br clear="none">> > I'll refer to this as hostX.<br clear="none">> ><br clear="none">> > I understand that hostX will need to be healed when it comes back<br clear="none">> > online.<br clear="none">> ><br clear="none">> > I would, of course, migrate guests from hostX to another host, in<br clear="none">> which<br clear="none">> > case hostX would then only be participating as a gluster replica<br clear="none">> brick<br clear="none">> > provider and serving gluster client requests.<br clear="none">> ><br clear="none">> > What I've experienced is that if I take one of host{1,2,3,4} offline,<br clear="none">> > this<br clear="none">> > can disrupt some of the VM guests on various other hosts such that<br clear="none">> > their<br clear="none">> > root filesystems go to read-only.<br clear="none">> ><br clear="none">> > What I'm looking for here are suggestions as to how to properly take<br clear="none">> > one<br clear="none">> > of host{1,2,3,4} offline to avoid such disruption or how to tune the<br clear="none">> > libvirt kvm hosts and guests to be sufficiently resilient in the face<br clear="none">> > of<br clear="none">> > taking one gluster replica node offline.<br clear="none">> ><br clear="none">> > Thanks,<br clear="none">> > Todd<br clear="none">> > ________<br clear="none">> ><br clear="none">> ><br clear="none">> ><br clear="none">> > Community Meeting Calendar:<br clear="none">> ><br clear="none">> > Schedule -<br clear="none">> > Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC<br clear="none">> > Bridge: <a shape="rect" href="https://meet.google.com/cpu-eiue-hvk" target="_blank">https://meet.google.com/cpu-eiue-hvk</a><br clear="none">> > Gluster-users mailing list<br clear="none">> > <a shape="rect" ymailto="mailto:Gluster-users@gluster.org" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br clear="none">> > <a shape="rect" href="https://lists.gluster.org/mailman/listinfo/gluster-users" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a><br clear="none">> ><br clear="none">> ><br clear="none">> ><br clear="none">> <br clear="none">> <br clear="none">><br clear="none"></div> </div> </blockquote></div>