Server 2012R2 Speicherpool mit mehr als 7 Platten - 2 Platten Parity?

Johannes66

Lt. Junior Grade
Registriert
Nov. 2009
Beiträge
509
Hallo,

bevor ich mein FreeNAS System ev. auf Server 2012 umstelle, hätte ich folgende Frage:
Bei Erstellen eines neuen Storage Space Speicherpools - Virtuellen Datenträger/Parity steht in der Beschreibung rechts, das zum Schutz von zwei Datenträgerfehlern mindestens 7 Datenträger vorhanden sein müssen.

Wird dann automatisch ein virtuelles Raid6 ähnliches Gebilde gemacht?

Ist die Sicherheit ähnlich ZFS RaidZ2?

Leider geht das mit VHDs nicht zum simulieren, und bevor ich das System mit 10 Platten platt mache, wäre es gut zu wissen, was da vor sich geht.

Danke für Feedback!
 
Die Spaceerstellung hat noch nichts mit den virtuellen Datenträger zu tun...obwohl es beim beim fertigstellen so übersetzt ist. Ich kann das schwer erklären , aber du schützt den Space vor Ausfallsucherheit schützen und später das Volume .....durch die doppelte sicherheit kommt das wohl mit den 7 Platten hin. Ich lese das aber heute nochmal nach.
 
Warum soll das nicht zu simulieren gehen? Wenn sieben Platten in einem Pool sind bekommst du beim anlegen der vDisk die Wahl zwischen Parity und Dual Parity.

Dir sollte aber klar sein das die Performance von Storage Spaces beim Schreiben ohne SSDs als Write-Back Cache sehr bescheiden ist.
 
Masamune2 schrieb:
Warum soll das nicht zu simulieren gehen? Wenn sieben Platten in einem Pool sind bekommst du beim anlegen der vDisk die Wahl zwischen Parity und Dual Parity.

Danke, das beantwortet meine Frage.

Ich hab keine Ahnung warum es mit VHDs nicht geht, aber der Punkt zum Erstellen eines Pools wird mir mit den VHDs die ich in der Server 2012R2 VM erstellt habe, nicht angeboten. Vielleicht hab ich die falsche Art von VHDs erstellt (single File? weiß nicht mehr).

Masamune2 schrieb:
Dir sollte aber klar sein das die Performance von Storage Spaces beim Schreiben ohne SSDs als Write-Back Cache sehr bescheiden ist.

Beim SSD Server mit 4 SSDs im Storage Space, konnte ich beim schreiben keinen Unterschied zu einem normalen Datenträger oder Raid5 (in der Datenträgerverwaltung erstellt) feststellen. Hab eine 35GByte Testdatei verschoben, und die wurde mit bis zu 700Mbyte/sec übers 10Gbit LAN geschrieben.
Der Unterschied war, das es am Schluß eine Zeitlang auf 200MByte/sec (also noch immer schneller als 1Gbit Lan) runtergegangen ist.
Auch bei vielen kleinen Dateien (für den Speedtest mit 100000 1KByte Dateien) war es nach einiger Zeit (wenn beim FreeNAS die 32GByte ECC Ram voll sind) bis zu 25x schneller als auf eine einzelne SSD (oder den Plattenpool) im FreeNAS Gerät.

Beim anderen Server mit Festplatten hab ich es eben noch nicht versucht. Aber ich glaube kaum, dass es bei vielen kleinen Dateien (was ich öfter brauche, und wichtiger ist als einzelne große) langsamer wird als ZFS, oder?
 
Wie gesagt, solange du SSDs mit im Pool hast die als Schreibcache verwendet werden ist das kein Problem. Ohne wirst du wesentlich langsamer sein als mit ZFS, das liegt an der Natur wie ZFS sein RaidZ schreibt und wie das bei Storage Spaces implementiert ist.
 
Ok, danke.
Hab jetzt noch mal ein bisschen getestet und sofern jetzt nicht eine Maschine beim lesen limitiert hat, hab ich gesehen wie das mit dem Storage Pool funktioniert.
Solange der Ram (32GB ECC) noch nicht mehr als 1/2 voll ist (so ca bis 17GB rauf von den 32), geht die Geschwindigkeit beim schreiben bis auf 1,08 Gbyte rauf.
Danach bricht die Geschwindigkeit massiv ein. Beim unverschlüsselten Pool auf ca.200MByte, und beim Bitlocker verschlüsselten auf ca. 30Mbyte.
Also hängts vom Ram ab, wie lange der Speed anhält. (alles ohne Schreibcache SSD)

MaxSpeed.jpg

Beim Schreiben von vielen kleinen Dateien ist der Storage Pool aber wesentlich schneller als ZFS (bis zu 30fach), weil sich da der Ram praktisch nie soweit füllt das direkt geschrieben wird. Auch nicht bei zig tausend kleinen Dateien. Keine Ahnung, was passiert, wenn es da mit dem Ram knapp wird. (wird bei meiner Konfig aber nie vorkommen)

Soweit passt es dann doch, dass der Datenserver Win mit Pool hat, und der Medienserver ZFS.

Und ZFS schreibt die große Testdatei konstant mit 350-400MByte, auch wenn der 32GB Ram voll ist.

ZFS Write1.jpg
 
Hast du jetzt SSDs im Pool? Ich erreiche ohne Schreibcache nicht mal annähernd diese Werte.
 
ja, ich hab 4xSamsung 850Pro 512GB im Pool mit einer Parity auf ReFS. Dann das ganze Volumen (Pool oder wie auch immer) bereitgestellt (gegenteil von Thin Prov. - fällt mir gerade nicht ein), und mit Bitlocker (wieder komplett) verschlüsselt.

Soweit ich jetzt gesehen habe, geht es mit vollem Lan Speed nur dann, wenn auf der Windows Maschine mit Storage Pool genug Ram frei ist (Bei der Lesemaschine war es offensichtlich im Ram, da sonst nur 6-700MByte). Der Pool verwendet, so wie es ausschaut, ca. 16GB von den vorhandenen 32GByte ECC als Cache. Sobald der Ram voll ist, knickt die Schreibgeschwindigkeit massiv ein, genau genommen auf Schneckenspeed.
Wenn dann die Datenübertragung aus ist (kein NW Traffic mehr) schreibt er schön gemütlich den Ram auf den Pool leer.

Ich denke fasst, das es bis der Ram ausgenutzt ist, keinen Unterschied zwischen HDDs und SSDs beim schreiben geben wird. Erst danach vermutlich.
Ob eine zusätzliche SSD jetzt bei der Konstellation was bringt, hab ich noch nicht erlesen. Leider geht das Einbinden nur über die Konsole, und da muß ich mich besser einlesen wie. Vielleicht versuch ich es, wobei sich die Frage stellt, ob dadurch nicht der Sinn (hohe Datensicherheit/keine Schreib-Lesefehler/Selbstheilend) mit der Cache SSD überhaupt erhalten bleibt! Müßte ja das rein- und raus vom SSD Cache verglichen werden. Ob das so ist?

Ich werde noch suchen, ob man den Storage Space nicht auf SSDs optimieren kann, aber bis jetzt hab ich nichts gefunden.
Keine Ahnung welche aufwendigen Algorythmen da dahinter liegen, an denen gedreht werden kann, aber die Schreibgeschwindigkeit von großen Dateien mit vollem Ram ist unterirdisch. Bei kleinen Dateien funktioniert es aber sehr gut im Gegensatz zu ZFS unter FreeNAS.
 
Mich wundert etwas was du im RAM beobachtest. Eigentlich sollte der RAM damit nicht zu tun haben, denn der Schreibcache liegt auf den SSDs. Ist dieser voll geht es nur noch langsam weiter. RAM ist flüchtig daher wird er nicht als Write-Back Cache verwendet.

Das wird sich mit Server 2016 und NVDIMMs ändern, dann werden die als Schreibache genutzt was Storage Spaces massiv beschleunigen soll. Ist aber für einen Homeserver wohl erst mal uninteressant.
 
Ich werd mich am Wochenende oder spätestens wenn die zweiten 32GB kommen, bzw. die zwei VMs am Server in Betrieb gehen noch mal spielen, und es genau dokumentieren. Aus meiner Sicht ist es eindeutig und reproduzierbar. Fällt halt nur bei sehr großen Dateien, und schnellem Netzwerk richtig auf. Bin selber schon neugierig was passiert, wenn der Ram durch andere Prozesse voller ist.
 
So, heute hab ich noch mal kurz Zeit gehabt, und bevor das Ram Upgrade kommt nochmal getestet.
Aus meiner Sicht ist es ganz eindeutig, das in den Ram geschrieben wird, und er somit als Schreib Speicher, Cache, oder wie immer man dazu sagen möchte, dient.

Bild 1 zeigt - vor dem Kopierstart einer Datei mit 4,5GB - Interessant oben Datenträger "8" Warteschlangenlänge (Schreibgeschwindigkeit)
Bild 2 zeigt - knapp vor Ende des Kopiervorganges - Diesmal hab ich 1G Lan verwendet und geschrieben wurde konstant mit 980mBit/sec. Unten ist der orange Speicherbereich der, der als Ram für den weiteren Schreibvorgang jetzt gefüllt wurde.
Bild 3 zeigt - 1 Minute nach Beendigung des Übertragungsvorganges - Datenträger schreibt noch immer, Ram leert sich.
Bild 4 zeigt - ca.2:15 nach Beendigung des Übertragungsvorganges - Datenträger hat aufgehört zu schreiben, Ram ist leer.
Bild 5 zeigt - tatsächliche Schreibgeschwindigkeit von ca. 40mByte/sec. auf den Datenträger (4x500GB Storage Space 1 Parity SSDs) wärend des Übertragungsvorganges.

Was meinst? Ist doch damit dokumentiert, oder gibts noch Zweifel?

1- Res.Mon1-vor Start.jpg
2 -Res.Mon2-knapp_ende.jpg
3- Res.Mon3-1min_nach_Ende.jpg
4- Res.Mon4-nach_fertigschreiben.jpg
5- Res.Mon5-tatsächliche_Datenträger_Schreibgeschwindigkeit.jpg

Bin schon gespannt, was nach dem Ram Upgrade ist.
Übrigens ist, während dem Schreiben, lesen auch langsam.
Warum die SSDs so langsam beschrieben werden, ist mir allerdings ein Rätzel. Leider hab ich zu wenig Zeit und Wissen, um das genau festzustellen, was da im gesamten abgeht, und ob es nicht einige Schräubchen zum drehen im Hintergrund gibt.

Wäre wirklich interessant, wenn CB mal einen Test von Storage Spaces macht. Ich denke, das hier SSDs als Speichermedium kaum was bringen. Interessant wäre auch die Anwendung von den Puffer SSDs mit Festplatten oder SSDs als Ziel.
 
Warum die SSDs so langsam beschrieben werden, ist mir allerdings ein Rätzel.
Weil der RAM eben nicht als Write Back Cache verwendet wird. Sonst hättest du auch etwa 200MB/s schreibend und nicht die üblichen 40.

Ich versuchs mal zu erklären.

Der RAM wird zwar genutzt um die zu schreibenden Daten zwischen zulagern, für das OS gelten sie dann aber noch nicht als geschrieben. Würdest du beim Schreiben den Strom raus ziehen wären die Daten im RAM weg, das Dateisystem und das Raid aber intakt.

Nutzt man den RAM wirklich als Write Back Cache für das Raid 5 (bzw. das Parity Layout) würde folgendes passieren: Beim Schreiben von neuen Daten werden die alten Daten eines Stripesets komplett gelegt, durch die neuen Daten ersetzt und anschließend das Stripeset neu geschrieben damit die Parität wieder stimmt. Um zu verhindern, dass das Dateisystem zwischendrin in einem nicht konsistenten Zustand ist wird immer nur ein Stripe nach dem anderen gemacht und gilt erst als abgeschlossen wenn er fertig geschrieben ist und dann gehts erst an den nächsten.
Mit SSD als WB Cache (oder mit einem Hardware Raid Controller der sowas an Board hat) wird immer so lange gewartet bis ein komplettes Stripeset voll ist. Das kann dann in einem Rutsch geschrieben werden ohne vorher das alte zu lesen weshalb die Geschwindigkeit massiv steigt. Macht man das allerdings ohne Schutz und der Strom fällt aus ist das Raid kaputt.

Aus diesem Grund aktivieren richtige Raid Controller den Write-Back Cache nur wenn sie eine Batterie am Controller haben (oder Superkondensatoren). Windows tut es nur dann wenn SSDs als Cache genutzt werden in denen der letzte Zustand des Raids gespeichert wird.

ZFS wiederum kann darauf verzichten da jede Schreibaktion auf das Dateisystem atomar ist und damit der Zustand immer konsistent.

Einen guten Test gibts hier: http://sp.ts.fujitsu.com/dmsp/Publications/public/wp-windows-storage-spaces-r2-performance-ww-de.pdf
"Spaces Single Parity with WBC vs. Spaces Single Parity" zeigt gut wie die Schreibperformance durch SSDs verbessert wird.
 
Danke für den Link und Deine Erklärungen.
So weit ich bis jetzt gelesen hätte, steht nirgends was passiert, wenn der komplette Pool aus SSDs besteht. Es wird in dem Dokument "immer" von einem Festplattenpool ausgegangen, wobei lt. Beschreibung SSDs schon automatisch erkannt werden, aber nur als "Teil" des Pools, ev. dann eben für besondere Verwendung im Pool. Ich fürchte, dass hier SSD Leistung verschenkt wird (Automtisch größerer WBCache auf den vorhandenen SSDs zB), wenn man nicht manuell konfiguriert, da ein reiner SSD Pool bei der Entwicklung vermutlich kein Thema war. Weiters, wenn ich richtig verstanden habe, brauchte ich zusätzlich 2 SSDs für den Writeback Cache bei einem Parity Layout. Der Einfluß von Ram wird auch nicht behandelt.
Es schaut so aus, dass eine intensive Ausseinandersetzung mit der Technologie notwendig ist, um sie gut zu verstehen und richtig einzusetzen. Ich glaub nicht, das ich da weiter experimentieren werde, da ich so damit leben kann und der Zeitaufwand recht groß ist um das alles richtig auszutesten und zu verstehen.
 
Ein Flash-only Pool ist aktuell nicht vorgesehen, SSDs werden lediglich als Cache oder zum Tiering verwendet. Das wird sich aber vielleicht mit Server 2016 ändern (konnte mir die Tech Preview noch nicht anschauen).

Der Einfluss von RAM wird eigentlich nie in einem Storage Test behandelt da er keinen Einfluss hat. Testet man wirklich nur den Storage ist es egal wie viel RAM verbaut ist.
 
Abschließend noch die Info zum Ram Upgrade. Jetzt mit 64GB Ram werden tatsächlich 32GB als Zwischenspeicher für den Netzwerktraffic verwendet (Speicher fürs Schreiben - nicht "write Back cache" wie ich gelernt habe), und die 35GB Testdatei wird fast komplett mit bis zu 1,1Gbyte/sec übertragen. Erst ganz am Schluß, wenn die 32GB Ram voll sind kommt der Einbruch. Wäre interessant, wo ich die Puffergröße einstellen kann, da hauptsächlich Fileserver, und so die restlichen 32GB abzüglch der VM meistens frei sind.

FullSpeed.jpg

Edit: der Vollständigkeit noch die Info, die ich im MSS Forum bekommen habe.
Den File Cache im Ram kann man nicht manuell ändern oder einstellen.
 
Zuletzt bearbeitet: (Ergänzung)
Zurück
Oben