Container oder VM antwortet nicht mehr
- Thread starter proxmeup
- Start date
Ja und? Dafür kann PVE Ceph als Storage nehmen, ob direkt auf dem Knoten oder als externen Speicher
Abgesehen davon, das PVE sowieso in der Lage sein sollte fast beliebige externe Zentralspeicher einzubinden, interessiert es mich schon brennend, wie du mit Speichermedien einzelner Knoten eines PVE-Clusters ein HA-Speichermedium dengelst.
Last edited:
OK, ohne zu lesen bin ich da nicht sattelfest, was das umpartitionieren angeht. Ist ja momentan alles LVM.
Dafür (und die Firewall) ist die Quad-Port-Ethernetkarte. Direkte Kabelverbindung zwischen den Nodes, nur das QDevice ist natürlich außen vor.
Das Schöne ist, das wir hier die eigenen Anforderungen auch anhand von Erfahrungen umdenken können
Es gibt doch recht wenig, was wirklich synchron oder richtig fault-tolerant sein muss. Wenn ich durch meine Applikationen gucke: OPNsense, weil sonst ist die Internetverbindung weg und der Rest der Bewohner meldet das schneller als jedes Monitoring ;-)
Gut wäre eine Lösung für Traefik (oder sonstigen Reverse Proxy) und Keycloak. Ist aber schon eher convenience / nice to have als echte Notwendigkeit. Na ja, mal sehen, ob ich das mit Redis o.ä. versuche.
Ununterbrochenes Logging ist im Heimumfeld auch eher "nett" als nötig.
Nahezu alle Applikationen sind sehr schnell aufgesetzt, meistens reicht es die Konfigurationsdateien abgespeichert zu haben (habe ich alle im Git).
Bei allen Apps wäre es aber wünschenswert, wenn die nach Ausfall eines PVE Hosts auf dem anderen automatisch starten. Da sich die Konfigurationen seltener ändern könnte ich die Apps auf beiden Nodes installieren und ab und an zwischen den Nodes den aktuellen Status (nicht Konfiguration) abgleichen.
Das scheint mir aufgrund der Nachrichten in diesem Thread eine gute und vor allem stabile Lösung komplett im von Proxmox supportetem Raum. Denn das Einfrieren von CTs ist nicht das Gelbe vom Ei.
Jau, ich wünschte alle Apps würden das unterstützen.
Es wird ja durch LINBIT supported. Aber vielleicht meinst du gar nicht mich mit dem "dranflicken" ;-)
Ich empfehle, die aus HA-Wünschen resultierenden Fehlerquellen und Aufwand zu eliminieren.
Ich nutze z.B gerne Pihole als DHCP/DNS Gespann.
Bevor ein Failover stattgefunden hat, haben drei Leute angerufen, dass das Inet nicht mehr funktioniert.
Vor dem Auflegen ist ein VM-Duplikat gestartet. Ganz ohne Abgleichsgedöns etc. pp.
Einfach nur automatisch täglich auf gewünschte Hosts kopiert.
Ich nutze z.B gerne Pihole als DHCP/DNS Gespann.
Bevor ein Failover stattgefunden hat, haben drei Leute angerufen, dass das Inet nicht mehr funktioniert.
Vor dem Auflegen ist ein VM-Duplikat gestartet. Ganz ohne Abgleichsgedöns etc. pp.
Einfach nur automatisch täglich auf gewünschte Hosts kopiert.
Anwender waren schon immer ein gut funktionierendes Monitoring.
Last edited:
Isso!Anwender waren schon immer ein gut funktionierendes Monitoring.
Leider!
Bevor NAGIOS und Konsorten nur die Farbe gewechselt haben, wurden schon gefühlte 10 Telefonate geführt.
Ist auch nicht förderlich "Hier ist alles grün" zu antworten.
Nix gegen DRBD an sich.
Aber wenn ich Proxmox produktiv nutzen möchte, nehme ich nur die Features, welche eingebaut sind.
Wenn ich ein externes Storage anbinde ist das auch ok, da man eine Entkopplung hat.
Kann aber jeder so halten wie er möchte, nur ich möchte das nicht bei meinen Kunden Supporten müssen.
Gerade pihole ist auch ein super Beispiel, wie man die Hochverfügbarkeit auf der Anwendungsebene einrichtet:
https://delightlylinux.wordpress.co...zed-pi-hole-with-keepalived-and-gravity-sync/
Dann ist es vermutlich das einfachste, alle vorhandenen VMs und Container von einen auf den anderen Knoten zu migrieren und zu backupen (nur für den Fall der Fälle), den Knoten aus den Cluster zu entfernen und neu aufzusetzen (nur halt mit ZFS). Diesen neuen Knoten nimmst du dann noch nicht in den Cluster auf, stattdessen migrierst du die VMs vom anderen Knoten wieder um. entweder auf der Konsole mit remote-migrate oder den Proxmox Datacenter Manager, dafür lässt sich ja schnell eine VM aufsetzen. Der PDC hat zwar noch Alpha-Status, aber das braucht dich ja nicht stören. Wenn es gar nicht klappen will die VM/den Container auf dem neu eingerichteten Knoten aus den Backup wieder herstellen. Sobald der letzte Knoten mit LVM leer gezogen ist auch den plattmachen und mit ZFS neu installieren, danach dann wieder einen Cluster bauen.
https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_join_node_to_cluster
https://pve.proxmox.com/wiki/Cluster_Manager#_remove_a_cluster_node
https://pve.proxmox.com/wiki/Proxmox_Datacenter_Manager_Roadmap
Für pct remote-migrate und qm remote-migrate:
https://pve.proxmox.com/pve-docs/pct.1.html
https://pve.proxmox.com/pve-docs/qm.1.html
Ich habe aus genau den Grund davon abgesehen OPNsense zu virtualisieren, mein Internetzugang läuft (weiterhin) über die Fritzbox. Nun geht es mir schon auf die Nerven, dass die wireguard-Funktionalität davon in Vergleich zu OPNSense/pfSense oder OpenWRT sehr kastriert ist, deshalb überlege ich mir dafür einen China-Router (Mini-PC mit mehreren Ethernet-Ports von den üblichen Quellen) anzuschaffen und darauf dann die Sense oder OpenWRT baremetal zu betreiben. Selbst da bin ich mir nicht sicher, ob ich das will, seitdem ich folgendes Posting von @meyergru gelesen habe: https://forum.opnsense.org/index.php?topic=39556.0
Und mit den Backups der VMs und Container selbst noch viel schneller
Tatsächlich ist das schlimmere ja der Verlust der eigentlich interessanten Daten (also z.B. der Medienbibliothek von Plex oder so).Naja, solange du mit einen kleinen Datenverlust leben kannst, ist genau das Szenario mit Storage-Replication gut abgedeckt. In der Voreinstellung läuft die Synchronisierung alle 15 Minuten, das kann aber für jede VM auch nach oben (meine bis zu mehreren Wochen!) und unten (bis zu einer Minute) reduziert werden. Bei den meisten Anwendungen dürfte ein Datenverlust von 1-15 Minuten verschmerzbar sein, gerade im Homelab
Und: Bei einer normalen Migration der VMs zu einen anderen Knoten (etwa Neustart nach Updates eines Knotens) hat man den nicht einmal, da ja vorher alle Daten inklusive des Systemzsutands und VM-RAM-Inhalts syncronisiert werden, die beim Sync davor noch nicht übertragen wurden.
Auch Container lassen sich so migrieren, nur werden die dabei (logischerweise) gestoppt und auf den anderen Knoten dann neu gestartet (sprich: Systemzustand und RAM-Inhalt sind weg, die eigentlichen Daten aber nicht). Je nachdem, was auf dem Container läuft, muss das nicht unbedingt schlimm sein, die starten ja deutlich schneller als VMs, man merkt also ggf. von der Downtime gar nichts
Was beunruhigt dich in dem Posting von @meyergru? Ich finde OPNSense läuft super in PVE. Ich betreibe OPNSense bei mir gem. "Falle 1" und das als HA (auf Applikationsebene), also Internet -Fritzbox - (Zwischen-LAN) - OPNSense - interne LANs. Ja, mit Double-NAT, was überhaupt kein Problem ist, weil nur genau 2 interne Systeme aus dem Internet erreichbar sind: 1x WireGuard auf der OPNSense selbst und 1x ein Reverse Proxy (auch PVE) per HTTPS-only, der auf andere interne System verteilt, ggfs. mit weiterer Authentifizierung per Keycloak. Da gibt es Double-NAT, aber ohne Probleme und alles läuft über die OPNSense.
Ausserdem soll ein zusätzlicher LTE-Router einen möglichen Ausfall des Standard-Internetanschlusses abdecken und bereits laufend ist ein selektives Routing von bestimmten Zielen per VPN - danke an die Telekom, die einige Ziele mit besch... Bandbreite und Latenz abdeckt. Alles Routing - Festnetz-Internet, LTE-Internet und VPN - läuft über OPNSense, daher muss das immer laufen.
Die Fritzbox-WLAN-Access Point Problematik habe ich nicht, da ich mehrere Access Points und dafür ein anderes System nutze.
Was ist Plex?
Tatsächlich sehe ich hier kein Problem bei einem Datenverlust, dem ich trotzdem durch Backups vorbeuge. Die Daten ändern sich nicht so schnell in einem solchen Umfang, dass ein Backup nicht ausreichen würde. Und wenn doch alles abhanden kommt: neu mit der Konfiguration aufsetzen und ein bis zwei Stunden arbeiten lassen. Dann ist die Bibliothek wieder da.
Sehe ich inzwischen genauso, wie in deinem letzten Abschnitt beschrieben. Was verliere ich denn an Daten? Logs! Letzte inhaltliche Änderungen werden nach dem Neustart einer VM oder eines CT bei meinen Apps automatisch wieder hergestellt. Für DHCP/DNS setze ich Technitium ein. Da verliere ich ggfs. den DHCP Log Eintrag. Der dadurch angelegte DNS Record wird applikationsintern repliziert und alle Technitium-Instanzen prüfen vor Ausgabe einer DHCP-Adresse per ping, ob tatsächlich frei.
War schön mal mit DRBD zu spielen. Aber mit der aktuellen LINBIT-Version kommen auch blöde Versionsabhängigkeiten ins Haus, auf die ich gut verzichten kann. Und ZFS kenne ich noch von TrueNAS. Ist aber dennoch schade, dass es offensichtlich keine einfache synchrone Storage-Replikation für 2+1 Nodes gibt oder eben nicht alle Apps intern HA - fault tolerant sind.
Auch diese wirkliche gute Beschreibung behandelt nur DNS. I.d.R. betreibt man Pihole aber zusätzlich auch als DHCP-Server. Da lauert dann schon die eine und andere Fußangel, welche man zwar mit Trick 17 entschärfen kann, aber nicht richtig glücklicher macht. Deshalb starte ich, im ohnehin unwahrscheinlichen Fall eines Pihole-Ausfalls, lieber eine möglichst aktuelle "schlafende" Pihole-VM statt mir die dauerhafte Komplexität von keepalived und Gravity ans Bein zu binden.
Ein ähnliches Problem, wenn man den Ausfall eines Knotens mal mit dem Mantel des Schweigens bedeckt, hat auch ein PVE-Cluster. Darum meide ich diese auch soweit es geht.
Kurz gesagt: PVE-Einzelnode fällt aus (HW-Fehler) => Cluster platt. Betroffene VMs kommen eben leider nicht automatisch auf einem anderen Node aus dem Quark.
Last edited:
Ein wenig Off-Topic aber wenn ihr einen redundanten DHCP Server haben wollt und keine Synchronisation benötigt, oder dynamische DNS Registrierung dann wäre es eine Option einfach zwei DHCP Server im Netz zu betreiben, mit unterschiedlichen sich nicht überschneidenden IP-Pools. Soweit ich weiss ist das laut DHCP Spezifikation erlaubt und der Client nimmt einfach die DHCP Antwort die er als erstes erhält. Da die Reservierung vom Client bestätigt wird bleibt die vom der zweiten DHCP Instanz angeboten IP frei. Nachteil ist dass es halt bei jeder DHCP Anfrage 2 Antworten gibt aber das sollte in kleineren Netzen kein Problem sein.
@MarkusKo: Getrennte Bereiche funktionieren natürlich immer. Du verteilst deine Leases auf mehrere Server. Trotzdem hat der interne DNS-Dienst ein Problem, da er nicht peilt, dass sich auf einem seiner DHCP-Kumpels plötzlich Clients eingebucht haben. Generelles Problem bei getrennt laufenden DHCP und DNS Servern in internen Netzen. So ist der Parameter dhcp-reply-delay angebrachter, der bei parallel laufenden Diensten sogar gleiche DHCP Adressräume relativ schmerzlos bedienen können. Lücken entstehen, wenn der Master wieder am Start ist.
Keiner will 7200s warten, bis der DNS-Dienst wieder uptodate ist. Die Leasetime zu minimieren ist auch keine ordentliche Lösung.
Dieser Bockmist führt bis Heute zu dem Paradigma "ein Server braucht eine feste IP".
Keiner will 7200s warten, bis der DNS-Dienst wieder uptodate ist. Die Leasetime zu minimieren ist auch keine ordentliche Lösung.
Dieser Bockmist führt bis Heute zu dem Paradigma "ein Server braucht eine feste IP".
Last edited:
Stimmt, ist aber nur ein Problem wenn man dynamische DNS Registrierung der Clients benötigt, für kleine (Heim)Netze sehe ich da keine Notwendigkeit. Die wichtigen Hosts (VM's) kann man ja statisch im DNS registrieren. Hängt natürlich immer von der Größe des Netzes und vom gewünschten Funktionsumfang ab.
Wir haben auch 2 "halbe" pihole mit eigenem Abgleich, kann jeden stoppen und alles geht weiter wie DNS und irgendwelche dhcp vm/lxc booten.
Ein pve können wir auch ausschalten und dank ha config fährt der dann "vermisste" Kram automagically auf anderen Nodes wieder hoch da alle images per nfs.
Ein pve können wir auch ausschalten und dank ha config fährt der dann "vermisste" Kram automagically auf anderen Nodes wieder hoch da alle images per nfs.
Last edited:
Statische Einträge kann PiHole mittels Gravity inzwischen ja sogar. Statische Einträge sind aber irgendwie 80er. Ein DHCP-Server sollte eine Anmeldung einfach transparent an einen oder gar mehrer DNS-Server melden. Da liegt der Hase im Pfeffer.
Last edited:
Verstehe ich es richtig, dass ihr eine PiHole-VM auf einem zentralen Speicher abgelegt habt und bei nicht Erreichbarkeit des "Masters", diesen auf einem anderen PVE-host startet? Klingt tricky aber gut.
DNS/DHCP ist in meinen Augen DER zentrale Dienst, der auch in Mininetzen ohne Geprökel funktionieren sollte.
Warum verteilen die DHCP-Server denn nicht den identischen Bereich?
Der "Trick" mit gegenseitigem DNS-Abgleich sollte doch auch dann funktionieren?