Neukonfiguration


Tiras

Recommended Posts

Hi Zusammen,

 

nachdem in der letzten Zeit so viele Probleme durch die aktuelle Konfiguration meines Unraid Servers aufgetreten sind und ich ehrlich gesagt nicht noch mehr Daten verlieren möchte, möchte ich gerne Eure Meinung zu folgender neuen Konfiguration wissen.

 

Aktuell habe ich einen Pool "data" (RAID 6 mit 2 x 4 TB HDD und 3 x 5TB HDD), auf dem sämtliche normale Shares als Cache = "data" und Only erstellt sind.

Dann habe ich ein Pool "services_nvme" (RAID 1 mit 2 x 128 GB) für Shares wie Transcode oder MagentaCloud als Cache = "services_nvme" und Only.

Als letztes habe ich einen Pool "vms_nvme" der nur dem Share "Virtualizations" als Only zugewiesen ist. Nachfolgend ein kurzer Screenshot einer Datenübertragung von Pool "vms_nvme" zu Pool "data (RAID 6)"

image.thumb.png.e7da508dfe8f83070f56332eb551703e.png

 

Nochmal kurz zu meiner Hardware:

Mainboard: Gigabyte x570 Gaming X

CPU: AMD Ryzen 5 4650G PRO

RAM: 2 x 32 GB 2600 MHz

2 x Gigabyte 128 GB NVMe

1 x SanDisk 240 GB SSD

2 x Samsung Evo 970 Plus NVMe

2 x WD 4 TB HDD (CMR)

1 x WD 5 TB HDD (CMR)

2 x Seagate 5 TB HDD (SMR)

1 x WD 6 TB HDD (CMR) - (Dient derzeit um Dateien abzusichern)

 

Konfiguration:

Array (Ohne Parity):

  • SanDisk 240 GB SSD
    • Für Shares wie appdata, Transcode, system

 

Pool_Data (Wird ein RAID 6):

  • 2 x 4 TB HDD
  • 3 x 5 TB HDD

 

Pool_VM (Wird ein RAID 1):

  • 2 x 1 TB NVMe

 

Cache_Service (Wird ein RAID 1):

  • 2 x 128 GB

 

1. Beschreibung:

Den normalen Shares wie Dokumente, Bilder, Medien etc. werden die Disk aus dem Array und zusätzlich dem Cache "Pool_Data" als Prefer zugewiesen.

Dem Share Virtualisierungen wird ebenfalls die Disk aus dem Array, aber dem "Pool_VM" als Prefer zugewiesen.

Shares wie appdata, Transcode und system würde ich die Disk aus dem Array und zusätzlich dem Cache "Cache_Service" als Prefer zuweisen, aber durch die SSD im Array müsste ich das nicht mal.

 

2. Beschreibung:

Den in der 1. Beschriebenen Shares wird nicht die Disk 1 aus dem Array, sondern nur die jeweiligen Pools als Only zugewiesen. Also eigentlich wie die aktuelle Konfiguration. Hier würde ich die Konfiguration nur erneut durchführen, in der Hoffnung, dass die Probleme die ich in den anderen Threads beschrieben habe, behoben werden (Missing Disk, Kopieren / Moven, etc.).

 

Warum diese Konfiguration?

Durch das RAID 6 habe ich ein hohes und ausgeglichenes Write trotz der SMR Platten. Zusätzlich habe ich die Parity gegen das RAID 6 ausgetausch und muss mir keine Gedanken darüber machen, dass die Parity min. so groß ist, wie die größte Disk im Array. Ich würde in beiden Beschreibungen in den "Global Share Settings" die Einstellung für User Share deaktivieren. Die Netzwerkplatten würde ich auf den entsprechenden Clients dann über den Disk Share machen. Damit erhoffe ich mir in Zukunft keine falschen Kopiervorgänge zu machen, die meine Dateien auf 0 KB setzen (wie im Thread Kopieren / Moven beschrieben).

Hinzu kommt, dass alle Shares auf einem Pool liegen und nicht auf unterschiedliche Disk wie in einer Array Konfiguration verteilt werden.

 

Fragen:

  • Den aktuellen RAID 6 Pool habe ich so erstellt, indem ich ein neuen Pool erstellt, die Anzahl der Platten festgelegt und die Platten hinzugefügt habe. Danach habe ich dem Pool den Datentyp (BTRFS Encrypted ) eingestellt. Nachdem ich das Array gestartet habe mussten die Platten im Pool formatiert werden und anschließend habe ich im Pool im Dropdown für "Balance Status" auf Convert to RAID 6 Mode" ausgewählt und auf Balance ausgeführt. War das die richtige Vorgehensweise, um ein RAID 6 zu erstellen oder wie erstellt man ein RAID (6) richtig in Unraid?
  • Wie muss man vorgehen, wenn eine Disk im RAID 6 ausfällt?
  • Da in beiden Beschreibungen die Ordner durch die Auswahl von Prefer oder Only auf den jeweiligen Pools liegen und auch dort erstellt werden, wäre es doch am Besten überall den Pfad vom Pool anstatt vom Share anzugeben, um das Problem mit der 0 KB Überschreibung zu umgehen, oder?

 

Ich hoffe ihr nehmt mir den langen Text nicht übel und ich bin sehr auf Eure Meinungen oder zusätzlichen Ideen gespannt und danke Euch für Eure Unterstützung.

Link to comment
  • 2 weeks later...

Hallo Zusammen,

 

ich habe meine neue Konfiguration nun abgeschlossen und mich für folgendes entschieden, was ich testen möchte.

 

1. Meine Dateien werden vorerst auf einer externen HDD gespeichert. Zusätzlich werden die wichtigen Daten via WebDav mit meiner MagentaCloud synchronisiert. In der MagentaCloud wird jeden 2. Tag ein Backup erstellt. Somit sind die wichtigen Dokumente wie Bilder, Musik, Unterlagen etc. erst einmal safe.

 

2. Habe ich mir aktuell ein Array wie folgt erstellt:

Parity: 1 TB NVMe

 

Array:

Disk 1: 1 TB NVMe (Wird in allen Shares excluded, weil sie nur für Virtualisierungen dienen soll).

Disk 2: 128 GB NVMe

Disk 3: 128 GB NVMe

 

Pool_Daten (RAID 5):

2 x 4 TB HDD

2 x 5 TB HDD

 

Sämtliche Shares - bis auf den VM Share - erhalten als Cache den Pool_Daten als Prefer. Das VM Backup Skript wird täglich ein Backup mit max. 7 Backups durchführen.

 

Die Frage habe ich zwar schon einmal gestellt, aber ehrlich gesagt bin ich mir noch nicht 100%ig sicher, ob ich es ganz verstanden habe ich den Aufwand, den ich wegen meinem Datenverlust durch das falsche Kopieren hatte, möchte ich nicht nochmal haben. Aus diesem Grund wollte ich noch einmal fragen, welchen Share Typ ich nun wählen sollte, um beim kopieren nicht wieder 0 KB Dateien zu erzeugen? Wenn ich darüber nachdenke, dann wäre es besser, den Disk Share Typ zu wählen und via Windows Explorer die Ordnerstruktur zu erstellen. Anschließend bekommen die entsprechenden Clients im Haushalt den relevanten Ordner als Netzlaufwerk über die Disk eingebunden.

 

Der User Share ist meiner Meinung nach sehr Fehleranfällig in Bezug auf kopieren von Share zu Disk. Außerdem war da ja noch die Sache, dass eine Reference einer Datei / Ordner erstellt wird, wenn man diese zwischen Shares kopiert die auf unterschiedlichen Disk liegen, wenn ich es richtig verstanden habe.

 

Was also wäre jetzt die bessere Vorgehensweise? Sollte ich in den Apps und den Clients nun /mnt/user/Sharename oder /mnt/disk1/Sharename verwenden?

 

Vielen Dank für Eure Hilfe/ Antworten.

Link to comment

deine Zusammenstellung verwirrt mich jetzt heute früh doch etwas ;)

 

10 hours ago, Tiras said:

Array:

Disk 1: 1 TB NVMe (Wird in allen Shares excluded, weil sie nur für Virtualisierungen dienen soll).

Disk 2: 128 GB NVMe

Disk 3: 128 GB NVMe

 

ich glaube hier solltest du Dich nochmal einlesen was du hier machst.

 

das kopieren, verschieben, .... auf /mnt/disk....ist die Ursache deiner 0byte files und solltest du eigentlich nicht machen wenn du dir nicht sicher bist, für was und wo machst du das überhaupt ? ist ja per default extra nicht so gedacht.

 

wenn du manuell mit /mnt/disk1/share arbeitest sollte deine "quelle" auch /mnt/disk2/wasauchimmer oder /mnt/cache/wasauchmmer sein ...

 

Beispiel

 

image.thumb.png.8b2c67965630966d89d5340a134f6a64.png

 

so kann nichts passieren da die Datei(en) sich nicht selbst überschreiben können, kann auch /mnt/disk2/... zu /mnt/disk1/... sein ... nur nicht gleich ...

 

jetzt zu dem was du (anscheinend) machst

 

image.thumb.png.5f6bd4583b708b4a5e56d361de6dd753.png

 

das ist der Tanz auf der Rasierklinge ... und zerschießt gerne deine Dateien wenn auf disk1 bereits Daten liegen ... ich denke hier liegt dein grundsätzliches Problem und das hat nichts mit deinen Array, Pool, Raid Einstellungen zu tun.

 

Nochmals zu deinem Platten Setup, das würde ich grundsätzlich überdenken nachdem ich mich eingelesen hätte.

 

"Normal", alle HDD's ins array mit mind. 1 parity (Größe beachten da parity mind. die Größe der größten Platte haben muss), cache pool(s) anlegen für die "schnellen" Dinge ;) docker(s), appdata, vm(s), was auch immer ... dann einstellen welche shares only (nur auf dem cache), prefer (bevorzugt auf dem cache, wird hin und her geschoben bei Bedarf), oder yes (erst cache, nach mover dann automatisch auf array und dort verbleibend) ... usw usw usw

 

Beispiel jetzt wo bei Dir zwar nicht passt, aber "einfach" sind (mein setup)

 

array 4 HDD Platten (da du sicherheitsbewusst bist wäre hier noch mind. 1 parity von mind. 8 tb vorzusehen)

cache als nvme, hier liegen bei mir docker, appdata, system und cache yes shares

vms als nvme (2. cache drive), hier liegen bei mir nur die vms als cache only drauf

image.thumb.png.081459cdb78dd2edaed542a261ed0ac9.png

 

wenn mein cache voll läuft schiebt der mover die cache yes, prefer, ... Daten auf das array, da dies jedoch Glaubensfragen aufwirft ;) bitte lesen und selbst entscheiden was für einen cache mode du wo nutzen möchtest, yes, prefer, ... aber hör auf manuell Dateien zu verschieben wen du dir nicht sicher bist was du da machst denn das war sicher die Ursache deiner ganzen Aktion ... ;)

 

hier siehst du mal mein setup und auch annhand free space wie sich onnly, prefer, yes ... darstellen.

image.thumb.png.2d21b249680d58e87bf1bc642ca4d1cc.png

 

aber wie gesagt, hierzu besser nochmals grundsätzlich einlesen

Link to comment
11 hours ago, Tiras said:

Der User Share ist meiner Meinung nach sehr Fehleranfällig in Bezug auf kopieren von Share zu Disk.

 

Wie schon mal von mehreren Seiten in Deinem folgenden Thread erwähnt, ist das Kopieren/Verschieben von User Shares nach Disk Shares extrem gefährlich. Kopieren/Verschieben sollte nur von User Share nach User Share oder Disk Share nach Disk Share erfolgen.

 

Das hat nichts mit Fehleranfälligkeit zu tun sondern liegt in der Natur der Sache. Die Summe aller Wurzel-Ordner auf allen Disks bilden User-Shares (Exclude/Include Regeln mal ignoriert). Wenn Du nun von einem User Share nach einem Disk Share kopierst, dann könntest Du Dateien durch sich selbst überschreiben. Das endet i.d.R. in einem Disaster.

 

 

Link to comment

Guten Morgen und vielen Dank für eure Antworten.

 

Mir ist schon klar, dass ich Kopiervorgänge falsch durchgeführt habe, weil ich es einfach von Windows gewohnt war vom "Datenträger C/Temp" zu "Datenträger D/Temp2" ohne Probleme kopieren zu können. Hier habe ich festgestellt, dass es zu Fehlern führt, wenn ich Dateien/Ordner von einem Share der auf Disk 1 liegt auf einen Share, der auf Disk 2 liegt, kopiere.

In dem anderen Thread habe ich mgutt (bitte nicht falsch verstehen) so verstanden, dass Kopiervorgänge von Share zu Share, die sich auf der gleichen Disk befinden mit /mnt/user machen sollte. Wenn man Kopiervorgänge von Disk1/Share zu Disk2/Share macht, dann mit /mnt/disk1 zu /mnt/disk2

 

Ich mache das ganze mit dem RAID und den NVMe´s im Array, weil ich die Dokumentation so verstandenen habe, dass die Parity keine Dateien wiederherstellt und in dem ein- oder anderen Beitrag erwähnt wurde, dass die Parity keine Backupmethode ersetzt und man sich darüber ebenfalls Gedanken machen sollte.

Die Aufgabe einer Parity liegt meiner Meinung nach darin, dass sie Informationen über Disks enthält, wo z.B. Ordner/Dateien sich befinden.

Sollte eine Disk ausfallen, dann werden die Daten nach dem Austausch wieder auf der ausgetauschten Disk hergestellt.

 

Um somit etwas mehr Sicherheit für meine Daten zu haben, habe ich das RAID 5 erstellt. Zum einen hat das den Vorteil, dass die unterschiedlichen Plattentypen gleichermaßen behandelt werden (R/W) und zum anderen, dass ich mir bzgl. Parity Größe keine Gedanken machen muss.

Es wäre nichts anderes, wenn ich hier eine Synology oder QNAP stehen hätte, dort die Daten liegen würde und ich eines der beiden System als SMB Share eingebunden hätte. Der Unterschied liegt hier nur, dass die Daten im RAID 5 bei mir auf dem gleich System liegen, was meiner Meinung nach auch kein Problem sein sollte.

 

@alturismo In vielen Beiträgen wurde mir empfohlen, dass ich vermeiden sollte ein Cache als Only zu verwenden. Wenn ein Cache als Yes eingebunden wird, dann werden die Daten zuerst in den Cache geladen und "erst" nach dem starten des Movers, werden die Daten auf das Ziel "verschoben". Bei Prefer bleiben die Daten bis zum Nimmerlandstag auf dem Cache, es sein denn, der Speicher auf dem Cache neigt sich dem Ende, aber bei Prefer wird der Mover ignoriert. Es gibt jedoch eine Ausnahme: Wenn ein Share erstellt wird, dort ein Cache als Prefer eingebunden wird, dann werden die Ordner/Datei bei der nächsten Ausführung des Movers auf den Cache geschoben.

 

Meiner Meinung ist es eigentlich egal, ob das Array aus HDDs, SSDs, USB-Sticks oder NVMe´s besteht. Wichtig ist - und das hat @mgutt sehr gut erklärt - das man bei den Platten generell (nicht nur bei Unraid) auf den Plattentypen (SMR vs. CRM) achten sollte. Ob ich als 10 x 5TB SSDs und eine 5 TB SSD als Parity konfiguriere oder HDDs ist egal. Es geht hier um die Verarbeitung der Anfragen und nicht nur um die Kapazität.

 

Ich werde zukünftig nur noch /mnt/user/share verwenden. Ich hoffe das klappt auch, wenn die Shares auf unterschiedlichen Disks liegen.

Link to comment
17 minutes ago, Tiras said:

Ich werde zukünftig nur noch /mnt/user/share verwenden. Ich hoffe das klappt auch, wenn die Shares auf unterschiedlichen Disks liegen.

 

klar, dann steuert unraid was, wo und wie ...

 

und Thema cache only, prefer, was auch immer ... alles richtig und siehe meine Anmerkung "Glaubensfrage", Du entscheidest, da halte ich mich gerne raus da du ja bereits bestens informiert bist zu dem Thema und einen Leitfaden hierzu hast.

 

Viel Spaß dann jetzt mit unraid, deine Überschreibungen sollten ja jetzt Geschichte sein wenn du die Finger von /mnt/diskx lässt ;)

Link to comment
1 hour ago, Tiras said:

Um somit etwas mehr Sicherheit für meine Daten zu haben, habe ich das RAID 5 erstellt.

Meiner Ansicht nach ist das ein RAID6:

https://carfax.org.uk/btrfs-usage/?c=1&slo=1&shi=100&p=2&d=4000&d=4000&d=5000&d=5000&d=5000

 

Bei einem RAID5 sollte man 18TB Speicherplatz haben, aber du hast 13TB:

image.png.af326b9c3bbfd4eb6d8873991fca3be5.png

 

Das wäre dann ein RAID6:

https://carfax.org.uk/btrfs-usage/?c=1&slo=1&shi=100&p=1&d=4000&d=4000&d=5000&d=5000&d=5000

 

1 hour ago, Tiras said:

hat das den Vorteil, dass die unterschiedlichen Plattentypen gleichermaßen behandelt werden (R/W)

Dazu habe ich dir schon mal gesagt, dass es absolut untypisch ist, dass man überhaupt mit den HDDs arbeitet. Ich habe verstanden, dass du dadurch deine SMR HDDs schneller nutzen kannst, aber was bringt es leise und kleine Platten zu haben, die ständig laufen, wenn man stattdessen 2 bis 4 große CMR HDDs haben könnte, die den ganzen Tag aus sind? Schlussendlich ist deine Motivation eher eine Budgetfrage. Also mit dem was du an Komponenten hast, ist deine Lösung denke ich ok, wobei ich nicht verstehe warum du die zweite NVMe ins Array gepackt hast. Lass sie doch als RAID1 oder wolltest du von BTRFS weg?

 

1 hour ago, Tiras said:

weil ich es einfach von Windows gewohnt war vom "Datenträger C/Temp" zu "Datenträger D/Temp2" ohne Probleme kopieren zu können.

Du hast aber nicht in unterschiedliche Ordner kopiert, geschweige denn von C auf D, sondern von C:/ordner auf C:/ordner. Quelle und Ziel waren also identisch. In quasi allen Betriebssystemen können zwei verschiedene Pfade auf das selbe Ziel verweisen. Und genau das ist bei /mnt/user/sharename und /mnt/disk1/sharename der Fall. Und wenn du die Quelle mit sich selbst überschreibst, kommt es eben im idealen Fall zu einem Fehler und im anderen zur Zerstörung der Datei.

 

 

In Windows geht das übrigens auch, aber es kommt zum Glück zu einem Fehler:

image.png.927c72bcee71c5cb84e3e1f563eb7977.png

 

 

In Linux führt das normalerweise auch zu einem Fehler. Hatte ich dir ja gezeigt. Aber nicht, wenn Fuse im Einsatz ist. Und Unraid nutzt bei "/mnt/user" eben Fuse (da es alternativlos ist). Ich habe dazu mal ein Issue aufgemacht, aber Fuse hat aktuell keinen fest zugeordneten Entwickler, weshalb es unwahrscheinlich ist, dass sich da jemand in absehbarer Zeit drum kümmert:

https://github.com/libfuse/sshfs/issues/262

 

 

 

Link to comment

Also laut den Daten im Pool ist es ein RAID 5.

image.thumb.png.d8372a80ecde1e4e2b6f6f09e1fdb133.png

 

Du hast recht, dass ich die 2 x 1 TB NVMe´s auch in ein Pool hinzufügen dem Share den Pool als Prefer zuweisen kann. Vielleicht mache ich das noch, da noch keine VM erstellt ist.

Wie läuft es dann ab, wenn Share "x" auf Disk 1 liegt, durch die Daten in Share "x" die Disk 1 nun voll läuft und weitere Daten auf Disk 2 speichert. Somit ist der Share "x" einmal auf Disk 1 und auf Disk 2. Wenn in Share "x" ein Dokument liegt mit 45 MB und nach Änderungen das Dokument nun 84 MB hat und der Platz nicht ausreicht, dann müsste die Datei ja von Disk 1 auf Disk 2 verschoben werden und somit wäre es ja dann auch ein Kopieren/ Verschieben von Disk zu Disk. Wir das Dokument nun lokal gespeichert und bearbeitet, anschließend wieder in den Pool kopiert, dann wäre es ja ein Share => Disk Kopiervorgang, oder nicht?

Link to comment
31 minutes ago, Tiras said:

Wenn in Share "x" ein Dokument liegt mit 45 MB und nach Änderungen das Dokument nun 84 MB hat und der Platz nicht ausreicht, dann müsste die Datei ja von Disk 1 auf Disk 2 verschoben werden

Wenn wirklich überschrieben wird und nicht erst gelöscht oder wie bei manchen Backup-Softwares, erst eine temporäre Datei erstellt, dann wird die Datei auf Disk 1 größer und nicht auf Disk 2 verschoben. Falls man die Platten wirklich so krass auslastet, könnte man in den Share-Einstellungen einen Minimum Free Space einstellen:

image.png.7b90699b279154ee046d98ce00531f56.png

 

Auf die Art bleiben auf der jeweiligen Disk 100GB frei und wenn bestehende Dateien überschrieben werden, kann diese Datei fehlerfrei wachsen. 

 

Wenn man allerdings "High-Water" eingestellt hat, ist das überflüssig, da Unraid dann ja eh schon zwischen den Disks je nach Füllstand springt. Damit dann eine Disk komplett voll wird, müssen erstmal alle voll sein.

 

31 minutes ago, Tiras said:

Also laut den Daten im Pool ist es ein RAID 5.

 

Stimmt. Unraid macht ja ein RAID1 für die Metadaten. Daher kommt das. Ist also korrekt.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.