Come devo configurare l'array RAID di unità SSD sul mio SQL Server?

14

Sto costruendo un SQL Server con 48 GB di RAM, 1 CPU e 8 unità SSD SATA III (6 GB / s) (128 GB Crucial m4) e un controller LSI MegaRAID (SAS 9265-8i). Mi aspetto che il carico di lavoro tipico sia per lo più letto. Ci saranno alcuni periodi di attività di scrittura più pesanti (sincronizzazione oraria dei dati con provider di dati di terze parti - backup notturni), ma sospetto che il tipico rapporto lettura / scrittura sia di circa il 90% in lettura / 10% in scrittura.

Opzione 1:
Unità logica C: - RAID 1 (2 unità fisiche) -
Unità logica D del sistema operativo : - RAID 10 (6 unità fisiche) - File DB / registri / tempdb / backup?

O

Opzione 2:
Unità logica C: - RAID 1 (2 unità fisiche) - OS
Unità logica D: - RAID 1 (2 unità fisiche) - File Db
Unità logica E: - RAID 1 (2 unità fisiche) - File di registro / backup?
Logical Drive F: - RAID 1 (2 unità fisiche) - tempdb

O

Opzione 3:
altri suggerimenti?

Sto pensando che l'opzione 1 mi darebbe prestazioni migliori, dal momento che tutta l'attività del DB verrebbe suddivisa su 3 unità (e rispecchiata sulle altre 3 nell'array), sebbene l'opzione 2 sembra imitare la saggezza convenzionale (che sembra applicarsi maggiormente alla meccanica unità rispetto agli SSD). Sembra che Stack Overflow sia andato con l' opzione 1 .

Sto indovinando con SSD è OK mettere tutto su una singola unità logica poiché il tuo server è probabilmente più CPU vincolata anziché I / O vincolata a quel punto?

Un'altra domanda che ho è dove devo posizionare i backup notturni? Non vogliamo che i backup rallentino il resto del server SQL e immagino che scrivere i backup nella stessa posizione dei registri sia una buona pratica perché il comportamento di lettura / scrittura in entrambi i casi è scritture sequenziali.

sql-server configuration

— robbie
fonte

Una volta ho creduto che ci fosse un vantaggio nella distribuzione logica, ma dopo alcune ricerche abbastanza approfondite (Michael potrebbe averne ancora una parte), siamo giunti alla conclusione che la distribuzione logica @ il livello target non ha migliorato le prestazioni. Quindi, se stessimo parlando di un disco fisico (che gira) e volevi 8 file di dati per sfruttare l'affinità di base, non importava se fossero 8 file su un singolo volume logico (sullo stesso disco fisico) o se si tagliano 8 partizioni logiche per quegli 8 file (sullo stesso disco fisico). Penso che lo troverai logicamente tagliando il tuo SSD

— Eric Higgins il

9

La saggezza convenzionale sul RAID non si applica bene agli SSD. Non hanno davvero bisogno di striping (RAID0). Sono inclini a errori di progettazione, ma RAID-1 di solito non è la risposta giusta per SSD per due motivi: a) è dispendioso, dimezza la capacità dell'array SSD (e sono costosi) e 2) le caratteristiche di errore degli SSD portano verso entrambe le unità del mirror per non funzionare a intervalli molto ravvicinati (es. errori correlati) e rendere così inutile l'intero array. Vedi RAID differenziale: ripensare RAID per affidabilità SSD per una discussione più lunga. Alcuni hanno raccomandato l'uso di Raid-6 per SSD.

Inoltre, la saggezza convenzionale del layout dei file di SQL Server non si applica agli SSD. Ti consiglierei di guardare SQL su SSD: Hot and Crazy Love e andare oltre i link di riferimento in questa risposta .

— Remus Rusanu
fonte

Un buon punto, con RAID 10, sono probabilmente più vulnerabile agli errori correlati. Grazie per il collegamento RAID differenziale.

— Robbie

8

L'approccio standard di separazione dei pattern I / O casuali per i dati dalla sequenza dei log semplicemente non si applica agli SSD, quindi sceglierei l'opzione 1 con avvertenze:

I backup DEVONO essere su una macchina separata. È inutile disporre di backup a cui non è possibile accedere in caso di fumo del server.
Vi è un certo valore nel separare i dati e le unità di registro in modo tale che un errore dell'array di dati consenta di eseguire una coda di backup del registro.
Ricorda che non hai una scorta calda.
Ricorda che hai unità a livello di consumatore. Non dare per scontato che saranno affidabili quanto gli equivalenti aziendali a multipli del costo.
Guarda l' SQL divertente e molto istruttivo sugli SSD: Hot and Crazy Love di Brent Ozar.

La questione della separazione dei registri dai dati in cui vengono utilizzati gli SSD è una questione di RPO (obiettivo del punto di ripristino) per il sistema, piuttosto che delle prestazioni. Se l'RPO è definito in pochi minuti, utilizzare un array condiviso e eseguire i backup del registro ogni [RPO] minuti. Se l'RPO è definito in pochi secondi, procedere con matrici separate.

Ad essere onesti, se l'RPO fosse stretto, terrei SSD per l'array di dati e utilizzerei una coppia speculare di costosi spinner affidabili (aziendali) per il registro.

— Mark Storey-Smith
fonte

I backup vengono inoltre copiati su un computer separato. Vengono creati sul computer locale in modo da poter utilizzare SQL Compare / Data Compare e ripristinare le modifiche in caso di regressione / errore utente.

— Robbie

Inoltre, l'RPO è definito in pochi minuti (penso che anche tra 10 minuti sarebbe accettabile per il mio scenario essere completamente onesto). Il post di Hot & Crazy Love mi fa pensare a fallimenti correlati. Nella mia esperienza limitata, ho avuto più guasti alla scheda madre e guasti totali al sistema (alimentatore / sovratensione frigge tutto) quindi guasti, quindi sto ancora cercando di determinare quale sarebbe il livello più conveniente di paranoia / prevenzione.

— Robbie

1

Dovresti andare con l'opzione 2 come segue:

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

Separando i tuoi dati e i tuoi indici in 2 diversi file di dati che vengono quindi memorizzati in 2 diverse unità logiche fisiche, otterrai un enorme aumento del disco io semplicemente perché quando esegui una query, avresti un disco che gira per i dati della tabella e un altro filatura per il tuo indice contemporaneamente.

Lascia anche tempdb separato dai tuoi backup perché ci sono anche molte cose. Non confondere i backup e il file di dati. anche se i backup non vengono eseguiti quotidianamente, quando avvengono subiscono un enorme successo sul tuo IO. in base alla tua attività e all'utilizzo del tuo database, alcune persone o MOLTE persone potrebbero lamentarsi durante il tempo di backup.

Spero che sia di aiuto

— Nicolas de Fontenay
fonte

6

Senza senso. Questi sono SSD, non spinner.

— Mark Storey-Smith

non ha senso anche con sdd c'è un certo numero di prestazioni raggiunte in quel modo, anche se non così tanto.

— Nicolas de Fontenay,

2

Anche con gli spinner la separazione dei dati dagli indici non ha alcun valore fino a quando non si gioca nel territorio SQLCAT. Anche il caso della separazione di tempdb non è mai chiaro e molto raramente si applica con un numero così piccolo di dischi.

— Mark Storey-Smith