Wie die Frage schon sagt.
Angenommen, ich möchte das Äquivalent einer skriptgesteuerten „Notfalltaste“ für meinen FreeNAS-Pool haben – etwas, auf das ich klicken kann, um es von einer GUI aus auszuführen oder in Konsole/SSH auszuführen, wodurch sehr schnell alles geschlossen wird, was möglicherweise darauf liest oder schreibt. unmountet das Dateisystem und – im Idealfall – legt die verwendeten Festplatten oder Partitionen still.
Ich kümmere mich nicht um Fehler, die dadurch bei anderer Software oder Remoteverbindungen entstehen, oder um lange Dateiübertragungen vorzeitig abzubrechen, ich möchte nur, dass der Pool so schnell wie möglich offline geschaltet wird, um seine Konsistenz zu erhalten und möglicherweise ein paar zu geben Sekunden, bis alle ausstehenden Schreibvorgänge abgeschlossen sind und der Pool für Datenzwecke in einem konsistenten Zustand ist.
Die von ZFS-Befehlen vorgeschlagenen Optionen sehen nicht vielversprechend aus:zpool offline funktioniert nur auf einzelnen Geräten, so dass es zu einer Race-Condition kommen kann, wenn geschrieben wird, während die Festplatten einzeln entfernt werden; zpool export erfordert die Option -f, falls verwendet, und enthält eine Warnung, dass -f können auch Daten verlieren. Man könnte alle offenen file descriptors überprüfen Verwenden Sie den Pool oder seine Geräte (Tausende oder Hunderttausende von ihnen?) und erzwingen Sie jedes manuelle Schließen, aber das könnte die Rennbedingungen beeinträchtigen, da es nicht verhindert, dass gleichzeitig neue fd erstellt werden. Ich sollte auch nicht davon ausgehen, dass alle ZFS-Aktivitäten durch eine Liste von Remote-Dateidienst-Daemons vermittelt werden, an die Exit-Signale gesendet werden, da einige Dateiaktivitäten wahrscheinlich lokal sind (cron/CLI/getrennte Sitzungen).
Wenn man sich also anschaut, wie man einen ganzen Pool am besten sicher und schnell offline schaltet, sieht es so aus:umount könnte meine beste Wahl sein – es funktioniert auf Dateisystemebene und kann ein ganzes Dateisystem schnell und als monolithische Einheit offline schalten, danach zpool export Es sieht so aus, als wäre es dann in der Lage, jede interne Aktivität auf sichere Weise ohne -f zu beenden und stillzulegen Möglichkeit, die Daten selbst in einem garantiert konsistenten Zustand zu halten. Wenn Raw-Disk-Aktivität stattfindet (Resilver oder Scrub), würde das vermutlich fortgesetzt oder neu gestartet werden, wenn der Pool später wieder online gebracht wird.
Aber auch umount scheint es nicht vollständig zu tun, weil es iSCSI zvol geben könnte auch Zielscheiben im Einsatz. Die Daten in diesen können von Natur aus nicht konsistent gehalten werden, da der Server seine Struktur nicht kennt, sodass die Remote-Initiatoren die Daten so gut wie möglich reparieren müssen, wenn sie sich wieder verbinden. Ich bin damit einverstanden, aber ich bin mir nicht sicher, ob eine Art Befehl zum erzwungenen Beenden oder Offlineschalten der Ziele erforderlich oder eine bewährte Methode ist. (Hinweis:Beenden von Verbindungen erzwingen hat die gleichen Probleme wie das Schließen einzelner fds.)
Mir ist bewusst, dass es zwangsläufig zu Datenverlusten oder Problemen kommen wird, wenn der Pool bei Schreibvorgängen abrupt aus dem RW-Status geworfen wird. Aber solange es nicht an Konsistenz verliert (auf ZFS-Pool- und Dateisystemebene), ist das in Ordnung – alle verwendeten Dateien/iSCSI-Ziele, die aktualisiert werden, müssen ihr Risiko eingehen, dass Dateien/Blöcke ZFS-konsistent sind aber datenungültiger Zustand, weil während des Schreibens von Daten offline gegangen wird. Das ist unvermeidlich und kein Thema für die Frage.
Welche Schritte muss ich also tatsächlich tun, um einen in Gebrauch befindlichen Pool so schnell wie möglich offline zu schalten, konsistent mit garantierter Pool-Sicherheit und -Konsistenz – und würde manuell umount die Nutzung eines in Gebrauch befindlichen ZFS-Dateisystems (als Teil einer Lösung) sicher ist oder das Risiko einer Datenbeschädigung birgt?
Aktualisierung: Hier erwähnen, falls jemand anderes dies nützlich findet. Die akzeptierte Antwort besagt, dass export -f möglicherweise Probleme mit zvols (iSCSI usw.). Basierend auf diesem Hinweis habe ich herausgefunden, dass der von FreeNAS verwendete iSCSI-Handler Sitzungen zwangsweise abmelden/beenden kann und andere nützliche Unterbefehle hat, die vorher ausgegeben werden könnten – siehe man ctladm . Wofür auch immer Ihre Zvols verwendet werden, es gibt wahrscheinlich einen Befehl, um Sitzungen auf ihnen zu beenden.)
Akzeptierte Antwort:
Haftungsausschluss:Ich habe im Moment nicht viele Links und Referenzen zur Verfügung, um alles unten zu sichern, und ich habe es nicht ausführlich getestet. Dies ist nur eine Zusammenfassung dessen, was ich in den letzten fünf bis sieben Jahren über ZFS und seine Funktionsweise gelesen habe, sowie einige begrenzte eigene Tests (nicht koordinierte, aber meist zufällige Neustarts).
Außerdem wird alles Nachfolgende ohne Berücksichtigung von Katastrophenereignissen (Server brennt vollständig ab), Softwarefehlern (Fehler in ZFS und dem Hauptbetriebssystem sowie Hardwarecontrollern) und aktiver Bosheit (Rogue Admin, Administrationsfehler) gesagt. Für all diese Fälle benötigen Sie dennoch regelmäßige und wiederherstellbare Backups!
Daten im Ruhezustand / Konsistenz auf der Festplatte
Ich kümmere mich nicht um Fehler, die dadurch bei anderer Software oder Remoteverbindungen entstehen, oder um lange Dateiübertragungen vorzeitig abzubrechen, ich möchte nur, dass der Pool so schnell wie möglich offline geschaltet wird, um seine Konsistenz zu erhalten und möglicherweise ein paar zu geben Sekunden, bis alle ausstehenden Schreibvorgänge abgeschlossen sind und der Pool für Datenzwecke in einem konsistenten Zustand ist.
Die gute Nachricht zuerst:Da ZFS CoW- und Atomic-Transaktionen verwendet, sind Ihre bereits vorhandenen Daten auch bei einem plötzlichen Stromausfall sicher. Dazu gehören das Pool-Layout und die Metadaten. Da alte Daten niemals verschoben werden, bevor neue Daten vollständig geschrieben wurden (tatsächlich werden sie überhaupt nicht verschoben, sondern nur neu zugewiesen), können diese Daten in keiner Weise gefährdet werden, wenn der Schreibvorgang plötzlich unterbrochen wird.
Verwandte:Grep – warum entfernen Klammern im grep-Muster den grep-Prozess aus ps-Ergebnissen?Darüber hinaus helfen Prüfsummen (Merkle-Hashbäume), um zu bestätigen, dass während des Neustarts nichts Schlimmes passiert ist, was Sie überprüfen können, indem Sie den Pool säubern. Wenn Sie über redundante vdevs verfügen, korrigiert ZFS automatisch alle Fehler, die es in einer bekanntermaßen guten Kopie findet. Wenn einige Blöcke in irgendeiner Weise beschädigt worden wären (zum Beispiel durch einen Rogue-Festplattencontroller, der nicht schreibt, aber sagt, dass er es tut), würden ihre Prüfsummen nicht mit denen von anderen vdevs übereinstimmen und Fehler würden angezeigt.
Daten im Flug-/Schreibmodus und Verlust der letzten n Sekunden
Synchronisierte und asynchrone Schreibvorgänge
Normalerweise sammelt ZFS mehrere Transaktionen, um die kostspieligen Schreibvorgänge auf rotierenden Laufwerken zu beschleunigen – das Positionieren des Schreibkopfs der Festplatte dauert viel länger als das eigentliche Schreiben, daher sollten Sie so viel wie möglich in die Warteschlange stellen und dann nacheinander (schneller) schreiben !) bestellen (denken Sie daran, wir haben CoW, das funktioniert hier ganz natürlich).
Der Nachteil dabei ist, dass je länger Sie sammeln, desto länger müssten Ihre Anwendungen auf eine „Schreiben erfolgreich“-Meldung warten – was bedeutet, dass Ihr System mehrere Sekunden lang gesperrt wird, was nicht akzeptabel ist. Schlimmer noch – Sie verlieren bei einem Stromausfall alle Daten, die auf die Festplatte geschrieben werden sollen, aber noch nicht geschrieben wurden. Wenn Ihre Anwendungen damit nicht zurechtkommen, kann es zu Beschädigungen auf der Anwendungsebene kommen.
Um dem entgegenzuwirken, wurde das ZIL (ZFS Intent Log) hinzugefügt. Alle Synchronisierungstransaktionen werden in diesem Protokoll gesammelt (das standardmäßig auf der langsamen Pool-Festplatte gespeichert wird, aber auf schnelleren, gespiegelten SSDs gespeichert werden kann, die als SLOG-Geräte bezeichnet werden) und nachdem sie gespeichert wurden, wird „Schreiben erfolgreich“ an die zurückgegeben Anwendung, die ihren Aufgaben nachgehen darf (keine langen Sperren mehr). Außerdem werden alle asynchronen Transaktionen ohne ZIL ausgeführt, sodass sie schneller sein können – vorausgesetzt, die Anwendung ruft die richtigen Schreibvorgänge für ihre Daten auf (sync vs. async).
ZFS-Eigenschaften
Nun zum interessanteren Teil – was passiert mit Ihren Schreibvorgängen? Dort müssen wir den Betriebsmodus für das Dateisystem erkennen (es ist eine ZFS-Eigenschaft und kann für jedes Dateisystem individuell eingestellt werden). Die drei möglichen Modi sind (aus den Manpages):
sync=standard
This is the default option. Synchronous file system transactions
(fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
and then secondly all devices written are flushed to ensure
the data is stable (not cached by device controllers).
sync=always
For the ultra-cautious, every file system transaction is
written and flushed to stable storage by a system call return.
This obviously has a big performance penalty.
sync=disabled
Synchronous requests are disabled. File system transactions
only commit to stable storage on the next DMU transaction group
commit which can be many seconds. This option gives the
highest performance. However, it is very dangerous as ZFS
is ignoring the synchronous transaction demands of
applications such as databases or NFS.
Setting sync=disabled on the currently active root or /var
file system may result in out-of-spec behavior, application data
loss and increased vulnerability to replay attacks.
This option does *NOT* affect ZFS on-disk consistency.
Administrators should only use this when these risks are understood.
Sie werden das bemerken, selbst wenn es disabled ist ausgewählt ist, wird Ihr Pool-Layout/Ihre interne Konsistenz nicht beeinflusst – Sie verlieren nur Ihre Daten der letzten 5 Sekunden und diese kann Ihre Dateien in einen falschen Zustand versetzen (z. B. weil Sie oben eine VM haben, die synchronisierte Schreibvorgänge erwartet, aber Sie nur ein asynchrones zvol als Sicherungsdatenspeicher angegeben haben).
Andererseits, wenn Sie überhaupt nichts verlieren möchten , setzen Sie alle Ihre Dateisysteme auf always und wechseln Sie zu Hochleistungs-SSDs, zumindest für das SLOG-Gerät (oder leiden Sie unter den Wartezeiten).
standard ist ein Kompromiss und am flexibelsten – die Anwendung entscheidet selbst, welchen Schreibmodus sie benötigt. Wenn Ihre Anwendungen schlecht sind, kann es zu Datenverlust kommen. Wenn sie sich benehmen, haben Sie die bestmögliche Leistung bei einer gegebenen Sicherheitsbasis.
Pool-Export/Import:
Aus der Dokumentation über zpool export :
Der Befehl versucht, alle gemounteten Dateisysteme innerhalb des Pools auszuhängen, bevor er fortfährt. Wenn eines der Dateisysteme nicht ausgehängt werden kann, können Sie es erzwingen, indem Sie die Option -f verwenden.
Wenn Geräte zum Zeitpunkt des Exports nicht verfügbar sind, können die Geräte nicht als sauber exportiert identifiziert werden. Wenn eines dieser Geräte später an ein System ohne funktionierende Geräte angeschlossen wird, wird es als „potenziell aktiv“ angezeigt.
Wenn im Pool ZFS-Volumes verwendet werden, kann der Pool auch mit der Option -f nicht exportiert werden. Um einen Pool mit einem ZFS-Volume zu exportieren, stellen Sie zunächst sicher, dass alle Verbraucher des Volumes nicht mehr aktiv sind.
Das bedeutet ungefähr drei Dinge:
-ferzwingt den Export des Pools, indem alle Dateisysteme zwangsweise ausgehängt werden, auch wenn sie aktiv sind (ohne Rücksicht auf Sperren oder dort schreibende Anwendungen)- Dies funktioniert nicht mit
zvols - Sie sollten Pools nicht aufteilen und auf verschiedenen Systemen verwenden (Vorsicht bei Failover-Situationen)
Zusammenfassung:
- Wenn Sie sich nur um die Konsistenz auf der Festplatte kümmern, sind Sie mit
export -fgut beraten oder ein kompletter Shutdown - Wenn Ihnen alle Daten wichtig sind, verwenden Sie
sync=alwaysund schnelle SSDs - In Bezug auf iSCSI/NFS als Datenspeicher für VMs kann diese Übersicht ebenfalls hilfreich sein (Auszug:Verwenden Sie NFS oder deaktivieren Sie den iSCSI-Writeback-Cache auf dem Gast-/VM-Host; legen Sie die VM still, bevor Sie einen ZFS-Snapshot erstellen, ZFS ist trotzdem in Ordnung, aber Gast-VM wird nur absturzkonsistent sein)
Als Antwort auf Folgefragen aus den Kommentaren (ausgelassene Fragen, auf die ich keine nützlichen Antworten habe):
(1) „gute Nachrichten/COW“ – was wäre, wenn die Blöcke der obersten Ebene aktualisiert würden – wird es immer einen verwendbaren Block der obersten Ebene finden (selbst wenn es auf leicht alte Versionen des Metadatenbaums verweist)? Wie schlimm kann das werden?
Im schlimmsten Fall wäre der Uberblock (der über allen anderen) auf allen redundanten Geräten beschädigt. Da sich kein Block darüber befindet, können Sie ihn nicht von oben rekonstruieren, daher existieren mehrere Kopien von jedem Uberblock (IIRC war es ungefähr 3 oder 4), sodass eine verloren gehen kann und eine Ersatzkopie immer noch vorhanden ist.
(2) Ich bin mit TXGs vertraut und verwende ESXi. Verwenden von APC UPS + gutem Netzteil/HW + P3700 NVMe ZIL, also anständige Leistung + schnelles ZIL. Aber es ist unwahrscheinlich, dass aktuelle Schreibvorgänge alle synchron sind, und wie Sie sagen, ist sync=always langsam. Aber Ihre Antwort wirft einen Gedanken auf, ich könnte einige Leistungstests durchführen. Ich verwende Deduplizierung (4x sparen, lohnt sich), also schreiben Sie trotzdem langsam (muss DDT nachschlagen). Der Grund dafür ist, dass sync=immer nur das Schreiben betrifft, das aufgrund von DDT sowieso langsam ist. Aber das Setzen von sync=erzwingt immer ZIL, ZIL ist sehr schnell und das macht lange TXGs sicher, was bedeuten könnte, dass der Festplattenzugriff effizienter ist. Oder es könnte die Latenz töten. Keine Ahnung welche! Vielleicht müssen wir es versuchen!
Ich habe keine wirkliche Erfahrung mit Deduplizierung, daher kann ich hier nichts Nützliches sagen, außer dass Sie bereits eine gute Hardwareauswahl getroffen haben (geringe Latenz, hohe zufällige 64k-Schreib-IOPS, NVMe-Schnittstelle). Es könnte nur schneller sein, wenn Sie in ein wirklich teures permanentes RAM-Laufwerk investieren (ZeusRAM et al.).
(6) Mit „Festplattenkonsistenz“ meinen Sie, dass ZFS zufrieden ist und der Pool selbstkonsistent ist? Keine Sorge, wenn einige Dateien/Verzeichnisse. endet mit ungültigem Inhalt oder wird nicht verschoben/gelöscht, wenn der Pool plötzlich verschwindet oder ein Dateisystem wie NTFWS/VMFS auf einem zvol intern beschädigt wird (dh als ZFS-zvol ist es in Ordnung, aber aus Client-Perspektive benötigt es fsck/chkdsk), bereitgestellter Pool aus Sicht von ZFS sicher/konsistent ist
Ja. Im Wesentlichen „mein Pool ist nicht beschissen, yay!“ in einem Mehrbenutzer-Setup – selbst wenn ein Benutzer Probleme mit seinen Dateien hat, leiden die anderen nicht darunter.
(7) Mit „absturzkonsistent“ meinst du, was ich meine (ich glaube, das tust du) – dass ZFS in Ordnung sein wird, der Pool, soweit ZFS es sieht, in Ordnung sein wird, aber die Daten des Remote-Clients können von denen dieses Clients verfälscht werden Perspektive ähnlich, als ob der Client einen plötzlichen Festplatten-E / A-Fehler erlitten hätte und Schreibvorgänge verloren gegangen wären? ==Der Pool ist in Ordnung, der Client hat möglicherweise Daten verloren/inkonsistent und benötigt möglicherweise Hilfe bei der Wiederherstellung, wie bei jedem anderen Festplatten-E/A-Fehler oder Systemabsturz?
Ja, im Wesentlichen ein hartes Ausschalten der VM anstelle eines sauberen Herunterfahrens und DANN Erstellen eines Snapshots – wenn Sie es danach einschalten, fsck o.ä. je nach Dateisystem ausgeführt und kann sich über unsauberes Herunterfahren beschweren. Dies steht im Gegensatz zu ESXi-Snapshots, die genau zu dem Zeitpunkt fortgesetzt werden, als ob nichts passiert wäre, aber sie benötigen eine Interaktion mit dem Gastsystem (Gasterweiterungen installiert) und umfassen den virtuellen Speicher der VM.
Sie können beides zu Ihrem Vorteil kombinieren:Zuerst einen ESXi-Snapshot erstellen, dann anschließend einen ZFS-Snapshot des Datenspeichers (ESXi speichert seine Snapshots neben der VM). Löschen Sie dann Ihren ESXi-Snapshot, aber behalten Sie den ZFS-Snapshot (benötigt aufgrund von Kopien auf Blockebene viel weniger Speicherplatz). Stellen Sie beim Wiederherstellen zuerst Ihren ZFS-Snapshot wieder her und kehren Sie dann zu Ihrem (gespeicherten) ESXi-Snapshot zurück, und Sie machen dort weiter, wo Sie aufgehört haben. napp-it (hervorragendes ZFS-Verwaltungssystem mit Weboberfläche) hat dieses Konzept integriert (zumindest für NFS-Datenspeicher habe ich iSCSI nicht überprüft, gehe aber davon aus, dass es ähnlich ist).