RS 4000 SSDx4 G8SE BF19 stürzt ungefär alle 5 - 10 Stunden ab

  • Guten Tag.


    Ich habe am Black Friday einen RS 4000 SSDx4 G8SE BF19 bestellt. Mittlerweile ist der Server schon seit fast 2 Wochen fester Bestandteil meines Kubernetes Clusters. Ich habe die Node wie alle anderen auch mit dem CentOS 7 Image aufgesetzt und danach mein Installation-Script ausgeführt. Schlussendlich wurde der RS in meinen Cluster integriert. Alles schien Problemlos zu laufen. Nun habe ich aber im laufe von rund einer Woche einige Abstürze festgestellt. Ich verwende das Monitoring-Tool Grafana. Ich prüfe die Uptime nun rund 2 mal täglich und stelle fest das die Uptime immer so zwischen 4 und 12 Stunden liegt, während die Uptime meiner übrigen Nodes bei mehreren Wochen liegt..


    Meine Frage ist nun, wie finde ich die Absturzursache heraus?

    pasted-from-clipboard.png


    Wie man hier auch sieht, ist der Server nicht übermäßig ausgelastet. Außerdem habe ich den Uptime Wert mit der Ausgabe des Befehls "uptime" abgeglichen. Die Ergebnisse sind nahezu identisch.



    Ich hoffe es kann mir jemand helfen.


    Vielen Dank

    Lg

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Ich habe mal Google bemüht und somit habe ich die Datei /var/log/dmesg angesehen, konnte aber keine Auffälligkeiten feststellen.

    Welche Logs wären in dem Fall sinnvoll genau zu untersuchen?


    pasted-from-clipboard.png

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Ich würde zunächst mal schauen, ob in


    Code
    1. journalctl -b-1

    etwas brauchbares zu finden ist. Am besten direkt ganz ans Ende scrollen (oder alternativ die Reihenfolge mit "-r" umdrehen). Was wären denn da die letzten Einträge, die das System vor dem Reboot gemeldet hat? Das System scheint ja anschließend wieder sauber hochgekommen zu sein.

  • Code
    1. # journalctl -b-1
    2. Specifying boot ID has no effect, no persistent journal was found

    Persistent Journal war nicht aktiviert. Ich muss wohl den nächsten Absturz abwarten.

    mit journalctl -b konnte ich ebenso keine Nennenswerten Fehler feststellen.


    Ich habe mir die Boot Logs der letzten Tage angesehen, die Startvorgänge verlaufen ohne Probleme.

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Du kannst vielleicht trotzdem mal in die Dateien "dmesg.old" und "messages.*" schauen. In CentOS 7 läuft ja standardmäßig auch noch ein rsyslog. Das mit dem journactl wäre nur eine andere (aus meiner Sicht einfachere) Möglichkeit gewesen.

  • Laut Netcup ist er seit über 11 Tage Online, aber bei der Eingabe von:

    Code
    1. $ uptime
    2.  15:35:36 up  7:25,  3 users,  load average: 0.64, 1.23, 1.39

    erhalte ich eine Uptime von 7:25

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Das eine ist, wie lange die VM läuft, das andere wie lange dein OS läuft. Zwei paar Schuhe.

    Das hab ich mir schon gedacht, allerdings habe ich versucht die Frage von A:H zu beantworten.


    Ist der Host selbst Down oder ist er nur aus Sicht der API down?

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Im Grafana.

    Problem bei Grafana ist, das auch hier die Metric-Daten nicht Persistent gespeichert wurden, ich habe das erst vor wenigen Stunden in der Konfiguration umgestellt.

    pasted-from-clipboard.png


    Ich muss wohl abwarten ob/wann der nächste Crash passiert um die Daten besser Analysieren zu können.

    HOSTING42 - Eine "Container as a Service" Plattform - Work in Progress - Tester gesucht

    Mehr auf www.hosting42.at | Anfragen gerne an office@hosting42.at

  • Hat denn deine Logfile Analyse etwas ergeben? So ohne Grund startet ein Server ja nicht neu. So ohne weitere Hinweise werden wir hier auch nur ganz schwer weiterhelfen können. Ein paar mehr Informationen müsstest du uns schon geben.


    Achja, was sagt denn die Uptime im SCP? Nur um mal auszuschließen, dass der Wirt die VM rebootet hat.