Windows Storage Spaces im Trusted und Untrusted Netzwerk

[BOfH_666 577]

vor 10 Minuten schrieb SaschaVolk:

Ich kann gerne berichten wie sich die Server schlagen werden falls jemand interesse hat.

Neugierig sind wir alle.   Informationen sind also immer willkommen - auch wenn man sie nicht direkt braucht.   

bearbeitet 23. Februar 2021 von BOfH_666

[Weingeist 159]

Du hast nicht richtig beschrieben was eigentlich Deine Frage/Ziel der Übung ist. Sprich ob es Dir um die Replikation geht oder was Du als Unterbau verwenden sollst. Aktuell scheint es dir um den Unterbau zu gehen.

 

Bezüglich Lizenzen: Nein eigentlich ist das theoretisch fast nicht möglich, dass Du korrekt lizenziert bist wenn unterschiedliche externe Leute auf den Server arbeiten. Du bräuchtes theoretisch für jeden externen MA oder Gerät eine CAL welche du wiederum nur innerhalb bestimmter Zeit neu vergeben darfst. Dass das in so einer Konstellation korrekt gemacht wird, habe ich noch nie gesehen. Daher sind da eigentlich fast alle illegal aber +- geduldet unterwegs. ;)

 

Ich arbeitet gerne mit Storage-Spaces, ich meine auch tatsächlich "Storage Spaces" wenn ich Storage Spaces schreibe. Sonst eben "Storage Spaces Direct". Cluster heisst wiederum nicht zwingend Storage Spaces direct mit shared nothing sondern kann auch einfach ein clustered Storage Spaces mit shared discs sein. Shared Disc braucht kein Datacenter.

 

Storage Spaces kommt sehr auf die Implementation an ob es performant läuft. Das ist standardmässig vor allem auf sehr grosse Umgebungen ausgelegt. Für das kleine Umfeld taugen die Standardwerte nichts, sofern man nicht rein mit All-Flash werkelt. Ein Teil der "Eigenheiten" habe ich oben beschrieben. Deine SSD's werden Dir mit Storage Spaces und sequentiellen Loads so gut wie nichts bringen wenn Du einfach standardmässig konfigurierst. Einfach weil die Loads nie auf den SSDs landen werden. Egal ob dieser Cache 100GB gross ist oder nicht.

 

Ein paar wichtige Stichworte die mir grad einfallen

- Journal Flag auf den SSD's damit Write-Cache überhaupt sinnvoll funktioniert, VOR der Erstellung eines Volumes

- Nur Parity Random/IO writes werden bei SP gecached, bei Storage Spaces direct alle. (Mirror Volumes kommen NICHT in den genuss des Caches für sequentielle Loads)

- Erhöhen des interleave bei Erstellung des Volumes bei sequentillen Loads auf Mirrored Volumes mit Magnetplatten auf SP ohne Cluster auf 4194304 (4MB statt 256KB) damit auch sequentielle Loads performanter laufen

- RAM Read Cache funktioniert nur bei Storage Spaces bereitstellung via Cluster

- Storage Spaces braucht für Triple Mirror 5 Discs, für dessen Write-Cache 3 discs (ZFS ist mit 2 für ZIL/Write Cache immer happy)

- Storage Spaces braucht für korrekten Mirror eigentlich 3 Discs auch wenn zwei funktionieren, für dessen Write-Cache 2 (hängt mit der Art und weise zusammen wie SP funktioniert)

- Single Node Cluster/Stager um die besseren Cache-Funktionen für einen einzelnen Server zu nutzen und Standardverhalten von Storage Spaces auszuhebeln (RAM Read Cache ermöglichen, alle writes auch bei Mirrored Volumes cachen etc.)

- Loads können theoretisch auch mit Tiering gecached werden. Das funktioniert auch mit sequentiellen Loads.  Hier sollte dann der Tier 1 so gross sein, dass alle Writes eines Tages darin landen und über Nacht das ganze auf Tier 2 verschoben werden kann. (unter Tage passiert bei Storage Spaces standardmässig gar nichts). Das Tiering funktioniert das erste mal bis der ganze Tier 1 voll ist performant, nachher erst wenn wieder aufgeräumt wurde

 

Single-Node Cluster - wenn man das möchte wegen dem RAM Read Cache - kann nur mit Powershell erstellt werden indem -FaultDomainAwarenessDefault auf PhysicalDisk gestellt wird. Auch Loadbalancing muss deaktiviert werden.

 

ZFS musst darauf achten, dass Writes auf ein Mirrored SSD Zil gehen und nicht nur in den RAM-Cache.  ZFS konfiguriert standardmässig ungepufferten RAM als Write-Cache. Daher wichtig ein Mirror-ZIL konfigurieren. Dafür cached ZFS standardmässig alle writes, egal ob Random oder sequentielle loads.

 

Fazit:

Alles in allem wird ZFS mit Magnetplatten vermutlich immer besser rennen wenn man sich nicht intensiv mit Storage Spaces beschäftigt, weil die Standardwerte von SP einfach unbrauchbar sind für kleine Umgebungen wo eher die Spitzenlast/Latenz als die durchschnittliche Auslastung wichtig/relevant ist.

Storage Spaces ist dagegen insgesamt flexibler, auch bezüglich Erweiterungen, theoretisch sicherer/besser für rebuilds (slab-Prinzip), erfordert aber etwas mehr Einarbeitung. Die Dokumentation von MS ist mitunter grauenhaft, insbesondere für die Eigenheiten damit es auch mit Magnetplatten rennt (wenn auch deutlich besser geworden als vor knapp 10 Jahren wo man fast alles noch selber raustüfteln musste).

 

Für beide Varianten gilt: Fachpersonal gibt es selten bis nie für typische KMU-Betriebe. Man tut einem allfälligen Nachfolger und der Firma also nicht ubedingt etwas gutes. Ausser man nutzt eine 0814 NAS von QNAP/Synology etc.

bearbeitet 23. Februar 2021 von Weingeist

[SaschaVolk 2]

Hallo Weingeist. Danke dir für die Ausführliche Erklärung. Das sind mal ein haufen Informationen. Ja im Moment geht es mir um den Unterbau wenn an das so nenen möchte. Die Replikation usw kann man erstmal außen vor lassen.

Im Moment intressiert mich wie ich die höchste Performance mit Storage hinbekomme.

 

Also im Endeffekt meinst du ist es besser einen Single clustered Storage Spaces mit shared discs aufzusetzen damit der Cache besser funktioniert.

 

Ok da setze ich mal ein Test System auf.

 

Zu den Lizenz Thema. Ja mit den Externen Mitarbeitern das muß nochmal überdacht werden. Aber das ist ein anders Thema ;o))

 

Hier noch ein paar Verständnisfrage

 

- Journal Flag auf den SSD's damit Write-Cache überhaupt sinnvoll funktioniert, VOR der Erstellung eines Volumes - Wie setze ich das ??

- Nur Parity Random/IO writes werden bei SP gecached, bei Storage Spaces direct alle. (Mirror Volumes kommen NICHT in den genuss des Caches für sequentielle Loads) - OK verstanden

- Erhöhen des interleave bei Erstellung des Volumes bei sequentillen Loads auf Mirrored Volumes mit Magnetplatten auf SP ohne Cluster auf 4194304 (4MB statt 256KB) damit auch sequentielle Loads performanter laufen -  Ok kann ich machen wenn ich das Volume über Powershell erstelle

- RAM Read Cache funktioniert nur bei Storage Spaces bereitstellung via Cluster - Ok würde ja dann funktionieren wenn ich ein Single clustered Storage Spaces mit shared discs aufsetze ?

- Storage Spaces braucht für Triple Mirror 5 Discs, für dessen Write-Cache 3 discs (ZFS ist mit 2 für ZIL/Write Cache immer happy) -  Vielleicht gehe ich dann doch auf ein einfaches Mirroring

- Storage Spaces braucht für korrekten Mirror eigentlich 3 Discs auch wenn zwei funktionieren, für dessen Write-Cache 2 (hängt mit der Art und weise zusammen wie SP funktioniert) - Also bin ich doch mit 6 Festplatten und 2 Optane SSD gut dabei wenn ich es als einfaches Mirror einrichte oder ?? Hätte dann halt nur 30TB (6x10TB) zur Verfügung.

- Single Node Cluster/Stager um die besseren Cache-Funktionen für einen einzelnen Server zu nutzen und Standardverhalten von Storage Spaces auszuhebeln (RAM Read Cache ermöglichen, alle writes auch bei Mirrored Volumes cachen etc.) - OK Probiere ich aus

- Loads können theoretisch auch mit Tiering gecached werden. Das funktioniert auch mit sequentiellen Loads.  Hier sollte dann der Tier 1 so gross sein, dass alle Writes eines Tages darin landen und über Nacht das ganze auf Tier 2 verschoben werden kann. (unter Tage passiert bei Storage Spaces standardmässig gar nichts). Das Tiering funktioniert das erste mal bis der ganze Tier 1 voll ist performant, nachher erst wenn wieder aufgeräumt wurde - Das habe ich jetzt nicht ganz verstanden. Klingt aber eher nach größeren Konfigurationen

 

Mit der Dokumentation von MS gebe ich dir recht. Die Punkte die du angesprochen hast habe ich bisher nirgends gelesen. Ich würde gerne bei Storage Spaces bleiben da die Einbindung in eine Windows Umgebung einfacher ist. Wir haben zwar eine Netapp aber nur eine ESerie, die kann keine CIFS Freigaben außerdem ist die Erweiterung etwas zu kostenintensiv. Vielleicht werden wir in naher Zukunft in der Richtung weiter gehen aber im Moment muß eine günstigere Lösung gefunden werden bis Coronna überstanden ist und die Geschäft wieder normal laufen. Die Firma kommt aus der Veranstaltungsbranche und uns hat es doch etwas getroffen.