ZFS: Raid Z2 mit 6 HDDs vs. Raid Z1 mit 3 HDDs

[oyster]

Moin zusammen,

ich bin gerade dabei mir einen neuen Server zusammenzustellen. Ich schwanke derzeit zwischen folgenden HDD-Konfigurationen:

1. 3x 6-8 TB im Raid Z1
2. 6x 3-4 TB im Raid Z2

Für Variante 1 spricht auf jeden Fall der geringere Strombedarf, für Variante 2 die erhöhte Verfügbarkeit bzw. geringere Wahrscheinlichkeit eines Totalausfall.

Zu bedenken ist, dass ich von den wirklich wichtigen Daten ein nächtliches, inkrementelles Backup in ein paar 100 km Entfernung anfertige.

Welche Variante sollte man in diesem Fall wählen? Ist Raid Z1 bei der Plattengröße völlig daneben? Man sagt ja gerne, dass man Raid 5 bei heutigen Plattengrößen nicht mehr verwenden sollte, ich denke bei Raid Z1 wird sich das ähnlich verhalten, richtig?

VG
oyster

 

[gea]

Grundstzlich möglich ist beides zumal Z1 bei einem Lesefehler nach einem Plattenausfall etwas unkritischer reagiert als Raid-5. Da ist dann nicht das Array verloren sondern nur die betroffene Datei.

Insgesamt sehe ich das aber so
Backup ist wie altes Brot, immer von gestern (es sei denn man nutzt ein syncrones Verfahren wie ZFS Pool-Spiegelung übers Netz). Für alltägliche Zwecke ist Versionierung das Wichtigste, das sind also Snaps, je mehr und le länger man die hat umso besser. Könnte man auch über Backup auf ZFS realisieren. Einfacher ist das aber lokal zu realsieren.

Grundsätzlich ist besonders zuverlässiges Primär-Storage das Wichtigste und das ist ZFS Z1 definitiv nicht. Platten gehen ab und an kaputt und dann beginnt ansonst das Hoffen und Bangen. Ich würde insbesondere bei großen Platten immer auf Z2 gehen, also 4-10 Platten je vdev. 6 und 10 Platten sind die Optionen mit der besten Platzausbeute. Von der Performance und Sicherheit geht jede Anzahl.

 

[oyster]

Danke, das hilft mir schonmal weiter. Noch eine ergänzende Frage:

Wie verhält sich ZFS, wenn man unterschiedlichste Festplatten in einem vdev mischt? Einfach gesagt also z. B. 3 5400er Platten mit 3 7200er Platten. Hat das negative Seiteneffekte oder läuft das lediglich darauf hinaus, dass die max. Performance von den 5400ern limitiert wird?

 

[gea]

ZFS ist das egal.
Bei sequentiellen Transfers ist der Unterschied gering, iops liegt im Schnitt irgendwo dazwischen.

Da aber sowohl Lesen wie Schreiben über einen Cache läuft, wird man den Unterschied kaum merken.

 

[pumuckel]

ideal imho wären 3 Mirror aus je 2

... aber gea kennt sich da besser aus

 

[Digi-Quick]

3x Mirror in einem Pool entspricht vom Redundanzlevel trotzdem nur Raid 10, da nur eine beliebige HDD ausfallen darf bei 50 % Kapazitätsverlust, man könnte natürlich jeden Mirror als eigenständigen Pool betreiben, verliert dabei aber den Vorteil der höheren IOPS und hat 3 einzelne Freigaben/Netzlaufwerke.

Ein Pool aus 2x Raidz1 aus jeweils 3 HDDs entspricht dem Raidlevel 50, es darf weiterhin nur eine beliebige HDD ausfallen, bei 33% Kapazitätsverlust.

Bei 1x Raidz2 aus 6HDDs sind es ebenfalls 33% Kapazittätsverlust, es dürfen aber 2 beliebige HDDs ausfallen

In Sachen IOPS in einem Pool ist natürlich 3x Mirror besser als 2x Raidz1 besser als 1x Raidz2.

Ps: Wenn du die Seagate NAS HDDs nimmst, ist auch Raidz1 noch relativ unkritsch, da diese eine URE von 1 in 10^15 haben (ggü 1 in 1^14 /10 in 10^15 bei WD etc.)

Jeder HDD Einbauplatz kostet Geld.
Ob es sinnvoller ist alle bzw. einen Großteil der vorhandenen HDD Einbauplätze mit in Summe billigeren kleineren HDDs zu belegen - mit entsprechend höhrerem Stromverbrauch - oder weniger und grössere HDDs für mehr Geld zu verbauen bei geringerem Stromverbrauch und dazu noch eine Erweiterungsreserve zu haben, muss man für sich entscheiden.

 

[pumuckel]

... omg, lange ist es her, helft mir mal - ich hatte früher mal stochastik

wie war die Wahrscheinlichkeit, dass unter 6 platten genau 2 in einem festen doppel ausfallen ?

im besten Fall könnten 3 ausfallen in schlechtesten nur eine mal sehen ob ich die formel noch finde

bei der 1. ist es unerheblich und bei der 2. wäre das 1:5 aka 20%, dass es genau die Mirrorplatte trifft und 80% dass es eine aus einem anderen Mirror ist und es überlebt, ... ich lass es lieber, ist zu lange her ^^

da der Rebuild aber kürzer ist bei Mirror senkt sich die Chance im vgl etwas

 

[Holt]

Wie hoch die Wahrscheinlichkeit eines Lesefehlers bei einer Platte ist, wird von den Herstellern in Form der UBER angegeben und die ist bei den üblichen 3.5" HDDs entweder <= 1:10^14 oder <= 1:10^15. Das bedeutet, dass eine HDD die innerhalb der Spezifikationen betrieben wird, dann maximal alle ca. 12TB bzw. 120TB gelesener Daten einen solche Lesefehler haben kann, ohne die Spezifikation zu verletzen, aber eben nicht haben muss. Damit ergibt sich je nach Größe der Platten z.B. bei drei 8TB HDDs im RAID 5/Z1 für ein Rebuild eine theoretische Wahrscheinlichkeit von 11,1% für eine HDD mit einer UBER von 1:1^0^14 das es klappt, es also keinen Fehler gibt wenn die ganzen 8TB von den zwei Platten gelesen werden während das Rebuild auf die dritte passiert.

Haben die Platten eine UBER von 1:10^15 steigt diese Wahrscheinlichkeit auf 87,1% an, die UBER ist daher fundamental um die Chancen für ein erfolgreiches Rebuild zu bestimmen, wobei das natürlich nicht bedeutet, dass es ab 50% immer klappen und darunter immer in die Hose gehen muss. Mit 6 HDDs zu je 4TB wäre die Chancen übrigens 13,2% bzw. 84,4%.

 

[sandreas]

6x 3-4 TB im Raid Z2

Aus meiner Sicht gibt es hier zwei weitere Vorteile, die viele nicht bedenken:

1.) RAID-Z1 ist, je nach verwendetem Betriebssystem bei EINER nur zum Teil defekten Platte u.U. nicht mehr in der Lage, die Lese- / Schreibraten aufrecht zu erhalten, die es normalerweise hat. Beispiel: Hast du ein System mit 100MB/s lesen, beginnt eine Platte zu straucheln. Plötzlich hast du zeitweise nur noch 5MB/s. Mach da mal ein Backup... viel Spaß.
2.) RAID-Z können nicht so ohne weiteres um eine Platte erweitert werden. Sprich, willst du ein 3x6TB RAID-Z1 vergrößern, geht das nur mit einem extra Pool. Einfach eine vierte 6TB-Platte dazu schustern (und ein RAID-Z1 beizubehalten) geht meines Wissens nach nicht. Hast du allerdings 6x3TB, kannst du Schritt für Schritt eine Platte nach der anderen durch eine 4TB austauschen und hast dann 6x4TB. Das funktioniert tadellos.


Ein 5x4TB RAID-Z2 würde aus meiner Sicht einen guten Kompromiss darstellen. Behalte auch im Hinterkopf, dass langsam aber sicher SSDs immer größer werden. Es wird sicher noch Jahre dauern, bis sie die traditionellen Platten im Preis-Leistungsverhältnis für reinen Storage überholen, aber frage dich auch, ob du mit dem jetzt geplanten Platz vielleicht 3 Jahre hinkommst und dann auf SSD-Technik umsteigen könntest.

 

[gea]

Lesefehler und der daraus resultierende Performanceeinbruch sind ein gar nicht so seltenes Problem. Vor allem unter Last kann so ein Recovery Versuch der Platte auch lange dauern. Bei Hardwareraid wird eine Platte meist nach ca 8s aus dem Raid geworfen. TLER Platten begrenzen die Recoveryversuche daher auf 7s.

ZFS wartet erheblich länger darauf dass die Platte Daten liefert. Man braucht daher auch keine TLER Platten. Den ZFS Default Timeout von 60s finde ich aber recht hoch weil das dazu führen kann dass der Pool bei mehreren Lesefehlern in der Performance massiv einbrechen kann. Den timeout kann man aber selber festlegen. Ich nehme meist 15s.

Insgesamt ist das aber kein so riesiges Problem. Über iostat sieht man schnell wenn eine Platte wesentlich schlechter ist als andere. Dann ersetzt man die halt, wenn sie ganz schlecht ist, erklärt man die als defekt und zieht sie und ersetzt aus der Raid Redundanz.

Zum Vergrößern eines ZFS Pools
War vermutlich richtig gemeint, der Begriff is aber falsch.
Man kann keinen Pool durch einen Pool erweitern. Ein Pool besteht aus einem oder mehrerer Raid Arrays. Die heißen vdevs. Erweitert wird ein Pool durch zusätzliche vdevs (Mirror, Raid-Z, Basic Disks). Alternativ kann man in einem vdev per disk-replace kleinere durch größere Platten ersetzen. Sind alle ersetzt, wird die größere Kapazität genutzt. Das geht bei Mirrors oder bei Z1/2/3. Ein Hinzufügen einer einzelnen Platte zu einem Raid-Z (Raid-Transformation) wird aber nicht unterstützt und braucht man ausserhalb des Home-Bereichs auch nicht.

Wenn möglich würde ich statt eines 5 Platten-Z2 eines aus 6 Platten nehmen da sonst etwas Platz verlorengeht.

 

[sandreas]

@gea: Danke für die Korrektur. Wieder was gelernt

 

[pumuckel]

jo, ich bin wohl zu konservative und halte mich an Allan Jude

gea sollte es am besten wissen

 

[Holt]

bei EINER nur zum Teil defekten Platte u.U. nicht mehr in der Lage, die Lese- / Schreibraten aufrecht zu erhalten, die es normalerweise hat.

Neben dem Timeout der Platte selbst (also TLER) liegt das aber daran, dass jeder anständige RAID bei Lesefehlern nicht nur die Daten aus der Parity recovern, sondern auch die Daten auf der Platten mit dem Problem überschreiben, was die Performance weiter mindert. Defekte Platten hat man aber zu ersetzen, denn das muss passiert und das Recovery beendet sein, bevor er Problem mit der nächsten Platte gibt.

Mach da mal ein Backup.

Backups macht man regelmäßig und hält sie auch regelmäßig aktuell, wenn es schon Probleme gibt, ist es oft zu spät und auch keine Datensicherung (=Backup) mehr, sondern schon Datenrettung!

2.) RAID-Z können nicht so ohne weiteres um eine Platte erweitert werden.

Das ist korrekt, wenn die Erweiterung um weitere Platten geplant ist, sollte man besser ein Linux md SW RAID verwenden.

 

[oyster]

Danke erstmal. Ich werde nun wohl erstmal auf 6x 3 TB RaidZ2 gehen und diese später durch größere Platten ersetzen.

Momentan überlege ich noch welches Betriebssystem ich wähle:

• Linux mit luks/dmcrypt (damit habe ich die meiste Erfahrung)
• FreeBSD mit Geli
• OmniOS mit lofiadm
• OmniOS generell ohne Verschlüsselung (ungerne)

Meine Clients sind primär Linux/OSX-Geräte. Das ganze soll au feinem AiO (ESXi) laufen, die Anbindung des Storage an den ESXi soll per NFS erfolgen.

Worauf sollte man bezüglich Performance optimalerweise setzen? Ich vermute OmniOS wird am flottesten sein. Hat da jemand belastbare Zahlen wie die Performance zwischen den einzelnen Betriebssystemen sich unterscheidet (jeweils für NFS und SMB)?

Wie funktioniert die Verschlüsselung mittels lofiadm? Sind meine zugrunde liegenden Laufwerke dann einzelne Pools auf denen jeweils eine verschlüsselte Datei mit der Größe der jeweiligen Platte liegt? Über diese Dateien wird dann dementsprechend ein RaidZ2 gebildet, was dann den eigentlichen Pool darstellt, richtig? Ich habe gelesen, dass ein ZFS-Pool optimal performt wenn er nicht voll belegt ist, wie verhält es sich dann wenn die verschlüsselten lofiadm-Dateien die jeweiligen Platten zu 100% füllen?

 

[gea]

Die beste Verschlüssellung ist in ZFS integriert.
Damit kann jedes Dateisystem einen eigenen Schlüssel erhalten und man kann verschlüsselt replizieren.
Leider gibt es das momentan nur von Oracle mit Solaris wie auch ein schnelleres Resilvering

Es gibt aber ein Projelt unter ZoL das auf Basis der (fast fertigen) implementierung in Illumos eine native ZFS Verschlüssellung bringen soll - und zwar dann für alle Open-ZFS Plattformen (genau wie schnelleres Resilvering), siehe Developper Summit im September OpenZFS

Alternativ kann man eine der zueinander inkompatiblen Varianten Geli, Luks oder Lofi nehmen.
Geli und Luks verschlüsseln die Platten auf denen ZFS dann seinen Pool anlegt. Ist ausgereift und schnell.

Lofi ist eine Lösung für spezielle Fälle. Es eignet sich nicht so gut für große Pools und ist auch langsamer. Es basiert auf normalen verschlüsselten Dateien aus denen ein Pool gebaut wird. Hauptvorteil: Man kann die Dateien einfach wegsichern ohne die Verschlüssellung oder die Raid-Z1-3 Sicherheit zu verlieren. Ideal also um sensible Daten in der Cloud oder auf unsicheren Datenträgern z.B. FAT USB Sticks zu sichern.

Volle Pools sollte man eigentlich immer und bei CopyOnWrite ganz besonders vermeiden da die dann wegen der Fragmentierung langsam werden.