Mir fehlt in deinen Setup wie du das Netzwerk aufgebaut hat. Ein Cluster braucht mindestens ein dezidiertes Netzwerk für die Cluster-Kommunikation:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network
Das braucht nicht viel Bandbreite haben (1Gbit ist absolut ausreichend, solange die Zahl der Knoten unter 20 ist), aber wichtig ist es, weil Corosync (der Cluster-Mechanismus) empfindlich auf Latenzen reagiert. Zusätzlich sollte das normale Netzwerk (also dass was man für den Zugriff aufs Webinterface, die VMs/Container und von den Knoten auf die NAS verwendet) als Ausfallnetz konfiguriert werden. In einer Umgebung außerhalb des Homelabs würde es sich außerdem auch anbieten, das Netzwerk für den Zugriff auf das NAS in ein eigenes Netz zu packen (und das wiederum als Fallback für corosync)
Wenn du drei Nodes hast, brauchst du kein Quorum Device! Mir ist gerade nicht ganz klar, ob das QDev in dem Fall "von alleine" den Mund hält, oder ob es hier zu "vier Votes" führt. Du willst jedenfalls immer eine ungerade Gesamtzahl Stimmen ("votes") haben, damit eine Abstimmung immer eine Mehrheit hat. Bei gerader Anzahl (4 votes) ist jedoch 50:50 möglich --> keine Mehrheit.
Exakt, steht auch in der Doku:
We support QDevices for clusters with an even number of nodes and recommend it for 2 node clusters, if they should provide higher availability. For clusters with an odd node count, we currently discourage the use of QDevices. The reason for this is the difference in the votes which the QDevice provides for each cluster type. Even numbered clusters get a single additional vote, which only increases availability, because if the QDevice itself fails, you are in the same position as with no QDevice at all.
On the other hand, with an odd numbered cluster size, the QDevice provides (N-1) votes — where N corresponds to the cluster node count. This alternative behavior makes sense; if it had only one additional vote, the cluster could get into a split-brain situation. This algorithm allows for all nodes but one (and naturally the QDevice itself) to fail. However, there are two drawbacks to this:
If the QNet daemon itself fails, no other node may fail or the cluster immediately loses quorum. For example, in a cluster with 15 nodes, 7 could fail before the cluster becomes inquorate. But, if a QDevice is configured here and it itself fails, no single node of the 15 may fail. The QDevice acts almost as a single point of failure in this case.
The fact that all but one node plus QDevice may fail sounds promising at first, but this may result in a mass recovery of HA services, which could overload the single remaining node. Furthermore, a Ceph server will stop providing services if only ((N-1)/2) nodes or less remain online.
If you understand the drawbacks and implications, you can decide yourself if you want to use this technology in an odd numbered cluster setup
https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support
Es ist also wie du gesagt hast: Sofern man mindestens drei Knoten und ingesamt eine ungerade Anzahl hat, das qdevice besser weglassen, das macht nur Ärger
Und tatsächlich glaube ich, dass genau dass das Problem von Hans Renz zusammen mit dem Fencing vom HA-Modus ist:
On node failures, fencing ensures that the erroneous node is guaranteed to be offline. This is required to make sure that no resource runs twice when it gets recovered on another node. This is a really important task, because without this, it would not be possible to recover a resource on another node.
If a node did not get fenced, it would be in an unknown state where it may have still access to shared resources. This is really dangerous! Imagine that every network but the storage one broke. Now, while not reachable from the public network, the VM still runs and writes to the shared storage.
If we then simply start up this VM on another node, we would get a dangerous race condition, because we write from both nodes. Such conditions can destroy all VM data and the whole VM could be rendered unusable. The recovery could also fail if the storage protects against multiple mounts.
https://pve.proxmox.com/wiki/High_Availability#ha_manager_fencing
Also: Bei aktivierten HA-Modus wird sichergestellt, dass ein ausgefallener Knoten nicht online geht, um zu vermeiden, dass eine VM mehrmals gestartet wird und dann gleichzeitig auf die gleiche Ressource zugreift (etwa die NAS). Blöderweise (siehe verlinkten Text zum qdevice oben) kann aber bei einer ungeraden Anzahl + qdevice ein Ausfall dazu führen, dass dann alle Knoten in diesen Zustand kommen, wenn ich das richtig verstanden habe (ich will nicht ausschließen, die Zusammenhänge falsch verstanden zu haben)
Das qdevice war dafür gedacht das auch mal ein Node offline sein kann. Man benötigt ja nicht immer alle. Und ich wollte, wegen meiner App, möglichst viele Fälle abdecken.
Es ehrt dich alle möglichen edge-cases abdecken zu wollen, aber das würde ich lassen. Wenn man nicht ständig alle Knoten im Cluster benötigt, dann braucht man diese Knoten auch nicht im Cluster. Sprich: Hat man drei Knoten, will aber einen davon die meiste Zeit auslassen, warum dann den überhaupt in den Cluster aufnehmen? Ein Cluster hat doch folgende Usecases:
- Hochverfügbarkeit bereitzustellen
- Gemeinsame Nutzung von Hardwareressourcen, etwa um die Last gleichmäßig zu verteilen, oder weil man sonst nicht genug Power hat, um seine Dienste zu betreiben.
Wenn man das nicht braucht (etwa weil der Knoten nicht benötigt wird, um noch genug Kapazität bei Ausfällen zu haben), wozu dann überhaupt den Cluster? Ist ein Knoten nur eine Spielwiese, die nicht ständig laufen muss, kann man ihn dann doch auch einfach einschalten, sobald man ihn braucht und muss sich dann halt extra anmelden, das ist doch dann auch kein Problem.
Wenn es einen um ein gemeinsames Interface zum Zugriff und die Migration zwischen Knoten geht: Das geht auch mit dem Proxmox Datacenter Manager, der hat auch nicht die Netzwerkanforderungen von corosync. Oder eben mit einer App fürs Smartphone, wenn der Entwickler die Unterstützung für remote-migrate eingebaut hat (der Datacenter-manager macht auch nichts anderes und soweit ich weiß läuft das auch über die API, Details kriegst du sicher über den PDM Quelltext raus oder die API-Doku):
https://www.thomas-krenn.com/en/wiki/Proxmox_Remote_Migrationt
https://github.com/proxmox/proxmox-datacenter-manager/
Edit: Habe auch die API-Doku gefunden:
https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/qemu/{vmid}/remote_migrate für vms und
https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/lxc/{vmid}/remote_migrate für container.
Sprich: Gerade als Entwickler einer unabhängigen App würde ich doch dringend dazu raten keine Setups zu unterstützen, die so nicht wirklich vorgesehen und "Build to break" sind. Und nicht nur die API-Doku zu lesen
Wenn meine Beobachtungen stimmen stört das qdevice nicht, solange die drei Nodes online sind. HA funktioniert zumindest wie ich es erwarten würde.
Aber wenn nun ein Node offline ist, also nur zwei echte Nodes in Betrieb sind, und ich auf dem Host, auf dem das qdevice läuft, ein Update mache und ich ihn rebooten muß, dann resetten die beiden Nodes.
Korrekt, siehe oben: Hat man eine ungerade Anzahl Knoten im Cluster wird das qdevice zum single-point-of-failure. Bei einer geraden Anzahl dagegen nicht, weil dann das Stimmverhalten anders ist. Darum: Bei gerade Anzahl Knoten: Qdevice hinzufügen. Danach dann entweder immer nur so viele Knoten hinzufügen (oder entfernen), dass die Zahl der Knoten ungerade bleibt oder entsprechend das qdevice vor Erweiterung des Clusters entsprechend entfernen und danach wieder hinzufügen (oder halt nicht).
Wozu dieser harte Reset, der dafür sorgt das garantiert nichts mehr geht? Warum kann man die beiden Nodes nicht einfach weiter laufen lassen?
Damit nicht die gleiche VMs auf mehreren Knoten läuft und gleichzeitig auf Daten zugreift (siehe oben).
