Storage und Snapshots: Eine Übersicht zu Volume-Typen und Speicherpool

[PROLOG]
Da haben wir uns mal 'nen QNAP-NAS gekauft und können unmöglich alle Funktionen überblicken, die dieses Gerät mit sich bringt:

Netzwerkeinstellungen, Einrichtung von Backups und auch noch Multimediaserver will alles eingerichtet sein. Container und VM kann das Teil auch noch, man muss fast schon studiert haben um sämtliche Funktionsumfänge zu kennen oder gar einrichten und verwalten zu können. „NAS“ bedeutet dabei eigentlich "Network Attached Storage", es ist also in erster Instanz ein netzwerkgebundener Datenspeicher.

Datenspeicher: Diese rudimentäre Funktion spielt sich bei QNAP-NAS hauptsächlich in "Storage und Snapshots" ab, doch irgendwie scheint das Verständnis für diese Grundfunktion nicht immer ausreichend vorhanden zu sein: Plötzlich warnt das NAS, dass der Speicherplatz ausgereizt sei... kann doch nicht sein?! Statisches, Thin oder Thick Volume... Speicherpool... was?! Selbst die Entscheidung, welcher Volume-Typ bei der Einrichtung erstellt wird, fällt vielen schwer.

Eigentlich hatte ich begonnen einen Artikel über die Gesamtheit von "Storage und Snapshots" zu schreiben. Die letzten Worte meines Entwurfs lauten: *Lecko mio, was habe ich mir hier nur vorgenommen?*

Das ist einfach zu viel für einen Artikel, daher möchte ich hier auf ein Thema eingehen, das immer wieder Fragen aufwirft: Volume-Typen und Speicherpool.

Dabei möchte ich die unterschiedlichen Volume-Typen kurz beschreiben und anschließend auf die Anzeigen zur verwendeten Kapazität eingehen. Ich hatte mir dazu einst selbst ein PDF zusammengeschustert, mit dem ich mir die Kapazitätsinformationen erklärt habe, dies werde ich nun einmal aufarbeiten und vervollständigen.

[ALLGEMEINES]
Auf geht´s, wir befinden uns in Storage und Snapshots > Storage/Snapshots.

Wir finden hier eine Übersicht über alle internen Speichermöglichkeiten, also "Bereiche" die auf den internen Festplatten/SSD zum Speichern von Daten eingerichtet sind.

In einem frisch aufgesetzten QNAP-NAS ist diese Seite zunächst leer, sofern die Entscheidungen nicht schon bei der Initialisierung (Ersteinrichtung) getroffen wurden. Über die Buttons "Neuer Speicherpool" oder „Neues Volume“ hat man nun die Qual der Wahl. Sind erstmal Volumes und/ oder ein Speicherpool erstellt, erhält man hier auch Informationen über die Belegung und Verwendung der Kapazität.

[VOLUME-TYPEN UND SPEICHERPOOL]

Speicherpool
Ein Speicherpool ist ein zusätzlicher, vorgelagerter Bereich zu den Volumes, der sich über die gesamte Kapazität auf einem Datenträger (bzw. RAID-Verbund) erstreckt. In einem Speicherpool können mehrere Thin- und/ oder Thick-Volumes erstellt werden. Ein Speicherpool (fortlaufend „Pool“ bezeichnet) bietet auch die Möglichkeit, Daten blockbasiert (physisch adressiert, Motto „Nullen und Einsen direkt vom Datenträger“) in dem Pool zu speichern. Im Gegensatz zur weitläufigen dateibasierten Speicherung (logisch adressiert, Motto „Inhaltsverzeichnis - an welcher Stelle liegt denn die Datei xy.zz?) ist die blockbasierte Methode schneller; es gibt kein Dateisystem das gelesen/ beschrieben werden muss, die Daten werden direkt vom Datenträger gelesen/ geschrieben.

Die direkte Ablage von Nutzdaten ist hier allerdings nicht möglich, der Bereich wird (neben den erstellten Volumes) für die Ablage von Snapshots verwendet.

Nur durch das Vorhandensein eines Speicherpools ist es überhaupt möglich Snapshots zu verwenden. Ein Speicherpool muss mindestens 144GB Kapazität haben, daher eignen sich „kleine“ SSD´s nicht.
Übrigens: es wird ein Teil der Kapazität für das System geopfert, der nicht in die 144GB mit einfließt.

Ein Pool wird nur für Thin- und Thick-Volumes benötigt. Statische Volumes müssen ohne Pool erstellt werden.

Speicher Pool – Snapshots
Ohne näher auf Snapshots eingehen zu wollen, muss es an dieser Stelle einfach kurz angerissen werden:

Snapshots liegen wie bereits erwähnt im Pool und benötigen auch eine entsprechende Kapazität aus dem Pool. Diese hängt lediglich von der Größe der getätigten Änderungen und der Anzahl an aufbewahrten Snapshots ab.

Optional reserviert QTS einen bestimmten Anteil (relativ oder absolut konfigurierbar) für Snapshots. Diese Kapazität (Garantierter Snapshot Speicherplatz) ist nicht für Volumes verwendbar. Ist keine Kapazität (oder zu wenig) für Snapshots reserviert, werden diese dennoch in die freie Pool-Kapazität geschrieben, aber automatisch gelöscht sobald die Kapazität von einem Volume benötigt wird.

Bevor es weitergehen kann müssen zunächst noch ein paar Begriffe erläutert werden, da diese ultimativ wichtig sind, um die Unterschiede und das Verhalten zu verstehen sowie die angezeigten Informationen deuten zu können:

physische Kapazität
Die physische Kapazität beschreibt die "netto"-Kapazität eines Datenträgers.
Eine 4TB HDD hat z.B. eine physische Kapazität von ca. 3,63TB. Das resultiert aus der unterschiedlichen Angabe (dezimal/ binär) der Kapazität.

nutzbare Kapazität

Hiermit beschreibe ich die Kapazität, die nach Abzug der Kapazität, die sich das Betriebssystem oder Dateisystem einbehält, zur freien Verwendung verfügbar ist.
=> physische Kapazität - vom System einbehaltene Kapazität = nutzbare Kapazität

definierte Kapazität

Hiermit beschreibe ich die Kapazität, die für ein Volume festgelegt/ eingestellt wurde. Man könnte es also auch salopp „Volumegröße“ nennen.
Über diese Kapazität hinaus kann ein Volume nicht beschrieben werden.

zugewiesene Kapazität

Der Begriff beschreibt die Kapazität, die ein Thin- oder Thick Volume dem Speicher Pool aktuell entzieht. Diese Kapazität ist immer dem entsprechenden Volume vorbehalten und steht daher nicht für andere Zwecke zur Verfügung. Dies muss nicht die für das Volume definierte Kapazität sein!

Welcher Parameter die zugewiesene Kapazität ausmacht ist abhängig davon, ob es sich um ein Thin- oder Thick-Volume handelt. Mehr dazu bei den Volume-Typen und später bei den Kapazitätsinformationen.

verwendete Kapazität

Dies beschreibt die Kapazität in einem Volume, die tatsächlich mit Daten belegt ist.

Kommen wir nun zu den verschiedenen Volume-Typen:

Statisches Volume

1. Ein statisches Volume ist die einfachste Form eines Volumes, es befindet sich direkt auf dem Datenträger, also nicht in einem Pool.
2. Seine Kapazität erstreckt sich immer über den gesamten Datenträger (bzw. RAID-Verbund).
3. Es kann nachträglich nur durch Löschung des Volumes und den darin liegenden Daten verändert/ konvertiert werden.
4. Statische Volumes unterstützen keine Snapshots (da kein Pool vorhanden).
5. Statische Volumes bieten höchste Performance - so sagt man jedenfalls.

Thick-Volume

1. Ein Thick-Volume muss in einem Pool erstellt werden.
2. Dabei besteht die Möglichkeit mehrere ^[1] Volumes von definierter Kapazität zu erstellen, auch in Kombination mit Thin-Volumes.
3. Ein Thick-Volume kann nachträglich in seiner Größe verändert werden, ohne dass es zur Löschung von Daten kommt. Es kann auch in ein Thin-Volume konvertiert werden ^[2].
4. Da das Volume in einem Pool liegt besteht die Möglichkeit Snapshots davon zu erstellen.
5. Thick-Volumes sind (angeblich) nicht so sehr performant wie ein statisches Volume.
6. Einem Thick-Volume ist immer die für das Volume definierte Kapazität aus dem Pool zugewiesen, egal wie viel Kapazität tatsächlich verwendet wird.

Thin-Volume

1. Ein Thin-Volume muss in einem Pool erstellt werden.
2. Dabei besteht die Möglichkeit mehrere ^[1] Volumes von definierter Kapazität zu erstellen, auch in Kombination mit Thick-Volumes.
3. Ein Thin-Volume kann nachträglich in seiner Größe verändert werden, ohne dass es zur Löschung von Daten kommt. Es kann auch in ein Thick-Volume konvertiert werden ^[2].
4. Da das Volume in einem Pool liegt besteht die Möglichkeit Snapshots davon zu erstellen.
5. Thin-Volumes sind weniger performant als ein Thick-Volume.
6. Einem Thin-Volume ist nur die Kapazität aus dem Pool zugewiesen, die auch wirklich verwendet wird, also mit Daten belegt ist.
   Genauer gesagt wird etwas mehr Kapazität zugewiesen, damit für neue Daten auch sofort Kapazität zur Verfügung steht, ohne dass diese erst noch zur Verfügung gestellt (zugewiesen) werden muss.
7. Thin-Volumes sind überprovisionierbar. Das bedeutet, dass die gesamte definierte Kapazität aller Volumes die nutzbare und physische Kapazität des Datenträgers (bzw. RAID-Verbunds) übersteigen kann. Das liegt in ihrer Eigenschaft von 6), hierbei ist allerdings unbedingt darauf zu achten, dass der Pool niemals an sein Limit kommt.
   Entsprechende Warnmeldungen gibt QTS bei der Überprovisionierung aus.
8. Eine Überprovisionierung sollte nur dann stattfinden, wenn man genau weiß warum man das tut und wie man damit umgeht. Durch Unachtsamkeit besteht die Gefahr von Datenverlust!

[1]

Die Aufteilung in mehrere Volumes hat nichts mit späteren Berechtigungen zu tun, sondern vielmehr mit der Einteilung in mehrere Dateisysteme mit -sofern gewünscht- unterschiedlichen Parametern. So ist durch einen Fehler im Dateisystem beispielsweise nur ein Volume betroffen und nicht der gesamte Datenbestand. Die Verwendung entsprechender Parameter ermöglicht es das Volume für die Speicherung von vielen kleinen oder wenigen großen Daten zu optimieren, je nach Bedarf eben. Bei Verwendung von Snapshots besteht so auch die Möglichkeit, die Snapshots entsprechend der Relevanz zu organisieren: Von manchen Daten braucht man gar keine Snapshots, von anderen mehr, von anderen weniger - alles eine Frage der Struktur.

[2]

Vorsicht! Das sollte nicht ohne aktuelle Backups erfolgen!
Hierbei muss einiges durch QTS berechnet werden und das kann auch mal schief gehen. Ich habe damit glücklicherweise einst nur auf einem Testsytem Schiffsbruch erlitten.

[KAPAZITÄTSINFORMATIONEN]
In der Übersicht der Pools und Volumes (Storage/Snapshots) finden wir Informationen über die Verwendung der Kapazität in Form von bunten Balken. Fährt man mit der Maus über die Balken, erhält man die zugehörige Legende samt absoluter und relativer Werte. Diese will ich nachfolgend für die unterschiedlichen Volume-Typen und Kombinationen beschreiben.

Bitte beachtet, dass manche Angaben in QTS gerundet werden und spätere Rechnungen in diesem Artikel daher von den angezeigten Werten abweichen können.

Statisches Volume
So einfach wie das Volume selbst ist, ist auch die Information zur Belegung zu deuten:static.JPG

Es handelt sich hier um eine 128GB SSD mit einer physischen Kapazität von 119,24GB und einer nutzbaren Kapazität von 95,96GB. Das statische Volume geht über die gesamte nutzbare Kapazität von 95,96GB, denn von der physischen Kapazität wurde ein Teil vom Betriebssystem sowie Dateisystem eingenommen, die uns für die weitere Verwendung nicht zur Verfügung steht ^[3].

Von den 95,96GB werden 16,34GB verwendet und demnach sind 79,53GB frei.

Der rote Balken markiert den Schwellwert/ die Kapazität (80% = ca. 76GB) bei dem das Gerät eine Warnung ausgibt, dass das Volume bald voll ist. Diesen Schwellwert kann man anpassen oder abschalten. Sollte man Daten auf das Volume schreiben wollen, für die nicht ausreichend freie Kapazität vorhanden ist, so wird dies vom jeweiligen Betriebssystem moniert, wie man es üblicherweise gewohnt ist (Fehlermeldung „zu wenig Speicherplatz“).

[3]

Das hat nichts damit zu tun, dass es sich hierbei um das System-Volume handelt, auch von nicht-System-Volumes wird ein Teil der Kapazität vom Betriebssystem eingenommen, da das Betriebssystem auf allen Datenträgern gespiegelt wird. Das Dateisystem behält ebenfalls von jedem Volume etwas ein.

Speicherpool (1/2)
Hier werden erwartungsgemäß Angaben gemacht, wie die Kapazität des Pools verwendet wird. Damit das deutlich wird sollten wir uns zunächst jedoch die Thin- und Thick Volumes anschauen, dabei werde ich dann auch auf den Speicherpool eingehen. Anschließend zeige ich noch ein paar weitere Szenarien bzgl. der Speicherpool-Nutzung.

Thick-Volume
Auch beim Thick-Volume sind die Kapazitätsinformationen leicht zu deuten:
thick.PNG

Für das Volume wurde eine Kapazität von 100GB definiert. Das Betriebssystem zwackt sich aus diesem Volume nichts ab, die erforderliche Kapazität holt sich das Betriebssystem direkt aus dem Speicherpool, jedoch behält das Dateisystem 1,8GB ein, sodass 98,2GB nutzbar sind. Im Beispiel werden 4,83GB verwendet und 93,36GB sind frei. Der rote Balken markiert ebenfalls die 80% Schwelle, bei der eine Warnung ausgegeben wird, dass das Volume ans Limit gerät. Auch hier wird durch das jeweilige Betriebssystem moniert, wenn man Daten schreiben möchte für die nicht ausreichend freie Kapazität zur Verfügung steht. Da sich das Volume in einem Speicherpool befindet, finden wir das Volume auch in der Speicherpool-Übersicht (Übersicht > Speicher) wieder:

pool_thick.PNG

Da in dem Pool zwei Thick Volumes mit jeweils 100GB definierter Kapazität liegen, wird uns hier angezeigt, dass 200GB des Pools den Thick-Volumes zugewiesen sind. Die Angabe bezieht sich also auf die definierte Summe aller Thick-Volumes.

Thin-Volume
Beim „komplizierten“ Thin-Volume finden wir eine weitere Angabe, der Rest ist soweit identisch zum Thick-Volume:
thin.PNG

Hier werden ebenfalls 4,83GB verwendet, die zusätzliche Angabe „zugewiesen“ teilt uns mit, wie viel Kapazität dem Pool für dieses Volume aktuell entzogen wird. Das sind in diesem Fall 6,10GB, also etwas mehr (1,27GB) als eigentlich verwendet und benötigt wird. Grund dafür ist, wie oben bereits angesprochen, dass dadurch sichergestellt wird dass für neue Daten stets freie Kapazität zur Verfügung steht, denn ein Volume kann nur in dem Bereich beschrieben werden der ihm auch zugewiesen wurde, was beim Thin-Volume dynamisch erfolgt. Der Wert, wie viel mehr dem Volume zugewiesen wird, ist nicht einstellbar und liegt bei mir immer um 1-2% der definierten Volume Kapazität.

Auch hier moniert das jeweilige Betriebssystem, wenn die definierte Kapazität erreicht und kein Platz für die zu schreibenden Daten verfügbar ist. Dies geschieht allerdings nicht, wenn überprovisioniert wurde und die freie Kapazität des Pools erschöpft ist. Hierbei kommt es unweigerlich zu Problemen und Datenverlust, da ein anderes System nur die freie Kapazität im Volume „sieht“, nicht aber ob auch im Pool ausreichend freie Kapazität vorhanden ist, was beim Einsatz von Thin-Volumes essentiell ist. Auch dieses Volume finden wir in der Pool-Übersicht wieder:

pool_thin.PNG

Hier sehen wir auch nochmal die definierte Kapazität (100GB) und wie viel davon tatsächlich zugewiesen ist (6,1GB). Würden mehrere Thin-Volumes existieren, würde hier entsprechend die Summe der für Thin-Volumes definierten und zugewiesenen Kapazitäten angezeigt werden.

Speicherpool (2/2)
Nachdem wir nun die ersten Einblicke in die Pool-Übersicht gewagt haben, betrachten wir die Ansicht nun nochmal in der Gesamtheit:

pool_1.PNG
Die Kapazität des Pools beträgt 456,27GB, dies ist an dieser Stelle jedoch nicht ersichtlich

Übrigens: die Kapazität die das Dateisystem für Metadaten einbehält ist in dieser Ansicht ebenfalls nicht berücksichtigt. Diese Kapazität fließt auch nicht in die zugewiesene Kapazität bei Thin-Volumes mit ein.
Sys. reserviert

Das System nimmt sich 71,1GB aus dem Pool, da das Betriebssystem auf alle Datenträger gespiegelt wird. => Dem Speicherpool werden dadurch 71,1GB entnommen.

Thick-Volume

Allen Thick-Volumes sind insgesamt 200GB zugewiesen, bei Thick-Volumes entspricht das der Summe der defininierten Kapazitäten. => Dem Speicherpool werden dadurch 200GB entnommen.

Thin-Volume

Allen Thin-Volumes sind insgesamt 6,1GB zugewiesen, die definierte Kapazität aller Thin-Volumes entspricht 100GB. => Dem Speicherpool werden dadurch aktuell 6,1GB entnommen.

Freier Speicher

Es ergibt sich eine freie Kapazität von 179,0GB, welche noch Volumes zugewiesen kann und in der Snapshots untergebracht werden können.

Abonnement

Das Abonnement ist die Summe der definierten Kapazitäten zzgl. der Kapazität für das System und wird hier relativ angegeben, absolut entspricht dies ca. 371GB. Daraus folgt, dass noch 18,7% bzw. 86,64GB zur Verfügung stehen, um Volumes zu vergrößern oder neue zu erstellen, ohne dass überabonniert werden muss. Dies scheint im Widerspruch zu dem angegebenen freien Speicher zu stehen, ist aber völlig korrekt, da im freien Speicher auch jene Kapazität enthalten ist, die für ein Thin-Volume zwar definiert, aber noch nicht zugewiesen ist. In diesem Fall sind dies 100GB - 6,1GB = 93,9GB. Addieren wir dies zu den nicht abonnierten 68,64GB, erhalten wir wieder den Wert des freien Speichers: 86,64 + 93,9GB = 180,54GB. (Ich verweise nochmal auf die Abweichung durch das Runden von QTS an manchen, aber nicht allen Stellen)

Irgendwie ziemlich trockener Stoff mit etwas Mathematik, hatte ich mir spannender vorgestellt, aber leider sind wir noch längst nicht am Ende, denn neben der bisher behandelten Übersicht, gibt es noch weitere Informationen zum Pool unter Speicher/Snapshots:

pool_2.PNG

Es handelt sich weiterhin um den Pool mit einer Kapazität von 456,27GB, was uns hier auch angezeigt wird.

Volume/LUN

Dies ist die Summe der zugewiesenen Kapazität und beinhaltet auch die Kapazität, die sich das System einbehalten hat.

Nicht zugewiesen

Das gleiche wie schon oben der „freie Speicher“: Diese Kapazität steht noch zur Zuweisung zur Verfügung. Hieraus können Volumes erstellt oder erweitert werden. Thin-Volumes können sich hieraus noch Kapazität zuweisen lassen und auch Snapshots können hier abgelegt werden.

Snapshot verwendet

Würde ich Snapshots auf dem System verwenden, so würde hier die Kapazität angezeigt werden, die die Snapshots beanspruchen. Ein Beispiel dazu folgt im nächsten Absatz.

Garantierter Snapshot-Speicherplatz

Sollte man optional eine gewisse Kapazität für Snapshots reservieren, so würde sich dies hier wiederspiegeln. Wie der Begriff „reserviert“ schon sagt, ist diese Kapazität der Snapshot-Lagerung vorbehalten und kann nicht für Volumes verwendet werden.

Alarm

Der Schwellwert des Pools ist auf 80% eingestellt. Sollte der Pool also nur noch 20% an nicht zugewiesener Kapazität aufweisen, wird ein Alarm ausgegeben.

In manch einem Anwendungsfall sollte man den Schwellwert komplett deaktivieren, in anderen Fällen sollte man den Schwellwert wiederum besonders beachten ^[4].

[4]

Der Pool-Schwellwert sollte z.B. immer dann abgeschaltet werden, wenn weder Snapshots noch Thin-Volumes eingesetzt werden. So umgeht man die lästige Warnung die dadurch auftritt, dass man die gesamnte Pool-Kapazität einem oder mehreren Thick-Volumes zugewiesen hat => Der Pool ist dann ausgereizt, obwohl durchaus noch freie Kapazität in den Volumes vorhanden ist.

Beim Einsatz von Snapshots sollte der Schwellwert aktiviert sein, sofern man keine Kapazität durch Setzen der entsprechenden Option für Snapshots reserviert.

Beim Einsatz von Thin-Volumes, ganz besonders bei Überprovisionierung, sollte der Schwellwert unbedingt aktiviert sein.

Weitere Szenarien

Snapshots
Nachfolgend die Ansicht beim Einsatz von Snapshots mit garantiertem Snapshot-Speicherplatz.

snapshot_1.PNGsnapshot.PNG
Der von Snapshots verwendete Speicher wird hier nicht extra dem Pool entzogen sondern ist im garantierten Snapshot-Speicher enthalten. In diesem Fall braucht man keine Sorge haben, dass Snapshots gelöscht werden, wenn die nicht zugewiesene Kapazität irgendwann von einem Volume benötigt wird. Anders würde es aussehen, wenn die von Snapshots verwendete Kapazität den garantierten Speicherplatz übersteigt oder eben gar kein reservierter Speicherplatz vorhanden ist.

Überprovisionierung / Überabonnierung
Hier die Ansicht bei einem überprovisioniertem Thin-Volume.

overprov_1.PNGoverprov_2.PNG

Obwohl die physische Kapazität der Festplatte nur 500GB beträgt, wurde ein Volume mit einer definierten Kapazität von 800GB erstellt. Natürlich können ihm diese 800GB niemals zugewiesen werden, da sie schlichtweg nicht vorhanden sind. Am Abonnement sieht man, dass (deutlich) überprovisioniert wurde und dringend darauf geachtet werden muss, dass die Pool-Kapazität nicht erschöpft wird.
Die Angabe „Überabonniert“ (rechtes Bild) macht nochmals deutlich, dass 660,49GB von den freien 792,61GB nicht aus dem Pool bezogen werden können, dazu müsste der Pool also zunächst vergrößert werden (z.B. durch zusätzliche oder größere HDD). Nochmal: Hier besteht die Gefahr von Datenverlust, wenn mehr als 792GB - 660GB = 132GB (gerundet) auf dieses Volume geschrieben werden soll!

[EPILOG]

Ich habe übrigens auch mal kurz geschaut, was an der Aussage dran ist, dass Thick-Volumes weniger performant sind als ein statisches Volume und Thin-Volumes noch weniger. Dabei habe ich einfach 10 Videodateien (insgesamt ca. 4GB) von einer internen SSD auf die entsprechenden Volume-Typen (alle auf derselben HDD) kopiert:
Statisch = 117 MB/s, Thick = 154 MB/s, Thin = 114 MB/s. So richtig kann ich die (offizielle) Aussage zur Performance mit diesen Werten also nicht nachvollziehen, aber dieser Schnelltest mag auch nicht sehr repräsentativ sein.

Sicherlich gibt es noch das Ein oder Andere, was ich nicht berücksichtigt habe, ich denke aber diese 9 Seiten sollten reichen um das Wesentliche deuten und verstehen zu können.

Ich hoffe es war kein zu trockener Stoff und kann dem Ein oder Anderen Unterstützung bieten oder auch einfach nur die Zeit am zweiten Corona - 1. Mai - Feiertag vertreiben.

Was mache ich ich denn jetzt eigentlich am 1. Mai-Wochenende, nachdem ich den Artikel fertiggestellt habe?

Ach ist doch irgendwie klar... cheers!