Ich bin ein bisschen neu in ZFS, aber ich rufe einen neuen Speicherpool mit 12 physischen Laufwerken auf.

Mein aktueller Plan ist RAIDZ2 auf 10 Laufwerken und zwei Ersatzteilen.

Aber ich frage mich, ob ich mit RAIDZ3 auf allen 12 Laufwerken und ohne Ersatzteile nicht besser dran wäre.

Der Grund dafür ist, dass Ersatzteile im Grunde genommen eingeschaltete Leerlaufantriebe sind. Es kann Monate oder Jahre dauern, bis sie in Dienst gestellt werden, und zu diesem Zeitpunkt könnte ich feststellen, dass sie nicht lebensfähig waren. Wenn sie Teil eines RAID-Streifens wären, könnte ich zumindest eine Rückmeldung bekommen, ob sie gut sind oder nicht.

Ich habe nicht viel Diskussion darüber im Web gesehen. Hat jemand einen Rat?

Über heiße Ersatzteile

Hot-Spares werden auf einen bestimmten Pool festgelegt , können jedoch bei Fehlern automatisch an jedes vdev des Pools angehängt werden . Wenn Sie nur ein einziges vdev haben, das aus all Ihren Festplatten besteht, sollten Sie die Festplatten besser direkt einbinden (außer wenn Sie bereits über RAIDZ3 verfügen und noch Festplatten zur Verfügung haben).

Darüber hinaus nimmt das Resilvering Zeit in Anspruch und erfolgt in einem anfälligen (RAIDZ1, 2-Wege-Spiegel) oder leistungsreduzierten Zustand (RAIDZ2, RAIDZ3, 3-Wege-Spiegel), der nicht aufgetreten wäre, wenn Sie das Gerät bereits an das vdev angeschlossen hätten.

Grundsätzlich sind Hot Spares eine Sache für große Arrays. Wenn Sie in RAIDZ3 27 Festplatten haben, die in 3 vdevs von 9 Festplatten aufgeteilt sind, können Sie 3 Ersatzlaufwerke hinzufügen, um die Momente zu reduzieren, in denen "Es ist 2 Uhr morgens und 3 Festplatten sind abgestürzt, jetzt muss ich aufstehen und dieses Durcheinander beheben" (unter der Annahme einer 32) Antriebsschachtsystem). Kleinere Systeme haben normalerweise nicht genügend Festplatten, um überhaupt in die Situation "2+ vdevs und Z2 / Z3" zu gelangen. Eine Ausnahme wären Spiegel (z. B. 6 x 2), bei denen Abstürze für den Pool viel tödlicher sind (und Sie nicht über genügend Festplatten verfügen, um sie 6 x 3 zu machen).

Optimales Poollayout

Einige Ratschläge aus dem Nex7-Blog zum Pool-Layout:

• Verwenden Sie raidz1 nicht für Festplatten mit einer Größe von 1 TB oder mehr.
• Verwenden Sie für raidz1 nicht weniger als 3 Festplatten und nicht mehr als 7 Festplatten in jedem vdev (und sie sollten wiederum weniger als 1 TB groß sein, vorzugsweise weniger als 750 GB) (5 ist ein typischer Durchschnitt).
• Verwenden Sie für raidz2 nicht weniger als 6 Festplatten und nicht mehr als 10 Festplatten in jedem vdev (8 ist ein typischer Durchschnitt).
• Verwenden Sie für raidz3 nicht weniger als 7 Festplatten und nicht mehr als 15 Festplatten in jedem vdev (13 und 15 sind typische Durchschnittswerte).
• Spiegel trumpfen fast jedes Mal Raidz. Bei gleicher Anzahl von Laufwerken ist das IOPS-Potenzial eines Spiegelpools weitaus höher als bei jedem anderen Raidz-Pool. Der einzige Nachteil ist die Redundanz - raidz2 / 3 sind sicherer, aber viel langsamer. Der einzige Weg, der die Leistung nicht aus Sicherheitsgründen beeinträchtigt, sind 3-Wege-Spiegel, der jedoch eine Menge Platz einbüßt (aber ich habe gesehen, dass Kunden dies tun - wenn Ihre Umgebung dies erfordert, können sich die Kosten lohnen).
• Bei Festplatten mit einer Größe von> = 3 TB werden 3-Wege-Spiegel immer überzeugender.

Dies bedeutet in Ihrem Fall, dass Sie die folgenden Optionen haben:

1. 9 verwendbare Festplatten: (Z3 mit 9 + 3)
2. 8 Festplatten verwendbar: (Z2 mit 4 + 2) ++ (Z2 mit 4 + 2)
3. 5 verwendbare Festplatten: (2 Spiegel) * 5 ++ (Ersatzlaufwerk) * 2
4. 4 verwendbare Festplatten: (3-Spiegel) * 4

Ich würde sie (absteigend) wie folgt einstufen:

• In Bezug auf Nutzfläche: 1, 2, 3, 4
• In Bezug auf die Sicherheit: 1, 2/4, 3
• In Bezug auf die Geschwindigkeit: 4, 3, 2, 1
• In Bezug auf die Fähigkeit, Laufwerke zu erweitern / hinzuzufügen: 3, 4, 2, 1

Ich würde RAIDZ1 unabhängig von der Größe nicht verwenden, da Sie sie möglicherweise später durch größere Festplatten ersetzen möchten und dann die Probleme auftreten (was bedeutet, dass Sie auf diese Weise kein Upgrade durchführen möchten und möglicherweise nicht in der Lage sind, den Speicherplatz zu erweitern, ohne zusätzliche Festplatten hinzuzufügen ).

Ich habe gerade ein Test-ZFS-Setup verglichen, um genau diese Frage in Bezug auf die Leistung zu beantworten (auf einem Paar alter staubiger Server, die aus ihrer Asche wiederbelebt wurden).

Mein Setup ist:

• 2x Intel Xeon L5640 CPU bei 2,27 GHz (insgesamt: 12 Kerne; HT deaktiviert)

• 96 GB DDR3-RAM bei 1333 MHz

• Adaptec 5805Z-Controller, der alle Festplatten als JBODs exportiert (mit aktiviertem Schreibcache dank batteriegepuffertem NVRAM des Controllers)

• 12 x 15 kRPM 146 GB SAS-Festplatten (Seagate ST3146356SS)

• DRBD-Replikation pro Platte (Protokoll C) über IP-over-Infiniband (20 Gbit / s Mellanox MT25204)

• ZFS 0.7.6 unter Debian / Stretch

• zpool create -o ashift = 12 ... / dev / drbd {...} (Hinweis: DRBD arbeitet mit einer Replikationsgröße von 4 KB)

• zfs create -o recordsize = 128k -o atime = aus -o Komprimierung = aus -o Primärcache = Metadaten ... (die letzten beiden nur für Benchmarking-Zwecke)

Unterhalb der bonnie ++ - Ergebnisse für alle möglichen interessanten Kombinationen von RAIDz2 und RAIDz3 ( gemittelt über 5 Läufe von 12 synchronisierten bonnie ++ - Prozessen):

TEST: # data bandwidth
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 1024:1024k -n 0 -q -x 1 -y s &
      done
      # create/stat/delete operations
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 0 -n 128:0:0:16 -q -x 1 -y s &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=278273, RW=150845, RD=487315
 ops/s: SCr=132681, SDl=71022, RCr=133677, RDl=71723

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=276121, RW=158854, RD=480744
 ops/s: SCr=132864, SDl=71848, RCr=127962, RDl=71616

CASE: 1*RAIDz2(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=260164, RW=151531, RD=541470
 ops/s: SCr=137148, SDl=71804, RCr=137616, RDl=71360

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=269130, RW=184821, RD=672185
 ops/s: SCr=134619, SDl=75716, RCr=127364, RDl=74545

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=255257, RW=135808, RD=509976
 ops/s: SCr=136218, SDl=74684, RCr=130325, RDl=73915

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=379814, RW=225399, RD=586771
 ops/s: SCr=120843, SDl=69416, RCr=122889, RDl=65736

DATA: WR  = Sequential Write
      RW  = Sequential Rewrite
      RD  = Sequential Read
      SCr = Sequential Create
      SDl = Sequential Delete
      RCr = Random Create
      RDl = Random Delete

In Bezug auf Aufführungen:

• 2 * RAIDz2 (4d + 2p + 0s) ist der Gewinner für ausgewogene Lese- / Schreibleistungen

• 1 * RAIDz3 (8d + 3p + 1s) für maximale Leseleistung (ziemlich seltsam)

Wie diese Ergebnisse zu interpretieren / zu erklären sind; meine 1-Pennies:

• 8 Datenfestplatten teilen die 128k-Datensatzgröße genau auf. Dies könnte erklären (?), Warum sie immer 9 oder 10 Datenfestplatten übertreffen (vorausgesetzt, der Test wird mit einer Blockgröße von 1024k ausgeführt, die genau auf allen Festplatten ausgerichtet ist).

• Ich würde erwarten, dass RAIDz3 schlechter abschneidet als RAIDz2, aber der Fall 1 * RAIDz3 (8d + 3p + 1s) widerspricht dem sehr seltsam

• Die deutlich kleinere VDEV-Größe des 2 * RAIDz2-Falls (4d + 2p + 0s) könnte erklären (?), warum die Leistung beim Schreiben erheblich besser ist

BEARBEITEN 1

Als Antwort auf den Kommentar von @AndrewHenle finden Sie unten zusätzliche Benchmarks mit unterschiedlichen "Chunk" -Größen. Leider erlaubt bonnie ++ keine anderen Blockgrößen als die Potenz von 2; Also kehrte ich zu ( 5 gemittelte Läufe ) von dd : PS zurück: Denken Sie daran, dass der ZFS-Lesecache (ARC) deaktiviert ist

TEST: # WR: Sequential Write
      rm /zfs/.../dd.*
      for n in $(seq 1 <threads>); do
        dd if=/dev/zero of=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done
      # RD: Sequential Read
      for n in $(seq 1 <threads>); do
        dd of=/dev/null if=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  418.64   (n/a)  434.56  404.44  361.76
        RD  413.24   (n/a)  469.70  266.58   15.44

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  428.44  421.78  440.76  421.60  362.48
        RD  425.76  394.48  486.64  264.74   16.50

CASE: 1*RAIDz3(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  422.56  431.82  462.14  437.90  399.94
        RD  420.66  406.38  476.34  259.04   16.48

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  470.42   (n/a)  508.96  476.34  426.08
        RD  523.88   (n/a)  586.10  370.58   17.02

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  411.42   (n/a)  450.54  425.38  378.38
        RD  399.42   (n/a)  444.24  267.26   16.92

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  603.64   (n/a)  643.96  604.02  564.64
        RD  481.40   (n/a)  534.80  349.50   18.52

Was meine 1-Pennies betrifft:

• ZFS optimiert Schreibvorgänge offensichtlich intelligent genug (auch für Blockgrößen unterhalb der Datensatzgröße), und / oder (?) Der Adaptec-Controller - Cache ( nichtflüchtig , 512 MB) hilft in dieser Hinsicht erheblich

• Offensichtlich ist das Deaktivieren des ZFS-Lesecaches (ARC) für Blockgrößen nahe oder unterhalb der Datensatzgröße sehr nachteilig. und es scheint, dass der Adaptec-Controller-Cache (überraschenderweise?) nicht zum Lesen verwendet wird. Fazit: Das Deaktivieren von ARC für Benchmark-Zwecke ermöglicht Einblicke in "rohe, niedrige" Leistungen, ist jedoch für die Verwendung in der Produktion nicht ratsam (abgesehen von bestimmten Fällen wie einer selten verwendeten Bibliothek mit großen Dateien).

• Das Anpassen der Blockgröße an die Größe der VDEVs scheint keine positive Rolle zu spielen [FALSCHE ANNAHME; siehe BEARBEITEN 2]

BEARBEITEN 2

Informationen zu RAIDz und Blockgröße (Ashift) und Datensatzgröße (ZFS-Dateisystem):

• RAIDz füllt die zugrunde liegenden Geräte mit Daten- / Paritätsblöcken, deren Größe durch die Ashift-Größe bestimmt wird

• Datensätze (keine Blöcke) sind die "Basiseinheit" von Prüfsummen- und Copy-on-Write-Operationen

• Idealerweise sollte die Datensatzgröße des ZFS-Dateisystems durch die Menge (D) der Datenfestplatten in den VDEVs teilbar sein (da es sich jedoch um eine Zweierpotenz handeln muss, kann dies schwierig zu erreichen sein).

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWork

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWorkII

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSLogicalVsPhysicalBlockSizes

Und eine WARNUNG:

• Hot Spares funktionieren möglicherweise nur , wenn sie sehr sorgfältig konfiguriert und die Funktionalität getestet wurden

• https://www.reddit.com/r/zfs/comments/4z19zt/automatic_use_of_hot_spares_does_not_seem_to_work/

BOTTOM LINE (Bestätigung dessen, was bereits in anderen Antworten gesagt wurde)

• (Striping) kleinere VDEVs - mit weniger Datenfestplatten - bieten eine bessere Leistung als große; Das Berechnen / Überprüfen der Parität ist offensichtlich eine kostspielige Operation, die über die Menge der Datenplatten schlechter als linear wächst (vgl. 8d 2- 4d-Fälle).

• VDEVs gleicher Größe mit mehr Paritätsdatenträgern bieten eine bessere Leistung als weniger Paritätsdatenträger und Hot-Spare- Datenträger und bieten einen besseren Datenschutz

• Verwenden Sie Hot Spare (s), um die Bedenken "Wecken Sie mich nicht mitten in der Nacht auf" zu beheben, wenn Sie nach der Bevorzugung von Paritätsdatenträgern noch Festplatten haben [WARNUNG! siehe BEARBEITEN 2]

POST SCRIPTUM

Mein letztendlicher Anwendungsfall ist das Hosten einer (langfristigen) Zeitreihendatenbank (stetige mittelgroße Schreibvorgänge und möglicherweise sehr große sporadische Lesevorgänge), für die ich nur sehr wenig detaillierte Dokumentation zu den E / A-Mustern habe (abgesehen von einer "optimierten für") SSD "Empfehlung), ich persönlich werde mich für 1 * RAIDz2 (8d + 3p + 1s) entscheiden: maximale Sicherheit, etwas weniger Kapazität, (2.) beste Leistung

Meine Empfehlung lautet:

2 x 5-Platten-RAIDZ1 + zwei Ersatzteile

oder

RAIDZ1 + Ersatzteile mit 3 x 3 Festplatten

oder

RAID-Spiegel mit 10 Festplatten

oder 2 x RAIDZ2 mit 5 oder 6 Festplatten mit oder ohne Ersatzteile

Dies hängt vom verwendeten Festplattentyp ab. Wenn 7200 U / min über 2 TB fahren, gehen Sie in Richtung RAIDZ2. Wenn 2 TB und Benutzer, ist RAIDZ1 in Ordnung.