[Sammelthread] ZFS Stammtisch

[gea]

Powerloss Protection ist nicht vorhanden. D.h. somit für ZFS eh ungeeignet?

So kann man das nicht sehen.

Das Problem ist, dass ZFS beim Schreiben einen bis zu mehrere GB großer RAM Cache nutzt. Stürzt der Rechner ab, ist der Cache verloren. Das ZFS Dateisystem geht dabei wegen CopyOnWrite nicht kaputt. Wenn der Speicher allerdings für VMs und darin enthaltene virtuelle Platten genutzt wird, so kann ZFS sich nicht um deren Konsistenz kümmern (weiß nichts davon). Ein Crash und diese Dateisysteme können defekt sein.

Bei ZFS kann man nun syncrones Schreiben aktivieren um einen ganz besonderen Schutz der Daten zu erreichen. Dabei wird der Inhalt des ZFS Schreibcaches gesichert und nach einem Crash beim nächsten Start auf den Pool geschrieben. Das setzt aber vorraus, dass nicht nur das Device das diese Cache-Protokollierung (onpool ZIL oder extra Slog) vornimmt, sicheres Schreiben beherrscht sondern auch der Pool selber (ein Commit einer Platte muss immer bedeuten dass die Daten tatsächlich auf Platte sind und nicht noch im Platten Cache). Eine SSD/NVMe ohne Powerloss Protection kann das nicht garantieren. ZFS könnte hier einfach mehr Sicherheit bieten wenn die Hardware besser wäre.

Es gibt NVMe ohne Powerloss Protection (z.B. die nicht-Datacenter Intel Optane wie eine 900P) die ziemlich sicher ein sehr gutmütiges Verhalten im Crash Fall haben, da sie keinen eigenen Dram Cache haben. Andere SSD/NVMe nutzen ausgiebig einen Dram Cache zur Performancesteigerung. Sowas ist dann eher Server-untauglich.

 

[WMDK]

Super, danke für die ausführliche Antwort D.h. im Grunde ist es in der Hardware Config zu unsicher und ein reguläres Softraid wäre empfehlenswerter, da hier der RAM nicht als riesen Puffer dient und somit die Daten bei einem Powerloss nicht futsch sind, verstehe ich das soweit korrekt?

Einfach eine SATA Datacenter SSD mit SLOG für ZFS würde als "Sicherheit" bei der Hardwarekonstellation also auch nicht reichen, da nicht sichergestellt ist, dass sich nicht noch Daten im Cache der SSD befinden, richtig?

Bisher hatte ich halt einfach ein SATA Hardware-Raid im Einsatz, ohne BBU mit Write Through im Einsatz und hatte mir von ZFS ein insgesamt moderneres und sichereres Dateisystem erhofft.

 

[gea]

Ein großer Schreibpuffer ist schneller und die Absicherung wird aufwändiger. Aber auch wenn der nur ein paar Hundert MB groß ist wie bei den meisten Hardwareraids oder Platten bleibt das Problem das gleiche. Sobald man mit virtuellen Platten und darauf enthaltenen Dateisystemen arbeitet MUSS ein Commit mit dem einer VM ein Schreibvorgang bestätigt wird bedeuten, dass die Daten auf Platte sind - andernfalls kann das Dateisystem korrupt sein.

Wenn man das Problem nicht ignorieren mochte oder kann, dann bedeutet das normale Platten mit writeback cache deaktiviert oder SSD/NVMe und Powerloss Protection. Bei Hardwareraid ist dazu Cache+BBU Pflicht, bei ZFS das Aktivieren von sync das gleiches leistet wie Cache+BBU bei Hardwarraid (Absicherung des Schreibcaches).

Ohne ZFS und mit anderen Softwareraids kann man das Problem nur ignorieren und hoffen dass alles gutgeht. Ein Absicherung der diversen Schreibcaches ist da nicht möglich.

 

[WMDK]

Verstehe, super. Vielen Dank Das hilft mir doch schonmal weiter.

 

[you]

Hi gea,

leider bekomme ich verschlüsseltes SMTP nicht zum Laufen. Wenn ich teste kommt folgende Fehlermeldung:

Can't locate Net/SSLeay.pm in [USER=30946]@inc[/USER] (you may need to install the Net::SSLeay module) ([USER=30946]@inc[/USER] contains: /var/web-gui/data/napp-it/CGI /usr/perl5/site_perl/5.30/i86pc-solaris-thread-multi-64 /usr/perl5/site_perl/5.30 /usr/perl5/vendor_perl/5.30/i86pc-solaris-thread-multi-64 /usr/perl5/vendor_perl/5.30 /usr/perl5/5.30/lib/i86pc-solaris-thread-multi-64 /usr/perl5/5.30/lib /var/web-gui/data/napp-it/zfsos/_lib/illumos /var/web-gui/_my/zfsos/_lib /var/web-gui/data/napp-it/zfsos/15_Jobs and data services /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email) at /var/web-gui/data/napp-it/CGI/Net/SMTP/TLS.pm line 89. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/Net/SMTP/TLS.pm line 89. Compilation failed in require at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 77. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/zfsos/15_Jobs and data services/04_TLS Email/09_TLS-test/action.pl line 77. Compilation failed in require at admin.pl line 514.

Die Installation habe ich gem. http://napp-it.org/downloads/tls.html gemacht. Wenn ich auf Jobs/TLS eMail/enable TLS Mail klicke steht dennoch "TLS (not supported, needed for Googlemail)" unter den Menuitems.

Hast Du eine Idee? Port 25 ist bei meinem Provider zu. uname sagt "SunOS vmnas 5.11 omnios-r151032-702376803e i86pc i386 i86pc"

VG

 

[gea]

Prinzipiell ist der Weg

-TLS als root installieren, https://napp-it.org/downloads/tls.html
(alle Rückfragen mit Enter bestätigen)
-TLS testen (Jobs > TLS Email)
-bei Erfolg: Alert auf TLS umstellen (Jobs > TLS Email)

Wenn man einen Gmail Account hat, kann man dafür auch Port 25 unverschlüsselt nutzen (siehe Link auf https://napp-it.org/downloads/tls.html)

Prinzipiell hatte ich nur Probleme bei einem OmniOS das von früher 151028 upgedated wurde weil da von Sun SSH auf OpenSSH umgestellt wurde.

 

[martingo]

Mach doch bitte nochmal die Schritte und poste die Ausgabe. Da fehlt schon das erste Perl Modul, sagt er ja auch (Nett::SSLeay)

 

[you]

OK. Da habe ich nicht richtig hingeschaut. Beim installieren von SSLeavy bekomme ich "sh: line 1: gcc: not found" angezeigt.

In der PDF Doku (nicht auf der Web-Seite) steht auch, dass man erst gcc6 installieren soll. Habe jetzt gcc7 nachinstalliert (gcc6 gibbet nicht) und die Testmail geht raus.

Danke Euch beiden !

 

[gea]

Der aktuelle napp-it wget Installer installiert den gcc7 Kompiler bei neueren OmniOS Versionen. Ein manuelles Nachinstallieren sollte eigentlich nicht nötig sein.

 

[dstockm]

Bzgl. Android FileExplorer: Danke für die Hinweise. Die beiden die funktionierenden sagen mir leider nicht so zu. Außerdem funktioniert meine Backup-Lösung mit FolderSync auch nicht.
Ich habe den Server downgegraded zu 151030al und es geht wieder.

 

[you]

Der aktuelle napp-it wget Installer installiert den gcc7 Kompiler bei neueren OmniOS Versionen. Ein manuelles Nachinstallieren sollte eigentlich nicht nötig sein.

Mh. Ich hatte zuletzt "19.Dev 11.dec.2019" installiert. Grad noch mal ein Update und bin auf "19.Dev 11.dec.2019". Ich habe das System seit 3-5 Jahren aber nie neu aufgesetzt, immer nur Upgrades gemacht.

Anyway. Et funnzt jetzt ... und nur das zählt

 

[gea]

Bzgl. Android FileExplorer: Danke für die Hinweise. Die beiden die funktionierenden sagen mir leider nicht so zu. Außerdem funktioniert meine Backup-Lösung mit FolderSync auch nicht.
Ich habe den Server downgegraded zu 151030al und es geht wieder.

OmniOS 151030 unterstützt SMB1 und SMB2.1. OmniOS 151032 kann zusätzlich SMB3. Eventuell genügt es, serverseitig das SMB Protokoll aud v1 oder v2.1 zu begrenzen (Napp-it Services > SMB > Properties). Man hätte dann dennoch die neuen Features wie ZFS Verschlüssellung, special vdevs, ashift force, trim etc.

Beitrag automatisch zusammengeführt: 26.01.2020

Ich habe das System seit 3-5 Jahren aber nie neu aufgesetzt, immer nur Upgrades gemacht.

Da gcc6 nicht mehr unterstützt wird, endet man bei einem OS Update gerne bei einem System ohne Kompiler. Der würde durch einen neueren wget Installer Lauf von napp-it installiert wie auch ein neueres Smartmontools. Alternativ halt Kompiler manuell nachinstallieren.

 

[you]

Wenn ich das Update im Menü mache, passiert das nicht dann? Oder muss ich das neu herunterladen und starten? Und was passiert dann mit den Einstellungen?

 

[gea]

Ein Update in napp-it per About > Update bezieht sich nur auf napp-it. Das Betriebssystem kann man/muss man separat updaten. Üblicherweise sollte man napp-it zuerst updaten damit gewährleistet ist, dass die neue OS Version unterstützt wird.

Wenn man den wget Installer erneut aufruft, wird napp-it (free) erneut installiert, zusammen mit neueren Versionen z.B. der Smartmontools, die Einstellungen in napp-it bleiben erhalten.

Ein Update des Betreibssysystems bei OmniOS bedeutet: Wechsel des Repository auf die neue Version, dann pkg update. Alle Einstellungen bleiben erhalten.

 

[dstockm]

OmniOS 151030 unterstützt SMB1 und SMB2.1. OmniOS 151032 kann zusätzlich SMB3. Eventuell genügt es, serverseitig das SMB Protokoll aud v1 oder v2.1 zu begrenzen (Napp-it Services > SMB > Properties). Man hätte dann dennoch die neuen Features wie ZFS Verschlüssellung, special vdevs, ashift force, trim etc.

Wenn max_protocol=1 bzw. 2.1 die richtige Option ist, dann hilft es leider nicht.
Ich muss dazu sagen, dass ich keine frische Neuinstallation gemacht habe. Ich komme von irgendwo zwischen 151022 - 151026....

P.S.: Wie setzt man eine property eigentlich wieder auf "leer"?

 

[you]

Sorry gea, da war ich nicht präzise genug. Ich bezog mich ausschliesslich auf das Update von napp-it. Das OS pflege ich per Console. Und, wenn ich Dich richtig verstanden habe, dann würde ein Re-Install von napp-it ebenfalls auf Console erfolgen und NICHT im Menü für das napp-it Update?

 

[asche77]

würde ein Re-Install von napp-it ebenfalls auf Console erfolgen und NICHT im Menü für das napp-it Update?

Korrekt.

 

[gea]

P.S.: Wie setzt man eine property eigentlich wieder auf "leer"?

Indem man bei den SMB (oder ZFS) Eigenschaften nur auf modify klickt ohne etwas einzugeben.

Beitrag automatisch zusammengeführt: 27.01.2020

Sorry gea, da war ich nicht präzise genug. Ich bezog mich ausschliesslich auf das Update von napp-it. Das OS pflege ich per Console. Und, wenn ich Dich richtig verstanden habe, dann würde ein Re-Install von napp-it ebenfalls auf Console erfolgen und NICHT im Menü für das napp-it Update?

Wenn napp-it läuft, macht man napp-it Updates/Downgrades im Menü About > Update. Den wget Installer braucht man für die Erstinstallation oder wenn z.B. ein Update fehlschlägt und man wieder ein lauffähiges System haben möchte.

 

[martingo]

Bei den SMB Properties funktioniert es bei mir über die GUI auch nicht, etwas auf Default zurückzusetzen. Wenn ich leer auf modify clicke kommt unten invalid value und der alte Wert bleibt.

Ich hatte mich mit SMB unter Android bisher gar nicht weiter auseinandergesetzt, nun aber mal mit min und max rumgespielt.
Es scheint so, dass die Explorer mit Endlosschleife nur SMB1 können und die funktionierenden nur SMB2.1. Jeweils exklusiv.
Mit SMB3.0 funktioniert keiner obwohl das schon seit 2017 in Android integriert sein sollte.

 

[gea]

Bei den SMB Properties funktioniert es bei mir über die GUI auch nicht, etwas auf Default zurückzusetzen. Wenn ich leer auf modify clicke kommt unten invalid value und der alte Wert bleibt.

In der Tat. Das ist neu bei OmniOS 151032. Vorher konnte man eine Einstellung noch löschen, jetzt will er einen gültigen Wert (auch none oder - geht nicht wie bei manchen ZFS properties). Bleibt also nur ein gültiger Wert wie 3.02 bei max_protocol der alles abdeckt.

 

[frittes]

Kann mir jemand sagen, ob ein SSD Mirror Cache etwas mehr Performance beim Schreiben bringen könnte? Ich habe die WD Red Platten und die scheinen teilweise nicht schnell genug zu schreiben.

Ich hätte noch einen Controller und zwei 128GB SSDs. Wie kann man den Cache, falls empfohlen, einbinden?

 

[gea]

Schreibcache bei ZFS ist (auschließlich) RAM.

Eine SSD kann man als L2Arc (Erweiterung des rambasierten Lesecaaches) und Slog (kein Schreibcache sondern Crash-Absicherung des RAM-Schreibcaches bei sync=enabled) einsetzen.

Die einzige Option, wo ein SSD Mirror beim Schreiben (außer Slog bei sync write) etwas bringt, ist ein special vdev. Dabei kann man bei einem aktuellen OmniOS einen mirror als special vdev dem Pool hinzufügen (auf gleiche ashift wie der Pool achten). Anschließend landen Metadaten oder kleine io auf diesem vdev. Man kann auch einzelne Dateisysteme oder die Dedup Tabelle auf die special vdev zwingen, siehe https://www.napp-it.org/doc/downloads/special-vdev.pdf

Wenn man nicht allzuviel RAM hat, dann kann mehr RAM (größerer Schreibcache) etwas bringen. Defaultgröße bei Open-ZFS ist 10% RAM, max 4GB.

 

[asche77]

In der OmniOS Gitter Lobby ist gerade die Rede davon, dass man evtl SamFS / SAM-QFS auf OmniOS portieren möchte. Also ein Hierarchical File System. Das wäre sicher die noch spannendere Variante, da es dort (zB) eingebaute schnelle "Parkplätze" für writes gibt, die dann später auf ein langsameres storage geschrieben werden (eine Art "disk cache"; UnRaid macht glaub ich was ähnliches?). https://en.wikipedia.org/wiki/QFS

Beitrag automatisch zusammengeführt: 29.01.2020

Ich habe die WD Red Platten und die scheinen teilweise nicht schnell genug zu schreiben.

Evtl. doch eher ein Problem der IOPS statt der sequenziellen Schreibleistung? Ansonsten (wie gea): Mehr RAM. Und mehr Geduld.

 

[frittes]

Evtl. doch eher ein Problem der IOPS statt der sequenziellen Schreibleistung? Ansonsten (wie gea): Mehr RAM. Und mehr Geduld.

RAM könnte ich noch auf 16GB verdoppeln, soviel Luft ist da.

Kann jemand die Stats interpretieren? In dem Fall habe ich, obwohl auf den Pools im Grunde nicht viel los ist, einen Einbruch in der Performance.

Plattform ist ein Dell T30 mit 64GB RAM, Fujitsu Controller mit 2x3TB POOL_1 (Mirror) für die VM-Images und 6x6TB POOL_2 (Raid-z2) für Daten. Alles WD Red-Platten (5400er). Sync ist auf beiden Pools deaktiviert. ESXI 6.7 U3 mit napp-it 18.12w4 (2CPU, 8GB RAM). Leider verliert die ESXI immer mal wieder den NFS-Store, ohne Fehlermeldungen wie latency too high (wie bei dem Dell Perc Controller). Ist weg und reconnected dann einfach wieder, Maschinen stehen dann natürlich in dem Moment.

EDIT: Folgende Meldung stehen dann im Protokoll der ESXI:

2020-01-24T13:07:47.851Z cpu2:2097971)WARNING: NFS: 337: Lost connection to the server 172.22.70.115 mount point /POOL_1/VM_IMAGES, mounted as 0de14a19-56af7258-0000-000000000000 ("ZFS_VM_IMAGES")
2020-01-24T15:54:24.930Z cpu1:2097971)WARNING: NFS: 337: Lost connection to the server 172.22.70.115 mount point /POOL_1/VM_IMAGES, mounted as 0de14a19-56af7258-0000-000000000000 ("ZFS_VM_IMAGES")

 

[Trambahner]

Persönliche Meinung: OS-Images für VMs haben IMO nichts auf langsamen HDD-Pools zu suchen, sondern gehören auf SSDs. Erst recht nicht bei so langsamen HDDs mit niedrigen IOPS und übersichtlicher Dram-Menge.
Sowas gehört auf SSDonly-Pools.

 

[asche77]

ESXI 6.7 U3 mit napp-it 18.12w4 (2CPU, 8GB RAM).

1. OmniOS aktualisiert?
2. Mehr RAM für den ZFS cache! Gerne auch mehr als 16GB.
3. VM Images auf den WD RED: In der Tat ein Problem, da der mirror ca. 120 iops hat - die sich auf lesen und schreiben verteilen müssen. Vor allem mit dem wenigen RAM sehr lahm.
4. Auch SSD können einbrechen, wenn es consumer SSDs sind - daher auf jeden Fall mit 20-30% overprovisioning arbeiten.
5. Daten-RAIDZ2: Wirst Du nicht viel schneller bekommen. Hier hilft nur viel RAM als Lese- und Schreib-Cache. Und ggfs. das spin-down ausschalten, damit Du bei seltenen Zugriffen keine 5s für das Hochfahren der Platten brauchst.

 

[gea]

RAM könnte ich noch auf 16GB verdoppeln, soviel Luft ist da.

Kann jemand die Stats interpretieren? In dem Fall habe ich, obwohl auf den Pools im Grunde nicht viel los ist, einen Einbruch in der Performance.

Plattform ist ein Dell T30 mit 64GB RAM, Fujitsu Controller mit 2x3TB POOL_1 (Mirror) für die VM-Images und 6x6TB POOL_2 (Raid-z2) für Daten. Alles WD Red-Platten (5400er). Sync ist auf beiden Pools deaktiviert. ESXI 6.7 U3 mit napp-it 18.12w4 (2CPU, 8GB RAM). Leider verliert die ESXI immer mal wieder den NFS-Store, ohne Fehlermeldungen wie latency too high (wie bei dem Dell Perc Controller). Ist weg und reconnected dann einfach wieder, Maschinen stehen dann natürlich in dem Moment.

EDIT: Folgende Meldung stehen dann im Protokoll der ESXI:

Bei NFS sieht es so aus dass ESXi beim Zugriff eine Reaktion innerhalt einer bestimmten Zeit erwartet. Bei längerem Warten wird NFS getrennt (und wenn NFS wieder verfügbar ist neu gemounted). VMs auf dem Datastore sind danach immer neu zu starten.

Seltener ist das Storage einfach zu langsam, insbesondere bei deaktiviertem sync (Vorsicht: ein Crash oder NFS off kann ein VM Dateisystem dabei ruinieren). Man muss jetzt nachvollziehen was die Ursache ist. Der erste Ort sind die Logfiles (System > Logs) und der Fault Manager (System > Faults). Oft ist die Ursache eine Platte mit "bad sector" bei dem das Lesen nach einiger Zeit klappt, das ist aber zu spät für NFS. Ich würde da auch den default ZFS Timout der Platten (System > Tuning) von 60s (viel zu hoch) niedriger setzen. Manche tler Platten für Hardwareraid haben 7s timout. Bei größeren Pools können 7s zu wenig sein. 10-15s sind gut. (Aktuelles OmniOS setzt das neuerdings selber so)

ps
Falls sync=default so wird bei ESXi und NFS sync aktiviert. Gut für die Sicherheit. Ein Pool aus WD Red kann aber dann schlicht zu langsam sein. Zum Testen sync auf disabled stellen. Dann ist sync garantiert aus. Ansonst sinkt die Schreibperformance gerne mal auf 10-30MB/s oder bricht bei vielen parallelen Zugriffen ganz ein.

Ein Log müsste man in dem Augenblick des Disconnect betrachten, besonders wait% und busy%. Bei einer hängenden Platte geht das schnell auf hohe Werte.

 

[frittes]

Danke für eure Anmerkungen und Hinweise!

Habe mir nun zwei Crucial MX500 2TB SSDs für nen ordentlichen VM-Mirror bestellt. Werde morgen Abend dann die VMs migrieren.

Backup auf ext. HDD läuft gerade, Restore-VM auf der M2 ist neben napp-it installiert, somit kann ich morgen auf die SSDs restoren.

Wie ist die beste Vorgehensweise? Zuerst ZFS-Filesystem destroyen, dann Pool destroyen und dann HDDs removen vor dem Shutdown in napp-it? Dann SSDs anstatt der HDDs dran, booten und neuen Pool erstellen?

@gea: Sync hatte ich direkt bei den ersten Performance-Problemen Anfang des Monats auf disabled gesetzt. Timeout ist schon auf 15sec.

@asche77: Sollte ich OmniOS aktualisieren? Macht auch ein napp-it-Update auf 19.10.homeuse Sinn? Bzgl. RAM-Cache, habe optimiert und kann nun 24GB für die Appliance reservieren für den Datenpool.

@Trambahner: Hast sicher Recht, aber es ist ein Homeserver. Mit dem Adaptec Hardware Raid und den Platten lief das mit 12 VMs angenehm performant. Bin morgen auf die Leistung der SSDs im ZFS gespannt.

 

[asche77]

@frittes:
1. Ja, ich würde OmniOS auf das neueste r32 aktualisieren. Wenn Du mit Android Apps zugreifen willst, evtl nur auf das neueste r30 (siehe ein paar Einträge weiter oben). Napp-IT kannst Du dann auch aktualisieren.
2. Hardware RAID und ZFS ist ein NO GO!
3. Auch SSD können einbrechen, wenn es consumer SSDs sind - die MX500 sind consumer SSDs ohne powerloss protection - es kann sein, dass die Leistung einbricht. Bitte 10-20% overprovisioning einstellen. Besser wären enterprise SSDs (halt mit weniger Kapazität), also Intel DC / D3, Samsung SM/PM 863/883, Micron 5100/5200/5300 oder ähnliches. Preise muss man gut vergleichen, sind oft überteuert.

 

[frittes]

Noch ne Frage:

Ist es möglich, dass ich erstmal eine HDD rausnehme und durch eine SSD ersetze? Die HDD hat 3TB, die SSD aber nur 2TB! Belegt sind nur 700GB.

Geht das unter Umständen auch mit einem Pool export/import? Problem ist, dass der Controller voll belegt ist und ich die Platten hart tauschen muss.

Jeder Hinweis ist willkommen.