ZFS Layout

Mrt12

Active Member
May 19, 2019
115
9
38
44
Moin moin

ich hatte vor einiger Zeit schon mal einen Thread, wo es um einen Samba File Server ging.
Mittlerweile konnte ich diese Probleme alle lösen und habe meinen Storage Server in Betrieb genommen.
Weil das Budget begrenzt war, habe ich nur 8x 16TB Disks kaufen können. Da ich in der Vergangenheit schlechte Erfahrungen mit der Performance mit RAIDZ2 gemacht habe, und auch schon die Erfahrung sammeln durfte, wie lange das Resilvern dauerte nachdem eine Disk ausgefallen war, habe ich meinen neuen Pool mit den 8x 16 TB aufgebaut, jeweils 2 Disks als Mirror. Also 4x 2 Disk Mirrors. Auch die Expandierbarkeit, welche ein wichtiges Kriterium ist, scheint mir mit den Mirrors besser zu sein. Ich muss nur 2 Disks hinzufügen, und schon kann ich expandieren. Auch sollte der Speed besser sein, wenn ich viele kleine vdevs habe; denn mein Netzwerk hat 50 GBit Glasfaser.
Ich werde später, wenn es das Budget wieder erlaubt, einen zusätzlichen JBOD Disk Shelf kaufen, wo ich weitere 8 Disks einfügen kann und dann meinen bestehenden Mirror so aufteilen, dass die eine Hälfte im einen Gehäuse, und die andere Hälfte im anderen Gehäuse ist. So könnte ein HBA oder der Disk Shelf komplett ausfallen, und alle Daten wären immer noch da.

Backups werden natürlich gemacht auf einen externen Tape Archiv.

Im Moment ist es in der Tat leider so, dass alle Disk-Schächte voll sind, ich kann also keine weiteren Disks hinzufügen. Wenn ich den JBOD dran habe, geht das wieder. Die Idee ist eigentlich, die Disks zu ersetzen, bevor sie ausfallen, und da würde ich bei einem 2x Mirror dann einfach eine 3. Disk hinzufügen, den Resilver abwarten, und die zu ersetzende Disk dann entfernen. Im Moment könnte ich das nicht, ich müsste eine Disk, die droht auszufallen, erst komplett entfernen, und dann ersetzen.

Gescrubbt wird wöchentlich, und SMART Daten täglich angeschaut. Die Disks sind neu und vom Lieferanten einem "Burn in" Test unterzogen worden, daher rechne ich eigentlich nicht damit, dass sofort eine ausfällt.

Die Resilver-Zeit dürfte auch OK sein: wenn die Disk 200MB/sec lesen kann, dauert das Wiederherstellen einer 16TB Disk rund 22 Stunden. Das gilt beim Mirror. Wenn ich aber RaidZ nehmen würde, dann müssten ja, um 1 Disk wiederherzustellen, alle anderen 7 Disks gelesen werden, dh. es müssten 7x 16 TB gelesen werden, um 16 TB zu rekonstruieren, d.h. es würde rund 7 Tage für den Resilver brauchen. Der Mirror ist besser, nicht?


Was ist von diesem Setup zu halten? war das dumm? hätte ich doch RAIDZ2 nehmen sollen? mit 8 Disks hätte das natürlich schon mehr Platz gebracht, aber eben auch weniger Performance.
 
Last edited:
Mit einem SSD Special Device könnte das schon mit RaidZ gehen. Wenn du nur HDDs hast, würde ich auch immer Mirror empfehlen.
Wenn du schnelleren Rebuild haben willst, könnte ein ZFS dRaid auch interessant sein. Aber auch da würde ich immer ein SSD Special Device davor packen.
An deinem Setup würde ich jetzt nichts ändern.
 
  • Like
Reactions: Mrt12
super, ich bin froh, dass du auch zu dem Mirror raten würdest.
Ich habe vorher wochenlang viel gelesen und recherchiert, bevor ich das eingerichtet habe, und der Tenor scheint bei HDDs eindeutig zu Mirrors zu raten.
Den Special Device habe ich noch nie ausprobiert und war mir ein wenig zu fancy. Wenn das Special Device stirbt, dann ist der ganze Pool weg, darum schreckt mich das ein wenig ab..... Aber was ich gemacht habe, ich habe kürzlich 2 SSDs als Cache hinzugefügt, und "l2arc_mfuonly=1" gesetzt. Bei diesem File Server scheint es wirklich etwas zu bringen; es gibt einige Ordner, wo bis zu 80000 Dateien drin sind, wenn man diese öffnet, sieht man im iostat gut, dass er praktisch nicht mehr auf die Disks zugreift sondern fast nur noch aus den SSD Caches.
Da ich 128GB RAM habe und recordsize=1M gesetzt habe, habe ich nicht so viel Angst, dass mir der SSD Cache zu viel RAM frisst. Und die Hit Rate ist meiner Meinung nach OK, ca. 60%, der Cache scheint also etwas zu bringen.

Vielen Dank für den Kommentar!
 
Die Resilver-Zeit dürfte auch OK sein: wenn die Disk 200MB/sec lesen kann, dauert das Wiederherstellen einer 16TB Disk rund 22 Stunden. Das gilt beim Mirror. Wenn ich aber RaidZ nehmen würde, dann müssten ja, um 1 Disk wiederherzustellen, alle anderen 7 Disks gelesen werden, dh. es müssten 7x 16 TB gelesen werden, um 16 TB zu rekonstruieren, d.h. es würde rund 7 Tage für den Resilver brauchen.
Wieso das denn? 7 Disks lesen ja nicht mit zusammen 200MB/s, sondern mit 7x200MB/s.

hätte ich doch RAIDZ2 nehmen sollen? mit 8 Disks hätte das natürlich schon mehr Platz gebracht, aber eben auch weniger Performance.
Andererseits dürfen bei raidz2 beliebige zwei Disks ausfallen. Bei Mirror hast Du die Arschkarte, wenn es die falschen zwei sind.
 
Wieso das denn? 7 Disks lesen ja nicht mit zusammen 200MB/s, sondern mit 7x200MB/s.


Andererseits dürfen bei raidz2 beliebige zwei Disks ausfallen. Bei Mirror hast Du die Arschkarte, wenn es die falschen zwei sind.

hmm stimmt auch wieder. Allerdings muss mit den ausgelesenen Daten und der Parität ja noch die Rekonstruktion der Daten berechnet werden. Es wird also sicher langsamer sein.

Ich fand die Erklärungen hier eigentlich ganz einleuchtend:

https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

und da ich früher schon mal ein RAIDZ2 mit 4x8TB in Betrieb hatte und die Performance sehr schlecht war, finde ich den Mirror schon sehr angenehm. Ist er wirklich so schlecht?

Beim RAIDZ Rebuild muss JEDE Disk komlett ausgelesen werden, um die ausgefallene Disk zu ersetzen.
Beim Mirror muss nur die andere Mirrorhälfte ausgelesen werden, d.h. die restlichen Disks sind absolut nicht betroffen.
Klar, hier liegt der Stress genau auf der einzigen Disk, die die noch verbleibende Kopie der Daten hat, aber beim RAIDZ2 wäre der Stress ja der selbe...
 
hmm stimmt auch wieder. Allerdings muss mit den ausgelesenen Daten und der Parität ja noch die Rekonstruktion der Daten berechnet werden. Es wird also sicher langsamer sein.

Ich fand die Erklärungen hier eigentlich ganz einleuchtend:

https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/

und da ich früher schon mal ein RAIDZ2 mit 4x8TB in Betrieb hatte und die Performance sehr schlecht war, finde ich den Mirror schon sehr angenehm. Ist er wirklich so schlecht?

Beim RAIDZ Rebuild muss JEDE Disk komlett ausgelesen werden, um die ausgefallene Disk zu ersetzen.
Beim Mirror muss nur die andere Mirrorhälfte ausgelesen werden, d.h. die restlichen Disks sind absolut nicht betroffen.
Klar, hier liegt der Stress genau auf der einzigen Disk, die die noch verbleibende Kopie der Daten hat, aber beim RAIDZ2 wäre der Stress ja der selbe...
Die Dauer ist in etwa gleich, aber ja bei RaidZ wird in Summe mehr gelesen.
Das lässt sich nur mit dRaid verbessern.
Aber während eines Resilver kannst du ein RaidZ mit nur HDDs fast gar nicht benutzen. Das wird dann extrem langsam.
 
Wenn das Special Device stirbt, dann ist der ganze Pool weg, darum schreckt mich das ein wenig ab.....
Deshalb spiegelt man die ja auch einmal oder sogar mehrfach. Spiegelst du 4 Stück ist das sicherer als dein Raidz2 bei den HDDs.

Bei Mirror hast Du die Arschkarte, wenn es die falschen zwei sind.
Außer du machst Striped 3-Disk Mirrors. Dann dürfen 2 beliebige Disks aus jedem Mirror ausfallen. Dann ist es wieder sicherer als ein Raidz2...ok... und nicht gerade Speicherplatzeffizient ;)
 
war denn jetzt mein Mirror so dumm oder ist es akzeptabel?
also mit der Performance bin ich sehr zufrieden, aber die 50% Verlust tun schon ein bisschen weh. Wenn ich den Server mit dem externen SAS JBOD erweitert habe, könnte ich auch 3fach Mirrors fahren, aber das wäre schon nicht so cool....
über 25 GBit hätte ich im Notfall die wichtigsten Daten in ein paar Stunden wiederhergestellt.

Meine Kriterien, warum ich den Mirror bevorzugt habe, waren einerseits die Argumente aus dem verlinkten Artikel, und andererseits die einfache erweiterbarkeit - mit 2 zusätzlichen Disks kann ich bereits expandieren, und das wird auf jeden Fall wichtig sein.
 
Wäre es eigentlich klug, die beiden Samsung SSDs

ata-SAMSUNG_MZ7L3240HCHQ-00A07

die ich noch habe, als Special Device Mirror zu benutzen, oder ist es als Cache besser?
Ich habe mit zdb herausgefunden, dass die Metadaten auf die SSDs passen würden, es sind "nur" 150GB Metadaten.
Die Frage ist, ob die Samsung PM893 eine gute SSD für den Special Device ist. Ich habe hier gelesen, dass sie zu Ausfällen neigt.

Ausserdem ist noch eine Frage, wie ich die Metadaten nach dem erstellen des Pools auf die SSD bekomme. Ich habe nicht genug Speicher, um die Daten wegzukopieren.
 
Ausserdem ist noch eine Frage, wie ich die Metadaten nach dem erstellen des Pools auf die SSD bekomme. Ich habe nicht genug Speicher, um die Daten wegzukopieren.
Da musst du schon die Daten neu schreiben. Falls deine Daten als Dateien in Datasets liegen, reicht es dann aber z.B. ein neues Dataset anzulegen und dann alle Dateien, Stück für Stück, vom einen Dataset ins andere zu kopieren. Guck nur das du dann keine Snapshots hast und du gelegendlich mal ein zpool trim anwirfst, dass ZFS auch den Platz der verschoben Dateien wieder freigibt.
 
Da musst du schon die Daten neu schreiben. Falls deine Daten als Dateien in Datasets liegen, reicht es dann aber z.B. ein neues Dataset anzulegen und dann alle Dateien, Stück für Stück, vom einen Dataset ins andere zu kopieren. Guck nur das du dann keine Snapshots hast und du gelegendlich mal ein zpool trim anwirfst, dass ZFS auch den Platz der verschoben Dateien wieder freigibt.
ja das habe ich befürchtet.

Jetzt gibt es ein Problem:
ich habe bereits ein Backup der Daten gemacht (auf Tape). Wenn ich die Dateien nun weg kopiere, dann ist die "ctime" anders, sprich, wenn ich dann erneut ein Backup laufen lasse, denkt er, die Datei ist neu und nimmt sie ins inkrementelle Backup auf. Was leider unschön ist.
Kann ich die ctime irgendwie mit kopieren? mit "cp --preserve=all" geht es jedenfalls nicht.

Und: eignet sich die Samsung PM893 als Special Device? zumindest von der TBW her schon, sie kann 1 DWPD ab. Das wäre ja OK. Aber ich habe hier im Forum gelesen, dass andere User mit der PM893 Probleme hatten unter Proxmox, dass die ZFS Pools teilweise degradierten, weil die PM893 komische Fehler erzeugte.
 
Das Problem war der LSI HBA. Oder besser die Firmware von dem Modell.
super Sache.
Ich habe die PM983 SSDs als special hinzugefügt. Rennt. Hab eines der kleineren Datasets mit zfs send und receive kopiert, und die Kopie dann umbenannt. Nun liegen die Metadaten auf den SSDs. Ich hätte das wirklich von Beginn an machen sollen - die Dateisuche läuft unglaubich viel schneller. Obwohl es nur recht poplige SATA SSDs sind.

Nun habe ich nur noch das "grosse" Dataset. Dieses umfasst 29TB, in meinem Pool sind noch 26TB frei. Das kann ich leider nicht in-place kopieren :-( könnte man mit irgend einem Trick das Dataset umkopieren?

Ich könnte zwar die Files alle in-place mit "cp" Kopieren und dann umbenennen, aber die Backup Software merkt das und denkt dann, die Dateien sind neu (weil der Creation Date geändert ist) und macht dann ein Backup von der Datei.

Kann ich irgendwie anders noch erzwingen, dass die Metadaten von Dateien neu geschrieben werden? wie ist es eigentlich, wenn z.B. auf die Dateien zugegriffen wird und z.B. die Modification Time geändert wird. Das muss dann ja auch in den Metadaten aktualisiert werden. Wandern dann die kompletten Metadaten irgendwann Stück für Stück auf die SSD, oder bleiben die Metadaten auf den HDDs, und nur die Modification Time wird auf der SSD geschrieben? weil, im Normalfall wird ZFS ja nur das neu schreiben, was sich wirklich ändert.

Auf dem grossen Dataset sind rund 30M Dateien. Da der Speed durch das special device in der Tat so viel besser ist, könnte man da durchaus profitieren.
 
Mit was schreibst du denn auf Tape?
Ich habe dieses Problem bisher auf Linux noch nicht gehabt, aber unter Windows habe ich das immer mit Robocopy erschlagen, da konnte man Daten verschieben und kopieren inklusive aller Flags. Das hat jedes Backupprogramm gefressen. Unter Linux gibts garantiert auch eine identische Möglichkeit.
 
Mit was schreibst du denn auf Tape?
Ich habe dieses Problem bisher auf Linux noch nicht gehabt, aber unter Windows habe ich das immer mit Robocopy erschlagen, da konnte man Daten verschieben und kopieren inklusive aller Flags. Das hat jedes Backupprogramm gefressen. Unter Linux gibts garantiert auch eine identische Möglichkeit.

eigentlich würde ich auch erwarten, dass es unter Linux möglich sein müsste.

Wir haben einen IBM Tivoli Storage Protect. Auf den kann ich mit dem "dsmc" Client zugreifen und die Backups hochladen.
Ich habe mal testweise ein paar Dateien kopiert, mit "cp --preserve=all", damit wird die ACL und alle Attribute beibehalten. Aber irgendwie merkt der "dsmc" dennoch, dass die Datei geändert wurde; offenbar merkt er es anhand der "creation time", die sich ja nicht ändern lässt.

Sprich: wenn ich die Dateien in-place neu schreibe, meint der Backup Client fälschlicherweise, dass sie geändert wurden, und macht ein Backup. Obwohl nur die "ctime" anders ist.
Das bedeutet dann, dass er mit 30 Millionen Files neu aufs Tape ballern würde, obwohl absolut nichts geändert wurde :-D ein Vollbackup dauert 85 Stunden.
 
Das ist einer der Gründe warum ich kein Tape mehr mache bei meinen Kunden. Wie schnell ist denn ein Restore?
Das ist in der Regel, das HAuptproblem, dass niemand so lange auf einen Restore Warten kann/möchte.

Das Tape ist über 10 GBit angebunden und hat einen vorgelagerten SSD Puffer. Der Speed wäre also ansich eigentlich OK, aber die Bandbreite teilen sich halt u.U. mehrere Nutzer.
Für den "heissen" Dataset, wo die Projekte liegen und die User täglich damit arbeiten, dauert ein Vollbackup ca. 2 Stunden, die inkrementellen Backups sind in unter 2 Minuten gemacht. Dort habe ich auch eine Replikation auf einen 2. Server eingerichtet; alle 15 Minuten wird mit zfs send / receive der Dataset incl. Snapshots repliziert; sollte etwas passieren, dann starte ich den Samba Container einfach auf dem 2. Server. Dieses Dataset ist aber auch recht klein, 4 TB.
Aber auf dem 2. Server habe ich nicht genug Disk Slots, um genügend Platz zu schaffen, den 2. grossen Dataset auch zu replizieren. Deshalb liegt der nur einmalig auf dem grossen Server vor und einmal pro Monat wird gesichert. Diese Daten sind nicht so kritisch, weil man sie, im Falle eines Totalverlusts, wieder berechnen könnte (Finite Elemente Simulationen, prozessierte Messdaten) - darum ist es auch akzeptabel, wenn der Restore länger dauert. Man greift da auch nicht täglich drauf zu.

Wenn es also wirklich nicht möglich sein sollte, ZFS irgendwie dazu zu bewegen, die Metadaten neu zu schreiben, dann ist das halt so. Meiner Meinung nach ist das ein recht grosses Design-Manko, dass man nicht die Daten in-place wieder neu schreiben lassen oder manuell die Metadaten hin- und her schieben lassen kann. Das selbe Problem hat man ja auch, wenn man die Kompression oder so ändert. Einen kompletten Dataset neu zu schreiben oder gar den kompletten Pool zerstören und neu kreieren zu müssen, ist in einigen Fällen einfach nicht akzeptabel. Jetzt kann man sagen OK, man müsste halt den Pool gleich von Anfang an richtig designen :-D was ein gutes Argument ist, aber man weiss ja vielleicht nicht immer von Anfang an, ob zstd-3 reicht oder ob man auch auf zstd-10 gehen könnte oder ob ein special device jetzt einen effektiven Nutzen bringt oder nicht....
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!