Windows Storage Pools Größe

[SaxnPaule]

Hallo Community,

ich habe heute mal ein wenig mit Windows Storage Pools rumgespielt, da ich das Konzept von verteilter Datenhaltung mit Parität ohne RAID ganz interessant finde.

Allerdings verstehe ich nicht ganz, wie sich der effektiv nutzbare Speicherplatz errechnet.

Ich habe mir dazu im Azure eine 2016 Datacenter Instanz hochgezogen, welcher ich 4 x 20GB HDDs spendiert habe.
Diese habe ich zu einem Storage Pool zusammengefasst. Kapazität beträgt 77GB. Soweit alles nachvollziehbar.

Jetzt habe ich auf dem Storage Pool ein Virtuelles Laufwerk mit Parität angelegt, welches mir bei maximaler Größe jedoch nur 48GB anbietet. Bei einfacher Parität müsste doch irgendwas um 58GB und bei zweifacher ca. 39GB bereitstehen.

Das mutwillige "Zerstören" einer Platte und das ersetzen durch eine neue habe ich getestet und es funktioniert wirklich gut. Fraglich ist nur, wie lange der ganze Prozess bei echten Größen im TB Bereich dauert.

Ich habe ja schonmal das Windows Software Raid5 getestet, was nach knapp zwei Tagen das Volume auch vernünftig bereitgestellt hat.
Allerdings war nach einem abgebrochenen Windows Update das Array schon wieder degraded und hätte wieder zwei Tage durchlaufen müssen.
Auf solche Schluckaufs habe ich keine Lust und daher frage ich mich, ob Storage Pools da eine geeignete, zuverlässigere Alternative zu dem Windows Software Raid sind, da ja erst beim Schreiben die Daten intelligent verteilt werden, wenn ich das richtig verstanden habe und nicht bereits vorab alle HDDs "vorformatiert" werden.


EDIT1: Ich habe das Thema bewusst unter Heimnetzwerke aufgehangen, da es prinzipiell zur NAS Konfiguration gedacht ist. Ob es tatsächlich zur Anwendung kommt hängt natürlich von eventuellen Erfahrungswerten ab.

EDIT2:
Bei einem Storage Pool aus 4 x 20GB (77GB) hat die vDisk 48GB (62%)
Bei einem Storage Pool aus 4 x 120GB (476GB) hat die vDisk 316GB (66%)
Bei einem Storage Pool aus 4 x 500GB (1,95TB) hat die vDisk 1,328TB (68%)
Bei einem Storage Pool aus 4 x 1023GB (3,99TB) hat die vDisk 2,66TB (67%)

Es wäre schon schön, wenn man irgendwie grob in Richtung 75% gelangen könnte.

 

[snaxilian]

Wenn du einfache Parität als Layout wählst, hast du das Gegenstück zum Raid 5. Jeder Datenblock wird auf deinen Pool doppelt geschrieben zzgl. Paritätsinformation. Du hast also 33% "Verschnitt".
Warum die Werte immer so voneinander abweichen kann zig Gründe haben. Vermischte Darstellung von Giga- & Gibibyte unter Windows, verwendete Blockgrößen, uvm. So oder so wird sich bei einfacher Parität der verfügbare Plattenplatz immer um 1/3 verkleinern.

 

[SaxnPaule]

Das ergäbe Sinn, wenn ich drei Platten hätte. Sind aber vier, somit nur 25% "Verschnitt".

Bei Raid 5 wird auch nix doppelt geschrieben, sondern verteilt auf die Platten + Parität. Also (Plattenzahl - 1) * Platz der kleinsten Platte. Genauso erwarte ich mir das in etwa auch von den Storage Pools, nur das da halt noch minimal was für Caching weggeht.

 

[snaxilian]

Nein, du denkst in alter Raid-Denkweise, musst jetzt mit Storage Spaces (SS) aber etwas umdenken und neu lernen.

Bei einem klassischen Raid gilt die Formel und der prozentuale Verschnitt verringert sich je mehr Platten im Array sind. SS musst du dir eher sinngemäß als JBOD oder Raid 0 vorstellen auf dem du mehrere vDisks erstellen kannst mit unterschiedlichen Layouts.

Mir fällt auch gerade auf, in meinem obigen Post hab ich noch einen Denkfehler, die 1/3 sind eben nicht statisch.

Kleines Beispiel: 4 Disks mit je 1 TB, also 4 TB im Pool verfügbar. Du hast 500 GB Nutzdaten, die dir aber absolut nicht wichtig sind. Daher nimmst du Layout "simple" mit dem Ergebnis, dass die vDisk auch nur 500 GB benötigt.
Zusätzlich hast du 500 GB Nutzdaten, die dir wichtig sind, daher nutzt du als Layout Parität. Die vDisk belegt jetzt auf dem Pool aber nicht 500 GB sondern 500 GB zzgl. Parity-Informationen.
Wie genau sich diese Datenmenge zusammen setzt, verrät MS nicht, zumindest nicht für das alte/klassisches Storage Spaces sondern nur für Storage Spaces Direct. Auf jeden Fall ist mir kein passender Calculator bekannt. So oder so nimmt MS bei SS deine Daten, zerlegt diese in für sich passende Streifen und legt dann für N Streifen per XOR-Operation die Parity Daten an.
Jetzt hast du noch 500 GB superduper wichtige Daten und erzeugst auch dafür eine vDisk mit douple parity. Diese vDisk belegt dann noch mehr Speicherplatz als die zweite vDisk.
Zu guter Letzt willst du noch für Benchmarks (oder was auch immer) 100 GB Daten doppelt vorhalten um die Lesegeschwindigkeit zu erhöhen. Du legst also noch eine vierte vDisk an mit Layout mirror. Diese vDisk belegt dann 200 GB auf deinem Pool.

Fürs Caching wird bei SS/S2D nix genutzt sofern du nicht explizit SSDs als Cache-Device einem Pool zuweist um dann Tiering zu betreiben.
Kompression bringt auch nur bedingt etwas, abhängig von den Daten, die du speichern willst und Deduplizierung läuft zum einen asynchron und kann Performanceeinbußen mit sich bringen.

 

[SaxnPaule]

So habe ich das auch aus den Docs gelesen. Allerdings habe ich nur eine vdisk über den gesamten SS angelegt mit einfacher Parität. Quasi dein Nutzdatenbeispiel.

Damit ist dann der gesamte SS belegt und ich kann keine weitere vdisk anlegen.

Für das Caching wird Platz genutzt. Es wird explizit beim Anlegen in einem Dialog darauf hingewiesen. Daher stehen auch nicht die vollen 80GB, sondern nur 77 zur Verfügung.

Die Abweichung GB/GiB spielt ja erst nach der Formatierung eine Rolle.

 

[snaxilian]

Solange MS seine Berechnungen zur Parität nicht offen legt bleibt's bei der Glaskugel bzw den Infos, die man in der Doku findet.