Ausfall eines VServers

  • Hallo zusammen,


    Wir hatten gestern Abend um 20:11 Uhr einen Ausfall eines unserer VServer.

    Allerdings wundern wir uns über die Ursache, denn von unserer Seite wurde seit mindestens Januar nichts am System gemacht.


    Was wir festgestellt haben ist:


    Wir kamen ab 20:11 Uhr von außerhalb gar nicht an das System ran, weder per IPv4 noch IPv6.

    Meldung per ping war, dass die IP nicht erreichbar wäre.

    Per VNC kamen wir auf das System. Von dort aber zu keinem System.

    Meldung bei ping auf google.de war, dass das Netzwerk nicht erreichbar wäre.


    Im Logfile steht aus unserer Sicht gar nichts auffälliges außer, dass ab 20:11 Uhr

    externe Systeme nicht erreichbar wären. Der erste Eintrag dazu im Debian-syslog:


    Mar 20 20:11:27 mail freshclam[640]: Fri Mar 20 20:11:27 2020 -> Received signal: wake up

    Mar 20 20:11:27 mail freshclam[640]: Fri Mar 20 20:11:27 2020 -> ClamAV update process started at Fri Mar 20 20:11:27 2020

    Mar 20 20:11:27 mail freshclam[640]: Fri Mar 20 20:11:27 2020 -> ^Can't query current.cvd.clamav.net

    Mar 20 20:11:27 mail freshclam[640]: Fri Mar 20 20:11:27 2020 -> ^Invalid DNS reply. Falling back to HTTP mode.

    Mar 20 20:11:27 mail freshclam[640]: Fri Mar 20 20:11:27 2020 -> Reading CVD header (daily.cvd): Fri Mar 20 20:11:27 2020 -> ^remote_cvdhead: Download failed

    (6) Fri Mar 20 20:11:27 2020 -> ^ Message: Couldn't resolve host name


    Der Kernel meldete einzig das:

    Mar 20 20:13:05 mail kernel: [2678893.429066] nfs: server 46.38.248.210 not

    responding, timed out


    Hat hier jemand ein Idee dazu ?

    Laut Netcup liegt das Problem bei unserer Maschine...

  • Was ich da sehe ist, dass keine DNS Auflösungen möglich sind.


    Was steht denn in eurer /etc/resolv.conf ?

    Weitere Hinewise zur DNS Konfiguration findet ihr hier.


    Wie schaut eure /etc/network/interfaces aus? (IP Adressen könnt ihr unkenntlich machen)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Das war ein temporärer Ausfall, der sich durch einen reboot erledigt hatte.

    Dies kann aber keine Basis für eine Fehlersuche sein. einfach das System neu zu booten.


    Wenn wir das Problem nicht erkennen können, dann ist ein produktives Arbeiten nicht mehr möglich.

    Es kann nicht sein das das System - ohne einen Eingriff - einfach seinen Dienst verweigert.


    /etc/resolv.conf

    nameserver 46.38.225.230

    nameserver 46.38.252.230


    # This file describes the network interfaces available on your system

    # and how to activate them. For more information, see interfaces(5).


    source /etc/network/interfaces.d/*

    # The loopback network interface

    auto lo

    iface lo inet loopback


    # The primary network interface

    auto eth0

    iface eth0 inet dhcp

    iface eth0 inet6 static

    address 2a03:4000:15:342::1

    netmask 64

    gateway fe80::1

  • Sieht jetzt erstmal nicht weiter auffällig aus...


    Mein Tipp wäre spontan, dass ihr auf jeden Fall mal IPv4 von DHCP auf statisch umstellt.

    Habt ihr das sysctl File für IPv6 entsprechend Netcups Empfehlung angelegt?



    Patcht ihr das System regelmäßig und achtet ihr vor allem auch darauf, dass es immer wenn notwendig einen reboot bekommt (Kernel Update)?

    Auf welcher Debian Version seid ihr unterwegs?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Hmm. Buster...


    Warum heißt dann bei euch in der Konfiguration der Netzwerkadapter eth0? Bei meinen Buster Servern hier bei Netcup heißt der immer ens3.

    Habt ihr einen anderen Treiber im SCP ausgewählt? Oder liegt da vielleicht sogar das Problem? :/

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Da muss ich mal schauen ...

    Das würde aber immer noch nicht erklären warum das 2 Monate problemlos läuft und dann auf einmal nicht mehr.

    Ohne Menschliches zutun...

    Na öhm... ums mal grob zu beschreiben: DHCP lease läuft irgendwann mal ab, NetworkManager tut Dinge, dhclient tut Dinge, beide versuchen eine ungültige Netzwerkconfig zu lesen und dann bumm... also vielleicht. Wäre jetzt meine wage Theorie.


    Die falsche Config kann ja auch noch von einem Upgrade von einer alten Debian Version übrig sein. Wer weiß... ?(

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Warum heißt dann bei euch in der Konfiguration der Netzwerkadapter eth0? Bei meinen Buster Servern hier bei Netcup heißt der immer ens3.

    Wenn das System von einer alten Version upgegraded wurde, völlig normal. Außerdem kann man es auch bei Neuinstallationen so konfigurieren, dass es bei den eth-Bezeichnungen bleibt.

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

  • Das System wurde Anfang Januar von Debian 9 auf 10 aktualisiert. Seither hatten wir einen Reboot im Februar, weil bei Netcup mal ein kompletter Ausfall einer Node war, der auch unsere Festplatte in Mitleidenschaft gezogen hat. Danach haben wir 2 Festplattenprüfungen erfolgreich durchlaufen lassen. Seither lief aber alles - rund 40 Tage glaube ich.

  • Der Thread ist an Großartigkeit nicht zu überbieten.


    "Ups es geht nicht mehr"

    "Verrückt, nach nem Reboot gehts wieder"

    "Seit Januar haben wir das System nicht mehr angefasst"


    Bin gespannt, was noch so kommt.


    Edit: Ich werde das Gefühl nicht los, dass der TO hier nicht wirklich weiss was er tut und die Schuld in Richtung netcup versucht zu schieben.

  • Ich werde das Gefühl nicht los, dass der TO hier nicht wirklich weiss was er tut und die Schuld in Richtung netcup versucht zu schieben.

    Manchmal verklemmt sich halt etwas, besonders wenn man einen Mix aus DHCP und statischer IP für das selbe Interface zu verwenden.

    Wo liest du da die Schuldzuweisung?

  • Manchmal verklemmt sich halt etwas, besonders wenn man einen Mix aus DHCP und statischer IP für das selbe Interface zu verwenden.

    Wo liest du da die Schuldzuweisung?

    Klar knackt es da im Gebälk. Aber wenn ich sowas lese wie "Ja ein Reboot kann ja nicht die Lösung sein" und es danach augenscheinlich wieder funktioniert hat da wundere ich mich doch ein wenig.


    ramstein links neben der leertaste ^^

  • hat noch jemand Ideen ?


    das vermeintlich komische das die Domain für einen kurzen Zeitraum nicht "da" war.

    Wir dachten zuerst an ein Routingproblem, aber nachdem keiner der Verantwortlichen, alle mit verschiedenen Providern, keinen Zugriff per SSH bekamen war das eigentlich hinfällig.

    Dann frage ich mich was das booten in das Rettungssystem mit diesem Problem zu tun haben sollte. Wenn ich das richtig verstanden habe dann mountet Netcup das Image über das interne (netcup) Netzwerk. Da findet keine Namensauflösung statt, oder ?

  • Ich vermute hier hat sich irgendwas im OS verworren oder so. Wenn kern.log und syslog keinen Aufschluss geben, dann wird es wohl vermutlich keiner können.


    Ich glaube, wie es H6G bereits erwähnte, an Probleme mit der gemischten Interface Konfiguration. Macht die ordentlich, rebootet die Kiste nochmal und checkt ob alles läuft.


    Dann richtet ihr euch ein externes Basismonitoring ein (Worldping wäre da eine kostenfreie Möglichkeit) und hofft, dass es nicht wieder passiert.

    Erst wenn das ganze dann nochmal auftritt, würde ich mir wirklich Gedanken machen. ;)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Wenn das System regelmäßig gepatcht wird – sei es nun (semi-)automatisch oder händisch –, dann haben sich in den zwei Monaten bestimmt Änderungen ergeben. Auch ohne Änderungen kann man je nach Anzahl und Umfang der installierten Programme nicht ausschließen, dass man früher oder später einmal Probleme haben wird.

    Die genannten Fehlermeldungen sind auch unterschiedlich – ich vermute aus der Beschreibung einmal einen vollständigen Ausfall der IPv4-Konnektivität. Clamav bekommt keine DNS-Daten mehr, weil der DNS-Server nicht kontaktiert werden kann; aber nfs arbeitet eigentlich ohne dynamische (d.h. wiederholte) Adressauflösung, und dort steht ja, dass eine IP nicht erreichbar war. (Das erscheint mir ggf. ein genauerer Hinweis auf mögliche Ursachen.)

    Ich würde anraten, Dienste nach Möglichkeit sowohl über IPv4 als auch IPv6 verfügbar zu machen/zu nutzen. Stimmt obengenannte Hypothese und wird die Netzwerkschnittstelle durch einen Reboot "wiederbelebt", hilft das Rettungssystem wenig bei Eingrenzung der Fehlerursache, sofern der Fehler nicht so häufig auftritt, dass es sich lohnt, das Rettungssystem beispielsweise einmal über das Wochenende durchlaufen zu lassen (sofern auf den Server in dieser Zeit verzichtet werden kann).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo,


    ich hatte das bei einem meiner VServer neulich auch. Das Netzwerkinterface war weg. Sohwohl IP V4 als auch V6. Über das VLAn kam ich noch rauf.

    Ein IFDOWN und IFUP haben das Problem behoben, trotzdem denke ich das da im Netzwerk irgendwas passiert ist was nicht hätte passieren sollen.


    Da ich zu dem Zeitpunkt allerdings zu beschäftigt war um mich mit Netcup zusammen noch um ein Ticket zu kümmern habe ich davon abgesehen das weiter zu eskalieren.


    Eckhard