Container oder VM antwortet nicht mehr

P

proxmeup

New Member
Nov 17, 2024
18
5
3
Hallo,
ich habe vor einiger Zeit begonnen Proxmox einzusetzen und möchte viele interne (privates Umfeld) Services größtenteils ausfallsicher auf Proxmox betreiben. Dazu wurden zwei Mini-PC mit internen NVMe Disks und Quad-Port 1 Gb/s Ethernet NICs installiert und als shared nothing Cluster mit einem RasPi als qDevice eingerichtet.

Es läuft momentan die Version 8.4.1, Updates stehen an.
Die internen NVMe Disks sind 256 GB groß, per LVM (und ohne ZFS) für Proxmox eingerichtet und ein LVM-Thin Bereich von ca. 160 GB für Container und VMs angelegt.
Es läuft pro PVE Node eine VM (BSD) und ca. 5 Container (alle Debian).

In Ermangelung eines Shared Storage wurde die Ausfallsicherheit pro Service betrachtet und unterschiedlich realisiert:
  • Replikation auf Applikationsebene (beide PVE Nodes fahren einen aktiven Service, der intern seine Daten synchronisiert)
  • Synchrone Storage Replikation zwischen den beiden internen NVMe Disks der beiden PVE Nodes mit LINBIT DRBD (der Container für den Service liegt auf einem per DRBD replizierten Device)
Das funktioniert auch soweit mit 1 Gb/s prima, da die Änderungen pro Zeiteinheit auf dem DRBD Device nur sehr klein sind. Eine Container Migration zwischen den Nodes klappt problemlos.

Die PVE Nodes zeigen eine durchschnittliche CPU Last von ca. 10% und eine durchschnittliche RAM Auslastung von ca. 30 % an. Das IO Delay liegt bei max 0,2% (zumeist deutlich darunter) und weniger als 2 Mbit/s Netzwerktraffic.

Nun ist es so, dass nach einiger Zeit - ich weiß nicht genau welche, so zwischen 10 und 28 Tagen geschätzt - Container nicht mehr korrekt erreichbar sind. D.h. im PVE Web-UI gehe ich auf die Console eines Containers, sehe ggfs. die Textzeile fürs Login, aber der Container reagiert nicht auf Eingaben. Beim Versuch per SSH gibt es: „Connection reset by 192.168.x.y port 22“.
Auch die dort laufende Software reagiert nur in Teilen. Bsp.: Connection zum WebUI der Applikation kann aufgebaut werden, aber es finden keine Reaktionen auf Mausklicks statt.

Die Container lassen sich per PVE WebUI nicht mehr stoppen, sondern nur per Kommandozeile und forced.

Werden die Container erneut gestartet, ist für eine Zeit wieder alles OK.Ein Reboot der PVE Node löst den Zustand ebenfalls, dauert aber etwas, das zunächst lange versucht wird die Container zu stoppen.

Dieser Zustand tritt bei Containern auf beiden PVE Nodes auf. Es scheint, dass nicht sofort alle Container auf einer Node betroffen sind. Wenn eine PVE Node betroffen ist, läuft die zweite Node zumeist absolut korrekt weiter. Die beiden VMs scheinen nie betroffen zu sein.

Der Zustand ist für das hausinterne „Produktionssystem“ natürlich nicht tragbar. Meine erste Frage wäre: was muss ich tun, welche Einstellungen für eine Analyse vornehmen und welche Logs wie sammeln, um das Problem anzugehen. Oder kann jemand aufgrund der Beschreibung bereits das Lösungs-Kaninchen aus dem Hut zaubern?

Ich sag schon mal Danke!
 
Mitunter hilft ein ping vor dem ssh um lxc's aufzuwecken, aber idR sind sie nie gestorben sondern man muß nur Geduld für mehrere ssh Versuche mitbringen. Bin aber eher ein Freund von vm's, weil sie halt eigentlich alles besser machen, nicht einschlafen und life migrierbar sind während lxc dafür immer neu gestartet werden und somit eine Serviceunterbrechung unumgänglich. Die üblich regelmäßigen pve/debian updates lassen sich mit vm's und pve node wartungsmode zzgl. reboot unbemerkt umsetzen.
 
  • Like
Reactions: proxmeup and Johannes S
Danke für die Antwort.

Verstehe ich das richtig: du sagst, dass meine Situation keinen Fehler darstellt und der im LXC laufende Service vermutlich weiter normal funktioniert - nur eben der Container nicht per SSH erreichbar ist bzw. auf Kommandos des PVE, wie z.B. shutdown oder restart, nicht reagiert?

Da muss ich mal bei Auftreten durch das WebUI eines Service gehen, um das zu testen.

waltar said:
Bin aber eher ein Freund von vm's, weil sie halt eigentlich alles besser machen, nicht einschlafen und life migrierbar sind
Click to expand...

Ist eben so eine Sache mit den Ressourcen. Vielleicht packe ich mal mehr RAM rein.
Viele Services benötigen kaum Ressourcen und da hat eine VM pro Service viel Overhead. Wenn doch nur Docker statt LXC ginge. Vielleicht mal eine Docker VM ausprobieren?!
 
Last edited:
proxmeup said:
Ist eben so eine Sache mit den Ressourcen. Vielleicht packe ich mal mehr RAM rein.
Viele Services benötigen kaum Ressourcen und da hat eine VM pro Service viel Overhead. Wenn doch nur Docker statt LXC ginge. Vielleicht mal eine Docker VM ausprobieren?!
Click to expand...
Deshalb hat man ja auch nicht eine VM pro Service, sondern eine docker-vm als Spielwiese/Testumgebung und eine für alles Wichtige, was unbedingt laufen muss. Damit relativiert sich der Mehrverbrauch sehr schnell und man spart sich die bei lxcs übliche Frickelei
 
Last edited:
  • Like
Reactions: proxmeup
Johannes S said:
Deshalb hat man ja auch nicht eine VM pro Service, sondern eine docker-vm als Spielwiese/Testumgebung und eine für alles Wichtige, was unbedingt laufen muss. Damit relativiert sich der Mehrverbrsuch sehr schnell und man spart sich die bei lxcs übliche Frickelei
Click to expand...
Dann gehe ich das wohl mal an.
 
Welche NIC?
Falls e1000, bist du womöglich folgendem Klub beigetreten:
M

[SOLVED] Thread 'Intel NIC e1000e hardware unit hang'

This has been discussed many times, is there a solution/workaround yet, as the specified steps are not working for me?
I've the following in /etc/network/interfaces

Code: 
auto lo
iface lo inet loopback

iface eno1 inet manual
        offload-gso off
        offload-gro off
        offload-tso off
        offload-rx off
        offload-tx off
        offload-rxvlan off
        offload-txvlan off
        offload-sg off
        offload-ufo off
        offload-lro off
auto vmbr0
iface vmbr0 inet static
        address xxx
        gateway xxx
        bridge-ports eno1
        bridge-stp off...
 
  • Like
Reactions: proxmeup
War auch nur eine spontane, leicht nachprüfbare Idee meinerseits, die offenbar nicht zu deinem Problem passt.
Hast du im Fehlerfall mal das Netzwerkkabel für kurze Zeit gezogen und wieder angesteckt?
Klingt nach Hausfrauenreparatur, Ist aber einfach und man kann sich ans Problem womöglich näher ranrobben.
 
So,

es ist wieder aufgetreten. Weder ein Ping, noch das Ziehen und Wiedereinstecken der Netzwerkkabel hat geholfen. Den Login-Namen konnte ich eingeben und dann hing die Console. SSH mit Fehler, wie oben genannt.

Aber: ein Container hatte keine Probleme.

Daher die Frage: wenn es ein Problem mit Intel Netzwerkkarten wäre, müssten dann nicht alle Container auf dem PVE Host betroffen sein?
Und: gibt es bei Intel-NIC Problemen Hinweise in den Logs? Wenn ja: welche?

Ich wäre ganz froh über Hinweise, wie der Fehler in welchen Logs ggfs. verfolgt werden kann.
 
Wenn alles hängt, aber ein Container läuft, dann schau mal nach deinem Storage. Wenn der Container rein im RAM läuft, dann ist für den alles fein. Alle anderen Services sind auch von Disk abhängig.
 
  • Like
Reactions: proxmeup
@proxmeup
Ähnliches Verhalten hatte ich gerade diese Woche, glücklicherweise mit einer IP-KVM davor. Über die hing dann sogar ein df-h auf dem Host. Ein Start von mc ging komischerweise. In Logs suchen ist leider vergebene Liebesmüh.
Es waren weder LXC noch VMs erreichbar.
Wenn es möglich ist (pci-Slot), würde ich die NIC tauschen. Günstig und erspart Kopfschmerzen.
Du hast m.E. ein INTEL-Problem.
Die ehemalige Bastion der Zuverlässigkeit :-(
 
Last edited:
TErxleben said:
Du hast m.E. ein INTEL-Problem.
Click to expand...
Glaube ich irgendwie nicht. Wenn NIC, dann müssten alle CTs betroffen sein.

Falk R. said:
Wenn alles hängt, aber ein Container läuft, dann schau mal nach deinem Storage
Click to expand...
Guter Hinweis. Die CTs, die hängen werden per LINBIT/DRBD zwischen den PVE Nodes gesynct. Der Container, der weiterlief ist nur lokal, da App-intern active/passive. Das Storage darunter - Hardware-Ebene - ist zwar immer dieselbe NVMe, aber DRBD macht hier schon einen möglicherweise entscheidenden Unterschied.

Und die VMs, die ja ohne Probleme laufen...sind auch nur lokal und nicht per DRBD gesynct.
 
Last edited:
proxmeup said:
Glaube ich irgendwie nicht. Wenn NIC, dann müssten alle CTs betroffen sein.


Guter Hinweis. Die CTs, die hängen werden per LINBIT/DRBD zwischen den PVE Nodes gesynct. Der Container, der weiterlief ist nur lokal, da App-intern active/passive. Das Storage darunter - Hardware-Ebene - ist zwar immer dieselbe NVMe, aber DRBD macht hier schon einen möglicherweise entscheidenden Unterschied.

Und die VMs, die ja ohne Probleme laufen...sind auch nur lokal und nicht per DRBD gesynct.
Click to expand...
Da haben wir vermutlich die Ursache. Dann musst du jetzt die Logs vom DRBD auswerten. Da kann ich dir leider nicht weiterhelfen, da ich persönlich solche Bastellösungen nicht mag und deshalb keine Erfahrung damit habe.
 
Falk R. said:
da ich persönlich solche Bastellösungen nicht mag
Click to expand...
Oha, das werden die Macher von DRBD bei LINBIT aber nicht gerne lesen. Ich hatte das auch nicht als Bastellösung eingestuft, als ich nach einer Lösung für HA suchte.

Was ist denn eine "vernünftige" Lösung für den Betrieb zuhause?

Die heimische Produktion:
2 PVE Hosts plus ein QDevice (wenn für eine Lösung nötig, füge ich auch gerne einen 3. Knoten an Stelle des RasPi QDevice hinzu)
Energieeffizient (bei mir laufen Mini-PCs mit << 20 W/h)
Standardkomponenten
Jeder Knoten hat eine interne NVMe - kein zusätzlicher Shared Storage für den Betrieb notwendig

Die eingesetzten Applikationen sollen entweder fault-tolerant oder automatisch auf anderen PVE Nodes restartable sein.
Dazu müssen Applikationsdaten verteilt verfügbar sein. Das kann über die App selbst oder eben per Shared Storage funktionieren.
App-intern: Applikation ist für Multi-Host HA-/Fault-Tolerance ausgelegt und repliziert die notwendigen Daten selbst übers Netzwerk (z.B. OpnSense)
Shared Storage (die Applikation bietet selbst keine Möglichkeit der Datenreplikation):
- der Container oder die VM mit Docker wird zwischen PVE Knoten repliziert oder
- die Applikationsdaten müssen repliziert werden

Eine synchrone Replikation wäre schön, da kein Datenverlust (deswegen kam ich auf DRBD). Wenn allerdings keine synchrone Replikation in dieser Umgebung vernünftig ist (bislang fällt für mich Ceph bei meiner Umgebung in dieses Raster), wäre wohl eine zeitlich wenig verzögerte asynchrone Replikation das Nächstliegende, z.B. per ZFS (muss ich eben den PVE Cluster neu machen).

Als Neuling habe ich vielleicht das Naheliegende übersehen und freue mich daher über einen Lösungsvorschlag.
 
Vergiss es einfach. PVE KANN einfach kein automatisches Failover, falls ein Node wegen z.B. Stromausfall wegfällt.
Ohne Shared Storage noch viel viel weniger.
Selbst mit Shared Storage geht es nicht.
Synchrone Replikation sowieso gar nicht.
Darum laufen hier viele ZFS/CEPH-Fans rum, die versuchen das mittels "sekündlichen" Snapshots hinzudengeln.
Daraus wachsen dann auch Meinungen, die DRBD als "Bastellösung" bezeichnen.
Allerdings erfordert DRBD auch einen erheblichen HW-Einsatz und ist in meinen Augen auch nicht der Weisheit letzter Schluß.
Das an pve dranzuflicken halte ich allerdings auch für verwegen.
 
  • Like
Reactions: proxmeup and waltar
Professionelles failover muß auf Applikationsseite existieren und dann auf mehreren hosts laufen, alles andere ist nur DR setup zu angenähertem HA.
 
  • Like
Reactions: proxmeup
TErxleben said:
Synchrone Replikation sowieso gar nicht.
Darum laufen hier viele ZFS/CEPH-Fans rum, die versuchen das mittels "sekündlichen" Snapshots hinzudengeln.
Click to expand...

Mit Ceph hat Storage Replication nichts zu tun, Ceph kann synchrone Replikation, braucht dann aber auch entsprechende Ressourcen.

ZFS Storage Replication ist keine Lösung für alles, aber halt relativ einfach umsetzbar und für den "Hausgebrauch" (wozu auch kleinere Unternehmen zählen) ausreichend. Und anders als DRBD und co direkt in die GUI integriert.

proxmeup said:
Eine synchrone Replikation wäre schön, da kein Datenverlust (deswegen kam ich auf DRBD). Wenn allerdings keine synchrone Replikation in dieser Umgebung vernünftig ist (bislang fällt für mich Ceph bei meiner Umgebung in dieses Raster), wäre wohl eine zeitlich wenig verzögerte asynchrone Replikation das Nächstliegende, z.B. per ZFS (muss ich eben den PVE Cluster neu machen).
Click to expand...

Den aktuellen Cluster kannst du schon so lassen, für Storage Replication brauchst du halt mindestens einen gleichlautenden ZFS-Storage auf beiden Knoten. Rein technisch funktioniert es aber problemlos, erst den einen Knoten mit ZFS zu beglücken (etwa auf einer zusätzlich eingebauten SSD) und danach den Anderen. Kannst ja die Container und vms vor den Umbau auf den anderen Knoten verschieben oder backupen.
Es wird allerdings empfohlen für die Cluster-Kommunikation und die Datenübertragung jeweils eigene Netzwerkverbindungen zu haben, damit die Latenzen schön niedrig bleiben, ich halte mich in meinen Homelab aber auch nicht dran. Aber man sollte das im Hinterkopf behalten, dass dadurch Probleme auftreten können. Es gibt darum hier auch Leute, die ihre wichtigen Sachen im Homelab sehr bewusst nicht im Cluster betreiben, sondern sich damit begnügen dass auf ihren Heimservern auch jeweils ein PBS läuft und beide Server sich gegenseitig die VMs und Container backuppen. Alternativ könnte man auch pve-zsync nutzen, um via zfs eine Synchronistation vorzunehmen, ohne dass beide Server im gleichen Cluster stehen.
Pick your poison ;)
https://pve.proxmox.com/wiki/Cluster_Manager
https://pve.proxmox.com/wiki/Storage_Replication
Lesestoff: https://pve.proxmox.com/wiki/PVE-zsync
 
  • Like
Reactions: UdoB and proxmeup
You must log in or register to reply here.
Top Bottom