SQL Server: Ideale Raid Konfiguration

[Masamune2]

Ich hab hier eine Diskussion bei der ich einfach nicht weiter komme und mir deshalb gern noch ein paar Meinungen einholen würde:

Es geht im die optimale Raid Konfiguration bei einem SQL Server. Ich hab mal gelernt das man die Daten auf ein Raid 5 legt und die Logs auf ein Raid 10.
Ich denke aber das es genau umgekehrt viel logischer ist. Einen gescheiten Controller mit Batterie gestütztem Cache (und damit Write Back) vorausgesetzt dürfte die sequentielle Schreibperformance eines Raid 5 die eines Raid 10 übersteigen. Ideal um die Logdateien abzulegen da diese ja nur sequentiell verarbeitet werden.
Bei den Daten selbst ist wiederum der zufällige Zugriff ausschlaggebend und da ist ein Raid ohne Parität natürlich immer schneller, da die Daten nicht zuerst gelesen, modifiziert und dann wieder geschrieben werden müssen.

Hab ich irgendwas vergessen zu bedenken? Die Last die durch die Berechnung der Parität entsteht ist bei aktuellen Controllern zu vernachlässigen, denn die schaffen spielend mehrere Gigabyte.

 

[Andreas75]

also raid10=gespiegeltes stripeset ist in der tat wohl das sinnvollste für performance. fand die raid5 bisher immer sehr träge. für logs sollte es eigentlich auch ein raid1 tun.

 

[Masamune2]

Raid 10 ist eben nicht immer das sinnvollste für Performance, es kommt auf den Anwendungsfall an. Beispiel:

8 Platten im Server -> Raid 10: Beim sequentiellen Schreiben werden vier Platten genutzt (die anderen vier schreiben den Spiegel)

8 Platten im Server -> Raid 5: Beim sequentiellen Schreiben werden sieben Platten genutzt (eine hält die Parität)

In diesem konkreten Fall ist das Raid 5 schneller. Und genau dieser Fall liegt meiner Meinung nach beim schreiben von SQL Logs vor.

 

[chris.]

korrekt, sofern der Controller die Bandbreite hergibt.

Grüße

 

[tm0975]

geht es dir um theoretische betrachtungen oder um ein praktisches beispiel? mein persönlicher eindruck von raid 5 ist ebenfalls nicht so besonders. allerdings ist, entsprechend hauptspeicher vorausgesetzt, das raid nicht die zentrale größe für die leistungsfähigkeit der applikation.

 

[Masamune2]

Naja ein konkretes Beispiel hab ich jetzt nicht, aber man kann sich ja realistische Szenarien schaffen wenn das die Diskussion erleichtert.

Mir geht es darum das weit verbreitete (in meinen Augen) Märchen zu wiederlegen, dass Daten auf Raid 5 liegen sollten und Log Files auf Raid 10.

 

[supastar]

Man rechnet nicht per Platten, sondern per Speicherplatz.

z. B. 1,8 TB Speicherplatz
= 4x 600 GB SAS-Festplatten im RAID 5
= 6x 600 GB SAS-Festplatten im RAID 10 bzw. würden hier wohl einige eher 12x 300 GB empfehlen wegen höherem I/O-Durchsatz.

Zudem dürfte die Paritätsberechnung bei 8 Platten durchaus ein wenig Performance fressen.

Ich würde hier in jedem Fall ein RAID 10 bevorzugen, für die Logs reicht IMHO evtl auch ein RAID 1.

Die Empfehlung für ein RAID 5 dürften hier wohl höchstens auf niedrigere Kosten hinauslaufen.

Ein ordentlicher Hardware-RAID-Controller mit BBU ist in jedem Fall empfehlenswert.


EDITh weißt darauf hin:
http://msdn.microsoft.com/en-us/library/dd758814.aspx
http://msdn.microsoft.com/en-us/library/ee229554(v=SQL.10).aspx

 

[Masamune2]

Natürlich rechnet man pro Platte (Spindel) denn das macht die Performance aus. Die Kapazität ist in der Betrachtung unwichtig.
Die Performance die durch die Paritätsberechnung verloren geht ist dank modernen Controllern zu vernachlässigen.

 

[supastar]

Zu vernachlässigen würde ich jetzt mal nicht sagen.
Geringer, aber in jedem Fall vorhanden.

Wobei die Lesezugriff natürlich im Vordergrund stehen dürften.

 

[Masamune2]

So einfach mal nachgemessen:

Hardware ist eine HP EVA 4400 mit 48 Platten.
vRaid1:
4k random read: 15500 I/O
4k random write: 12200 I/O
streaming read: 800 MB/s
streaming write: 410 MB/s

vRaid5:
4k random read: 15000 I/O
4k random write: 9250 I/O
streaming read: 800 MB/s
streaming write: 430 MB/s

Für die Datenpartition ist also ein Raid 1 (oder jede variante davon) zu bevorzugen da hauptsächlich zufällige verteilte Zugriffe stattfinden, für die Log Dateien empfiehlt sich Raid 5 (oder jede Variante davon) da hauptsächlich sequentielle Zugriffe stattfiden.

 

[Onkelhitman]

Um wieviel Speicherplatz dreht es sich hier eigentlich in diesem speziellen Fall?

 

[Masamune2]

Naja es gibt keinen konkreten Bedarf, mich hat nur mal die Theorie interessiert.

 

[HisN]

Ich stell mir unter SQL-Datenbanken immer einen Haufen kleiner Text-Sätze vor.
Bei random-Zugriff müsste doch eine SSD (ohne RAID) jedes Raid wegrocken, da die sequentiellen Dauerdateitransferbandbreiten dabei doch völlig wurst sind.

 

[Masamune2]

Ist richtig, aber im Enterprise Bereich sind die SSDs noch nicht so angekommen wie bei Endnutzern. Außerdem ist soviel Performance ja nur selten nötig, es ging hier ja nur darum bei klassichen Plattensystemen das Maximum rauszuholen.

 

[CedBE]

Wie würde das Szenario bei einem Webserver aussehen?
Gilt generell immer OS / application server und SQL Server auf unterschiedlichen Raid's zu betreiben?

Bei mir würde sich derzeit ein konkretes Problem stellen, könnten wir das daran erläutern?
OS mit Webserver auf einer SSD, und SQL Server auf einem Raid 1?

 

[Andreas75]

cedbe, beide server jeweils auf ein raid1, den sqler dabei mit ssd

 

[CedBE]

Und jeweils mit getrennten Controllern? - eine Modell bzw. Markenempfehlung?
Die Platten wären in meinem konkreten Fall mit S-ATA Interface...

 

[Masamune2]

Ob es Sinn macht OS und Daten immer zu trennen hängt vom Controller ab und davon welche Zugriffsmuster du hast.

Moderne Controller fassen alle Platten zu einem Verbund zusammen und legen dort dann mehrere Volumes mit unterschiedlichen Raid Leveln an die sich über alle Platten erstrecken (einige Controller haben das Raid Level auch schon direkt beim Plattenverbund und alle Volumes drauf haben dann das gleiche Level).
OS und Daten zu trennen macht aus Performance Sicht dann nur noch Sinn wenn man unterschiedliche Raid Level nutzt. z.B.

8 Platten im Server in einem Array:
- Raid 5 für das OS, da hauptsächlich lesender Zugriff im Betrieb
- Raid 1 für die Datenbank, da verteilte Schreibzugriffe relativ häufig sind
- Raid 5 für die Logs, da hauptsächlich sequentielle Zugriffe

Bei einem Webserver wird quasi ausschließlich gelesen, daher ist hier ein Raid 5 ausreichend. Hier musst du OS und Daten also nur trennen um zu verhindern das die OS Platte komplett voll geschrieben wird. Aus Performance Sicht gibt es keinen Grund.

Je nachdem wieviele Zugriff du hast sind diese Optimierungen allerdings mit Kanonen aus Spatzen geschossen. Bei einem typischen Miet Server von 1und1 und Co. stecken ohnehin nicht die richtigen Controller bzw genügend Platten im System als das man sich um solche Optimierungen Gedanken machen müsste. In deinem Fall wäre die SQL Datenbank auf der SSD allerdings wohl besser untergebracht.

 

[CedBE]

SSD ohne Raid?
Wie ist es denn da mit der Ausfallsicherheit bestellt?

Denn darum geht es, ein dump File wird mehrmals täglich erstellt und auf ein NAS System kopiert...

 

[Masamune2]

Wenn nur eine SSD drin is is halt nur eine drin. Dann musste dich zwischen Geschwindigkeit und Ausfallsicherheit entscheiden.