File Server mit UNRAID (nach ein paar Monaten zum Durchbeissen)

Begonnen von Mam, Dezember 20, 2021, 11:44:44

« vorheriges - nächstes »

Mam

WARNUNG! die folgenden Ausführungen gelten nur, wenn die LAN Anbindung des Fileservers größer oder gleich 5 Gigabit/s ist. Für langsamere LANs lese den Ergänzungsartikel!!!

Ich bin ja, wie schon mal anderweitig erwähnt, auf dem Wege "weg von Windoof" und hin zu Alternativen.

Deshalb habe ich mutig vor ein paar Wochen den alten Windows 2019 Fileserver in Rente geschickt und stattdessen UNRAID (auf Linux basierend) draufgepackt. Es hat einige Zeit gedauert, bis die Daten umkopiert waren und noch längere Zeit, bis ich eine möglichst flotte Konfiguration der Platten hinbekommen habe. So mit "einfach mal alles reinwerfen" wird man nicht glücklich, da muss man schon etwas Planung vorab machen.

Für die, die nicht gerne bis zu Ende lesen wollen: UNRAID ist lahm, wollt ihr schnell, bleibt bei Windows!

Für die, die jetzt noch nicht abgeschreckt sind: weiterlesen, es gibt auch eindeutige Vorteile, an die Windows nicht rankommt!

Also zuerst muß man mal die Philosophie von UNRAID begreifen und die verwendeten Begriffe verstehen. Leider sind die "historisch gewachsen" und tun manchmal gar nicht mehr das, was der originalen Wortbedeutung entsprechen würde.

Die Festplatten unterscheidet UNRAID in "Array" und "Cache-Pools". Zumindest letztere ist völlig daneben, wie wir sehen werden.

Fangen wir mit dem "Array" an, davon kann es derzeit nur eines geben. Ein "Array" sind ersmal nur einzelne, unverbundene Festplatten. Die Unterverzeichnisse dieser Platten stehen als Freigaben zur Verfügung. So kennt man das von überall her.
Aber, es gibt einen wesentlichen Unterschied: Enthalten die Platten Unterverzeichnisse mit gleichem Namen, so werden sie automatisch zusammengefasst zu EINER Freigabe.
Gibt es also auf mehreren Platten das Verzeichnis /Filme, so sehen die Klienten im LAN nur eine Freigabe Filme, aber deren Inhalt umfasst alle Dateien von allen Platten mit /Filme!
Das ist voll cool, denn so kann man bei vollwerdenden Platten einfach Dateien verschieben, oder ne neue Platte dranhängen und dort auch wieder ein Verzeichnis /Filme anlegen und schon ist automatisch mehr Platz da!
Das kann UNRAID sogar automatisch, bei jeder Freigabe kann man angeben, welche Disks sie belegen darf und wo sie nicht hindarf. Neue Dateien werden dann automatisch und möglichst gleichmässig über alle erlaubten Laufwerke verteilt.

Damit dieses Array etwas (daten)sicherer wird, kann man ihm ein oder gar zwei "Parity Laufwerke" zuweisen. Die Vorraussetzung ist allerdings, diese Parity Disks müssen immer die größten (oder gleich groß) Platten aller Teilnehmer des Arrays sein. Die Parität meiner 18Tb Disks zu berechnen dauert etwas über 25 Stunden, aber das macht man ja hoffentlich nicht so häufig.
Mit einem Parity Drive darf eine Datenplatte kapput gehen, bei zweien dürfen bis zu 2 Datenplatten gleichzeitig ausfallen.
Während des Ausfalls werden die fehlenden Daten automatisch errechnet und wenn man eine neue, frische Datendisk für die kaputte reinpackt, wird sie automatisch wieder befüllt. Also im Prinzip wie RAID-5 oder RAID-6, aber hier brauchen die Datenplatten nicht alle gleich groß zu sein!!!

Damit man sich nicht so mit den lahmen aber großen Disks rumplagen muss, kann man noch "Cache Platten" einrichten. Das sollten dann NVMe und / oder SSD Laufwerke sein.

Man weißt diese aber nicht dem Array insgesamt zu, sondern den einzelnen Freigaben.

Das Verhalten dieses "Caches" ist allerdings gewöhnungsbedürftig!

Diese "Cache Pools" haben mehrere Einstellungsmöglichkeiten.

Aber zuerst einmal: sie sind NICHT Teil des Arrays, mit ihren Daten wird die Parität also nicht gefüttert. Ist die Cache Disk kaputt, sind die Daten weg.
Wer das verhindern will, kann jedem Cache Pool eine zweite Platte zuordnen. UNRAID macht dann daraus automatisch und ohne Rückfrage ein RAID-1 (Spiegelung) Array.
Deshalb heißt das "Pool". Der ist natürlich nur so groß, wie die kleinere der beiden Platten.
Bei der Ausfallrate von NVMe oder Sata SSDs muß man sich überlegen, ob man das braucht. Gerade im Falle von NVMes würde ich davon absehen, denn die schnellen Steckplätze sind rar und man kann damit was Besseres anfangen.

Zurück zu den "Cache" Einstellungen:
Die natürliche Einstellung bei den Freigaben wäre "Ja: Cache". Sie klingt so verlockend, man wählt sie fast automatisch. Und, der geneigte Leser ahnt es bereits, sie ist grottenfalsch :-(
Man würde meinen, diese Cache Platte würde für die Freigabe automatisch verwendet und Lese- und Schreibbefehle abfangen und auf die schnelle SSD umleiten. Pustekuchen!
Was es bedeutet ist einfach: beim Schreiben von NEUEN Dateien landen sie erstmal auf der SSD, solange noch Platz ist. Alles bereits vorhandene wird davon nicht tangiert!
Das ist erstmal echt enttäuschend, aber damit muss man leben.
Und die Daten werden auch nicht gespiegelt, geht der Cache kapput, sind die Daten verloren, sie haben es niemals aufs gesicherte Array geschafft.

Dazu gibt es ein Programm "Mover", das normalerweise einmal in der Nacht von Cron gestartet wird. Es verschiebt die Daten vom Cache auf das Array und man verliert dann den Geschwindigkeitsvorteil beim Lesen. Aber zumindest sind sie dann "sicher".

Die anderen möglichen Einstellungen der Freigabe, beeinflußt eben diesen Mover mit.

Bei "Nein" ist klar, neue Daten landen direkt auf dem Array, der Mover wird nie gebraucht.

Bei "Nur: Cache" ist es umgekehrt, neue Daten landen nur auf der Cache Platte und werden vom Mover nie verschoben.

Und zu guter Letzt gibts noch "Bevorzugt: cache", das ist ein Mischmasch. Neue Daten landen im Cache, der Mover verschiebt in der Nacht dann noch Daten vom Array (leider rein zufällig, nicht anhand einer Benutzungsstatistik) zurück bis der Cache voll ist. Damit sind die dann natürlich auch wieder ungesichert.

Bei allen dieser möglichen Einstellungen gibt es kein Verhalten, dass es wert wäre "Cache" genannt zu werden. Deshalb verzichten wir nun auf die Bezeichnung und sagen einfach "Pool".

Wozu die gut sind versteht man erst nach ein wenig "Lernen durch Leiden".

Anfang kam ich auf die Idee, alle Platten (auch die SSDs) ausser Parity und Cache ab ins Array. Ging, funktionierte und war lahm wie Hund :-(
Warum? Ein typischer MAM-zu-Doof-Error. Wenn man die flotten SSDs mit ins Array packt, werden sie auf das normale HD Niveau herabgebremst, denn bei jeder Schreibaktion muss die Parität angepasst und neu geschrieben werden. Und die ist nun mal auf der größten, also langsamsten, Festplatte.
Kann man drauf kommen, bei mir hats aber ein paar Tage gedauert.
Ich hatte recht sorgfältig bestimmte Verzeichnisse (Homeshares, Source, private Dokumente), die besonders flott sein sollten, mit den Einschränkungen "nur Disk3" usw. auf bestimmte Laufwerke gezwungen, aber wie erwähnt, die Parität bestimmt den Takt.
Beim Lesen gehts flott, denn dazu wird die Parität nicht ausgewertet, solange die Originalplatte funktioniert.
Aber Schreiben war echt ermüdend. Gerade mal so 200-300Mb/s.

Also, alles nochmal von vorne (eins der netten Features von Unraid ist, dass man die gesamte Konfiguration löschen kann, die Daten aber weiter erhalten bleiben. Man darf dann nur nicht den Fehler machen, eine Datenplatte mit der Paritätsplatte zu vertauschen! SCHREIBT EUCHT DIE SERIENNUMMERN AUF, SONST KANN ES BÖSE ENDEN!!!)

Alles geslöscht, ein neues Array aufgesetzt, diesmal nur 2*18Gb Daten + 18Gb Parität. Alle verbleibenden SSDs in jeweils einen Pool gepackt und die Freigaben dann entsprechend auf den gewünschten Pool mit "Nur: Poolname" umgeleitet.

Und schon ging die Sonne auf, zumindest für die SSDs.

Sie sind zwar ungesichert, aber das macht mir nix, ich habe ja noch einen Backupserver, der einmal täglich ALLE Disks spiegelt und sich dann selber vom Stromnetz trennt. Statt der viele 2Tb NVMe SSDs hat der aber nur eine 10Tb Platte, die SSDs sind dort Unterverzeichnisse. Aber das reicht, falls mal was abraucht.

Für den Schreibcache des Arrays habe ich nur eine uralte SATA SSD abgestellt, dank Mover ist sie eh meist leer. Da sind ansonsten nur die VM Images drauf (Docker nehme ich nicht). Das reicht um neue Filme recht flott rüberzuschieben (so 450-500Mb/s). Die Homeverzeichnisse liefern so 700-900Mb/s je nach Mondphase (keine Systematik erkennbar, ist mehr oder minder Zufall).

Wie gesagt, Windows war deutlich flotter (mit einem Ram Cache so bei konstant 1,1Gb/s wenn man unter 50Gb Größe blieb), aber ich kann mit UNRAID leben.
(und es sind noch 5 Drive-Bays leer, wo man einfach immer 18Tb Platten nachwerfen könnte)

Vielleicht schalte ich die Parität irgendwann ab. Dank Backupserver brauche ich sie eigentlich nicht. Sie würde nur im Falle eines Ausfalls den Dauerbetrieb sicherstellen. Da hier keine wirklichen User mehr drauf sind, könnte ich einen Ausfall für eine bestimmte Zeit nun auch verdauen.



Ich lese hier nur

Es ist immer wieder interessant etwas über deine Experimente  :D :D :D :D :D zu lesen.

Mam

Zitat von: Ich lese hier nur am Dezember 21, 2021, 01:38:13
Es ist immer wieder interessant etwas über deine Experimente  :D :D :D :D :D zu lesen.
:-* So als Rentner hat man ja viel Zeit   :-*

Manche verbringen sie auf der Couch, ich hingegen stelle mir immer neue Aufgaben, an denen ich dann gnadenlos scheitern kann  ;D ;D ;D ;D

Mam

Wenn man allerdings zuhause nicht mit einem schnellen LAN gesegnet ist, dann sieht die Betrachtung von UNRAID deutlich anders aus:

Solange die Festplatten schneller sind, als die LAN Anbindung macht es keinen Unterschied, ob eine SSD Teil des Arrays ist, oder nicht. Sie wird, wie selbst die "langsamen" großen Platten immer vom LAN ausgebremst.
Bei den heute oft angebotenen 2,5Gbit/s Verbindungen ist man so gerade auf der Kippe. Sie ist noch zu langsam für eine SSD, aber meist zu schnell für ältere Festplatten.

Mit 1Gbit/s ist es aber meist völlig egal, sofern man nicht uralte Festplatten hat, die selbst die 100Mb/s nicht schaffen. Aber moderne Platten sind deutlich flotter als 200Mb/s, sie würden also ausgebremst.

Auf jeden Fall ist in diesen Fällen eine "Cache SSD" immer angebracht, sie nimmt den Schreibstress von der Platte, die ja noch deutlich lahme wird, muss sie doch noch oft zwischen den Spuren hin und herspringen.

NVMes sind aber Perlen vor die Säue geworfen, die sollte man nur für VMs, Docker usw. verwenden.


www.cypheros.de