Ausfallsicherheit in HA - Proxmox fehlerhaft

Moin zusammen,

hier mal ein vorläufiger (hoffentlich aber endgültiger) Abschlussbericht.

Ich habe nun einen zweiten Mini-PC auf dem Proxmox läuft. Seit nun einer Woche (immerhin :slight_smile: ) stabil und ohne Ausfälle. Juchu.

Auf dem zweiten Proxmox ist der Proxmox Backup Server drauf, der täglich die Backups der Container und VMs vom ersten Proxmox macht. Diese werden dann auf der Festplatte des zweiten Proxmox gespeichert. Ich spare mir hierdurch den Dauerbetrieb meiner Synology, die ich eh nicht oft nutze.
Zusätzlich habe ich auf dem zweiten Proxmox auch noch Home Assistant installiert. Sehr rudimentär. Ich pinge den ersten Proxmox an, ist der Ping nicht erfolgreich, wird noch 5 Minuten gewartet und nochmal ein Ping ausgeführt. Ist dieser immer noch nicht erfolgreich, dann wir der Shelly Plug S vom ersten Server aus- und wieder eingeschaltet, so dass sich der erste Server dann wieder selbstständig hochfährt. So habe ich eventuelle Fehler durch nicht Erreichbarkeit ausgebügelt und muss morgens nicht von der Chefin schlechtgelaunt geweckt werden :rofl: .

Ich habe mich absichtlich gegen eine Cluster Lösung entschieden, da diese ja eigentlich nur mit drei physikalischen Servern richtig Sinn macht - ja, es gibt auch eine Option für 2 Server. Und den wirklichen Vorteil habe ich auch nicht, da ich eigentlich wollen würde: Ein Server fällt aus, ein zweiter springt atoc ein - quasi wie ein Raid. Geht aber nicht, da am Server noch ein HMIP-Funkstick sowie ein Zigbee-Stick dranhängen.

Sei es drum. Im Moment bin ich glücklich und hoffe, dass es weiter so bleibt.
Es scheint ja wohl wirklich ein Hardwaredefekt gewesen zu sein…oder das System war überlastet (da hatte ich vorher auch immer mal wieder Meldungen bekommen, das ist seit dem neuen Server auch nicht mehr der Fall).

Vielen Dank für eure ganzen Impulse, die wirklich sehr weitergeholfen haben!

vg
sven

Moin,

Zum Teil richtig, aber auch wieder nicht :slight_smile:
Ja, je mehr Nodes vorhanden sind, um so sicherer ist das Umschaltverhalten, ab Drei ist es machbar, aber es müssen nicht zwangsläufig 3 vollwertige Server sein, es können auch deine zwei Mini-PCs sein und ein RasPI in der Ecke, der sonst noch andere Aufgaben macht, dann kann man ein Quorum aufbauen, dazu muss nur eine kleine Software installiert sein.

Zu einer ausfallsicheren Lösung, gehört aber auch, dass man nicht nur über ein Netzwerk miteinander spricht, sondern über zwei, denn es kann ja auch etwas anderes in der Kette ausfallen, sieh unten.

ich denke, du meinst das, was ich oben geschrieben habe :thinking:

Die Holzhammermethode :slight_smile:
Das mal ein Ping nicht geht, kann ja mehrere Ursachen haben, Switch defekt, Kabel aus Versehen herausgezogen, defekt, usw. dann wird ein Rechner, der eigentlich noch super läuft, hart heruntergefahren, was dann in 99 % aller Fälle zu einer korrupten Datenbank führt, die beim Neustart, dann erst wieder repariert werden muss, was auch nicht immer möglich ist, oder irgendwann sind Bitkipper auf der SSD, HDD, die man nicht mehr loswird, dann muss man das ganze System neu Aufsetzen.

Falsche Analogie, in einem Raid 1 springt nichts ein, sondern die Daten werden gespiegelt und erst ein Raid 5, mit mindestens 3 Platten, hat eine Spare Platte, die automatisch eine ausgefallene Platte ersetzt :wink:
Das, was du meinst, ist Cold Standby, oder Hot Standby und dann entweder automatische Umschaltung oder händische Umschaltung.

Ja, das ist meist das Problem, da kann man nur umswitchen, in Sticks, die über LAN angebunden werden, ob es das bei HMIP gibt :man_shrugging:, Zigbee schon, oder eben USBIP, das gibt es in Hardware oder als Software, macht aber das Setup um einiges komplexer und teurer :frowning:

Das ist das, was wichtig ist, nicht einfach, Fire and forget, sondern seine Systeme regelmäßig auf Meldungen hin untersuchen und beheben, regelmäßig Updates fahren.

VG
Bernd

P.S.: Will dich nicht entmutigen, ich finde es toll, dass du dich mit dem Thema beschäftigt hast und wünsche dir für die Zukunft keine unnötigen, harten Abschaltungen, was mich dazu bringt, auch noch mal den Wert einer USV zu betonen :slight_smile:

Ich habe nun auch ein wenig mit Proxmox und 2 vorhanden Mini-PCs gespielt, im Job gibt es andere Systeme :).

Für meine Anwendungsfälle sieht das recht gut aus.
Ich habe jetzt mal 3 Asus NUCs bestellt (inkl 96GB RAM, auch wegen ZFS Caching) und werde Home Assistant einmal hochverfügbar aufsetzten.
Die notwendigen USB-Sticks (Z-Wave und Seriel-Adapter für den Solar-Akku) werden per Raspberry Pi im Netzwerk verfügbar gemacht. So können die VMs (HA und Add-ons) schwenken und die Konnektivität bleibt erhalten.

Ich hoffe, die Geräte kommen in den nächsten Tagen, dann gibt es wieder eine Abendbeschäftigung :smiley:

Also ich hatte nach dem letzten Update von Proxmox ein Problem, dass der Server immer wieder mal nicht mehr erreichbar war. Habe ich das Netzwerkkabel gezogen und neu angesteckt hat es wieder für 4-6 Stunden funktioniert. Dann wieder alles von vorne.

Im Logfile fand ich einen Eintrag enp0s25: Detected Hardware Unit Hang:

Die Lösung war unter /etc/network/interfaces folgendes einzutragen:

post-up ethtool -K enp0s25 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off

und zwar gleich unterhalb vom bereits vorhandenen Eintrag

iface enp0s25 inet manual

Seit dem (29.03.) läuft alles wieder fehlerfrei und ohne Unterbrechung.
Ich wollte das nur hier lassen, weil ich sehr lange gebraucht habe auf diese Lösung zu kommen. Der Name des Gerätes (bei mir enp0s25) kann bei euch ein anderer sein, daher nicht blind kopieren.

2 „Gefällt mir“

Hallo @Gorki, ich hatte nun auch genau die gleiche Fehlermeldung :scream: Aber total verrückt. Vorher ist das System einfach mal 3 Wochen durchgelaufen und nun habe ich das im Log stehen:
Apr 19 10:31:25 pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang

Ich habe nun den Eintrag in der “interfaces” gemacht. :sweat_smile: Ich bin gespannt und hoffe das Beste! Gab es bei dir noch Probleme? :nerd_face:

1 „Gefällt mir“

Hi @AnnaM86 !

Seit diesem Eintrag gibt es keine Probleme mehr. Proxmox läuft durch und ist auch durchgehend erreichbar.

Freut mich, wenn ich helfen konnte!

Schöne Grüße, Gorki

Hi, ja vielen vielen Dank!! :100:
Aber wie kann es sein, dass nur wir zwei das Problem hatten?! :sweat_smile:

1 „Gefällt mir“

Das Problem hattet nicht nur ihr zwei, :slightly_smiling_face: sondern das - oder genauer gesagt so ein - Problem taucht schon seit Jahren immer mal wieder auf und dürfte vermutlich mit der Kombination von verwendeter NIC und den dafür aktuell verwendeten Treibern zusammenhängen.

VG Jim

Nachdem mein System die letzte Woche ebenfalls zwei Mal nicht mehr erreichbar war und ich es jedes Mal mit einem manuellen Neustart wieder zum Leben erweckt habe, habe ich heute den angepassten Befehl ausgeführt. Neustart des Systems hat erstmal geklappt. Jetzt heißt es beobachten oder im besten Fall nicht beobachten, aber auf jeden Fall erstmal vielen Dank!

Interessanter Thread.
Nachdem ich erstmals vor 2 Wochen auch ein nicht mehr erreichbares System hatte, hatte ich ebenfalls

pve kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang

im log entdeckt.
Nur seltsam, dass das (Proxmox)-System (HP Elitedesk G4 8500T) vorher wochen- und monatelang problemlos lief.
Hierzu habe ich auch eine Quelle gefunden (bereits aus 2019(!)

1 „Gefällt mir“

Ich hatte das heute Nacht nun auch.
Kurz nach Mitternacht war nichts mehr erreichbar.
und heute morgen dann auch wieder nicht.
Hatte gestern das hier gelesen…
Bestimmt hat sich mein Proxmox gedacht “Da mache ich doch mal mit”
:speak_no_evil: :hear_no_evil: :see_no_evil:
Habe den Codeschnipsel bei mir auch eingetragen.
Mal sehen ob er auch bei mir Abhilfe Schaft…

@Gorki Ich glaube der erste Teil gehört da nicht rein! “post-up”

ethtool -K enp0s25 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off

'###########################################################

Nachtrag.
10 Stunden später war Proxmox und dadurch alle darauf laufenden Sachen wieder nicht erreichbar.
Also das hilft bei mir so leider nicht…

:cry:

Also bis jetzt hat der Eintrag immer funktioniert.
Wichtig ist, dass er eben genau so eingetragen wird (inkl. “post-up”) und dass der Adaptername (bei mir enp0s25) auch mit Deinem übereinstimmt.

post-up ethtool -K enp0s25 gso off tso off rxvlan off txvlan off gro off tx off rx off sg off

1 „Gefällt mir“

Ja, genau so war es auch bei mir. Jahrelang ohne Probleme und jetzt braucht der NUC den Eintrag. Und was noch viel verwirrender ist. Ich habe einen baugleichen NUC und der arbeitet problemlos ohne diesen Eintrag. Ich muss es nicht verstehen aber freue mich, dass es eine Lösung gibt! :wink:

OK… Das versuche ich dann nochmal.
Allerdings wird in den ganzen Verlinkten Beiträgen dieser Zusatz (post-up) nie angegeben.

Ja. Der Adaptername wird bei mir auch so in dem “Fehler-Protokoll” angezeigt.

Funktioniert bei mir auch nicht, ich habe den Eintrag in der
/etc/network/interfaces
gesetzt.
Dieser wird auch übernommen. Ob es Besserung bringt werden die nächsten Tage zeigen :slight_smile:

Also als dauerhafte Lösung kann ich das empfehlen:
https://forum.proxmox.com/threads/intel-nic-e1000e-hardware-unit-hang.106001/page-3#post-767515
bzw.
[Intel e1000e fix - Proxmox · GitHub]

Moin

Wie bereits geschrieben

und man findet dazu jede Menge Beiträge/Postings im Proxmox Forum. Ihr müsst einfach nur mal nach dem NIC-Modell suchen das in Euren Kisten verbaut ist. Also z.B. nach I219-V oder auch I219-LM usw. In einem NUC - wie z.B. in meinen NUC8 hier - ist z.B. eine Intel I219-V verbaut

und mit dieser kommt es - je nachdem welche Linux Kernel-Version und welchen Treiber man dann verwendet - ggf. zu diesem Problem. Als ich hier mal eine Zeit lang (2022) einen NUC8 mit I219-V NIC für Proxmox verwendet habe hatte ich mit einer Proxmox-Version X dann das Problem auch und ich musste diesen Eintrag bei Network - Interfaces auch vornehmen. Dann gab es ein neue Proxmox-Version Y und dabei war der Eintrag dann nicht mehr notwendig. Dann gab es wieder ein Update von Proxmox und schon tauchte das Problem wieder auf und der Eintrag bei Network - Interfaces war wieder notwendig. :rofl:

In meiner jetzigen Fujitsu Kiste, die ich für Proxmox nutze, steckt zwar auch eine Intel I219 NIC, allerdings das Modell I219-LM


und mit diesem Modell gab es jetzt - dreimal auf Holz klopf - seit ~ 2 Jahren noch nie das Problem und bei der war auch noch nie der entsprechende Eintrag in der Network Interfaces notwendig. Egal welche Proxmox-Version und Kernel ich hier verwendet habe. Die Netzwerk-Verbindung ist und bleibt absolut stabil.

BTW: Mit Realtek NICs gibt es natürlich auch immer mal wieder Probleme. Falls man ggf. davon betroffen sein sollte auch da immer nach der Modell-Bezeichung (z.B. RTL8169, RTL8125, RTL8156B usw.) im Proxmox Forum suchen.
Meine Realtek RTL8125 PCI NIC in meiner Proxmox Kiste läuft z.B. auch absolut stabil, wohingegen die Realtek RTL8156B-2 USB NIC so 2 - 3 mal am Tag kurzzeitig die Verbindung verliert. :rofl:

Mein Fazit zu dem Thema: NICs und die dann verwendeten Treiber dafür, können immer mal wieder irgendwelche Probleme bereiten. Warum das so ist und warum es immer mal wieder auftaucht, dafür habe ich auch keine wirklich Erklärung. Damit wird man wohl vermutlich (immer) leben müssen. :slightly_smiling_face:

Edit: Ich habe die Jahreszahl oben im Text eben noch korriert. :slightly_smiling_face: Den NUC8 habe ich in 2022 mal für Proxmox genutzt und seit Oktober 2022 nutze ich bereits die Fujitsu Kiste hier. Kinder was doch die Zeit vergeht. :laughing:

VG Jim

1 „Gefällt mir“

Ich habtte einige Zeit Probleme mit meinem Proxmox-Server das der auch immer wieder ausgestiegen ist ohne erkennbaren Grund.

Lösung war am Ende: im BIOS die Power-Settings der CPU alle ausschalten, seit dem hatte ich keinen einzigen Ausfall mehr.

Intel i217-lm in einem Fujitsu Q920

Naja. Mal sehen… Für tiefgründige Reparaturen reichen meine Kenntnisse nicht. Und mein denglich schonmal gar nicht. :stuck_out_tongue_winking_eye:

In meinem Test System werkelt ein Realtek RTL8111/8168/8411
Ist ja auch klar, das das Produktivsystem von so etwas betroffen ist und nicht das unwichtige Test System…

Ja das Problem ist u.a. auch das es natürlich unzählige Modelle von Intel und Realtek NICs gibt und dann kommen die Hersteller auch noch auf die Idee auch noch verschiedene Revisionen davon auf den Markt zu bringen. Die Realtek USB NICs hier haben z.B. die Bezeichnung RTL8125 (Rev 05) und somit ist das die 5. Revision/Version davon. Je nachdem was dabei dann genau geändert wurde kann es sein das irgendwelche Treiber auch schon wieder angepasst werden müssen und wie üblich hält sich weder Intel noch Realtek so wirklich dafür zuständig dann auch passende und fehlerfrei funktionierende Treiber auch für Linux anzubieten. Somit müssen sich dann um das Thema irgendwelche Linux-Entwickler kümmern und die müssen dann auch noch darauf hoffen das ihnen Intel oder Realtek auch alle relevanten Infos zur Verfügung stellt.

Somit kann es also auch passieren das z.B. ein Modell I219 oder RTL8125 aus dem letzten Jahr keinerlei Probleme mit/unter Linux hatte und mit einer neuen Revision von dem Modell es ggf. wieder Probleme gibt.

Was jetzt Deine Intel I217-LM NIC betrifft: Auch von der gibt es div. Revisionen (mind. 4) und wenn Du im Proxmox Forum einfach mal nach I217-LM suchst wirst Du feststellen das es auch zu der dort div. Postings mit Problemen gibt. Wenn ich das so auf die Schnelle richtig sehe auch schon seit ~ 2021. D.h. die I217-LM taucht u.a. auch immer mal wieder in diesem seitenlangen Beitrag (e1000 driver hang) mit auf. Z.B.:

Und dann kommt natürlich hinzu das Linux Entwickler auch nur Menschen sind :slightly_smiling_face: und im Vorfeld auch nicht (immer) genau klären können welche Änderungen am Kernel und Treibern sich dann wie auf irgendwelche NICs auswirken können oder könnten. Somit kann es halt auch passieren das nach irgendwelchen Updates ggf. irgendwelche Probleme (wieder) auftauchen, von denen man dachte das diese schon lange der Vergangenheit angehören. :laughing:

VG Jim

1 „Gefällt mir“