Es gibt verschiedene Gründe für Einsatz (oder überhaupt erstmal die Entwicklung!) verschiedener Redundanzverfahren. Kosten und Aufwand gehören dazu. Alle Konfigurationen haben Vor- und Nachteile und man muß immer abwägen, was einem wichtiger ist.
Das Ergebnis hinten ist immer dasselbe. Aber der Weg, wie man da hinkommt, ist es nicht.
Zur Veranschaulichung:
- ich hab 10 Datenträger zu jeweils 1TB und will möglichst viel Speicherplatz zur Verfügung haben.
- verwende ich einen Mirror, dann krieg ich nur 1TB Nutzdaten raus, egal was ich mache.
- also muß ich auf eine verschränkte Konfiguration ausweichen (üblicherweise +0, hier also sowas wie RAID 1+0).
- jetzt kann ich mit viel gutem Willen fünf Mirror bauen und diese miteinander verbinden.
- Dann hab ich 5TB, die ich nutzen kann und praktisch (nicht rechnerisch!) darf exakt eine Platte ausfallen.
- (Rechnerisch kommen Wahrscheinlichkeiten hinzu, da in jedem der fünf Mirror je eine Platte ausfallen darf - aber wenn mehr als eine Platte ausfällt und diese "rein zufällig" einen Mirror komplett lahmlegen, dann war's das.)
- Oder ich kauf größere Platten. Hier im Beispiel geht das noch, aber immer ist das nicht möglich - es gibt nach wie vor Maximalgrößen pro physikalischem Datenträger. Und unter der Annahme, daß die zehn Platten zu je 1TB schon rumliegen, wäre das eine zusätzliche Investition.
- verwende ich einfache Parität, dann reicht ein virtuelles Gerät mit allen zehn Datenträgern, ich kann 9TB nutzen und 1TB fällt für die Parität weg. Eine (beliebige) Platte darf ausfallen.
- entsprechend bei zweifacher Parität 8TB zur Nutzung und 2TB für die Parität und zwei beliebige Platten dürfen ausfallen.
- wenn ich also wie bei einfacher Parität 9TB in Mirrorkonfiguration nutzen können will, dann bräuchte ich nicht fünf, sondern neun virtuelle Geräte UND ich hätte nicht 10, sondern 18 Festplatten kaufen müssen.
- Problem dasselbe wie oben, am Ende darf nur exakt eine Platte ausfallen, weil jede weitere ausgefallene Platte zu Datenverlust führen könnte (auch wenn die Wahrscheinlichkeit wegen mehr Mirrors dafür nun geringer ist). Daß insgesamt 9 von den 18 Platten ausfallen können, wenn es die richtigen Platten sind, spielt keine Rolle.
- wenn aber wie bei zweifacher Parität 8TB nutzbar sein und zwei Platten ausfallen können sollen, dann muß ich mir was einfallen lassen. Denn dazu brauch ich notwendigerweise zweifache Spiegel und jedes GB Nutzdaten kostet mich nun 3GB Plattenplatz.
Unter der Annahme, daß meine Platten weiterhin 1TB groß sind, müßte ich also 8 virtuelle Geräte aus jeweils drei Platten zusammenfassen. Das sind 24 Platten oder 24TB brutto... von denen 8TB nutzbar sind. Wie oben ist die rechnerische Ausfallsicherheit auch hier größer als zwei, aber nur zwei Platten können ausfallen, OHNE daß das die "richtigen" Platten sein müssen. Die Tatsache, daß
theoretisch auch 16 Platten ausfallen könnten,
wenn es nur die richtigen 16 sind, muß aus demselben Grund unbeachtet bleiben.
Macht natürlich keiner. 24 Platten kosten mehr in Anschaffung und auch im Betrieb, sind aufwendiger zu verwalten UND müssen irgendwo hingelegt werden.
Mirrors sind daher in "kleinen" Konfigurationen sinnvoll, zB fürs Betriebssystem, wenn nur wenige Platten verfügbar sind (oder sein sollen) sodaß das Problem "teurer Plattenplatz" nicht so ins Gewicht fällt. Sie sind außerdem sinnvoll, wenn auf Teufel komm raus Daten erhalten bleiben
müssen, weil man mit Mirrors ganz einfach irgendwelche Redundanzen sicherstellen kann. Klar, dann kostet Plattenplatz sehr viel Geld in bezug auf den nutzbaren Platz, aber vergleichsweise wenig in bezug auf die Ausfallsicherheit. 9 Platten dürfen kaputtgehen, bevor was passiert? Für so eine Ausfallsicherheit müßte man ohne Mirror sehr viel mehr ausgeben - der erfordert dafür nur 10 Platten insgesamt.
Ergo: Mirror skaliert mit der Ausfallsicherheit, nicht jedoch mit dem Datenvolumen.
Parity auf der anderen Seite lohnt sich für größere Konfigurationen, erfordern aber mehr Ressourcen vom PC für die erforderlichen Berechnungen. Dafür kosten sie weniger in bezug auf den nutzbaren Platz. Entsprechend paßt Parity gut fürs Datengrab - jede Platte, die zusätzlich ausfallen können soll, kostet mich nur jeweils eine Festplatte mehr.
Ergo: Parity skaliert mit dem Datenvolumen, nicht jedoch mit der Ausfallsicherheit.
Je nachdem was ich brauche kann ich mich also entscheiden. "Selbstheilen" tun die alle - die einzige Anforderung
dafür ist, daß es genug Redundanz gibt, um ein Datum zu rekonstruieren. Eine Platte allein genügt in keinem Fall - btrfs / zfs mit einer Platte ist also relativ albern (sollte man imo auch vermeiden).
