Wie funktioniert software RAID 1?
-
Ich denke schon, dass die Problematik eng mit dem Dateisystem zusammenhängt.
Bereits Fall 1 ( ein Block unterschiedlich ) darf nicht eintreten, da das RAID-1 "zufällig" auswählt von welcher Festplatte es welchen Block liest. Im Fall 1 wäre das System somit nicht mehr deterministisch.
Aber Fall 1 kann nur eintreten wenn ein Schreibvorgang nicht abgeschlossen werden konnte. Im Journal des Dateisystems wird der nicht vollständig geschriebene Block somit als Müll betrachtet und der Schreibvorgang wird erneut ausgeführt. Das RAID-1 schreibt somit auf beide Festplatten erneut das x in Block 2.
Das Dateisystem ist ja unteranderem dafür da sicherzustellen, dass die Schreiboperationen korrekt ausgeführt wurden. Ob der Fehler auftritt, der von dir angesprochen wurden, oder ob ein Block auf nur einer Festplatte nur zu Hälfte geschrieben wurde ist egal,Das Dateisystem kann auf jedem Fall diesen Block nicht mehr verwenden. Daher besitzt es Mechanismen um genau diese Fälle zu behandeln.
Falls Fall 2 auftritt, dann wurde die Konsistenzprüfung des Dateisystems nach einem Fehler nicht ausgeführt und das Dateisystem ist zerstört.
-
Hallo,
@pasti: Stimmt so nicht, auch beim Filesystem-Check wird ja nur von einer bzw. beiden Platten gelesen (aber jeder Block eben nur von einer). Du checkst ja /dev/mdx und nicht die beiden Einzel-Partitionen des RAIDs.
Ich habe jetzt auch über das Problem nachgedacht, aber verstehe auch nicht, wie das behandelt wird. Würde mich aber auch interessieren!
ChrisM
-
Ich verstehe nicht genau was du meinst. Auf welchen Teil meines Posts bezog sich deiner?
Ich bezog mich auf Journalingdateisysteme, die anhand des Journals erkennen falls ein Schreibvorgang nicht erfolgreich war.
Ohne Journal-FS hat man meiner Meinung nach mehr Probleme. Man kann dann nur noch schauen, auf welcher HD das Dateisystem weniger beschädigt ist, und dann mit dieser das RAID neu aufbauen.
Natürlich ist es tödlich für die Daten im RAID, falls man nach einem Absturz eifach so weiterarbeitet ohne das RAID neu aufzubauen. Ist in etwa das gleiche, wenn man nach einem Absturz fsck nicht laufen lässt.
-
Das RAID System darf von mir genauso wenig verlangen nach einem Absturz das Array neu zu synchronisieren wie das Dateisystem von mir verlangen darf chkdsk/fsck nach einem Absturz auszuführen. Diese Dinge müssen unbedingt automatisch funktionieren, sonst wird das nie was. Genau dafür gibt es ja z.B. Journaling beim FS, damit das chkdsk eben NICHT notwendig ist.
Genauso muss IMHO ein RAID System das automatisch können.
-
Ein RAID kann man auch während dem Synchronisieren verwenden, bei fsck geht das nicht.
Falls Du das RAID nicht neu synchronisierst nach einem Absturz, geht das Dateisystem früher oder später den Bach runter.
Ein Absturz führt meistens zu Datenverlust, deshalb schützt man die Server auch per USV, redundate Lüfter und redundates RAM.
Das einzige was ein RAID automatisch kann, ist ein Festplattenausfall aufzufangen. Bei allen anderen Fehlern ist Handarbeit angesagt.
-
pasti, ich weigere mich einfach zu glauben dass ich nach einem Stromausfall selbst eingreifen muss um das RAID am Leben zu halten. Das darf nicht sein, damit wäre die ganze Technik unbrauchbar, da das unter realen Bedingungen eben einfach nicht möglich ist -- sowas kann man viel zu schnell übersehen.
Das würde auch bedeuten dass man einen Rechner mit einem RAID System niemals auf "always on after power loss" einstellen dürfte, sonst könnte das System wenn es keiner beobachtet ja evtl. nen Stromausfall erleiden, dann neu booten, und lässig anfangen Daten zu vernichten. Soll heissen: das RAID System muss selbst mitbekommen dass es sich gefälligst neu zu synchronisieren hat, und das dann verfluchnochmal auch machen.
Genauso darf ein Dateisystem nicht inkonsistent werden wenn ich irgendwann einfach den Stecker rausziehe. Und wenn ich mir NTFS angucke, dann passiert das auch nicht. Das einzige was hin und wieder passiert ist, dass Blöcke als "belegt" markiert sind, die in wirklichkeit frei sind. Und das alleine ist nicht so ein schlimmes Problem -- dadurch werden niemals Daten vernichtet werden.
-
Als Nebenjob zum Studium bin ich SysAdmin in einer kleinen Firma mit 6 Servern ( 6 Kisten, virtualisierte nicht gezählt ). Es gibt sicher viele Leute hier im Forum, die sich viel besser auskennen als ich, aber ich finde das Thema sehr interessant und deshalb erlaube ich mir auch, gestützt auf mein mageres Wissen, dazu etwas zu schreiben.
Hast du schon einmal bei einem Activedirectory-Server den Stecker gezogen? Ich habe mal an unserm Testserver aus versehen den Strom gekappt, als gerade Windows 2003 als AD-Server lief. Ich konnte die Datenbank nicht wiederherstellen, obwohl ich alle Wiederherstellungsroutinen durchprobiert habe. Beim produktiven System hat man natürlich ein Backup, trotzdem würde hier ein Stromausfall im dümmsten Fall alles lahmlegen, bis man das Backup wieder eingespielt hat. Auf dem Testserver lief ein RAID 1 mit einem 2200s Controller von Adaptec, also einer der besseren auf dem Markt. Der hat mir da gar nichts genutzt.
Ich bin jetzt etwas abgeschweift, aber ich wollte nur illustrieren, dass ein Stromausfall noch vieles andere töten kann, nicht nur das RAID.
Zudem würde ich nie irgend ein Gerät auf "always on after power loss" einstellen, da wenn der Strom nach dem Stromausfall wieder kommt teilweise Spannungsspitzen auftreten, was man sehr schön am Log einer USV sehen kann ( ist vielleicht nicht an allen Standorten so ).
Warum hat jeder Server mindestens 2 Stromanschlüsse und Netzteile, wenn man eifach so mal den Stecker ziehen könnte?
Bei Controllern, wo zuerst in den Cache des Controllers geschriben wird, bevor dieser auf die Festplatten schreibt, kann ich mir vorstellen, dass falls die Cache Batteriegepuffert ist, festgestellt wird falls ein Schreibvorgang nicht korrekt durchgeführt wurde.
Bei günstigeren Controllerm wo die Cache nicht Batteriegepuffert ist, wird aber die Cache nicht zum Schreiben verwendet. Analog verhält es sich mit dem Software-RAID. Da kann dir der Controller in keinem Fall grossartig helfen.
Falls ein RAID-1 nun einen Fehler hat, hat der Controller ja 2 Möglichkeiten. Entwerder er schreibt Disk 1 nach Disk 2 oder umgekehrt. Er weiss ja nicht, welche Festplatte die "richtigeren" Daten enthält. Deshalb wird ein RAID-1 auch nicht eifach so nach einem Fehler ein sync machen. Weil ein sync bedeuten den Verlust der Daten auf einer Festplatte. Vielleicht ist eine Datenbank auf der einen Festplatte noch perfekt konsistent und auf der inkonsistent und unbrauchbar. Deshalb muss man zuerst schauen, wo welche Daten konsistent sind, und diese sichern. Danach kann man ein sync machen und die vorher gemachte Sicherung wieder einspielen.
-
Also ich arbeite in einer Firma die durchaus auch einige Server betreibt. Und es ist doch hin und wieder mal vorgekommen dass irgendeine Box sich weggehängt hat (vor allem zu NT4 Zeiten), bzw. auch selten mal dass wir sie einfach ausschalten mussten, bzw. den Stecker gezogen haben. Einmal speziell als ein Hochwasser den Serverraum zu überfluten drohte, und wir die Server schnell nen Stock höher transportieren mussten. Da haben wir auch nix runtergefahren oder sonstwas - dafür war keine Zeit.
Hat aber nie ein Problem gemacht.Ich konnte die Datenbank nicht wiederherstellen, obwohl ich alle Wiederherstellungsroutinen durchprobiert habe.
Ok, das ist übel. Das bedeutet für mich aber nur dass irgendwas an eurem System faul ist. Entweder ist das AD so mies implementiert, oder der Cache vom RAID Controller wird im Write Back betrieben obwohl er nicht batteriegepuffert ist. Sowas wäre natürlich tödlich.
Bei Controllern, wo zuerst in den Cache des Controllers geschriben wird, bevor dieser auf die Festplatten schreibt, kann ich mir vorstellen, dass falls die Cache Batteriegepuffert ist, festgestellt wird falls ein Schreibvorgang nicht korrekt durchgeführt wurde.
Ganz sicher sogar. Unsere neuen SANs machen das z.B. so. Commit to cache. Feine Sache.
Falls ein RAID-1 nun einen Fehler hat, hat der Controller ja 2 Möglichkeiten. Entwerder er schreibt Disk 1 nach Disk 2 oder umgekehrt. Er weiss ja nicht, welche Festplatte die "richtigeren" Daten enthält. Deshalb wird ein RAID-1 auch nicht eifach so nach einem Fehler ein sync machen. Weil ein sync bedeuten den Verlust der Daten auf einer Festplatte. Vielleicht ist eine Datenbank auf der einen Festplatte noch perfekt konsistent und auf der inkonsistent und unbrauchbar. Deshalb muss man zuerst schauen, wo welche Daten konsistent sind, und diese sichern. Danach kann man ein sync machen und die vorher gemachte Sicherung wieder einspielen.
Nö, da bin ich wieder gänzlich anderer Meinung. Es müssen auf jeden Fall BEIDE Platten immer konsistente Daten haben, bloss können diese unterschiedlich sein - was aber egal sein sollte, da es sich bloss um ein paar Sekunden (bzw. eher Bruchteile einer Sekunde) an Transaktionen handeln kann die die Platte mit den "neueren" Daten hat, die andere aber nicht.
Erst wenn man diese Platten mit unterschiedlichen Daten in einem RAID 1 zusammen betreibt, ohne das RAID neu zu synchronisieren, ist es fatal.
Warum immer beide Platten konsistente Daten haben? Weil die Datenbank/das Filesystem/... eben durch die Art und Weise wie geschrieben wird bzw. wie Transaktionen auf den Datenfiles gemacht werden dafür sorgt dass nie etwas inkonsistent werden kann.Aber egal, selbst wenn wir davon ausgehen dass wir beide Platten getrennt ansehen möchten, und dann entscheiden welches die "gute" ist -- selbst dann ist es komplett daneben wenn der RAID Controller bzw. das software RAID das Array nach so einem Vorfall einfach als "healthy" behandelt. DANN wäre die einzig richtige Vorgehensweise das Array auf read-only zu schalten, und zwar read-only von einer einzelnen Platte. Tut aber kein mir bekanntes System, und halte ich auch nicht für sinnvoll.
-
Hehe, die Story mit dem Hochwasser kenne ich. Beim Fall den ich kenne, habe sie aber die USVs in die Racks eingebaut und dann die Racks als ganzes weggerollt.
Was mit diesem AD schief gelaufen ist, weiss ich auch nicht. Hätte auch nicht erwartet, dass sowas passieren kann.
Wenn ich mal wieder in der Firma bin, werde ich mir mal aus der Bastelkiste ein Linux-Software RAID zusammenfrickeln, ein paar mal den Stecker ziehen und mal schauen was passiert.
Wikipedia/RAID:
Atomic Write Failure
Also known by various terms such as torn writes, torn pages, incomplete writes, interrupted writes, non-transactional, etc. This is a little understood and rarely mentioned failure mode for redundant storage systems that do not utilize transactional features. Database researcher Jim Gray wrote "Update in Place is a Poison Apple" during the early days of relational database commercialization. However, this warning largely went unheeded and fell by the wayside upon the advent of RAID, which many software engineers mistook as solving all data storage integrity and reliability problems. Many software programs update a storage object "in-place"; that is, they write a new version of the object on to the same disk addresses as the old version of the object. While the software may also log some delta information elsewhere, it expects the storage to present "atomic write semantics," meaning that the write of the data either occurred in its entirety or did not occur at all.However, very few storage systems provide support for atomic writes, and even fewer specify their rate of failure in providing this semantic. Note that during the act of writing an object, a RAID storage device will usually be writing all redundant copies of the object in parallel, although overlapped or staggered writes are more common when a single RAID processor is responsible for multiple disks. Hence an error that occurs during the process of writing may leave the redundant copies in different states, and furthermore may leave the copies in neither the old nor the new state. The little known failure mode is that delta logging relies on the original data being either in the old or the new state so as to enable backing out the logical change, yet few storage systems provide an atomic write semantic on a RAID disk.
Since transactional support is not universally present in hardware RAID, many operating systems include transactional support to protect against data loss during an interrupted write. Novell Netware, starting with version 3.x, included a transaction tracking system. Microsoft introduced transaction tracking via the journalling feature in NTFS.
Hier steht nochmals das, was ich zu sagen versuchte. Leider ohne Quellen. Aber hier wird nochmals der Zusammenhang zwischen RAID und Filesystem angesprochen. Insbesondere löst ein Journaling-FS die Inkosistenzprobleme, da es den Schreibvorgang wiederholt, falls die Operation von Controller nicht als abgeschlossen bestätigt wurde.
-
Die vermischen hier 3 Sachen die miteinander nicht viel zu tun haben:
- Torn Writes aka. Torn Pages aka. ...
Das kann passieren wenn ein Schreibvorgang unterbrochen wurde. Statt AAAA oder BBBB kann also BAAA oder ABAB oder ABBB oder sonstwas auf der Disk stehen. Im schlimmsten Fall, nämlich wenn die Platte so doof ist dass sie nichtmal einzelne Sektoren "atomic" schreiben kann, kann auch ABXB oder sowas drinnen stehen.
Das ansich stellt IMHO noch kein Problem dar, wenn auch die Sache sehr lästig wird wenn man mit "zerrissenen Sektoren" rechnen muss - weil man viel öfter flushen muss, und sich an mehr Stellen auf Checksummen verlassen muss.
Das ist aber ein Problem welches mit RAID überhaupt nix zu tun hat, die Verwendung eines RAID Systems macht das weder besser noch schlechter. Ausnahme wäre hier ein RAID mit "commit to cache", da man bei so einem System zumindest nichtmehr mit "zerrissenen Sektoren" rechnen muss. Darauf dass ein Schreibbefehl der mehr als einen Sektor schreibt "atomic" ausgeführt wird kann man sich aber auch mit "commit to cache" nicht verlassen.
Von einem RAID System zu fordern dieses Problem zu lösen ist IMHO auch komplett unvernünftig, da es kaum möglich ist -- zumindest nicht solange das RAID System transparent arbeiten soll, denn dafür wäre eine Änderung des Storage-Device-Interface notwendig.
- Das "redundant copies in different states" Problem.
Das ist das wovon ich die ganze Zeit rede
Und das ist ein Problem welches mit einem RAID System existiert, ohne RAID allerdings nicht. Daher muss es IMHO auch das RAID System transparent lösen, da es nicht sein kann, dass ein System welches für das OS bzw. die Programme transparent arbeiten sollte, Garantien wegnimmt die eine einfache Platte noch bietet.
----
In dem zitierten Abschnitt werden nun beide Probleme vermischt, was ich für unglücklich halte, da sie IMHO miteinander nix zu tun haben. Garnichts.
Hier steht nochmals das, was ich zu sagen versuchte. Leider ohne Quellen. Aber hier wird nochmals der Zusammenhang zwischen RAID und Filesystem angesprochen. Insbesondere löst ein Journaling-FS die Inkosistenzprobleme, da es den Schreibvorgang wiederholt, falls die Operation von Controller nicht als abgeschlossen bestätigt wurde.
Ein FS welches (wie NTFS) nur Änderungen an Metadaten, nicht aber am File-Inhalt logt, löst dieses Problem aber nur für eben diese Metadaten. (Wenn überhaupt, da ein System welches "atomic transactions" ermöglichen soll, aber ohne Rücksicht auf Problem #2 programmiert wurde, u.U. auch davon ausgeht dass einmal gelesene Daten "stabil" sind, und dann genauso versagt.)
Solange man aber Problem #2 nicht irgendwie auch für "Userdaten" behandelt kann es immernoch passieren dass ich nach dem Stromausfall "Foo.txt" im Notepad aufmache, den Inhalt angucke und alles passt -- und ein paar Sekunden später "Foo.txt" nochmal aufmache, und auf einmal was ganz anderes drinnen steht. Und genau das darf eben nicht sein, da viele Programme damit nicht klarkommen werden.
- Torn Writes aka. Torn Pages aka. ...
