Synology: Ein Volume pro Shared Folder oder mehrere Shared Folders in einem Volume?

[Whistl0r]

Ich habe hier ein Synology System mit 120 TB nutzbarem Disk-Space.

Auf diesem existieren 27 Volumes, da für jeden "Shared Folder" in der Vergangenheit eben auch immer ein Volume erstellt wurde (dabei auch immer BTRF, d.h. bei diesem Storage gibt es keinen Grund für bestimmte Shared Folders auf ein anderes Dateisystem aus $Gründen zu setzen -- alles ist gleich).

Ich halte das für keine gute Praxis. Im Alltag beobachte ich bspw. meistens folgende Situation:

Einem Volume wurden 10TB zugewiesen, es ist bereits mit 9.5TB Daten belegt. Einem anderen Volume wurden 20TB zugewiesen, dort sind aber nur 7TB belegt.

Da man Volumes nur vergrößern, aber nicht verkleinern kann (https://kb.synology.com/en-my/DSM/tutorial/Shrinking_existing_volume), ist das nun erst einmal ein Problem. Den beschrieben Workaround anzuwenden, d.h. bspw. ein neues 10TB Volume zu erstellen, dorthin dann die 7TB umzuziehen usw. um dann letztendlich das freigewordene 20TB Volume zu löschen damit man dann den Speicher hat um das mit 9.5TB belegte Volume letztendlich zu vergrößern zu können, ist nicht immer einfach so möglich und setzt vor allem voraus, dass man eben noch 10TB für ein neues Volume frei hatte.

Würde man hingegen nur ein Volume verwenden auf welchem man seine ganzen Shared Folders packt, würde man dieses Problem vermeiden.

Wie seht ihr das? Lieber ein Volume pro Shared Folder oder mehrere Shared Folder auf einem Volume?

Bislang wäre der einzige Grund der für ein Volume pro Shared Folder spricht eine indirekte Usability Verbesserung: Über den Storage-Manager sieht man so auf einen Blick, wieviel Storage die einzelnen Shared Folder belegen, da hier eben die Volume-Auslastung angezeigt wird.

Würde man nur ein Volume nutzen, könnte man über diese Übersicht zumindest nicht mehr direkt sehen welcher Shared Folder wieviel Storage belegt. Man müsste sich dann bspw. immer erst die Eigenschaften eines Shared Folders anzeigen (hier wird im Quota-Bereich die aktuelle Nutzung angezeigt).

Aber gibt es abseits dieser "Einschränkung" weitere Gründe die für "ein Volume pro Shared Folder" sprechen bzw. gegen "Mehrere Shared Folder in einem Volume"? Wie handhabt ihr das in der Praxis?

 

[Rickmer]

Ich sehe keinen Grund für solche eine Aufteilung in zig kleine Volumes solange es keinen technischen Grund dafür gibt.
So wie es klingt sind die auch nicht thin provisioned?

120TB ist schon 'ne Hausnummer, und 27 Volumes? Wer hat denn da noch wirklich Überblick? Da hat der PC nichtmals genügend Buchstaben um die alle zu mappen...

(Mir ist klar, dass es alternative Möglichkeiten gibt, Volumes zu mappen ohne einen Buchstaben zu belegen. Danke.)

 

[DHC]

Na ja.
So riesige Datenmengen habe ich nicht.

Ich habe zwei Pools mit jeweils einem Volume (RAID 1 / BTRFS).
Ein Pool / Volume ist zum Arbeiten mit mehreren Shared Folders. Der andere Pool / Volume hat nur einen Shared Folder und dient als Archiv für ältere Daten.

Was für ein NAS hast du?

 

[JumpingCat]

Pro:
- Ein defektes Dateisystem macht nur ein Shared Folder kaputt. Aber Synology hat da diverse Hintergrund-Tasks laufen die bekannten Problemen entgegen wirken.

Contra:

• Deduplizierung wirkt nur auf Volume Ebene
• Caching per nmve läuft nur per Volume ab (oder?)
• Übersichtlichkeit allgemein: Replizieren, etc braucht viel einzelne Jobs und wird unübersichtlich

 

[MaverickM]

Lieber ein Volume pro Shared Folder oder mehrere Shared Folder auf einem Volume?

Ein Volume mit beliebig vielen Shared Folders. Notfalls mit Quotas arbeiten.

Alles andere ergibt aus meiner Sicht einfach wenig Sinn.

 

[MoonTower]

Um solche Volumegrößen zu erstellen brauchst Du viel RAM und bestimmte Modelle von Synology.
https://kb.synology.com/de-de/DSM/t...logy_NAS_have_a_single_volume_size_limitation

Ich wollte mir zunächst das Vorgängermodell der DS1823xs+ kaufen, um Geld zu sparen, hatte dann aber mehr durch Zufall entdeckt., dass meine Konfiguration dann nicht möglich wäre.

 

[NobodysFool]

Also meine DS1821+ ist jetzt mit 8x 18 TB im SHR2 bestückt, und dürfte somit die maximale Volumegröße erreicht haben. Sehe ich aber nicht als Problem. Wenn mir der Platz ausgeht kann ich ja Freigaben, für die der dann freie neue Platz reicht, auf ein zweites Volume schieben um so wieder Platz auf dem ersten frei zumachen. Vorerst wird mir das aber noch eine Weile erspart bleiben. Ich habe jetzt noch ca. 9 TB frei.

Wo ich aber auf jeden Fall auf separate Volume setze ist, wenn Erweiterungen benutzt werden. Wie zum Beispiel bei meinem Zweit-NAS, der DS1815+ mit der DX513 und der DX213. Da haben die Platten in den Erweiterungen jeweils separate Volumes.

 

[Wertzius]

Wow - das würde mir nie in den Sinn kommen? Ein zweites Volume würde ich maximal für eine Expansion Unit erstellen.

 

[Whistl0r]

So wie es klingt sind die auch nicht thin provisioned?

Nein, "Thin Provisioned" habe ich in dem Kontext von Synology auch noch nie gehört. Magst du das ausführen? Wenn ich hier im Storage Pool schaue und ein neues Volume erstellen will, sehe ich nichts dergleichen.

120TB ist schon 'ne Hausnummer, und 27 Volumes? Wer hat denn da noch wirklich Überblick? Da hat der PC nichtmals genügend Buchstaben um die alle zu mappen...

(Mir ist klar, dass es alternative Möglichkeiten gibt, Volumes zu mappen ohne einen Buchstaben zu belegen. Danke.)

Hehe -- "Historisch gewachsen" :-)

Nein, darunter sind auch viele Shares die bspw. nur von Linux-Servern per NFS angesprochen werden. Aber grundsätzlich lief das hier bislang wie folgt ab: Irgendeine Abteilung möchte irgendetwas zentral abspeichern und forderte Netzwerk-Speicher an. Daraufhin wurde für diese Abteilung eben ein Volume erstellt (mind. 10GB) und darauf eine Share. So existieren nun halt zig Volumes die teilweise kaum genutzt wertvollen Speicher der nicht anderweitig verwendet werden kann. Das versuche ich zu ändern.

Was für ein NAS hast du?

Mehrere. RS3621xs+ im Cluster und das mit den 27 Volumes ist ein RS4021xs+ mit RX1217RP (allerdings erst zur Hälfte ausgebaut).

Pro:
- Ein defektes Dateisystem macht nur ein Shared Folder kaputt. Aber Synology hat da diverse Hintergrund-Tasks laufen die bekannten Problemen entgegen wirken.

Ein guter Punkt! Hast du defekte Dateisysteme bei der Synology bereits erlebt? Ich bislang nicht. Zur Risikobewertung würde mich interessieren, was zu Defekten führen kann. Mir fallen da spontan nur Stromausfälle ein gegen die wir aber IMHO gut abgesichert sind (redundante Netzteile an unterschiedlichen Stromkreisen die jeweils eigenes abgesichert sind).

Also meine DS1821+ ist jetzt mit 8x 18 TB im SHR2 bestückt, und dürfte somit die maximale Volumegröße erreicht haben. Sehe ich aber nicht als Problem. Wenn mir der Platz ausgeht kann ich ja Freigaben, für die der dann freie neue Platz reicht, auf ein zweites Volume schieben um so wieder Platz auf dem ersten frei zumachen. Vorerst wird mir das aber noch eine Weile erspart bleiben. Ich habe jetzt noch ca. 9 TB frei.

9 TB freier Speicher klingt für den einen viel, für den anderen nicht: Wir haben z.B. aktuell ein Volumen mit 30 TB Speicher, wo ein MSSQL-Cluster täglich seine Backups hinschiebt. Das Volume ist so gut wie voll. Was machst du hier? Da kannst du ja nur die 9 TB dem Volume zuweisen. Ein neues Volume erstellen kannst du nicht.

Ähnliches Beispiel: Wir haben auch noch ein Volume was bspw. 20 TB groß ist. Dort liegen 12 TB Daten. Die Datenmenge wird sich auch nicht mehr ändern (ist ein Archiv). Und jetzt? Die 8 TB ungenutzter Speicher sind für uns blockiert. Mit den 9 TB kommen wir nicht weiter -- das reicht nicht um ein neues Volume für die 12 TB zu erstellen um anschließend das 20 TB Volume löschen zu können.

Genau diese Fälle hoffe ich ja zukünftig durch "mehrere Shared Folder in einem Volume" vermeiden zu können.

Wo ich aber auf jeden Fall auf separate Volume setze ist, wenn Erweiterungen benutzt werden. Wie zum Beispiel bei meinem Zweit-NAS, der DS1815+ mit der DX513 und der DX213. Da haben die Platten in den Erweiterungen jeweils separate Volumes.

Vom Bauchgefühl her würde ich das wohl ähnlich sehen, weil ich die Erweiterungseinheiten tendenziell als eigenes NAS ansehe. Aber das ist irgendwie auch quatsch.

Vor allem: Eigene Volumes bringen doch nur Nachteile, wenn am Ende alles auf dem gleichen fetten RAID 5,6,10 etc. liegt. Oder achtest du darauf, hierfür dann auch eigene Storage Pools zu erstellen?

 

[Rickmer]

Nein, "Thin Provisioned" habe ich in dem Kontext von Synology auch noch nie gehört. Magst du das ausführen? Wenn ich hier im Storage Pool schaue und ein neues Volume erstellen will, sehe ich nichts dergleichen.

Stimmt, mein Fehler.

Bei Syno gibt es das wohl nur in Verbindung mit dem Erstellen eines LUN auf einem Volume über den SAN-Manager.

Wobei...

Nein, darunter sind auch viele Shares die bspw. nur von Linux-Servern per NFS angesprochen werden. Aber grundsätzlich lief das hier bislang wie folgt ab: Irgendeine Abteilung möchte irgendetwas zentral abspeichern und forderte Netzwerk-Speicher an. Daraufhin wurde für diese Abteilung eben ein Volume erstellt (mind. 10GB) und darauf eine Share.

Diese Anforderung hätte ich persönlich vermutlich eh über iSCSI umgesetzt und dann kann man genauso gut mehrere thin provisioned iSCSI LUNs auf ein Volume ablegen für effizientere Speicher-Ausnutzung.

Wobei ich als Zuständiger eh Alarm schlagen würde wenn hier ein Synology NAS effektiv als SAN genutzt wird. Für Archiv-Daten oder als Backup-Kopie sehe ich kein Problem, aber Synology (sowie QNAP) bieten nicht zufällig keine Serviceverträge an. Wenn's mieß läuft kann ein Austausch einer defekten Komponente sogar Wochen oder Monate dauern. Habe ich schon erlebt...

Wenn dann eine Mehrzahl an Servern mehrere Wochen lang nicht laufen weil kein Zugriff auf die Daten besteht kann die Stimmung in der Firma echt mies werden.

Dann lieber ein 'richtiges' SAN mit interner Ausfallredundanz und entsprechendem Servicevertrag, auch wenn's mehr kostet.

 

[JumpingCat]

Hast du defekte Dateisysteme bei der Synology bereits erlebt?

Ich nutze Synology noch nicht so lange. Btrfs aber schon sehr lange. Ich hatte hat vor vielen Jahren einige Probleme bei bestimmten Workloads (backup per snapshot). Mit regelmäßigen rebalance,etc war das aber nicht mehr aufgetreten. Das ist genau das was Synology auch macht.

 

[NobodysFool]

@Whistl0r Ich habe nur einen Storage Pool auf meinem PrimärNAS, und nur ein Volume mit allen Shares. Die 9 TB sind darauf noch frei. Ich hätte nur das Problem (künftig), sollte ich mit größeren Platten den Pool erweitern (SHR2), dann kann ich den zusätzlichen Platz nicht mehr diesem Volume zuweisen, da ich die Maximalgröße des Volumes bereits habe. Allerdings kann ich dann bestehende Shares bei denen sich das vom Platz ausgeht auf das neue zweite Volume verschieben und gewinne so Platz auf Volume 1. Bei 30 TB wäre ich noch nicht an der maximalen Volumegröße, und hätte noch die Möglichkeit, mit größeren Platten den Pool und das Volume zu vergrößern.

Wenn die Erweiterungsboxen eigene Volumes haben geht das nur, wenn sie auch eigene Storage Pools sind. Bei einem einzigen Storagepool wären die Volumes ja alle über die Platten des NAS und der Erweiterungen verteilt. Dein Hinweis ist hier in sich nicht schlüssig.

Ausserdem macht es meiner Meinung nach insofern Sinn, Expansions mit eigenen Storage Pools und Volumes zu betreiben, weil ein Ausfall einer Expansion wegen Kabel- oder Netzteildefekten sonst sofort alles degraded. Ich habe noch nie ausprobiert wenn man Volumes auf NAS + Expansion ausbreitet, was dann passiert wenn man die Expansion vom Strom trennt. Wenn es gut umgesetzt ist kann man runterfahren, die Expansion wieder in Betrieb nehmen und neu starten und es würde wieder laufen. Aber selbst wenn das im versuch einmal klappen würde, würde ich mich nicht generell darauf verlassen. Daher gehe ich davon aus, dass das RAID in dem Fall hinüber wäre. Daher mache ich das nicht, wenn es keinen absolut unabdingbaren Grund gibt, warum ich das muss.