V-Server wiederholt nicht erreichbar

  • Hallo,
    wir betreiben einen VServer mit einem relativ kleinen Online-Shop und einer überschaubaren Anzahl an Zugriffen.


    Bereits vor ca. 2 Wochen und plötzloch auch heute war der V-Server nicht mehr erreichbar. Auch über SSH konnten wir nicht mehr zugreifen.


    Über das SCP konnten wir zumindest noch einen Blick auf die Konsole werfen. Ihr findet im Anhang einen Screenshot. Könnt ihr durch die Meldungen mögliche Rückschlüsse auf die Ursache ziehen?


    In den Logfiles und auch über den externen Munin-Server gab es unmittelbar vor dem Absturz keine Auffälligkeiten.


    Ich würde mich sehr über Ratschläge freuen. Diese plötzlichen Abstürze machen kein gutes Gefühl.


    Ich danke euch für die Mithilfe.

  • Ich habe gestern Abend noch den Netcup-Support um Hilfe gebeten.


    Als Antwort habe ich einen Link auf die Netcup-Wiki erhalten:


    KVM Tuning – netcup Wiki


    Mir wurde empfohlen, den Ausführungen dieses Artikels zu folgen. Anschließend soll der Sachverhalt nicht mehr auftreten.



    Die wirkliche Ursache leuchtet mir jetzt zwar noch nicht wirklich ein, ich werde es aber trotzdem gern versuchen.

  • Mittlerweile hat es mich ebenfalls erwischt, ich bin auch betroffen. Aktuell nur auf dem System mit der VMX-Option.


    Den erwähnten Wikiartikel arbeite ich jetzt einmal durch.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Nachtrag: Auch am VPS 20 häufen sich ähnliche Probleme in letzter Zeit. Ist mir nur nicht aufgefallen.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)


  • Was habt ihr denn für Server und wie ist dort die I/O Geschwindigkeit der Festplatte?

    Ich habe einen Root-Server L v3.
    - 2 Kerne
    - 8GB Arbeitsspeicher
    - 500 GB Festplatte / Raid 50



    Unter dem folgenden Link habe ich noch weitere Informationen gefunden:
    Linux Kernel panic issue: How to fix hung_task_timeout_secs and blocked for more than 120 seconds problem - blackMORE Ops


    Verstehe ich es richtig, dass der Fehler auf eine steigende Festplattenauslastuing zurückzuführen ist? Müsste ich dann über Munin nicht entsprechende i/o Werte feststellen?


    Ich habe aktuell eine durchschnittliche I/O Wait Time von 280 ms.

  • Tolive: Beim VPS 20 scheint es nach genauerer Betrachtung aber ein etwas anderes Problem zu sein und nicht direkt mit der I/O Leistung zu tun haben. Da habe ich eventuell zu früh "hier" geschrieben.


    Bezüglich meines anderen Servers: RS2000+ (SAS) mit 4 Kernen und 10GB Ram. I/O Leistungseinbrüche kann ich normalerweise keine feststellen, meine I/O Anforderungen halten sich in Grenzen. Im Moment habe ich das Problem, dass einzelne Qemu-Prozesse komplett Amok laufen, in den Gastsystemen eine Kernel Panic ausgelöst wird und libvirtd nicht mehr richtig mit dem Kernel kommunizieren kann. Da meine eigenen VMs dadurch abstürzen, ist das aktuell eine untragbare Situation für meine drei MySQL-Slaves, die u.a. darauf laufen. Ich kann aktuell öfters das Relay-Log wiederherstellen, als es mir lieb ist. Dass es am KVM-in-KVM Setup liegt, kann ich natürlich nicht ausschließen. So oder so muss ich das irgendwie lösen, ansonsten bin ich gezwungen mir etwas anderes einfallen lassen. Mehr als 22 Euro pro Monat für ein System, das u.a. fürs Backups dient, die im Ernstfall nichts bringen, sind irgendwie nicht Sinn der Sache. Nicht umsonst habe ich beim gestrigen Aktionsserverchen aus dem Adventkalender zugeschlagen. Ich trau der Festplatte bzw. der Integrität des Dateisystems nicht mehr und lege die wichtigsten Daten temporär zusätzlich dort ab.



    MfG Christian


    PS: Die I/O Werte bei einem alten Osteraktionsserverchen sind größtenteils nicht so berauschend und waren sie auch nie. Da der aber sehr günstig ist, kann ich gut damit leben. Probleme mit hängen bleibenden Prozessen oder kompletten Serverabstürzen gab es dort in mehreren Jahren aber noch nie. Und dort hätte ich am ehesten damit gerechnet.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • ... Im Moment habe ich das Problem, dass einzelne Qemu-Prozesse komplett Amok laufen, in den Gastsystemen eine Kernel Panic ausgelöst wird und libvirtd nicht mehr richtig mit dem Kernel kommunizieren kann. Da meine eigenen VMs dadurch abstürzen, ...


    Welches Betriebssystem mit welcher Versionsnummer nutzt du zur KVM-Virtualisierung? Und hast du auch die nötigen Treiber auf deinem RS... und auf deinen einzelnen VM´s installiert?


    Ob die nötigen Treiber installiert sind, kannst du mit folgendem Befehl abfragen und das Ergebnis würde dann in etwa wie folgt aussehen:


  • Welches Betriebssystem mit welcher Versionsnummer nutzt du zur KVM-Virtualisierung? Und hast du auch die nötigen Treiber auf deinem RS... und auf deinen einzelnen VM´s installiert?


    Debian Jessie (8.x) in allen Systemen. Die virtio-Module sind dort standardmäßig vorhanden und werden auch genutzt. Allgemein habe ich das System nahezu gleich zu meinem KVM-Host zu Hause eingerichtet. Spontan würde ich sagen, dass es fast nur zwei mögliche Ursachen geben kann: Probleme am netcup-Node oder irgendetwas, das sich mit der Nested-Virtualization nicht verträgt. Die jetzigen Probleme sind auch neu, die gab es seit Oktober nicht. Davor gab es andere I/O-Probleme, die vermutlich durch das Online-Discard ausgelöst wurden.


    Falls es sich nicht bessert, melde ich mich nächste Woche einmal beim Support. Vorher will ich aber sicher gehen, dass ich alles in meinem Einflussbereich bestmöglich ausgeschlossen habe.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Debian Jessie (8.x) in allen Systemen.


    Eventuell hilft dir folgender Erfahrungsbericht weiter:
    Seit Anfang des Jahres 2016 habe ich mich neben OpenVZ und OpenVZ 7 auch intensiv mit der Virtualisierungstechnologie KVM beschäftigt und zu Beginn auf meiner Teststellung das Betriebssystem Ubuntu 14.04 LTS und danach auch 16.04 LTS verwendet. Da ich ähnliches labiles Verhalten wie von dir hier beschrieben auch auf meiner Teststellung feststellen konnte, bin ich dann auf CentOS 7 umgestiegen. Seit Anfang September diesen Jahres nutze ich auf meinen großen Server mit mehr als 10GB RAM, der mittlerweile produktiv eingesetzt wird, problemlos die Virtualisierungstechnologie KVM mit 4 virtuellen Servern.


    Auf einer der virtuellen Server habe ich sogar OpenVZ 7 mit 4 weiteren VM´s installiert, die auch problemlos darauf laufen.


    Weiterhin habe ich auch auf dem Hostsystem auf ressourcenhungrige Anwendungen wie z.B. einem Adminpanel zur bequemeren Administration der einzelnen VM´s und auf Grafiksoftware, die z.B. aus den gesammelten Logs Linien- oder Balkendiagramme erzeugt oder auf z.B. dem Befehl Trim verzichtet.


    Das Hostsystem wird auch nicht überbucht, so dass nicht nur jeder VM stets ihre zugewiesenen Ressourcen zur Verfügung gestellt werden können, sondern auch dem Hostsystem.


    Unter CentOS 7 wird derzeit zur KVM-Virtualisierung die Kernelversion "Linux ... 3.10.0-514.2.2.el7.x86_64 #1 SMP Tue Dec 6 23:06:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux" genutzt.

    2 Mal editiert, zuletzt von Exmember01 ()

  • Vicman Nein, wenn I/O wait und Geschwindigkeit in Ordnung sind, wird es sehr wahrscheinlich an der CPU liegen. Im PROXMOX Forum gibt es mehrere Threads mit ähnlichen Probleme. Dort werden als Ursache häufig Haswell CPUs mit älteren Linux Kernen und der virtio Treiber genant. Offiziell ist das Problem bei PROXMOX in der aktuellen Version gelöst ... offiziell.


    Ansonsten kann der Fehler mit der von netcup beschriebenen Lösung (Punkt 2) umgangen werden. Man sollte jedoch wissen, was es bewirkt und ob die entsprechenden Nebeneffekte für einen akzeptabel sind. Die hat netcup aber auch im wiki beschrieben.


    KB19 Ja, mein Oster-Server von 2015 läuft auch sehr gut. Wollte diesen eigentlich durch den Winter-RS ablösen, habe aber leider keinen mehr bekommen :(. Muss der bis nächste Weihnachten noch seine Arbeit verrichten.


    Bzgl. der anderen Probleme: Konfigurierst du selbst oder nutzt du PROXMOX oder etwas ähnliches?


    Ansonsten glaube ich nicht, dass es an der VM in der VM liegt, da das Problem ja auch welche haben, die nicht virtualisierung. Allerdings, insbesondere wenn es tatsächlich an der CPU im Zusammenhang mit dem VirtIO Treiber oder Kernel liegt, könnte die zusätzliche Virtualisierung das Problem natürlich eher hervorrufen.

  • Ich nutze Libvirt(d), alles andere ist manuell konfiguriert. Die Sache mit der CPU ist vielleicht gar nicht so verkehrt. Ich könnte mal das Upgrade auf Stretch versuchen oder wenigstens ein neuerer Kernel aus Backports.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Langsam tritt es fast täglich auf. Das ist definitiv neu, das gab es in den letzten Monaten nie. Kernelupdate gab es dazwischen auch keines. Mittlerweile dürfte es fast nur bei jenem Gastsystem auftreten, das die meisten MySQL-Queries abbekommt. Oder es liegt daran, dass ich es schnell genug bemerke und den betroffenen Gast "zerstöre". Meistens fangen nach ein paar Stunden nämlich alle VMs der Reihe nach an Probleme zu bekommen.


    Ich werde heute Nacht noch einen neueren Kernel einspielen und mich nächste Woche an den Support wenden. Vielleicht fällt denen noch etwas dazu ein.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Moin

    Ich werde heute Nacht noch einen neueren Kernel einspielen und mich nächste Woche an den Support wenden. Vielleicht fällt denen noch etwas dazu ein.


    Ich habe die gleichen Probleme, mehrere Abstuerze meiner virtuellen Maschinen am Tag. Habt ihr schon irgendwas heraus gefunden?


    Hostsystem: Ubuntu 16.04.1 LTS
    CPU: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz



    KVM zum virtualisieren. Netzwerkkarten auf virtio und auch die festplatten virtio mit qcow2 Images.


    Client Systeme auch alles Ubuntu.


    Die Tips aus dem Wiki habe ich schon eingebaut, aber scheinen auch nicht zu helfen.


    Gabs schon Kontakt zum Support?


    Nachtrag: VMX Option ist gebucht.



    LG Marc

  • ... Seit Anfang September diesen Jahres nutze ich auf meinen großen Server mit mehr als 10GB RAM, der mittlerweile produktiv eingesetzt wird, problemlos die Virtualisierungstechnologie KVM mit 4 virtuellen Servern.


    Noch ein Nachtrag bzw. Richtigstellung zu meinem Beitrag vom 23.12.2016 um 23:47 Uhr:
    Der im Beitrag genannte große Server ist kein virtueller Server, sondern ein dedizierter Server bei einem Fremdanbieter. Also echte Hardware.


    Auf einen virtuellen Server bei Netcup mit der Bezeichnung RS 6000 SAS G7 SE läuft seit einigen Monaten sehr stabil und zuverlässig OpenVZ 7 auch mit vier VM´s bzw. Containern.

    • Offizieller Beitrag

    Wir sehen derzeit keinen Zusammenhang zum VMX Flag.


    Es kann dennoch durchaus helfen die vm.dirty sysctl Werte zu setzen. Mit diesen haben wir auch bereits gute Erfahrungen bei unseren Managed vServern gemacht.


    Der drop_caches Cronjob kann dann aus der "/etc/cron.d/kernel" entfernt werden. Danach sollte man den crond allerdings noch einmal neu starten.

  • ... Mit diesen haben wir auch bereits gute Erfahrungen bei unseren Managed vServern gemacht.


    Soll dass heißen, dass Sie selber auch in einem vollviertualisierten Server (KVM-Server) bzw. einer VM die "Managed vServer" vollvirtualisieren?

    • Offizieller Beitrag

    Soll dass heißen, dass Sie selber auch in einem vollviertualisierten Server (KVM-Server) bzw. einer VM die "Managed vServer" vollvirtualisieren?


    Nein soll es nicht. Wie bereits geschrieben sehen wir keinen Zusammenhang zum VMX Flag.
    Das hung_task verhalten kann auch bei vServern ohne VMX flag und somit ohne nested Virtualization auftreten. Die Managed vServer von denen ich sprach sind normale vServer wie die Root-Server Serie. Mit dem Unterschied, dass wir die Administration des Systems übernehmen und der Kunde keinen root Zugriff erhält