Raid5_unconfigured good

[PeterWS]

Hallo zusammen!

Zur Augangslage:
Ich habe ein Raid5 System aufgesetzt mit 5x1TB-Platten. Alles lief ca 1 Jahr störungsfrei, bis der Controller plötzlich zu fiepen anfing. Ich hab das System dann heruntergefahren und im Bios festgestellt, daß von den fünf Platten zwei als "foreign - unconfigured good" nicht mehr in den Raidverbund importiert werden (können).

Ich bin kein Hardcore Experte was Raid-Systeme angeht, aber ich stelle mir vor, daß bei den beiden besagten Platten nur die Metainformationen beschädigt sind, die Strip-Daten auf den Platten hingegen intakt sind, denn beide Platten sind physikalisch anscheinend i.O.(eben unconfigured good)

Zur Lösung meines Problems sehe ich momentan nur zwei Lösungswege:

1) Bearbeitung der Contoller-Metadaten auf zumindest einer der beiden Foreigner-Platte um wenigstens ein Degraded-Raid5 hinzukriegen

2) Auf fünf anderen Platten ein identisches Raid5-System anlegen (damit der Contoller die Metadaten auf die Platten schreibt) und die Platteninhalte dann auf die neuen Platten kopieren.

Am ausichtsreichsten erscheint mir Lsg2.
Ehe ich mich aber nun ans langwierige Kopieren mache, kann mir vielleicht einer der Experten hier im Forum noch den einen oder anderen Rat geben.

Danke jedenfalls schon mal im voraus

 

[Ernst@at]

Um welchen Controller handelt es sich da? Mainboard wäre auch interessant.
Ob die Metadaten auf den Platten(und wenn, wo genau) oder im NVRAM des Controllers abgespeichert werden, hängt bei externen Controllern/PCI(-E) Steckkarten vom Controllertyp ab.

zu 1) Stellt sich die Frage, wo die Metadaten der beiden "foreign" Platten plötzlich hingekommen sind

zu 2) besteht bei dieser Vorgangsweise höchste Gefahr, die Daten zu schrotten, solange man nicht die exakte Reihenfolge(Kabel könnten im Laufe des vergangenen Jahres seit der Erstellung des RAID5 vertauscht worden sein) wiederherstellt und sich vergewissert hat, dass beide Platten gleichzeitig und nicht zeitmäßig hintereinander "ausgestößen" wurden, d.h. einige Zeit degraded weiterlief.

 

[PeterWS]

Es handelt sich beim Mainboard um ein altes Gigabyte GA-M59SLi-S5 und beim SATA-Controller um einen LSi MegaRaid-SAS-8308ELP.
Den Kontroller hatte ich extra gewählt, da er relativ verbreitet ist (im Ggs. zu meinem damaligen Favoriten von Areca) und ich leicht an Austauschtypen kommen kann - im Falle eines Ausfalls. D.h. ich bin immer unbewußt davon ausgegangen, daß die Raid-Platten für sich eine Einheit bilden und Meta-Daten zur evt. Rekonstruktion sich nicht auch noch auf der Kontrollerkarte befinden - dafür dachte ich, würde ja die HPA extra angelegt.

Zu Punkt 2:
Sehr schöne, profunde Überlegung . hätt ich selbst nie dran gedacht.
Diese Unsicherheiten lassen sich in meinem Fall allerdings eindeutig ausschließen. Die Reihenfolge/Anordnung von Platten und Kabeln lag und liegt eindeutig fest und ist nie verändert worden.

Zum Ausfall: Ich bin zufällig gerade am Rechner gewesen, als der Controller zu fiepen anfing - sofortiges Herunerfahren und booten ins Controllerbios zeigte dann, daß die Platten 4+5 als foreign angesehen werden, aber nicht als bad eingestuft werden. Das System lief nie degraded.

Der Ausfall zweier(!) Platten erinnert mich an alte IDE-Zeiten, wo oft der Ausfall einer Master-Platte denjenigen der Slave-Plate nach sich zog (und v.v.). Es wäre interessant zu erfahren, inwiefern sich vielleicht Altlasten des Protokolls noch in der SATA(II)-Kommunikation wiederfinden (möglicherweise ist Raid6 speziell aus diesem Grund eine Überlegung wert).

Besonders ist noch, daß beide ausgeschiedenen Platten an einem Stromversorgungsstrang hingen - vielleicht ein kurzer Spannungseinbruch o.ä., der softwaremäßige Konsequenzen hatte.


Meine momentane Lösungstrategie wäre:

Ein zweites Raid5 System, aus "jungfräulichen Platten", anlegen um die HPA Daten (und was vielleicht zusätzlich noch dazu gehört) durch den Controller auf die neuen HDDs schreiben zu lassen. Die HPA-Sektoren ermitteln und dann alle Daten, d.h. alle 64kB Stripes, Platte für Platte kopieren - nicht besonders "sophisticated", aber zielführend.

Umgekehrt wäre es natürlich eleganter (4MB statt 4TB), wenn man einfach die HPA-Bereiche kopieren könnte, so daß die Platten als zur Konfiguration gehörend eingebunden werden, aber ich weiß nicht, ob mit dem HPA-Bereich alle Infos kopiert sind - ich vermute mal, daß irgendwo anders noch Bezug genommen wird auf die Plattenhardware in Form von Seriennummern o.ä.

Es gibt zur Raid Wiederherstellung noch ein Program aus Indien "RAID-Reconstructor", was sich von der Beschreibung her recht intelligent anhört.

Es ermittelt die Plattensequenz, wenn sie nicht bekannt sein sollte und legt dann ein sog. vim-(xml)-File an, das die Anleitung enthält, in welcher Reihenfolge die Cluster zusammen zu kopieren sind, um die Daten wiederherzustellen. Allerdings händelt es, glaube ich, nur MBR-Platten, kommt also wohl für die neueren GUID-Verbunde nicht mehr in Frage.

Grüße

 

[Ernst@at]

Ich selbst bin zwar auf Rekonstruktion aller Spielarten von RAID-Ausfällen an Onboard-Controllern geübt, hatte aber noch keine Gelegenheit, da mal an einem Externen zu studieren, da die ja so selten mal Hoppala machen - aber manchmal eben doch, wie sich hier leider bestätigt.

Im Normalfall muss es reichen, alle Informationen (Arraygröße, Stripesize, Plattenreihenfolge) zusammenzusuchen, und im Fall, dass der RAID5 von einem Moment zum anderen sich von READY nach FAILED begeben hat, den Verbund im Controller aufzulösen und exakt gleich neu zu definieren.
Ist der RAID auch nur kurze Zeit im DEGRADED weitergelaufen (also ohne eine der Platten), dann muss man diesen degraded-Zustand sofort nach Definition durch Abstecken der zuerst ausgefallenen nachstellen, und kann dann per normalem Rebuild die Platte wieder einbinden, um die Datenintegrität zu wahren.

Empfehlenswert ist auch, vorher den Array fürs System unschädlich zu machen, indem man den MBR des Arrays sichert & löscht, der sich auf der ersten Memberplatte und am Paritystripe einer anderen befindet. Dann kann man die korrekte Plattenreihenfolge/Stripesize mittels eines Platteneditors inspizieren, ob sich tatsächlich alles am richtigen Fleck befindet, und dann den MBR wieder aktivieren.

Bevor einzelne Platten zwecks Kopieren an einen anderen Controller gesteckt werden, sollte man sich der Tatsache bewusst sein, dass Windows die GUID/GPT-Information auf eine 1TB-Platte korrigiert, was dann als RAID-Memberplatte völlig falsch ist. Das passiert auf der ersten und letzten(parity des Stripe0) Memberplatte und zerstört dabei auch die Metadaten, die normalerweise am Ende der Platte liegen.

Zu den Metadaten: Die befinden sich bei diesem Controller in einer HPA? Davon habe ich keine Information. Mir ist allerdings bekannt, dass das Gigabyte-Boards ein Backup ihres BIOS auf den Platten verewigen, und dabei uU die Metadaten des RAID überschreiben. Wie das allerdings in Deinem Fall abgelaufen sein sollte, ist nicht erklärbar, weil das nur beim BIOS-Post passieren könnte(naja, nach dem Ausfall gab es ja eines). Ist die HPA erst als die Platten rausgefallen sind, auf die Platten gekommen, kann das eine fatale Verkleinerung der Arraygröße zur Folge haben bei einer Neudefinition.

Hingen spätere RAID-Platten aber schon vorher während eines BIOS-Post an einem Onboard-Controller, dann ist es gut möglich, dass damit eine HPA auf die Platte kommt. Diese wäre 2113 Sektoren groß, und die 1TB Platte hat dann statt 1953525168 und diese Zahl weniger Sektoren. Ob das an diesem Board überhaupt passiert, kann nicht mit Sicherheit gesagt werden, weil die technischen Spezifikationen dazu ungenau sind.

Welches System läuft auf dem Board?

 

[Tudeski]

du schreibst du kommst an austauschtypen ran, wie wäre es einmal einen austasuchtyp einzubauen? vielleicht hat der controller einen an der waffel und nicht die hds.

 

[PeterWS]

Generell zum Controller:

Er läßt sich quasi auf 3 Ebenen administrieren:

Auf der Ebene des Betriebssystems durch eine Java-GUI, sowie ein Command Line Interface. Während des Systemboots läßt sich die 3.Bedienebene auswählen, indem man das Bios des Kontollers auswählt. Die weitaus meisten Optionen biete die CLi, die aber i.d.R. nur selten benötigt wird (eMail Support etc.).
Bios und GUi sind ähnlich strukturiert, nur hat das Bios-Interface den Vorteil Systemnah mit dem Kontroller zu kommunizieren, ohne Interferenzen durch Betriebssystem oder andere HDDs.

Das Problem ist nun, daß der Kontroller beim booten eine "Virtuelle Disk" (so nennt er das) bestehend aus 5 Platten feststellt (das ist der alte funktionierende Plattenverbund). Er findet allerdings nur 3 phys. Platten, die zu dieser VD gehören, sowie 2 Platten die er als foreign: unconfigured good einstuft.

Will man nun die Konfiguration importieren, dann scheitert dies, weil bei 2 Platten eben eine zu viel für ein Raid5 fehlt (was ich logisch finde). Dies bedeutet, daß die 2 HDDs irgendwie als fremd markiert wurden und ich glaube, daß diese Infos auf jeder der beiden Platten stehen (nihct im NVRam des Kontrollers).

Wo diese flags zu finden sind weiß ich nicht. Ich bin einfach naiv davon ausgegangen, daß für diese Infos der Controller eine HPA am ENDE der HDDS anlegt - daß er jedenfalls die Daten (i.e. die Strips) strickt von den Metainformationen trennt.

Jetzt wollte ich mit DEMSELBEN Controller und 5 gleichen Platten einen neuen RAID5-Verbund mit identischen Parametern anlegen, um eben diese Metainfos des Kontrollers auf die Platten zu bekommen. Dann wollte ich die Strip-Daten des beschädigten Verbundes Platte für Platte folgerichtig auf die neuen Platten kopieren.

Das Kopieren stelle ich mir hardwarenah mit dd vor, so daß die erwähnten GUID-Probleme eigentlich nicht auftreten sollten. Nach 4-5 Tagen Kopiererei müßte ich dann 5HDDs haben, die mit den richtigen Infos vom Kontroller als Virtuelle Disk akzepiert werden sollten.

Wie gesagt keine elegante Methode aber vielleicht ja funktionabel.

Beim Kopieren der Sektoren muß nur sichergestellt sein, daß die fehlerhaften Metadaten nicht mit auf die neue Platte kopiert werden.

Als OS habe ich ein unerschütterliches WinServer2003 auf dem Board - noch aktuell genug was Treiber etc. angeht und alt genug um Vista/Win7 Probleme, wie z.B. GUID-Sektorgrenzen etc. noch nicht zu haben.

Grüße in die höheren Lagen über NN.

Ergänzung (11. August 2010)

Gute Idee.
Ich werde am Wochenende den Plattenstapel gleich mal an einige typgleiche Kontroller in der Uni anschließen, um diesen Unsicherheitsfaktor auszuschließen

 

[Mueli]

Versuche es auch mal auf den Support-Seiten von HP, in fast allen grösseren Windows-Servern steck(t)en dort die MegaRaid von LSI, mir ist so ein teil leider nie unter die Finger gekommen, weil ich primär mit UNIX Servern auf PA-Basis zu tun hatte.

 

[Ernst@at]

Mit dem GUI kann es derzeit keine Interferenzen mit dem System geben, weil der Array(oder auch virtuelle Disk) jetzt ja tot ist.
Im GUI muss sich noch feststellen lassen, wie der Array definiert war(Stripesize, Reihenfolge der Memberplatten mit Angabe der Seriennummen und Portanschluss) und vielleicht findet sich auch ein Logfile, der die letzten Ereignisse dokumentiert hat, die zum Ausfall geführt haben.
Alle derzeitigen Konfigurationsinformationen sollten auf jeden Fall notiert werden, solange sie noch vorhanden sind.

An welcher Stelle in der Konfigurationsreihenfolge liegen die beiden rausgefallenen Platten?

Wenn der Controller die Metadaten ausschließlich im NVRAM führen wurde, wäre das einzige "Erkennungszeichen" von Memberplatten die Seriennummer, und die kann sich nicht geändert haben.
Also muss die Metainfo auf den Platten selbst stehen.
Erkennt der Controller die nicht und weist zwei der Platten als "non-Member" oder "foreign" aus, dann bedeutet das, er kann seine Metadaten auf diesen Platten nicht finden. Bei onboard-Controllern befinden sich diese am Plattenende, das kann bei diesem Controller auch so sein.

Diese Metadaten müssen auf den beiden Platten also irgendwie unbrauchbar oder inaccessibel geworden werden. Entweder durch einen Plattenfehler an diesen Sektoren, dem Anlegen oder entfernen einer HPA, oder auch durch einen Controllerfehler, der die Informationen mit falschen Daten überschrieben hat.
Ist der Inhalt des Arrays mit irgendeinem System verschlüsselt?

Die beiden rausgefallenen "foreign" Platten gehören ja derzeit nicht mehr dem Array an, also sollten sie in der Datenträgerverwaltung als Einzelplatten sichtbar sein.
Eventuell dabei erscheinende Popups, die diese Platten initialisieren wollen, ablehnen!

Mit einem geeigneten Hex-Editor z.B. HxD(für eine weitere Kommunikation darüber wäre die englische Version vorteilhaft) lässt sich der Platteninhalt einsehen, und auch die aktuelle zur Verfügung stehende Sektoranzahl feststellen, womit eine An/Abwesenheit einer vom Board aufgebrachten HPA verifiziert werden kann (und auch bei zum Ausfallereignis führender Entfernung einer HPA die nun um 2113 Sektoren zu tief liegenden Metainformationen, wenn vorhanden, dort gefunden werden können)

Bei Abklemmen aller restlichen im Verbund stehenden Memberplatten lässt sich von allen, an z.B. so einen USB-Adapter um €15 angeschlossen, per USB oder direkt SATA angeschlossen, zerstörungsfrei nur an einem XP x32 System. (Die USB-Variante hat den Vorteil, dass man die Diagnose auch ohne Plattenausbau mit einem geeigneten Note-/Netbook durchführen kann)
- der SMART-Status zur Überprüfung auf Hardwarefehler erheben
- Einsicht in die Metadaten der gesunden Platten genommen werden
- Eine Entschlüsselung der Metadaten, wenn das Layout bekannt ist, vorgenommen werden.
- Die aktuelle Partitionierung des RAID-Arrays sektorgenau in Erfahrung bringen

Diese Information ist notwendig, um die Grenze zwischen Arraybereich und Metadatenbereich auf den Platten zu kennen, damit bei so einem Versuch des Kopierens der Platten die neuen Metadaten nicht zerstört werden.

Hat man aber all diese Informationen beisammen, kann man den RAID aber auch gleich am Ursprungscontroller auflösen und neu definieren, um ihn wieder ohne Datenverlust funktionsfähig zu kriegen.

 

[PeterWS]

Ich muß eines vorausschicken:
Ich habe eine einzelne Platte eines Raid5 Verbundes noch nicht sektormäßig untersucht und zwar aus folgendem Grund:
In er Anfangszeit, als ich noch mit dem Kontroller experimentierte, hatte ich eine der Platten in Verdacht SMART-Fehler aufzuweisen. Der Kontroller gibt in der GUI Auskunft über den Smart Status, aber ich traute den Angaben nicht so recht.
Ich habe also eine Platte, an einem normalen MB-Anschluß, mit einem Smart-Tool untersucht, fand die Angaben des Kontrollers allerdings durch das Tool bestätigt: alle Parameter im grünen Bereich.
Ich hatte streng darauf geachtet, daß die Analyse nur im Read-Only-Mode stattfindet und auch darauf gesehen, alle möglichen Interferenzen, wie Virenscanner u.ä. auszuschließen. Trotzdem hat der Kontroller die Platte nach Wiederanschließen als fremd eingestuft und ein 30h Rebuild war notwendig. Ich habe mir die Sache damals einfach so erklärt, daß die Karte beleidigt ob des Mißtrauens ihr gegenüber sich rächen wollte...

Nein, nicht ganz so - ich nahm einfach an, daß das Kartenbios die Zeitstempel der Memberplatten vergleicht und bei Abweichungen aus Konsistenzgründen auf Nummer sicher geht und einen Rebuild verlangt. Wie gesagt, ich hatte die Platten vorher nicht als Offline oder dergleichen markiert, wie man das bei einem geregelten Herausnehmen einzelner Member machen würde.
Dieses Problem stellt sich bei meinen beiden ausgeschiedenen Platten ja ohnehin nicht mehr. sie kann ich also in dieser Hinsicht unbesorgt untersuchen.

Diese Analyse läßt sich allerdings nicht am Kontroller selbst durchführen, denn in der Datenträgerverwaltung erscheint unter Windows keine der Platten/Partitionen:
Der Kontroller repräsentiert seine angeschlossenen HDDs dem OS gegenüber und da er keine virtuellen Disks erkennt, zeigt er auch keine Drives an.

Vielleicht darf ich noch einige mir unverständliche Punkte auflisten:

a)>> zerstörungsfrei nur an einem XP x32 System.
Wass daas? Spielst Du auf die geänderte Track-Partitions-Einteilung an?


b) HPA:
Wie erwähnt habe ich noch keine Platte näher untersucht und weiß daher nicht, ob überhaupt eine klassische HPA vom Kontroller an jedem Plattenende angelegt wird. Mir sind bewußt bislang noch keine HPAs untergekommen.
Wenn ich den Terminus bislang gebraucht habe, dann eher im Sinne von "Hic Patriae...Artibus" um anzuzeigen, daß ich darunter all jene kontrollerspezifischen Plattenbereiche verstehe, die keine Nutzdaten enthalten.
Wo er (d.h. der Bereich in dem der Kontroller die Metadaten ablegt) zu lokaliseren ist, ob klar abgegrenzt am phys, Ende der Platte ab: (max.Sektornummer minus HPA) oder im Bereich; (max.Sektornummer PLUS HPA) oder mit den Nutzdaten verschränkt im Bereich: (Sektor63 minus Sektor0) oder in den freien ersten Blöcken der GUID-Platte.. keine Ahnung.

Diese Kenntnis ist, wie wir uns einig sind, allerdings unabdingbar um die Nutz- sauber von den invaliden Metadaten trennen zu können. Hier sind mir weitere sachdienliche Hinweise hochwillkommen.


c) NVRam:
Es ist 32kB groß und wie Du ja bereits ausgeführt hast, wird es keine vitalen Informationen über das Array enthalten, die sich nicht auch auf den HDDs finden ließen (so sagt jedenfalls der gesunde Menschenverstand).
Er enthält wohl Referenzinfos, die bei Diskrepanzen zur aktuellen Harwarekonfiguration den Kontroller zu Maßnahmen/Hinweisen veranlassen.
Aber es wäre schön eindeutige Aussagen hierzu treffen zu können, vielleicht hat ja jemand Fakten parat.


d)
>>den RAID aber auch gleich am Ursprungscontroller auflösen und neu definieren, um ihn wieder ohne Datenverlust funktionsfähig zu kriegen.
Hab' ich nicht verstanden,
Du meinst also, ich solle ein neues Array, mit den gleichen Geometriedaten, definieren (ohne erneute Initialisierung!) und der Kontroller wird dann die Platten unter Wahrung des alten Nutzdateninhalts zu einer neuen virtuellen Disk, also einem neuen Raid5-System zusammenfügen ?



@Mueli:
Guter Hinweis.
LSI taucht in vielen System als OEM auf. So sind die Dell Perc5 Kontroller, auf die man alle naselang trifft, ebenfalls von LSI und auch Fujitsu hat LSi als OEM - allerdings oft arg kastriert.


Danke jedenfalls daß Ihr mich an Euren Überlegungen teilhaben laßt.

 

[Ernst@at]

Antworten

zu a) WinXP x32 deswegen, weil das von den Win's das einzige ist, welches die GUID/GPT Infos auf den Platten nicht verändert. Deren sind am gesamten Array eine auf der ersten Memberplatte A und öfters auch auf der der letzten Memberplatte E. Da die erste Partition erst auf Sektor 2048 beginnt, sind normalerweise die 128 Sektoren eines 64K Stripes auf den Platten B,C,D befüllt mit 0x00 (manchmal aber auch mit altem Kram).
Das ergibt auf E= A XOR B XOR C XOR D=A XOR 0x00 XOR 0x00 XOR 0x00 = A, also auch einen sinvollen MBR+GPT.
Alle Win-Systeme, welche GUID Datenträger unterstützen, machen dann ein Update auf die Plattengröße einer einzigen Platte (1TB) und setzen hinten über die RAID-Metadaten auf den letzten 33 Sektoren der Platte den GPT-Mirror - worauf der RAID-Controller dann die Platte nicht mehr erkennt.

b) in der Festplattenterminologie steht HPA für Hardware Protected Area. Mit speziellen Befehlen, die auch von Festplattentools aus abgesetzt werden können, kann die Platte um eine beliebige Sektoranzahl reduziert werden. Hardwaremäßig wird eine so behandelte Platte nur mehr mit den restlichen Sektoren erkannt, alles darüberliegende so versteckte ist nicht im Zugriff.

c) den Controller kenn ich nicht

d) Ja, so meine ich es - schon dutzendweise derart praktiziert. Manchmal geht der MBR (Sektor 0) der Einzelplatten und damit auch des Arrays flöten, weil bei der Rücksetzung auf non-RAID da ein Standard-MBR draufgepappt wird und nach Neudefinition des Arrays ebenso wieder einer am Sektor 0 des Arrays;
Vorher muss aber unbedingt geklärt sein, ob auf die beiden Einzelplatten eine HPA angelegt wurde, weil dies die Größe des Gesamtarrays beim Neuanlegen beeinflussen kann und der dann kleiner als das Partitionende wird, was sich nicht so gut macht und dann außerdem noch der GPT-Mirror drübergeschrieben wird.
Vorherige Sicherung des MBR oder nachträgliche Korrektur beheben das Problem; bevor die GPT-Informationen wieder aktiviert werden, kann man zerstörungsfrei die Array-Size abchecken. Bei falscher Array-Größe wird normalerweise nichts von den RAID-Metadaten überschrieben.

 

[PeterWS]

Hello - just back again.

Ich wollte nur kurz vermelden, daß mein RAid5 ganze Geschichte gut überstanden hat und ich zudem noch einiges dazu gelernt habe.

Zu meiner Vorgehensweise:
Ich habe zuerst 2 andere identische Kontroller ausprobiert- jedoch keine Änderung im Verhalten. Nach einigen Tagen Kopiererei war ich dann in der Lage - unbesorgt - einige Experimente durchzuführen.

Genau wie Ernst@at es in Punkt d) erläutert hat, habe ich das zerschossene Array gelöscht und dann ein identisches Array neu angelegt.
Gleich beim ersten Neustart war das alte (neue) Raid5 System "up and running".
Endlich ist mir der Initialisierungvorgang klar. Ärgerlich nur, daß im Handbuch oder in der FAQ-Sektion von LSi kein Wort darüber verloren wird.

Mein Dank geht an alle für die guten Tips - speziell aber an Ernst@at - es ist immer gut einen Könner als Backup zu haben.