Windows 10 Speicherplatz nach Server 2016 umziehen und SSD Cache

L

LuckyHans

Neuling
Thread Starter
Mitglied seit
07.02.2017
Beiträge
5
Hallo zusammen,

ich habe seit etlichen Jahren ein Eigenbau-NAS mit ständig wechselnder Hardware und BS. Bis vor Kurzem hatte ich Windows 10 als BS und einen Speicherplatz mit Parität (3x Seagate 8TB). Jetzt bin ich auf Server 2016 Essentials umgestiegen und würde gerne eine 120GB SSD als Cachemit in den Pool aufnehmen, da die Schreibgeschwindigkeit nach kurzer Zeit extrem einbricht. Das Ganze dann natürlich ohne Datenverlust. :)

Gibt es überhaupt diese Möglichkeit, oder muss der Speicherplatz dafür neu angelegt werden?

Vielen Dank,
LucjyHans
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dies wäre zwar möglich, wird aber an deinem Problem vermutlich nichts ändern.

Wenn die Schreibrate einbricht, wird wohl eher ein Fehler in deiner SP Konfiguration vorliegen.
 
Zuletzt bearbeitet:
Klingt für mich nach Seagate Archive HDD mit SMR, stimmts?
Ich fürchte das Problem wird sich nicht mit ner SSD oder gar einem RAID Controller lösen lassen.

cu
 
Hallo,

es sind die Seagate Archive V2 mit SMR. Unter Windows 10 hatte ich das Problem, dass bei Schreibvorgängen der Datendurchsatz stark einbrach, nachdem der recht kleine Cache voll war. Im Schnitt habe ich dann mit 15-20MB/s kopiert, lesen war kein Problem, das ging immer schnell.
Jetzt mit dem gleichen SP, aber Server 2016 hat sich das bereits signifikant gebessert. Ich komme jetzt auf eine durchschnittliche Schreibrate von 45-50MB/s, gemessen mit 500GB Daten, bestehend aus Dateien von 200MB bis 15GB.

Könntet ihr mir evtl. auch sagen wie genau ich die SSD als Cache nutzen kann, ohne die Daten zu verlieren? Was man so findet ist meist sehr allgemein.

LG
 
Bei Cache musst du zwischen Read , Write und Read-Write Cache unterscheiden.
Für Read-Cache braucht man im Normalfall eine SSD.
Für Write-Cache, den du brauchst, bräuchte man 2 SSDs, damit geschriebene Daten gespiegelt werden können.
 
Danke, eine zweite SSD ist ja recht schnell bestellt.
Nur wie bewerkstellige ich es am besten, diese beiden SSDs auch mit in den Pool zu bekommen?
 
Bist du auf Windows-Server angewiesen?
Probier doch mal FreeNas(ZFS), Napp-IT(ZFS) oder Xpenology(EXT4 oder BTRFS).

Dort ist das einrichten von SSD-Cache recht einfach, vorallem bei Xpenology. (Die Performance dürfte bei allen dreien deutlich besser sein)
 
Zuletzt bearbeitet:
Der Server ist mein DC, daher würde ich äußerst ungern auf Win Server verzichten.
 
Jemand der SMR Platten des Preises wegen kauft wird sicher keine Enterprise-Software für mehrere hundert Euro kaufen. Da kann man genauso gut nen extra NAS oder ähnliches kaufen.

BTT: SSD-Cache bei Windows (Storage-Pools) lässt sich glaube ich nicht nachträglich (ohne Datenverlust) einbauen.

Da fällt mir ein. Teste mal Primo-Cache (PrimoCache Overview).
Da kannst du dann auch RAM als Write-Cache nutzen.

Aber bitte bedenken: Beim Stromausfall kann es schnell zur Inkonsistents des Raids kommen.
 
Zuletzt bearbeitet:
Es ist kein Problem nachträglich eine SSD hinzufügen, aber der gewünschte Effekt wird halt ausbleiben. Die Kiste bräuchte bessere und mehr Platten, SP ist halt nicht wirklich für winzige Installationen ausgelegt.
 
LuckyHans schrieb:
Danke dafür.
Zum Vergrößern anklicken....

Nein, um mal sachlich zu bleiben: dem Pool kannst du die SSDs natürlich einfach hinzufügen.
was nicht geht ist Sie nachträglich einer virtuellen Disk (die ja aus dem Pool erstellt wird) hinzuzufügen.

Wenn deine virtuelle Disk nicht alle Platten voll ausfüllt, könntest du aber (nachdem die SSDs) im Pool sind eine neue virtuelle Disk erstellen (diesmal mit Tiering also SSD und HDD-Anteilen) und die Daten dann von der alten auf die neue virtuelle Disk kopieren. Ggf ist das auch in mehreren Schritten denkbar (neue Disk schrittweise erweitern) wenn die Daten der alten vDisk nicht komplett auf den noch übrigen Platz der neuen passen. Hängt natürlich davon ab wie du derzeit vDisks erstellt hast.

Dass die SMR-Platten für ein RAID nicht gedacht sind wurde hier ja schon erwähnt.
 
Boy2006 schrieb:
Dafür nutzt man ja auch eine BBU.
Zum Vergrößern anklicken....

Schwachsinn. Eine BBU sichert den Cache eines Raidcontrollers. Nicht den Ram eines Rechners.
Dafür nutzt man eine USV.

Probier einfach mal Primo-Cache aus. Das dürfte deine Anforderungen erfüllen.
Ein Backup ist so oder so unersetzlich.(Wegen Stromausfall)
 
Zuletzt bearbeitet:
MicroCane schrieb:
Bist du auf Windows-Server angewiesen?
Probier doch mal FreeNas(ZFS), Napp-IT(ZFS) oder Xpenology(EXT4 oder BTRFS).

Dort ist das einrichten von SSD-Cache recht einfach, vorallem bei Xpenology. (Die Performance dürfte bei allen dreien deutlich besser sein)
Zum Vergrößern anklicken....


Gibt es hierzu Belege?

Bisher habe ich im Netz noch nie einen tatsächlichen Vergleichstest hierzu gesehen (mit jeweils identischer Hardware). Das meiste sind persönliche Geschmäcker aber kaum Zahlen.

Und mein bescheidener Test mit napp-it vs. Storage-Spaces fiel mit meiner Hardware zugunsten der Storage Spaces aus.

Insofern freue ich mich gern über weitere belegbare Vergleiche.
 
Beruht auf eigenem Test mit 3x WD-RED 5TB und einmal mit 5x 500gb Seagate.
Beide begrenzten bei 30-50mb/s (Anfangs volle Schreibgeschwindigkeit bis der zugewiesene RAM voll war).

Sollte das ganze an falscher Konfiguration liegen, bin ich natürlich selbst schuld. Aber mehr als 5-10x auf "Weiter" zu drücken ist es bei Storage-Spaces ja eigentlich auch nicht. Allerdings hatte ich häufiger gelesen, dass "Paritiy" nicht besonders dolle bei SS ist.

Performance Vergleich zwischen Windows Storage Spaces und Hardware Raid Leveln | Dynamic IT Management Blog
Parity Storage Space so slow that its unusable
Windows vs Intel Raid Performance Smackdown FoxDeploy.com


Vielleicht hätte ja das geholfen:
Storage Spaces and Parity - Slow write speeds - Tecfused
 
Zuletzt bearbeitet:
Boy2006 schrieb:
Natürlich meinte ich den Ram des Raid Controller was sonst?!
Zum Vergrößern anklicken....

Macht es nicht richtiger... Es geht dabei um den RAM des Servers, dessen Inhalt bei Stromausfall verlustig geht und unter Umständen das Raid inkonsistent werden lässt, da eben Daten im RAM nicht auf den Disks landen, die dort aber hingehören...
 
MicroCane schrieb:
Beruht auf eigenem Test mit 3x WD-RED 5TB und einmal mit 5x 500gb Seagate.
Beide begrenzten bei 30-50mb/s (Anfangs volle Schreibgeschwindigkeit bis der zugewiesene RAM voll war).

Sollte das ganze an falscher Konfiguration liegen, bin ich natürlich selbst schuld. Aber mehr als 5-10x auf "Weiter" zu drücken ist es bei Storage-Spaces ja eigentlich auch nicht. Allerdings hatte ich häufiger gelesen, dass "Paritiy" nicht besonders dolle bei SS ist.

Performance Vergleich zwischen Windows Storage Spaces und Hardware Raid Leveln | Dynamic IT Management Blog
Parity Storage Space so slow that its unusable
Windows vs Intel Raid Performance Smackdown FoxDeploy.com


Vielleicht hätte ja das geholfen:
Storage Spaces and Parity - Slow write speeds - Tecfused
Zum Vergrößern anklicken....



Ok, dazu muss ich vielleicht ergänzen, dass ich (mangels HDDs) bisher nur das Mirror-Layout nutze und das zusammen mit 2 SSDs (konkret: 2x 4 TB Seagate NAS und 2x 300 GB Intel DC 3500).
dort erreiche mich mit Tiering deutlich bessere Werte.

direkt auf dem Windows Server,
Virtuelle Disk: 50GB + 50 GB
Volume: NTFS:

1.png

und in der VM,
100 GB SSD + 500 GB HDD
per iSCSI an vSphere-Host, dort als Datastore mit der VM:

2.png
 
Dann liegt das wohl an Paritiy. Das ist fürchterlich langsam im schreiben. Vielleicht schaltet MS ja den onDisk-Cache aus. Wer weiß.
 
Die Parity Daten müssen ja berechnet werden -> das macht die CPU in dem Fall. Keine Ahnung, ob die Software mittlerweile Multithreading beherscht. Früher (Softwareraid unter Windows) war das nicht der Fall -> weswegen der Spaß eben grottig lahm ist...
Das Problem hier sind doch aber viel eher die Disks... Die brechen nunmal weg, wenn du über den Puffer schreibst, weil die Daten dann nicht nur 1x geschrieben werden, sondern beim Schreiben werden Teile vorhandener/beschriebener Daten/Spuren überschrieben, weswegen die Disks intern für das Vorhaben einfach länger brauchen. Lesen ist kein Problem... Schreiben aber eben schon.
500GB am Stück da drauf zu tackern schmeckt den Disks halt einfach nicht! Du füllst damit alle Caches, die das System hat -> und wenn das der Fall ist, bricht die Datenrate weg, weil du nur noch den Speed zu sehen bekommst, den die Platten schaffen, ohne in Zwischenspeicher beschreiben zu können.

Mit ner 120GB SSD, rein vom logischen her, bekommt man das auch nicht weg -> denn dann würden einfach die 120GB voll geschrieben und das Problem bleibt...
 
MicroCane schrieb:
Dann liegt das wohl an Paritiy. Das ist fürchterlich langsam im schreiben. Vielleicht schaltet MS ja den onDisk-Cache aus. Wer weiß.
Zum Vergrößern anklicken....

Da kommen viele Faktoren ins Spiel. Es fängt bei der simplen Blocksize an die passend zum Anwendungszweck gewählt werden sollte, einer angepassten Cache Strategie bis hin zum Umstand ob man Enterprise Platten mit PLP verwendet. Du kannst natürlich alles verfügbare an Write-Caches aktivieren, überlege aber zuerst was bei einem Ausfall mit den Daten im Cache passiert - könnten für dich entscheidende Daten verloren gehen? Zumindest um´s Filesystem musst du dir keine Gedanken machen wenn du ReFS verwendest.
 
Zuletzt bearbeitet:
Es ist allerdings schade, dass Microsoft solche Sachen nicht einfach per Einstellungen ermöglicht.
Ewig im Internet zu suchen um den passenden Shell-Befehl zu finden halte ich für unpassend.

@fdsonne
Parity Berechnung durch die CPU ist absolut kein Problem. Da sind problemlos mehrere gb/s möglich.
Andere Software-Raids (5) haben bei gleichen Platten deutlich bessere Performance. Dazu gehören aufjedenfall ZFS, BTRFS und MDADM.
 
Schlussendlich ist der Kram nicht wirklich für "Heimanwender" gedacht. Das Verhalten des Disk Caches kannst du ja durchaus pro Platte einzeln definieren. Bei einer kleinen Kiste mit 4 Platten ist dies ja noch machbar, aber es wird etwas langweilig wenn du pro Knoten mal 48 Platten verbaut hast.
 
MicroCane schrieb:
@fdsonne
Parity Berechnung durch die CPU ist absolut kein Problem. Da sind problemlos mehrere gb/s möglich.
Andere Software-Raids (5) haben bei gleichen Platten deutlich bessere Performance. Dazu gehören aufjedenfall ZFS, BTRFS und MDADM.
Zum Vergrößern anklicken....

Das war nicht meine Aussage... Andere Software-Raid5 Umsetzungen nutzen ggf. Multithreading... Ich habe hier noch einen alten HighPoint RocketRaid 2300... Der skaliert bspw. auf einem Core2 2,66GHz Intel Xeon ggü. einem 3GHz der gleichen Modellreihe annähernd linear mit den Transferraten. Es wird auch nur ein Thread für die Parity benutzt.
Keine Ahnung, wie Microsoft das mit SS macht. Bekannt ist allerdings, dass die Parity Level nicht sonderlich performant sind. Die Disks tun ihr übriges dazu...

Solange der RAM nicht voll ist, scheint der Speed ja OK. Was auch klar darauf schließen lässt, dass es eben A) am Parity Level bzw. der Umsetzung bei Microsoft liegt und/oder B) an den Disks...

PS: Quervergleiche mit völlig anderen Systemen halte ich für wenig sinnig in dem Zusammenhang ;)
Es sind einfach zu viele Einflussfaktoren dabei, die den Spaß beeinflussen... Wenn mich nicht alles täuscht, versucht ein System, was ZFS basiert läuft wohl auch, Random Access nicht native auf die Disks loszulassen. Gerade beim Schreiben... Da wird gesammelt und dann Stückweise am Stück geschrieben. Ich müsste nun lügen, aber bei Microsoft dürfte das klar nicht der Fall sein. Random IO auf den Pool = Random IO auf den Disks.
 
Du findest im übrigen überall im Internet Probleme mit dem Parity Mode vom Windows Server. Die Lösung ist dabei wohl einen SSD Cache zu nutzen.

Ich hänge leider auch auf 20 TB Storage im Raid 5 auf einem Storage Space fest und weiß ehrlich gesagt noch nicht, wie ich da rauskommen soll. (Ausser sich ein paar Platten zu bestellen, auf was neues migrieren und dann zurück zu schicken :) )
 
Wenn du den Cache groß genug machen kannst, wäre das ja eine Option... Wie ich das oben aber verstehe ist eine 120GB SSD im "Plan" -> und es geht (wurde zumindest so genannt) um Transfers von teils 500GB am Stück.
Das hilft dann halt einfach nicht bzw. verlagert das Problem nur nach hinten.

Wobei ich ehrlich gesagt auch nicht weis, ob MS überhaupt endlos große SSDs als Cache nutzen kann oder ob es da harte Limits gibt.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh