52
Optimierung Raidsystem Hyper-V Host
Hallo zusammen,
da ich hier gerade einen unserer Hyper-V Hosts räume, um diesen frisch zu installieren,
mache ich mir ebenfalls Gedanken über das Raidset.
Der Systembetreuer hat das Gerät mit Raid 6 ausgeliefert, was in meinen Augen nicht ideal ist und teilweise träge wirkt.
Das System macht beherbergt eigentlich alles, also von Fileserver über Applikationsserver bis Datenbankserver (SQL, Postgre, Actian, MariaDB).
...nur die Backups landen extern.
Sieht also aktuell so aus:
Grundlegend hätte ich gern auf ein Raid 10 gesetzt, da dies für SSDs entsprechend optimiert wurde?
Damit klaue ich mir aber 50% Speicherplatz, was ich mir leider nicht ganz erlauben kann.
...außer, ich lagere einige Systeme auf die SATA SSDs aus:
Alternativ könnte ich natürlich auch splitten, kann aber nicht beurteilen wie sich die Performance des Raid 10 dann macht?
Die ultimative Lösung wird es vermutlich nicht geben, also ist es immer ein Kompromiss, eine Ersatz SSD von den Nytros liegt im
Schrank, bei einem Ausfall kann also entsprechend zügig reagiert werden.
Bin auf eure Meinungen gespannt.
Grüße
ToWa
Edit: Benchmarkergebnisse: Optimierung Raidsystem Hyper-V Host
da ich hier gerade einen unserer Hyper-V Hosts räume, um diesen frisch zu installieren,
mache ich mir ebenfalls Gedanken über das Raidset.
Der Systembetreuer hat das Gerät mit Raid 6 ausgeliefert, was in meinen Augen nicht ideal ist und teilweise träge wirkt.
Das System macht beherbergt eigentlich alles, also von Fileserver über Applikationsserver bis Datenbankserver (SQL, Postgre, Actian, MariaDB).
...nur die Backups landen extern.
Sieht also aktuell so aus:
Grundlegend hätte ich gern auf ein Raid 10 gesetzt, da dies für SSDs entsprechend optimiert wurde?
Damit klaue ich mir aber 50% Speicherplatz, was ich mir leider nicht ganz erlauben kann.
...außer, ich lagere einige Systeme auf die SATA SSDs aus:
Alternativ könnte ich natürlich auch splitten, kann aber nicht beurteilen wie sich die Performance des Raid 10 dann macht?
Die ultimative Lösung wird es vermutlich nicht geben, also ist es immer ein Kompromiss, eine Ersatz SSD von den Nytros liegt im
Schrank, bei einem Ausfall kann also entsprechend zügig reagiert werden.
Bin auf eure Meinungen gespannt.
Grüße
ToWa
Edit: Benchmarkergebnisse: Optimierung Raidsystem Hyper-V Host
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3249592275
Url: https://administrator.de/contentid/3249592275
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
52 Kommentare
Neuester Kommentar
Du schreibst nicht, wie viel Speicherkapazität derzeit in Nutzung ist und mit wie viel du rechnest. Du darfst auch nicht vergessen das für Snapshots und eventuell mal den ein oder anderen Restore Platz da sein muss.
Hast du mal Benchmarks laufen lassen um RAID 5 bzw. 6 mit RAID 10 zu vergleichen? Was schafft den der Controller an Bandbreite?
Hast du mal Benchmarks laufen lassen um RAID 5 bzw. 6 mit RAID 10 zu vergleichen? Was schafft den der Controller an Bandbreite?
Zitat von @ukulele-7:
Hast du mal Benchmarks laufen lassen um RAID 5 bzw. 6 mit RAID 10 zu vergleichen? Was schafft den der Controller an Bandbreite?
Hast du mal Benchmarks laufen lassen um RAID 5 bzw. 6 mit RAID 10 zu vergleichen? Was schafft den der Controller an Bandbreite?
Salut,
das System ist noch nicht frei, daher kann ich da gerade nur in der Theorie baden.
Nach meiner Auffassung sollte Raid 6 aber generell die langsamste Option und nicht gerade das Optimum für Datenbanken sein.
Hinsichtlich der Kapazitäten komme ich bei der stumpfen Addition auf 2,8 TB, das bei einem Raid 10 mit 3,2 TB Kapazität bisschen knapp wäre.
Ich hätte aber bspw. einen Archivserver mit 1 TB der problemlos auf die separaten SATA - SSDs könnte, damit wäre wieder ausreichend Platz.
Wäre also möglich, allerdings frage ich mich ob in der Theorie:
- Raid 10 aus 4 Disks für vornehmlich Datenbanken & Raid 5 aus 4 Disks für andere Serversysteme
- Raid 10 über alle 8 Disks
Klar, ein Gesamtstorage wäre für den Speicherplatz auch leichter zu verwalten, ein geteiltes Storage wäre hinsichtlich Zugriffe aber eventuell wieder von Vorteil?
Ich würde mindestens 25% freien Platz (oder in Höhe der größten einzel VM) zu jeder Zeit für Snapshots und Restores bereit halten ansonsten kannst du kaum noch agieren wenn es mal ein Problem gibt. 0,4TB sind verdammt wenig. Wenn du jetzt auf 2 oder 3 Volumes splittest gilt das natürlich für jedes Volume genauso wie für die Gesamtumgebung, das wird bei mehr Volumes also irgendwo zu mehr ungenutztem Speicher führen und je kleiner die Volumes werden desto schneller sind auch mal die freien Kapazitäten aufgebraucht.
RAID 5 und RAID 6 werden sich in der Performance fast gar nicht unterscheiden.
Ein 4 Disk RAID 5 macht aus meiner Sicht allgemein wenig Sinn, das ist irgendwie so die Geiz ist Geil-Lösung.
Wie werden denn die 4 HDDs derzeit genutzt?
RAID 5 und RAID 6 werden sich in der Performance fast gar nicht unterscheiden.
Ein 4 Disk RAID 5 macht aus meiner Sicht allgemein wenig Sinn, das ist irgendwie so die Geiz ist Geil-Lösung.
Wie werden denn die 4 HDDs derzeit genutzt?
Welche 4 HDDs?
Du meinst du 4x SATA SSDs?
Gar nicht, die waren mal als Raid 6 in dem System aktiv, liegen aktuell aber brach.
Verstehe was du mit dem Restoreplatz meinst, im Zweifel ist dafür aber auch ein zweiter Hyper-V vorhanden:
Gefühlte Performance ist auf diesem besser als auf dem Hauptsystem mit dem Raid 6, sind aber auch nur die für den Übergangsbetrieb unabdingbaren VMs gehostet.
Hauptsächlich geht es mir einfach darum die Datenbanken gescheit zu versorgen, der Controller könnte ja auch Raid 50 oder gar 60, über alle Platten, aber auch da muss wieder mehr berechnet werden als bei einem simplen Raid 10.
Kenne WD Red nur als HDD aber mag sein das es auch SSD gibt. Dann sollten die auf jeden Fall für den Archiv Server her halten.
Die übrigen Platten würde ich wirklich mal einem Benchmark unterziehen um eine Vorstellung vom Unterscheid zwischen RAID 5 und RAID 10 zu bekommen. Die größte Gefahr für einen klassischen RAID geht aus meiner Sicht von einem Rebuild aus. Wenn eine Disk versagt und der Rebuild auf das cold oder hot spare läuft müssen beim RAID 5 alle Sektoren aller verbliebenen Platten fehlerfrei liefern, da gibt es ein hohes Risiko das ein weiterer Lesefehler deinen RAID kompromittiert. Ein RAID 6 kann einen weiteren Fehler verkraften, das hat schon seinen Reiz.
Ob die Datenbanken überhaupt von RAID 10 profitieren kann man pauschal nicht sagen. Datenbanken profitieren auf jeden Fall von RAM aber wie viel Disk IO machen deine Datenbanken? Das müsste man schon sehr genau betrachten um da einen Effekt zu sehen.
Die übrigen Platten würde ich wirklich mal einem Benchmark unterziehen um eine Vorstellung vom Unterscheid zwischen RAID 5 und RAID 10 zu bekommen. Die größte Gefahr für einen klassischen RAID geht aus meiner Sicht von einem Rebuild aus. Wenn eine Disk versagt und der Rebuild auf das cold oder hot spare läuft müssen beim RAID 5 alle Sektoren aller verbliebenen Platten fehlerfrei liefern, da gibt es ein hohes Risiko das ein weiterer Lesefehler deinen RAID kompromittiert. Ein RAID 6 kann einen weiteren Fehler verkraften, das hat schon seinen Reiz.
Ob die Datenbanken überhaupt von RAID 10 profitieren kann man pauschal nicht sagen. Datenbanken profitieren auf jeden Fall von RAM aber wie viel Disk IO machen deine Datenbanken? Das müsste man schon sehr genau betrachten um da einen Effekt zu sehen.
Zitat von @ukulele-7:
Ob die Datenbanken überhaupt von RAID 10 profitieren kann man pauschal nicht sagen. Datenbanken profitieren auf jeden Fall von RAM aber wie viel Disk IO machen deine Datenbanken?
Ob die Datenbanken überhaupt von RAID 10 profitieren kann man pauschal nicht sagen. Datenbanken profitieren auf jeden Fall von RAM aber wie viel Disk IO machen deine Datenbanken?
Vermutlich wird das nachher gar nicht ins Gewicht fallen, aber ich mache mir da gern vor einem Neuaufbau Gedanken.
Nachher ärgert man sich und packt den Server noch mal an, muss nicht sein.
Mal so ganz allgemein zu Raid 10:
Lesen: Um ~35% langsamer als RAID 5 mit 4 SSDs
Schreiben: 4 SSDs 1,46 Mal so schnell wie eine SSD, und 1,38 Mal so schnell wie RAID 5
Schreiben: 4 SSDs 1,46 Mal so schnell wie eine SSD, und 1,38 Mal so schnell wie RAID 5
65/35 mixed: Latenzen von RAID 5 mit 4 SSDs sind, im Vergleich zu RAID 10, fast 2 Mal so hoch
Schreiben: Latenzen von RAID 5 mit 4 SSDs sind, im Vergleich zu RAID 10, 6 Mal so hoch
Quelle: https://www.thomas-krenn.com/de/wiki/SSD_RAID_Performance-TestsSchreiben: Latenzen von RAID 5 mit 4 SSDs sind, im Vergleich zu RAID 10, 6 Mal so hoch
Wenn ich das auf Raid 6 adaptiere wird das noch mal gruseliger.
Dann kommt aber natürlich wieder der Cache des Raidcontrollers mit 8GB der das Latenzproblem auffangen sollte.
Hinsichtlich der Sektorproblematik bei Wiederherstellung hast du recht mit Raid 6, nun könnte man aber ganz verwegen sein und sagen die SSDs haben alle identische "gesamte Schreibleistungen", da die Daten verteilt geschrieben werden, ist die Abnutzung relativ identisch.
Ich würde daher auch behaupten, dass die Wahrscheinlichkeit eines Mehrfachdefekts bei SSDs höher ist als bei HDDs, ob es mir im Zweifel hilft eine weitere Platte potenziell in der Rückhand zu haben - wer weiß.
Prinzipiell könnten bei Raid 10 ebenfalls 2 Platten ausfallen, diese müssen nur im jeweils anderen Set sein.
Ich habe mal noch addiert und gruppiert, nötiger Speicherplatz für:
Würde sich damit wie folgt ausgehen:
Beides möglich.
- Datenbankorientierte Systeme: 1,3 TB (wobei davon 500 GB zu einem System in Ablösung zählen)
- Serviceorientierte Systeme: 2,4 TB (da lassen sich wie gesagt 1 TB vom Archivsystem auf SATA-SSDs rauslösen)
Würde sich damit wie folgt ausgehen:
- Raid 10 mit 8 Disks: 3,2 TB
- -> 2,5 TB aktuell belegt, 2 TB aktuell belegt wenn das in Ablösung befindliche System rausgerechnet wird
- -> Rest auf SATA SSDs ausgelagert
- Raid 10 & Raid 5 mit je 4 Disks
- -> Raid 10 mit 1,6 TB zu 1,3 TB bzw. 0,8 TB belegt (wenn Ablösesystem weg)
- -> Raid 5 mit 2,4 TB zu 1,4 TB belegt (Archivsystem auf SATA-SSDs verlegt)
Beides möglich.
Teste lieber auf deiner Hardware wenn die Gelegenheit da ist.
Plane nicht zu knapp. Wenn du jetzt schon mit System in Ablösung planst kommen bestimmt auch neue Sachen dazu.
Ich würde sagen die Abnutzung bei SSDs ist, wegen diverser Techniken bei der Optimierung/Verwaltung der Zellen durch die SSD selbst, vermutlich nicht sehr linear in der Entwicklung, eher bei HDDs. Früher hat man gezielt HDDs aus verschiedenen Chargen verbaut weil genau das ein Problem war: Gleiche Nutzung, zeitgleicher Ausfall.
Plane nicht zu knapp. Wenn du jetzt schon mit System in Ablösung planst kommen bestimmt auch neue Sachen dazu.
Ich würde sagen die Abnutzung bei SSDs ist, wegen diverser Techniken bei der Optimierung/Verwaltung der Zellen durch die SSD selbst, vermutlich nicht sehr linear in der Entwicklung, eher bei HDDs. Früher hat man gezielt HDDs aus verschiedenen Chargen verbaut weil genau das ein Problem war: Gleiche Nutzung, zeitgleicher Ausfall.
Zitat von @ukulele-7:
Plane nicht zu knapp. Wenn du jetzt schon mit System in Ablösung planst kommen bestimmt auch neue Sachen dazu.
Plane nicht zu knapp. Wenn du jetzt schon mit System in Ablösung planst kommen bestimmt auch neue Sachen dazu.
Tatsächlich sind die neuen schon alle da, die alten müssen nur noch vollständig überführt werden.
Aber Mittwoch sollte es soweit sein, dass ich mal ein wenig was an Benchmarks erstellen kann, zwar nur am leeren System aber ggf. kann man dann zu Raid 10 only und Raid 10 & Raid 5 kombi etwas sagen.
Vorschläge was ich an Programmen/Benchmarks vergleichen sollte?
Also für reine Schreib/Lesetests ist ATTO immer ganz easy gewesen. IOmeter müsste für Datenbankszenarien gut taugen leider bin ich nie wirklich dazu gekommen da mal richtig tief einzusteigen. Vielleicht gibt's hier noch was gutes:
https://www.thomas-krenn.com/de/wiki/I/O_Performance_Benchmarking_Tools_ ...
https://www.thomas-krenn.com/de/wiki/I/O_Performance_Benchmarking_Tools_ ...
Moin ToWa,
die Trägheit wird aber sicherlich nicht am RAID6 liegen, schon gar nicht, wenn du z.B. bereits schon lesend Probleme feststellen solltest.
Nein, RAID 10 ist keineswegs für SSD's optimiert und bringt insbesondere bei diesen auch keine höhere Performance, zumindest dann nicht, wenn du einen anständigen RAID-Controller für die SSD's verwendest.
Im Gegenteil, RAID 10 ist insbesondere beim Schreiben meistens viel lahmer wie ein RAID5.
Gruss Alex
da ich hier gerade einen unserer Hyper-V Hosts räume, um diesen frisch zu installieren,
mache ich mir ebenfalls Gedanken über das Raidset.
Der Systembetreuer hat das Gerät mit Raid 6 ausgeliefert, was in meinen Augen nicht ideal ist und teilweise träge wirkt.
mache ich mir ebenfalls Gedanken über das Raidset.
Der Systembetreuer hat das Gerät mit Raid 6 ausgeliefert, was in meinen Augen nicht ideal ist und teilweise träge wirkt.
die Trägheit wird aber sicherlich nicht am RAID6 liegen, schon gar nicht, wenn du z.B. bereits schon lesend Probleme feststellen solltest.
Grundlegend hätte ich gern auf ein Raid 10 gesetzt, da dies für SSDs entsprechend optimiert wurde?
Damit klaue ich mir aber 50% Speicherplatz, was ich mir leider nicht ganz erlauben kann.
Damit klaue ich mir aber 50% Speicherplatz, was ich mir leider nicht ganz erlauben kann.
Nein, RAID 10 ist keineswegs für SSD's optimiert und bringt insbesondere bei diesen auch keine höhere Performance, zumindest dann nicht, wenn du einen anständigen RAID-Controller für die SSD's verwendest.
Im Gegenteil, RAID 10 ist insbesondere beim Schreiben meistens viel lahmer wie ein RAID5.
Gruss Alex
Zitat von @MysticFoxDE
Nein, RAID 10 ist keineswegs für SSD's optimiert und bringt insbesondere bei diesen auch keine höhere Performance, zumindest dann nicht, wenn du einen anständigen RAID-Controller für die SSD's verwendest.
Im Gegenteil, RAID 10 ist insbesondere beim Schreiben meistens viel lahmer wie ein RAID5.
Nein, RAID 10 ist keineswegs für SSD's optimiert und bringt insbesondere bei diesen auch keine höhere Performance, zumindest dann nicht, wenn du einen anständigen RAID-Controller für die SSD's verwendest.
Im Gegenteil, RAID 10 ist insbesondere beim Schreiben meistens viel lahmer wie ein RAID5.
Hey Alex,
ich hatte das gestern gelesen, dass Raid 10 als einziges Raidlevel für SSDs angepasst/optimiert wurde.
Ist aber tatsächlich so, dass bei SSDs ein bisschen was zu berücksichtigen ist.
Mal als Bsp.:
With SSDs, everything is different: Their performance is already so high that a write cache only slows things down because of the associated overhead. This is confirmed by the measurement results in Figure 4: In a RAID 5 with four SSDs, the write IOPS decreased with writeback activated from 14,400 to 3,000 – nearly 80 percent fewer IOPS. The only advantage of the write cache is low write latencies for RAID 5 sets. Because latencies are even lower for RAID 1 (no parity calculations and no write cache), this advantage is quickly lost. The recommendation is thus: Use SSD RAID without write cache (i.e., write through instead of write back). This also means savings of about $150-$250 for the BBU or flash protection module.
Read ahead – reading data blocks that reside behind the currently requested data – is also a performance optimization that only offers genuine benefits for hard disks. In RAID 5 with four SSDs, activating read ahead slowed down the read IOPS these tests by 20 percent (from 175,000 to 140,000 read IOPS). In terms of throughput, you'll see no performance differences for reading with 64KB or 1,024KB blocks. Read ahead only offered benefits in our lab in throughput with 8KB blocks. Additionally, read ahead can only offer benefits in single-threaded read tests (e.g., with dd on Linux). However, both access patterns are atypical in server operations. My recommendation is therefore to run SSD RAIDs without read ahead.
Quelle: https://www.admin-magazine.com/Archive/2015/28/Tuning-SSD-RAID-for-optim ...
Bei IONIS sind die Raidlevel tatsächlich recht gut erklärt, ohne dabei auf Details einzugehen:
Raid 10: https://www.ionos.de/digitalguide/server/sicherheit/raid-10/
- auf die in aller Regelmäßigkeit zugegriffen wird;
- die möglichst schnell lesbar sein sollen;
- die ein Höchstmaß an Sicherheit genießen sollen.
Raid 6: https://www.ionos.de/digitalguide/server/sicherheit/raid-6/
- große Datenmengen langfristig ausfallsicher speichern
- Serversysteme, auf denen Daten archiviert werden
- Auch Datenbank- oder Transaktionsserver
Ansonsten korrekt, wie oben von Thomas-Krenn zitiert ist die Leseperformance ~35% langsamer als Raid 5 mit 4 SSDs, dafür sind eben die Zugriffszeiten deutlich besser und ich hätte im Zweifel 8 SSDs und keine 4, wodurch sich die max. Leseperformance in Luft auflöst.
Viel spannender finde ich aber die o.g. Einstellungen zu Write Cache und Read Ahead, wobei der Artikel aus 2015 vermutlich nicht auf relativ aktuelle Controller anwendbar ist?
ToWa
Zum Thema Cache ist ja grade ein neuer Thread auf gemacht worden:
SSD RAID - Controller mit Cache oder ohne?
Was sowohl den spezifischen Controller als auch die Wahl des RAID Levels angeht würde ich mir erst mit Benchmarks einen Eindruck verschaffen. Ich tendiere aber eher zu RAID 5 oder 6. Grund: Du hantierst mit relativ wenig Reserven, ich gehe also davon aus das deine Datenmengen nicht sonderlich schnell wachsen. Datenbanken lesen ja meist so schon mehr als sie schreiben, bei dir wird das vermutlich deutlich sein. Daher eher RAID 5 für Leseperformance, auch für die DBs. Und es bietet dir schlicht mehr Spielraum beim Platz.
SSD RAID - Controller mit Cache oder ohne?
Was sowohl den spezifischen Controller als auch die Wahl des RAID Levels angeht würde ich mir erst mit Benchmarks einen Eindruck verschaffen. Ich tendiere aber eher zu RAID 5 oder 6. Grund: Du hantierst mit relativ wenig Reserven, ich gehe also davon aus das deine Datenmengen nicht sonderlich schnell wachsen. Datenbanken lesen ja meist so schon mehr als sie schreiben, bei dir wird das vermutlich deutlich sein. Daher eher RAID 5 für Leseperformance, auch für die DBs. Und es bietet dir schlicht mehr Spielraum beim Platz.
1Zitat von @ukulele-7:
Was sowohl den spezifischen Controller als auch die Wahl des RAID Levels angeht würde ich mir erst mit Benchmarks einen Eindruck verschaffen.
Was sowohl den spezifischen Controller als auch die Wahl des RAID Levels angeht würde ich mir erst mit Benchmarks einen Eindruck verschaffen.
Das werde ich morgen tun, zudem ist gerade eine Anfrage an den areca-Support hinsichtlich SSD Settings raus.
Die Jungs waren da bislang immer ganz gut auf Zack, mal sehen ob ich da heute Nacht eine Antwort aus Taiwan bekomme.
Edit: Antwort schon da, allerdings scheut man sich auch dort vor belastbaren Aussagen...
Dear Sir/Madam,
we do not have recommend settings as the situation may vary with your applications, you have to try to find it out.
you can use benchmark software like iometer to test the volume to find out the best settings for your application.
iometer can configure the test pattern to meet your application.
Best Regards,
So, Testtag läuft.
IOMeter scheidet wohl direkt aus, die Software startet auf dem Hyper-V Core nicht.
IOMeter scheidet wohl direkt aus, die Software startet auf dem Hyper-V Core nicht.
Du kannst auch innerhalb einer VM benchmarken aber sieht ja schon mal gut aus.
So, erstes Ergebnis mit dem IST Raid 6 vs. RAID 10 (8 Disks).
Da brauchen wir glaub ich gar nicht lang reden...
Ich fahre jetzt noch den Test mit Raid 10 (4 Disks) & Raid 5 (4 Disks).
Da brauchen wir glaub ich gar nicht lang reden...
Ich fahre jetzt noch den Test mit Raid 10 (4 Disks) & Raid 5 (4 Disks).
Merkwürdig wie sich die IOPS verteilen. Bei 4k-64Th ist write deutlich schneller bei RAID 10 read aber kaum. Und umgekehrt beim Zugriff write gleich und read deutlich schneller. Ich kriege von sowas Kopfschmerzen aber ja, RAID 10 scheint grundsätzlich schneller in dieser Konstellation.
PS: Eventuell nochmal in der VM testen.
PS: Eventuell nochmal in der VM testen.
Ich brauch die Performance am Host.
Aber ja, ich bekomme da auch Kopfweh, vor allem wenn man dann noch überlegt welche StripeSize wohl ideal wäre.
Nach meinem Verständnis große Dateien (VHDX) gleich große StripeSize, nach Recherche werden wohl 64 KB empfohlen, ich hatte hier gerade mal 256 KB genommen, weil mein Bauchgefühl mir das so sagte.
Einfach mal wechseln zum Test ist auch nicht, das Set muss dafür migriert werden - so viel Zeit hab ich dann auch nicht.
Also eher löschen und noch mal neu installieren.
So, 256 KB vs. 64 KB in Raid 10 mit 8 Disks aufgenommen.
500 MB sequenzielles Schreiben verpuffen, dafür gibt es 15 MB mehr an Schreibperformance in 4K Blöcken.
Guter Rat ist teuer, ich würde tendenziell aber auf die 500 MB sequenziell verzichten?
Nun mache ich mal mit 4 Disk Raid 10 weiter und beschränke mich da erstmal auf die 64 KB StripeSize.
500 MB sequenzielles Schreiben verpuffen, dafür gibt es 15 MB mehr an Schreibperformance in 4K Blöcken.
Guter Rat ist teuer, ich würde tendenziell aber auf die 500 MB sequenziell verzichten?
Nun mache ich mal mit 4 Disk Raid 10 weiter und beschränke mich da erstmal auf die 64 KB StripeSize.
Ergänzung, nun mit RAID 10 & 5 á 4 Disks...
Bei dem Resultat erstelle ich noch mal ein RAID 6 über alle Disks, also so wie es eigentlich ganz zuvor war.
Ich glaube fast nicht, dass der Unterschied zwischen RAID 6 und 5 so krass ist.
...oder aber die Performance lässt bei einem "gebrauchten" Raidset überproportional stark nach.
Dann müsste ich aber mal mit areca sprechen ob ggf. keine TRIM Befehle an die SSD rausgehen.
Bei den Neuerstellungen der Volumens macht er das nämlich brav TRIM über alle Laufwerke.
Bei dem Resultat erstelle ich noch mal ein RAID 6 über alle Disks, also so wie es eigentlich ganz zuvor war.
Ich glaube fast nicht, dass der Unterschied zwischen RAID 6 und 5 so krass ist.
...oder aber die Performance lässt bei einem "gebrauchten" Raidset überproportional stark nach.
Dann müsste ich aber mal mit areca sprechen ob ggf. keine TRIM Befehle an die SSD rausgehen.
Bei den Neuerstellungen der Volumens macht er das nämlich brav TRIM über alle Laufwerke.
So, wie befürchtet wird es nun nicht einfacher...
Das neu erstellte Raid 6 ist deutlich besser als das 1,5 Jahre alte, im sequenziellen Schreiben aber dennoch deutlich unterlegen.
Nun bin ich aber vollends verwirrt.
Das neu erstellte Raid 6 ist deutlich besser als das 1,5 Jahre alte, im sequenziellen Schreiben aber dennoch deutlich unterlegen.
Nun bin ich aber vollends verwirrt.
Könnte auch sein das die SSDs da rein funken und irgendwas optimieren aber da fehlt mir echt die Erfahrung.
Auf dem Hostsystem läuft aber nichts anderes während des Benchmark nehme ich an?
Auf dem Hostsystem läuft aber nichts anderes während des Benchmark nehme ich an?
Zitat von @ukulele-7:
Auf dem Hostsystem läuft aber nichts anderes während des Benchmark nehme ich an?
Auf dem Hostsystem läuft aber nichts anderes während des Benchmark nehme ich an?
Nope, weder vorher noch jetzt ist, ist ja ein Core und alle VMs waren ja schon weg vom System.
Ich denke ich schlaf mal ne Nacht drüber und areca habe ich mit den Ergebnissen gerade auch noch mal konfrontiert.
Vielleicht hat ja hier auch noch jemand einen schlauen Einfall...?
Die Optionen bleiben ja zu den Messergebnissen:
- Raid 6
- Raid 10
- Raid 10 & 5 in Kombination
Hiernach sollte auch Raid 10 genommen werden: https://www.techtarget.com/searchstorage/definition/RAID-10-redundant-ar ...
Ass Disk mit 10 GB soll was Aussagen?
Ich würde mit IOMeter und der Realität entsprechenden Workloads das Setup überprüfen.
Ich würde mit IOMeter und der Realität entsprechenden Workloads das Setup überprüfen.
Zitat von @2423392070:
Ass Disk mit 10 GB soll was Aussagen?
Mir ging es erstmal als Richtwert um die Übertragungsraten und da IOMeter am Core Server nicht läuft hab ich keine Vergleichswerte von vorher.Ass Disk mit 10 GB soll was Aussagen?
Ich könnte auch die 1 GB Datei nehmen, habe ich aber nicht gemacht, da der Controller 8 GB DDR3 RAM hat...
Nach der Info des areca Support ist übrigens egal, die Seq-Werte kann ich ignorieren, da das Raidset offenbar nicht mit dem TRIM-Befehl versorgt wird/werden kann und die ermittelten Werte entsprechend normal sind.
https://www.it-daily.net/speicherguide/storage-spg/problem-ssds-mit-trim ...
Bedeutet im Umkehrschluss, dass alle Volumes nach einiger Zeit Leistung einbüßen, aber auch, dass das nicht nur ein Gefühl ist, dass die VMs auf dem frisch installierten zweiten Host mit Raid 5 aus 4 SSDs performanter laufen.
Nun stellt sich nur die Frage welchen Schluss ich daraus ziehe.
- Ich nehme vollständig Raid 10 um möglichst viel Performance in die Laufzeit reinzugeben
- Ich nehme die Variante Raid 10 & 5 um die Systeme auf unterschiedliche Volumes zu teilen und somit deutlich einfacher während der Laufzeit mal ein Volume zu plätten und neu zu intitialisieren
Moin dertowa,
bin im Stress, daher muss ich mich kurz fassen.
Bei deinem Test mit RAID6 VS RAID10 passt etwas nicht.
Bei dem RAID6 müsste sowohl die Lese- als auch die Schreibperformance deutlich höher sein!
In deiner Konstellation solltest du im RAID6 beim Lesen +- die summarische Performance von 6 einelnen SSD's erreichen und davon bist du mit deinen Ergebnissen weit entfernt.
Beim Schreiben sollte das ähnlich aussehen, hier musss der Controller zwar noch die Parität berechnen und auf zwei SSD's schreiben, das macht ein moderner Controller normalerweise quasi im Schlaf.
Wie schnell sind die SSD's am Controller angebunden 6G oder 12G?
Gruss Alex
bin im Stress, daher muss ich mich kurz fassen.
Bei deinem Test mit RAID6 VS RAID10 passt etwas nicht.
Bei dem RAID6 müsste sowohl die Lese- als auch die Schreibperformance deutlich höher sein!
In deiner Konstellation solltest du im RAID6 beim Lesen +- die summarische Performance von 6 einelnen SSD's erreichen und davon bist du mit deinen Ergebnissen weit entfernt.
Beim Schreiben sollte das ähnlich aussehen, hier musss der Controller zwar noch die Parität berechnen und auf zwei SSD's schreiben, das macht ein moderner Controller normalerweise quasi im Schlaf.
Wie schnell sind die SSD's am Controller angebunden 6G oder 12G?
Gruss Alex
Hallo Alex,
die SSDs laufen mit 12G am Controller.
Seitens areca gibt es auch keine Einstellungsvorgaben die HDD und SSD am Controller unterscheiden, dieser erkennt was er da am Kabel hängen hat.
Wie gesagt die Leistung steigt wenn die Dateien kleiner werden, aber dann bin ich ja im Cache des Controllers unterwegs...
Seagate gibt die Leistungsdaten bei 128 bzw. 4KB an:
Moin dertowa,
ja, das sieht doch schon deutlich besser aus.
Und mit RAID5 bekommst du nochmals mehr Bums. 😉
Mach übrigens das Strippe-Set so klein wie möglich, dann hast du beim Schreiben die beste random Performance.
SSD's die in einem RAID an einem Hardware-RAID-Controller hängen können grundsätzlich vom OS nicht getrimmt werden. Hier muss man dem Windows des Trimmen von Hand abgewöhnen.
Siehe.
https://www.easeus.com/resource/trim-ssd-windows-10.html
Nicht, wenn der Controller selbst seine Arbeit richtig macht.
Wenn das Enterprise-SSD's sind, dann nimm RAID5 und gut ist.
Die Dinger gehen im Vergleich zu Festplatten, so gut wie nie kaputt.
Habe in den letzten >10 Jahren schon xxx davon in SAN's verbaut (allesamt RAID5).
RAID6 nehme ich nur bei Backup-SAN's und HDD's. 🙃
Gruss Alex
Ich könnte auch die 1 GB Datei nehmen, habe ich aber nicht gemacht, da der Controller 8 GB DDR3 RAM hat...
ja, das sieht doch schon deutlich besser aus.
Und mit RAID5 bekommst du nochmals mehr Bums. 😉
Mach übrigens das Strippe-Set so klein wie möglich, dann hast du beim Schreiben die beste random Performance.
Nach der Info des areca Support ist übrigens egal, die Seq-Werte kann ich ignorieren, da das Raidset offenbar nicht mit dem TRIM-Befehl versorgt wird/werden kann und die ermittelten Werte entsprechend normal sind.
https://www.it-daily.net/speicherguide/storage-spg/problem-ssds-mit-trim ...
https://www.it-daily.net/speicherguide/storage-spg/problem-ssds-mit-trim ...
SSD's die in einem RAID an einem Hardware-RAID-Controller hängen können grundsätzlich vom OS nicht getrimmt werden. Hier muss man dem Windows des Trimmen von Hand abgewöhnen.
Siehe.
https://www.easeus.com/resource/trim-ssd-windows-10.html
Bedeutet im Umkehrschluss, dass alle Volumes nach einiger Zeit Leistung einbüßen, aber auch, dass das nicht nur ein Gefühl ist, dass die VMs auf dem frisch installierten zweiten Host mit Raid 5 aus 4 SSDs performanter laufen.
Nicht, wenn der Controller selbst seine Arbeit richtig macht.
Nun stellt sich nur die Frage welchen Schluss ich daraus ziehe.
- Ich nehme vollständig Raid 10 um möglichst viel Performance in die Laufzeit reinzugeben
- Ich nehme die Variante Raid 10 & 5 um die Systeme auf unterschiedliche Volumes zu teilen und somit deutlich einfacher während der Laufzeit mal ein Volume zu plätten und neu zu intitialisieren
Wenn das Enterprise-SSD's sind, dann nimm RAID5 und gut ist.
Die Dinger gehen im Vergleich zu Festplatten, so gut wie nie kaputt.
Habe in den letzten >10 Jahren schon xxx davon in SAN's verbaut (allesamt RAID5).
RAID6 nehme ich nur bei Backup-SAN's und HDD's. 🙃
Gruss Alex
Moin dertowa,
12G lecker, dann sollte man aus den 8 SSD's aber noch deutlich mehr rausholen können.
Jup, das ist auch gut so und hoffentlich ist dieser per Akku/Power-CAP gepuffert.
Haben die Seagate-SSD's einen eigenen Cache und wenn ja, ist dieser am Areca überhaupt aktiviert?
Und bevor mich hier jetzt jemand wegen dem Drive-Cache und einem Strohmausfall belehren möchte.
Wir sprechen hier über (hoffentlich) Enterprise SSD's und hier verhält sich die Materie ganz anders als bei HDD's oder auch Konsumer-SSD's.
Beste Grüsse aus BaWü
Gruss Alex
die SSDs laufen mit 12G am Controller.
Seitens areca gibt es auch keine Einstellungsvorgaben die HDD und SSD am Controller unterscheiden, dieser erkennt was er da am Kabel hängen hat.
Seitens areca gibt es auch keine Einstellungsvorgaben die HDD und SSD am Controller unterscheiden, dieser erkennt was er da am Kabel hängen hat.
12G lecker, dann sollte man aus den 8 SSD's aber noch deutlich mehr rausholen können.
Wie gesagt die Leistung steigt wenn die Dateien kleiner werden, aber dann bin ich ja im Cache des Controllers unterwegs...
Jup, das ist auch gut so und hoffentlich ist dieser per Akku/Power-CAP gepuffert.
Seagate gibt die Leistungsdaten bei 128 bzw. 4KB an:
Haben die Seagate-SSD's einen eigenen Cache und wenn ja, ist dieser am Areca überhaupt aktiviert?
Und bevor mich hier jetzt jemand wegen dem Drive-Cache und einem Strohmausfall belehren möchte.
Wir sprechen hier über (hoffentlich) Enterprise SSD's und hier verhält sich die Materie ganz anders als bei HDD's oder auch Konsumer-SSD's.
Beste Grüsse aus BaWü
Gruss Alex
I try my very best.
Vom Controller kann ich auf 4 KB gehen, teste ich gleich mal, bei meiner Recherche wurde aber immer von mind. 64 KB gesprochen und wenn ich bei den Leistungsdaten von Seagate sehe, dass die für sequenzielles Schreiben 128 KB und sonst 4 KB angeben, wäre irgendwo der goldene Mittelweg der richtige?
...denn nach Marketing gibt der Hersteller immer das an was am besten läuft.
Zur Auswahl stehen StripeSizes:
4 / 8 / 16 / 32 / 64 / 128
Die goldene Mitte der SSD Angaben wäre also 16 oder 32.
Windows erkennt das Raidset glaub ich nicht als SSD, check ich aber definitiv noch mal.
Also ja, Ausfall ist relativ selten, gerade bei diesem Set aber schon vorgekommen.
Hier mal noch Raid 10 over 8 mit 1GB...
Edit:
StripeSize 16 KB zu 64 KB liegt in der Messtoleranz, also nicht entscheidend bzw. eher nachteilig:
Mach übrigens das Strippe-Set so klein wie möglich, dann hast du beim Schreiben die beste random Performance.
Das ergab auch mein Spontantest, 256 vs 64.Vom Controller kann ich auf 4 KB gehen, teste ich gleich mal, bei meiner Recherche wurde aber immer von mind. 64 KB gesprochen und wenn ich bei den Leistungsdaten von Seagate sehe, dass die für sequenzielles Schreiben 128 KB und sonst 4 KB angeben, wäre irgendwo der goldene Mittelweg der richtige?
...denn nach Marketing gibt der Hersteller immer das an was am besten läuft.
Zur Auswahl stehen StripeSizes:
4 / 8 / 16 / 32 / 64 / 128
Die goldene Mitte der SSD Angaben wäre also 16 oder 32.
SSD's die in einem RAID an einem Hardware-RAID-Controller hängen können grundsätzlich vom OS nicht getrimmt werden. Hier muss man dem Windows des Trimmen von Hand abgewöhnen.
Siehe.
https://www.easeus.com/resource/trim-ssd-windows-10.html
Siehe.
https://www.easeus.com/resource/trim-ssd-windows-10.html
Windows erkennt das Raidset glaub ich nicht als SSD, check ich aber definitiv noch mal.
Wenn das Enterprise-SSD's sind, dann nimm RAID5 und gut ist.
Die Dinger gehen im Vergleich zu Festplatten, so gut wie nie kaputt.
Ausnahmen bestätigen die Regel, ich hatte in den Servern bis auf diese Seagate - Platten noch keine Defekte.Die Dinger gehen im Vergleich zu Festplatten, so gut wie nie kaputt.
Also ja, Ausfall ist relativ selten, gerade bei diesem Set aber schon vorgekommen.
Hier mal noch Raid 10 over 8 mit 1GB...
Edit:
StripeSize 16 KB zu 64 KB liegt in der Messtoleranz, also nicht entscheidend bzw. eher nachteilig:
Was für eine PCIe Version und wie viele Lanes hat denn der Controller bzw. der Slot in dem der Controller läuft? Ist da eventuell die RAID 5 / 6 Performance limitiert?
https://en.wikipedia.org/wiki/PCI_Express
https://en.wikipedia.org/wiki/PCI_Express
1Zitat von @MysticFoxDE:
12G lecker, dann sollte man aus den 8 SSD's aber noch deutlich mehr rausholen können.
Da haste recht, denn hier kommt "no difference" zwischen 4 und 8 disks!12G lecker, dann sollte man aus den 8 SSD's aber noch deutlich mehr rausholen können.
Mal die Werte für Raid 10 & 5 mit 4 Platten ergänzt.
Jup, das ist auch gut so und hoffentlich ist dieser per Akku/Power-CAP gepuffert.
Natürlich, hier wird nicht gepfuscht. Haben die Seagate-SSD's einen eigenen Cache und wenn ja, ist dieser am Areca überhaupt aktiviert?
Davon steht in den Specs der SSDs nichts. Wir sprechen hier über (hoffentlich) Enterprise SSD's
Selbstredend sind das Enterprise SSDs.Modell: XS800LE70004
https://www.seagate.com/de/de/enterprise-storage/nytro-drives/nytro-sas- ...
Zitat von @ukulele-7:
Was für eine PCIe Version und wie viele Lanes hat denn der Controller bzw. der Slot in dem der Controller läuft?
areca gibt PCIe 3.0 mit 8 Lanes an: https://www.areca.us/support/download/adapter/doc/ARC-1883_specification ...Was für eine PCIe Version und wie viele Lanes hat denn der Controller bzw. der Slot in dem der Controller läuft?
Steckt im Supermicro H11SSW-NT im einzigen 16x Slot.
Ich muss gestehen mir läuft ein wenig die Zeit weg.
Das Teil muss heute Abend wieder laufen, momentan tendiere ich zu meiner Splittung, Raid 10 & Raid 5 mit je 4 Disks.
Die weiteren 4 SATA-SSDs bekommen dann Raid 6 für Archivsysteme.
...ansonsten ist Raid 6 aus meiner Überlegung komplett raus, die Werte sind vergleichsweise grottig.
@MysticFoxDE
Hast übrigens Recht hinsichtlich TRIM, Server 2022 gibt aus, dass dies für NTFS und ReFS aktiviert ist.
Das kommt dann mit auf meine Liste zur Deaktivierung nach finaler Installation.
Allerdings müssten die commands beim Controller enden, denn Zitat areca:
1. controller do not support TRIM commands from operation system.
2. controller send TRIM command to drives only when you create the array
Zitat von @dertowa:
Ich könnte auch die 1 GB Datei nehmen, habe ich aber nicht gemacht, da der Controller 8 GB DDR3 RAM hat...
Nach der Info des areca Support ist übrigens egal, die Seq-Werte kann ich ignorieren, da das Raidset offenbar nicht mit dem TRIM-Befehl versorgt wird/werden kann und die ermittelten Werte entsprechend normal sind.
https://www.it-daily.net/speicherguide/storage-spg/problem-ssds-mit-trim ...
Bedeutet im Umkehrschluss, dass alle Volumes nach einiger Zeit Leistung einbüßen, aber auch, dass das nicht nur ein Gefühl ist, dass die VMs auf dem frisch installierten zweiten Host mit Raid 5 aus 4 SSDs performanter laufen.
Nun stellt sich nur die Frage welchen Schluss ich daraus ziehe.
Zitat von @2423392070:
Ass Disk mit 10 GB soll was Aussagen?
Mir ging es erstmal als Richtwert um die Übertragungsraten und da IOMeter am Core Server nicht läuft hab ich keine Vergleichswerte von vorher.Ass Disk mit 10 GB soll was Aussagen?
Ich könnte auch die 1 GB Datei nehmen, habe ich aber nicht gemacht, da der Controller 8 GB DDR3 RAM hat...
Nach der Info des areca Support ist übrigens egal, die Seq-Werte kann ich ignorieren, da das Raidset offenbar nicht mit dem TRIM-Befehl versorgt wird/werden kann und die ermittelten Werte entsprechend normal sind.
https://www.it-daily.net/speicherguide/storage-spg/problem-ssds-mit-trim ...
Bedeutet im Umkehrschluss, dass alle Volumes nach einiger Zeit Leistung einbüßen, aber auch, dass das nicht nur ein Gefühl ist, dass die VMs auf dem frisch installierten zweiten Host mit Raid 5 aus 4 SSDs performanter laufen.
Nun stellt sich nur die Frage welchen Schluss ich daraus ziehe.
- Ich nehme vollständig Raid 10 um möglichst viel Performance in die Laufzeit reinzugeben
- Ich nehme die Variante Raid 10 & 5 um die Systeme auf unterschiedliche Volumes zu teilen und somit deutlich einfacher während der Laufzeit mal ein Volume zu plätten und neu zu intitialisieren
Sehe da auch keine Richtwerte.
Feature on demand kennst Du?
Zitat von @2423392070:
Sehe da auch keine Richtwerte.
Feature on demand kennst Du?
Sehe da auch keine Richtwerte.
Feature on demand kennst Du?
Was möchtest du bitte?
Mir ging es hier eigentlich nur um den "best practise" für einen Neuaufbau des Raidsets.
...dass die spontan genommenen Benchmarkwerte vor Löschung des Raidsets so weit auseinander klaffen war mir vorher nicht klar...
Auf dem System läuft alles, ich kann also nicht sagen "ich optimiere mal für Datenbanken" oder "ich brauche maximale Datenübertragung".
Noch mal, vom Systembuilder war das Teil in der Raid 6 Konfiguration, nach meiner bisherigen Auswertung sehe ich das aber nicht als ideal an.
Zitat von @ukulele-7:
Was für eine PCIe Version und wie viele Lanes hat denn der Controller bzw. der Slot in dem der Controller läuft? Ist da eventuell die RAID 5 / 6 Performance limitiert?
https://en.wikipedia.org/wiki/PCI_Express
Was für eine PCIe Version und wie viele Lanes hat denn der Controller bzw. der Slot in dem der Controller läuft? Ist da eventuell die RAID 5 / 6 Performance limitiert?
https://en.wikipedia.org/wiki/PCI_Express
👍👍👍, sehr gute Frage!
PCI Express 3.0's 8 GT/s bit rate effectively delivers 985 MB/s per lane
8 * 985 MB/s = 7880 MB/s
Sollte er demnach können....
Habe gerade mal testweise die Volumes Raid 10 & 5 parallel mit dem AS SSD Benchmark befeuert.
Da komme ich auf 6000 MB/s sequenzielle Leserate über beide Sets.
Aber, je größer die Datei wird, desto langsamer wird es über beide Sets gesehen, da reicht dann der
Dual Core RAID-on-Chip (ROC) 1.2GHz processor wohl nicht mehr aus.
Diese knapp 8 GB/s sind ja auch ein theoretischer Wert. Ich denke mal das Board wird das schaffen aber eventuell nicht die CPU des Controllers und eventuell auch nicht das Hauptsystem.
Das könnte man genauer bestimmen in dem 8 zu 6 Disks vergleicht mit ansonsten exakten Settings. Aber irgendwann will man es vielleicht auch gut sein lassen
Das könnte man genauer bestimmen in dem 8 zu 6 Disks vergleicht mit ansonsten exakten Settings. Aber irgendwann will man es vielleicht auch gut sein lassen
Zitat von @dertowa:
Was möchtest du bitte?
Mir ging es hier eigentlich nur um den "best practise" für einen Neuaufbau des Raidsets.
...dass die spontan genommenen Benchmarkwerte vor Löschung des Raidsets so weit auseinander klaffen war mir vorher nicht klar...
Auf dem System läuft alles, ich kann also nicht sagen "ich optimiere mal für Datenbanken" oder "ich brauche maximale Datenübertragung".
Noch mal, vom Systembuilder war das Teil in der Raid 6 Konfiguration, nach meiner bisherigen Auswertung sehe ich das aber nicht als ideal an.
Zitat von @2423392070:
Sehe da auch keine Richtwerte.
Feature on demand kennst Du?
Sehe da auch keine Richtwerte.
Feature on demand kennst Du?
Was möchtest du bitte?
Mir ging es hier eigentlich nur um den "best practise" für einen Neuaufbau des Raidsets.
...dass die spontan genommenen Benchmarkwerte vor Löschung des Raidsets so weit auseinander klaffen war mir vorher nicht klar...
Auf dem System läuft alles, ich kann also nicht sagen "ich optimiere mal für Datenbanken" oder "ich brauche maximale Datenübertragung".
Noch mal, vom Systembuilder war das Teil in der Raid 6 Konfiguration, nach meiner bisherigen Auswertung sehe ich das aber nicht als ideal an.
Ich habe dir mitgeteilt, dass deine Benchmark oder anders formuliert Richtwerte keine Aussagekraft haben.
Schwurbeln mit sinnfreien Tools und füttern von Tabellen soll was bewirken?
Dein Tool hat fast ausschließlich den Cache bedient und davon gelebt.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Zitat von @ukulele-7:
Das könnte man genauer bestimmen in dem 8 zu 6 Disks vergleicht mit ansonsten exakten Settings. Aber irgendwann will man es vielleicht auch gut sein lassen
Das könnte man genauer bestimmen in dem 8 zu 6 Disks vergleicht mit ansonsten exakten Settings. Aber irgendwann will man es vielleicht auch gut sein lassen
4 haben ja bereits keinen Leistungsverlust, also werden mir 6 auch zu 8 keinen Vorteil verschaffen.
Ich war aber gerade mal verwegen und habe 2x Raid 5 in einem Raid 50 zusammengefasst, überzeugt mich aber auch nicht wirklich (wäre aber ggf. der goldene Mittelweg).
Zitat von @2423392070:
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Was nun bedeutet?
Ich bin immer froh über sinnvolle Aufklärung, ich soll nun also mal die Raidsets mit IOMeter testen?
...aber wie funktioniert das Ding?
Anklicken und Benchmark starten ist nicht (hängt Ewigkeiten bei "Preparing Drives" und nix tut sich).
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Wenn du nicht weißt, was Gehauen und Gestochen ist, dann nutze sowas z.b.: https://app.liveoptics.com/Register/HCI
Oder das Pendant von z. B. HPE oder Lenovo.
Es ist kostenlos.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Wenn du nicht weißt, was Gehauen und Gestochen ist, dann nutze sowas z.b.: https://app.liveoptics.com/Register/HCI
Oder das Pendant von z. B. HPE oder Lenovo.
Es ist kostenlos.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
Zitat von @2423392070:
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
Nicht was den Realbetrieb angeht das ich richtig, wohl aber was die grundsätzliche Performance der Raidsets zueinander hergibt.
Für den detaillierten Einblick fehlt mir die Zeit und das KnowHow um mir genau dieses in Bezug auf den vor mir liegenden Server anzueignen.
Das Teil muss heute noch installiert, konfiguriert werden und in die Infrastruktur eingebunden, damit die Maschinen heute Nacht dorthin wieder übertragen werden können.
Vielleicht spiel ich mir dann mal mit dem Ersatzserver hinsichtlich der Storageperformance.
Gerade gehts aber nur noch darum zu evaluieren auf was ich nun für den produktiven Betrieb sinnvoll setze.
- Single Raid 5
- Raid 10 & 5 in zwei Sets
- Raid 5 & 5 in zwei Sets
- Raid 50
Mir wäre das Risiko zu groß schlauer zu werden oder es gar zu bereuen.
Zitat von @2423392070:
Mir wäre das Risiko zu groß schlauer zu werden oder es gar zu bereuen.
Mir wäre das Risiko zu groß schlauer zu werden oder es gar zu bereuen.
Darum frage ich hier nach Erfahrungswerten und da hilft mir das leider gerade gar nicht.
Final kann es nicht schlimmer werden als mit dem Raid 6 zuvor.
Zitat von @dertowa:
Habe gerade mal testweise die Volumes Raid 10 & 5 parallel mit dem AS SSD Benchmark befeuert.
Da komme ich auf 6000 MB/s sequenzielle Leserate über beide Sets.
Aber, je größer die Datei wird, desto langsamer wird es über beide Sets gesehen, da reicht dann der
Dual Core RAID-on-Chip (ROC) 1.2GHz processor wohl nicht mehr aus.
Habe gerade mal testweise die Volumes Raid 10 & 5 parallel mit dem AS SSD Benchmark befeuert.
Da komme ich auf 6000 MB/s sequenzielle Leserate über beide Sets.
Aber, je größer die Datei wird, desto langsamer wird es über beide Sets gesehen, da reicht dann der
Dual Core RAID-on-Chip (ROC) 1.2GHz processor wohl nicht mehr aus.
du bekommst bei RAID5 und RAID10 annähernd dieselbe Transferrate ... 🤔
Dann liegt die "Limitierung" zu 99,9% nicht an der ASIC der RAID-Controllers, sondern eher an der Bandbreite des für den Cache verwendeten RAM's.
Zitat von @2423392070:
Ich habe dir mitgeteilt, dass deine Benchmark oder anders formuliert Richtwerte keine Aussagekraft haben.
Schwurbeln mit sinnfreien Tools und füttern von Tabellen soll was bewirken?
Ich habe dir mitgeteilt, dass deine Benchmark oder anders formuliert Richtwerte keine Aussagekraft haben.
Schwurbeln mit sinnfreien Tools und füttern von Tabellen soll was bewirken?
Das ist keineswegs nutzloses Schwurbeln, sondern wertvolle Arbeit um die Funktionsweise und auch die Leistungsfähigkeit seines Systems selbst besser zu verstehen.
Dein Tool hat fast ausschließlich den Cache bedient und davon gelebt.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Ähm doch und nicht nur die, sondern auch die SAN's & Co.
Das letzte SAN das unser Haus verlassen hat, hatte 128G Cache per Controller und das obwohl es ein All-Flash ist.🤪Flash ist Flash und RAM ist eben RAM und das letztere davon ist eben immer noch viel schneller. 😉
Zitat von @2423392070:
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
IOMeter kann ich ebenfalls nur empfehlen, aber das Ding muss man auch bedienen und die Werte richtig interpretieren können.
Was das Multithreading angeht, ja bei vielen Benutzern ist eine hohe Multithread-Performance auch wichtig, aber was den einzelnen Benutzer angeht, so ist für diesen die Singlethread-Performance dennoch meist viel wichtiger.
Moin dertowa,
die obere Erklärung ins nur halbwegs korrekt.
Read Ahead bring keineswegs nur bei HDD's eine Vorteil sondern auch bei SSD's, aber eben nur für einen bestimmten Workload-Typ, nämlich sequentielle Lesezugriffe.
Und das war es dann auch schon, bei allen anderen Workloads und insbesondere bei Random-Access, bringt dieses Feature jedoch nur Nachteile, das es ständig den Cache mit nicht benötigten Daten vorbefüllt. Dadurch wird der Cache selbst mehr als nötig Belastet und auch die Datenträger müssen viel mehr Daten auslesen, als eigentlich vom darüberliegenden System angefragt wird.
Für die meisten Anwendungsfälle und insbesondere bei Datenbanken ist dieses Feature einfach nur Gift.
Beste Grüsse aus BaWü
Alex
Read ahead – reading data blocks that reside behind the currently requested data – is also a performance optimization that only offers genuine benefits for hard disks. In RAID 5 with four SSDs, activating read ahead slowed down the read IOPS these tests by 20 percent (from 175,000 to 140,000 read IOPS). In terms of throughput, you'll see no performance differences for reading with 64KB or 1,024KB blocks. Read ahead only offered benefits in our lab in throughput with 8KB blocks. Additionally, read ahead can only offer benefits in single-threaded read tests (e.g., with dd on Linux). However, both access patterns are atypical in server operations. My recommendation is therefore to run SSD RAIDs without read ahead.
Quelle: https://www.admin-magazine.com/Archive/2015/28/Tuning-SSD-RAID-for-optim ...
Quelle: https://www.admin-magazine.com/Archive/2015/28/Tuning-SSD-RAID-for-optim ...
die obere Erklärung ins nur halbwegs korrekt.
Read Ahead bring keineswegs nur bei HDD's eine Vorteil sondern auch bei SSD's, aber eben nur für einen bestimmten Workload-Typ, nämlich sequentielle Lesezugriffe.
Und das war es dann auch schon, bei allen anderen Workloads und insbesondere bei Random-Access, bringt dieses Feature jedoch nur Nachteile, das es ständig den Cache mit nicht benötigten Daten vorbefüllt. Dadurch wird der Cache selbst mehr als nötig Belastet und auch die Datenträger müssen viel mehr Daten auslesen, als eigentlich vom darüberliegenden System angefragt wird.
Für die meisten Anwendungsfälle und insbesondere bei Datenbanken ist dieses Feature einfach nur Gift.
Beste Grüsse aus BaWü
Alex
Salut zusammen,
ich habe mich gestern für die Aufteilung auf Raid 10 für die Datenbanksysteme und Raid 5 für die übrigen Server entschieden, manchmal muss man einfach seinen Kopf durchsetzen und nachdem ich das mehrfach überlegt hatte und mehr als 4 Platten faktisch nicht mehr Performance gaben, sowie die Verkettung von 8 Platten (bspw. Raid 50) eher nachteilig wirkte war das mein Stand.
Areca hatte mir auch noch mitgeteilt:
controller do have limitation on performance, you can not get higher performance by increasing drive amounts as soon as you reach the bottleneck of the controller.
Ich verspreche mir also von einer Kanalaufteilung und einer "Lastaufteilung" mehr als von einem stumpfen großen Raidset.
Der Controller entspringt eben auch nicht der aktuellsten Generation und man empfiehlt für die maximale Performance mit den SSDs einen aus der neuen ARC-1886er Serie, da gibts dann auch DDR4 und NVMe Support.
Erstmal egal, das System läuft seit gestern Nachmittag wieder und ich bin ja unmittelbar dabei um die Performance langfristig zu beobachten.
Im Zweifel muss ich in 1 oder 2 Jahren noch mal ran und das Raidset noch mal überdenken, ich werde mich hoffentlich an diesen Thread zurückerinnern.
@MysticFoxDE
Bzgl. Read Ahead, da bezieht sich der areca Controller auch schon nur auf HDDs, bei SSDs scheint das Feature also seitens areca schon nicht gegeben:
Danke an alle Beteiligten.
ich habe mich gestern für die Aufteilung auf Raid 10 für die Datenbanksysteme und Raid 5 für die übrigen Server entschieden, manchmal muss man einfach seinen Kopf durchsetzen und nachdem ich das mehrfach überlegt hatte und mehr als 4 Platten faktisch nicht mehr Performance gaben, sowie die Verkettung von 8 Platten (bspw. Raid 50) eher nachteilig wirkte war das mein Stand.
Areca hatte mir auch noch mitgeteilt:
controller do have limitation on performance, you can not get higher performance by increasing drive amounts as soon as you reach the bottleneck of the controller.
Ich verspreche mir also von einer Kanalaufteilung und einer "Lastaufteilung" mehr als von einem stumpfen großen Raidset.
Der Controller entspringt eben auch nicht der aktuellsten Generation und man empfiehlt für die maximale Performance mit den SSDs einen aus der neuen ARC-1886er Serie, da gibts dann auch DDR4 und NVMe Support.
Erstmal egal, das System läuft seit gestern Nachmittag wieder und ich bin ja unmittelbar dabei um die Performance langfristig zu beobachten.
Im Zweifel muss ich in 1 oder 2 Jahren noch mal ran und das Raidset noch mal überdenken, ich werde mich hoffentlich an diesen Thread zurückerinnern.
@MysticFoxDE
Bzgl. Read Ahead, da bezieht sich der areca Controller auch schon nur auf HDDs, bei SSDs scheint das Feature also seitens areca schon nicht gegeben:
Danke an alle Beteiligten.
Zitat von @MysticFoxDE:
IOMeter kann ich ebenfalls nur empfehlen, aber das Ding muss man auch bedienen und die Werte richtig interpretieren können.
Was das Multithreading angeht, ja bei vielen Benutzern ist eine hohe Multithread-Performance auch wichtig, aber was den einzelnen Benutzer angeht, so ist für diesen die Singlethread-Performance dennoch meist viel wichtiger.
Zitat von @2423392070:
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
Das bedeutet, dass du keine Erkenntnisse hast die belastbar sind.
IOMeter sollte mindestens 16 Threads, eher 32 oder 64 machen, die dem Reallife-Verhalten entsprechen.
Nach der Erkenntnis kannst du IOMeter dann so einstellen, dass es das Reallife mit Druck dem Storage abverlangt und dann kannst du das Optimum suchen, finden und bewerten.
IOMeter kann ich ebenfalls nur empfehlen, aber das Ding muss man auch bedienen und die Werte richtig interpretieren können.
Was das Multithreading angeht, ja bei vielen Benutzern ist eine hohe Multithread-Performance auch wichtig, aber was den einzelnen Benutzer angeht, so ist für diesen die Singlethread-Performance dennoch meist viel wichtiger.
Es sollen Threads sein, die die Warteschlangen des Storage in Arbeit darstellen. Bei ESXI oder Hyper-Pfau auch Queue genannt.
Ein SAS Laufwerk kann 256 und der Treiber arbeitet auch damit.
Es ist sinnbefreit ein Tool laufen zu lassen, dass das RAID nicht auf diesen Umstand untersucht.
Zitat von @MysticFoxDE:
Das ist keineswegs nutzloses Schwurbeln, sondern wertvolle Arbeit um die Funktionsweise und auch die Leistungsfähigkeit seines Systems selbst besser zu verstehen.
Ähm doch und nicht nur die, sondern auch die SAN's & Co.
Das letzte SAN das unser Haus verlassen hat, hatte 128G Cache per Controller und das obwohl es ein All-Flash ist.🤪Flash ist Flash und RAM ist eben RAM und das letztere davon ist eben immer noch viel schneller. 😉
Zitat von @2423392070:
Ich habe dir mitgeteilt, dass deine Benchmark oder anders formuliert Richtwerte keine Aussagekraft haben.
Schwurbeln mit sinnfreien Tools und füttern von Tabellen soll was bewirken?
Ich habe dir mitgeteilt, dass deine Benchmark oder anders formuliert Richtwerte keine Aussagekraft haben.
Schwurbeln mit sinnfreien Tools und füttern von Tabellen soll was bewirken?
Das ist keineswegs nutzloses Schwurbeln, sondern wertvolle Arbeit um die Funktionsweise und auch die Leistungsfähigkeit seines Systems selbst besser zu verstehen.
Dein Tool hat fast ausschließlich den Cache bedient und davon gelebt.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Übrigens arbeitet kein Server so, außer ein solches Tool läuft.
Ähm doch und nicht nur die, sondern auch die SAN's & Co.
Das letzte SAN das unser Haus verlassen hat, hatte 128G Cache per Controller und das obwohl es ein All-Flash ist.🤪Flash ist Flash und RAM ist eben RAM und das letztere davon ist eben immer noch viel schneller. 😉
Das kann man nicht vergleichen.
Die Hosts die die LUNs halten sehen nicht, egal was in den Treiber eingestellt ist, dass die LUNs im Storage hinter dicken Cache liegen. Etwas anders ist das bei NVME over Fabric LUNs, da sind die LUNs mit der CPU direkt verbunden.
Windows weiß von dem Cache des Controllers und der Laufwerke und verhält sich entsprechend des Treibers. Daher ist die "Tiefe der Warteschlange" hin und wieder zu überprüfen und zu optimieren.
Moin unbelanglos,
die Materie mit den Queues ist mir durchaus bekannt.
In der heutigen Zeit und vor allem Dank des blöden RAM-Block-Cache des OS (vor allem bei Microsoft), landet ein Grossteil der IO's leider in diesem Cache und wird dort schlichtweg sequentialisiert. 🤢
Und beim Hyper-Pfau pfuscht eventuell auch noch der CSV-Cache (reiner Lesecache) dazwischen. 🤮
Diese Aussage ist so leider nicht korrekt.
Genau so wie die direkt angebundenen HDD's oder SSD's sollten auch die LUN's eines SAN's dem angebundenen Host sehr wohl mitteilen ob diese gecacht sind oder nicht.
Und auch hier pfuscht dir der angesprochene OS RAM-Block-Cache (bei Windows ist das Modified- & Standby Memory) leider dazwischen.
Ja, das war gestern.
Heute versucht Windows so gut wie alles über den Host-RAM zu schieben um ja nicht zu viele IO's auf dem Storage selbst zu erzeugen. Könnte ja gut sein, dass darunter ein S2D liegt und dieses mag zu viele (direct) IO's überhaupt nicht. 😉
Beste Grüsse aus BaWü
Alex
P.S. Der Hyper-Pfau gibt übrigens sämtlichen Write-IO der VM's als "write through" an die LUN's weiter und umgeht
damit meistens den Write-Cache der SAN's. 🤮🤮🤮
Es sollen Threads sein, die die Warteschlangen des Storage in Arbeit darstellen. Bei ESXI oder Hyper-Pfau auch Queue genannt.
Ein SAS Laufwerk kann 256 und der Treiber arbeitet auch damit.
Ein SAS Laufwerk kann 256 und der Treiber arbeitet auch damit.
die Materie mit den Queues ist mir durchaus bekannt.
In der heutigen Zeit und vor allem Dank des blöden RAM-Block-Cache des OS (vor allem bei Microsoft), landet ein Grossteil der IO's leider in diesem Cache und wird dort schlichtweg sequentialisiert. 🤢
Und beim Hyper-Pfau pfuscht eventuell auch noch der CSV-Cache (reiner Lesecache) dazwischen. 🤮
Die Hosts die die LUNs halten sehen nicht, egal was in den Treiber eingestellt ist, dass die LUNs im Storage hinter dicken Cache liegen.
Diese Aussage ist so leider nicht korrekt.
Genau so wie die direkt angebundenen HDD's oder SSD's sollten auch die LUN's eines SAN's dem angebundenen Host sehr wohl mitteilen ob diese gecacht sind oder nicht.
Etwas anders ist das bei NVME over Fabric LUNs, da sind die LUNs mit der CPU direkt verbunden.
Und auch hier pfuscht dir der angesprochene OS RAM-Block-Cache (bei Windows ist das Modified- & Standby Memory) leider dazwischen.
Windows weiß von dem Cache des Controllers und der Laufwerke und verhält sich entsprechend des Treibers. Daher ist die "Tiefe der Warteschlange" hin und wieder zu überprüfen und zu optimieren.
Ja, das war gestern.
Heute versucht Windows so gut wie alles über den Host-RAM zu schieben um ja nicht zu viele IO's auf dem Storage selbst zu erzeugen. Könnte ja gut sein, dass darunter ein S2D liegt und dieses mag zu viele (direct) IO's überhaupt nicht. 😉
Beste Grüsse aus BaWü
Alex
P.S. Der Hyper-Pfau gibt übrigens sämtlichen Write-IO der VM's als "write through" an die LUN's weiter und umgeht
damit meistens den Write-Cache der SAN's. 🤮🤮🤮
