I have a three node cluster set up with HA and working great. I'd like to add a fourth node to the cluster to consolidate management and to allow easy VM migration, but without affecting quorum. Meaning: the three nodes and the fourth node would not wait for the other to boot before operating normally. The three original nodes would still vote for themselves, not affecting the fourth node. Is such a configuration possible?
Adding a node to a cluster without affecting quorum
- Thread starter Masterjuggler
- Start date
Of course the correct approach is: add your fourth node. Now you need three nodes to be active to quorate. Then add a "Quorum Device" (as often mentioned here). The resulting cluster has five votes - and it needs three to be okay.
Now you can shutdown the fourth node and one of the original three nodes may die and you still have quorum, thanks to the QDev.
This is the recommended way. Everything else is a hack. For example my Homelab implements this approach:
Give your three main nodes two votes instead of one. Add your fourth node with one vote. No QDev!
Now you have 2+2+2+1 = 7 votes. As long as two of the "old" nodes are alive there is 2+2=4 --> Quorum reached
This does not answer your question on the point, if I understand it correctly. But from my point of view this is the best option you have. Only two machines (of the basic three) need to start up successfully to "activate" the cluster. And when the fourth starts it is integrated seamlessly.
Best regards
Now you can shutdown the fourth node and one of the original three nodes may die and you still have quorum, thanks to the QDev.
This is the recommended way. Everything else is a hack. For example my Homelab implements this approach:
Give your three main nodes two votes instead of one. Add your fourth node with one vote. No QDev!
Now you have 2+2+2+1 = 7 votes. As long as two of the "old" nodes are alive there is 2+2=4 --> Quorum reached
This does not answer your question on the point, if I understand it correctly. But from my point of view this is the best option you have. Only two machines (of the basic three) need to start up successfully to "activate" the cluster. And when the fourth starts it is integrated seamlessly.
Best regards
Thanks for the thought out response!
Yes, I fully understand the correct approach to a system working in the intended fashion lol. This is also a homelab and no one is relying on it but me, so off the beaten path hacks are interesting if for no reason other than to have tried it.
Giving each of the original three nodes two votes is a pretty simple approach, though you are correct that it doesn't achieve allowing the fourth node to activate by itself without the og three up.
At the core of this, my main goal is to have the ability to easily migrate between the og three and the fourth node without affecting their current quorum. I've seen the experimental remote-migrate feature which I'll have to try. That would mostly solve this except for it not being a ui element right in front of you like the regular migration feature, so it's somewhat more clunky to use until it's integrated.
Yes, I fully understand the correct approach to a system working in the intended fashion lol. This is also a homelab and no one is relying on it but me, so off the beaten path hacks are interesting if for no reason other than to have tried it.
Giving each of the original three nodes two votes is a pretty simple approach, though you are correct that it doesn't achieve allowing the fourth node to activate by itself without the og three up.
At the core of this, my main goal is to have the ability to easily migrate between the og three and the fourth node without affecting their current quorum. I've seen the experimental remote-migrate feature which I'll have to try. That would mostly solve this except for it not being a ui element right in front of you like the regular migration feature, so it's somewhat more clunky to use until it's integrated.
In my model and in "an emergency", without the main three nodes being available there is always the "pvecm expected x" way to make it work. This command simply lies to the fourth node to make it "believe" Quorum is reached.
In an active cluster environment this is considered dangerous - but an admin of course always knows what he does ;-)
As so often: there is more than one way to reach a specific goal - and that's great!
Oh, pvecm expected makes sense in a pinch to get the fourth node running.
I'll have to bring up four PVE nodes in VMs and play around with various configurations and situations to see how they'd behave. Perhaps there's a way to set the og three with two votes each as you mentioned and automate running pvecm expected on the fourth node when quorum is broken. My understanding is when all nodes are brought back up, pvce expected is then overwritten. I'll have to test this of course.
Essentially what I have going on is a cluster of three mini PCs running various services in HA, and a fourth node with high memory and storage running a NAS VM. Both are taken down relatively often to tinker with them, so the idea is to migrate all VMs during this time for low downtime.
I'll have to bring up four PVE nodes in VMs and play around with various configurations and situations to see how they'd behave. Perhaps there's a way to set the og three with two votes each as you mentioned and automate running pvecm expected on the fourth node when quorum is broken. My understanding is when all nodes are brought back up, pvce expected is then overwritten. I'll have to test this of course.
Essentially what I have going on is a cluster of three mini PCs running various services in HA, and a fourth node with high memory and storage running a NAS VM. Both are taken down relatively often to tinker with them, so the idea is to migrate all VMs during this time for low downtime.
Last edited: