[Sammelthread] ZFS Stammtisch

[gea]

Prinzipiell sehe ich das auch so.
Mit einem CopyOnWrite Dateisystem ist man privilegiert.
Wenn beim Kopieren oder Speichern einer Datei der Strom ausfällt, ist die Datei kaputt (sofern das schreibende Programm z.B. wie Office nichts dagegen unternimmt), das Dateisystem aber ok (Während es bei alten Dateisystemen potentiell korrupt ist oder Transaktionen nicht mehr konsistent sind)

Es gibt aber Fälle, wo das auch mit ZFS absolut nicht geht, z.B.
Auf ZFS liegt ein altes Dateisystem, z.B. ESXi per NFS oder es werden sichere Transaktionen benötigt, z.B. Finanztransaktionen/ Buchungen. Das ist dann ein Fall für sicheres sync Write mit einem Zil Logdevice und dann darf es absolut nicht passieren, dass eine SSD Daten irgendwo im Cache verliert.

Es gibt dazwischen noch Fälle wo man z.B. mit SMB aus Performancegründen auf sync verzichtet und dennoch beste Sicherheit haben möchte. Ich würde mit CopyOnWrite die absolute Notwendigkeit aber vor allem bei Log Devices sehen.

 

[Rahvin]

Erklärt immer noch nicht die angebliche Unterscheidung zwischen Nutz- und Metadaten, die die Frage als gegeben dargestellt hat. Woher kommt diese Info?

Siehe z.B. hier: Micron M600 (128GB, 256GB & 1TB) SSD Review

In the MX100 review, I was still under the impression that there was full power-loss protection in the drive, but my impression was wrong. The client-level implementation only guarantees that data-at-rest is protected, meaning that any in-flight data will be lost, including the user data in the DRAM buffer. In other words the M500, M550 and MX100 do not have power-loss protection -- what they have is circuitry that protects against corruption of existing data in the case of a power-loss.

 

[gea]

Eine SSD weiss ja nicht was Metadaten sind und was Daten.
Ist aber auch egal. Wenn eine SSD dem OS "Daten sind auf dem Storage" meldet, dann muss das bei vielen Anwendungsfällen genau so sein, bei anderen mag das egal sein.

 

[Rahvin]

Eine SSD weiss ja nicht was Metadaten sind und was Daten.

Das möchte ich bezweifeln. Eine SSD muss ja wissen in welchen physischen Teil des Flash Speichers ein logischer Block geschrieben wurde (Stichworte Overprovisioning, Wear-Levelling).

Damit wir nicht aneinander vorbei reden: Ich denke bei Metadaten an die "Verwaltungsdaten" der SSD, nicht etwa die Metadaten eines Dateisystems (welche für die SSD natürlich zu den Benutzer-Daten zählen) - war vielleicht nicht ganz eindeutig in einem Filesystem-Thread

 

[gea]

Das möchte ich bezweifeln. Eine SSD muss ja wissen in welchen physischen Teil des Flash Speichers ein logischer Block geschrieben wurde (Stichworte Overprovisioning, Wear-Levelling).

Damit wir nicht aneinander vorbei reden: Ich denke bei Metadaten an die "Verwaltungsdaten" der SSD, nicht etwa die Metadaten eines Dateisystems (welche für die SSD natürlich zu den Benutzer-Daten zählen) - war vielleicht nicht ganz eindeutig in einem Filesystem-Thread

Für mich sind Metadaten zunächst Strukturdaten des Filesystems. Nur das ist ja für das Schreiben zunächst wichtig. SSD eigene Optimierungen, Garbage Collection etc ist davon unabhängig und "sollte" auch ohne power-loss protection sauber funktionieren.

Ist aber ein weiterer Grund für sicheres Powerloss Protection. Mein Vertrauen in die SSD Fähigkeiten von Consumer SSDs ist da auch begrenzt.

 

[trendco]

Es gibt aber Fälle, wo das auch mit ZFS absolut nicht geht, z.B.
Auf ZFS liegt ein altes Dateisystem, z.B. ESXi per NFS oder es werden sichere Transaktionen benötigt, z.B. Finanztransaktionen/ Buchungen. Das ist dann ein Fall für sicheres sync Write mit einem Zil Logdevice und dann darf es absolut nicht passieren, dass eine SSD Daten irgendwo im Cache verliert.

Ok, Du meinst also, wenn ich z.B. ein Dataset eines Pools per NFS an ESXi, Proxmox, etc. als Datastore für Ihre VM's bereitstelle und die dort laufende VM z.B. ein Windows mit NTFS oder ein Linux mit ext4 ist, dann wäre bei einem Powerloss (ohne Protection) zwar der ZFS-Pool auf alle Fälle konsistent, nicht aber unbedingt die Filesysteme der VM's mit NTF / ext4 ?

 

[gea]

Ein konsistentes ZFS Dateisystem heisst ja noch lange nicht, dass auch ein darauf angelegtes ext4 oder ntfs konsistent bleibt. Auch sonstige offene Dateien können natürlich nach einem Powerloss korrupt sein. Das verhält sich dann auch nicht anders beim Powerloss als wenn das Dateisystem direkt auf Hardware laufen würde. Das wird nur dann besser wenn man ein Hardware Raid mit Cache und BBU oder eben ZFS mit sync write nutzt das die letzten noch offenen Writes nach dem Reboot nachholt.

 

[trendco]

oder eben ZFS mit sync write nutzt das die letzten noch offenen Writes nach dem Reboot nachholt.

Aber genau das meine ich doch, wenn dann aber die SDD's keine Powerloss Protection haben oder die HD's intern einen Cache haben, dann bekommt doch ZFS selbst bei einem Sync Write das OK, selbst wenn noch nicht alle Daten auf der Platte sind, oder verstehe ich das falsch?

Sorry wenn ich da noch mal nachhaken muss, aber ich check da grad nicht mehr ganz durch.

 

[gea]

In einer perfekten Welt bräuchte man keine Power-Loss Protection. Wenn man sync write aktiviert und die Platte bestätigt, dass die Daten sicher gespeichert sind, dann sollte das auch so sein.

In der wirklichen Welt möchte man aber besonders hohe iops und Scheibwerte (oder geringen Verbrauch/ Schadstoffemmissionen) auf die Verpackung schreiben und das geht am Einfachsten mit Caches oder Tricksereien. Die Caches können aber dann dafür verantwortlich sein, dass Daten bei einem Stromausfall verloren gehen, obwohl dem OS/ZFS das erfolgreiche Schreiben bereits bestätigt wurde.

Daher haben teure SSDs eine (hoffentlich sauber funktionierende) Powerloss Protection mit Stützkondensatoren. Nur dann ist gewährleistet, dass im ZIL Logdevice alle Daten liegen, die dem OS als bereits geschrieben gemeldet sind (auch die Metadaten für das Dateisystem) damit beim nächsten Reboot das Dateissystem wieder auf einen konsistenten Stand gebracht werden kann. Der Pool selber hat bis dahin ja nur teilweise die Daten aktualisiert.

Sync write bedeutet ja normales, schnelles asyncrones Schreiben auf den Pool (über den ZFS Schreibcache) und zusätzliches Loggen der einzelnen Schreibaktionen auf ein schnelleres ZIL Logdevice.

 

[CommanderBond]

Warum "braucht" man dieses Powerloss Feature denn jetzt bei SSDs, bei HDDs hat das ja noch nie einen interesiert anscheinend.

Im "schlimmsten Fall" verliert man doch nur neue Daten oder? Alles was schon länger auf dem Pool liegt sollte aber doch weiterhin sicher sein egal ob Powerloss Feature oder nicht.

 

[gea]

Wenn man bei ZFS das Feature sync write nicht nutzt, braucht man das ja auch nicht denn dann sind die Daten im ZFS Schreibcache bei einem Crash immer verloren. Wenn man das aber nicht möchte (meist VM Storage oder transaktionsbasierte Datenbanken) und deshalb das Sicherheitsfeature sync write auf einer SSD als ZIL Logdevice aktiviert, dann macht es schon einen gravierenden Unterschied.

Wenn man sync write auf dem normalen Pool nutzt oder mit einer SSD ohne Powerloss, dann ist das zwar sicherer als kein sync write. Es kann aber da dennoch zu Datenverlust kommen. Im kommerziellen Umfeld (und da braucht man sicheres Schreiben) konnte man das aber noch nie tolerieren. Da käme auch niemand auf die Idee Hardwareraid ohne BBU und Cache zu nutzen das ähnlich wie sync write bei ZFS diesen Stromausfall absichert.

Zur Relevanz
Viele Aktionen sind transaktionsbasiert, z.B. wenn eine Datei unter NTFS editiert wird, so werden die geänderten Daten auf die Platten geschrieben (Die alte Datei wird dabei teilweise überschrieben) und dann werden die Metadaten aktualisiert. Wenn ersteres passiert, zweiteres aber nicht, kann im Extremfall sogar das Dateisystem beschädigt werden (Gut bei ZFS only nicht da dann wegen CopyOnWrite der vorherige Stand genutzt wird, bei ext4/ntfs over ZFS ist aber nur ZFS sicher, nicht aber ext4/ntfs)

Anderes Beispiel ist eine Finanzbuchung. Eine komplette Buchung besteht aus einer Belastung eines Kontos und einer Zuweisung auf ein anderes Konto. Entweder beide Buchungen werden durchgeführt oder keine oder das Geld ist im digitalen Nirwana verschwunden.

Um genau diese Transaktionen geht es. Eine große Photoshop Datei ist immer kaputt wenn das System beim Schreiben abstürzt. Das Dateisystem darf/sollte dabei aber nicht hopps gehen.

 

[CommanderBond]

Aber wenn ich die SSDs weglasse und sync write benutze bin ich auf der sicheren Seite?

 

[Rahvin]

Aber wenn ich die SSDs weglasse und sync write benutze bin ich auf der sicheren Seite?

Auf der ziemlich sicheren Seite bist du nur
- wenn alle Server bei Stromausfall an einer USV hängen
- die USV einwandfrei funktioniert
- die Server merken dass der Strom weg ist und sich (in der richtigen Reihenfolge!) ordentlich herunterfahren

Auch Magnetplatten haben einen (DRAM-) Puffer - wenn die Daten im Puffer noch nicht auf Magnetplatte gelandet sind hast du das gleiche Problem wie mit Daten im (DRAM-) Puffer der SSD

100% Sicherheit gibt es nicht - man kann nur versuchen möglichst viele Fehlerquellen in dern Griff zu bekommen, beherrschen kann man nie alle Fehlerquellen.

 

[gea]

Aber wenn ich die SSDs weglasse und sync write benutze bin ich auf der sicheren Seite?

Entscheidend ist immer ob die Daten tatsächlich auf dem Storage sind wenn die Platte das an ZFS so meldet. Das kann auch bei Platten mit writeback cache schiefgehen. Da aber ein normaler Pool mit sync write unterirdisch lahm ist, ist die Frage eher akademisch relevant. Man braucht für gute Performance mit sync write immer ein zusätzliches High-Performance log-device.

Aber zur Klarstellung.
Ein normaler Fileserver mit SMB nutzt das nicht, braucht das nicht.
Sync write ist was für besondere Anforderungen.

@Rahvin als Ergänzung
Eine UPS ist sehr hilfreich, nützt aber nicht immer - bei einem Crash nichts.
Für jedes Problem gibt es halt eine eigene Lösung.

Da UPS aber gerne auch ausfallen, nutze ich die eigentlich nur noch zusammen mit redundanten Netzteilen, eins an der UPS, eins am Netz.

 

[Opticum]

hat jemand Erfahrung mit Backup auf USB Festplatten? Versuche mir grad was einfaches, funktionelles zusammen zu stricken um meinen ZFS Pool (regelmäßig) zu sichern.

EDIT: Bittorrent Sync + Autosnapshop scheint eine super Sache zu sein. Ich werde mir das mal anschauen und berichten falls es läuft.

 

[trendco]

zfs get all |grep sync
raid1-ssd sync standard default
raid1-ssd/pve sync standard local

Standard bedeutet jetzt noch mal was genau?

 

[gea]

Standard bedeutet jetzt noch mal was genau?

Der schreibende Prozess wünscht sich was und der Wunsch wird erfüllt.

 

[gea]

Info:

Es gibt ein Update für OmniOS 151014 long term stable.
- NVMe Treiber
- NFS bugfixes

ReleaseNotes/r151014

 

[trendco]

Entscheidend ist immer ob die Daten tatsächlich auf dem Storage sind wenn die Platte das an ZFS so meldet. Das kann auch bei Platten mit writeback cache schiefgehen. Da aber ein normaler Pool mit sync write unterirdisch lahm ist, ist die Frage eher akademisch relevant. Man braucht für gute Performance mit sync write immer ein zusätzliches High-Performance log-device.

Aber wäre dann nicht auch das CoW an sich gefährdet, wenn die Platten Schreibcache benutzen? Oder managed das ZFS mit den Platten?

Sorry fals das jetzt ne unterirdisch Dumme Frage ist

 

[gea]

Aber wäre dann nicht auch das CoW an sich gefährdet, wenn die Platten Schreibcache benutzen? Oder managed das ZFS mit den Platten?

Sorry fals das jetzt ne unterirdisch Dumme Frage ist

Das schlimmste was mit CopyOnWrite passiert ist eine unvollständige Transaktion. Damit bleibt halt der vorherige Stand gültig und das Dateisystem valide - die aktuell geschriebebe Datei ist natürlich unvollständig und defekt.

Ohne CopyonWrite kann das Dateisystem Schaden nehmen.

 

[Morpheus2200]

Info:

Es gibt ein Update für OmniOS 151014 long term stable.
- NVMe Treiber
- NFS bugfixes

ReleaseNotes/r151014

Ist nur ein paar Tage her, da habe ich gesehen das ein Nexenta Mitarbeiter den NVME Treiber veröffentlicht hat und schon ein long term stable update für OmniOS, das geht aber fix.
Ich habe sogar gerade ein System zum Testen hier stehen, nur leider kein NVME speicher.
NVME für ZIL oder L2ARC würde ich gern mal testen, hat schon Potential die Performance erheblich zu verbessern.

Ich habe letzte Woche mal einen alten Server mit OmniOS und napp-it aufgesetzt. Installation und Konfiguration sind ja ein Kinderspiel. Danke dafür gea.

Jetzt habe ich 3 Fragen:
1. Per default sind nur 16 NFS Threads eingerichtet. Verhält sich der NFS Server uner OmniOS anders als unter Linux? Da bin ich es gewöhnt deutlich mehr NFS Serer Threads zu eröffnen.
2. Gibt es für die Anbindung an Verzeichnisdienste wie AD oder LDAP auch den Komfortablen Weg über das Webfrontend?
3. Die Maximale Menge an RAM die als ARC genutzt wird, wie wird die festgelegt? Meine anderen Filer haben da eine Obergrenze, um sicherzustellen das für andere Systemfunktionen genug Speicher verfügbar bleibt.

 

[trendco]

Das schlimmste was mit CopyOnWrite passiert ist eine unvollständige Transaktion. Damit bleibt halt der vorherige Stand gültig und das Dateisystem valide - die aktuell geschriebebe Datei ist natürlich unvollständig und defekt.

Ohne CopyonWrite kann das Dateisystem Schaden nehmen.

Ich hatte das eigentlich so gemeint:
Neue Daten wurden geschrieben -> der Verweis in den Metadaten auf die neue Datei wir angefangen zu schreiben, die Daten dazu liegen jetzt im Festplatten-Schreib-Cache -> Strom weg, keine Powerloss Protection -> Platte kann nur einen Teil dieser Meta-Daten schreiben -> Meta-Daten beschädigt?

Ich weiß, das ist jetzt "Haarspalterei", mir gehts aber nur ums Prinzip

 

[gea]

1.
Unter Solaris kann man den NFS server per sharectrl oder bei direkt als share parameter konfigurieren.

z.B.
illumos: manual page: sharectl.1m
NFS Commands - Managing Network File Systems in Oracle Solaris 11.1
https://ervikrant06.wordpress.com/2014/06/23/how-to-configure-nfs-server-and-client-in-solaris-11/

2.
Solaris/ OmniOS unterstützt AD (inkl. Speicherung der Windows SID und Windows kompatible ACL)
Dazu einfach OmniOS oder Solaris in die Domände aufnehmen (Services > SMB >> Acive Directory).
Optional dann noch ein idmapping winuseromain=unixuser:root setzen damit der Vollzugriff hat.

3.
z.B.
ZFS ARC Parameters - Oracle Solaris 11.1 Tunable Parameters Reference Manual
https://rageek.wordpress.com/2012/07/09/strickly-limiting-zfs-arc-cache-size/

Ist aber normalerweise nicht notwendig.
Solaris sorgt selbst dafür dass andere Systemfunktionen genug RAM haben.

- - - Updated - - -

Ich hatte das eigentlich so gemeint:
Neue Daten wurden geschrieben -> der Verweis in den Metadaten auf die neue Datei wir angefangen zu schreiben, die Daten dazu liegen jetzt im Festplatten-Schreib-Cache -> Strom weg, keine Powerloss Protection -> Platte kann nur einen Teil dieser Meta-Daten schreiben -> Meta-Daten beschädigt?

Ich weiß, das ist jetzt "Haarspalterei", mir gehts aber nur ums Prinzip

Dank CopyOnWrite ist der vorherige Stand der Matadaten ja noch vorhanden da kein Inline Update oder Änderung dieser Daten stattfindet sondern grundsätzlich alle zu ändernen (Meta)Daten neu angelegt werden. Erst wenn alle dazu nötigen Transaktionen erfolgt sind, werden als letzte Aktion die neuen Daten benutzt. (Alles oder nichts Prinzip)

Eine Beschädigung der Metadaten kann dadurch per Design nicht entstehen - auch nicht wenn kein Powerloss vorhanden ist.
Powerloss sorgt nur dafür, dass Schreib-Transaktionen, die an das schreibende Programm als erfolgt gemeldet sind, auch tatsächlich auf Platte sind um diesem Prozess ebenfalls Transaktionssicherheit zu geben (einer Datenbank oder dem OS das seine Dateisysteme wie ext4 oder ntfs) konsistent halten möchte (was da natürlich wegen eines nur teilweisen Updates der Metadaten dann fehlschlagen kann).

 

[TCM]

Eine Beschädigung der Metadaten kann dadurch per Design nicht entstehen - auch nicht wenn kein Powerloss vorhanden ist.
Powerloss sorgt nur dafür, dass Schreib-Transaktionen, die an das schreibende Programm als erfolgt gemeldet sind, auch tatsächlich auf Platte sind um diesem Prozess ebenfalls Transaktionssicherheit zu geben (einer Datenbank oder dem OS das seine Dateisysteme wie ext4 oder ntfs) konsistent halten möchte (was da natürlich wegen eines nur teilweisen Updates der Metadaten dann fehlschlagen kann).

Hä? Powerloss = Stromausfall.

 

[gea]

Hä? Powerloss = Stromausfall.

Diese Diskussion dreht sich um die Funktion "Powerloss Protection" besserer SSDs.

 

[TCM]

Diese Diskussion dreht sich um die Funktion "Powerloss Protection" besserer SSDs.

Ja, dann sollte man das auch so nennen und nicht einfach Wörter weglassen.

 

[CommanderBond]

Gea, was aber wenn die Änderungen noch im Cache der Hdd sind. In dem Fall wird dem System dennoch eine erfolgreiche Transaktion gemeldet. Obwohl die Daten eben noch nicht alle auf der Platte sind.
Sprich zfs denkt es ist schon im neuen Zustand weil die Daten im Cache schon geupdatet wurden. Auf den Magnetscheiben selbst ist aber noch der alte Zustand.

 

[gea]

Gea, was aber wenn die Änderungen noch im Cache der Hdd sind. In dem Fall wird dem System dennoch eine erfolgreiche Transaktion gemeldet. Obwohl die Daten eben noch nicht alle auf der Platte sind.
Sprich zfs denkt es ist schon im neuen Zustand weil die Daten im Cache schon geupdatet wurden. Auf den Magnetscheiben selbst ist aber noch der alte Zustand.

Das ist die gleiche Situation wie bei einer SSD ohne Powerloss Protection. Wenn da der Strom ausfällt ist die aktuelle Schreibaktion unvollständig und damit bleibt der letzte Stand gültig. Die letzte Schreib-Transaktion ging im Cache verloren obwohl sie dem OS als geschrieben gemeldet ist. Das ist ja auch üblicherweise kein Problem. Ein normaler SMB Filer kümmert sich darum eh nicht.

Kompliziert (mit sync write, SSD und powerloss protection) wird es ja nur dann wenn ein bestätigter Schreibvorgang auch garantiert auf dem Storage sein muss.

 

[supemole]

Gea, welche Konfiguration empfiehlst Du aktuell für ein Napp-In-One Produktivsystem?

a) ESXi 5.5 U2 + vmware tools ESXi 5.5 + OmniOS 151012

b) ESXi 5.5 U2 + vmware tools ESXi 5.5 + OmniOS 151014 LTS September (incl. L2Arc bug fixed)

c) ESXi 6 + vmware tools ESXi 6.00b + OmniOS 151014 LTS September (incl. L2Arc bug fixed)

 

[gea]

a.) ist sehr konservativ und sollte keine Probleme bereiten.
b.) und c.) sollte man unter Last testen ob die NFS Freigabe stabil ist (Sowohl Vmware wie auch Illumos haben an NFS Änderungen vorgenommen). Es gibt aber bei jeder Variante einzelne Problemberichte.

Da Probleme oft von der jeweiligen Hardware abhängen, würde ich immer eine gewisse Testphase bei neuer Software vorsehen. Insgesamt würde ich erst einen Test mit den aktuellen Versionen machen. Mögliche Probleme liegen in Verbindungsabbrüchen von ESXi zu NFS unter Last.