Ich muss mich jetzt auch noch mal einklinken, für meinen Geschmack sind die (sonst hochgeschätzten) Kollegen hier in der Diskussion teilweise etwas zu dogmatisch, bzw. zu sehr von ihrer beruflichen Brille geprägt. Ein Großteil der Regulars hier (mich eingeschloßen) verdient ja auch seine Brötchen mit Computerkram, da hat man dann in Bezug auf Betrieb, dessen Stabilität und Hochverfügbarkeit andere Ansprüche und Sichtweisen, als jemand im Heimnetz. Das ist auch überhaupt nicht schlimm, aber was in einen Fall ein No-Go ist, kann im anderen Fall durchaus tolerabel sein.
Worüber du dir also zuerst klar sein musst, was du dir unter Hochverfügbarkeit vorstellst:
- Sollen die Dienste weiterlaufen, während du z.B. einen Knoten wartest (neue Platte einbauen, Updates machen und neustarten)?
- Sollen die Dienste weiterlaufen, wenn ein Knoten (wegen Hardwareschaden, gezogenen Kabel o.ä.) ausfällt?
- Soll niemand was vom Ausfall bemerken oder ist eine kleine Downtime vertretbar? Falls letzteres, wie lange darf es maximal dauern?
- Fall ja: Dürfen dabei (für einen kleinen Zeitraum) Daten verloren gehen, oder muss der Datenbestand immer auf beiden Knoten identisch sein?
Diese Ansprüche kriegt man auch im Heimnetz erledigt, je nach vorhandener Hardware und Budget mehr oder weniger gut und mit unterschiedlichen Vor- und Nachteilen, mehr dazu gleich
Im professionellen Umfeld will man aber meistens auch folgendes:
- Die Dienste sollen auch bei einen Internetausfall weiter laufen, etwa damit Unternehmenswebseiten/der Passwortmanager (in deinen Fall bitwarden)/das VPN (wg-easy) weiter erreichbar sind. Dafür hat man dann einen zusätzlichen Internetvertrag, der dann aber nur für solche Notfälle ist und hat einen entsprechend eingerichteten Router, der zwischen beiden hin- und herwechseln kann. Mit einer handelsüblichen Fritzbox o.ä. funktioniert das nicht, aber OPNsense kann das z.B. Das ist dafür aber dann auch deutlich komplexer im Handling und man braucht eigentlich zwei Router, falls mal einer ausfälllt.
- Auch im Falle eines Stromausfalls es noch eine bestimmte Zeit weiterlaufen. Zum einen, um alle Systeme geordnet zu stoppen, damit es keine Folgefehler aus den Ausfall gibt. Zum anderen, um envtl. an einen anderen Standort (z.B. Cloud) auf Reserve gehaltene Notfallinfrastruktur starten zu können. Je nach Anspruch werden dafür Notfallaggregate oder auch "nur" Batterien genutzt. Während die Batterievariante auch für Heimanwender noch möglich ist (sofern man nur genug Zeit für die Notabschaltung haben will), werden die wenigsten Anwender wie ein mir bekanntes Rechenzentrum genug Diesel bevorraten, um 2-4 Tage (je nachdem, was man abschaltet) ohne Strom auszukommen.
Ich unterstelle mal, dass du dabei nicht soweit gehst, wie unsereins bei unseren täglich Brot, sondern es dir "nur" darum geht die Wartung deines Hauptknotens oder dessen Ausfall zu kompensieren und außerdem mal VMs und Container zwischen beiden Knoten hin- und herbewegen zu können.
Das geht grundsätzlich mit ProxmoxVE. Nur fürs bewegen (migrieren) reicht der ProxmoxDatacenterManager, den kann man auch als schmale VM oder Container einrichten. Hochverfügbarkeit hat man nicht (doof), dafür braucht es keine zusätzliche Netzwerkhardware oder einen dritten Knoten.
Will man dagegen einen richtigen Cluster, dann sollte dieser pro Knoten mindestens (!) zwei Netzwerkkarten haben, wobei einer exklusiv nur für die Cluster-Kommunikation mit corosync verwendet wird:
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network Der Grund dafür ist, dass die Knoten gerne miteinander reden möchten, um ihren Status und Konfiguration untereinander abzugleichen sowie, mitzukriegen, falls einer ausfällt und auszumachen, wer dann dessen VMs /Container übernimmt. Wenn nun die Hauptkarte schon mit den regulären Traffic plus Datenübertragung fürs Migrieren o.ä. beschäftigt ist, dann kann es passieren, dass irgendwann die Leitung dicht ist und der Cluster nicht mehr seinen Status synchronisieren kann->Cluster funktioniert nicht wie erwartet. Da für die Abstimmung, wer übernimmt immer eine Mehrheit benötigt wird, ergibt sich daraus auch, dass es mindestens drei Knoten braucht. Wenn man aber noch einen alten PC, eine NAS mit VM- oder Docker-Support, einen PI (oder irgendwas anderes worauf Debian läuft) über hat, dann kann dieses Gerät die Rolle des dritten Knotens übernehmen (
https://pve.proxmox.com/wiki/Cluster_Manager#_corosync_external_vote_support ). Dafür braucht es auch nur eine Netzwerkkarte, da dafür weniger Daten fließen als bei der eigentlichen Cluster-Kommunikation.
Die Netzwerkkarten sind aber nur die halbe Miete: Du willst ja erreichen, dass deine Workloads weiterlaufen, woher soll aber der zweite Knoten die Daten her haben und wissen, wieviel RAM/CPUs etc deine Container/VMs kriegen sollen? Auch diese Konfiguration wird über corosync abgeglichen, auch darum ist es wichtig, dass die corosync-Verbindung sich ihre Bandbreite nicht mit anderen teilen muss. Bleiben noch die eigentlichen Daten, also virtuellen Platten der vms und container. Will man, dass die Daten immer gleich sind, dann braucht es einen Netzwerkspeicher, der dies sicherstellt zwischen beiden Knoten. Ceph ist dafür eigentlich das vorgesehene Mittel der Wahl in ProxmoxVE, das braucht aber dann noch mal mehr Netz- und Storagehardware und mindestens drei Knoten (siehe
https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/). Das dürfte in deinen Szenario tatsächlich too much sein. Eine andere Möglichkeit wäre das NAS zu nutzen, aber über ein langsames Netzwerk wird das dann zum Flaschenhals für die virtuellen Laufwerke mit Betriebssystem und Anwendungen. Man könnte aber das NAS nutzen, um darüber gemeinsame Ordner zu realisieren, die die eigentlichen Daten enthalten. Hat das NAS (wie die meisten Homeuser-NAS) selbst keine Hochverfügbarkeitsfunktion (die ja selbst wieder ein zusätzliches kompatibles NAS bräuchte), wird das NAS dann zum single-point-of-failure. Ist man bereit das Risiko zu akzeptieren wie ein Kollege von mir in seinen Heimlabor? Dann kann man das machen, aber strenggenommen läuft das deiner Idee der Hochverfügbarkeit zuwider.
Was dagegen im Heimnetz "gut" genug funktioniert sind folgende Varianten (beide basieren auf zfs-internen Mechanismen und brauchen somit zwingend zfs, aber das will man eh haben
https://forum.proxmox.com/threads/f...y-a-few-disks-should-i-use-zfs-at-all.160037/ dann aber die VMs/lxcs nur in mirrors ablegen, sonst wird es lahm:
https://forum.proxmox.com/threads/fabu-can-i-use-zfs-raidz-for-my-vms.159923/ ):
- pve-zsync (
https://pve.proxmox.com/wiki/PVE-zsync) : Synchronisiert Daten und Konfiguration von vms und containern zwischen mehreren Knoten. Vorteil: Die müssen nicht mal im gleichen Cluster sein, Nachteil: Sie müssen manuell gestartet werden
-
https://pve.proxmox.com/wiki/Storage_Replication Synchronisiert Daten und Konfiguration von vms und containern zwischen mehreren Knoten eines Clusters. Im aktivierten HA-Modus (
https://pve.proxmox.com/pve-docs/chapter-ha-manager.html ) führt dann ein Ausfall oder eine geplante Wartung dazu, dass die VMs und Container auf den anderen Knoten übertragen (bei Migration) und danach gestartet werden. Bei einen Ausfall entfällt natürlich die Übertratung (darum kleiner Datenverlust), gestartet wird aber trotzdem. Das benötigt dann aber halt einen Cluster mit allen Anforderungen (Drei Knoten oder 2+qdevice, dezidiertes Clusternetzwerk etc)
Beide Verfahren sind asynchron und gehen nur mit zfs, standardmäßig werden die Inhalte alle 15 Minuten synchronisiert, das kann aber auf bis zu eine Minute reduziert werden. Ich behaupte, dass das ein Datenverlust ist, denn die meisten Homelabs besser verkraften können als alle Daten seit dem letzten Backup (was man ja trotzdem braucht! Hochverfügbarkeit und Replikation sind KEIN Backup) oder das Risiko eines Ausfalls falls das NAS wegbricht. Es gibt sogar Firmen, die das einsetzen, weil für ihren Usecase, dieses Risiko als vertretbar gesehen wird,
@Falk R. hat öfter erwähnt, dass er kleine Mittelständler hat, die so ein Setup fahren. Und auch die Proxmox-Webseite hat da das Beispiel einer portugiesischen Online-Apotheke, die damit arbeiten:
https://www.proxmox.com/de/ueber-uns/ueber-uns/stories/story/farmacia-nova-da-maia-de
In solchen Fällen ist aber dann bessere Netzwerkhardware zur Datenübertragung (mindestens 10GB besser 25G-Karten) am start, als im typischen Heimnetzwerk
Eine andere Sache, die man sich klar machen muss, sind prinzipbedingte Unterschiede zwischen VMs und Containern.
@TErxleben hat ja bereits die Problematik in Bezug auf docker erwähnt. Es ist in der Vergangenheit immer mal wieder vorgekommen, dass in lxc-Containern laufende docker-Container nach einen Update nicht mehr gingen (siehe z.B. hier
https://forum.proxmox.com/threads/d...bian-13-host-worked-fine-on-proxmox-8.169508/ ), weil sich was geändert hat, was dann vom Host auf die Container durchschleift. Das passiert bei VMs deutlich seltener. Ein anderer Unterschied ist, dass bei der Migration eines Containers IMMER der Container gestoppt und gestartet werden muss. Das dauert zwar normalerweise nur ein paar Sekunden, aber solange ist der Dienst dann nicht erreichbar. VMs können dagegen (wenn sie migriert werden) mehr oder weniger unterbrechungsfrei (tatsächlich gibt es auch dort eine kurze Auszeit, aber die ist quasi nicht wahrnehmbar) auf dem neuen Host dort weitermachen, wo sie vorher waren. Wenn du also keine Hardware an deine Anwendungen durchreichen musst (und imho ist das für keine deiner Anwendungen nötig), dann würde ich mir gut überlegen, ob eine Umstellung der docker-Container auf eine VM nicht stressfreier ist. VMs müssen nicht viel Ressourcen fressen, die Debian-VM mit meinen docker-Containern (sind nicht viel mehr als du) hat zwei CPUs und vier GB RAM zugewiesen, wirklich genutzt wird davon aktuell nur die Hälfte des RAMs und die beiden vCPUs langweilen sich.
Eine andere Möglichkeit Hochverfügbarkeit herzustellen ist eine auf Anwendungsebene (hier ist ein Beispiel für den adblocker pihole, auch wenn die Anleitung so auf neueren Versionen von pihole nicht mehr funktionieren wird, Idee sollte aber klar werden:
https://forum.proxmox.com/threads/pi-hole-lxc-with-gravity-sync.109881/post-645646) statt ProxmoxVE. Die meisten Datenbanken (Mysql/mariadb, MSSQL, Postgres) können das zum Beispiel, für deine Anwendungen müsstest du das prüfen (würde mich ehrlich gesagt eher wundern, aber Doku lesen schadet nie).
Langer Rede gar kein Sinn: Wenn du bereit bist, bestimmte Grenzen zu akzeptieren und dir ggf. passende Hardware zuzlegen, ist eine eingeschränkte Hochverfügbarkeit auch zuhause definitiv möglich und je nach Nutzungszweck auch nützlich. Ob das für dich zutrifft, kannst aber nur du entscheiden
