Neopolis 19 Geschrieben 12. August 2020 Melden Teilen Geschrieben 12. August 2020 Ne ich würde in jedem Fall mindestens 2 nehmen. schon wegen der Ausfallsicherheit. und die an den SQL Server als weiteres Laufwerk anbinden. Dann das Datenbankverzeichnis dorthin schieben und im SQL anpassen. Wenn das so problemlos möglich ist und keine großen Abhängigkeiten bestehen. Dann hast Du schon mal Lese/ Schreibzugriffe der Datenbank von deinen HDDs runter Wenn das schon besser ist hast Du etwas gewonnen. Zitieren Link zu diesem Kommentar
bigthe 3 Geschrieben 12. August 2020 Autor Melden Teilen Geschrieben 12. August 2020 (bearbeitet) vor 30 Minuten schrieb Neopolis: Ne ich würde in jedem Fall mindestens 2 nehmen. schon wegen der Ausfallsicherheit. und die an den SQL Server als weiteres Laufwerk anbinden. Dann das Datenbankverzeichnis dorthin schieben und im SQL anpassen. Wenn das so problemlos möglich ist und keine großen Abhängigkeiten bestehen. Dann hast Du schon mal Lese/ Schreibzugriffe der Datenbank von deinen HDDs runter Wenn das schon besser ist hast Du etwas gewonnen. Ok so ginge es auch. Ich denke nicht das es nur an der SQL VM liegt, wie gesagt ich hatte alle VMs bis auf den DC heruntergefahren und es lief auch langsam. Ich denke es ist ein generelles Problem. Oder liege ich falsch und die VMs auch wenn sie heruntergefahren sind erzeugen Last? Zum Test werde ich das nach meinem Urlaub mal so angehen wie von euch beschrieben, danke. bearbeitet 12. August 2020 von bigthe Zitieren Link zu diesem Kommentar
mwiederkehr 351 Geschrieben 13. August 2020 Melden Teilen Geschrieben 13. August 2020 Bei kleinen Servern mit ein paar VMs muss es nach meinen Erfahrungen kein HW-RAID sein, jedenfalls nicht für die Performance. Die Parität für RAID 5 oder 6 rechnet eine moderne CPU nebenher, ohne gross ins Schwitzen zu kommen, zumindest bei den im Betrieb gefragten Bandbreiten. (Die günstigen NAS sind auch alles SW-RAIDs und dazu noch mit schwächerer CPU als normale Server.) Gefragt ist nicht ein möglichst hoher Durchsatz, sondern viele IOPS. Da helfen nur SSDs. Habe kürzlich einen HPE ProLiant ML30 mit zwei SATA-Disks am SW-RAID-Controller angetroffen und der war richtig träge: Server Manager starten dauerte fast eine Minute, die drei Benutzer auf der Terminalserver-VM konnten nach einem Neustart mehrere Minuten kaum arbeiten etc. Lösung: Disks durch SSDs ersetzt, wieder als SW-RAID. Seither ist alles schnell ohne Hänger. Grosse SSDs sind mittlerweile so günstig, dass sie auch für Datenmengen von mehreren Terabytes nicht mehr unbezahlbar sind. Ansonsten macht man zwei RAIDs: eines mit SSDs für alle System- und Datenbank-VHDX und eines mit Disks für die Daten. Zitieren Link zu diesem Kommentar
bigthe 3 Geschrieben 13. August 2020 Autor Melden Teilen Geschrieben 13. August 2020 Hallo, kurzes Update: Habe die Energieeinstellungen auf dem Server Core und den VMs auf Höchstleistung außerdem habe ich den Cache über den Geräte-Manager aktiviert auf den Laufwerken. Es läuft nun deutlich schneller das belegen auch die Zugriffszeiten: Command Line: diskspd.exe -c16G -d300 -r -w30 -b8k -t4 -o8 -h -L c:\Test.dat Input parameters: timespan: 1 ------------- duration: 300s warm up time: 5s cool down time: 0s measuring latency random seed: 0 path: 'c:\Test.dat' think time: 0ms burst size: 0 software cache disabled hardware write cache disabled, writethrough on performing mix test (read/write ratio: 70/30) block size: 8192 using random I/O (alignment: 8192) number of outstanding I/O operations: 8 thread stride size: 0 threads per file: 4 using I/O Completion Ports IO priority: normal System information: computer name: NephroVM start time: 2020/08/13 13:48:24 UTC Results for timespan 1: ******************************************************************************* actual test time: 300.00s thread count: 4 proc count: 12 CPU | Usage | User | Kernel | Idle ------------------------------------------- 0| 1.09%| 0.34%| 0.74%| 98.91% 1| 1.55%| 0.56%| 0.99%| 98.45% 2| 1.03%| 0.34%| 0.69%| 98.97% 3| 1.25%| 0.25%| 1.00%| 98.75% 4| 3.25%| 1.98%| 1.27%| 96.75% 5| 3.86%| 2.45%| 1.41%| 96.14% 6| 2.42%| 0.52%| 1.90%| 97.58% 7| 1.67%| 0.33%| 1.34%| 98.33% 8| 1.21%| 0.40%| 0.81%| 98.79% 9| 2.80%| 1.36%| 1.43%| 97.20% 10| 0.73%| 0.17%| 0.56%| 99.27% 11| 0.39%| 0.15%| 0.24%| 99.61% ------------------------------------------- avg.| 1.77%| 0.74%| 1.03%| 98.23% Total IO thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file ----------------------------------------------------------------------------------------------------- 0 | 309174272 | 37741 | 0.98 | 125.80 | 63.790 | 127.440 | c:\Test.dat (16GiB) 1 | 311304192 | 38001 | 0.99 | 126.67 | 63.347 | 127.734 | c:\Test.dat (16GiB) 2 | 306118656 | 37368 | 0.97 | 124.56 | 64.393 | 129.501 | c:\Test.dat (16GiB) 3 | 310222848 | 37869 | 0.99 | 126.23 | 63.497 | 127.835 | c:\Test.dat (16GiB) ----------------------------------------------------------------------------------------------------- total: 1236819968 | 150979 | 3.93 | 503.26 | 63.754 | 128.126 Read IO thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file ----------------------------------------------------------------------------------------------------- 0 | 217112576 | 26503 | 0.69 | 88.34 | 74.193 | 100.603 | c:\Test.dat (16GiB) 1 | 217530368 | 26554 | 0.69 | 88.51 | 73.696 | 100.802 | c:\Test.dat (16GiB) 2 | 214081536 | 26133 | 0.68 | 87.11 | 74.422 | 100.268 | c:\Test.dat (16GiB) 3 | 216924160 | 26480 | 0.69 | 88.27 | 74.215 | 101.807 | c:\Test.dat (16GiB) ----------------------------------------------------------------------------------------------------- total: 865648640 | 105670 | 2.75 | 352.23 | 74.131 | 100.874 Write IO thread | bytes | I/Os | MiB/s | I/O per s | AvgLat | LatStdDev | file ----------------------------------------------------------------------------------------------------- 0 | 92061696 | 11238 | 0.29 | 37.46 | 39.254 | 172.676 | c:\Test.dat (16GiB) 1 | 93773824 | 11447 | 0.30 | 38.16 | 39.338 | 172.536 | c:\Test.dat (16GiB) 2 | 92037120 | 11235 | 0.29 | 37.45 | 41.065 | 177.810 | c:\Test.dat (16GiB) 3 | 93298688 | 11389 | 0.30 | 37.96 | 38.578 | 171.319 | c:\Test.dat (16GiB) ----------------------------------------------------------------------------------------------------- total: 371171328 | 45309 | 1.18 | 151.03 | 39.554 | 173.593 total: %-ile | Read (ms) | Write (ms) | Total (ms) ---------------------------------------------- min | 0.033 | 0.343 | 0.033 25th | 18.142 | 0.853 | 6.548 50th | 43.835 | 1.564 | 26.916 75th | 93.286 | 9.851 | 76.996 90th | 161.198 | 72.576 | 144.209 95th | 229.157 | 129.854 | 214.781 99th | 510.556 | 1003.437 | 602.468 3-nines | 1070.169 | 2064.597 | 1592.495 4-nines | 1411.675 | 2583.996 | 2520.209 5-nines | 1810.665 | 2825.525 | 2620.693 6-nines | 1990.036 | 2825.525 | 2825.525 7-nines | 1990.036 | 2825.525 | 2825.525 8-nines | 1990.036 | 2825.525 | 2825.525 9-nines | 1990.036 | 2825.525 | 2825.525 max | 1990.036 | 2825.525 | 2825.525 Ich werde trotzdem SSDs dort einbauen, so wie ihr mir das geraten habt. Ich danke euch vielmals für eure Tipps und Erfahrungen! Viele Grüße Zitieren Link zu diesem Kommentar
Dominik Weber 19 Geschrieben 13. August 2020 Melden Teilen Geschrieben 13. August 2020 Schreibcache auf dem Laufwerken ist aber seeehr gefährlich Zitieren Link zu diesem Kommentar
Dukel 436 Geschrieben 13. August 2020 Melden Teilen Geschrieben 13. August 2020 Außer man hat eine USV an dem Server. Zitieren Link zu diesem Kommentar
Gu4rdi4n 53 Geschrieben 13. August 2020 Melden Teilen Geschrieben 13. August 2020 vor 4 Minuten schrieb Dukel: Außer man hat eine USV an dem Server. Auch nicht unbedingt. Wenn dir das Netzteil Abraucht bringt dir die USV auch nix ;) Außer man hat natürlich noch ein redundantes Netzteil :p Zitieren Link zu diesem Kommentar
bigthe 3 Geschrieben 13. August 2020 Autor Melden Teilen Geschrieben 13. August 2020 (bearbeitet) Yuhu, hab beides! Die zwei Wochen wird er aushalten dann gibts sowieso SSDs bearbeitet 13. August 2020 von bigthe 2 Zitieren Link zu diesem Kommentar
Nobbyaushb 1.358 Geschrieben 13. August 2020 Melden Teilen Geschrieben 13. August 2020 vor 41 Minuten schrieb bigthe: Yuhu, hab beides! Die zwei Wochen wird er aushalten dann gibts sowieso SSDs Sehr gut! Und hoffentlich die SSD min im Raid-1 und vom Hersteller zugelassen, an einem Controller der den Speed auch kann. S-ATA macht eben max 6Gbit.... Zitieren Link zu diesem Kommentar
bigthe 3 Geschrieben 15. September 2020 Autor Melden Teilen Geschrieben 15. September 2020 (bearbeitet) Hallo, nur zur Info, der Wechsel der VM wo die SQL Datenbank lief auf SSDs ist erfolgt und brachte Erfolg! Ausserdem durfte ich eine Server für eine Kunden konfektionieren und habe mich durchgesetzt! Sowohl das Host als auch das VM System laufen komplett auf SSDs zwar mit einem SW-Raid aber immerhin. Die Kunden sind zufrieden! Mein Chef will nicht auf SSDs seiner Meinung nach sind die anfällig und haben kurze Lebensdauer. Auch diverse Artikel aus Fachzeitschriften und gute Argumente können ihn nicht überzeugen. Ich würde gern noch einen Schritt weiter gehen und sogar eine 250 GB Samsung SSD 860 EVO (M.2 SATA III 2280) verbauen für den Host (die soll deutlich längere Lebensdauer haben). Wie ist eure Meinung dazu? MfG bearbeitet 15. September 2020 von bigthe 1 Zitieren Link zu diesem Kommentar
Gu4rdi4n 53 Geschrieben 15. September 2020 Melden Teilen Geschrieben 15. September 2020 (bearbeitet) Netter Artikel zur Haltbarkeit von SSDs https://www.ontrack.com/de-de/blog/how-long-do-ssds-really-last#:~:text=Eine typische TBW-Zahl für,Zeitraum von einem Jahr schreiben. abseits davon: Wer kein Raid + Backup verwendet, braucht sich nicht wundern, wenn Daten Flöten gehen. Befolge das, dann kann man mit reinem Gewissen eine SSD verwenden. btw: auf gh.de kannst du die TBW Zahl einschränken. Da siehst du für wie viel TBW die SSDs ausgelegt sind bearbeitet 15. September 2020 von Gu4rdi4n Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 15. September 2020 Melden Teilen Geschrieben 15. September 2020 (bearbeitet) vor 49 Minuten schrieb bigthe: Die Kunden sind zufrieden! Du hast ein SW-Raid? Wie denn? Der ist ist dann nicht mehr zufrieden, wenn der Datenverlust hat. Wie bemerkst Du bei einem SW-Raid den Ausfall einer SSD? Hat Du das getestet? Kennst Du den Rebuild-Prozess? Welche Ausfallzeiten hat der Kunde? Ach ja: die EVO-SSDs sind für Desktop-PC und nicht für Server. Kurzes Beispiel: Unsere Netapp wirft aktuell mit defekten HDDs um sich. Störungen hatten wir deshalb keine. bearbeitet 15. September 2020 von zahni Zitieren Link zu diesem Kommentar
bigthe 3 Geschrieben 15. September 2020 Autor Melden Teilen Geschrieben 15. September 2020 Also ich habe ein SW-Raid Controller on Board C622 und das zeigt mir auch fehlerhafte Platten an. Backup usw ist natürlich mehrfach vorhanden. Thomas-Krenn bietet derzeit diese 250 GB Samsung SSD 860 EVO (M.2 SATA III 2280) für Server an... Zitieren Link zu diesem Kommentar
Dukel 436 Geschrieben 15. September 2020 Melden Teilen Geschrieben 15. September 2020 17 minutes ago, bigthe said: Thomas-Krenn bietet derzeit diese 250 GB Samsung SSD 860 EVO (M.2 SATA III 2280) für Server an... Das heisst aber nicht, dass man diese nutzt. Server SSD's haben höhere TBW und Garantien. Zitieren Link zu diesem Kommentar
zahni 521 Geschrieben 15. September 2020 Melden Teilen Geschrieben 15. September 2020 vor 39 Minuten schrieb bigthe: Also ich habe ein SW-Raid Controller on Board C622 und das zeigt mir auch fehlerhafte Platten an Die Frage ist: Meldet sich "der Raid-Controller" auch bei Dir oder beim Kunden per Mail? Wer bekommt mit, dass die SSD ausgefallen ist? Moderne Server-SSDs haben haben internes Monitoring, dass die voraussichtliche Lebensdauer anzeigt. Deckt das der Controller auch ab? Kann Dein Kunde die im Rahmen seines Service Vertrags ersetzt bekommen? Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.