OVH Community, your new community space.

Eine Festplatte tauschen = 7h offline+alle Festplatten tauschen


tester
28.09.11, 22:27
kann man sehen wie man will...


gleich alle tauschen -> weniger tickets wenn die anderen hdds in wochen ausfallen... kunde ev. verärgert....
einzeln tauschen, mehr arbeit durch ovh -> kunde auch verärgert weil ein hdd tausch bei (wieviele server gibts aktuell ?) halt mehrere stunden dauert...

...

timmy
22.09.11, 17:20
Die Meldungen mit dem zurückgesetzten SATA-Link waren bei mir bislang immer einwandfrei und eindeutig auf defekte Kabel / korrodierte Steckverbinder zurückzuführen.

Bezüglich Deines ersten Postings wegen des Tausches aller Festplatten: Da die Platten ja von Anfang an relativ ähnlich belatet wurden, ist es durchaus wahrscheinlich, dass sie auch ähnliche Ausfallzeitpunkte haben. Auch wenn es ärgerlich ist, finde ich die Reaktion des OVH-Menschen gut, dass er gleichzeitig auch nach den anderen Platten schaut.

Azrael
22.09.11, 02:10
Die Kabel hatte ich von Anfang an im Verdacht, allerdings kam immer die Rückmeldung der Techniker: da dran kann es nicht liegen.

Heute vormittag habe ich noch einen Lesetest mittels hdparm gemacht, alles ok.
Server wieder normal gestartet und Synchronisierung der 2. Platte gestartet.
Obwohl die Geschwindigkeit immer noch bei maximal 25mb/s lag, habe ich es soweit einmal hingenommen.
Vorhin um 00:44 fiel die Platte aber komplett aus.
Sep 22 00:44:45 kernel: [27504.201529] ata1.01: qc timeout (cmd 0xec)
Sep 22 00:44:45 kernel: [27504.201540] ata1.01: failed to IDENTIFY (I/O error, err_mask=0x5)
Sep 22 00:44:45 kernel: [27504.201588] ata1.00: hard resetting link
Sep 22 00:44:45 kernel: [27504.520868] ata1.01: hard resetting link
Sep 22 00:44:46 kernel: [27505.557685] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 22 00:44:46 kernel: [27505.557715] ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 22 00:44:51 kernel: [27510.557599] ata1.00: hard resetting link
Sep 22 00:44:51 kernel: [27510.878021] ata1.01: hard resetting link
Sep 22 00:44:52 kernel: [27511.353777] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 22 00:44:52 kernel: [27511.353806] ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep 22 00:44:52 kernel: [27511.388350] ata1.01: disabled
Sep 22 00:44:52 kernel: [27511.412826] ata1.00: configured for UDMA/133
Sep 22 00:44:52 kernel: [27511.412853] ata1: EH complete
Sep 22 00:44:52 kernel: [27511.412895] sd 0:0:1:0: [sdb] Unhandled error code
Sep 22 00:44:52 kernel: [27511.412899] sd 0:0:1:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Sep 22 00:44:52 kernel: [27511.412904] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2f 64 4c 1e 00 04 00 00
Sep 22 00:44:52 kernel: [27511.413336] sd 0:0:1:0: [sdb] Unhandled error code
Sep 22 00:44:52 kernel: [27511.413340] sd 0:0:1:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Sep 22 00:44:52 kernel: [27511.413345] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 2f 64 50 1e 00 04 00 00
Sep 22 00:44:52 kernel: [27511.413958] sd 0:0:1:0: [sdb] Unhandled error code
Auch ein Restart hat nichts gebracht. Die Festplatte ist nur komplett aus dem System verschwunden als wenn sie physisch entfernt worden wäre.

Auch wenn immer gesagt wird, dass an dem System doch alles perfekt liefe bezeugt dieser Fehler aber doch eine andere Situation.

Ich freue mich jetzt schon wieder auf die neuen (nächsten) Ausfälle die bei weiteren Austauschvorgängen vorkommen werden und lasse mich über weitere Späße überraschen.

strex
21.09.11, 19:20
Frag mal nach einem Tausch der SATA Kabel nach. Hat schon öfters Wunder bewirkt.

Azrael
21.09.11, 10:00
Die Logs sind sauber da sich nach dem letzten Festplattentausch die Aussetzer der frisch getauschten Festplatte etwas verkürzt haben und sich somit das System nicht mehr genötigt fühlt alle paar Minuten einen Reset auf dem Sata Link durchzuführen. Die Aussetzer in denen auf der Festplatte weder geschrieben noch gelesen wird sind dennoch vorhanden (iostat zeigt es).
SMART ist installiert und sieht für alle Festplatten perfekt aus (sind ja auch jetzt erst maximal 4 Tage alt).

whyte
21.09.11, 08:42
Vielleicht ist wieder das Mainboard oder der Controller defekt.
Auf jeden Fall würde ich das nicht als normal ansehen.
Hast du SMART installiert? Da sieht man in den Logs meines Wissens noch bischen was.

Und du hast (glaub ich) auch bei Hardwareausfällen SLAs.
Dein Server muss ja ein höherwertigerer sein.

Azrael
20.09.11, 23:56
Backups sind alle vorhanden.
Läuft alles auf Raid 10 da 4 Platten zur Verfügung stehen.
Das Problem sind die Ausfallzeiten.
Für jeden Austausch muß der Server einige Zeit offline genommen werden wo die Techniker erst nochmal überprüfen ob die Angaben auch stimmen und dann erst die Hardware austauschen.
Problematisch wird es wenn es einen nicht offensichtlichen Fehler gibt. Hierfür muß der Server immer im Rescuemodus sein damit auch nichts dazwischenfunken kann -> weiter Ausfallzeit.
Fährt man den Server selbst in den Rescuemodus damit die Techniker sich dort den Fehler anschauen können kann man nur beten dass dies auch zeitnah passiert. Es kann auch mal um einiges länger dauern.
Sagt man den Technikern sie sollen es untersuchen weiss man nicht wann wie wo was passiert. Kann innerhalb der nächsten 24 Stunden alles mögliche sein.

In meinem Fall mit der noch fehlerhaften Festplatte ist das Problem dass ein Aussetzer dieser dazu führt, dass auch alle anderen Festplatten gleichzeitig eine Ruhepause (scheinbar aus Solidarität) mit einlegen.
Dadurch kann es vorkommen dass man auf der Konsole auf ein schlichtes "ps" 15 Sekunden wartet bis die Pause wieder vorbei ist. Für ein laufendes System in dem Last ist führt das sehr schnell zu einem Lockup da alles auf Daten von den Festplatten wartet.

Es ist auch nur sehr schwierig Leuten beizubringen dass ein Server alle 2-3 Tage für mehrere Stunden offline ist. Auch wenn es keine Hochkritischen Systeme sind summieren sich die Ausfallzeiten doch mit der Zeit auf ein unannehmbares Maß.

tester
20.09.11, 23:45
ich versteh nicht was manche leute mit ihren servern so anstellen das ein plattencrash so viele probleme macht...

<-- raid 1 + regelm. backups

Azrael
20.09.11, 22:20
Fortsetzung der Geschichte:

Trotz neuer Festplatten und neuem Mainboard war die Performance des Raid10 sehr schlecht. Im Rescuemodus schwankte die Wiederherstellungsgeschwindigkeit zwischen 100kb und 10mb/s. Meist lag sie im Durchschnitt bei 3mb/s wodurch das restoren 85 Tage gedauert hätte.
In /proc/sys/dev/raid war das Maximum auf 300000 und das Minimum auf 100000 gesetzt ohne dass sich eine Änderung ergeben hätte.

Nach einigem Probieren wurde dann folgender Fehler gefunden der alle paar Minuten auftrat:
kernel: [80546.868289] ata1.00: hard resetting link
kernel: [80547.188066] ata1.01: hard resetting link
kernel: [80548.280175] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
kernel: [80548.280204] ata1.01: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
kernel: [80548.400647] ata1.00: configured for UDMA/133
kernel: [80548.744386] ata1.01: configured for UDMA/33
kernel: [80548.744393] ata1.01: device reported invalid CHS sector 0
Heute abend wurde nun die 2. Festplatte erneut getauscht.
Das Raid10 hat zuerst ohne die neu getauschte Festplatte erstmalig synchronisiert und eine wunderbare Geschwindigkeit geliefert, 150-220mb/s, Durchschnitt ungefähr 190mb/s.

Der nächste Synchronisierungsvorgang mit der neu getauschten Festplatte war aber wieder enttäuschend. Durchschnittsgeschwindigkeit ungefähr 15mb/s.
iostat zeigte ganz genau den Vorgang:
2-3 Sekunden volle Geschwindigkeit (bis zu 160k Blöcke pro Sekunde geschrieben)
und danach
10-15 Sekunden lang 0 Blöcke lesen/schreiben auf allen Platten.

Der einzige Unterschied zum vorherigen Szenario: die Aussetzer sind etwas kürzer wodurch das System bisher den Link noch keinen Reset durchgeführt hat.
Vom Verhalten her ist das System mit dieser Festplatte immer noch nicht richtig nutzbar da auch immer alle anderen Platten bei den Pausen mitmachen.

Azrael

strex
19.09.11, 18:20
Schnelle und saubere Lösung. Eventuell war auch nur der Controller defekt und deshalb kam es zu vielen Fehlermeldungen. Aus Kosten- und Zeitgründen wird dann immer alles getauscht.

Felix
19.09.11, 12:06
Azrael wrote:
> jedem Eingriff können einen auch noch andere Ursachen vermuten lassen.


Klar, aber fragwuerdig "stabile" hardware wird nicht wieder eingebaut.

aus meiner Sicht gibt es hier nichts auszusetzen, im Zweifel lieber zu viel als
zu wenig Hardware durch neue zu ersetzen ermöglicht auch eine schnellere
Behebung - Ich will nicht wissen wie laut das geschrei gewesen waere, waere der
Server zur Fehlersuche und -analyse noch ein paar Stunden laenger offline
gewesen.

Azrael
18.09.11, 23:43
Hallo,

neue Späße aus dem Land von OVH.
Heutiges Thema: Wie sich ein einfacher Austausch einer einzigen Festplatte zu einer Aktion von knapp 7 Stunden ausartet.

Anfang nimmt die Geschichte an einem Samstag nachmittag.
In dem Server mit 4 Festplatten ist eine ausgefallen. Sie ist im System nicht mehr zu erkennen, daher wird ein zügiger Austausch von der Supporthotline auch zugesichert.

15:30 Uhr: Das Ticket für den Tausch der Festplatte wird erstellt.
15:40 Uhr: Server wird vom Techniker neu gestartet und in den Rescuemodus gefahren
16:24 Uhr: Rückmeldung von Techniker dass anstatt der einen nun 3 Festplatten Fehler haben.
16:31 Uhr: Meldung an Technik dass bitte nur die anfangs gewünschte Festplatte getauscht werden soll da bei den anderen Festplatten noch keine Lese- oder Schreibfehler aufgetreten sind und somit mittels Raid die Ausfallzeit und Festplattenwiederherstellung kurz gehalten werden soll.
16:55 Uhr: Anfangs gewünschte Festplatte wird getauscht
17:05 - 18:38 Uhr: Nach dem Tausch der Festplatte treten nun auch bei den nicht getauschten, aber als fehlerhaften erkannten, Festplatten Lesefehler auf. Teilweise ist das Raid nicht mehr wiederherstellbar.
(Raid 1 und Raid 10 darauf installiert).
18:38 Uhr: Ticket für die Ersetzung der anderen beiden fehlerhaft erkannten Festplatten wird erstellt.
(Seriennummern werden explizit angegeben)
19:02 Uhr: Bestätigung von der Technik welche Festplatten ersetzt werden. Hier werden die angegebenen Seriennummern bestätigt.
22:05 Uhr: Server ist wieder im Rescuemodus online. ALLE Festplatten und das Motherboard sind getauscht worden. Auch die zuerst getauschte Festplatte ist noch einmal getauscht worden.
Daten schnell per Raid schnell wiederherzustellen sind demnach nicht mehr möglich. Alle Festplatten sind jungfräulich leer.
Rückmeldung vom Techniker: Server ist erst nach der Ersetzung aller Festplatten und des Motherboards wieder gestartet. Zuvor haben sie den Server nicht zum Laufen gebracht.

Der daraufhin folgende Restore über das Netzwerk vom Backup war natürlich dann aufwändiger und dauerte viel länger als für den Tausch einer einzelnen Festplatte geplant war.

Natürlich kommt es vor dass Festplatten aus einer Produktionslinie zeitnah ausfallen.
Sehr verwunderlich ist aber hier die nahe zeitliche Abfolge wo dann auch noch die letzte Festplatte ungefragt ausgetauscht wurde bei der die SMART-Daten einwandfrei gewesen sind.
Zwar kann der Neustart einer Festplatte neue Fehler zum Vorschein bringen, aber die Häufung der Fehler nach jedem Eingriff können einen auch noch andere Ursachen vermuten lassen.

Gruß vom ausgelaugten Techniker
Azrael