ZFS Platten mit unterschiedlichen größen nutzen und ersetzen

DorMoordor

Lt. Junior Grade
Registriert
Aug. 2017
Beiträge
361
Hallo,

ich habe mal bzgl. ZFS eine Verständnisfrage. Ich möchte ZFS nutzen, habe aktuell aber nur:
  • 1x 1TB
  • 2x 2TB
  • 1x 4TB
Ich würde gerne ein RaidZ2 erstellen mit allen 4 Platten. Natürlich werde ich dann zu beginn nicht die volle Kapazität der 2TB un 4 TB Platten nutzen können.

Jetzt ist meine Frage, wenn später die 1 TB Platte den Geist auf gibt und ich die austausche (mit sagen wir einer 4TB Platte), wie verhält sich dann das RaidZ2? Wird dann automatisch das RaidZ2 vergrößert und an die Festplattengröße angepasst oder Müsste ich das RaidZ2 neu anlegen, um den Speicher nutzen zu können.

Viele Grüße

DorMoordor
 
Ich bin mir ziemlich sicher, dass ZFS ein VDEV automatisch vergrößert, sobald alle Platten gegen größere getauscht wurden. In der Theorie sollte es also gehen, allerdings ist ein RaidZ2 mit so verschiedenen Platten nicht wirklich sinnvoll.

Nehm doch striped-mirrors, also raid10 quasi. 2x2TB gibt einen passenden mirror mit 2TB, die 1TB + 4TB den zweiten mit nur 1TB. Macht vorerst mal 3TB und wenn dann die 1TB durch 4TB getauscht wird gibts 6TB nutzbaren Platz.
 
  • Gefällt mir
Reaktionen: Ebrithil
SlaterTh90 schrieb:
Nehm doch striped-mirrors
Daran hatte ich noch gar nicht gedacht. Das ist denke ich auch eine Überlegung wert.

SlaterTh90 schrieb:
allerdings ist ein RaidZ2 mit so verschiedenen Platten nicht wirklich sinnvoll.
Ja ich weiß, das war auch erstmal nur zum Verständis. Ich werde die 1TB Platte wahrscheinlich eh innerhalb eines Jahres austauschen und dann als Backup Platte nutzen. Aktuell fehlt aber leider dafür das Geld
 
Es macht jedenfalls nicht wirklich Sinn mit nur 4 Platten ein RaidZ2 anzufangen. Man kann zwar die Platten tauschen, aber aktuell kann man keine weiteren zum RaidZ2 Verbund hinzufügen - es bleibt also immer bei 50% Verlust für Redundanz. Dazu hat RaidZ2 nur die IOPS-Performance einer einzelnen Festplatte, bei Raid10 kann man alle effektiv nutzen. Insofern würde ich in der Situation auf jeden Fall "Raid10" machen. Zumindest unter ZFS-on-Linux kann man ganze VDEVs aus dem Pool nehmen, damit könnte man dann die 1TB Platten einfacher loswerden später.
 
SlaterTh90 schrieb:
Man kann zwar die Platten tauschen, aber aktuell kann man keine weiteren zum RaidZ2 Verbund hinzufügen
Ok, das wusste ich nicht. Ich dachte ich könnte später auf mehr Platten upgraden, so macht es wahrscheinlich wirklich mehr Sinn ein Raid10 zu nutzen. Danke für die Infos bis hierhin
 
@DorMoordor Ja und Nein. Ja, du kannst jederzeit einem Pool weitere vDevs hinzufügen. Nein, eine vDev kannst du nicht nachträglich verändern. Es bleibt aber dabei: Stirbt eine vDev im Pool dann stirbt der Pool. Kleines Beispiel:
Du startest mit zwei HDDs (h1, h2) und machst daraus eine mirrored-vDev (v1). Darauf erstellst du deinen Pool (p1).
Eine Woche später kaufst du dir h3 und machst daraus eine single vDev v2 und fügst diese p1 hinzu womit der Pool striped ist.
Stirbt h1 oder h2 > Du kaufst Ersatz, baust ein, resilvering und alles ist gut. Stirbt h3 war es das mit deinem Pool und den Daten.
Wenn du anstatt nur h3 dir gleich auch h4 kaufst kannst daraus den nächsten Mirror v2 machen und p1 hinzufügen. Jetzt kann je aus v1 und v2 eine HDD sterben und Daten sind noch da.
Theoretisch kannst du jetzt auch h5, h6, h7 kaufen und daraus ein raidz1 als dritte vDev erstellen und deinem Pool hinzufügen. Macht zwar wenig Sinn aber möglich.
Du kannst jederzeit eine vDev vergrößern indem du eine HDD gegen eine größere tauschst. Sobald alle HDDs einer vDev getauscht und resilvert sind kannst die vDev vergrößern und damit auch den Pool (oder ggf. auch direkt den Pool, müsste man mal recherchieren).

Die Aussage man könne bei ZFS-on-Linux inzwischen HDDs aus vDevs oder Pools entfernen ist mit größter Vorsicht zu genießen! Stand heute kann man lediglich einzelne HDDs oder mirrored vDevs aus einem Pool entfernen wenn man aus Versehen eine HDD als single vDev oder eben mirror-vDev dem Pool hinzugefügt hat. Auch das gilt nur solange der Pool aus mirror-vDevs besteht. Sollte in einem Pool raidz(1,2,3) vDevs vorhanden sein geht Stand heute kein entfernen. Da das Feature noch relativ neu ist würde ich dies mit Vorsicht genießen und stets funktionierende Backups parat haben.

Ansonsten gilt bei ZFS, zumindest unter BSD (inkl. FreeNAS): Du kannst jederzeit kleine durch größere HDDs in einer vDev ersetzen aber nicht eine vDev vergrößern aber nicht verkleinern. Du kannst jederzeit einen Pool durch weitere vDevs vergrößern aber nicht verkleinern.
Wenn du deine vDevs oder Pools umbauen willst: Daten sichern/exportieren, Pool "zerstören", vDevs "zerstören" und neu anlegen.
 
SlaterTh90 schrieb:
es bleibt also immer bei 50% Verlust für Redundanz.
Bei 4 gleich großen Platten, aber hier wäre der Verlust höher, denn auch wenn ich kein ZFS Experte bin, dürfte es auch beim RaidZ2 wie bei einem normalen RAID 6 sein und man bekommt als Nutzkapazität die Kapazität der kleinsten Platte mal der Anzahl der Platten - 2 (für die doppelte Redundanz), was hier wegen der 1TB HDD dann am Ende gerade mal 2TB Nutzkapazität bei 9TB Rohkapazität wären.
 
@Holt ja das ist richtig, ich meinte nur für den Fall dass man irgendwann dann alle Platten in der selben Größe hat. Einziger Vorteil gegenüber Raid10 ist bei 4 Platten, dass es für die Wiederherstellung komplett egal ist welche beiden Platten man verliert, während es bei Raid10 natürlich nur zwei aus zwei verschiedenen Mirrors sein können.
 
Jup. Raid6 bzw. Raidz2 hat aber auch den Nachteil der deutlich höheren Last beim Rebuild/Resilvering auf allen verbliebenen Platten, da die fehlenden Daten bzw. Paritäten alle neu eingelesen und errechnet werden müssen. Bei einem Mirror muss "nur" einmal linear gelesen werden.
Jede Variante hat also ihre Vor- & Nachteile aber bei beiden ist ein Backup Pflicht wenn die Daten wichtig sind.
 
Vielen Dank euch allen für die Infos. Ich denke ich werde es vorerst mit einem Raid10 probieren.
Und ja ich weiß Raid ist kein Backup, deswegen ist das zusätzlich in der Planung. Außer 2 externer Platten habe ich da aber vorerst nichts geplant.
 
Als ersten Schritt in Richtung Backup, würde ich mit regelmäßigen Snapshots anfangen. Die kriegst du bei ZFS "frei Haus" und bieten schonmal etwas mehr Sicherheit.
 
@Ebrithil Okay, du hast den einfachen Teil genannt und wie genau bekommt der TE jetzt im besten Fall (semi-)automatisiert die Snapshots auf seine zwei externen HDDs sobald er diese anschließt und löscht dann auch Snapshots die aus der Retention gelaufen sind?
 
Die ersten Schritte sind immer die ienfachsten, Hilfe und/oder Hirnschmalz in der Regel beim Rest und den verschweigst du. Zfssnap erleichtert die Erstellung neuer und Löschung alter Snapshots aber nennt als Beispiel auch nur Replikation zu anderem (zfs-fähigen) Server. Das hilft wie genau dem TE mit externen HDDs?
ZFS ist top wenn man die Vor- und Nachteile kennt und sich nicht davor scheut fehlende Dinge selbst zu verskripten. Aber ich stelle mal die gewagte These auf, dass dies bei den allerwenigsten Anwendern der Fall ist...
 
Einfach rsync oder ähnliches ist in dem Fall wohl besser. ZFS/BTRFS/Raid genrell mit USB-HDDs ist nicht empfohlen.
 
Es geht in der Situation des TEs nicht darum, ein ZFS auf USB-Disks zu betreiben, dafür will er afaik interne SATA-Disks nutzen aber Backup soll auf externe und somit USB-Disks. Mehrere USB-Disks mit einer bestmöglichen Automatisation des Backups bei Anschluss an den PC/Server/NAS und ZFS gibt es defacto nicht.
Ja, rsync wäre da vermutlich wirklich einfacher aber dann muss man immer noch selbst Hand anlegen oder sich was skripten was bei Anschluss der externen HDD diese mountet, das vorgefertigte rsync startet und nach Ende die HDD wieder auswirft und ggf. benachrichtigt...
 
Für die Backups will ich Borg nutzen.
https://www.borgbackup.org/

Und ja die automatismen werde ich wohl selber Scripten müssen. Was ich noch überlege ist, wie ich die USB Festplatten automatisch mounte und ein Backup einspiele und gleichzeitig die Festplatten woanders lagere als den Standort des Servers.

Aber ich glaube das hat jetzt nicht mehr so viel mit meiner ursprünglichen Frage zu tun 😉 Aber danke, dass ihr gleich wesentlich weiter denkt, da bekommt man gleich noch ein paar gute Tipps, über die man mal nachdenken kann
 
Zurück
Oben