Hardwareprobleme März 2014 – Post-Mortem

Wir hatten zuletzt ein paar Probleme mit unserer Hardware für Forum und Newsbereich – die Lösung war nicht trivial und wir brauchten auch einige Zeit, bis wir alles wieder im Griff hatten.

Was war passiert?

Wir haben einige Server im Rechenzentrum nicht nur mit einem Netzwerkanschluss zum Internet, sondern jeweils zusätzlich einen Anschluss an ein kleines, privates Netzwerk, in dem sich unsere Maschinen untereinander „unterhalten“ können.

Der Haupt-Datenbankserver für das Forum und den Newsbereich liefert zu Spitzenzeiten Daten mit über 800 Megabit pro Sekunde an die Webserver über unser privates Netzwerk aus. Es häuften sich zuletzt Paketverluste („dropped packets“), die sporadisch, dann aber in sehr großer Zahl auftauchten. Dies führte dann immer wieder dazu, dass ihr zuletzt hin und wieder im Forum Fehlermeldungen zu sehen bekommen habt.

Die erste Vermutung bei Paketverlust ist immer eine schlechte Verkabelung und ich hatte das Ticket ans Rechenzentrum schon fast geschrieben, als ich noch mal die anderen Server im gleichen Netzwerk anschaute. Und siehe da, noch ein Server war davon betroffen. Gleich zwei defekte Kabel auf einmal?

Ich schaute mir die Hardwaredetails der Server dann noch einmal an und fand eine Gemeinsamkeit: die Netzwerkkarte. Beide hatten eine Intel 82574L eingebaut. Eine Recherche im Internet brachte dann die Erkenntnis, dass unsere Server nicht die einzigen sind, die Probleme mit einer Netzwerkkarte diesen Typs haben. Es gab einige Ideen zur Behebung, die aber bei den meisten Leuten und auch bei uns nichts brachten.

Der nächste Schritt war dann das Schreiben eines Tickets ans Rechenzentrum mit der Bitte um Einbau einer neuen Netzwerkkarte.

Ich hatte dann einen Termin am 7. März 2014 um 8:30 für den Einbau der neuen Netzwerkkarte ausgemacht und dieser wurde auch zügig erledigt.

An dieser Stelle möchte ich mal ein kurzes Lob für unseren Hosting-Provider Hetzner Online loswerden: in all den Jahren, die wir jetzt dort sind, gab es noch nie irgendeinen Grund zu meckern – insbesondere der Support macht eine wirklich erstklassige Arbeit. In diesem Preissegment haben wir bisher keinen anderen Hoster mit einer ähnlich hohen Service-Qualität erlebt – und wir kennen mittlerweile durchaus eine Menge preiswerte Hosting-Provider in In- und Ausland.

Ich konfigurierte also die neu eingebaute Netzwerkkarte, lehnte mich entspannt zurück und schaute auf die Monitoring-Programme. Der Maschine sollte ja jetzt schnurren wie ein Kätzchen.

tmux

Denkste! Der Server lief Amok, die Datenbank bekam die Antworten auf ihre Abfragen nicht durch das Netzwerkinterface zum Webserver gesendet und neue Datenbank-Abfragen von den Webservern kamen auch nicht mehr auf dem Datenbankserver an.

Zum Glück hatten die Techniker unserem Wunsch entsprochen, das Kabel der alten Netzwerkkarte noch eingesteckt zu lassen, so dass ich kurzfristig wieder auf die bisherige Konfiguration umschalten konnte.

Jetzt begann das große Rätselraten. Während ich mir die Logfiles und Systemeinstellungen noch mal durchsah, fiel mir auf, dass nun auch noch eine der Festplatten Probleme machte (Auslastung nahe an 100 Prozent) und die Datenbank dadurch stark ausgebremst wurde, was wiederum zu einer langsamen Beantwortung der Abfragen führte. Auch das noch…

Eine kurze Überprüfung mit dem Tool smartctl zeigte, dass die Platte tatsächlich fehlerhaft arbeitete. Also machte ich erneut einen Termin mit dem Support aus – diesmal zum Tausch der Festplatte.

Die Sache mit der Netzwerkkarte legte ich erst mal zur Seite, wichtiger war jetzt die neue Festplatte. Sie wurde auf die Minute genau zum vereinbarten Termin eingebaut und wir konnten den Server kurz danach wieder in Betrieb nehmen. Ich vermute, dass die Pause zum Einbau der Netzwerkkarte – immerhin der erste Power-Cycle nach 15 Monaten Dauerbetrieb – dazu führte, dass die Platte durch die kurzzeitige Temperaturänderung (warm, kalt und wieder warm) versagte. Die neue Platte wurde wieder ins System konfiguriert und das RAID-Rebuild gestartet.

Damit hatte ich jetzt ein Problem weniger – das ursprüngliche war aber nach wie vor ungelöst: die neue Netzwerkkarte war de facto nicht nutzbar.

Also noch mal von vorn. Ich schaute mir jetzt die alles noch einmal in Ruhe an und testete auch den Netzwerk-Durchsatz mit einem synthetischen Benchmark (iperf). Ich stellte fest, dass sie nur einen Bruchteil der erwarteten Geschwindigkeit von 1 Gigabit pro Sekunde erreichte. Dazu kam, dass der Linux-Kernel im Message Buffer Probleme (Absturz des Treibers) mit der neuen Netzwerkkarte anzeigte. Endlich eine Spur!

Es stellte sich relativ schnell heraus, dass der Treiber, den der Linux-Kernel für die Netzwerkkarte lädt, alles andere als ordentlich funktioniert. Die Lösung des Problems war relativ einfach: einen passenden, aktuellen Treiber für die Netzwerkkarte beim Hersteller herunterladen, das Kernel-Modul daraus kompilieren und in den Kernel laden.

Seitdem läuft wieder alles wunderbar, es gibt keine Paketverluste mehr und die Datenbankabfragen werden so schnell beantwortet wie man es erwartet.

2 Gedanken zu „Hardwareprobleme März 2014 – Post-Mortem

  1. Irgendwie stimmt der letzte Absatz nicht. Denn es gibt nach wie vor noch einige Paketverluste. Anstatt der Webseite hat man dann eine weiße Seite mit einem Warnhinweis.

  2. Ja, wie das so ist – löst man ein Problem, kommen drei neue um die Ecke ;-)

    Ich habe eben noch mal ein paar Einstellungen im TCP/IP-Stack der Server angepasst. Ich denke mal, es wird jetzt besser werden. Mehr wissen wir morgen Abend.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.