ZFS Write Amplification
Beobachtung
Die ursprüngliche LINSTOR-Implementierung im Cluster home-tamay-cloud verwendete ZFS Thin Pools. ZFS arbeitet mit Copy-on-Write und erzeugt neben den Nutzdaten zusätzliche Metadatenoperationen. Die daraus entstehenden Schreibzugriffe werden bei replizierten Volumes anschließend durch DRBD auf weitere Nodes übertragen.
Auf den Patriot P220 ohne DRAM-Cache führte die Kombination aus ZFS, DRBD und schreibintensiven Anwendungen zu hohen und teilweise stark schwankenden IO-Latenzen. Kleine synchrone Schreibzugriffe waren besonders problematisch, da die physisch geschriebenen Daten die von der Anwendung angeforderte Datenmenge deutlich überschreiten konnten.
Erkenntnis
Die Write Amplification entsteht nicht durch eine einzelne Komponente, sondern durch das Zusammenspiel mehrerer Ebenen:
Anwendung
|
v
Dateisystem
|
v
ZFS Copy-on-Write
|
v
DRBD-Replikation
|
v
Consumer-SSDZFS-Einstellungen wie compression=lz4, atime=off und xattr=sa reduzieren einzelne Schreib- und Metadatenzugriffe. Sie beseitigen jedoch nicht die grundsätzliche Write Amplification durch Copy-on-Write, synchrone Schreibvorgänge, ZFS-Metadaten und DRBD-Replikation.
Die Höhe der Write Amplification hängt vom konkreten Workload, der Synchronizität der Schreibzugriffe, der Blockgröße und weiteren Eigenschaften des Storage-Stacks ab. Einzelne Benchmark-Ergebnisse lassen sich deshalb nicht unverändert auf den Cluster übertragen.
Konsequenz
Für produktive LINSTOR-Volumes auf den vorhandenen Consumer-SSDs wird LVM gegenüber ZFS bevorzugt. Die Nutzdaten werden in LVM Thin Pools gespeichert, wenn CSI-Snapshots, Thin Provisioning und flexible Speicherzuweisung benötigt werden.
Thick LVM kann bei IO-sensitiven Workloads eine bessere Performance erreichen, da die Blöcke bereits bei der Bereitstellung reserviert werden. Für die regulären Nutzdatenpools wird dennoch LVM Thin verwendet, weil Snapshots und Thin Provisioning benötigt werden. Die damit verbundenen zusätzlichen Metadatenoperationen werden bewusst akzeptiert.