Re: Frage zu Software-Raid oder: Wie Datensicherung organisieren.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
regards,
Mario
--
User sind wie ideale Gase - sie verteilen sich gleichmaessig ueber alle Platten
Reply to: