2 Node HA Cluster
- Thread starter Dexter23
- Start date
The sImple answer is no. No matter which way you spin it, the qdevice needs to be running outside the cluster to give the remaining node more than 50% of the votes.
adding on top of Aaron's concise answer: Note that a QDevice has less requirements than a full blown PVE node, e.g., it doesn't necessarily needs to be in the same LAN (less latency sensitive) and it can run on other Linux distros that provide a package, e.g., Debian, some here use a Raspberry Pi to provide the QDevice service to a PVE cluster with success. I mean, if you can I'd go for the third node, as that also helps a lot in balancing the HA services from a failed one but if you just cannot have that in the setup planned, a QDevice on an external host is the next best you can do.
What I maintain personally, are 2 powerful AMD EPYC nodes that run the infrastructure. The 3rd server is far less powerful in terms of CPU and memory and is using cheaper but quite a bit larger SSDs to be used as PBS for that 2-node cluster and also to remote sync another small PVE / PBS combo on the other side of the country.
On that 3rd machine I installed PVE first and PBS on top. PBS is the main functionality for that machine. On the PVE side, for now, the only guest is the qdevice container. That PBS server is there anyway, and using PVE on that one as well helps to keep using the tools I already know well.
Depending on your situation, you might have something else that can be used, like the NAS that you mentioned. As long as the machine on which the qdevice is running, is not running on the cluster that you want to use it with, you should be fine. Just try to keep it as simple as possible as a complicated setup has a higher chance to fail or not work in a certain failure scenario that you did not foresee
On that 3rd machine I installed PVE first and PBS on top. PBS is the main functionality for that machine. On the PVE side, for now, the only guest is the qdevice container. That PBS server is there anyway, and using PVE on that one as well helps to keep using the tools I already know well.
Depending on your situation, you might have something else that can be used, like the NAS that you mentioned. As long as the machine on which the qdevice is running, is not running on the cluster that you want to use it with, you should be fine. Just try to keep it as simple as possible as a complicated setup has a higher chance to fail or not work in a certain failure scenario that you did not foresee
There are a few things to consider, and you will have to decide what works best in your situation.
Do you plan to use a PBS? Then you can think about using my approach. If you install PVE and PBS on the same machine, I would not add the PVE installation to the cluster, but keep it separate and use the QDevice as an additional vote. Keeping things simple and fairly separated.
If you have no need for a PBS, then it comes down to a few other thins to consider.
If you add a 3rd full PVE installation to the cluster with hardware that is not similar to the other 2 nodes, you will have to make sure to not migrate VMs to that node. This is also important if you use HA. Depending on how you have your storages configured, you will also have to handle the 3rd node accordingly.
For example, if the 2 nodes are using ZFS with VM replication, the 3rd node will most likely not have the VM storage available since it does not have the necessary hardware for it.
If all you require is the QDevice, then I would first start looking into already available infrastructure. If the NAS can run VMs or containers, that would be my first try, as a bare OS installation with the `corosync-qnetd` service is enough for that.
So all in all, you have a few options, depending on your needs. I would recommend keeping it as simple as possible.
Do you plan to use a PBS? Then you can think about using my approach. If you install PVE and PBS on the same machine, I would not add the PVE installation to the cluster, but keep it separate and use the QDevice as an additional vote. Keeping things simple and fairly separated.
If you have no need for a PBS, then it comes down to a few other thins to consider.
If you add a 3rd full PVE installation to the cluster with hardware that is not similar to the other 2 nodes, you will have to make sure to not migrate VMs to that node. This is also important if you use HA. Depending on how you have your storages configured, you will also have to handle the 3rd node accordingly.
For example, if the 2 nodes are using ZFS with VM replication, the 3rd node will most likely not have the VM storage available since it does not have the necessary hardware for it.
If all you require is the QDevice, then I would first start looking into already available infrastructure. If the NAS can run VMs or containers, that would be my first try, as a bare OS installation with the `corosync-qnetd` service is enough for that.
So all in all, you have a few options, depending on your needs. I would recommend keeping it as simple as possible.
If it is not powerful enough to actually host VMs and the needed storage, I would keep it out of the PVE cluster. This avoids some issues (for example migrating a VM to it by accident) but with the QDevice you can still have that 3rd vote.
This will work, but depending on how many backups you have, how large they are and how many clients need to access it at the same time (backing up, restoring, maintenance tasks like garbage collection or verification), it might be a bit on the slow side.
We recommend fast (SSD) local storage.
Something to keep in mind, should the performance not be what you want it to