[Sammelthread] ZFS Stammtisch

Ich beschäftige mich gerade mit dem Thema Cloud-Filer, also einem lokalen ZFS Filer auf dem man per SMB Dateien direkt bearbeiten kann kombiniert mit einer inhouse Amazon kompatiblen S3 Cloud bei dem man die gleichen Dateien im Internet bereitstellt (sync and share).

Prinzipiell sind Dateien auf einem lokalen SMB Filer und gleichzeitiger Cloudzugriff darauf problematisch wenn nicht inkompatibel da es kein gemeinsames File-Locking, Authentifizierung oder Authorisierung auf Datei Ebene gibt. Nicht zuletzt wegen Corona wird Internet Zugriff auf Dateien deren primärer Speicherort ein lokaler Filer ist aber immer wichtiger. Auch wird eine lokale Inhouse-Cloud den Datenschutzforderungen wegen dem EUGH Urteil/ Schrems 2 eher gerecht als eine Cloud von US Anbietern.

Mein aktueller Ansatz:
- Doppelte Bereitstellung der Dateien in einem SMB Dateisystem und einem S3 Cloud Dateisystem. Das gleichzeitige Sharen eines ZFS Dateisystems via SMB und S3 ist zwar möglich aber nur bei einem/wenigen Nutzern sinnvoll.

- Aktivierung von ZFS Realtime Dedup damit alle Datenblöcke nur einmal gespeichert werden.
- Nutzung eines NVMe Mirrors (z.B. Optane 4801X=100) als special vdev für die Dedup Tabelle
Das vermeidet die RAM Probleme von dedup

- Nutzung der Benutzer/ Gruppenverwaltung von S3 (minIO)
S3 Nutzer und Gruppen kann man mit Unix/SMB Nutzern syncronisieren. Ich arbeite gerade daran das in napp-it 20.dev zu integrieren. Beim Anlegen eines S3 Nutzes kann man gleichzeitig einen SMB Nutzer anlegen und einer lokalen SMB Gruppe zuweisen.

-Policy Management für S3 (menügesteuert).
Beim Anlegen einer Policy kann man per Bucket (S3 Ordner) Rechte wie readonly, writeonly oder readwrite festlegen und die dann einem Benutzer oder Gruppe zuweisen.

- Sync der beiden Bereiche on demand oder zeitgesteuert mit rclone, rsync oder einem sync Script als job (one way oder 2way).

Im Moment kämpfe ich noch etwas mit dem Policymanagement von S3 bei einzelnen Buckets (Ordner auf einem S3 Server). Prinzipiell funktioniert es aber bereits.

Falls jemand mehr Details will, siehe (um nicht alles doppelt zu schreiben)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
jetzt habe ich auch mal ne Frage, scheinbar habe ich mich irgendwie ausgetrickst....

Ziel ist: endlich mal SLOG und Cache ausprobieren, also kleine Optane-Karte gekauft und an die VM gegeben per passthrough. Das klappte nicht, also dann halt per RDM, das scheint zu funktionieren. Das ganze läuft auf einer Napp-it in one mit 'omnios-r151034-b3d6e2addc'.

Den Riegel habe ich vorher per gparted boot disk partitioniert, und nun geht's los:
Code:
# echo | format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
[...]
       6. c12t1d0 <VMware-Virtual NVMe Disk-1.0-13.41GB>
          /pci@0,0/pci15ad,7a0@17/pci15ad,7f0@0/blkdev@1,0
Specify disk (enter its number): Specify disk (enter its number):
und
Code:
# parted /dev/dsk/c12t1d0 print
Model: Generic Ide (ide)
Disk /dev/dsk/c12t1d0: 14.4GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name       Flags
 1      1049kB  2308MB  2307MB               op-log1         
 2      2308MB  4615MB  2307MB               op-log2         
 3      4615MB  9019MB  4404MB               op-cache1       
 4      9019MB  13.4GB  4404MB               op-cache2

Also dann log erstellen... - klappt aber nicht:
Code:
# zpool add filepool01 log /dev/dsk/c12t1d0p1
cannot open '/dev/dsk/c12t1d0p1': No such device or address

Nanu? Die gleiche Fehlermeldung kommt übrigens auch per Napp-it WebUI - aber nur mit 'aktivierten' Partitionen. Ohne dies wird der ganze Datenträger verwendet - das klappt zwar, aber ich möchte ihn lieber aufteilen...

Und dieses Gerät müsste doch existieren, es wird immerhin auch bei Napp-it in der Übersicht angezeigt:
Bildschirmfoto 2020-10-11 um 17.13.29.png


Aber irgendetwas mache ich wohl grundsätzlich falsch bei der Sache, oder??
 
so, nach nun einigem hin- und herprobieren habe ich den Datenträger mit dem OmniOS eigenen fdisk formatiert - da muss man interaktiv die Größen der Partitionen in % eingeben, und damit hat's dann geklappt.
So ganz verstehe ich das nicht, aber nun, immerhin einen Schritt weiter gekommen 👍
 
Hat jemand einen Tipp, was man bei macos tun kann, um die SMB Zugriffsrate zu verbessern. Aktuell komme ich selbst kabelgebunden nicht über 23-25 MB/s hinaus. Die selbe Leitung mit Windows schafft zwischen 100-115 MB/s. Es ist echt z.K.

Catalina 10.15.7, smb://
 
Zuletzt bearbeitet:
Seit 10.11 habe ich es nie mehr geschafft, unter OSX annähernd an Windows heranzukommen. Bis da war OSX eher minimal schneller. Dass Windows einfach so 3x so schnell ist entspricht auch meinen aktuellen Erfahrungen. Was man tun kann ist SMB signing abzuschalten (Server oder Client) und sicherzustellen dass der Server SMB 3 kann.

Das Abschalten der .DS_Store soll auch was bringen, hieß es früher wenigstens mal. Dr. Google bringt aber auch aktuell mehr Problemmeldungen als Lösungen zu "Slow SMB Catalina"

 
  • Danke
Reaktionen: you
Danke gea,

dann lass ich es jetzt so und mache größere Downloads und File-Transfer über eine virtuelle Windows10-Maschine auf dem Macbook. Es ist schon verrückt, aber über die Parallels-Windows 10 Maschine funktioniert der Download wie nativ unter Windows.

Also: Macbook mit macos, darauf läuft über Parallels eine Windows10 VM und hat Zugriff auf SMB meines NAS, Download erfolgt auf macos/USER/xyz/Download Verzeichnis --> Speed: 110-120 MB/s
 
Signing kann man serverseits auf jeden Fall abschalten.
Unter OmniOS/napp-it im Menü Services > SMB > Properties.

Falls OmniOS, dann 151034 nehmen. Da gibt es viele OSX Anpassungen u.A. auch Timemachine über SMB out of the Box.
 
  • Danke
Reaktionen: you
Hi,
Ich habe zwei neue EVO 860 im mirror ohne Probleme am laufen. Beim scrub erhalte ich aber folgende Meldung:

Code:
pool: ssdpool
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: http://zfsonlinux.org/msg/ZFS-8000-9P
  scan: scrub repaired 378K in 0 days 00:08:52 with 0 errors on Sat Oct
17 13:18:40 2020
config:

        NAME                        STATE     READ WRITE CKSUM
        ssdpool                     DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            wwn-0x5002538e39c27678  DEGRADED     3     0   114  too many errors
            wwn-0x5002538e49b1c1c9  ONLINE       0     0     0

errors: No known data errors

Ist die SSD im Eimer?


Wenn ich clear mache, läuft sie ohne Probleme weiter im Pool online
 
Was sagt smartctl zu der betroffenen SSD?

Dem ersten Blick nach, ist sie aber kurz vorm Ableben.
 
Smartwerte protokollieren Betriebswerte einer Platte während ZFS tatsächliche Fehler anzeigt. Auch wenn Smart nichts anmerkt, so sind doch tatsächliche Lesefehler aufgetreten. Smart würde allenfalls einen erfolglosen Leseversuch protokollieren, keine falschen Daten.

Wenn nicht gerade das Kabel oder ein Steckanschluß das Problem erzeugt, so ist die SSD defekt. Man sollte ein Testtool einsetzen das die SSD intensiver auswertet oder prüft (Samsung Magician, WD data lifeguard o.Ä.). Damit hätte man mehr Gewissheit und ein Fehlerprotokoll für eine eventuelle Garantieforderung.
 
Ich würde in der Tat den Anschluss kontrollieren. Also die Kontakte mit Iso säubern und das Sata-Kabel wechseln. Dann Pool resilvern lassen und prüfen, wie es aussieht.
 
Das (un)schöne an ZFS ist dass es gnadenlos jeden Fehler sofort entdeckt. Mit ext4 oder ntfs könnte man weiter ruhig schlafen und müsste nichts davon wissen - bis man halt voll auf die Nase fällt.

Ich würde auf jeden Fall die Disk kritisch beobachten, regelmäßig Backups machen und hoffen dass das Problem nicht mehr auftaucht. Wenn auch die andere Platte sowas meldet, ist es vermutlich ein RAM Problem. Ram Fehler (ohne ECC) können auch dazu führen dass eine Platte wegen too many errors rausfliegt. Hat die gleiche Platte nochmal das Problem, Kabel prüfen/tauschen ansonst raus damit und ersetzen.

Eventuell auch ein Auge auf die Temperatur werfen (mit Smartmontools auslesbar).
 
ZFS hat da auch mich schon rechtzeitig gewarnt, dass in nem Pool was nicht stimmt. Sei es ein Speichermedium gewesen oder auch eine Verkabelung/Backplane. :-)
 
Die Temperatur liegt bei 21 Grad. RAM ist reg. ECC und die SSD steckt in einer Backplane.

Ich werde es Mal weiter beobachten und Backups machen.

Welche ist denn davon nun die auffällige SSD?
 
Die WWN-Nummer ist nicht aufgedruckt? Die sollte normal eindeutig sein (zumindest ist sie das normal bei den guten Herstellern. Bei den allerbilligst-SSDen aus so manchem Online-Kanal wär ich da eher skeptisch)
Der Pool scheint ja mittels den WWN (0x5002538e39c27678) eingerichtet zu sein. Damit kann man sie identifizieren.

Falls WWN nicht aufgedruckt, im Zweifelsfall per "smartctl" die Daten beider SSDen ausgeben lassen und die Hersteller-Seriennummer der mit der problematischen WWN notieren. Diese Seriennummer sollte auf alle Fälle aufgedruckt sein.

Noch einfacher wirds natürlich, wenn Du Dir die Einbauplätze zusammen mit Seriennummern und WWN wo notiert hast. Manche Appliances (ich meine auch z.B. napp-IT) haben auch eine elektronische Map für die Einbauplätze, die man dann via Browser pflegen und abfragen kann.
 
Zuletzt bearbeitet:
Ah okay, danke. Der Server steht aktuell 550 km entfernt, deshalb habe ich keinen physischen Zugriff. Ich mache aktuell ein paar Backups.

Hat hier jemand Erfahrungen mit striped raidz1 oder striped raidz2?
 
Zuletzt bearbeitet:
Hallo zusammen,

ich möchte unter OmniOS/napp-it einen pool umkonfigurieren (mirror aus 2 SSDs mit 4 neuen Laufwerken zu 6 SSD raidZ1 ändern) und ihn deshalb temporär auf andere platten verschieben. Gibt es eine Möglichkeit das so hinzubekommen, dass die Snaps und Replikationsjobs hinterher normal weiterlaufen?

Kann man einfach die Dateisysteme in einen anderen pool verschieben, den alten Pool zerstören, Platten tauschen, neuen Pool wie den alten benennen und die Dateisysteme zurückschieben? Gehen die Snaps mit, wenn man das Dateisystem mit mc verschiebt? Die Replikationsjobs wären aufgrund der überschaubaren Datenmenge nicht das Problem (interessiert mich aber).
Danke.
 
Die Dateisysteme z.B. ssd/dateisystem1 (2,3 usw) lassen sich auf einen backup pool replizieren, ergibt backup/dateisystem1 (2,3, usw). Dann den neuen Z1 Pool unter altem Namen anlegen und aus dem Backupsystem zurück replizieren z.B. backup/dateisystem1 nach ssd, ergibt wieder ssd/dateisystem1. Falls man einen Pool umbenennen möchte, exportieren und beim Import einen anderen Namen vergeben.

Wenn der neue Pool den bisherigen Namen hat, laufen Autosnap Jobs weiter. Replikationsjobs benötigen gleiche Dateisystemnamen und ein gemeinsames Snappaar. Hat man das nicht mehr, das Zieldateisystem umbenennen z.B. dateisystem.bak. Dann kann man den Replikationsjob einfach starten und er wird eine initiale Replikation anlegen.

Prinzipiell kann man auch vorhandene Snaps bei einer Replikation mit übertragen. Die Option -I überträgt alle Snaps zwischen dem letzten Basissynap und dem neuen. Doe Option -R überträgt alle darunterliegenden Dateisysteme/Snaps.

Snaps gehören zum ZFS Dateisystem und sind readonly. Man kann die zwar per mc kopieren, das Ergebnis ist aber eine Datenkopie und kein Snap.
 
Hat hier schon Jemand Erfahrung mit den Fusion Pools / Metadata Caching gemacht ?
 
Ok, danke. Das heißt je Dateisystem zwei Replikationsjobs anlegen einmal zum Backup (ssd-->tank) und wieder zurück (tank-->ssd).
Dann in den echten Backups die Dateisysteme umbenennen, damit ich die ganzen (echten Backup-)Replikationsjobs nicht neu anlegen/planen muss.
 
Eine ZFS Replikation überträgt ein Dateisystem immer unter ein anderes. Ein rekursives ssd/* -> tank erzeugt tank/ssd/*. Wenn man die Struktur erhalten möchte muss man einzelne Dateisysteme wie ssd/fs -> tank replizieren um tank/fs zu erhalten bzw beim Rücktransfer entsprechend.
Beitrag automatisch zusammengeführt:

Hat hier schon Jemand Erfahrung mit den Fusion Pools / Metadata Caching gemacht ?

??
Was ist damit gemeint.
 
??
Was ist damit gemeint.

Bei der neuen TrueNAS / FreeNAS-Version wurde die Fusion-Pools "eingeführt".
Allgemein bei ZFS nennt man es glaub ich Special Allocation Class.

Zu einem Daten-Pool werden SSDs hinzugefügt und die Metadaten oder Daten mit kleiner Größe werden auf den SSDs abgelegt und große Daten werden wiederum auf den HDDs abgelegt.
 
Noch eine ergänzende Frage zum Thema Overprovisioning: Wie mache ich das praktisch?
Ich hatte es mir so vorgestellt das einmal mit der Herstellersoftware auf den SSD's einzurichten und mich danach nicht mehr darum kümmern zu müssen.
Samsung Magician scheint aber einfach nur die vorhandene Partition zu verkleinern (ohne vorhandene Partition mag es gar nicht). Klingt für mich irgendwie widersinnig.
Die Partitionierung wird doch vermutlich beim Initialisieren der Laufwerke im napp-it wieder gelöscht und Vorgaben für Partitionen macht man doch dann gar nicht explizit.
Ich hatte mir das eigentlich so vorgestellt, dass der geschützte Bereich im Betriebssystem gar nicht mehr angezeigt wird. Bekomme das also nur mittels hdparm oder hdat2 hin und ist das notwendig? Oder reicht die reine Reservierung freien Speichers, die bei den Pools ja i.d.R. sowieso vorgenommen wird? Aber dann ist der Teil aus Sicht der SSD ja vergeben...
 
Ich hatte mir das eigentlich so vorgestellt, dass der geschützte Bereich im Betriebssystem gar nicht mehr angezeigt wird. Bekomme das also nur mittels hdparm oder hdat2 hin und ist das notwendig? Oder reicht die reine Reservierung freien Speichers, die bei den Pools ja i.d.R. sowieso vorgenommen wird? Aber dann ist der Teil aus Sicht der SSD ja vergeben...

Wenn man bei einer neuen oder sicher gelöschten SSD per hdat2 eine "Host protected area/ HPA" anlegt, so meldet sich die SSD dem Betriebssystem gegenüber als kleinere Platte. Lediglich der SSD Controller hat Zugriff auf den geschützten Bereich und kann den nutzen um Schreibvorgänge zu optimieren oder belegte Bereiche im Hintergrund zusammenzufassen. Da sich die Datenmenge die geschrieben werden kann auf die Kapazität bezieht steigt die Langlebigkeit. Enterprise SSDs arbeiten im Prinzip nach diesem Verfahren.

Bei einer ZFS Reservierung sieht und nutzt das OS die ganze Platte. Das bringt also aus Sicht von iops bei dauerhaftem Schreiben oder Standhaftigkeit der SSD nichts da lediglich die freie Kapazitätsanzeige kleiner wird und eben nicht dem SSD Controller zur ausschließlichen Verfügung steht.
Beitrag automatisch zusammengeführt:

Bei der neuen TrueNAS / FreeNAS-Version wurde die Fusion-Pools "eingeführt".
Allgemein bei ZFS nennt man es glaub ich Special Allocation Class.

Zu einem Daten-Pool werden SSDs hinzugefügt und die Metadaten oder Daten mit kleiner Größe werden auf den SSDs abgelegt und große Daten werden wiederum auf den HDDs abgelegt.

Special vdevs ist ein von Intel entwickeltes Verfahren das seit ca 1,5 Jahren in Open-ZFS unter Linux/ Illumos (z.B. OmniOS) enthalten ist. Im Gegensatz zu normalen vdevs bei denen alle Schreibvorgänge auf allen vdevs gleichmäßig verteilt werden, landen hier nur spezielle Schreibvorgänge aufgrund besonderer Merkmale wie kleine Datenblöcke (small io), Metadaten, Dedupdaten oder komplette Dateisysteme die man durch ihre recsize Einstellung auf das special vdev zwingt.

Da die Daten tatsächlich auf dem special vdev gespeichert werden, handelt es sich auch nicht um einen Cache wie den rambasierten Arc Cache in dem ja die letzten Metadatenzugriffe gepuffert werden.

Ich habe vor fast genau einem Jahr mal ein paar Tests damit durchgeführt. Dateisysteme die ich auf das special vdev gezwungen habe waren so schnell wie ich es von dem vdev erwartet habe (Intel Optane) und damit viel schneller wie auf dem restlichen Pool. Wenn ich lediglich small io und Metadaten auf das special vdev gelegt habe war es in Benchmarks dagegen eher langsamer als ohne special vdev. Das liegt wohl daran dass bei Schreibvorgängen über den Ramcache große Datenblöcke in recsize auf den Pool geschreiben werden und nur kleine Restblöcke als small io auf dem special vdev landen. Metadaten werden bei aktuellen Aktionen wie einem Benchmark eh im noch schnelleren Arc Cache bereitstehen.

Insgesamt sehe ich special vdev als besonders sinnvoll, wenn
- einzelne Dateisysteme beschleunigt werden sollen
- Dedup aktiviert wird da damit das RAM Problem beseitigt ist
- Es sich um einen Filer handelt bei dem ständig neue Metadaten abgerufen werden. Ein Mailserver mit mehreren Millionen Mails und Hunderten Usern wäre da ein gutes Beispiel.

Für einen einfachen Home oder SoHo Fileserver bringt es eher nichts
 
Zuletzt bearbeitet:
Dank dir für die ausführliche Antwort, @gea :wink:
Genau das PDF hab ich auch schon gesehen.

Ist es aber nicht so dass man z.B. mit dem Befehl "special_small_blocks" den Pool die Möglichkeit gibt mehrere kleine Daten, die regulär auf HDDs geschrieben werden würden, auf SSDs abzulegen ?
Die Anzahl und Größe der Daten würde sich mit dem Befehl und dem Record-Size steuern lassen.



Ich werde demnächst sowieso einen neuen Pool anlegen müssen und würd gern mal die Funktion mit folgender Kombination testen:
- 6x WD Red 4TB (WD40EFRX / 5400 u/min) im Raid-z2
- 2x Intel DC S3700 (200GB / Power-Loss-Protection) im Mirror

Wäre die HW-Kombination mit dem "Special_Small_Blocks"-Feature keine gute Idee ?
 
Wenn man kleine Datenblöcke, sagen wir mal zwischen 4k (Minimum, physikalische Blocksize der Platten) und 64k auf eine Platte schreibt, so ist die Performance erheblich geringer als bei größeren Datenblöcken. Sieht man sehr gut z.B. bei einem Atto Benchmark. Das gilt es also nach Möglichkeit zu vermeiden oder eben die auf ein schnelleres vdev auszulagern, so wie es bei den vdev Typen special und Slog passiert.

Das Besondere an ZFS ist aber dass ZFS bis auf das Slog mit aktiviertem sync write kaum kleine Datenblöcke schreiben will. Alle Schreibaktionen werden im RAM-Schreibcache gesammelt und in Blöcken zu recsize aufgeteilt und geschrieben (default=128k). Nur ein Rest z.B. bei einer angesammelten Schreibaktion von 140k die 12k die über das 128k Raster hinausgehen. Daher sieht man bei einem einfachen Filer kaum Vorteile im Benchmark beim Schreiben. Beim Lesen kann es aber einen erheblichen Unterschied machen aber nur wenn die Daten nicht eh schon im noch schnelleren Arc Cache liegen und sie vorher auf das special vdev statt dem Pool gespeichert wurden (dies ist aber die Ausnahme wenn es nur durch small io passiert). Es kommt daher sehr auf den Anwendungsfall an.
 
Zuletzt bearbeitet:
Ich versuch einfach mal mein Glück - dank dir :)

Ist die Geschwindigkeit der Intel S3700 "ausreichend" für den Special VDEV ?
 
Die DC S3700 kann ca 500 MB/s sequentiell und 20-40k write iops (steady write). In meinen Versuchen habe ich die Optane 900 (2,5 GB/s sequentiell und 500k write iops) benutzt mit genannten Vor/Nachteilen.

Einfach mal probieren und ein paar Benchmarks fahren.
Mit dem "richtigen" Workload wird es was bringen, außerhalb ist es kontra produktiv.
 
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