ZFS - Teil 2 - Datensicherheit

Die Datensicherheit steht ganz oben beim ZFS. Hier ein kleiner Einblick, mit welcher Sicherheit ein falscher Optimismus einen um Kopf und Daten bringt!

Das Stichwort ist "Selbstheilungskräfte". Ein großes Wort! Es beschreibt aber doch recht gut, was ZFS so treibt.

Wenn man sich ein "herkömmlichen" RAID-Verbund vorstellt, so kann es schmerzliche Folgen haben, wenn man kaputte/inkonsistente Blöcke von einer Platte eines Spiegels ließt. So lange es "nur" ein logischer Fehler ist, bekommt das der Controller nicht mit. Die Folge ist, dass der Block und damit die Daten unbrauchbar werden. Mit viel Glück "vererbt" sich das Problem dann nicht auf den Spiegel.

ZFS hat eine Lösung für das Problem. Es wird eine Checksumme über jedem Block gebildet, welche sicherstellt, dass der Block das enthält, was er enthalten muss. Liest ZFS einen defekten Block, so holt es sich den korrekten Block vom Spiegel, markiert den invaliden Block und schreibt den Block an anderer Stelle neu. Damit bekommt immer korrekte Daten zurück und das Dateisystem "heilt sich selbst". - So die Idee!

Darüber hinaus scheint ZFS durch seine Philosophie, dass man sich nicht auf den Datenträger verlassen kann, sehr Fehlertolerant zu sein.

Ich habe ein Notebook, die Festplatte ist physisch so kaputt, dass weder Linux noch BSD von zuverlässigen Systemabstürzen absehen konnte. Windows wirkt da robuster. "Wirkt", denn es merkt nur nicht, dass die Festplatte kaputt ist! :-) Grinsen hin oder her, Windows verliert Daten und merkt es nicht. Das tut dann schon mehr weh als ein paar wilde Log-Eintrage mit späterem Absturz.

Um die Stabilität von ZFS zu testen habe ich mit dd große Dateien auf die Festplatte geschrieben. So groß, dass diese auf jeden Fall in Bereiche hineinreichten, die physisch Schadhaft waren. Keine Log-Einträge, keine Abstürze... Der Schreibvorgang scheint nur langsamer zu laufen. (Das kann natürlich auch ein "Zufall" sein, aber wenn das schreiben ca. 50% länger dauert, dann gehe ich mal davon aus.) OpenSolaris mit den ZFS auf einem physisch fragwürdigen Datenspeicher - und alles läuft - Klasse!

Der nächste Test wird dann einen Mirror beinhalten - Mal sehen, ob OpenSolaris meine Festplatte wenigstens logisch heilen kann.

Zuerst müssen 2 gleich große Festplatten bzw. Partitionen existieren. Wie diese erstellt werden kannst hier nachgelesen werden: Partition erstellen

Im Anschluss wird ein einfacher Mirror, ein Festplatten-/Partitionsspiegel, angelegt. Eine echter und für den produktiven Einsatz sinnvoller Spiegel läuft natürlich über mehrere Festplatten und nicht über Partitionen auf einer Festplatte. Es geht ja hier auch nicht um den Produktiveinsatz auf meinem Testsystem mit einer mehr als kaputten Festplatte, sondern um den Test und ob ZFS wirklich so genial ist, wie SUN behauptet.

Mirror erstellen: ZFS Festplattenspiegel einrichten

Es steht vollkommen außer Zweifel, dass der Spiegel sich über kaputte Teile der Festplatte erstreckt. Ich fülle nun den "data-Pool" mit Daten: dd if=/dev/zero of=/data/temp.dmp bs=1024 count=1024000000

Die Datei, die nun erstellt wird ist natürlich größer als das Fassungsvermögen des "data-Pools". Das ist gut, denn so kann davon ausgegangen werden, dass die Partitionen auch gefüllt werden. Selbstverständlich dauert es ein wenig, bis dieser Befehl beendet ist. Dass dieser mit einer Fehlermeldung beendet wird ist nicht tragisch, denn der Pool ist einfach nur voll und die erstellte Datei belegt weiterhin Speicherplatz.

Mit iostat -En kann der Status des Pool abgefragt werden. Keine Fehler! - Das sieht doch sehr gut aus!!!

Nun wird eine "echte" Prüfung über den Pool durchgeführt. Der Pool wird ausgeräumt: ZFS-Pool prüfen

Dieses "Aufräumen" sorgt dafür, dass die Checksummen erneut berechnet werden.

Also: Mit zpool scrub data den Prozess anstoßen und mit zpool status data den Fortschritt ansehen.

"...und da verließen sie ihnen!"

Will sagen: ZFS streckte die Waffen! Schade, denn es fing sehr gut an und es sah sehr gut aus. Zumal OpenSolaris problemlos auf den Partitionsspiegel hat beschreiben können, keine Fehler anzeigte und bis dato sehr gut funktionierte.

Ich war gezwungen das nun festgefahrene System mit einem Kaltstart zu beglücken. OpenSolaris fuhr hoch, die Festplatte ging wieder zum Angriff über und bevor man "ZFS" schreien konnte, war schon wieder alles vorbei. Manchmal besteht die Heilung ja auch einfach in Selbstzerstörung, oder nicht?

Dank der SnapShot-Funktionalität konnte ich das System mit der letzten funktionierenden Konfiguration wiederherstellen. Das System fuhr tadellos hoch. Zu meinem Erstaunen existierte der "data-Pool". Da hat wohl jemand mitgedacht - Respekt! zpool status data verriet aber, das der Mirror in einem Status war, der als unbrauchbar beschrieben werden sollte. Also kurz mit zpool destroy data den Pool zerstört und das "letzte, aktuelle System" wieder angestartet. - Es fuhr ohne Probleme an.

Ich vermute mal, dass OpenSolaris so schlau war, bemerkt zu haben, dass das "scrub" abbrach und nach dem Systemstart weiter machte. Natürlich wieder mit dem Ergebnis, dass es sich dem Suizid hingibt.

Da der mysteriös zerstörte Pool nun aber nicht mehr existierte, läuft wieder alles perfekt. Also muss der Selbstmord-Pool doch glatt nochmal angelegt werden: zpool create data mirror c3d0p2 c3d0p3 Im Anschluss wieder die Festplatte Vollschreiben und ein erneutes zpool scrub data

Zuverlässig ist OpenSolaris - das kann ihm niemand absprechen. Denn das Ergebnis war das gleiche!

Nun, zu welchen Ergebnis komme ich?

Das ZFS von OpenSolaris ist sicher innovativ, revolutionär und ein Grund mit farbenfroh-schillernden Attributen um sich zu werfen. ABER - Selbstheilungskräfte... Davon ist das ZFS (meiner Meinung nach) noch ein Stück entfernt!

Ich bin mir sicher, dass es beim "normalen" Festplatten-Tot mehr Sicherheit und von mir aus auch Selbstheilungskraft beweist, als beispielsweise das gute, alte FAT.

Aber es gilt immer noch:

Es geht nichts über ein Backup!

ZFS - Übersicht