Problem mit RAID

M

Mr.Check

New Member
Moin moin,

mir ist vor ner knappen Stunde ein Server um die Ohren geflogen - supergeiler Zeitpunkt dafür, oder? ;)

Nachdem das Monitoring Alarm geschlagen hat und auch ein SSH-Zugriff nicht mehr funktioniert hat, bin ich über den KVM-Switch auf die Kiste. Da hat sich nur die Meldung "sd 0:0:0:0: rejecting i/o to offline device" immer wieder wiederholt, und der Server war absolut nicht mehr ansprechbar. Beim ersten Reboot hat mir der Raid-Controller (3Ware 9650SE-4LPML) gesagt, dass eine Festplatte im DEGRADED Status ist und der Reboot ist mit ner Kernel Panic abgebrochen. Beim zweiten Reboot war der Status immerhin schonmal auf Rebuild und die Kiste ist zumindest mal wieder hochgefahren.

Aktuell sieht das Ganze so aus:

Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-10 REBUILDING 52% - 256K 1862.62 RiW ON

VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 DEGRADED u0 931.51 GB SATA 0 - WDC WD1002FBYS-02A6
p1 ECC-ERROR u0 931.51 GB SATA 1 - WDC WD1002FBYS-02A6
p2 OK u0 931.51 GB SATA 2 - WDC WD1002FBYS-02A6
p3 OK u0 931.51 GB SATA 3 - WDC WD1002FBYS-02A6


Hat jemand eine Idee, was genau da passiert sein kann und was ich jetzt am besten mache, um die Kiste am Leben zu erhalten? Natürlich werd ich jetzt erstmal den Rebuild abwarten, aber irgendwas muss ja zu diesem Problem geführt haben und das sollte wenn möglich, nicht so schnell nochmal passieren. Mail an den Hersteller-Support ist schon raus, aber das kann ja ggf. dauern.


der Andi
 
Verhalten und die Ausgabe von tw_cli lassen ziemlich gut auf 2 defekte Festplatten schließen. Wenn er mit Kernelpanic und IO Errors reagiert, werden die 2 Festplatten wohl auch zu der einen Raid0 Hälfte deines Raid10 gehören.
Wenn du den Rebuild nun auf die defekte Platte machst, kannst du damit rechnen, dass dir das System bald wieder um die Ohren fliegt.

Tausche p0, hoffe drauf, dass er das Raid wieder zusammen bekommt und tausche dann p1.
Ansonsten bleibt zu hoffen, dass du ein Backup hast. ;)

Es gibt im übrigen ungünstigere Zeitpunkte fürn Systemausfall. :p
 
Dank dir für deine Antwort.

Aber irgendwo muss da doch der Wurm drin sein. Heute Morgen kamen während des Rebuilds u.a. noch folgende Meldungen:

Dec 26 06:12:10 carrie kernel: 3w-9xxx: scsi0: AEN: ERROR (0x04:0x0009): Drive timeout detected:port=3.
Dec 26 06:12:13 carrie kernel: 3w-9xxx: scsi0: AEN: ERROR (0x04:0x0002): Degraded unit:unit=0, port=3.
Dec 26 06:12:17 carrie kernel: 3w-9xxx: scsi0: AEN: ERROR (0x04:0x0009): Drive timeout detected:port=3.
Dec 26 06:13:03 carrie kernel: 3w-9xxx: scsi0: AEN: ERROR (0x04:0x003A): Drive power on reset detected:port=3.
Dec 26 06:13:03 carrie kernel: 3w-9xxx: scsi0: AEN: WARNING (0x04:0x0019): Drive removed:port=3.
Dec 26 06:13:03 carrie kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x001A): Drive inserted:port=3.
Dec 26 06:13:05 carrie kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x003B): Rebuild paused:unit=0, subunit=1.
Dec 26 06:13:05 carrie kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x001F): Unit operational:unit=0.
Dec 26 06:13:28 carrie kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x000B): Rebuild started:unit=0, subunit=1.
Dec 26 06:14:28 carrie kernel: 3w-9xxx: scsi0: AEN: INFO (0x04:0x000B): Rebuild started:unit=0, subunit=0.

Der Zustand des Raid ist gerade wie folgt:

Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
------------------------------------------------------------------------------
u0 RAID-10 REBUILDING 51% - 256K 1862.62 RiW ON

VPort Status Unit Size Type Phy Encl-Slot Model
------------------------------------------------------------------------------
p0 DEGRADED u0 931.51 GB SATA 0 - WDC WD1002FBYS-02A6
p1 OK u0 931.51 GB SATA 1 - WDC WD1002FBYS-02A6
p2 OK u0 931.51 GB SATA 2 - WDC WD1002FBYS-02A6
p3 DEGRADED u0 931.51 GB SATA 3 - WDC WD1002FBYS-02A6


Kann es nicht eher sein, dass der Controller einen an der Pfanne hat?
 
Ich hatte unerklärliche Probleme bei diesem Controller mit einem 26er Kernel. Da stiegen diverse Platten desöfteren einfach aus. Beim Rebuild war dann Schluß -> Orphaned Inodes und sonnem Kram -> fsck -> Kernel Update -> Kiste wieder up und seit dem am leben.
 
Es könnte eben so gut Controller, Backplane oder Kabel defekt sein. Oder du hast einfach nur Pech gehabt und 3 von 4 Platten sind gleichzeitig kaputt gegangen. ;)
 
Nächstes Symptom, bei dem ich irgendwie keinen Zusammenhang zu den anderen Problemen sehe:

Auf dem Supermicro-Mainboard ist ein IPMI-Interface integriert. Seit gestern Abend/Nacht bekomm ich keine http- oder https-Verbindung mehr. Anpingbar ist die IP allerdings noch.

Naja ich werd mal die virtuellen Maschinen evakuieren und dann mal sehen. Für Tipps oder Hilfestellungen bin ich natürlich weiterhin dankbar!
 
Könnte auch zu wenig Strom bzw. "schlechter" Strom (bezogen auf den Output zur Hardware hin vom Netzteil) sein. Da steigen dann irgenwelche Geräte bei Last einfach aus.
 
Wenn ich so recht drüber nachdenke, bleibt wohl nichts anderes als die gesamte Kiste zu tauschen.

Möglich wären Fehler bei:

- Festplatten
- Controller
- Mainboard
- Netzteil
- Kernel

Bis ich das alles durchgetauscht habe, ist aller Tage Abend. Vor allem wüsste ich nicht, wie lange ich den Server nach dem Tausch jeweils eines Bauteils laufen lassen sollte, um ihn wieder produktiv zu machen.

Dass der Kernel generell Probleme mit dem Controller hat.. ich weiß es nicht. Immerhin lief der Server monatelang sauber.
 
Bei mir wars nicht direkt der Kernel sondern der 3Ware Treiber welcher in dem Kernel war, welcher das "Verifying" bei bestimmten Konstellationen nicht richtig zuende führen konnte. Somit kam das Problem erst als die erste Platte mal "rausrutschte"...
 
Das kommt immer drauf an wie wichtig die Kiste ist...

Ich würde erstmal bei bekannten Software Bugs anfangen. Schauen welcher 3Ware Treiber konkret drin ist, dann schauen welche Bugs sich dazu finden lassen und ob etwas zu der Problematik passt.

Einen richtig defekten Controller hatte ich schon lange nicht mehr.

Meistens war der Spuk nach Tausch von RAM, Board oder Netzteil vorbei. Wenn nicht der neue Kernel schon den Bug behoben hatte.
 
Hast Du noch irgendwelche Monitoring-Möglichkeiten?
Könnte (z.B. durch einen ausgefallenen Lüfter) die Temperatur im Chassis zu hoch sein?

Ansonsten würde ich DjTom-i beipflichten und als erste Ursache die Spannungsversorgung untersuchen.
Viellicht zeigt sich da ja auch etwas auffälliges im Monitoring.
Falls ein Ersatznetzteil greifbar ist - tauschen und weiter beobachten.

Kernkomponenten wie CPU, RAM und Chipsatz halte ich für weniger wahrscheinlich, da der Fehler ja vom autonom arbeitenden BIOS des RAID-Controllers signalisiert wird. Insbesondere das Event Dec 26 06:13:03 deutet auf einen Brownout hin.
Eventuell kann man den Multilane-Stecker nochmal begutachten, möglicherweise ist er ja bei einer anderen Wartung leicht herausgerutscht.

Falls es ein Komplettsystem z.B. von HP ist, sollte es auch soetwas wie einen Platform Confidence Test dazu geben, den man laufen lassen kann - ansonsten einfach einen klassischen Stresstest.

PS: Falls es ein gemietetes System ist, würde ich auf jeden Fall Ersatz vom Anbieter fordern.
 
Whistler said:
Hast Du noch irgendwelche Monitoring-Möglichkeiten?
Click to expand...

Naja, normalerweise das IPMI, aber das hat sich ja gestern Abend auch verabschiedet. Bis dahin hat es allerdings alle Lüfter grün angezeigt.

Whistler said:
Falls ein Ersatznetzteil greifbar ist - tauschen und weiter beobachten.
Click to expand...

Mit dem Tauschen und Beobachten weiß ich nicht. Das Problem kann ja nach einem Tag, einer Woche oder vielleicht auch nie wieder auftauchen. Vielleicht verhält der Server sich ja jetzt sogar ohne dass ich etwas veränder eine ganze Weile normal.

Whistler said:
PS: Falls es ein gemietetes System ist, würde ich auf jeden Fall Ersatz vom Anbieter fordern.
Click to expand...

Gemietet nicht, aber ist noch Garantie drauf. Muss mir halt nur überlegen, für welches Teil ich gerne Ersatz hätte ;)

.. In der LSI Knowledge-Base habe ich was gefunden, dass der 9650SE wohl erst ab Kernel 2.6.19 unterstützt wird (ich fahre ja mit 2.6.18 und soweit ich weiß gibt es für Virtuozzo auch keinen neueren. Bei Virtuozzo 4.5 steht der Controller sogar in der Komp.-Liste, für meine Version 4.0 ist leider keine mehr online). Macht diese Variante in euren Augen Sinn? Immerhin lief es damit einige Monate und ein weiterer Server mit dem gleichen Kernel und einem Controller der selben Serie ist jetzt auch schon 270 Tage up. Dass gestern Abend eine besonders große Last auf dem Server war, möchte ich auch ausschließen. Blöderweise steht zu dem Ausfall gestern um 18:30 nichts in den Logs. Die einzig dokumentierten Ausfälle sind ein Wegfall von p2 am 16.12. (ohne Auswirkungen auf den Betrieb, danach lief direkt ein Rebuild und alles war wieder gut), der ECC-Error von p1 während des Rebuilds gestern Abend und der Wegfall von p3 heute Morgen.

Seit heute Mittag läuft der Server übrigens wieder, als wär nie was gewesen. Da er das jetzt wohl auch die nächsten Tage tun wird, fällt es mir also schwer nach dem Austausch einer beliebigen Komponente zu sagen "das war es" oder eben nicht.

Naja ich danke euch bis hierhin erstmal für eure Hilfestellungen. Weitere Anregungen sind natürlich willkommen ;) Man muss doch irgendwas prüfbares unternehmen können, was einem sagt, dass der Server dieses Problem nicht mehr hat..
 
.. an diversen Stellen im Netz bin ich auf den Hinweis gestoßen, beim Bootloader hinter dem zu ladenden Kernel "noapic" zu ergänzen. Das soll das Problem bei vielen behoben haben und wird wohl auch vom 3Ware Support empfohlen.

Was haltet ihr davon?

Ich werd die Kiste jetzt auf jeden Fall wieder in Betrieb nehmen - halte euch auf dem Laufenden :cool:
 
.. natürlich will ich euch die Antwort des Herstellers nicht vorenthalten:

-------------------------------------
This (noapic) could be the source of the issue and I would recommend setting this, but there are other possibilities as well. All drives save 1 currently have reallocated sectors and the data should be backed up on the chance of possible failure of the array:

/c0/p0 Reallocated Sectors = 21
/c0/p1 Reallocated Sectors = 83
/c0/p2 Reallocated Sectors = 43
/c0/p3 Reallocated Sectors = 0

I would recommend one by one replacement of the drives with reallocated sectors at this point after the backup is taken.
-------------------------------------

Zu deutsch: An dem Ausfall KÖNNTE die fehlende noapic-Funktion Schuld sein. Darüber hinaus haben drei von vier Festplatten einen weg. Das ist mal n Schnitt...
 
Festplatten >320GB sind nunmal rein physikalisch schon deutlich anfälliger und >500GB für den professionellen Einsatz schlicht nicht ausgereift, was einem auch die Hersteller durchweg hinter vorgehaltener Hand bestätigen. Aber wer mit RAIDs spielt, hat ja auch an Backups gedacht, daher kostet es nur Lehrgeld und keinen Datenverlust...
 
You must log in or register to reply here.
Back
Top