Kann ZFS einen plötzlichen Stromausfall bewältigen? (Welche Ereignisse führen dazu, dass ein Pool nicht wiederhergestellt werden kann, wenn der Datenträger selbst nicht ausgefallen ist oder unzuverlässig wird.)

Welche Chance hat ZFS, in einem konsistenten Zustand zu sein (auch wenn einige Daten verloren gegangen sind) und der Pool beim Neustart verwendbar / lesbar ist?

ZFS funktioniert wie ein Transaktionsdatenbank- Verwaltungssystem, da alte Daten beim Aktualisieren nicht überschrieben werden, wie dies bei herkömmlichen Dateisystemen der Fall ist. Stattdessen werden die neuen Daten an anderer Stelle auf die Festplatte geschrieben, dann werden die Metadatenstrukturen des Dateisystems so aktualisiert, dass sie auf die neuen Daten verweisen. Erst dann wird der Block der alten Daten für die Wiederverwendung durch das Dateisystem freigegeben. Auf diese Weise bleibt bei einem plötzlichen Stromausfall die alte Kopie der Daten bestehen, wenn die neuen Datenaktualisierungen nicht zu 100% auf permanenten Speicherplatz festgelegt sind. Sie haben nicht die Hälfte des Blocks ersetzt oder ähnliches, wodurch Daten beschädigt werden.

Darüber hinaus verwendet ZFS ein ausgefeiltes Prüfsummenschema, mit dem das Dateisystem falsch geschriebene oder beschädigte Daten erkennen kann.

Wenn Sie ZFS mit redundantem Speicher verwenden, kann dieses Dateisystem bei der Reparatur des Dateisystems zwischen zwei oder mehr redundanten Kopien der Daten wählen. Wenn Sie also zwei Kopien eines Blocks haben und nur eine davon mit der gespeicherten Prüfsumme übereinstimmt, weiß das Dateisystem, dass es die fehlerhaften Kopien mit der leeren reparieren soll.

Diese Reparaturen können im zfs scrublaufenden Betrieb ausgeführt werden, wenn Sie versuchen, die Daten zu lesen oder zu ändern. Daraufhin erkennt das Dateisystem möglicherweise, dass die angeforderten Blöcke nicht vollständig koscher sind - oder während einer Operation. Es ist üblich, einen Scrub so zu planen, dass er regelmäßig in ZFS-Pools ausgeführt wird, auf die selten auf Dateien zugegriffen wird, da das Dateisystem sonst keinen Hardware-Datenverlust im normalen Betriebsablauf feststellen würde. Es ist üblich, dass ZFS-Pools, die auf zweifelhafter Hardware ausgeführt werden, nach jedem Scrubben eine bestimmte Anzahl fester Blöcke anzeigen.

Das Scrubben ist ein bisschen wie fsckbei anderen Dateisystemen vom Typ Unix, nur dass dies online geschieht, während das Dateisystem eingehängt und verwendbar ist. Dies geschieht im Hintergrund und nur, wenn sich der Pool sonst im Leerlauf befindet. Außerdem fsckprüfen Implementierungen normalerweise nur Metadaten und nicht Daten, sondern beide ZFS-Prüfsummen und können somit Fehler in beiden erkennen. Wenn diese Integritätsmechanismen entscheiden, dass einer der Blöcke ersetzt werden muss, kann er anhand der Prüfsummen entscheiden, mit welcher Kopie die beschädigten Kopien ersetzt werden sollen.

Angenommen, die Speichermedien, Hardware und Software funktionieren noch zuverlässig / ordnungsgemäß. Was muss sonst noch schief gegangen sein, damit ein Pool verloren geht?

Meines Wissens gibt es keinen solchen Fall. Entweder ist eines der drei Dinge, die Sie erwähnen, fehlgeschlagen, oder ZFS wird den Pool bereitstellen und aus ihm lesen.

Unzureichende Redundanz + Festplattenfehler (oder andere schwerwiegende Hardwareprobleme) ist ein Fall

Ja, obwohl dies in einem subtileren Fall passieren kann, als ich denke, dass Sie darüber nachdenken.

Nehmen Sie einen einfachen 2-Wege-Spiegel. Ich denke, Sie denken darüber nach, dass eine der Festplatten physisch vom Computer entfernt oder zumindest aus irgendeinem Grund nicht zugänglich ist. Stellen Sie sich jedoch vor, dass der Sektor 12345 auf beiden Festplatten beschädigt ist. Dann können Ihnen alle intelligenten Prüfsummen und Redundanzen in ZFS nicht helfen: Beide Kopien sind beschädigt, sodass der gesamte Block, der diesen Sektor enthält, nicht gelesen werden kann.

Aber hier ist der Clou: weil ZFS ist sowohl ein Dateisystem und ein Volume - Manager - im Gegensatz zu peitschen-up wie Hardware - RAID + ext4 oder LVM2 + ext4 - ein zpool statusBefehl werden Ihnen sagen, welche Datei unwiederbringlich beschädigt wird. Wenn Sie diese Datei entfernen, kehrt der Pool sofort in einen unbeschädigten Zustand zurück. Das Problem wurde behoben. Die Lash-ups, die das Dateisystem von den RAID- und LVM-Komponenten trennen, können dies nicht tun.

Welche Situationen müssen entstehen, bevor es nicht möglich ist, und was muss geschehen, um sie entstehen zu lassen?

Der einzige Fall, den ich kenne, ist so etwas wie das obige Beispiel, bei dem die Datenbeschädigung die redundanten Kopien der Metadaten der Schlüsseldateisysteme beschädigt hat, die ZFS nicht lesen kann.

Aus diesem Grund mit heutigen extrem großen Festplatten - 100 Billionen Bits! - Ich empfehle, dass Sie ZFS (oder ein anderes RAID- oder LVM-System) mit mindestens zwei Redundanzen konfigurieren. In ZFS bedeutet dies raidz2, 3-Wege-Spiegel oder höher.

Allerdings speichert ZFS normalerweise weitere Kopien aller Metadaten des Dateisystems, die über die normalen Redundanzwerte für reguläre Dateidaten hinausgehen. Ein 2-Wege-Spiegel speichert beispielsweise 2 Kopien der regulären Benutzerdaten, aber 4 Kopien aller Metadaten. Sie können dies für die Leistung zurückrufen, aber Sie können es nicht vollständig deaktivieren.

Es gibt ein Kapitel im ZFS-Handbuch über ZFS-Fehlermodi, das Sie möglicherweise aufklären werden.

Da meine Kommentare zu lang werden, erscheint diese Antwort nützlich. Warren Young hat bereits alle grundlegenden Überlegungen in seiner Antwort richtig umrissen, daher konzentriere ich mich auf den Teil "Spiegeln oder nicht Spiegeln des SLOG-Geräts?".

Die Situation ist wie folgt:

Ich wandere zu meinem ZFS-System und stolpere ohne Vorwarnung hoch und riss den P3500 ZIL aus Versehen während einer sehr eingehenden Datensitzung heraus, und das System friert sofort ein. Dank eines guten Netzteils und MB sind die anderen Festplatten / SSDs nicht von den elektrischen Transienten betroffen. Mit Ausnahme des ZIL war jede andere Platte / Band redundant. Habe ich gerade ein paar Daten verloren, den gesamten Pool oder "es kommt darauf an" und wenn es darauf ankommt, worauf? )

Wenn Sie darüber nachdenken, wird die ZIL normalerweise auf allen Pool-Festplatten gespeichert und genießt daher dieselbe Redundanz wie der Pool. Wenn Sie ihn aus Geschwindigkeitsgründen auf einem separaten Gerät nach außen verschieben, müssen Sie selbst einen anderen Spiegel erstellen, wenn Sie Redundanz benötigen. Aber selbst wenn Sie es nicht haben, verlieren Sie nur die winzige Datenmenge in der ZIL (Wiederherstellen von Sicherungskopien ist nur erforderlich, wenn Synchronisierungsschreibvorgänge erforderlich sind und die Anwendungsdaten beschädigt sind) und machen nicht den gesamten Pool inkonsistent (was dazu führt, wäre in allen Fällen aus dem Backup wiederherzustellen).

Nun zur Frage, was Sie wählen sollen:

Irgendwann muss ich entscheiden, wofür ich entwerfen möchte, wenn ich mein Geld auf die Hardware-Spezifikation verteile.

Das hängt von Ihrer Situation ab (wie immer):

• Wenn Sie nur einfachen Datenspeicher haben (klassischer Dateiserver), erhalten Sie durch das Verschieben der ZIL auf ein SLOG-Gerät nicht viel (oder nichts), da SMB asynchron ist und plötzlichen Stromausfall bewältigen kann. Ich glaube, für NFS hängt es von Ihren Entscheidungen / Ihrer Software ab, aber heutzutage verwenden die meisten Leute SMB auf allen drei Hauptsystemen.
• Wenn Sie Geschwindigkeit und Integrität benötigen (meistens für Datenbanken und VM-Speicher), werden Sie (sollten) mit laufen, sync=alwaysund Sie benötigen ein SLOG-Gerät für das ZIL, oder es wird sehr langsam. In diesen Fällen können Sie entweder das SLOG-Gerät spiegeln oder entscheiden, dass das Ereignis "plötzlicher SSD- / Controller-Hardwarefehler oder -abbau UND plötzlicher Stromausfall" selten genug ist, um es ohne auszuführen. Sie können dann entscheiden, ob die Kosten vertretbar sind oder nicht (in den meisten Fällen ist dies der Fall, da der Rest der Hardware recht teuer ist, aber immer noch viel günstiger als kommerzielle Angebote).
• Wenn Sie Ruhe haben möchten, aber auf einem Etat sind, kann ich die Intel SSD 730 empfehlen. Sie wird als "Gamer" - oder "Enthusiasten" verkauft, ist jedoch der kleineren 3700-Serie intern sehr ähnlich, wenn Sie die Datenblätter vergleichen . Es hat auch die Superkondensatoren, als mehrere Quellen im Webzustand. Natürlich wird Intel das nicht zugeben, denn dann würde niemand die teuren kaufen.

Bearbeiten: in Bezug auf Ihren Kommentar:

NFS / ESXi / Sync wird ein wichtiger Anwendungsfall sein. Da die Kosten und das Risiko auf meinen Schultern liegen, versuche ich, das Risiko zu verstehen, anstatt einen empfohlenen Ansatz zu erhalten - wenn das separate ZIL als Teil des Stromausfalls ausfällt (ob es beabsichtigt war, redundant zu sein oder vor Verlust geschützt zu sein, usw.), aber nichts anderes ist betroffen. Der Verlust / die Beschädigung ist auf die vom ZIL empfangenen Daten beschränkt, die noch nicht in den Pool geschrieben wurden (die letzten Sekunden sind die Daten im schlimmsten Fall) und sind wiederherstellbar. Angenommen, keine andere Art von Fehler gleichzeitig) kann der Pool nicht wiederhergestellt werden?

Alle Punkte gelten nur unter der Annahme Ihres Beispiels, und keines der folgenden Punkte trifft zu: (a) Fehler in ZFS, (b) vollständiger Hardwarefehler aller Ihrer Pool-Festplatten, (c) menschlicher Fehler / Bosheit.

• Ihre Pooldaten sind sicher und die Integrität der Daten bleibt erhalten. Das bedeutet, dass Sie den Pool importieren können und aus Sicht von ZFS nicht beschädigt werden. Dies ist das normale Verhalten eines Stromausfalls in ZFS und Teil seines Designs.
• Nach Wiederherstellung der Stromversorgung wird normalerweise die ZIL gelesen, um die verlorenen Transaktionen (ähnlich einem RDBMS) erneut auszuführen. Jetzt ist folgendes möglich:
  • Ihr SLOG-Gerät ist nicht beschädigt, oder die beschädigten Teile können vom SLOG-Spiegel wiederhergestellt werden: Alles funktioniert wie gewohnt (nach einem eventuellen Resilver), und Ihre letzten 5 Sekunden werden in den Pool zurückgeschrieben.
  • Ihr SLOG-Gerät ist beschädigt: ZIL kann nicht ordnungsgemäß zurückgesetzt werden. Ich weiß nicht, ob ein teilweiser Rollbackversuch unternommen wird, aber aus Ihrer Sicht wäre es nicht wichtig (weil Sie alle Transaktionen benötigen). Ich gehe davon aus, dass Ihre letzten 5 Sekunden verworfen werden.

Aus Sicht des Pools ist selbst dieser schlechteste Fall ziemlich gut - 5 Sekunden verloren, aber der Pool kann importiert werden (wenn seine Version mindestens 19 ist ). Vom Anwendungspunkt aus kann dies jedoch ein kritischer Fehler sein - die Anwendung hat gerade 5 Sekunden Sync-Daten geschrieben, die Bestätigung erhalten, dass sie erfolgreich geschrieben wurde, und nach dem Neustart fehlen die Daten, die Anwendung weiß dies jedoch nicht. Der genaue Fehler hängt von der Anwendung ab. Ein DBMS ist möglicherweise inkonsistent geworden und muss repariert werden, eine große Datendatei kann unlesbar sein, Systemdateien können schwer zu Abstürzen führen, eine verschlüsselte Speicherpartition ist möglicherweise nicht mehr wiederherstellbar - alles, weil ein Teil des DBMS nicht vorhanden oder falsch ist.

Ein weiterer Punkt, der selten erwähnt wird: SSDs können unerwartet sterben, daher ist das Spiegeln wichtiger als bei HDDs. Wenn Sie jedoch zwei identische SSDs ab Werk neu in das System einsetzen, können Ihre Fehler gleichzeitig auftreten.

Sie können eine gute Zusammenfassung über Solaris ZFS, Synchronous Writes und die erläuterte ZIL sowie einige Details zum Anteil von Datenverlustsituationen zu den Auswirkungen des Verlusts eines ZFS-ZIL-SLOG-Geräts nach meinem Verständnis lesen . Die Oracle-Dokumentation ist etwas kurz, erwähnt jedoch auch, dass sich die ZIL bei normalem Betrieb automatisch von SLOG zu Pool-Geräten bewegt, wenn ein SLOG-Fehler auftritt (natürlich haben Sie dort eine Sicherheitslücke von 5 Sekunden).

Die Manpage bietet auch Informationen zum Importieren von Pools ohne ZIL:

 zpool import -a [-DfmN] [-F [-n]] [-c cachefile|-d dir] [-o mntopts] [-o property=value]... [-R root]  -m Allows a pool to import when there is a missing log device. Recent transactions can be lost because the log device will be discarded. 

Ich verwende ZFS auf 4 Servern und auch meinem Laptop seit über 5 Jahren. Ich hatte wenige Stromausfälle auf schreibintensiven Servern (defekte USV-Firmware meldete falsche Daten) und bemerkte ANY * -Datenfehler / Pool-Mount-Probleme nicht (was nicht bedeutet, dass bei der letzten Transaktion kein Datenverlust aufgetreten ist, der nicht wie beschrieben das Schreiben beendet hatte.) /Kuh)

* Mit Ausnahme eines einzigen Ereignisses, als ich vom ZFS-Handbuch abwich: Ich hatte ZFS auf einer einzigen Festplatte (iSCIS SAN LUN auf dem Host) in KVM Guest und nach der ersten Datenkopie habe ich vergessen, den Cache-Modus von WriteBack in WriteThrough zu ändern. Pool (5 TB) war lesbar, hatte jedoch Fehler von 20.000. Ich musste den Pool mithilfe von Daten vom Sicherungsserver neu erstellen - dank zfs-Snapshots und zfs senden / empfangen habe ich nur 2 Minuten an Daten verloren (was sehr viel schlimmer sein könnte). Verwenden Sie ECC-Speicher, deaktivieren Sie die gesamte Schreibpufferung (zumindest ohne BBU / FBU - Thema für eine andere Story), RTFM und ZFS sind absolut solide.