SQL Server: separazione di dati, log e file TempDB su una SAN


8

Ho un SQL Server collegato a una SAN. Il nostro nuovo fornitore di archiviazione consiglia a tutti i LUN di estendersi all'intero array di dischi, che è RAID5. Normalmente richiederei 3 LUN separati (dati, log e TempDB) all'amministratore della SAN, ma, dato il consiglio del nuovo fornitore, ha senso creare LUN separati? O vedrei la stessa performance se tutto fosse in un LUN poiché avrebbe comunque esteso tutti i dischi?

Grande articolo qui, ma non risolve del tutto la mia situazione esatta: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

Risposte:


6

Una cosa da considerare è che i file di registro sono scritture sequenziali in cui i file di dati non sono sequenziali. Questo è uno dei motivi per LUN separati. I file di registro scrivono più velocemente se sono nella propria LUN perché i mandrini non devono saltare, basta scrivere sequenziali. Se aggiungi un file di dati, i mandrini devono saltare e perdi alcune prestazioni. Spero di avere la giusta terminologia lì dato che non conosco molto bene le SAN stesse. L'idea alla base dovrebbe essere comunque.

I consigli del fornitore frequenti sono errati quando si tratta di SQL Server. Solo perché SQL Server ha esigenze diverse rispetto alla maggior parte delle applicazioni che utilizzano una SAN.


1
Penso che ciò che l'OP sta dicendo sia che, indipendentemente dal LUN, stanno colpendo tutti gli stessi mandrini. In altre parole, non esiste una separazione fisica per pool di dischi isolati.
Thomas Stringer,

1
Ah, immagino che ciò che stavo dicendo non sia impostato in questo modo :) avere ciascuno dei LUN su diversi mandrini anche se il venditore suggerisce il contrario. Se ciò non è possibile, non vi è alcun motivo prestazionale per separarli su LUN diversi. Anche se non si sa mai cosa succederà in background e ad un certo punto in futuro se si trovano su LUN separati, possono essere spostati su diversi mandrini.
Kenneth Fisher,

4

Molto dipende dalla SAN, in genere si desidera configurare diversi LUN con differenti cache, compressione, crittografia, read-ahead, criteri di scrittura / priorità, priorità, ecc. I file di dati SQL presentano spesso comportamenti diversi rispetto a tempdb o log File. Il metodo di accesso / rete entra anche in gioco in quanto il trunking, il multi-pathing e altre tecnologie possono o meno funzionare a seconda del metodo di accesso (FC, iSCSI, ..) e dell'infrastruttura. Dovrai essere in grado di utilizzare la tua rete al massimo con SQL Server poiché latenza e velocità effettiva sono fondamentali. Ho visto casi con configurazione di teaming in rete, ma solo 1 Gbps era utilizzabile a causa di altri vincoli di cui il client non era a conoscenza. Concordo con Kenneth, prendo le raccomandazioni del fornitore con una grande dose di sale, sono spesso sbagliate. SQL Server è una bestia volubile, ci sono pochissimi assoluti, di solito solo più domande. Porre le domande giuste (attraverso i test) è davvero la chiave.


2

Non "prendere le raccomandazioni del fornitore con una grande dose di sale", a meno che non provengano dal reparto vendite o marketing. Al contrario, se riesci ad avere accesso ai loro tecnici di implementazione tecnica, fai amicizia.

Probabilmente questa è una delle nuove appliance di razza che virtualizza il pool di archiviazione e include funzionalità di livello automatico. Un esempio sarebbe Compellent . Eseguono ogni sorta di voodoo SAN come:

  • Scrivi blocchi attivi di dati nello storage di livello 1 con livelli RAID ottimizzati per le prestazioni come RAID 10.
  • Esegui la migrazione automatica dei blocchi di dati inattivi nella memoria di livello inferiore con RAID 5 o 6 con overhead superiore e protezione elevata.

Per il Compellent, l'archiviazione è divisa in 3 livelli con Tier1 il più veloce (SSD o RAID 10) fino al lento Tier3 che comprende dischi SAS 7k. Non ho ancora usato uno di questi in un ambiente di produzione, ma ne ho accesso a uno, che spero di poter eseguire alcuni test.

Confesso di essere al tempo stesso incuriosito e impaurito dalle funzionalità di auto-tier, che sulla carta sembrano meravigliose ma in produzione possono essere problematiche. Il primo esempio che si è verificato come potenzialmente fustigazione del meccanismo di livello automatico sono stati i backup del database. Lì hai un target di scrittura alto ripetuto che può ingannare il meccanismo di tiering nel spostare i blocchi in un pool ad alte prestazioni, potenzialmente espellendo i dati che dovrebbero essere lì.

Alla domanda originale:

... ha senso creare LUN separati?

Probabilmente no, no. Rendi il caso d'uso chiaro al venditore per essere sicuro, ma se si tratta di un dispositivo di tipo Compellent, non credo che tu possa ottenere nulla dalla divisione dei tuoi LUN.


2

C'è qualche punto per separare i LUN? Quasi sempre. Altrimenti si finisce per sovraccaricare la coda LUN sul server Windows. E sperimentare qfull condizioni è doloroso, indipendentemente dal sistema operativo, dalla virtualizzazione o dalla piattaforma di archiviazione

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.