MrHonk
mit Baby Bruno
- Registriert
- 6 Mai 2021
- Beiträge
- 885
- Erhaltene Likes
- 1.822
Raid-5 ist ja schön und gut, aber ehrlich gesagt finde ich die Array Lösung von Unraid da wesentlich entspannter (und spannender!). Es gibt ein Paritätslaufwerk und dann mehrere Datenlaufwerke, auf denen, wie der Name es schon sagt, deine Daten liegen. Fällt nun ein Datenlaufwerk aus, entfernt man die defekte Platte, schiebt eine neue Platte rein und mit Hilfe des Paritätslaufwerks werden die Daten von der ausgetauschten Platte wiederhergestellt. Und für den sehr unwahrscheinlichen Fall, das zwei Datenplatten mehr oder weniger gleichzeitig ausfallen sollten, könnte man bei Unraid auch noch eine zweite Paritätsplatte definieren. Die einzige Einschränkung, die es gibt ist die, dass das Paritätslaufwerk immer das größte Laufwerk im Array sein muss. Ist das Paritätslaufwerk z.B. 12 TB groß, dann dürfen die verwendeten Datenplatten auch jeweils nur maximal 12 TB groß sein. Dabei spielt es dann aber auch keine Rolle, ob man 3, 4, 5 oder 6 Datenplatten á 12 TB verwendet. Erst wenn man größere Datenplatten verwenden will, muss man zwingend auch die Größe des Paritätslaufwerks erhöhen.
Und mal so angemerkt, das Array muss nicht nur aus HDDs bestehen, da darf auch fleißig gemixt werden (HDD, SSD, NVMe) - alles egal, solange die einzelnen Datenplatten jede für sich keine größere Kapazität haben als das/die Paritätslaufwerk(e).
Und ja, weil beim Schreiben von Daten auf das Array immer auch gleichzeitig die Parität neu berechnet wird, sinkt die Schreibrate ins Array spürbar. Um aber das Schreiben aufs Array für den Benutzer angenehmer zu gestalten, schaltetet man bei Unraid in der Regel ein Cache Laufwerk vorweg, auf dem die Daten, die ins Array geschrieben werden sollen, erst einmal landen, bevor sie dann mit Hilfe eines Movers zu selbst festgelegten Zeiten ins Array geschrieben werden. So kann man z.B. tagsüber mit voller Geschwindigkeit seine Daten aufs Cachelaufwerk schieben und nachts dann z.B. die Daten vom Cachelaufwerk aufs Array kopieren lassen - wobei einem zu der Uhrzeit dann die langsamere Kopiergeschwindigkeit sicherlich nichts ausmacht. Achja, die Daten sind auch dann schon so verfügbar als wären sie direkt im Array, wenn sie sich erst noch auf dem Cachelaufwerk befinden.
Beim Lesen hingegen wird das Paritätslaufwerk nicht benötigt, da erhält man dann immer die volle Geschwindigkeit mit der die Datenplatte liefern kann, auf der die angeforderten Daten auch liegen. Hat man also eine NVMe als Datenplatte im Array und jemand greift darauf über das Netzwerk zu, dann werden die Daten auch mit der vollen Geschwindigkeit geliefert, die entweder das Netzwerk bietet, oder die NVMe. Da die Leseraten von heutigen NVMe Laufwerken aber höher sind als die Geschwindigkeit, die eine 10 GBit Netzwerkkarte liefert, kann man von einer NVMe aus mit voller Netzwerkgeschwindigkeit liefern.
Wer jetzt ganz auf Nummer sicher gehen will, der verwendet als Cache-Laufwerk einen Raid1 Pool, so verhindert man den sehr seltenen Fall, dass das Cachelaufwerk kaputt geht, noch bevor wichtige Daten aufs Array geschrieben worden sind.
Unraid kann zudem sehr gut mit Docker und VMs umgehen ... und mittlerweile gibt es fast alles auch als Docker (z.B. Plex). Wer mag kann auch eine dedizierte Grafikkarte exklusiv an einen Docker oder eine VM binden, sodass dann da auch Hardware-Transkoding mit machbar ist, was die CPU schont. Docker und VMs können auch gezielt CPU-Kerne zugewiesen werden, sodass es da zu keinerlei Leistungseinbußen kommt, wenn mal ein anderes System ebenfalls Rechenzeit von der CPU benötigt. Aber die meiste Zeit läuft das System eh im Idle.
Ganz ehrlich, wenn ich mir dein Budget anschaue, dann würde ich ohne zu zögern zur Selbstbaulösung greifen, so wie es @TotalMayhem schon geschrieben hat. Der späteren Erweiterbarkeit, und die wird kommen, das ist jetzt schon sicher, sind damit quasi keine Grenzen gesetzt.
Und mal so angemerkt, das Array muss nicht nur aus HDDs bestehen, da darf auch fleißig gemixt werden (HDD, SSD, NVMe) - alles egal, solange die einzelnen Datenplatten jede für sich keine größere Kapazität haben als das/die Paritätslaufwerk(e).
Und ja, weil beim Schreiben von Daten auf das Array immer auch gleichzeitig die Parität neu berechnet wird, sinkt die Schreibrate ins Array spürbar. Um aber das Schreiben aufs Array für den Benutzer angenehmer zu gestalten, schaltetet man bei Unraid in der Regel ein Cache Laufwerk vorweg, auf dem die Daten, die ins Array geschrieben werden sollen, erst einmal landen, bevor sie dann mit Hilfe eines Movers zu selbst festgelegten Zeiten ins Array geschrieben werden. So kann man z.B. tagsüber mit voller Geschwindigkeit seine Daten aufs Cachelaufwerk schieben und nachts dann z.B. die Daten vom Cachelaufwerk aufs Array kopieren lassen - wobei einem zu der Uhrzeit dann die langsamere Kopiergeschwindigkeit sicherlich nichts ausmacht. Achja, die Daten sind auch dann schon so verfügbar als wären sie direkt im Array, wenn sie sich erst noch auf dem Cachelaufwerk befinden.
Beim Lesen hingegen wird das Paritätslaufwerk nicht benötigt, da erhält man dann immer die volle Geschwindigkeit mit der die Datenplatte liefern kann, auf der die angeforderten Daten auch liegen. Hat man also eine NVMe als Datenplatte im Array und jemand greift darauf über das Netzwerk zu, dann werden die Daten auch mit der vollen Geschwindigkeit geliefert, die entweder das Netzwerk bietet, oder die NVMe. Da die Leseraten von heutigen NVMe Laufwerken aber höher sind als die Geschwindigkeit, die eine 10 GBit Netzwerkkarte liefert, kann man von einer NVMe aus mit voller Netzwerkgeschwindigkeit liefern.
Wer jetzt ganz auf Nummer sicher gehen will, der verwendet als Cache-Laufwerk einen Raid1 Pool, so verhindert man den sehr seltenen Fall, dass das Cachelaufwerk kaputt geht, noch bevor wichtige Daten aufs Array geschrieben worden sind.
Unraid kann zudem sehr gut mit Docker und VMs umgehen ... und mittlerweile gibt es fast alles auch als Docker (z.B. Plex). Wer mag kann auch eine dedizierte Grafikkarte exklusiv an einen Docker oder eine VM binden, sodass dann da auch Hardware-Transkoding mit machbar ist, was die CPU schont. Docker und VMs können auch gezielt CPU-Kerne zugewiesen werden, sodass es da zu keinerlei Leistungseinbußen kommt, wenn mal ein anderes System ebenfalls Rechenzeit von der CPU benötigt. Aber die meiste Zeit läuft das System eh im Idle.
Ganz ehrlich, wenn ich mir dein Budget anschaue, dann würde ich ohne zu zögern zur Selbstbaulösung greifen, so wie es @TotalMayhem schon geschrieben hat. Der späteren Erweiterbarkeit, und die wird kommen, das ist jetzt schon sicher, sind damit quasi keine Grenzen gesetzt.
Zuletzt bearbeitet:
