ZFS Raid-Z Performance

lockdoc

Well-Known Member
Hallo,

ich habe letztens irgendwo (finde leider den link nicht mehr) gelesen, dass man beim Einrichten eines ZFS Raid-Z genau darauf achten sollte, wieviel Platten man in den Raid einhaengt und ggf. mehrere Raids dann in den Tank haengen.

Irgendwie hat es was mit der 512 Block Groesse zu tun.

Also bei 6 Platten gaebe es ja die Kombination (2 raids)
Code:
 NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1    ONLINE       0     0     0
            ad0  ONLINE       0     0     0
            ad1  ONLINE       0     0     0
            ad2  ONLINE       0     0     0
          raidz1    ONLINE       0     0     0
            ad3  ONLINE       0     0     0
            ad4  ONLINE       0     0     0
            ad5  ONLINE       0     0     0
und nur ein raid
Code:
 NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1    ONLINE       0     0     0
            ad0  ONLINE       0     0     0
            ad1  ONLINE       0     0     0
            ad2  ONLINE       0     0     0
            ad3  ONLINE       0     0     0
            ad4  ONLINE       0     0     0
            ad5  ONLINE       0     0     0
Des weiteren koennte man ja dann auch noch ein raid-z(2) machen


Hat da Jemand genauere Informationen zu, was in dieser Situation am besten fuer schreib/lese Performance waere?

LG
lockdoc
 

lockdoc

Well-Known Member
Also von hier:
http://www.solarisinternals.com/wik...2.2C_RAIDZ-3.2C_or_a_Mirrored_Storage_Pool.3F
kann ich folgendes rauslesen
The recommended number of disks per group is between 3 and 9. If you have more disks, use multiple groups.

Demnach wuerden beide meiner oberen Raid-Z(1) Beispiele empfohlen werden. Die Frage ist allerdings wo ist dort der Performance Unterschied.

Was genau verstehe ich denn unter "random i/o", also Welche Operationen sind davon betroffen.

Eventuell wuerde ich auch zu einem RAID-10 tendieren, falls dies unter ZFS wesentlich performanter als Raid-Z ist.
 

KobRheTilla

used register
Was genau verstehe ich denn unter "random i/o", also Welche Operationen sind davon betroffen.

Die Frage ist, was du willst/brauchst. Wenn du viele zufällige Zugriffe auf eher kleinere Dateien (also wenig sequenziell) hast, dann sind mehrere 2/3-way mirrors besser. Wenn du eher sequentielle Zugriffe hast, dann ist wohl ein RAIDZ angemessen.

Rob
 

lockdoc

Well-Known Member
Die meisten Lesezugriffe werden dann wohlsequentiell sein, also tendenziell Raid-Z.

Wie sieht der Unterschied bei den Schreibzugriffen aus?

Aber es steht noch die Ausgangsfrage offen, ob man bei beispielsweise 6 Platten 2 Raid-Z(1) nimmt oder daraus ein einziges macht
 

KobRheTilla

used register
Aber es steht noch die Ausgangsfrage offen, ob man bei beispielsweise 6 Platten 2 Raid-Z(1) nimmt oder daraus ein einziges macht

Nimmst du zweimal RAIDz, können zwei Platten ausfallen (jeweils eine pro RAIDz), ansonsten nur eine insgesamt. Dafür hast du aber "Gesamtkapazität=4 Platten". Außerdem macht ZFS automatisch eine Art load balancing bei mehreren Komponenten pro Pool (hier: mehrere RAIDz) in Form eines automatischen stripings. Um nun wirklich zu wissen, was für dich besser ist, musst du benchmarks machen (bonnie++ z.B.).

Rob
 

oenone

Well-Known Member
6 ist doch noch innerhalb von "between 3 and 9", um genau zu sein, es ist genau die Mitte.. Wie kommst du darauf, dass demnach zwei RaidZs empfohlen werden? Für die geringe Anzahl an Platten reicht ein einziges RaidZ.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Wenn es um Performance geht, wird ein extra Cache-Device und / oder Log-Device sicher wesentlich mehr bringen, als sich um die Anzahl der Platten Gedanken zu machen. Man muss schließlich beachten, dass ZFS extrem aggressiv cached und viele Operationen überhaupt nicht oder nur mit Verzögerung auf die eigentlichen Platten durchschlagen. Gerade wenn man viele zufällige Leseoprationen hat, kann schon ein billig(st)er USB-Stick etwas bringen: http://www.leidinger.net/blog/2010/02/10/making-zfs-faster/ Eine kleine SSD bringt noch etliches mehr, da sie schneller ist und besser angebunden...
 

Crest

rm -rf /*
Teammitglied
Dennoch ein RAID-Z VDEV hat soviele IOPS wie die langsamste Platte im VDEV. Kommt es auf IOPS an gibt es also gute Gründe mehrere RAID-Z VDEVs oder Mirrors im selben Pool zu verwenden.

Ein (hoffentlich gemirrortes) ZIL auf SSDs kann die erreichbaren Transaktionen pro Sekunde massiv erhöhen.
Die meisten Reads können mit genug RAM gecached werden oder zu mindestens auf einer schnell lesbaren SSD als L2ARC gecached werden.
 

lockdoc

Well-Known Member
Wenn ich jetzt ca. 4-6 HDD's als Storage, 1 SSD fuer den Cache und ca. 6-8GB RAM zur Verfuegung haette, welcher Aufbau unter ZFS waere der performanteste fuer sequentiell und welcher fuer random, wobei ich mindestens eine Festplatte ausfallen lassen koennte?
 

KobRheTilla

used register
Wenn ich jetzt ca. 4-6 HDD's als Storage, 1 SSD fuer den Cache und ca. 6-8GB RAM zur Verfuegung haette, welcher Aufbau unter ZFS waere der performanteste fuer sequentiell und welcher fuer random, wobei ich mindestens eine Festplatte ausfallen lassen koennte?

Für random-io gilt: mehrere 3-way mirrors. Die Frage ist ja auch, wieviel Kapazität du im Endeffekt überhaben willst. Bei zwei 3-way-mirrors hast du 2/6 Kapazität, als Konfiguration mit 6 Platten im RAIDz1 hast du 5/6 Platten, mit 2x3 Platten RAIDz1 hast du 4/6 über.

Mal direkt gefragt: was soll die Kiste machen? (NFS, Samba, DB, ...)

Rob
 

lockdoc

Well-Known Member
@Nukama:
nein, leider nicht. Was ich gefunden hatte, sprach glaube von einer ungeraden Zahl an Festplatten in einem Raid-Z. Aber es ging auch um die 512 Block Groesse.

@Oneone:
Hot Spare brauche ich erstmal nicht

@KobRheTilla:
+ Es greifen 2-3 Leute ueber Gbit LAN darauf zu.
+ Die Server Kiste beherbergt Samba und NFS
+ Video/Photobearbeitung uebers Netz (hier brauch ich eine geringe Latenz)
+ Anschauen von HD Filmen
+ Es sitzen 2 vmware images auf dem Server, welche auf den Clients abgespielt werden
+ Zusaetzlich laeuft mysql mit ein paar Gigabyte Daten
+ http/svn server
+ Eigene Dateien der User PCs sind auch Netzlaufwerke die auf den Server fuehren

Dementsprechend brauche ich viel Platz und besonders schnellen Platz :-)


@Yamag: und Crest
... extra Cache-Device und / oder Log-Device ...
ZIL auf SSDs kann die erreichbaren Transaktionen pro Sekunde massiv erhöhen.
Genau dafuer wollte ich die SSD einsetzen... allerdings fehlt es mir hier noch an technischem Know-How
 

KobRheTilla

used register
+ Es greifen 2-3 Leute ueber Gbit LAN darauf zu.
+ Die Server Kiste beherbergt Samba und NFS
Wenn die NFS-Last hoch ist, dann auf jeden Fall die SSD als separates ZIL, sonst bricht die Performance weg (ist auch so dokumentiert).

+ Es sitzen 2 vmware images auf dem Server, welche auf den Clients abgespielt werden
+ Zusaetzlich laeuft mysql mit ein paar Gigabyte Daten
+ http/svn server
+ Eigene Dateien der User PCs sind auch Netzlaufwerke die auf den Server fuehren

MySQL auch noch, hmm. Normalerweise beschneidet man ZFS dann im Caching um MySQL den meisten Speicher zu geben. Für die anderen Einsatzzwecke ist der Cache aber relativ wichtig.

Generell sehe ich mehr random i/o über das Storage als Streaming, ich würde eher die RAID10-ähnliche Variante nehmen, vielleicht aber auch nur mit 2-way-mirrors dafür 3 vdevs.

Rob
 

lockdoc

Well-Known Member
So ich habe nun fast alles fuer die Hardware zusammen und es wird so aussehen:
Code:
+ CPU:		 Core2Duo 3.4 Ghz
+ RAM:           16 GB
+ Storage:       6x 1TB HDD
+ Cache/Log+ZIL: 2x 32GB SSD (gemirrored)
Ich habe mich entschieden auf jeden Fall einen Mirror Raid zu machen, da dort der random zugriff besser ist.

Nun habe ich noch 3 verschiedene Varianten zur Auswahl:

a.) 3x Raid1 (jeweils 2 platten gemirrored)
b.) 3x Raid1 (jeweils 2 platten gemirrored), welche anschliessend zu einem Raid0 gebaut werden
c.) 2x Raid0 (jeweils aus 3 Platten bestehend), welche anschliessen zu einem Raid1-mirror zusammen geschlossen werden.


Hier ist jetzt die Frage Erweiterbarkeit, Ausfallsicherheit und Schnelligkeit.

1.) Wie ist der Geschwindigkeitsunterschied zwischen den 3 Varianten, oder nimmt es sich nix?
2.) Sind b) und c) gleich Ausfallsicher?
3.) Kann ich im Fall b) einfach ein weiteren Mirror in den Raid0 einbauen?

4.) Falls jemand ein besseres Setup empfehlen wuerde... einfach sagen
 

Elessar

Huldigt dem _/\_
a = b) wenn du 2 mirror vdevs im gleichen Pool hast, striped zfs automatisch darueber.
3) du kannst keine vdevs aus vdevs bauen, du haettest dann 2 stripesets ueber die zfs nochmal striped. quasi raid doppelnull.

Mit 6 Platten sind die naheliegenden Optionen:
- 2 Mirror vdevs aus je 3 Platten (2 Platten Nettovolumen)
- 3 Mirror vdevs aus je 2 Platten (3 Platten Nettovolumen)
- 2 RaidZ vdevs aus je 3 Platten (4 Platten Nettovolumen)

Mit dem ZIL auf SSD wirst die Performanz der SSD sehr klein bekommen, da ausser im Recovery Fall vom ZIL eigentlich nicht gelesen wird, das is purer write-IO - aufgrund der vielen fsync calls von nfs will man es aber auch nicht auf regulaeren Platten haben. Da sollte man dann leider regelmaessig eine der SSDs aus dem Mirror nehmen und mit Trim drueber (und heulen wenn in der Zeit die andere ausfaellt).

[Edit]
Zu der 4k Geschichte: wenn deine Platten eine physikalische Sektorgroesse von 4096 Bytes haben, ist es vorteilhaft das dem Dateisystem mitzuteilen, denn ein 512 Byte write auf eine Platte mit 4k Sektoren wird von der Firmware in einen 4k Read, austauschen der "neuen" 512 Byte und einen anschliessenden 4k Write ersetzt.
Dann sollte man peinlich genau dann darauf achten das der Partitionsbeginn auf einem natuerlichen vielfachen von 8 beginnt. Wenn der 4k Write des Dateisystems zum 4k Layout der Platte verschoben ist, machen die Platten den obigen Spass fuer jeden write gleich 2 mal. Gegen ein Floppy wirst noch gewinnen, aber ansonsten erzeugt das sehr traurige IO-Leistungen.

[Edit2]
Je nach Datensicherheitsparanoia kannst Dateisystemen mit wenig Schreibzugriffen und ueberschaubarem Volumen (zB /) auch vor dem befuellen mit `zfs set copies=2 $pool/$fs` (oder copies=3) Bescheid geben, das sie alle Daten ausserdem noch 2 (3) mal auf die Platten schreiben sollen. Damit kannst sogar bei ausgefallenem Spiegel noch Sektorfehler auf der verbliebenen Disk ausgleichen. Schreibperformanz ist dann aber halt entsprechend... mau.
 
Zuletzt bearbeitet:

lockdoc

Well-Known Member
Danke fuer die ausfuehrliche Antwort. Hier ist allerdings irgendwie eine Sache nicht ganz angekommen:
Mit dem ZIL auf SSD wirst die Performanz der SSD sehr klein bekommen...
Ich dachte mit der Auslagerung des ZIL auf SSD's geht die Performance enorm in die Hoehe?

Zu der 4k Geschichte
Bei mir wird das System (der Pool, nicht die SSD's) zusaetzlich mit Geli Vollverschluesselt.
Da ist jetzt die Entscheidung:

(I.) erst Verschluesselung, dann ZFS
(II). erst ZFS und darauf Verschluesselung

Wenn ich erst Verschluessele (I.), muss ich dann dem ZFS Dateisystem sagen, welche Sector Groesse Geli hat oder welche Groesse die HDD hat?
 

Elessar

Huldigt dem _/\_
Danke fuer die ausfuehrliche Antwort. Hier ist allerdings irgendwie eine Sache nicht ganz angekommen:

Ich dachte mit der Auslagerung des ZIL auf SSD's geht die Performance enorm in die Hoehe?
Ja (wenn du viele synchrone writes hast).
Unabhaengig davon laesst aber durch den reinen write-IO des ZIL die Performanz der SSD schneller nach nach als bei anderen, ausgeglicheneren Workloads.

(I.) erst Verschluesselung, dann ZFS
(II). erst ZFS und darauf Verschluesselung

Wenn ich erst Verschluessele (I.), muss ich dann dem ZFS Dateisystem sagen, welche Sector Groesse Geli hat oder welche Groesse die HDD hat?
Ich bin mir 99.98% sicher, das du GELI nur unterhalb von ZFS verwenden kannst, nicht auf ZFS oben drauf.

[Edit] Also selbst im unwahrscheinlichen Fall das kein Lachen aus dem Speaker kommt wenn man es versucht, kann man mit einem geoeffneten Geli-Device ja erstmal nichts anfangen. Wuerdest dann oben nochmal UFS2 draufstecken oder wie war das angedacht?
 
Zuletzt bearbeitet:

Crest

rm -rf /*
Teammitglied
GELI kannst du sinnvoll nur unterhalb von ZFS verwenden. Theoretisch kannst du GELI auch auf ZVOLs benutzten. Sinnvolle Szenarien fallen mir dafür gerade nicht wirklich ein. geom eli init -s 4096 sorgt dafür das GELI 4kB reads/writes ausführt, wenn das Alignment stimmt. ZFS ist schlau genug dann selbst auf dem betroffenen VDEV auch 4kB als kleinste Blockgröße zu verwenden. Guck dir deinen Pool mit zdb an. Ashift sollte auf allen VDEVs die Platten mit 4kB Sektoren enthalten >= 12 sein.
 

lockdoc

Well-Known Member
a = b) wenn du 2 mirror vdevs im gleichen Pool hast, striped zfs automatisch darueber.

nochmal zum Verstaendnis:

Wenn ich also 2 Platten in den Pool haenge ohne, irgendetwas weiteres anzugeben, dann macht er automatisch ein Raid-0 draus?


Waere dass hier dann ein Raid-0: ?
Code:
#> zpool status
    pool: tank
   state: ONLINE
   scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          ad2p1     ONLINE       0     0     0
          ad3p1     ONLINE       0     0     0
 
Oben