SSD RAID - Controller mit Cache oder ohne?
Moin,
ich hole gerade Angebote für einen neuen Datenbank-Server (MS SQL) ein. Der Plan: OS läuft auf RAID 1, die DBs sollen auf RAID 10 laufen. Jetzt stellt sich die Frage, ob der verwendete RAID-Controller eigenen Cache benötigt oder nicht. Aussage des Serverlieferanten: Das ist unnötig, weil die SSDs schnell genug sind (SATA 6G) und der Controllercache das System eher ausbremsen würde.
Hier lese ich nun aber dies:
https://community.spiceworks.com/topic/2204748-does-a-server-with-ssd-dr ...
Was meint Ihr? Cache nötig oder unnötig?
Gruß
ich hole gerade Angebote für einen neuen Datenbank-Server (MS SQL) ein. Der Plan: OS läuft auf RAID 1, die DBs sollen auf RAID 10 laufen. Jetzt stellt sich die Frage, ob der verwendete RAID-Controller eigenen Cache benötigt oder nicht. Aussage des Serverlieferanten: Das ist unnötig, weil die SSDs schnell genug sind (SATA 6G) und der Controllercache das System eher ausbremsen würde.
Hier lese ich nun aber dies:
https://community.spiceworks.com/topic/2204748-does-a-server-with-ssd-dr ...
Was meint Ihr? Cache nötig oder unnötig?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3257181758
Url: https://administrator.de/contentid/3257181758
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
24 Kommentare
Neuester Kommentar
Ich würde immer mit nehmen. Die Konfig ist entsprechend anzupassen.
Moin,
Hardwareschrauber hat unrecht und der Kollege auf spicework hat recht imho.
Nötig? Hängt von Deinen Ansprüchen ab. Da läuft eine DB drauf ist nicht hinreichend, um zu beurteilen, ob es nötig ist oder nicht. Nice to have? Auf jeden Fall. Bremst das System aus? Auf keinen Fall.
hth
Erik
Zitat von @Coreknabe:
Aussage des Serverlieferanten: Das ist unnötig, weil die SSDs schnell genug sind (SATA 6G) und der Controllercache das System eher ausbremsen würde.
Hier lese ich nun aber dies:
https://community.spiceworks.com/topic/2204748-does-a-server-with-ssd-dr ...
Aussage des Serverlieferanten: Das ist unnötig, weil die SSDs schnell genug sind (SATA 6G) und der Controllercache das System eher ausbremsen würde.
Hier lese ich nun aber dies:
https://community.spiceworks.com/topic/2204748-does-a-server-with-ssd-dr ...
Hardwareschrauber hat unrecht und der Kollege auf spicework hat recht imho.
Was meint Ihr? Cache nötig oder unnötig?
Nötig? Hängt von Deinen Ansprüchen ab. Da läuft eine DB drauf ist nicht hinreichend, um zu beurteilen, ob es nötig ist oder nicht. Nice to have? Auf jeden Fall. Bremst das System aus? Auf keinen Fall.
hth
Erik
Zitat von @Coreknabe:
@2423392070
Warum und wie?
@2423392070
Ich würde immer mit nehmen. Die Konfig ist entsprechend anzupassen.
Warum und wie?
Weil es Performance bringt und hält.
Der Controller hat ein BIOS, Treiber und Software zum optimieren.
Hallo,
bei 4x SATA würde ich einen Controller mit Cache und BBU empfehlen.
Lesen = ca. 2.160 MB/Sek
Schreiben = ca. 1.080 MB/Sek
Oder aber
1x m2 NVME SSD Enterprise 2TB ohne RAID.
Die Fujitsu Server haben seit einiger Zeit alle 2 M2 Slots on Board (1x SATA und 1x NVME). Oder als PCIe-Karte.
Lesen + Schreiben = ca. 6.000 MB/Sek
Kommt auf Anforderung an.
Ich bin der Meinung, dass das Ausfallrisiko des Controllers gleich hoch ist wie das einer SSD.
Muss aber jeder selber entscheiden.
bei 4x SATA würde ich einen Controller mit Cache und BBU empfehlen.
Lesen = ca. 2.160 MB/Sek
Schreiben = ca. 1.080 MB/Sek
Oder aber
1x m2 NVME SSD Enterprise 2TB ohne RAID.
Die Fujitsu Server haben seit einiger Zeit alle 2 M2 Slots on Board (1x SATA und 1x NVME). Oder als PCIe-Karte.
Lesen + Schreiben = ca. 6.000 MB/Sek
Kommt auf Anforderung an.
Ich bin der Meinung, dass das Ausfallrisiko des Controllers gleich hoch ist wie das einer SSD.
Muss aber jeder selber entscheiden.
Zitat von @StefanKittel:
Ich bin der Meinung, dass das Ausfallrisiko des Controllers gleich hoch ist wie das einer SSD.
Ich bin der Meinung, dass das Ausfallrisiko des Controllers gleich hoch ist wie das einer SSD.
Natürlich, es zählt grundsätzlich immer das schwächste Glied der Kette.
Beim Raidcontroller hätte man aber auch weitere Vorteile u.a. kann ein Ersatzcontroller unproblematisch eingesteckt werden und die Raidsets weiterbetreiben, wohingegen bei einer Einzelplatte das Backup bemüht werden muss.
Cache hin oder her, ich habe heute bei unserem Hyper-V Host mal Performancetests gemacht:
Optimierung Raidsystem Hyper-V Host
Cache ist aktiv.
Hallo Coreknabe,
ich tausche bei meinen Kunden eh die Server inkl. Controller und SSDs nach 5 Jahren wenn der Vor-Ort-Service ausläuft.
Innerhalb dieser 5 Jahren hatte ich mit Enterprise SAS HDDs immer so 2-3 Ausfälle bei 15 Servern. Mit den Enterprise SSDs bisher 0,0.
Ich habe hier aber noch einen Bastelserver mit Samsung 850er Pro aus 2014 ohne RAID-Controller.
Die Dinger laufen immer noch Prima ohne Macken...
Stefan
ich tausche bei meinen Kunden eh die Server inkl. Controller und SSDs nach 5 Jahren wenn der Vor-Ort-Service ausläuft.
Innerhalb dieser 5 Jahren hatte ich mit Enterprise SAS HDDs immer so 2-3 Ausfälle bei 15 Servern. Mit den Enterprise SSDs bisher 0,0.
Ich habe hier aber noch einen Bastelserver mit Samsung 850er Pro aus 2014 ohne RAID-Controller.
Die Dinger laufen immer noch Prima ohne Macken...
Stefan
Zitat von @Roland567:
Cache ist sicherlich nach wie vor schneller, da ja die 1. Anlaufstelle für die Controller.
Dann zeig mir mal den Controller der 144 GByte/Sekunde liefern kann ohne dabei zu schmelzen...Cache ist sicherlich nach wie vor schneller, da ja die 1. Anlaufstelle für die Controller.
46GB/s kann dieser mal zumindest
Microchip SmartRAID Controllers for HPE Gen10 Plus
HPE SR932i-p x32 Lanes 8GB Wide Cache NVMe/SAS 24G PCIe4 x16 Gen10 Plus Controller
Einzelne NVMe's nutzen dir auch reichlich wenige in einem Windows.
Willst ja keine 24 Laufwerke, sondern irgendwo ein Raid.
Aber ist auch weit weg von den ursprünglichen Anforderungen und Fragestellung.
Aber ich habe gerade noch eine ganz entscheiden Fehler Coreknabbe gesehen.
DU darfst/solltest NEVER EVER SATA bei einer Datenbank verwenden.
Das Minimum wäre UNBEDINGT SAS.
Weil
SAS hat höhere IOPS (Inputs Outputs pro Sekunde) gegenüber SATA, was bedeutet, dass damit die Möglichkeit besteht, Daten schneller zu lesen und zu schreiben. Das hat SAS zu einer optimalen Wahl für Systeme gemacht, die hohe Leistung und Verfügbarkeit erfordern.
Roland
Microchip SmartRAID Controllers for HPE Gen10 Plus
HPE SR932i-p x32 Lanes 8GB Wide Cache NVMe/SAS 24G PCIe4 x16 Gen10 Plus Controller
Einzelne NVMe's nutzen dir auch reichlich wenige in einem Windows.
Willst ja keine 24 Laufwerke, sondern irgendwo ein Raid.
Aber ist auch weit weg von den ursprünglichen Anforderungen und Fragestellung.
Aber ich habe gerade noch eine ganz entscheiden Fehler Coreknabbe gesehen.
DU darfst/solltest NEVER EVER SATA bei einer Datenbank verwenden.
Das Minimum wäre UNBEDINGT SAS.
Weil
SAS hat höhere IOPS (Inputs Outputs pro Sekunde) gegenüber SATA, was bedeutet, dass damit die Möglichkeit besteht, Daten schneller zu lesen und zu schreiben. Das hat SAS zu einer optimalen Wahl für Systeme gemacht, die hohe Leistung und Verfügbarkeit erfordern.
Roland
Zitat von @Roland567:
DU darfst/solltest NEVER EVER SATA bei einer Datenbank verwenden.
Das Minimum wäre UNBEDINGT SAS.
Ich würde eine Enterprise SATA SSD deutlich einer Enterprise 15k SAS HDD vorziehen.DU darfst/solltest NEVER EVER SATA bei einer Datenbank verwenden.
Das Minimum wäre UNBEDINGT SAS.
Hallo,
StefanKittel, ja das mag noch so passen, aber qie reden ja "nur" von SSD und bei SSD im Business ist SAS einfach Pflicht und erst Recht bei einer Datenbank.
Coreknabbe
Dein Ausführungen kann ich nicht nicht ganz nachvollziehen.
Für's booten soll es NVMe sein, aber für das SQL reicht dann auf einmal SATA locker aus ?!?!?!?
Sorry dafür habe ich dann aber doch wenig Verständnis und frage mich, wo die Prio liegt.
SATA ist einfach nicht ausgelegt, wenn gleichzeitig viel gelesen und geschrieben wird, was bei einer Datenbank nun mal zwangsläuft häufig auftritt. AUSSER du hast nur eine DB, bei der primär NUR gelesen wird; da sieht die Sache sicherlich anders aus.
Also das Geld von NVMe, könnte man dann auch in SAS stecken und damit Booten UND die SQL Daten vernünftig bedienen. (die 5 Sekunden, die das booten dann langsamer ist, holst du in der DB wieder rein)
Und wenn du wirklich auf SATA baust, erübrigt sich die ursprüngliche Frage für den Cache erst recht.
Da hier das SATA zum Flaschenhals wird, kommst du um den Cache eigentlich nicht drumrum.
Alles andere kann man nicht mit gutem Gewissen "verkaufen".
Naja, viel "Spass" damit.
Gruss Roland
StefanKittel, ja das mag noch so passen, aber qie reden ja "nur" von SSD und bei SSD im Business ist SAS einfach Pflicht und erst Recht bei einer Datenbank.
Coreknabbe
Dein Ausführungen kann ich nicht nicht ganz nachvollziehen.
Für's booten soll es NVMe sein, aber für das SQL reicht dann auf einmal SATA locker aus ?!?!?!?
Sorry dafür habe ich dann aber doch wenig Verständnis und frage mich, wo die Prio liegt.
SATA ist einfach nicht ausgelegt, wenn gleichzeitig viel gelesen und geschrieben wird, was bei einer Datenbank nun mal zwangsläuft häufig auftritt. AUSSER du hast nur eine DB, bei der primär NUR gelesen wird; da sieht die Sache sicherlich anders aus.
Also das Geld von NVMe, könnte man dann auch in SAS stecken und damit Booten UND die SQL Daten vernünftig bedienen. (die 5 Sekunden, die das booten dann langsamer ist, holst du in der DB wieder rein)
Und wenn du wirklich auf SATA baust, erübrigt sich die ursprüngliche Frage für den Cache erst recht.
Da hier das SATA zum Flaschenhals wird, kommst du um den Cache eigentlich nicht drumrum.
Alles andere kann man nicht mit gutem Gewissen "verkaufen".
Naja, viel "Spass" damit.
Gruss Roland
wenn gleichzeitig viel gelesen und geschrieben wird, was bei einer Datenbank nun mal zwangsläuft häufig auftritt. AUSSER du hast nur eine DB, bei der primär NUR gelesen wird; da sieht die Sache sicherlich anders aus.
Anscheinend wissen nicht mal die Hälfte der Admins hier, solche Details über ihre Konfigurationen.
Anscheinend wissen nicht mal die Hälfte der Admins hier, solche Details über ihre Konfigurationen.