Wie sollte ich das RAID-Array von SSD-Laufwerken auf meinem SQL Server konfigurieren?

Ich baue einen SQL Server mit 48 GB RAM, 1 CPU und 8 SATA III (6 GB / s) SSD-Laufwerken (128 GB Crucial m4) und einem LSI MegaRAID-Controller (SAS 9265-8i). Ich gehe davon aus, dass die typische Arbeitsbelastung hauptsächlich bei den Lesern liegt. Es wird einige Perioden intensiverer Schreibaktivitäten geben (stündliche Datensynchronisierung mit Datenanbietern von Drittanbietern - nächtliche Sicherungen), aber ich vermute, dass das typische Lese- / Schreibverhältnis etwa 90% Lesezugriffe / 10% Schreibzugriffe beträgt.

Option 1:
Logisches Laufwerk C: - RAID 1 (2 physische Laufwerke) -
Logisches Laufwerk D des Betriebssystems : - RAID 10 (6 physische Laufwerke) - DB-Dateien / Protokolle / Tempdb / Backups?

ODER

Option 2:
Logisches Laufwerk C: - RAID 1 (2 physische Laufwerke) -
Logisches Laufwerk D des Betriebssystems : - RAID 1 (2 physische Laufwerke) - DB-Dateien
Logisches Laufwerk E: - RAID 1 (2 physische Laufwerke) - Protokolldateien / Backups?
Logisches Laufwerk F: - RAID 1 (2 physische Laufwerke) - Tempdb

ODER

Option 3:
Andere Vorschläge?

Ich denke, Option 1 würde zu einer besseren Leistung führen, da alle DB-Aktivitäten auf drei Laufwerke verteilt werden (und auf die anderen drei im Array gespiegelt werden), obwohl Option 2 konventionelle Weisheiten zu imitieren scheint (was eher auf die Mechanik zutrifft) Laufwerke als SSDs). Es scheint, als wäre der Stapelüberlauf mit Option 1 verschwunden .

Ich vermute, mit SSDs ist es in Ordnung, alles auf ein einziges logisches Laufwerk zu setzen, da Ihr Server an diesem Punkt wahrscheinlich mehr CPU-Beschränkungen als E / A-Beschränkungen unterliegt.

Eine andere Frage, die ich habe, ist, wo ich die nächtlichen Backups platzieren soll. Wir wollen nicht, dass Sicherungen den Rest des SQL-Servers verlangsamen, und ich schätze, dass das Schreiben der Sicherungen am selben Speicherort wie die Protokolle eine gute Praxis ist, da das Lese- / Schreibverhalten in beiden Fällen sequentielles Schreiben ist.

Herkömmliche Kenntnisse über RAID lassen sich nicht gut auf SSDs anwenden. Sie brauchen kein Striping (RAID0). Sie sind anfällig für systembedingte Ausfälle, aber RAID-1 ist normalerweise aus zwei Gründen nicht die richtige Antwort für SSD: a) ist verschwenderisch, halbiert die Kapazität des SSD-Arrays (und sie sind teuer) und 2) führt zu Ausfällen bei SSDs zu beiden Laufwerken in dem Spiegel, um in sehr engen Intervallen (dh korrelierten Ausfällen) auszufallen und somit das gesamte Array unbrauchbar zu machen. Weitere Informationen finden Sie unter Differenzielles RAID: RAID für SSD-Zuverlässigkeit überdenken . Einige haben die Verwendung von Raid-6 für SSDs empfohlen .

Darüber hinaus gilt die herkömmliche Weisheit des SQL Server-Dateilayouts nicht für SSDs. Ich würde empfehlen, dass Sie sich SQL auf SSDs ansehen : Hot and Crazy Love und die Benchmark-Links in dieser Antwort durchgehen .

Die Standardmethode zum Trennen der zufälligen E / A-Muster für Daten von der Protokollsequenz gilt für SSDs einfach nicht. Daher würde ich Ihre Option 1 mit folgenden Einschränkungen auswählen:

• Backups MÜSSEN sich auf einem separaten Computer befinden. Es hat wenig Sinn, Backups zu haben, auf die Sie nicht zugreifen können, wenn der Server in Rauch aufsteigt.
• Es ist sinnvoll, die Daten- und Protokolllaufwerke so zu trennen, dass Sie bei einem Ausfall des Daten-Arrays ein Ende der Protokollsicherung erstellen können.
• Achten Sie darauf, dass Sie keinen Ersatz haben.
• Denken Sie daran, dass Sie Laufwerke auf Consumer-Ebene haben. Gehen Sie nicht davon aus, dass sie zu einem Vielfachen der Kosten so zuverlässig sind wie die Unternehmens-Äquivalente.
• Sehen Sie sich das unterhaltsame und sehr informative SQL zu SSDs an: Hot and Crazy Love von Brent Ozar.

Das Problem der Trennung von Protokollen von Daten, bei denen SSDs verwendet werden, ist eher eine Frage der RPO (Recovery Point Objective) für das System als der Leistung. Wenn das RPO in Minuten definiert ist, verwenden Sie ein freigegebenes Array und erstellen Sie alle [RPO] Minuten Protokollsicherungen. Wenn das RPO in Sekunden definiert ist, verwenden Sie separate Arrays.

Um ehrlich zu sein, würde ich bei einem engen RPO SSDs für das Datenarray behalten und ein gespiegeltes Paar teurer (Unternehmens-) zuverlässiger Spinner für das Protokoll verwenden.

Sie sollten mit Option 2 wie folgt fortfahren:

Logical Drive - RAID 1 (2 physical drives)
 1 partition C: OS
 2 partition D: backups / log files
Logical Drive E: - RAID 1 (2 physical drives) - DATA files
Logical Drive F: - RAID 1 (2 physical drives) - INDEX files
Logical Drive G: - RAID 1 (2 physical drives) - tempdb

Wenn Sie Ihre Daten und Ihre Indizes in zwei verschiedene Datendateien aufteilen, die dann auf zwei verschiedenen physischen logischen Laufwerken gespeichert werden, erhöht sich die Anzahl der Festplatten erheblich, da bei einer Abfrage nur eine Festplatte für die Tabellendaten und eine andere für die Tabellendaten rotiert zur gleichen Zeit für Ihren Index drehen.

Lassen Sie tempdb auch von Ihren Backups getrennt, da dort auch eine Menge Dinge passieren. Verwechseln Sie nicht Ihre Backups und Ihre Datendatei. Auch wenn Backups nicht täglich durchgeführt werden, haben sie einen großen Einfluss auf Ihre E / A. Abhängig von Ihrem Unternehmen und der Nutzung Ihrer Datenbank können sich einige oder VIELE Personen während der Sicherungszeit beschweren.

Hoffe das hilft