Configurazione consigliata di disco / partizione per un server SQL

Sto cercando qualche consiglio riguardo al modo migliore per configurare i miei dischi / partizioni per SQL Server. Ecco alcune delle mie maggiori preoccupazioni:

Come devono essere separati i file SQL (file di dati, registri, temp)?

È meglio RAID molti HDD e partizionare lo spazio o creare più RAID con meno dischi per ciascun RAID?

I file di dati e di registro devono essere su un tipo RAID diverso?

I database predefiniti (master, msdb, ecc ...) dovrebbero trovarsi sul C: o dovrebbero trovarsi nello stesso posto degli altri file di dati / log?

Ecco un bel post sul blog: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

White paper sull'allineamento del disco: http://msdn.microsoft.com/en-us/library/dd758814.aspx

In breve, il tuo sistema operativo dovrebbe essere su RAID 1, i tuoi file di dati su RAID 10 (preferibilmente) e i file di registro su RAID 1.

Articolo SQL Performance: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx

PDF sui 10 migliori consigli sulle prestazioni: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Ricorda inoltre di posizionare TEMPDB su un disco separato per motivi di prestazioni. Sono sicuro che Paul Randal entrerà qui e ti lascerà a bocca aperta perché tra un po '.

MS dice perché per tempdb: http://msdn.microsoft.com/en-us/library/ms175527.aspx

Questa è una grande domanda "dipende".

Non posso rispondere a come creare la singola domanda di array RAID per te, poiché non sono un esperto di archiviazione, ma posso aiutarti con il resto.

La prima cosa che devi considerare è qual è il carico di lavoro sui vari database: OLTP (lettura / scrittura) o DSS / DW (lettura per lo più). Per i carichi di lavoro in lettura / scrittura, dovresti guardare RAID 1 o RAID 10 (RAID 1 + 0), in quanto forniscono ridondanza e ottime prestazioni di lettura / scrittura. Per i carichi di lavoro prevalentemente a lettura è possibile utilizzare RAID 5. Il motivo per cui RAID 5 non deve essere utilizzato per i carichi di lavoro in lettura / scrittura è che si paga una penalità per le prestazioni in scrittura.

I registri delle transazioni, per loro stessa natura, sono in lettura / scrittura (o in gran parte in scrittura, a seconda che si stia utilizzando il registro delle transazioni per qualsiasi cosa, ad esempio backup dei registri o replica) e quindi non devono mai essere inseriti in RAID 5.

Ciò significa che per alcuni database e carichi di lavoro, potresti avere file di dati su RAID 5 e file di log su RAID 1/10 e per altri database potresti avere tutto su RAID 1/10. Andando oltre, se si dispone di un database partizionato, potrebbe contenere alcuni dati di lettura e lettura / scrittura, eventualmente anche all'interno della stessa tabella. Questo può essere suddiviso in filegroup separati e quindi ciascun filegroup ha un livello RAID appropriato.

La separazione dei database effettivi dipende nuovamente dal carico di lavoro e dalle capacità del sottosistema IO sottostante. Ad esempio, potrebbe essere necessario un livello di separazione più elevato per l'archiviazione su singoli array RAID rispetto a una SAN.

Tempdb è un caso speciale tutto da solo, in quanto di solito è un database pesantemente caricato e deve essere archiviato separatamente dagli altri database. I database di sistema non devono essere utilizzati pesantemente e possono essere posizionati ovunque purché vi sia ridondanza.

Ecco un link a un white paper che ho aiutato a scrivere che dovrebbe aiutarti: Physical Database Storage Design . Assicurati inoltre che il tuo sottosistema IO sia in grado di gestire il carico di lavoro previsto. Consulta questo white paper: Best Practices I / O Predeployment . Infine, assicurati di utilizzare la dimensione di striping RAID corretta (in genere 64 KB o superiore su sistemi più recenti), la dimensione dell'unità di allocazione NTFS corretta (in genere 64 KB) e che su sistemi precedenti a Windows Server 2008, imposti correttamente l'offset della partizione del disco . Per informazioni su questi e suggerimenti per ulteriori informazioni su di essi e perché dovresti configurarli in questo modo, vedi questo post sul blog: Gli offset della partizione del disco, le dimensioni della striscia RAID e le unità di allocazione NTFS sono impostate correttamente? .

Linea Bototm: conoscere il carico di lavoro e le capacità del sottosistema IO e quindi implementare di conseguenza.

Spero che questo ti sia di aiuto.

PS Per quanto riguarda tempdb, è una grande quantità di worm su come configurarlo e ci sono tutti i tipi di informazioni contrastanti. Ho scritto un post completo sul blog sulla configurazione del file di dati tempdb a Misconceptions intorno a TF 1118 .

La risposta breve per i server che ho impostato è sempre stata

Accede a dischi fisici separati, raid 1 o 10 (striping + mirroring)

Database su propri dischi, a seconda delle esigenze prestazionali generalmente RAID5

Molta cache sui controller dei raid

Preferibilmente incollare nuovamente il proprio sistema operativo e file di paging di Windows su un array separato, di solito solo un mirror (Raid 1). Ciò mantiene separate tutte le operazioni di scrittura in modo che le prestazioni pesanti non trascinino tutto verso il basso.

Quello che ho sperimentato in passato è che avere scritture di database + scritture di log + scritture di file di paging impantanerà un array Raid5 e le prestazioni andranno a male in un cestino. Il problema è che le tue prestazioni andranno bene nei test, negli sviluppatori, ecc. Ma quando inizi a produrre e utilizzare i razzi questo problema apparirà "all'improvviso" e le lamentele degli utenti saliranno alle stelle.

Ci sono ragazzi MSSQL molto migliori qui di me, ma in generale suggerirei quanto segue;

Sistema operativo e codice su C: - questo dovrebbe essere il disco locale, dovrebbe essere una coppia di array RAID1 - per questo utilizziamo 2 dischi SAS da 146 GB 10krpm da 2,5 pollici ma è possibile utilizzare 2 dischi SATA 7.2. I dati dovrebbero essere su un array RAID abbastanza veloce (10krpm o migliore) RAID 1/10, 5/50/6/60 di qualunque dimensione tu abbia bisogno - conserviamo i nostri su FC SAN LUN, di solito su un gruppo di dischi 'tier 2' / 10krpm . I log dovrebbero essere su una coppia di array RAID 1 piccola MOLTO VELOCE (15krpm) separata (10 GB o meno?) - manteniamo i nostri su LUN FC SAN, di solito su un gruppo di dischi 'tier1' / 15krpm molto piccolo o su un 'tier0' / gruppo ssd.

In ogni caso, vuoi che ogni pezzo di questi su fusi / array separati per le prestazioni - ovviamente funzionerà tutto da un singolo disco ma immagino che tu stia cercando un equilibrio tra prestazioni e costi.

Archiviamo il nostro master / tempdb con i nostri database regolari ma è possibile suddividerlo in un LUN di array di dati separato.

Spero che sia di aiuto.