Come devo configurare questi dischi su un SQL Server per una configurazione BI?

Supponendo che la memoria costante (32 GB) e la CPU (4), 2 x array di dischi, ho i seguenti dischi

2 x 150 (10k)
6 x 150 (15k)

Sono tutti dischi locali.

Le mie esigenze

Il mio DB è di 350 GB e impostato su una crescita predefinita del 10%
Il mio sistema operativo e SQL Server sono Server 2k8R2 (C: sistema operativo + pagina + applicazioni + 55 Gb)
I requisiti del registro sono di circa 70 GB e sono impostati su una crescita predefinita del 10% e vengono regolarmente troncati
Il mio TempDb è attualmente di circa 12 GB e impostato su una crescita predefinita del 10%

Il mio problema è che sto cercando di capire dove posizionare al meglio TempDB, OS e Log. La mia esperienza è limitata nella configurazione ottimale di questi due

Questo non è un sistema transazionale online. Ha una scrittura pesante di dati (nuovi dati + indici ricostruiti / riprogrammati), quindi una lettura pesante di dati (sto valutando a circa 50/50) per circa 13 ore, e poi semplicemente silenziosa.

La mia comprensione è che TEMPDB è molto utilizzato durante la normale elaborazione rispetto al registro.

La mia idea è la seguente

2 x 150g (15k) Raid 1 = 150g per OS + TempDB
2 x 150g (10k) Raid 1 = 150g per LOG (nota i dischi più lenti qui)
4 x 150g (15k) Raid 5 = 150g per i dati

Sembra una buona idea? Potrei quindi scambiare Log + TempDB se necessario.

Sto infrangendo le regole cardinali come non mettere mai TempDB sul disco del sistema operativo a causa di problemi di paging o forse non mettere mai il registro su un disco più lento dei dati ?

Modificare:

Abbiamo anche un SSAS sul sistema e gli utenti finali accedono solo al cubo. Il 50% letto sopra si basa sul tempo impiegato per elaborare il database SSAS.

sql-server-2008-r2 business-intelligence disk-structures

— Preet Sangha
fonte

Risposte:

2 * 10k RAID1 per sistema operativo, 6 * 15k RAID10 per tutto il resto. Onestamente, con questo numero di dischi 1 array è la scommessa più sicura e solitamente più veloce.

Se hai tempo per testare e avere un carico di lavoro misurabile, ripetibile e reale, allora esegui un test con il tuo tempdb sull'unità del sistema operativo (attenzione: limita la crescita dei file tempdb per assicurarti di non dividere il sistema operativo) . D'altro canto, potresti notare moderati miglioramenti nel caricamento e nella manutenzione dei dati con il registro lì, quindi vale la pena eseguire un test o due se il tempo lo consente.

— Mark Storey-Smith
fonte

C'è qualcosa da avere con array extra? Il TempDB non dovrebbe trovarsi in un set di array / mandrini separato? Sto stimando il 50/50 poiché si basa sull'elaborazione DW 50% e l'elaborazione SSAS 50% (6 ore di lettura).

— Preet Sangha,

Non vedo alcuna menzione di un cubo di servizi di analisi nella tua domanda originale. Sia il database relazionale che il cubo vengono interrogati dagli utenti finali o solo dal cubo?

— Mark Storey-Smith,

+1 Mi piace la tua raccomandazione. Vale la pena notare che se mette tempdb sull'unità del sistema operativo, sicuramente limita la dimensione massima per i file di database. Siamo tutti d'accordo sul fatto che non vogliamo che file di database non autorizzati riempiano quel particolare disco.

— Thomas Stringer,

@PreetSangha Belief non è un'ottima base su cui pianificare una distribuzione di server o di archiviazione. Devi dedicare un po 'di tempo alla ricerca e alla comprensione del perché sia appropriato in alcuni scenari e non in altri. La separazione del cubo dal database relazionale può avere delle gambe qui, ma chi può dirlo senza testarlo. Non c'è niente di duro e veloce, una taglia adatta a tutti, temo l'approccio JFDI a questo.

— Mark Storey-Smith,

Se riesci a testare e misurare i vari scenari con il tuo carico di lavoro, potrebbe rivelarsi perfetto. Quando / se non puoi, un grande pool di storage il più veloce possibile assorbirà i grumi e le protuberanze meglio di un colpo nella divisione oscura. Sentiti libero di entrare in chat se vuoi far rimbalzare idee. Esistono diversi clienti abituali con più esperienza SSAS di me che potrebbero avere suggerimenti per determinare come / se è necessario dividere il cubo dal database.

— Mark Storey-Smith,

Concordo con Mark sul fatto che l' approccio ideale è quello di mettere le due unità più lente in RAID 1 solo per O / S, e il resto delle unità in RAID 10 per tutto il resto. Sarebbe l'ideale.

In base alle dimensioni che hai fornito, tuttavia, questo ti dà quasi il massimo per iniziare, con un margine di errore molto piccolo e nessuna possibilità di crescita. E a proposito, se qualcuno ti dicesse che le unità sono 150 GB, potrebbero effettivamente essere più piccole di quelle (146 GB?), Non formattate, il che probabilmente significa che non tutto si adatterà immediatamente.

Sfortunatamente, il carico di lavoro comporta scritture pesanti e, per questo, RAID 5 ... non è tuo amico.

Se riesci a districare un po 'di budget extra, ci sono un paio di approcci:

Altre due unità da 15k della stessa dimensione. A seconda del significato di "2 array di dischi",> 8 unità totali potrebbero indicare la necessità di un nuovo controller RAID. (E / o un telaio più grande, possibilmente.)
Due SSD da ~ 120 GB (PCI-express o SATA) nel software RAID 1 per dati / registro TempDB e file di registro del database. Questa potrebbe effettivamente essere la soluzione, il periodo più veloce e potrebbe costare molto meno di 2 unità 15k di classe enterprise (per non parlare di un controller RAID comparabile). Questo presuppone che ci siano slot / porte disponibili sulla scheda madre, che probabilmente ci sono.

Se la gestione non si sposta sul budget (questa situazione puzza come il vecchio hardware viene riproposto per un nuovo progetto ... il che significa che il budget è zero), dovrai utilizzare RAID 5 per motivi di spazio, perché non c'è modo per evitarlo senza più dischi disponibili. A quel punto, la mossa migliore è probabilmente quella di mettere i 2 dischi più lenti in RAID 1 solo per O / S, e il resto in RAID 5 per massimizzare lo spazio. Se sei costretto a utilizzare RAID 5 per qualsiasi parte di questo, la direzione deve firmare (per iscritto) per capire cosa significa in termini di prestazioni.

— Jon Seigel
fonte

Grazie. Questo è un server client, quindi prenderanno la decisione finale, ma accettiamo che le grandi strisce ridondanti veloci siano le migliori a cui dovremmo puntare. I nostri server utilizzano strisce SSD di grandi dimensioni.

— Preet Sangha,