wo sind die NFS am laufen? auf irgendwelche VMs oder eigene hosts?
um festzustellen wo der crash passiert:
um festzustellen wo der crash passiert:
mkdir /tmp/trace; cd /tmp/trace; strace -ff -o daemon-strace systemctl restart pvedaemon. danach wirst du ein paar files sehen, z.b. daemon-strace.937119. diese bitte hier postenWas meinst du mit "wo am laufen"?
Wenn du die location meinst: Das sind eigene physikalische NAS im selben Netzwerk (also fummelt uns keine Gateway mit Funktion X Y rein)
Grundsätzlich benutze ich die NAS ... (was ist plural davon?) für Backup und Desasterzwecke. Da mir aber aktuell das CEPH mangels maschinen weggenommen wird, muss ich für 4-5 Wochen auf NAS die VMs schreiben lassen.
Files kommen ASAP-
Wenn du die location meinst: Das sind eigene physikalische NAS im selben Netzwerk (also fummelt uns keine Gateway mit Funktion X Y rein)
Grundsätzlich benutze ich die NAS ... (was ist plural davon?) für Backup und Desasterzwecke. Da mir aber aktuell das CEPH mangels maschinen weggenommen wird, muss ich für 4-5 Wochen auf NAS die VMs schreiben lassen.
Files kommen ASAP-
Ich hatte gestern abend die Maschine neu hochfahren müssen damit die wieder gut erreichbar ist.
Heute morgen kam direkt ein Ticket daher, dass das selbe Fehlerbild beschreibt.
Wieder war es _eine_, nicht alle, VMs die auf der NAS die Platten hat. Auch hier half nur ein Hardreset der Maschine (Host).
Interessanterweise ist das _bisher_ beim anderen PVE Cluster noch nicht aufgetreten, auch da liegt eine VM herum die ihre Platten auf der NAS hat.
Das Problem kenne ich also bisher nur bei diesem "großem" cluster bei sporadisch(!) allen Hosts und verschiedenen NAS.
Nochmal zum Reboot: Ein kontrollierter Reboot ist nicht möglich, auch nach 30min tut sich da nichts mehr
Heute morgen kam direkt ein Ticket daher, dass das selbe Fehlerbild beschreibt.
Wieder war es _eine_, nicht alle, VMs die auf der NAS die Platten hat. Auch hier half nur ein Hardreset der Maschine (Host).
Interessanterweise ist das _bisher_ beim anderen PVE Cluster noch nicht aufgetreten, auch da liegt eine VM herum die ihre Platten auf der NAS hat.
Das Problem kenne ich also bisher nur bei diesem "großem" cluster bei sporadisch(!) allen Hosts und verschiedenen NAS.
Nochmal zum Reboot: Ein kontrollierter Reboot ist nicht möglich, auch nach 30min tut sich da nichts mehr
Wars es dann? ^^
Heute hatte ich erneut einen halb gestorbenen PVE-Host mit einer gekillten VM, identisches Fehlerbild.
- Lokales PVE nicht erreichbar
- PVE Features via andere Cluster Hosts erreichbar aber nicht wirklich steuerbar (timeouts)
- Überlebende VMs per Console erreichbar und "herunterfahrbar"; aber nicht migrierbar
- CEPH war healhy
- Nur ein Hardwarereset erwirkte einen Neustart.
Heute hatte ich erneut einen halb gestorbenen PVE-Host mit einer gekillten VM, identisches Fehlerbild.
- Lokales PVE nicht erreichbar
- PVE Features via andere Cluster Hosts erreichbar aber nicht wirklich steuerbar (timeouts)
- Überlebende VMs per Console erreichbar und "herunterfahrbar"; aber nicht migrierbar
- CEPH war healhy
- Nur ein Hardwarereset erwirkte einen Neustart.
Nein, das wäre in diesem Case auch unklug.
Diese Geräte (Also die PVE Hosts und NAS) stecken direkt auf dem Backbone im selben VLAN.
Naja Das in ein vlan zu packen ist unklug. Der Traffic von nfs ist groß und ggf ist der Switch damit ausgelastet. Trenn am besten das Storage Netz Cluster Netz und Client /produktiv Netz dann hast du schonmal weniger Stress sollte eine Migration statt finden. Cronosync braucht eine sehr geringe Latenz
Tut mir Leid, aber das halte ich für ausgemachten Quatsch.
Ausgelastet ist gar kein Netz oder Hardware (Switch, Host, NAS). Gäbe es ein derartiges Problem, wäre es auch ein globales Thema. Hier beschränkt es sich aber auf einem Cluster. Die anderen Cluster mit selben Konfigurationen bzw. sogar der identischen NAS haben keine Probleme damit.
Abgesehen davon ist das "Systemnetz" schon ein eigenes, darin befindet sich das PVE und die entsprechenden Laufwerke. Die VMs werden mit VLAN Tags in PVE angesprochen. Das Tagging im Systemnetz geschieht ausschließlich im Switch, nach "außen" gibts nativ.
Ausgelastet ist gar kein Netz oder Hardware (Switch, Host, NAS). Gäbe es ein derartiges Problem, wäre es auch ein globales Thema. Hier beschränkt es sich aber auf einem Cluster. Die anderen Cluster mit selben Konfigurationen bzw. sogar der identischen NAS haben keine Probleme damit.
Abgesehen davon ist das "Systemnetz" schon ein eigenes, darin befindet sich das PVE und die entsprechenden Laufwerke. Die VMs werden mit VLAN Tags in PVE angesprochen. Das Tagging im Systemnetz geschieht ausschließlich im Switch, nach "außen" gibts nativ.
Backbone 20gbit (2x 10gbit LACP), Hosts 2x 10gbit active/passive, die beiden angesprochenen NAS einmal 1x 1gbit und einmal 2x 10 gbit active-passive
Nach PRTG ist das Netz (also das Backbone) nicht einmal zu 10% ausgelastet, Peaks ~15%.
Zu den anderen Netzteilnehmern kommen hauptsächlich lächerliche Datenmengen zusammen (SIP/RTP, RDP und ein wenig "gesurfe" welches mit QoS an der Gateway gebremst wird.
Nach PRTG ist das Netz (also das Backbone) nicht einmal zu 10% ausgelastet, Peaks ~15%.
Zu den anderen Netzteilnehmern kommen hauptsächlich lächerliche Datenmengen zusammen (SIP/RTP, RDP und ein wenig "gesurfe" welches mit QoS an der Gateway gebremst wird.
Eine weitere Erkenntnis: Die drölfte NAS, nun eine Synology mit 4x 1gbit Anbindung an einer anderen Stelle im Netzwerk hat bei den Hosts den selben Effekt. Der alte Cluster zeigt bis heute keine Probleme dieser Art an.
Vorteil bei dieser NAS ist, dass die Sessions angezeigt werden. Dort ist die Session (Also die NFS Verbindung) durchgehend aktiv - mal davon ausgegangen, dass ein Timeout gezählt wird.
Offenbar bezieht es sich es immer mehr auf die Hosts selbst, die bzw. auch schonmal komplett neu installiert wurden ohne 3rd Party Software.
PS: Wenn man lange genug wartet, gesellen sich weitere VMs hinzu die dann gestört sind.
Vorteil bei dieser NAS ist, dass die Sessions angezeigt werden. Dort ist die Session (Also die NFS Verbindung) durchgehend aktiv - mal davon ausgegangen, dass ein Timeout gezählt wird.
Offenbar bezieht es sich es immer mehr auf die Hosts selbst, die bzw. auch schonmal komplett neu installiert wurden ohne 3rd Party Software.
PS: Wenn man lange genug wartet, gesellen sich weitere VMs hinzu die dann gestört sind.
Last edited:
OK leider muss ich sagen haben wir fast das gleich problem aktuell. NFS ist per Ping erreichbar aber laut Gui nicht mehr Aktiv.
@LachCraft habt ihr Check_MK zufällig am Laufen auf einer der Vms ?
@LachCraft habt ihr Check_MK zufällig am Laufen auf einer der Vms ?
Was für ein NAS benutzt du genau?
Es hat sich herausgestellt, dass die von Buffalo mächtig zicken machen.
Bei Synology und Eigenbauten mit FreeNAS gibt es gar keine Probleme. Ähnliche Probleme hörte ich von Netgear.
Wirklich sparen kann man bei FertigNAS eh nichts, also bau ich die in Zukunft alle selbst.
Wir nutzen ein NFS Cluster (EuroNas) bisher lief das ganz gut und wir waren zufrieden.
Das einzigste, was wir am Cluster geändert haben ist das wir eine VM mit Check_Mk installiert haben seitdem sobald die check_mk vm schmiert bei nur diesem einen Node die NFS Verbindung ab.
Das einzigste, was wir am Cluster geändert haben ist das wir eine VM mit Check_Mk installiert haben seitdem sobald die check_mk vm schmiert bei nur diesem einen Node die NFS Verbindung ab.