2 physical servers to share resources and provide redundancy

[techprofessional1027]

Hello everyone. Currently I have a supermicro server and I am using proxmox as my main system. It is basically a VM server that I run my labs on (GNS3, EVE-NG, CML, Ubuntu, etc)

It works excellent for all my VMs.

Here the issue:

Currently it is a single point of failure. Recently a friend of mine gave me another server (a Dell Poweredge R430).

I thought, outstanding. Not only could it work as a backup server in case the supermicro goes down, but also the two servers can possibly share their resources.

Please forgive my ignorance. I am very new servers. My main specialty is routers and switches. But I wanted to find out if anyone on here knew how I could lump these two servers together to make it one proxmox server so I have more redundancy (similar concept to stacking switches) and the servers share their resources.

If there is a way to do this, does anyone know of a step by step process? Or does anyone know of any good sources (like YouTube, etc) I can turn to to help me carry out this process?

Obviously I know I would need to install proxmox on the Dell server as well. So that's a given, but how would I integrate them together to work as one server yet, still make it so one or the other server would take over, if one or the other went down?

Any help with resources I can turn to I would greatly appreciate. I always appreciate all the help I get from this forum.

 

[UdoB]

If there is a way to do this, does anyone know of a step by step process?

The concept you are searching for is called a "cluster". You can build one with two servers but you need a third leg (a Quorum Device) to stay in a stable condition when one of those two servers fails.

The installation process is described here:

• https://pve.proxmox.com/wiki/Cluster_Manager
• https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_pvecm

Have fun!

 

[techprofessional1027]

Thank you for the help. I think I found something that might work as a quorum device?

From what I read on reddit, it was recommended that Raspberry Pi is a good device to use as the quorum device. Again, please bear with my ignorance on this. I think this is what they are referring to, but I want to make sure before spending the money.

Here is the device I am seeing on amazon. Is this what they are referring to?

https://www.amazon.com/CanaKit-Rasp...words=raspberry+pi&qid=1734640646&sr=8-1&th=1

Thanks again.

 

[tcabernoch]

A Q-device has very low requirements. You could absolutely run it on a Pi.

Now, I don't want to suggest a non-optimal config ... but you know if you stand up two Proxmox servers and join them into a cluster ... well it just works. Yes, you do want an odd amount of cluster members to prevent quorum issues. But its gonna work even if you don't do that.

Proxmox cluster management can be quite a deep rabbit hole.
I see the Q-device as icing on the cake, to be applied after you have the rest figured out.
Give it a try. Figure out the Q-device as you go.

Read the Cluster_Manager link Udo posted! It's jammed full of vital info.

 

[UdoB]

Here is the device I am seeing on amazon. Is this what they are referring to?

Yes, that one is fine. Actually it is already "too much" if it is only serving as a Quorum Device. Any used/cheap Raspi 3/4/5 will do.

And yes, @tcabernoch is of course right - you can start building a cluster without such a thing. Nevertheless I do recommend establishing it early for two and a half reasons:

1) in any case you will encounter error conditions. With a QDev some errors just vanish. Without a QDev you need to seek information regarding "no quorum"-errors. If this happens when some services are already established and are considered "important!" (think Home Assistant or a streaming service or ...) this may lead to (avoidable) stress

2) if you (later on) want to test High-Availability you need to have Quorum - it is not optional

3) why not do it "right" from the beginning? In my opinion this is easier than learning what's not working and fighting an avoidable situation...


But yeah, ymmv

 

[Johannes S]

Yes, that one is fine. Actually it is already "too much" if it is only serving as a Quorum Device. Any used/cheap Raspi 3/4/5 will do.

Or used Mini-PC. Which would also have the benefit that it could be used as ProxmoxBackupServer (which is not possible with a Raspi due to ARM instead of X86 CPU). In both cases OP should be able to find something fitting for his usecase for under 50€ on Ebay or a dealer of refurbished hardware.

 

[tcabernoch]

Now, now.
If we are gonna go recommending the addition of a virtual object like a quorum device for "stability" or whatever ... um ... does it make sense to then say "you can run this on any old piece of junk"?
Well ... sure it does. Because the q-device is optional until late in the game. I don't see too much posturing here, but there's just a bit going on ...

Here's my two cents. Run it as a guest of one of the hosts.
Presto. That one always gets 2 votes. No more quorum ties.
No more hardware. And it breaks the same rules as running it on a piece of junk, so why not?

 

[Johannes S]

Now, now.
If we are gonna go recommending the addition of a virtual object like a quorum device for "stability" or whatever ... um ... does it make sense to then say "you can run this on any old piece of junk"?

Yes because the point it to provide an additional vote, you don't need enterprise-ready hardware for that, especially in a homelab. Thus running it as a vm or changing expected votes to a not-recommended value would miss the point.

 

[UdoB]

If we are gonna go recommending the addition of a virtual object like a quorum device for "stability" or whatever ... um ... does it make sense to then say "you can run this on any old piece of junk"?

Old hardware may be absolutely capable or running stable and the performance is completely enough for this specific task.

(My alternate recommendation would be to run a VM or a Container on a NAS. But I do not see OP has such a thing.)

Run it as a guest of one of the hosts.

Are you trolling me? I won't start a discussion on this one, it has been discussed several times --> a QDev must be independent from the two Nodes!

I will stop here. There is more than one way to skin a cat...

 

[tcabernoch]

No Udo, I'm not trolling you, or at least no more you than the entire forum.
My point is that one unreliable method is essentially equivalent to another, in that they both fail.

But I'll reveal this uncomfortable truth ... I have a production system with an even-numbered member count.
I've learned how to manage the cluster.
I certainly don't recommend anybody follow my example, but your first quorum failure looks like a disaster.
The second one is more of just a PITA.
And the third? Well, you should have some scripts ready by that point. I do.

(And for anybody following my awful example, physically redundant cluster node links and dedicated migration (vmotion) subnet/VLAN helps a lot.)

 

[Johannes S]

No Udo, I'm not trolling you, or at least no more you than the entire forum.
My point is that one unreliable method is essentially equivalent to another, in that they both fail.

I beg to differ. Adding on unreliable device as qdevice least reduces the propability a little bit more than just adding a qdevice-VM.

 

[UdoB]

No Udo, I'm not trolling you,

Thanks.
Probably I should not have written that sentence.

I have a production system with an even-numbered member count.
...
... but your first quorum failure looks like a disaster.
The second one is more of just a PITA.
And the third? Well, you should have some scripts ready by that point. I do.

Yeah, experience can only get gathered by actually handling problematic situations.

In my understanding the QDev is really important in two node setups. If you have -let's say- six nodes then the seventh vote from a QDev is not so relevant anymore. (With six nodes two may fail while keeping 4 up --> still quorate.)

Unfortunately there are three factors hindering the creation of the optimal cluster: Money, Money, Money... https:// yewtu.be/watch?v=Zqcf1r1zBxc