Hallo Patrick,
vieleicht zuerst: Ich kenne die grundsätzlich Funktionalität von Raids
aber nicht die eines EMC Clarion AX100.
Nachdem was ich hier gerade gelesen habe denke ich das Du Dir hier
Gedanken über die Sicherungsstrategie (bzw. Rücksicherung) machen musst.
Nach dem Fehlerbild kann Dir keiner die Konsistenz der Daten auf dem
Raid garantieren.
BTW. Hie wird wohl auch ein Gespräch mit EMC fällig. Das hier zwei
Platten nahezu gleichzeitig nach einem Update der Firmware ausfallen
hört sich schon mächtig komisch an.
Aber mal zu Deiner Mail im Einzelnen:
Patrick Schulz wrote:
Hi, wir haben hier gestern ein Firmware Update auf einer EMC Clarion
AX100 gemacht. Nach deren Reboot schien alles ganz sauber zu laufen bis
sich 5 Minuten später die erste Festplatte aus dem RAID 5 verabschiedete.
Vor dem Update näturlich ALLE Daten extern gesichert, ODER?
Das Hotspare sprang ein und begann die Funktion der defekten Platte zu
übernehmen und begann die replizierung.
Zu diesem Zeitpunkt sollte Eigentlich die defekte Platte im Raid keine
Rolle mehr spielen und aus der Storage Unit entfernt werden!
Hierzu sollte es aber detailierte Anweisungen vom Hersteller geben!!
Ca. eine halbe Stunde später verabschiedete sich eine zweite Platte aus
dem Array.
Schon komisch. Mal bei EMC anfragen was die dazu sagen.
Gibts da eigentlich keine Wochenend-Hotline?
In der Storage Unit befinden sich 6 Platten - eine davon ist ein Hotspare.
Über die ersten drei ist ein RAID5 gespannt, das das OS der AX100 trägt.
Größe ca. 1-2GB (ich nenne es mal OS-Array).
Über den Rest dieser 3 Platten und zusammen mit 2 weiteren spannt sich
ein weiteres RAID5 (Daten-Array). Die Hardware scheint sowas zu
unterstützen.
Nicht ales was die Hardware unterstützt sollte man auch tun. (Ich weis,
hinterher sind alle schlauer, aber sowas sollte man eigentlich vorher im
Detail klären)
Bei einem Raid5 werden Bereiche zweier Festplatten mit XOR verknüpft und
auf eine dritten abgespeichert. Hierdurch kann beim Ausfall EINER Platte
der Inhalt dieser Platte jeweils aus dem Inhalt der zwei anderen wieder
rekonstruiert werden. Der Ausfall von ZWEI Platten ist jedoch ein
technischer KO. Das einzige was sich bei einer Verteilung über fünf HDDs
ändert ist das mehr Daten mit ins Grab gerissen werden, aber das hast Du
wahrscheinlich schon realisiert. :-(
(BTW, wieviele Platten passen eigentlich in in die Storage Unit?
Eine Aufteilung über sechs Platten plus ein oder zwei Hotstandby macht
hier mehr Sinn. )
So, die erste Platte die ausfiel gehört zu dem Daten-Array und war eine
der zwei zusätzlichen.
Lässt sich anhand der Konfiguration verifizieren.
Die zweite Platte gehörte zum OS-Array.
Dass der zweite Fehler _nur_ zu dem OS-Array gehörte läßt sich aus
folgendem ableiten:
Nach mehrmaligem herausziehen und wieder hineinstecken dieser zweiten
Platte begannen nur die ersten drei Platten sich zu synchronisieren. Das
OS-Array schien wieder zu laufen. Das Daten-Array setzte die
Sychronisation mit dem Hotspare fort.
Das sehe ich aber ganz anderst. Nach meinem Dafürhalten beginnt genau
hier das ganze Drama.
Eigentlich muss es heissen "Nach mehrmaligen ... wird die zweite Platte
wieder als vermeintlich fehlerfrei wieder in das Raid integriert".
Der genaue Zustand der Platte ist jedoch NICHT bekannt. Der Bereich der
OS-Partition wird aus den Bereichen der Platte 1 und 3 wieder
hergestellt, was soweit erstmal funktionieren kann.
Da jedoch zu diesem Zeitpunkt die Wiederherstellung des Daten-Array noch
nicht abgeschlossen ist, wird diese jetzt mit einer fehlenden Platte
und einer, in ihrem Zustand fragwürdigen, Platte weiter syncronisiert.
Reines Glücksspiel!!!
Das Daten-Array war auch während dieser synchronisation online und
konnte gemountet werden.
Das ist auch eine Grundfunktion eines Raids, sagt aber in diesem Falle
eigentlich nichts über die Konsistenz der Daten!!!
Nach zwei weiteren Tests dieser Art (Kann der Server das Volume wieder
mounten?!?) fiel während des reiserfsck beim Boot wieder die Platte zwei
aus....
War eigentlich vorherzusehen, oder?
Auch hier half Platte raus und rein.
Wie bereits gesagt, diese 'Hilfe' ist keine!
Jetzt haben wir über Nacht alles schön brav weiter laufen lassen. Die
anfänglich defekte erste Platte wurde (leider) wieder als fehlerfrei
erkannt und bekam seine Daten vom Hotspare zurück.
Auch hier wie bereits gesagt: defekte Hardware/Platten haben in einem
Raid nichts zu suchen!!
Jetzt sagt mir allerdings mein Server, dass das reiserfs auf dem
Datenarray BadBlocks habe. Ich komme nicht mehr ran.
850GB...
Entschuldige meine harten Worte, aber wen soll das verwundern?
Bitte, helft mir.
Das Dateisystem liegt also auf der StorageUnit angebunden über
FibreChannel -> LVM -> ReiserFS.
Patrick, hier kann und sollte Dir eigentlich nur noch der Support des
Herstellers oder auf gleichem Level geschultes Personal, welches dieses
System (und die Firmware) aus dem F-F kennt, helfen. Weiteres
'Rumbastel' macht alles nur noch schlimmer.
Sorry für die 'harten' Fakten, aber vieleicht kann ja noch jemand aus
diesem Drama lernen bevor er die gleichen Fehler macht.
Deshalb wäre es auch interesant den Ausgang zu erfahren.
Da fällt mir noch ein: eigentlich sollte man im Produktiven Umfeld bei
der Anschaffung eines Raids mindestens die Anzahl der aktiv verwendeten
Platten nochmals einlagern. (d.h. NICHT als HotStandBy sondern orginal
eingepackt im Regal)
Warum?
Auch wenn in Raids, in der Regel, Platten aus unterschiedlicher
Produktionsreihen (Datum) verwendet werden um eben das Risiko eines
gleichzeitigen Ausfall mehrerer Platten, zumindest durch
unterschiedliche Fertigungsreihen, zu minimieren, kann man dies jedoch
nicht ausschliessen.
Baugleiche Platten können unter Umständen nach mehreren Jahren nicht
mehr bezogen werden und ein Plattenmix ist nicht zu empfehlen.
Die zweite Platte fällt immer dann aus wenn die erste gerade
'verbraucht' wurde und keine weitere zur Hand ist. (Murphy oder so)
Gruß,
Klaus
--
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
