ZFS Layout 8 Disks

[Mrt12]

Hallo,
hat indirekt mit Proxmox zu tun, da ich den ZFS Pool ua. um Speichern der VM images benutzen möchte.

Ich baue bald einen neuen Proxmox + Storage Server auf. Er hat Platz für 8 Disks. Da das Budget endlich ist, und ich auch nicht gleich übertreiben möchte, würde ich wirklich gern mit den 8 Disks starten, ich kann ja den Pool über eine weitere PCIe HBA Karte immer noch expandieren.

Zur Diskussion stehen 8x 16TB Enterprise Disks. Ich hsbe mir nun überlegt, wie ich den Pool am besten auslege:

a) 2 vDevs zu je 4 Disks mit Raidz-1. Das hat den Vorteil, dass die IOPS höher sind, dass beim Resilvering von 1 vDev nur 3 weitere Disks beansprucht werden, dass ich den Pool kostengünstig expandieren könnte, indem ich nacheinander die 4 Disks eines vDev durch grössere ersetze. Ausserdem sollen die einzelnen vDevs ja nicht zu gross sein (weniger Disks).

b) Nur 1 vDev mit Raidz-2. Das hat eine bessere Verfügbarkeit, dafür müsste man 8 neue Disks kaufen, sollte man sie durch Grössere ersetzen wollen. Beim Resilvering werden alle 8 Disks beansprucht und die IOPS sind kleiner. Wennich später mittels HBA expandieren möchte, dann muss ich nur 4 weitere Disks kaufen, um ein zusätzliches vDev anlegen zu können.

Raidz3 oder Mirrors kommen eigentlich nicht in Frage, weil ich jetzt schon rund 40TB Platz brauche, dh. der neue Pool sollte vermutlich schon doppelt so gross sein, sonst bringt es nichts. Mit den beiden oben genannten Konfigurationen komme ich auf 96TB, das ist OK.

Backup mache ich im Moment wöchentlich, Restore habe ich auch schon getestet und von besonders wichtigen Sachen gibt es ein tägliches Backup.

Welche der Poolkonfigurationen ist anzustreben?

 

[Dunuin]

Zur Diskussion stehen 8x 16TB Enterprise Disks.

HDDs? Damit wirst du nicht wirklich Spaß haben als VM/LXC Storage. Da brauchst du ja primär IOPS Performance für all die OSs die da dann parallel laufen. Selbst mit 2x 4 Disk Raidz1 kommst du ja nur auf gut 200 IOPS. HDDs im Raidz1/2 wären meiner Meinung nach höchstens was für zusätzlichen Cold-Storage. Außerdem nicht vergessen, dass du mit Raidz1/2/3 die Blockgröße erheblich anheben musst um nicht massig Kapazität am Padding Overhead zu verlieren. Minimum 16K und für mehr Kapazität vielleicht sogar hoch auf 32/64/128K.
VMs würde ich schon wenigstens auf einem Enterprise SSD Mirror laufen lassen. Und wenn es nur gebrauchte alte SATA Enterprise SSDs sind.

 

[news]

Und bitte an die Maximale Auslastung eines ZFS Pools von 80% - 90% denken.
Ich setzte mir immer eine globales Quota von ca. 85% auf den Pool.

Zu @Dunuin mit einem Mirror oder RaidZ1 mit NVMe SSD oder SATA SSD für ein Spezial Device, wären die Meta Daten schon mal von den HDDs ausgelagert.
Dann hätte man noch die Möglichkeit ein Write Cache über Mirror oder RaidZ1 mit NVMe SSD oder SATA SSD an zu legen, und alle Schreiboperation würde dann mit NVMe oder SATA Geschwindigkeit ablaufen.

Könntest Du einen Mischbetrieb vorstellen für mehr Durchsatz?
Aus der Praxis eine US Unternehmens:
# https://youtu.be/0aM1iZJkOaA?feature=shared
# https://youtu.be/VkCM_DY-nwQ?feature=shared

 

[Mrt12]

Und bitte an die Maximale Auslastung eines ZFS Pools von 80% - 90% denken.
Ich setzte mir immer eine globales Quota von ca. 85% auf den Pool.

Zu @Dunuin mit einem Mirror oder RaidZ1 mit NVMe SSD oder SATA SSD für ein Spezial Device, wären die Meta Daten schon mal von den HDDs ausgelagert.
Dann hätte man noch die Möglichkeit ein Write Cache über Mirror oder RaidZ1 mit NVMe SSD oder SATA SSD an zu legen, und alle Schreiboperation würde dann mit NVMe oder SATA Geschwindigkeit ablaufen.

Könntest Du einen Mischbetrieb vorstellen für mehr Durchsatz?
Aus der Praxis eine US Unternehmens:
# https://youtu.be/0aM1iZJkOaA?feature=shared
# https://youtu.be/VkCM_DY-nwQ?feature=shared

klar Mischbetrieb wäre möglich.
Ich könnte auch 2 Pools laufen lassen und die HDDs nur für den Storage nutzen, dafür sollten sie ja OK sein. Stellt sich immer noch die Frage, welche config.

 

[Dunuin]

Also bei 16TB HDDs würde ich schon Minimum Raidz2 haben wollen und kein Raidz1. So ein Resilver kann Tage oder gar Wochen dauern wo dann die HDDs an ihre Grenzen gebracht werden. Nicht unwahrscheinlich, dass da dann durch die Belastung gleich noch eine weitere HDD ausfällt. Und selbst wenn die zweite HDD beim Resilvering nicht ausfällt, dann hast du über die ganze Zeit trotzdem keinen Bit Rot Schutz mehr und jede kleinste Datenkorruption ist dann nicht mehr reparabel.

Ich würde die 8 HDDs also in ein Raidz2 packen. Dazu dann 3x Enterprise SSD in einem Tripple-Mirror als Special Vdev. Da kannst du dann auch mit der special_small_blocks arbeiten und dann bestimmen, welche virtuellen Disks auf den SSDs und welche auf den HDDs landen sollen.
Wenn du die andere SSDs etwas schonen willst und bessere Performance bei DBs und Co haben willst gerne noch eine vierte Enterprise SSD rein als SLOG zum Auslagern von Sync Writes. Da dann am beste eine Intel Optane solange man die noch kaufen kann weil man nicht viel Kapazität braucht aber die Latenz so klein und Haltbarkeit so gut wie möglich sein sollte, weil Sync Writes wirklich NAND fressen.
Wenn man keine Lust auf die knappen 75% Kapazitätsverlust der Special Vdevs für die VMs hat, dann kann man auch 3 kleinere Enterprise SSDs rein für Metadaten nehmen und das special_small_blocks ignorieren und sich dann noch weitere Enterprise SSDs holen und die für VMs im normalen 2 Disk Mirror (oder 4+ Disks Striped Mirror) betreiben.
Ist dann die Frage ab wann dir die Ports und Laufwerksschächte ausgehen.

 

[Mrt12]

Also bei 16TB HDDs würde ich schon Minimum Raidz2 haben wollen und kein Raidz1. So ein Resilver kann Tage oder gar Wochen dauern wo dann die HDDs an ihre Grenzen gebracht werden. Nicht unwahrscheinlich, dass da dann durch die Belastung gleich noch eine weitere HDD ausfällt. Und selbst wenn die zweite HDD beim Resilvering nicht ausfällt, dann hast du über die ganze Zeit trotzdem keinen Bit Rot Schutz mehr und jede kleinste Datenkorruption ist dann nicht mehr reparabel.

Ich würde die 8 HDDs also in ein Raidz2 packen. Dazu dann 3x Enterprise SSD in einem Tripple-Mirror als Special Vdev. Da kannst du dann auch mit der special_small_blocks arbeiten und dann bestimmen, welche virtuellen Disks auf den SSDs und welche auf den HDDs landen sollen.
Wenn du die andere SSDs etwas schonen willst und bessere Performance bei DBs und Co haben willst gerne noch eine vierte Enterprise SSD rein als SLOG zum Auslagern von Sync Writes. Da dann am beste eine Intel Optane solange man die noch kaufen kann weil man nicht viel Kapazität braucht aber die Latenz so klein und Haltbarkeit so gut wie möglich sein sollte, weil Sync Writes wirklich NAND fressen.
Wenn man keine Lust auf die knappen 75% Kapazitätsverlust der Special Vdevs für die VMs hat, dann kann man auch 3 kleinere Enterprise SSDs rein für Metadaten nehmen und das special_small_blocks ignorieren und sich dann noch weitere Enterprise SSDs holen und die für VMs im normalen 2 Disk Mirror (oder 4+ Disks Striped Mirror) betreiben.
Ist dann die Frage ab wann dir die Ports und Laufwerksschächte ausgehen.

Hallo hallo,

ich habe den Pool noch nicht eingerichtet, aber ich habe in der Zwischenzeit viel gelesen. Offenbar verwenden viele leute lieber Mirrors als RAIDZ1/2. Ich habe auf einem anderen Proxmox Server, auf dem ich schon einige VMs laufen habe, einen neuen ZPOOL eingerichtet mit folgendem Layout:

    NAME                                                   STATE     READ WRITE CKSUM
    tank                                                   ONLINE       0     0     0
      mirror-0                                             ONLINE       0     0     0
        ata-TOSHIBA_MG05ACA800E_78IAK8ZEFUUD               ONLINE       0     0     0
        ata-ST10000VN0004-1ZD101_ZA223SB6                  ONLINE       0     0     0
      mirror-1                                             ONLINE       0     0     0
        ata-TOSHIBA_MG05ACA800E_78LBK8P9FUUD               ONLINE       0     0     0
        ata-TOSHIBA_MG05ACA800E_78LBK8PAFUUD               ONLINE       0     0     0
      mirror-2                                             ONLINE       0     0     0
        ata-TOSHIBA_MG05ACA800E_78LBK8P7FUUD               ONLINE       0     0     0
        ata-ST10000VN0004-1ZD101_ZA223S8V                  ONLINE       0     0     0
    cache
      nvme-Samsung_SSD_970_EVO_Plus_500GB_S4EVNX1W406978Z  ONLINE       0     0     0

und was soll ich sagen, das scheint mir auf den ersten Blick wirklich viel besser zu sein:

a) expandierbarkeit: ich kann jederzeit 2 Disks hinzufügen, um die Kapazität zu erhöhen.
b) Speed: IOPS und Bandwidth sind phantastisch. Man merkt es sogleich an der Performance der VMs; ich habe eine Windows VM, die gefühlt deutlich flüssiger läuft.
c) Resilver Speed: läuft auch viel schneller.

Klar hat man das Problem, dass wenn von einem Mirror eine Disk abraucht, man keinen zweiten Ausfall in dem selben Mirror tolerieren kann, aber man hat ja auch ein Backup.

Was denkst du von einem solchen Setup. Ich habe mir überlegt, dass ich mit meinen 8 Disks auch sowas machen könnte, dann habe ich am Ende halt nur 64 TB und muss bald expandieren, aber das Expandieren ist ja kein Problem.


P.S. die Samsung SSD habe ich als Test hinzugefügt, ob ein L2 Cache was bringt bei meiner Workload. Und was soll ich sagen: super! zu gewissen Zeitpunkten liest er ausschliesslich von der SSD, mit einigen tausend IOPs, während die Harddisks in dieser Zeit gar keine IOPS haben. Also scheint der Cache für meine spezifische Workload in der Tat etwas zu bringen. Demnach werde ich die Samsung SSD durch eine echte Datacenter SSD ersetzen, aber erst mal schaue ich, wie schnell die Disk abnutzt.

 

[Dunuin]

und was soll ich sagen, das scheint mir auf den ersten Blick wirklich viel besser zu sein:

a) expandierbarkeit: ich kann jederzeit 2 Disks hinzufügen, um die Kapazität zu erhöhen.
b) Speed: IOPS und Bandwidth sind phantastisch. Man merkt es sogleich an der Performance der VMs; ich habe eine Windows VM, die gefühlt deutlich flüssiger läuft.
c) Resilver Speed: läuft auch viel schneller.

Klar hat man das Problem, dass wenn von einem Mirror eine Disk abraucht, man keinen zweiten Ausfall in dem selben Mirror tolerieren kann, aber man hat ja auch ein Backup.

Was denkst du von einem solchen Setup. Ich habe mir überlegt, dass ich mit meinen 8 Disks auch sowas machen könnte, dann habe ich am Ende halt nur 64 TB und muss bald expandieren, aber das Expandieren ist ja kein Problem.

Wenn das im Budget ist (braucht man ja mehr Disks für gleiche Kapazität und ggf. größeren Server mit mehr Ports/Einschüben) würde ich auch ein Striped Mirror bevorzugen. Im übrigen kann man auch Tripple-Mirrors stripen, dann dürften auch je 2 Disks pro Mirror ausfallen, aber dann brauchst halt schon 12x 16TB Disks für deine 64TB. Und die 64TB sind ja auch nicht voll nutzbar. So 10-20% sollten ja immer frei bleiben wegen Fragmentation/Performance und wenn man Snapshots nutzen will für Ransomware Protection/Versionierung sollte man einen guten Teil der Kapazität auch dafür noch einplanen. Bei mir wären von den 64TB dann in der Praxis nur so ca die hälfte nutzbar.

 

[Mrt12]

Wenn das im Budget ist (braucht man ja mehr Disks für gleiche Kapazität und ggf. größeren Server mit mehr Ports/Einschüben) würde ich auch ein Striped Mirror bevorzugen. Im übrigen kann man auch Tripple-Mirrors stripen, dann dürften auch je 2 Disks pro Mirror ausfallen, aber dann brauchst halt schon 12x 16TB Disks für deine 64TB. Und die 64TB sind ja auch nicht voll nutzbar. So 10-20% sollten ja immer frei bleiben wegen Fragmentation/Performance und wenn man Snapshots nutzen will für Ransomware Protection/Versionierung sollte man einen guten Teil der Kapazität auch dafür noch einplanen. Bei mir wären von den 64TB dann in der Praxis nur so ca die hälfte nutzbar.

Ja, die effektiv nutzbare Kapazität ist wirklich ein grosser Nachteil, aber da hier die Expandierbarkeit viel besser ist, kann ich mit 64 TB starten - die werden im Lauf des nächsten Jahres voll, und dann kann ich per Ende Jahr im Budget ein zusätzliches Chassis für Disks einplanen.

Hast du selber 3fach Mirrors? das ist schon cool, weil dir dann wirklich in jedem Mirror bis zu 2 Disks abrauchen dürfen, aber die Speichernutzung ist so schlecht, dass mich das extrem abschreckt, ich weiss aber auch noch nicht sicher, wie klug 2x Mirrors sind. Vielleicht in jedem Mirror 2 Disks unterschiedlicher Hersteller oder unterschiedlichen Alters mischen?

Theoretisch darf ja bei meinem oben dargestellten Pool bis zu 3 Disks abrauchen, aber nur, wenn sie nicht im gleichen Mirror sind. Es ist also sicherlich ein wenig schlechter von der Zuverlässigkeit her, als RAIDZ2, aber deutlich besser als RAIDZ1.




P.S.: also die Performance ist wirklich um Welten besser, als bei RAIDZ2, was ich vorher in Betrieb hatte. Auch der Scrub läuft um Faktoren schneller; wenn es vorher einen halben Tag dauerte, habe ich nun innert 4 Stunden gescrubbt. Das ist ziemlich cool.

 

[Dunuin]

Hast du selber 3fach Mirrors?

Nur für die Special Devices damit das zum Raidz2 passt.

Vielleicht in jedem Mirror 2 Disks unterschiedlicher Hersteller oder unterschiedlichen Alters mischen?

Ja, das macht Sinn sofern die Performance relativ identisch ist. Ein weiterer Vorteil von einem Striped Mirror ist, dass du alle ersten Disks eines Mirrors an einen HBA hängen kannst und die zweite Disks des Mirrors an einen anderen HBA. Raucht dir dann ein HBA ab (das hatte ich gerade erst...) dann bleibt der Pool wenigstens noch funktionsfähig.

 

[Mrt12]

Nur für die Special Devices damit das zum Raidz2 passt.


Ja, das macht Sinn sofern die Performance relativ identisch ist. Ein weiterer Vorteil von einem Striped Mirror ist, dass du alle ersten Disks eines Mirrors an einen HBA hängen kannst und die zweite Disks des Mirrors an einen anderen HBA. Raucht dir dann ein HBA ab (das hatte ich gerade erst...) dann bleibt der Pool wenigstens noch funktionsfähig.

ok du hast also Raidz2?

 

[Mrt12]

Hallo nochmal,
noch eine Frage. Ich habe ja meinen zpool aufgebaut und mal testweise eine consumer SSD rein gemacht, für Cache. Und nun auch eine für SLOG, nur um mal zu schauen, wie viel ich gewinne. Ich wollte das mal in aller Ruhe testen.
Jetzt habe ich ein wenig mit dem SLOG herum gepröbelt, und im Output von "zdb" sehe ich dann Zeug wie

children[13]:
            type: 'hole'
            id: 13
            guid: 0
            whole_disk: 0
            metaslab_array: 0
            metaslab_shift: 0
            ashift: 0
            asize: 0
            is_log: 0
            is_hole: 1

ist das ein Problem, bzw. kann ich die "holes" irgendwie wieder loswerden? ich denke, das ist wirklich vom herum experimentieren mit dem SLOG device?