ECC-RAM und RAID/ZFS/BTRFS Dateisysteme in VM´s?

[fdiskc2000]

Moin zusammen,

ich stelle mir gerade die Frage ob es Sinn macht, bzw. notwendig ist, wenn in einer VM zusätzlich zum darunterliegenden ZFS-Dateisystem ebenfalls ein RAID mit z.B. BTRFS eingerichtet wird.

Es geht um meinen Server #2, der hier weit verbreitete ESXI mit ZFS-Storage Appliance.
Nun ist eine meiner VM´s auch ein XPenology zum testen und spielen. Muss ich dieser VM genau so 2 "HDD" zu einem Raid1/BTRFS zuweisen um die gleiche Datensicherheit zu haben wie bei meiner echten Diskstation? Meine echte Diskstation fährt ein Raid 1 mit BTRFS (ich weiss kein ECC).

Oder ist das quasi durch den darunter liegenden ESXI mit ECC RAM und ZFS Filesystem abgesichert? Die XPenology-VM könnte ja quasi die in ihr liegenden Daten nicht per Scrub verifizieren und reparieren wenn sie kein eigenes RAID hätte, oder? Es ist ja "eigentlich" ein eigenständiger Rechner?

Ich hoffe ich konnte rüber bringen was ich meine und schreibe nicht zu wirr

 

[gea]

Wenn eine Storage VM direkten Hardwarezugriff erhält (pass-through), muss sie sich selbst um alles kümmern. Gibt es bereits eine Storage VM, so nutzen weitere VMs virtuelle Platten auf dem ZFS Storage z.B. über NFS.

Ein Raid über mehrere virtuelle Platten bringt keinen Sicherheitsgewinn - ganz im Gegenteil. Ein zusätzliches Xpenology Raid könnte durch das Write Hole Problem sogar gefärdeter sein. Für die Sicherheit der Daten ist nur ZFS zuständig und dafür auch erheblich besser geeignet.

Man muss allerdings wissen, dass ZFS einen RAM-Schreibcache von bis zu 4GB nutzt. Bei einem plötzlichen Crash ist der Inhalt des Schreibcaches verloren sofern man kein Sync-Write auf ZFS aktiviert hat.

 

[fdiskc2000]

Mir geht es weniger um den Sicherheitsgewinn bzgl. des Ausfalls, sondern um die Sicherheit der korrekten Daten.

Wenn ich Dateien direkt in der Storage-VM habe so ist klar, dass diese durch die jeweiligen Mechanismen geschützt sind.
Wenn die Dateien aber in der VM selbst liegen (welche nur als VMDK auf dem ZFS liegen), so kann hier ja keinerlei Korrektur/Fehlererkennung stattfinden, bezogen auf diese Datei. Also bit rot Erkennung, oder? Ausser die VM selber nutzt wiederum ein COW-Dateisystem wie BTRFS und führt selbständig Scrubs ihrere Daten durch?

Das die VM per Share auf die Daten zugreift die originär in der Storage-VM liegen wäre zwar optimal (dann wäre die Überlegung ja bereits zu Ende), klappt aber leider (vielleicht auch nur in diesem Fall) nicht, da die VM-Programme nicht immer mit Shares arbeiten können.

 

[gea]

Die virtuellen Platten (vmdk), mit denen eine VM arbeitet liegen auf dem ZFS NFS Datastore und sind damit 100% abgesichert. Tritt ein Problem auf (Bitrot, Datenkorruption, Plattenausfall) so wird das von ZFS erkannt und repariert - egal mit welchem Dateisystem eine VM arbeitet. Selbst ein relativ unsicheres FAT Dateisystem ist als VM auf ZFS so sicher wie es eben geht - viel sicherer als es das mit eigenem Plattenzugriff jemals sein könnte.

Aus Sicht einer VM wie Xpenology sind die virtuellen vmdk Platten bitrotfrei und immer 100% valide. Eine Datenscrub auf der Ebene Xpenology/btrfs würde da nichts verbessern - mal davon abgesehen dass Xpenology mit btrfs und Prüfsummen zwar Fehler im Raid erkennen kann, die aber über das mdadm/Linux Raid eh nicht reparieren könnte.

Wichtig ist nur, dass einem der Schreibcache im darunterliegenden Storage keine Daten verlieren lässt.

 

[fdiskc2000]

Ah ok, also werden die guten Eigenschaften quasi an die VM´s "vererbt" und eine doppelte Sicherung wäre nicht notwendig. Wie immer vielen Dank für Deine kompetente Hilfe, gea.

... mal davon abgesehen dass Xpenology mit btrfs und Prüfsummen zwar Fehler im Raid erkennen kann, die aber über das mdadm/Linux Raid eh nicht reparieren könnte. ...

Das ist übrigens seit dem aktuellen DSM 6.1 nicht mehr korrekt, nun kann auch korrigiert werden. (also zumindest die originalen Diskstations)

 

[gea]

Das ist übrigens seit dem aktuellen DSM 6.1 nicht mehr korrekt, nun kann auch korrigiert werden. (also zumindest die originalen Diskstations)

Ich nutze Xpenology nicht. Das Reparieren aus Prüfsummen und Redundanz im Raid-1 wäre auch durchaus machbar sofern btrfs-Softwareraid genutzt wird. Die ganzen Raid-Spezialitäten von Xpenology wie auch höhere Raid-Level sind damit aber nicht machbar bzw. nur ohne Reparaturoption.

 

[fdiskc2000]

Die ganzen Raid-Spezialitäten von Xpenology wie auch höhere Raid-Level sind damit aber nicht machbar bzw. nur ohne Reparaturoption.

Könntest Du das bitte noch etwas genauer erläutern? Denn wenn ich es nicht falsch verstehe, hebt Synology das ja gerade hervor:

Datei-Selbstreparatur

Das Btrfs-Dateisystem kann mithilfe der Metadatenspiegelung beschädigte Dateien (schleichende Datenkorruption) automatisch erkennen und fehlerhafte Daten mittels der unterstützten RAID-Volumes, einschließlich RAID 1, 5, 6, 10, F1 und SHR, wiederherstellen.

 

[gea]

Ich kann zu Xpenology Features natürlich nur spekulieren.
Das grundsätzliche Problem ist aber folgendes:

Geht in einem Raid eine Platte oder Sektor kaputt, so wird dies wenn es erkannt wird aus dem Raid repariert. Dazu braucht man keine Datenprüfsummen und btrfs/ReFS oder ZFS. Der Begriff Metadatenspiegelung besagt zudem auch nur, dass Metadaten (was ist wo gespeichert) doppelt vorhanden sind. Liegen Metadaten auf einem defekten Sektor, so wird die Kopie gelesen - alles Gut.

Das Problem z.B. bei Bitrot ist nun aber folgendes.
Wenn man beispielsweise einen Mirror hat der von von ZFS Softraid verwaltet wird und bei dem auf einer Platte ein Fehler auftritt so sind beide Mirrorhälften unterschiedlich. Beim Lesen gibt es jetzt eine 50% Wahrscheinlichkeit dass der "gute" oder "schlechte" Block gelesen wird. Bei einem normalen Raid ohne Prüfsummen kann weder festgestellt werden ob der Block fehlerhaft ist noch kann im Zweifen bestimmt werden welcher der beiden Daten konsistent ist. Genau dazu braucht man die Datenprüfsummen.

ZFS erkennt beim Lesen den Fehler damit sicher als Prüfsummenfehler und kann dann den gleichen Block aus dem anderen Mirror lesen. Ist der ok wird der fehlerhafte Block repariert.

Liegt nun ein Raid zwischen btrfs oder ZFS und den einzelnen Platten (aus btrfs/ZFS Sicht ist das Raid dann ja praktisch wie eine einzelne Platte) so kann der Fehler beim Lesen zwar als Prüfsummenfehler erkannt werden. Da btrfs/ZFS aber keinen direkten Zugriff auf die einzelnen Platten hat (den hat ja nur das mdadm/MHR/Hardware/was auch immer Raid) so kann es den Fehler nicht reparieren. Das Raid selber kann das auch nicht, denn es erkennt den Fehler ja nichtmal da es mit den btrfs/ZFS Prüfsummen nichts anfangen kann.

Daran wird sich absehbar wohl auch nichts ändern. Xpenology wird höhere Raidfeatures nicht aufgeben wollen und der Ausweg btrfs-Raid 5/6 ist im Gegensatz zu btrfs Raid-1 absehbar nicht stabil. Sonderraid Features wie SHR werden wohl absehbar nie mit btrfs zusammenarbeiten.