Re: Frage zu Software-Raid oder: Wie Datensicherung organisieren.
Am Dienstag, 15. Februar 2005 09:25 schrieb Mario Holbe:
> Matthias Houdek <linux@houdek.de> wrote:
> > Am Samstag, 12. Februar 2005 09:28 schrieb Peter Kuechler:
> >> Am Freitag, 11. Februar 2005 18:56 schrieb Mario Holbe:
> >> > Peter Kuechler <peter.kuechler@gmx.de> wrote:
> >> > > Am Freitag, 11. Februar 2005 13:55 schrieb Matthias Houdek:
> >> > >> Platten unterschiedliche Ausfälle erzeugen kann (sicher sehr,
> >> > >> sehr selten, aber nicht auszuschließen). Wenn das System dann
> >> > >> wieder hochfährt, wird so der bestmögliche Stand
> >> > >> wirderhergestellt. Es wird wechselseitig abgeglichen.
> >> > >
> >> > > Klar, macht einen Sinn.
> >> >
> >> > Das macht nicht wirklich Sinn, wenn man mal drueber nachdenkt.
> >
> > Sorry, bin ich vielleicht zu dämlich für. Warum macht das keinen
> > Sinn?
>
> Erstmal sorry fuer das lange quoting, aber irgendwie laesst sich
> anders der Zusammenhang nicht erhalten.
>
> Also... ich versuchs mal geordneterweise auseinanderzuklamuesern.
> Ein RAID1 heisst erstmal grundsaetzlich: identische Mirrors. Auf
> jedem Mirror steht genau dasselbe.
Das ist das Ziel, das in der Regel auch erreicht wird.
> Steht auf zwei Mirrors nicht dasselbe, ist irgendwas schiefgelaufen,
> was auch immer. Dann muss man irgendwie die Identitaet wieder
> herstellen. Soweit sind sich sicher alle hier einig.
Deswegen hat man ja die Mirrors - um gerade solche Fehler aufzudecken
und möglichst zeitnah und transparent für den User wieder zu richten.
> Wenn ich irgendwie herausfinde, dass auf einem Mirror *nur* neuere
> Daten stehen und auf dem anderen *nur* aeltere, ist das Herstellen
> dieser Identitaet offensichtlich unproblematisch.
ACK.
> Wenn auf einem Mirror was eines neueres und auf dem anderen was
> anderes neueres steht, ist irgendwas gar fuerchterlich
> schiefgelaufen. Versuchen wir mal, eine solche Situation zu
> konstruieren.
>
> Angenommen, wir haben eine Folge von Schreiboperationen auf das RAID:
> RAID: O1 O2 O3 O4
> Konstruieren wir nun eine beliebige Konstellation wie oben
> beschrieben:
> Mirror 1: O1 O2
> Mirror 2: O1 O4
Warum so kompliziert? Das ist nun wirklich ein Fall, der nicht auftreten
dürfte und der leider auch durch ein RAID nicht gefixed werden kann.
> Da stellt sich natuerlich die gute Frage, wie sowas ueberhaupt
> entstehen kann. O4 haette auf Mirror 2 garnicht stattfinden duerfen,
> bevor O2 und O3 nicht abgeschlossen sind. Wenn aber O2 nicht
> abgeschlossen werden konnte, haette Mirror 2 als defekt markiert
> werden muessen und O4 haette wiederum garnicht stattfinden duerfen.
> Well, nehmen wir an, wir haben einen schrecklich fiesen Controller,
> der Schreiboperationen umgruppiert und entscheidet, O4 vor O2 und O3
> auszufuehren - was im uebrigen den zulaessigen Grundannahmen jeder
> anderen beteiligten Hardware-, Software- und User-Komponente
> widersprechen wuerde -, dann koennte es zu einer solchen Situation
> kommen.
ACK.
Warum nicht was einfacheres?
Mirror 1: 01 02 -Fehler- Ersatzsektor noch nicht lokalisiert \
Mirror 2: 01 02 03 / crash
Nach dem Crash wird das System wieder hochgefahren und das RAID erkennt
die Differenz. UNd nun?
So, wie ich dich und verstanden habe, wird der Zustand von Mirror 1 auf
Mirror 2 synchronisiert und nie anders herum. Warum nicht? Warum macht
das keinen Sinn?
> Gut, ist passiert - wie auch immer...
>
> Nach dem Starten des RAID kenne ich die Original-Folge von Schreib-
> operationen nicht mehr, ich kann nur sehen, dass auf Mirror 2 zwar
> neuere Daten als auf Mirror 1 gespeichert sind, jedoch einige Daten
> aelter sind, als auf Mirror 1. Insbesondere bin ich zu diesem
> Zeitpunkt nicht mehr in der Lage, zu erkennen, ob die Luecke (O3)
> zwischen den neeueren Daten auf Mirror 1 (O2) und den neueren Daten
> auf Mirror 2 (O4) existiert oder nicht.
>
> Die eigentliche Frage ist nun: Was ist ein bestmoeglicher Zustand?
Der wäre hier offensichtlich der Zustand nach Schreiboperation 02, weil
das System unschwer erkennen kann, dass da ein erster Fehler
aufgetreten ist. Alle nachfolgenden Zustände sind ab hier nicht
definiert.
> Ein bestmoeglicher Zustand ist - insbesondere in einer solchen
> Situation - keineswegs der 'neueste', sondern einer, der moeglichst
> konsistent ist. Man stelle sich ein RAID unter einer
> Datenbankpartition vor: dort waere es fatal, wenn nach dem Speichern
> der eigentlichen Daten zwar nicht die Daten selbst, hingegen jedoch
> die Aenderungen am Transaction-Log, die besagen "Daten wurden
> gespeichert" sehr wohl geschrieben waeren.
>
> Insofern ist also ein moeglichst konsistenter Zustand ein Zustand,
> der ausschliesslich aus aufeinanderfolgenden Schreiboperationen
> hervorgegangen sein kann.
ACK.
> Wenn ich also nun einen solchen schrecklich fiesen Controller habe,
> der oben beschriebenes Verhalten aufweist und ich um dieses Verhalten
> weiss oder aber eine Situation wie beschrieben vorfinde, tue ich
> genau entgegen der Aussage meiner Vorredner gut daran, mir den
> *aeltesten* Mirror zu suchen und nach dem zu synchronisieren, weil
> nur der mir garantiert, dass er aus einer vollstaendigen Folge von
> Schreib- operationen erzeugt wurde und somit die hoechste
> Wahrscheinlichkeit fuer eine Konsistenz aufweist.
Ah, ja. Und der älteste Mirror ist unbestritten der, der
zwischenzeitlich als Backup im Schrank lag. Uff ...
> Suchte ich mir den neuesten Mirror oder eine Mischung aus beiden,
> erhoehte sich die Wahrscheinlichkeit von Luecken in den Schreib-
> operationen und somit die Wahrscheinlichkeit, in einen inkonsistenten
> Zustand zu synchronisieren erheblich.
Ich sag ja nicht, dass das System RAID perfekt ist. Im Gegenteil. Und
genau deshalb ist eine davon unabhängige Datensicherung unerlässlich.
> Ach ja - nun wird jemand kommen und sagen: "Jaaaa, mein Controller
> stellt aber sicher, dass die Luecke O3 nie existieren kann". Das ist
> offensichtlich unmoeglich, da Mirror 1 zu jedem beliebigen Zeitpunkt
> unwiederbringlich ausfallen kann - ich haette zu diesem Zeitpunkt
> also lediglich Mirror 2 zur Rekonstruktion zur Verfuegung, auf dem
> aber offensichtlich O2 und O3 fehlen. Das Problem waere somit
> dasselbe, wie eben beschrieben.
Ja.
> Fazit: *Wenn* ich eine Situation feststelle, in der zwei Mirrors
> jeweils neuere, aber voneinander verschiedene Daten aufweisen, ist
> die einzig sinnvolle und zukunftssichere Strategie, den Controller
> wegzuwerfen.
Aber genau diese Situation kann man gerade beim ständigen Auflösen und
Wiederherstellen der RAIDs zum Wechseln der Platten erzeugen. Wie du
schon schriebst, die Hardware (oder besser die Firmware darauf) sollte
so etwas relativ sicher verhindern.
Solange alle Platten im RAID bleiben, sollte sich fast immer ein Weg
finden lassen, die Synchronität wieder herzustellen. Und wenn entgegen
aller Logik doch nicht (Softwarefehler, Murphy, ...), hat man ja eine
(echte) Datensicherung.
Wird aber eine Platte aus dem RAID gerissen, so sollte man sie danach
nicht wieder in das selbe RAID hinzufügen (außer als "saubere, neue"
Platte). Das Ergebnis der Synchronisation kann sonst im Einzelfall sehr
böse aussehen, wie du eindrucksvoll oben geschildert hat (und was ich
die ganze Zeit auch deutlich zu machen versuchte).
Und wenn ich die Platte auch noch jedes Mal vor dem Wiedereinsetzen neu
formatieren soll - das hat ja nun gar nix mehr mit einfach und
unkompliziert zu tun, oder?
--
Gruß
MaxX
Hinweis: PMs an diese Adresse werden automatisch vernichtet.
Reply to: