Ausführliche ZFS-Dokumentation?

M

morpheus

Well-Known Member
Hallo,

ich bin gerade dabei, mich mal etwas intensiver mit ZFS zu beschäftigen, da ich dem Dateisystem durchaus zutraue, mit dem stetig größer werdenden Speicherplatzbedarf in unserer Firma zurechtzukommen. Nachdem ich beim letzten mal, nachdem ich unser Storagegehäuse mit sechs weiteren Platten bestückt hatte, eine Komplettsicherung machen, anschließend das Raid neu erstellen und die Daten wieder zurücksichern musste, möchte ich für die Zukunft eine einfacher zu handhabende Lösung haben und ich denke, dass ZFS hier helfen kann.

Nun enthält das FreeBSD Handbook ja nicht allzu umfangreiche Informationen zu diesem Thema. Gibt es im Netz eine Quelle, wo ich mehr Informationen zu ZFS unter FreeBSD herbekomme als nur die einfachen Basics? (Also z.B. ZIL hinzufügen, Dedup, L2ARC-Cache einrichten etc.)

Gruß, Morpheus
 
morpheus schrieb:
ich bin gerade dabei, mich mal etwas intensiver mit ZFS zu beschäftigen, da ich dem Dateisystem durchaus zutraue, mit dem stetig größer werdenden Speicherplatzbedarf in unserer Firma zurechtzukommen.
Zum Vergrößern anklicken....

Rein interessehalber, weil wir vor einiger Zeit die Diskussion zum Thema FreeBSD im professionellen Einsatz hatten: wieviele Mitarbeiter hat die Firma?

morpheus schrieb:
Nun enthält das FreeBSD Handbook ja nicht allzu umfangreiche Informationen zu diesem Thema. Gibt es im Netz eine Quelle, wo ich mehr Informationen zu ZFS unter FreeBSD herbekomme als nur die einfachen Basics? (Also z.B. ZIL hinzufügen, Dedup, L2ARC-Cache einrichten etc.)
Zum Vergrößern anklicken....

Den Großteil kannst du der Solaris-Dokumentation sowie dem ZFS Best Practices Guide entnehmen.
 
Azazyel schrieb:
Rein interessehalber, weil wir vor einiger Zeit die Diskussion zum Thema FreeBSD im professionellen Einsatz hatten: wieviele Mitarbeiter hat die Firma?
.
Zum Vergrößern anklicken....

Knapp 100 MA. Aufgrund bestimmter Gegebenheiten ist der Speicherplatzbedarf allerdings enorm geworden. Vor zwei Jahren waren 12 TB noch ausreichend, mittlerweile platzt auch dieses Storage aus allen Nähten. Beim klassischen Raid fehlt da halt einfach die Flexibilität, mal eben zusätzliche Plattenkapazität hinzuzufügen, ohne das Raid komplett neu erstellen zu müssen.
 
morpheus schrieb:
... Beim klassischen Raid fehlt da halt einfach die Flexibilität, mal eben zusätzliche Plattenkapazität hinzuzufügen, ohne das Raid komplett neu erstellen zu müssen.
Zum Vergrößern anklicken....
Kann man denn inzwischen zpools dynamisch vergroessern oder den Typ aendern? Ich dachte, das einzige was geht ist pools ohne mirror (~raid0) platz hinzufuegen, oder eben spare.
 
h^2 schrieb:
Kann man denn inzwischen zpools dynamisch vergroessern oder den Typ aendern? Ich dachte, das einzige was geht ist pools ohne mirror (~raid0) platz hinzufuegen, oder eben spare.
Zum Vergrößern anklicken....

Da bin ich eigentlich von ausgegangen, ansonsten wäre ZFS doch nicht viel mehr als ein sehr gut funktionierendes Software-RAID, oder sehe ich das falsch?

Vielleicht kann sich jemand dazu äußern, der Erfahrung im Einsatz von ZFS hat.
 
Also, RAID-Z hat drei Einschränkungen in Sachen Wachstum und es sieht derzeit nicht danach aus, als würden sie jemals aufgehoben werden:
1. Ein RAID-Z kann nach dem Erstellen keine weiteres Medien aufnehmen.
2. Man kann Medien nicht aus einem RAID-Z entfernen (aber ersetzen!), sobald sie eingefügt wurden.
3. Ein RAID-Z kann nicht schrumpfen.
Um ein RAID-Z wachsen zu lassen, ist die einzige gangbare Strategie alle vorhandenen Platten gegen größere Modelle auszutauschen, anschließend den Pool zu exportieren und wieder zu importieren. Die FreeBSD Foundation sponsert derzeit ein Projekt, was das Vergrößern ohne Export und Import ermöglichen soll. Aber: Wer größere Pools baut, tut sowieso sehr gut daran, komplexere Setups anstelle eines einzelnen Vdev zu nutzen. Beispielsweise mehrere RAID-Z aus 3 Platten (6 für RAID-Z2, 9 für RAID-Z3) zu einem Pool zusammenfassen. Ist Ausfallsicherheit sehr wichtig, kann man RAID-Z auch zu Mirror zusammenfassen. Etc. So kann man, wenn man mehr Platz benötigt, einfach ein weiteres Vdev in den Pool einfügen und fertig.
 
Yamagi schrieb:
So kann man, wenn man mehr Platz benötigt, einfach ein weiteres Vdev in den Pool einfügen und fertig.
Zum Vergrößern anklicken....
Was genau meinst du damit? Kann ich einem RAIDZ1 nun weitere Platte spendieren, bei Beibehaltung der 1er-Paritaet? Kann ich dann auch ein RAIDZ1 mit zwei Platten "starten" (quasi-Mirror) und spaeter eine dritte, vierte hinzufuegen?
 
Nein. Einem RAID-Z kann man keine Platten hinzufügen. Man kann aber ein RAID-Z in ein anderes Vdev einfügen. Angenommen du hast einen Pool, der wie folgt aufgebaut ist:
Code: 
Poolname
  raidz
   /dev/ada0
   /dev/ada1
   /dev/ada2
  raidz
   /dev/ada3
   /dev/ada4
   /dev/ada5

Nun erstellst du ein neues Vdev und fügst es in den Pool ein. Anschließend hast du:

Code: 
Poolname
  raidz
   /dev/ada0
   /dev/ada1
   /dev/ada2
  raidz
   /dev/ada3
   /dev/ada4
   /dev/ada5
  raidz
   /dev/ada6
   /dev/ada7
   /dev/ada8

Die Kapazität des Pools erhöht sich um die Kapazität des neu eingefügten RAID-Z.
 
@yamagi: ah, ok. Hatte das mit den vdevs nicht im Auge. Wobei es doch bei <10 Platten eigentlich keinen Grund gibt, mehrere vdevs zu benutzen, oder? Gerade in dem Beispiel mit 9 Platten. Da hat man ja immernoch nur single-parity, wo man doch eigentlich tripple-parity haben koennte...

Glaube, dass es trotzdem eine Riesenmanko ist, dass meine keine neuen Platten hinzufuegen kann. Im High-End-Bereich vielleicht weniger relevant, aber gerade bei kleineren Usern / KMUs etc, die insgesamt 2-3 server mit je 2-6 Platten betreiben, macht das die Wartung doch unnoetig kompliziert.
 
h^2 schrieb:
@yamagi: ah, ok. Hatte das mit den vdevs nicht im Auge. Wobei es doch bei <10 Platten eigentlich keinen Grund gibt, mehrere vdevs zu benutzen, oder? Gerade in dem Beispiel mit 9 Platten. Da hat man ja immernoch nur single-parity, wo man doch eigentlich tripple-parity haben koennte...

Glaube, dass es trotzdem eine Riesenmanko ist, dass meine keine neuen Platten hinzufuegen kann. Im High-End-Bereich vielleicht weniger relevant, aber gerade bei kleineren Usern / KMUs etc, die insgesamt 2-3 server mit je 2-6 Platten betreiben, macht das die Wartung doch unnoetig kompliziert.
Zum Vergrößern anklicken....

Hallo,

Du kannst dem RAIDZ-Verband keine Platten hinzufügen, dem ganzen Pool jedoch schon.
Warum also nicht einfach ein Mirror oder ein weiteres RAIDZ dem bestehenden Pool spendieren?

Wesentlich mehr Sorgen bereitet mir das Backup solch grosser Datenhalden...

Gruss aus Berlin

marmorkuchen
 
hi

der vorteil von mehreren vdevs im pool ist das data-stripeing .... sprich performance.

und selbst bei netapp kannst du eine bestehende raid gruppe nicht erweitern

man kann dann nur eine neue raidgruppe mit den neuen platten dem bestehenden
aggregat hinzufuegen also so wie es zfs auch macht mit pool und vdev.

holger
 
h^2: Es gibt sogar sehr gute Gründe mehrere VDEVs zu verwendeten statt eines großen RAID-Z3. Ein RAID-Z1-3 hat ca. die IOPS des langsamsten Devices. Ein Pool mit mehren redundanten VDEVs striped über alle VDEVs ohne unzuverlässig zu werden.
 
Crest schrieb:
h^2: Es gibt sogar sehr gute Gründe mehrere VDEVs zu verwendeten statt eines großen RAID-Z3. Ein RAID-Z1-3 hat ca. die IOPS des langsamsten Devices. Ein Pool mit mehren redundanten VDEVs striped über alle VDEVs ohne unzuverlässig zu werden.
Zum Vergrößern anklicken....

Das habe ich noch nicht genau verstanden. Nehmen wir das Bsp. von Yamagi:
9 Platten a 1TB z.B.

szenario1: RAIDZ3
- 6Platten effektiv nutzbar
- tripple-parity
- daten gleichmaessig verteilt, da ja jede platte Paritaet fuer mehrere Platten macht

szenario2: RAIDZ1*3
- 6Platten effektiv nutzbar
- single-parity
- daten gleichmaessig nur innerhalb eines RAIDZ1 verteilt, jede platte macht Paritaet fuer 2 andere Platten

-> oder habe ich das falsch verstanden?

Fuer mich ergibt sich daraus: gleicher Platz, (deutlich) weniger ausfallsicherheit[1], und nicht mehr performance (wenn nicht sogar weniger).


[1] nehmen wir indiv. ausfallwahrscheinlichkeit p an, dann ist vollstaendige ausfallwahrscheinlichkeit in szen1 p^4 und in szen2 p*p/3. (nach simplester statistik IIANM
 
mark05 schrieb:
und selbst bei netapp kannst du eine bestehende raid gruppe nicht erweitern
Zum Vergrößern anklicken....

Das stimmt schon lange nicht mehr, man kann NetApp RAID-Gruppen problemlos erweitern, aber es ist u.U. durchaus sinnvoller, eine neue RAID-Gruppe hinzuzufügen. Das dürfte bei ZFS ähnlich sein.
 
h^2: Die 3 RAID-Z1 wären zwar anfälliger, aber deutlich schneller in der Praxis. 4 Mirrors + 1 Hotspare wären wahrscheinlich noch schneller.
 
Crest schrieb:
h^2: Die 3 RAID-Z1 wären zwar anfälliger, aber deutlich schneller in der Praxis.
Zum Vergrößern anklicken....
Das musst du mir erklären. Die Daten sind nicht öfter da, und außerdem noch schlechter verteilt (das heißt Beeinträchtigung durch eine langsame Platte größer, weniger balancing etc). Wieso ist das schneller?
4 Mirrors + 1 Hotspare wären wahrscheinlich noch schneller.
Zum Vergrößern anklicken....
Das glaube ich dir, da sind ja auch alle Daten real doppelt da. Da hat man allerdings noch mehr Kapizitätsverschnitt. Aber das ist mir nicht so wichtig, mir gings hier um den anderen Fall.
 
h^2: Weil ein RAID-Zn die Stripgröße zwar erhöht, aber nicht die IOPS steigert. Damit profitiert man nur hauptsächlich bei seq. I/O.
 
Crest schrieb:
h^2: Weil ein RAID-Zn die Stripgröße zwar erhöht, aber nicht die IOPS steigert. Damit profitiert man nur hauptsächlich bei seq. I/O.
Zum Vergrößern anklicken....

Aber drei RAIDZ1 hintereinander schon? Wieso? Wo kommen die extra IOPS da denn her?
[also die Fragen hier sind ernst gemeint, ich will garnicht flamen, oder so, es leuchtet mir einfach garnicht ein]
 
hi
also scenario 2 hat deutlich mehr performance als scnario1 da du vergisst das
zfs einen datastripe macht auf den 3 vdev von scenario 2.

enfachgesagt scenario2 schreibt im gleichen zeitraum 3 databloecke wo scenario1 nur einen
schreibt.

z3 ist wirklich sinnvoll wenn ich daten langfristig bereitstellen will und es nicht wirklich
auf perfromance ankommt , z.b. fuer archivierung oder backup system.

will aber eine mischung aus kapazitaet und performance ist scenario2 die bessere wahl.

holger
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben