News Intern: Probleme mit dem Webserver heute Nacht - und wieder da

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Wie unsere Leser bemerkt haben werden war Planet 3DNow! in den letzten 12 Stunden nicht erreichbar. Aufgrund von Problemen mit dem SCSI-Controller haben wir "Das Boot" gestern Abend heruntergefahren, um die Datenintegrität nicht zu gefährden. Anschließlich war kein Start mehr möglich; zumindest nicht mit den Mittel des Nacht-Supports vor Ort. Heute mit dem regulären Support als "Remote-Hands" war der Server - zumindest vorerst - relativ schnell wieder flott.

Wir werden zuerst einmal ausführliche Tests machen, sodass es sein kann, dass die Seite zwischenzeitlich immer mal wieder nicht erreichbar ist. Für diese Zwecke existiert ja bereits seit Jahren unser Fallback-Forum auf planet3dnow.<b>net</b>, wo wir unsere Leser immer auf dem Laufenden halten bzgl. der Arbeiten am Server.

<b>Update 29.09.2009, 13:15 Uhr</b>
Planet 3DNow! ist inzwischen wieder voll einsatzbereit, nachdem alle Komponenten einem ausführlichen Check unterzogen wurden. Was bleibt ist eine lähmende Ungewissheit bzgl. der Ursache des Ausfalls. Kurz chronologisch.

Gestern gegen 18:30 Uhr gab es erste Warn-E-Mails vom Server, dass er das Raid-1 aller SCSI-Platten verloren habe. Bis auf eine konnte im laufenden Betrieb jedoch alles wieder synchronisiert werden. Eine der DB-HDDs jedoch blieb verschollen, auch nach diversen Controller-Resets. Blieb noch einen kompletten Reset zu versuchen, in der Hoffnung, dass das Controller-BIOS die Platte bei einem Neustart wieder finden würde. Allerdings ist ein Reboot bei einem Server immer so eine Sache, der nicht zu Hause neben dem Schreibtisch steht, sondern im fernen Frankfurt am Main 350 km vom nächsten P3D-Admin entfernt.

Und so kam es wie es kommen musste: der Server bootet nicht mehr. Es war 23:30 Uhr Nachts. Im Rechenzentrum ist zu diesem Zeitpunkt nur ein Not-Support anwesend, der Monitor-Meldungen vorlesen oder vielleicht eine Live-CD einlegen, jedoch selbst nichts am Server machen darf, auch unter unserer telefonischen Anleitung nicht. Wir bekamen lediglich die Meldung, dass der Server den Bootvorgang mit "no active partitions" abbrach. Ergo hieß es erst einmal warten, bis der "echte" Support wieder im Rechenzentrum eintraf, um dessen "Remote-Hands" zu nutzen.

Dann jedoch - inzwischen haben wir den 29.09.2009 gegen halb 12 - ging es relativ schnell. Mit dem Mann vor Ort war rasch herausgefunden, dass sich im BIOS die Bootreihenfolge verstellt hatte. Der Server versuchte von einer der IDE-Platten zu booten, die als Backup-Space im Server stecken. Wir fanden heraus, dass das Tyan-Board jedes Mal die Bootreihenfolge auf IDE-0 zurücksetzte, sobald am SCSI-Controller eine Festplatte hinzugefügt oder entfernt wurde. Eine überdenkenswerte Strategie...

Aber abgesehen davon: da der Server seit November 2007 nicht angefasst wurde und seitdem ohne Probleme durchgelaufen ist, bleibt die Frage, wie das sein kann?! Ein SCSI-Kabel, das sich wie von Geisterhand über einen Zeitraum von 2 Jahren selbst lockert und damit als Verkettung unglücklicher Umstände die Bootreihenfolge ändert? Wäre mal was neues. Zumindest würde das erklären, wieso der Controller die Platten im laufenden Betrieb verloren hat und wieso der Server beim nächsten Reboot versucht hat, von IDE zu booten statt von SCSI. Aber als Erklärungsversuch äußerst dürftig.

Inzwischen ist alles wieder hergestellt, alles doppelt und dreifach gecheckt, alle Kabel kontrolliert. Offenbar ist keine der Komponenten defekt. Auch die Software inkl. der Daten scheint keinen Schaden davon getragen zu haben. So erfreulich das auf der einen Seite ist, so unbefriedigend ist dies für das Bemühen die tatsächliche Ursache zu finden und eine Wiederholung in Zukunft auszuschließen.

<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?p=2548179#post2548179">Infos zum Server</a></li><li><a href="http://www.planet3dnow.net" rel="nofollow">Das Planet 3DNow! Fallback-Forum</a></li></ul>
 
fanden heraus, dass das Tyan-Board jedes Mal die Bootreihenfolge auf IDE-0 zurücksetzte, sobald am SCSI-Controller eine Festplatte hinzugefügt oder entfernt wurde. Eine überdenkenswerte Strategie...
*chatt* *rofl*


Die Mail an Tyan ist schon raus, oder?
 
Wir fanden heraus, dass das Tyan-Board jedes Mal die Bootreihenfolge auf IDE-0 zurücksetzte, sobald am SCSI-Controller eine Festplatte hinzugefügt oder entfernt wurde. Eine überdenkenswerte Strategie...
Scheint Standard bei Tyan zu sein. Mit dem Problem darf ich mich hier auch immer wieder herumschlagen. :(

Aber abgesehen davon: da der Server seit November 2007 nicht angefasst wurde und seitdem ohne Probleme durchgelaufen ist, bleibt die Frage, wie das sein kann?! Ein SCSI-Kabel, das sich wie von Geisterhand über einen Zeitraum von 2 Jahren selbst lockert und damit als Verkettung unglücklicher Umstände die Bootreihenfolge ändert? Wäre mal was neues. Zumindest würde das erklären, wieso der Controller die Platten im laufenden Betrieb verloren hat und wieso der Server beim nächsten Reboot versucht hat, von IDE zu booten statt von SCSI. Aber als Erklärungsversuch äußerst dürftig.

Inzwischen ist alles wieder hergestellt, alles doppelt und dreifach gecheckt. Offenbar ist keine der Komponenten defekt. Auch die Software inkl. der Daten scheint keinen Schaden davon getragen zu haben. So erfreulich das auf der einen Seite ist, so unbefriedigend ist dies für das Bemühen die tatsächliche Ursache zu finden und eine Wiederholung in Zukunft auszuschließen.

Mit etwas Glück findet ihr noch in den Logs von Linux und/oder dem Controller Hinweise auf die Ausfallursache. Wenn gar nichts darin dazu geloggt wurde, habt ihr da verloren. Wenn es aber zumindest ein paar Infos in die logs geschafft haben, besteht eine Chance, den Fehler zu rekonstruieren.
 
...
Aber abgesehen davon: da der Server seit November 2007 nicht angefasst wurde und seitdem ohne Probleme durchgelaufen ist, bleibt die Frage, wie das sein kann?! Ein SCSI-Kabel, das sich wie von Geisterhand über einen Zeitraum von 2 Jahren selbst lockert und damit als Verkettung unglücklicher Umstände die Bootreihenfolge ändert?...

War die Putzfrau im Serverraum? :) Wobei... Wenn ich den Server aus dem Link unten anschau... Die Platten sind da intern verbaut?

Oder war es ein Techniker der aus Versehen den falschen Server erwischt und die Platten gezogen hat? :)
 
War die Putzfrau im Serverraum? :) Wobei... Wenn ich den Server aus dem Link unten anschau... Die Platten sind da intern verbaut?

Oder war es ein Techniker der aus Versehen den falschen Server erwischt und die Platten gezogen hat? :)

Der Controller meckert eigentlich recht lautstark, wenn ihm Platten fehlen. Das sollte einem schon mit der ersten Platte zu denken geben, die man entfernt. *buck*
 
Warum wird der Server momentan deutlich wärmer als vor der Downtime?

 
Wahrscheinlich haben die Jungs mal wieder die Schranktür offen gelassen ;)
 
Wenn sie da verschiedene (Last-)Tests gemacht haben hatte das Boot schon etwas zu tun als nur rum zu idlen ^^
 
...

Aber abgesehen davon: da der Server seit November 2007 nicht angefasst wurde und seitdem ohne Probleme durchgelaufen ist, bleibt die Frage, wie das sein kann?! ....

..... So erfreulich das auf der einen Seite ist, so unbefriedigend ist dies für das Bemühen die tatsächliche Ursache zu finden und eine Wiederholung in Zukunft auszuschließen.
.....

Never touch a running System.
And then it not run you can touch this bis it wieder run ^^
 
Warum wird der Server momentan deutlich wärmer als vor der Downtime?

Aber höchst interessant ist da doch, daß die Temperaturen vor dem Ausfall signifikant angestiegen sind. Entweder ein Hardwareschaden oder jemand hat daran gefingert. Jeder Fernsehkommissar würde nun fragen: "Wo waren Sie gestern zwischen 21h und 22h?" *suspect*
 
Die letzte Stunde vor dem Ausfall ist das nicht wirklich verwunderlich. Wir haben alle wichtigen Dinge gesichert, ein MySQL-Dump gemacht, etc. Das belastet die Maschine spürbar, daher sind die Temperaturen in diesem Zeitraum leicht angestiegen. Der Anstieg beginnt um exakt 21:00 Uhr, als wir mit dem Backup angefangen haben, und endet um 22:00 Uhr, als wir die Maschine als letzten Notanker neustarten mussten, weil weder Busreset noch SCSI-Hostadapter-Reset geholfen haben.

Die Jungs haben die Türen mittlerweile wieder verschlossen, die Temperaturen sind auf normales Level gesunken:
sensors_temp-day.png
 
zum glück rennt das kriegsschiff wieder =)

Bin mal gespannt ob ihr da noch etwas heraus bekommt - Ungewissheit ist ätzend
 
Tjaja die Geister in der Maschine ;D
 
Erinnerungen werden wach :-/, damals 2007 als das Boot in einer stürmischen Nacht heftigst Schlagseite bekamm.

Ich drück die Daumen, sicher wars nur die berühmte Putzfrau, die verflixter Weise immer für sowas Verantwortlich zu machen ist. ;D

Gruß Input
 
Allerdings ist ein Reboot bei einem Server immer so eine Sache, der nicht zu Hause neben dem Schreibtisch steht, sondern im fernen Frankfurt am Main 350 km vom nächsten P3D-Admin entfernt.
Wie wärs ev. mal mit einem Remote Insight Board?
Ich administriere praktisch alle Server über diese Boards - sehr praktisch. :)
 
Naja vll. entwickelt unser "Boot", ja langsam ein eigenes Bewusstsein*chatt*
Eine K.I. mit dem Namen das Boot...

lg schieby77;D
 
Verwendet ihr SCSI Terminatoren? Die machen häufiger mal die Grätsche und solche lustige Effekte passieren dann.
 
Der Controller meckert eigentlich recht lautstark, wenn ihm Platten fehlen. Das sollte einem schon mit der ersten Platte zu denken geben, die man entfernt. *buck*
Der Controller hat als erstes einen Dump geschrieben.
Danach war eine Disk einfach weg.
Während des darauf folgenden Bus Resets kam es zu timeouts bei einem weiteren Raid1.

lg
__tom
 
Ein SCSI-Kabel, das sich wie von Geisterhand über einen Zeitraum von 2 Jahren selbst lockert und damit als Verkettung unglücklicher Umstände die Bootreihenfolge ändert?
Dazu muß sich nicht ein kompletter Steckerkorb lösen, es reicht auch, daß irgendwo ein Defekt (evtl. in einem LW) die Signalpegel der Daten-/Steuer-Leitungen komplett in die Knie zwingen. Dann ist der Controller machtlos mit bekanntem Verlauf. Habt ein Augenmerk auf das nicht reanimierbare Laufwerk...
 
Gut solange es so läuft würde ich es belassen, aber bei einer Umrüstung des Server dann mal über SAS nachdenken, dürfte weniger anfällig als SCSI sein.

Und wenn Tyan, keine Lösung für das IDE-Problem hat, würde ich mal ganz stumpf ebenfalls ein bootfähiges System auf IDE-Platten erstellen, ebenfalls im Raid-1 so das das Boot dann halt nicht absäuft sondern nur einen Gang runterschaltet, falls SCSI ausfällt.
 
Ich sehe auf bei munin Boardtemperaturwerte von ~50°C.
Könnte es da bei knapp 30000 Betriebsstunden mal ne Idee sein die Kondensatoren auf Board und SCSI-Controller unter die Lupe zu nehmen? Oder ist sowas völlig ausgeschlossen?
 
Ich sehe auf bei munin Boardtemperaturwerte von ~50°C.
Könnte es da bei knapp 30000 Betriebsstunden mal ne Idee sein die Kondensatoren auf Board und SCSI-Controller unter die Lupe zu nehmen? Oder ist sowas völlig ausgeschlossen?

Wenn die Komponenten drum rum schlecht gekühlt werden und dauerhafte Hotspots enstehen, durchaus möglich. Selbst die Controller Elektronik der Festplatten, kann sehr heiß werden, aber 50 Grad für ein Mobo ist schon recht viel, da ja die Fehlfunktion bei einer der Festplatten ja auch noch nicht geklärt worden ist.

Sollte der SCSI-Controller besserer Natur sein, könnte man versuchen den Verbund anhand eines Files was man damals gespeichert hat, wieder herzustellen. Evt. findet er dann wieder diese Platten oder kann sich am Verbund selbst wieder anmelden. Zumindest geht das bei meinem Raid-Controller, hatte zuvor die Config des Raid-5 abgespeichert, und konnte es so wieder herstellen und die Festplatte erneut anmelden, falls sie nicht defekt ist, aber durch nen defektes Kabel etc. aus dem Verbund geworfen worden ist.
 
Ich sehe auf bei munin Boardtemperaturwerte von ~50°C.
Könnte es da bei knapp 30000 Betriebsstunden mal ne Idee sein die Kondensatoren auf Board und SCSI-Controller unter die Lupe zu nehmen? Oder ist sowas völlig ausgeschlossen?
Ist zwar richtig Dein Hinweis.
Jedoch gibt es bisher keine intermittierende Fehler wie spontane reboots usw.
Letztlich scheint es ein abgegangener SCSI Stecker gewesen zu sein.
Zudem ist sämtliche Abluft vom Server immer ziemlich "kalt" was nicht auf zu große innere Hitze hindeutet.

lg
__tom
 
Zurück
Oben Unten