[Sammelthread] ZFS Stammtisch

Ich hab mal einen einfachen sync-write Test ins aktuelle napp-it integriert.
Der öffnet eine Datei, schreibt ein Zeichen und schließt die Datei dann wieder und misst wie oft das z.B. in 60s möglich ist- ein erster Anhaltspunkt für sync write.

Menü Pools > Benchmark > syncwrite

Bei einem Plattenpool bitte nicht erschrecken.
Bei einem SSD Pool kommen bei sync always vs sync disabled deutlich bessere Werte aber immer noch viel schlechter als mit sync=disabled
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Okay aber bei einem Resilvering mit einer frischen Platte wird er mir den alten Eintrag auch auf die neue kopieren warscheinlich?

Mal getestet nach export des mirror Pools, alte HDD entfernen und Pool wieder importieren taucht der alte Pool zum importieren nicht mehr auf. Also scheint der Eintrag beim Resilvern dann nicht mit kopiert zu werden auf die neue Platte.

edit: Importiert man den gesamten Mirror (beide Platten) ist der alte Pool offensichtlich auch entfernt worden aus der Liste, taucht nichtmal unter destroyed Pools noch auf.
 
Zuletzt bearbeitet:
Gude Abend,

ich wollt mal wieder Napit auf meiner Solaris VM installieren, allerdings ghet es wohl nicht wirklich voran.

sol.JPG

Bei miener letzten installation, war das deutlich mehr und dauerte auch ne gewisse Zeit, wo ist da der Fehler ?
 
Den Installer muss man als root aus dem Ordner /root starten

su
cd /root
wget ..
 
Ah, jetzt ja.Jetzt wo du es sagst, beim letzen mal war ich direkt als root angemeldet..xD Da hilft dann auch kein Sudo...
Danke.


Edit

Kann man eigentlich das Befehlsfenster/Shell anpinnen ? Damit man die Befehle sieht die abgesetzt werden - als Lerneffekt, damit man eben auch sieht was hinter einem Klick passiert ?
 
Zuletzt bearbeitet:
Kann man eigentlich das Befehlsfenster/Shell anpinnen ? Damit man die Befehle sieht die abgesetzt werden - als Lerneffekt, damit man eben auch sieht was hinter einem Klick passiert ?

Jein
Die letzten Befehl sieht man unten im Minlog. In napp-it pro kann man zusätzlich im TopMenü (neben Logout) auf Edit klicken. Nach einem Menü kann man dann über "Log" eine Komplettübersicht abrufen.

Ich habe übrigens meinen Simple-Write Test im Menü Pools > Benchmark um sync vs async mit kleiner und größerer filesize, optional mit modified recsize settings und einem abschliessenden sequential dd test with 5GB erweitert (aktuelles napp-it free/Pro). Der Unterschied Platten Pool vs SSD Pool ist schon heftig.

ex disk based pool

Code:
hostname                           filer
pool                               tank
write loop                         10 s
remark                             2 x Z2/6 disk vdev HGST Ultrastar 4TB

test 1/2 results                   writes via cache + sync logging    writes via cache only           
data per write                     8KB                                8KB                             
sync setting                       always                             disabled                        
compress setting                   off                                off                             
recordsize setting                 128K                               128K                            
write actions                      47                                 454                             
write actions/s                    4                                  45                              
throughput                         32 KBytes/s                        360 KBytes/s                    

test 3/4 results                   writes via cache + sync logging    writes via cache only           
data per commit                    256K                               256K                            
sync setting                       always                             disabled                        
compress setting                   off                                off                             
recordsize setting                 128K                               128K                            
write actions                      535                                436                             
write actions/s                    53                                 43                              
throughput                         13.6 MBytes/s                      11.0 MBytes/s                   

test 5/6 results                   writes via cache + sync logging    writes via cache only           
data                               5GB                                5GB                             
sync setting                       always                             disabled                        
dd sequential                      1.1 GB/s                           1.0 GB/s

vs ähnlich aufgebautem SSD only Pool

Code:
hostname                           video-1
pool                               av1
write loop                         10 s
remark                             2 x Z2/6 disk vdev Sandisk Extrem 960GB, no Slog

test 1/2 results                   writes via cache + sync logging    writes via cache only           
data per write                     8KB                                8KB                             
sync setting                       always                             disabled                         
compress setting                   off                                off                             
recordsize setting                 128K                               128K                             
write actions                      1056                               3660                             
write actions/s                    105                                366                             
throughput                         840 KBytes/s                       2.9 MBytes/s                     

test 3/4 results                   writes via cache + sync logging    writes via cache only           
data per commit                    256K                               256K                             
sync setting                       always                             disabled                         
compress setting                   off                                off                             
recordsize setting                 128K                               128K                             
write actions                      162                                1846                             
write actions/s                    16                                 184                             
throughput                         4.1 MBytes/s                       47.1 MBytes/s                   

test 5/6 results                   writes via cache + sync logging    writes via cache only           
data                               5GB                                5GB                             
sync setting                       always                             disabled                         
dd sequential                      861.2 MB/s                         2.1 GB/s
 
Moin,

sagt mal… ich habe mal eine Frage zu ESXi… In meinem Setup startet eine omniOS VM, welche per passthrough einen NFS pool an den ESXi bereitstellt, auf dem dann andere VMs liegen. Soweit so gut. Wenn jetzt die VMs nach dem Booten des ESXi alle automatisch hochfahren sollen, dann muss ja als erstes die omniOS VM gestartet werden und es muss auf alle Fälle genügend Zeit vergehen, bis ESXi den NFS-Pool wieder aktiviert.

Jetzt meine Frage… in ESXi kann man nicht nur die Startreihenfolge der einzelnen VMs, sondern auch eine Startverögerung setzen, bezieht sich die Startverzägerung jeder VM auf den Zeitpunkt an dem sie gestartet werden soll, oder auf den Startzeitpunkt des Hosts? Sprich, wenn ich die omniOS VM gleich zu Beginn starte, sgen wir mal nach 30s und der NFS-Pool dann nach 90s in ESXi sichtbar ist und die zweite VM nach der omniOS VM startet, würde man dann die Startverzegörung für die zweite VM relativ zum Start der omniOS VM angeben? Und die 3. VM dann relativ zur 2.?
 
@gea: ist 1706 immer noch aktuell? Der Updater gibt mir zumindest nix Neueres?

Und: das schreit ja fast nach einer Datenbank... gibt's die Möglichkeit, die Bench-Ergebnisse irgendwo hochzuladen? ;)

Ich hab da jetzt mal mit Standard-Settings (monitoring aus, stumpf nur auf "Submit" geclickt) beim Benchmark folgende Ergebnisse:

1. Raidz2 mit 8x4TB Seagate Constellation 2 (ST4000NM0033-9ZM)

Code:
hostname                           SM836
pool                               ISO_Raw
write loop                         10 s
remark                             RaidZ2/8Disk ST4000NM0033-9ZM 

test 1/2 results                   writes via cache + sync logging    writes via cache only              
data per write                     8KB                                8KB                                
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      257                                1857                               
write actions/s                    25                                 185                                
throughput                         200 KBytes/s                       1.5 MBytes/s                       

test 3/4 results                   writes via cache + sync logging    writes via cache only              
data per commit                    256K                               256K                               
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      28                                 1213                               
write actions/s                    2                                  121                                
throughput                         512 KBytes/s                       31.0 MBytes/s                      

test 5/6 results                   writes via cache + sync logging    writes via cache only              
data                               5GB                                5GB                                
sync setting                       always                             disabled                           
dd sequential

2. Mit 4x1TB alte Samsung HDDs im RaidZ:
Code:
hostname                           SolIntel
pool                               OldHDD
write loop                         10 s
remark                             RaidZ/4Disk SAMSUNG HD103SI  

test 1/2 results                   writes via cache + sync logging    writes via cache only              
data per write                     8KB                                8KB                                
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      293                                1829                               
write actions/s                    29                                 182                                
throughput                         232 KBytes/s                       1.5 MBytes/s                       

test 3/4 results                   writes via cache + sync logging    writes via cache only              
data per commit                    256K                               256K                               
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      21                                 1152                               
write actions/s                    2                                  115                                
throughput                         512 KBytes/s                       29.4 MBytes/s                      

test 5/6 results                   writes via cache + sync logging    writes via cache only              
data                               5GB                                5GB                                
sync setting                       always                             disabled                           
dd sequential

3. 4x4TB WD Red im RaidZ:
Code:
hostname                           SolIntel
pool                               ZFSdata
write loop                         10 s
remark                             RaidZ/4Disk WDC WD40EFRX-68W 

test 1/2 results                   writes via cache + sync logging    writes via cache only              
data per write                     8KB                                8KB                                
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      293                                1858                               
write actions/s                    29                                 185                                
throughput                         232 KBytes/s                       1.5 MBytes/s                       

test 3/4 results                   writes via cache + sync logging    writes via cache only              
data per commit                    256K                               256K                               
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      25                                 1148                               
write actions/s                    2                                  114                                
throughput                         512 KBytes/s                       29.2 MBytes/s                      

test 5/6 results                   writes via cache + sync logging    writes via cache only              
data                               5GB                                5GB                                
sync setting                       always                             disabled                           
dd sequential

4. Und zum Schluss 4x256GB Adata-SSDs im "Raid 0":
Code:
hostname                           SolIntel
pool                               iSCSI
write loop                         10 s
remark                             Raid0/4SSD ADATA SP920SS  

test 1/2 results                   writes via cache + sync logging    writes via cache only              
data per write                     8KB                                8KB                                
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      671                                1847                               
write actions/s                    67                                 184                                
throughput                         536 KBytes/s                       1.5 MBytes/s                       

test 3/4 results                   writes via cache + sync logging    writes via cache only              
data per commit                    256K                               256K                               
sync setting                       always                             disabled                           
compress setting                   off                                off                                
recordsize setting                 128K                               128K                               
write actions                      67                                 1159                               
write actions/s                    6                                  115                                
throughput                         1.5 MBytes/s                       29.4 MBytes/s                      

test 5/6 results                   writes via cache + sync logging    writes via cache only              
data                               5GB                                5GB                                
sync setting                       always                             disabled                           
dd sequential

Irgendwie zeigt er mir für Test 5 und 6 keine Ergebnisse (s.o.)?

Und irgendwie ist der SSD-Pool entweder grottenlahm oder die HDDs (genauso) schnell?
 
Moin,

sagt mal… ich habe mal eine Frage zu ESXi… In meinem Setup startet eine omniOS VM, welche per passthrough einen NFS pool an den ESXi bereitstellt, auf dem dann andere VMs liegen. Soweit so gut. Wenn jetzt die VMs nach dem Booten des ESXi alle automatisch hochfahren sollen, dann muss ja als erstes die omniOS VM gestartet werden und es muss auf alle Fälle genügend Zeit vergehen, bis ESXi den NFS-Pool wieder aktiviert.

Jetzt meine Frage… in ESXi kann man nicht nur die Startreihenfolge der einzelnen VMs, sondern auch eine Startverögerung setzen, bezieht sich die Startverzägerung jeder VM auf den Zeitpunkt an dem sie gestartet werden soll, oder auf den Startzeitpunkt des Hosts? Sprich, wenn ich die omniOS VM gleich zu Beginn starte, sgen wir mal nach 30s und der NFS-Pool dann nach 90s in ESXi sichtbar ist und die zweite VM nach der omniOS VM startet, würde man dann die Startverzegörung für die zweite VM relativ zum Start der omniOS VM angeben? Und die 3. VM dann relativ zur 2.?

Ich würde sagen, du bist hier im falschen Thread. Hier gibt es einen Thread für ESXI:

ESX / ESXi - Hilfethread

Gruß Hoppel
 
Mal so für für einen napp it Neuling, wo finde ich die Ergebnisse des Benches ? Irgendwie finde ich nichts was auch nur ansatzweiße so auschaut wie eure Posts.
 
Aus dem Kopf: Menü "Pools" glaub 2. Punkt von unten "Benchmarks" clicken, also nicht einen der Untermenüpunkte. Da dann auf submit und am Ende werden Dir die Ergebnisse angezeigt.
 
Menü Pools > Benchmarks verweist in der neuesten Version auf obigen Write-Test.
Updaten auf aktuellste Version über About > Update > Download 17.06 free oder Pro (16. Okt 2017)
 
@Deathweaver:
Das hast du dir leider mit deinem Pool das versaut:
Du hast eine Recordsize von 128K und sechs Datenhaltende Platten mit 4K Sektoren. Also wäre für die Platten der kleinste Block 6*4K also 24K. Um die 128K zu schreiben benötigst du nun 6 Blöcke von jeder Platte. Das sind also 6*24K also 144K Real für jeden Block a 128K. Hier sehen wir 16K Verschnitt oder um es deutlicher auszudrücken: 12,5%. Dies ist der Platz der dir fehlt. Deshalb wird für jedes RaidZ empfohlen 2^n plus Redundanz also für ein RaidZ1 3 oder 5 Platten, für ein RaidZ2 6, 10 oder 18 und für ein RaidZ3 7, 11, 19 oder 35 Platten.

Was würde eigentlich passieren wenn man die Recordsize von 128k auf 96k oder 192k ändert? Und die Daten auf nen neues Dataset kopiert? Dann müsste der verschnitt doch bei praktisch 0 sein?
 
Was würde eigentlich passieren?

Es käme eine Fehlermeldung dass recordsize nur eine Zweierpotenz zwischen 512B und 1M sein kann.


Der übliche Ausweg wenn man nicht die optimale Anzahl von Platten je vdev hat, ist aber eine größere recordsize z.B. 256, 512k oder 1M. Wenn man allerdings iSCSI targets, Datenbanken oder VMs mit anderen Dateisystemen auf dem Pool hat, ist vor allem bei parallelen Zugriffen mit einer geringeren Performance zu rechnen.
 
Freenas vs. FreeBSD im Bezug auf ZFS

Freenas beruht ja auf FreeBSD.... aber ist das FreeBSD „effizienter“ Ressourcenschonender als das freenas?
Steh gerade vor der Entscheidung....benötige nur zfs mit nfs...
 
FreeNAS (oder auch Nas4Free) erleichtern die Einrichtung/Verwaltung von ZFS über eine GUI und hat einie Features von Haus aus integriert, die ebenfalls via GUI eingerichtet/verwaltet werden

Bei FreeBSD hast du nur (erstmal) die shell-befehle. Für ZFS ist mir leider kein Verwaltungswerkzeug bekannt, welches unter native FreeBSD läuft. Webmin bringt einige wenige Funktionen für ZFS mit, aber längst nicht alle. Napp-IT ist leider nicht für FreeBSD portiert. (Man könnte natürlich versuchen die Linux Version zum laufen zu bekommen. Soweit ich weiß gibt es da teilweise Möglichkeiten.)

TrueOS wäre dann die möglicherweise bessere Alternative. TrueOS (ehemals PCBSD) ist ein FreeBSD Fork mit deutlich verbesserter Integration von ZFS und bringt auch für FS einige GUI-Werkzeuge mit.
z.B. kann man gleich bei der Installation ein redundantes VDEV aus mehreren HDDS/SSDs für rpool anlegen, das geht bei FreeBSD auch wieder nur via shell - so zumindest mein letzter Stand, könnte sich mitlerweile also geändert haben.

Kurzum: Willst du ein einfachverwaltbares Storage haben, welches die ein ander Funktion/Dienst zusätzlich bereitstellt und ggf. über Virtualisierungsumgebungen (Docker bei FreeNAS / Virtualbox bei N4F), zusätzlich Plugins / Addons oder Jails erweiterbar ist >> Go NAS-Distri
Willst du ein voll konfigurierbares FreeBSD >> Go TrueOS | FreeBSD Desktop Operating System with ZFS - TrueOS oder FreeBSD
 
Zuletzt bearbeitet:
Wenn wirklich nur zfs mit nfs - warum nicht direkt die Mutter Solarish + napp-it?
 
Solaris und Napp-it wäre da auch mein Vorschlag, wenn nicht viel mehr benötigt wird als NFS.
Soweit ich weiß, hat Open ZFS auch noch kein Trim Support - solltest du SSDs einsetzen wollen.Ausnahme ist wohl tatsächlich FreeBSD, was wohl Trim kann.
 
FreeBSD 11 nativ als auch Nas4Free kann man gleich bootbar auf Zpools mit und ohne Redundanz installieren.
FreeNas weiss ich grad nicht mehr.

FreeBSD nativ hat den Vorteil, dass es sehr ressourcenschonend ist. GUI kann man ja bei Bedarf via X11+KDE nachinstallieren.
ARC Komprimierung geht mittlerweile auch.

Als Virtualisierer steht bhyve nativ in FreeBSD zur Verfügung. Der kann direkt mit Zvols als virtuelle Platten umgehen. Bhyve ist halt noch jung.

Ich bau seit geraumer Zeit (mit wenig Prio) an einen VisualStudio-Projekt zur Verwaltung von FreeBSD-Storage via SSH, hab aber nur sehr wenig Zeit dafür.
 
Zuletzt bearbeitet:
Also kurz zur Erklärung.

Ich habe Proxmox laufen und will dort eine VM mit geringen Ressourcen haben an die die Platten durchgereicht werden und dann durch nfs zu den anderen VM bereitstellt.

Dazu benötige ich keine GUI. Konsole reicht, wenn man dann noch etwas dazu lernt kann das ja auch nicht schaden ;)
 
Solaris und Napp-it wäre da auch mein Vorschlag, wenn nicht viel mehr benötigt wird als NFS.
Soweit ich weiß, hat Open ZFS auch noch kein Trim Support - solltest du SSDs einsetzen wollen.Ausnahme ist wohl tatsächlich FreeBSD, was wohl Trim kann.

Die Situation ist recht uneinheitlich vor allem wenn es um Trim auf Raid/vdev Ebene geht und nicht nur bei Einzel-SSDs. Unterstützung von Trim auf ZFS vdev Ebene gibt es unter BSD und bei Illumos mit NexentaStor5. Es gibt Requests für allgemeines Illumos und ZoL. Vielleicht kommt das irgendwann wird aber auf Entwicklerebene nicht als dringend gesehen. Schnellere Alternativen auf ZFS Metaslab Ebene werden da bevorzugt aber auch das mit minimaler Entwicklerpräferenz, vgl Features - OpenZFS

Das Problem ist daß es Trim nicht umsonst gibt. Trim auf Raid/vdev und OS Ebene bedeutet dass eine Map mit den SSD Regionen geführt werden muss die bei jedem Write aktualisiert und gelesen werden muss um zu entscheiden ob eine Region vor dem Schreiben gelöscht werden muss. Das kostet RAM und Schreib-Performance. Es wirkt damit umso besser je weniger Schreiblast anliegt und je schlechter die SSD sind. Soweit ich die Diskussion verfolgt habe war die vorherrschende Meinung eher dass für ein professionelles System mit hoher Schreiblast eher auf Trim verzichtet werden soll und stattdessen Enterprise-SSDs eingesetzt werden. Deren interne Garbage Collection ist so gut dass es ein Extra OS Trim nicht braucht, ganz im Gegenteil es ohne dessen Performanceprobleme arbeitet. Man sieht das ja schön an Dauerschreibtests. Während eine Desktop SSD mit angegebenen 80k Schreib-Iops unter dauerhaftem Schreiben gerne mal auf 5k iops einbricht bleibt eine gute Enterprise SSD bei 40k iops ohne Trim.

Bei Semi-professionellen SSDS kann man durch Overprovisioning z.B. mittels HPA/ host protected area (SSD wird nicht voll genutzt sondern z.B. nur zu 80%) fast die Dauer-Schreibleistung von Enterprise SSDs erreichen.

Ich vermisse Trim daher nicht sondern nehme halt entsprechend bessere SSDs für ein insgesamt schnelleres Schreibverhalten. Zudem haben Enterprise SSDs auch Powerloss Protection, ohnehin ein wichtiges Feauture
 
Aber nochmal die Sinnfrage: Proxmox ist ein Debian, was das selbst genauso gut kann wie das, was Du Dir da wohl als VM vorstellst? Du verkomplizierst da m.E. etwas unnötig. Es sei denn, du willst da Dateisysteme, Netzwerkprotokolle oder Usermanagement verwalten, die Proxmox von Haus aus nicht kann. Dann bietet sich eventuell (!) iSCSI als Freigabeweg in die VM an.
 
Hallo zusammen,

Ich hätte da mal ne Frage bzgl. des Pools.

Ich lege ein 3x SSD RaidZ an und habe nur dies im Pool.
Das RaidZ wird befüllt und hat irgendwann 60%.

Nun entscheide ich mich den Pool um ein weiteres 3x SSD RaidZ zu erweitern.

Wie wird der Pool nun weiter befüllt?
1. Neue Daten werden auf das neue RaidZ gelegt bis der Füllstand gleich ist (Geschwindkeit also =1)
2. Neue Daten werden verteilt geschrieben bis der alte Pool voll ist und nur noch der neue Befüllt wird (Geschwindkeit also anfangs =x2, später =1)
3. Das System verteilt die Daten des alten Pools mit auf den neuen Pool und gleicht den Füllstand an. (Geschwindkeit wird nach kurzer Zeit bei =2)
 
4. Die Daten werden nicht gleich verteilt. Auf das das leere vdev werden mehr Daten geschrieben, bis sich der Füllstand irgendwann mal angleicht. Je höher der Unterschied, desto mehr Writes gehen auf das leerere vdev.
 
Aber nochmal die Sinnfrage: Proxmox ist ein Debian, was das selbst genauso gut kann wie das, was Du Dir da wohl als VM vorstellst? Du verkomplizierst da m.E. etwas unnötig. Es sei denn, du willst da Dateisysteme, Netzwerkprotokolle oder Usermanagement verwalten, die Proxmox von Haus aus nicht kann. Dann bietet sich eventuell (!) iSCSI als Freigabeweg in die VM an.

naja ich glaube ich hab da echt etwas verkompliziert als es eigentlich ist. Ich hab es aber gerade am Speed gemerkt, dass das so nichts wird ;) Mit ZFS im Debian/Proxmox ist es deutlich schneller :P

Ist es denn Sinnvoll einen nfs server im Debian/proxmox laufen zu lassen oder eine vm zu erstellen, den storage durchzureichen und denn dann wieder mit nfs für andere vm freizugeben?
 
Wegen NFS irgendwas durchzureichen macht keinen m.E. keinen Sinn.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh