[Sammelthread] ZFS Stammtisch

ja, aber da funktioniert leider kein Snapshot usw, wenn ich mich nicht täusche?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
am Proxmox Host nur per Qcow, aber ich würde dies dem Storage und nicht dem Proxmox Host überlassen.
 
Kann man in napp-it die Notification Mail irgendwie testen? Bin mir nicht sicher ob ich alles richtig eingegeben habe bzw. ob es notwendig noch irgendwas an der Firewall meines Router einzustellen (habe eine FritzBox). Gehe mal nicht davon aus, da es ja nur Ausgehender Traffic ist.

Screenshot 2018-11-04 at 15.33.10.png
 
Menü Jobs > TLS Email > TLS Test (Für TLS verschlüsselte Mails via Gmail)
 
Soll ich bei einem Replikationsjob für ein Backup auf einer HDD immer erst den Pool exportieren bei herausnahme der HDD vom Server und importieren bei einstecken der HDD? Oder ist es genug, wenn ich die Platte einfach abziehe? Insofern bekomme ich dann aber Fehlermeldungen, dass der Pool nicht mehr verfügbar ist.
 
irgendwie glaube ich, dass mein ZFS nicht die Geschwindigkeit erreicht, die es eigentlich haben müsste:

Ich habe einen Striped Mirror (2*3TB+2*4TB+2*3TB) und habe per 10Gbe (NFS) eine Schreibrate von ca 300mb/s und lesend ca 200mb/s.

Ich hätte jetzt eher etwas in Richtung von 400mb/s in beide Richtungen erwartet.
Crystal Diskmark gibt sogar nur so 12-50mb/s schreibend an bei 200mb/s lesend. Mit mergerfs (also wohl auch in den RAM) hatte ich zumindest Raten von 560mb/s lesend und 490mb/s schreibend.
Ich wollte mit ZFS einen Performancegewinn und keinen -verlust erzielen..

Woran kann das liegen?
 
Zuletzt bearbeitet:
Soll ich bei einem Replikationsjob für ein Backup auf einer HDD immer erst den Pool exportieren bei herausnahme der HDD vom Server und importieren bei einstecken der HDD? Oder ist es genug, wenn ich die Platte einfach abziehe? Insofern bekomme ich dann aber Fehlermeldungen, dass der Pool nicht mehr verfügbar ist.

Die saubere Methode ist mit Export/ Import.
Neben den Fehlermeldungen gibts ansonst auch Alert-Emails (sofern verfügbar) und je nach Controller sogar ein kurz/länger/immer hängendes System

- - - Updated - - -

irgendwie glaube ich, dass mein ZFS nicht die Geschwindigkeit erreicht, die es eigentlich haben müsste:

Ich habe einen Striped Mirror (2*3TB+2*4TB+2*3TB) und habe per 10Gbe (NFS) eine Schreibrate von ca 300mb/s und lesend ca 200mb/s.

Ich hätte jetzt eher etwas in Richtung von 400mb/s in beide Richtungen erwartet.
Crystal Diskmark gibt sogar nur so 12-50mb/s schreibend an bei 200mb/s lesend. Mit mergerfs (also wohl auch in den RAM) hatte ich zumindest Raten von 560mb/s lesend und 490mb/s schreibend.
Ich wollte mit ZFS einen Performancegewinn und keinen -verlust erzielen..

Woran kann das liegen?

Welches OS
wieviel RAM
was für ein HBA/ Nic

Ansonsten ist ZFS mit wenig RAM langsamer als z.B. ext4.
ZFS wurde ja mit dem Ziel crashsicher und Datensicherheit entwickelt. Sowohl CopyOnWrite (Crashsicher aber mehr Fragmentation und Daten da immer ein kompletter Block neu geschrieben werden muss/ kein Infile Update) wie auch Prüfsummen (mehr Daten) sind ja nicht performancesteigernd. Ausgleichen kann man das aber meist mit mehr RAM als Schreib/ Lesecache.

Auch gibt es Unterschiede je nach OS. Ortiginal ZFS ist auch schneller als Open-ZFS.
 
@gea:
OS: Debian 9.5
RAM: 16GB (sollte bei 20TB Netto ohne deduplication ausreichen)
HBA: aktuell onboard, es steht aber auch ein H310 im IT-Modus bereit
NIC: Mellanox Connectx-2

achja: sollte man sharenfs bzw sharesmb nutzen oder die "normalen" konfigurationen des Betriebssystems?


edit: ahh es lag an NFS bzw sharenfs. Ich habe mal sharesmb auf off gesetzt und dann "normal" per Samba angebunden und schon sind die Raten bei 533mb/s lesend und 935mb/s schreibend. Das ist doch schon eher was :)
 
Zuletzt bearbeitet:
edit: ahh es lag an NFS bzw sharenfs. Ich habe mal sharesmb auf off gesetzt und dann "normal" per Samba angebunden und schon sind die Raten bei 533mb/s lesend und 935mb/s schreibend. Das ist doch schon eher was :)
sharenfs / sharesmb dürfte auf 1G und nicht auf 10G konfiguriert sein. Vielleicht klappt es mit den Optimierungen von gea für 10G besser? (s. z.B. napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Handbücher -Tuning).
 
Die smb/sharenfs=on Einstellung gibt es unter BSD oder Linux nur aus Kompatibilitätsgründen zu Solarish.
Lediglich Solarish hat z.B. den in ZFS und das OS eingebauten multithreaded SMB Server.

Unter Linux geht das z.B. auf den normalen SAMBA Server. Lediglich die Einstellungen können unterschiedlich sein und das wird hier wohl die Ursache sein,
 
kann mir jemand sagen, wie die Performance -Unterschiede zwischen Freenas und Proxmox ZFS sind?

Zum Hintergrund: Derzeit hab ich ein Proxmox Server, wo ich per Container ein Samba Share bereitstelle. Hab derzeit noch ein Pi-Hole.

Mehr hab ich aber derzeit nicht an VM's.Aus diesem Grund überlege ich evtl. zu FreeNas zu wechseln. Bin mir aber noch nicht 100% sicher. Ob sich das lohnt, da bin ich mir nicht ganz sicher.
 
FreeNAS basiert auf Free-BSD als OS mit SAMBA
Proxmox basiert auf Linux als OS mit SAMBA

Ich erwarte keine allzu großen Performanceunterschiede. FreeNAS gilt als besonders Ram hungrig, liegt aber eher an der GUI.

Alternative
Solarish mit dem in ZFS und das OS integrierten multithreaded SMB Server

Bei Solarish gibt es Oracle Solaris (schlicht der schnellste ZFS Server mit nativen ZFS und den meisten Features) und die freien Solaris Forks um Illumos, z.B. OmniOS und NexentaStor. Die nutzen wie BSD oder Linux Open-ZFS bringen aber von Haus aus den Solaris eigenen SMB, NFS und FC/iSCSI Server. (Sun hat nicht nur Solaris und ZFS erfunden sondern auch z.B. NFS).
 
Nichtsdestotrotz finde ich solarish bedeutend komplizierter zum einarbeiten.
 
Für einen reinen Filer ist die Komplexität sehr überschaubar.
 
1. Natives ZFS, das ist Oracle Solaris und die ersten Solaris Forks. Viele ursprüngliche ZFS Eigenschaften wie der in ZFS eingebaute NFS/SMB Server sowie die Unterstützung von Windows SID und ntfs4 ACL (wie bei ntfs) sind nach wie vor nur bei Solaris und dessen Illumos Fork verfügbar.

2. Seit 2010 wird ZFS einerseits bei Oracle (die native Version ZFS v.44) und für BSD, Illumos und ZoL als koordiniertes Projekt (ZFS v.5000) unter dem Dach von Open-ZFS weiterentwickelt. Das sorgt dafür dass Open-ZFS Pools eine sehr große Kompatibilität zwischen den Betriebssystemen BSD, Illumos und Linux haben und neue Features recht schnell auf den verschiedenen Plattformen erscheinen. In den Features unterscheiden sich BSD, Illumos und Zol bis auf die Eigenschaften unter 1. gottseidank recht wenig bzw nur kurzzeitig.

Richtig ist allerdings, dass ZFS unter Illumos das alleinige Dateisystem ist und unter BSD das dominierende. Das sorgt hier für Problemfreiheit im Betrieb oder bei Updates da alles ausschließlich oder weitgehends auf ZFS abgestimmt ist. Unter Linux ist ZFS eins von vielen und nicht das Basisdateisystem und damit gibts doch immer wieder Probleme, insbesondere bei Updates.

Auch fehlt ZoL eine vergleichbare webbasierte Managementoberfläche die die Möglichkeiten von ZFS auch nur halbwegs abdeckt. Es gibt OMV aber das ist eher für nicht-ZFS Sachen optimal.
 
Bin gerade am Überlegen, ob sich Open-ZFS bei mir aufgrund des Verhaltens von Verschlüsselung + L2ARC disqualifiziert:

Laut FreeNAS-Doku ist alles, was auf den L2ARC-Laufwerken liegt, nicht verschlüsselt (Quelle: 8. Storage FreeNAS®11.1-U6 User Guide Table of Contents ).

Ist dies bei Orlacles Variante genauso? Ich verstehe ja noch, dass alles im ARC/RAM entschlüsselt vorliegt, aber auf nicht-flüchtigen Speichern finde ich das irgendwie weniger berauschend.
 
Bisher geschieht die Verschlüssellung bei Open-ZFS (egal ob BSD, Illumos oder Linux) auf der Basis von verschlüsselten Platten oder Dateien, also unterhalb von ZFS. ZFS bekommt davon gar nichts mit. Damit ist klar dass Cache und Replikation immer unverschlüsselt ist. Das ändert sich aber in naher Zukunft da es auch unter Open-ZFS echte ZFS Verschlüssellung geben wird: 8727 Native data and metadata encryption for zfs by lundman · Pull Request #489 · openzfs/openzfs · GitHub. Diesmal ist sogar eine auf ZoL spezialisierte Firma federführend. Dank Open-ZFS Kooperation kommt das auch auf den anderen Plattformen ziemlich zeitgleich.

Lediglich das originale ZFS v.44 in Oracle Solaris hat momentan echte ZFS Verschlüssellung. Damit kann man auch Cache und Replikation verschlüsseln oder per Dateisystem unterschiedlich verfahren (Verschlüssellung ist Eigenschaft eines einzelnen Dateisystems). Solaris ZFS ist Open-ZFS immer noch deutlich vorraus. Da gibts auch vieles wie dedup2, schnelleres Resilvering, Auditing, NFS 4.1, SMB 3.1 das es bei Open-ZFS oder den freien Solaris Forks nicht gibt.
Solaris kann man frei bei Oracle herunterladen und nicht-kommerziell nutzen - das dann aber ohne Bugfixes. Das erfordert einen Wartungsvertrag den es dann bis 2036 gibt. Kostet halt ca 800 Euro pro Jahr für eine single-CPU und ist für kommerzielle Nutzung obligatorisch.
 
Zuletzt bearbeitet:
ZFS vCluster

Ich bin gerade dabei meine Z-Raid ZFS Cluster in a Box Lösung fertig zu entwickeln.

Die herkömmliche Lösung ist ein Cluster in a Box bei der sich zwei Server einen gemeinsamen Pool von Multipath SAS Platten teilen. Von SuperMicro gibt es dazu Gehäuse für zwei Mainboards und multipath SAS Platten. Ein Server greift auf die Platten zu und gibt Dienste wie NFS oder SMB frei. Zur Wartung oder im Fehlerfall kann man auf den zweiten Server umschalten der dann die Platten/den Pool übernimmt und die Dienste bereitstellt. Eine gängige Software dazu ist RSF-1 von high-availability.

Diese Lösung ist üblicherweise sehr teuer und sehr kompliziert. Sie erlaubt aber hochverfügbare Speicherlösungen bei bestmöglicher Performance. Meine Lösung basiert auf dem gleichen Konzept, virtualisiert aber den Cluster unter ESXi (Lizenz egal) und nutzt die Möglichkeiten von ESXi RAW Platten zwischen VMs zu sharen. Damit geht diese Lösung auch mit Sata Platten. Auch genügt ein Server statt der vorherigen zwei.

Setup siehe http://www.napp-it.org/doc/downloads/z-raid.pdf

Wer`s testen möchte, es ist als Preview in der 18.02pre free (freier Download)


cluster-in-a-box.png
 
Problem mit unbekanntem Device

Debian mit ZFS und folgendes Problem beim "pool2":

pool: pool1
state: ONLINE
scan: resilvered 3,68M in 0h0m with 0 errors on Sun Oct 14 15:36:55 2018
config:

NAME STATE READ WRITE CKSUM
pool1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
sda ONLINE 0 0 0

errors: No known data errors

pool: pool2
state: DEGRADED
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: ZFS Message ID: ZFS-8000-9P
scan: scrub repaired 0 in 0h0m with 0 errors on Fri Nov 9 14:10:40 2018
config:

NAME STATE READ WRITE CKSUM
pool2 DEGRADED 0 0 0
raidz2-0 DEGRADED 0 0 0
8682216994852003140 OFFLINE 0 0 0 was /dev/sda1
sdb ONLINE 0 0 2
sde ONLINE 0 0 0
sdf ONLINE 0 0 0
sdg1 ONLINE 0 0 0

errors: No known data errors

Offline hab ich das ja schon bekommen, aber es geht nicht zu entfernen mit "zpool remove" oder "zpool detach"
Es ist auch keine HD angeschlossen mit dem Namen. Das Problem besteht seit dem letzten reboot, da hat sich wohl was mit den Laufwerksbezeichnungen verändert.
 
Hat ZFS/Nappit irgendeinen Tieringmechanismus der Daten nach Zugriffsmustern auf verschiedenen Pools verschieben kann ?
 
nein.
ZFS möchte durch massiven Einsatz von RAM/SSD/NVMe Cache den Zugriff auf den gesamten Pool beschleunigen bzw die Schreib und Leselast möglichst aus dem RAM zu bedienen.
 
Ich nutze zur ZoL.

Würde es ein Problem sein, wenn ich die SnapShots (Backup) auf napp-it speichern würde? Ich denke verwenden könnte ich dann die SnapShots weiterhin nur auf ein ZoL oder?
 
Ein Snapshots bei ZFS friert einen früheren Dateistand ein. Er ist also Bestandteil eines Dateisystems. Man kann lediglich ein ganzes Dateisystem auf der Basis eines Snaps auf ein anderes ZFS Dateisystem (gleicher oder anderer Pool/Rechner) per zfs send übertragen. Das muss nicht, geht aber oft zwischen verschiedenen Open-ZFS Plattformen
 
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