La sua pratica standard di separare i file di registro e di dati per separare i dischi dal sistema operativo (anche tempdb, backup e file di scambio) Questa logica ha ancora senso quando le tue unità sono tutte basate su SAN e i tuoi LUN non sono scolpiti su specifici set di dischi o raid -sono solo parte del numero x di unità sulla SAN e il LUN è solo l'allocazione dello spazio
Risposte:
I log e le unità dati hanno diversi modelli di accesso ai dati che sono in conflitto tra loro (almeno in teoria) quando condividono un'unità.
Scrive log
L'accesso al registro è costituito da un numero molto elevato di piccole scritture sequenziali. Un po 'semplicisticamente, i registri DB sono buffer di anello contenenti un elenco di istruzioni per scrivere elementi di dati in posizioni particolari sul disco. Il modello di accesso è costituito da un gran numero di piccole scritture sequenziali che devono essere garantite per il completamento, quindi vengono scritte su disco.
Idealmente, i registri dovrebbero essere su un volume RAID-1 o RAID-10 silenzioso (cioè non condiviso con nient'altro). Logicamente, è possibile visualizzare il processo come DBMS principale che scrive le voci di registro e uno o più thread del lettore di registri che consumano i registri e scrivono le modifiche sui dischi di dati (in pratica, il processo è ottimizzato in modo che le scritture dei dati vengano scritte immediatamente fuori dove possibile). Se c'è altro traffico sui dischi di registro, le testine vengono spostate da questi altri accessi e le scritture sequenziali del registro diventano scritture casuali. Questi sono molto più lenti, quindi i dischi di log occupati possono creare un hotspot che funge da collo di bottiglia sull'intero sistema.
Scrittura dati
(aggiornato) Le scritture del registro devono essere impegnate sul disco (indicato come supporto stabile) affinché una transazione sia valida e idonea al commit. È logicamente possibile visualizzarlo come voci di registro in fase di scrittura e quindi utilizzate come istruzioni per scrivere pagine di dati sul disco mediante un processo asincrono. In pratica, le scritture della pagina del disco vengono effettivamente preparate e memorizzate nel buffer al momento dell'inserimento della voce di registro, ma non è necessario che vengano scritte immediatamente per il commit della transazione. I buffer del disco vengono scritti su supporti stabili (disco) dal processo Lazy Writer (grazie a Paul Randal per averlo segnalato) di cui questo articolo Technet discute in modo un po 'più dettagliato.
Questo è un modello di accesso fortemente casuale, quindi condividere gli stessi dischi fisici con i log può creare un collo di bottiglia artificiale sulle prestazioni del sistema. Le voci del registro devono essere scritte per il commit della transazione, quindi avere ricerche casuali che rallentano questo processo (l'I / O casuale è molto più lento dell'I / O sequenziale del registro) trasformerà il registro da un sequenital in un dispositivo ad accesso casuale. Ciò crea un grave collo di bottiglia nelle prestazioni di un sistema occupato e dovrebbe essere evitato. Lo stesso vale quando si condividono aree temporanee con volumi di registro.
Il ruolo della memorizzazione nella cache
I controller SAN tendono ad avere cache RAM di grandi dimensioni, che possono assorbire il traffico ad accesso casuale in una certa misura. Tuttavia, per integrità transazionale è auspicabile che le scritture su disco da un DBMS siano completate. Quando un controller è impostato per utilizzare la memorizzazione nella cache write-back, i blocchi sporchi vengono memorizzati nella cache e la chiamata I / O viene segnalata come completa all'host.
Questo può risolvere molti problemi di contesa poiché la cache può assorbire molti I / O che altrimenti andrebbero sul disco fisico. Può anche ottimizzare le letture e le scritture di parità per RAID-5, riducendo l'effetto sulle prestazioni dei volumi RAID-5.
Queste sono le caratteristiche che guidano la scuola di pensiero "Lascia che la SAN lo affronti", sebbene questa visione abbia alcune limitazioni:
La memorizzazione nella cache di write-back ha ancora modalità di errore che possono perdere dati e il controller si è bloccato sul DBMS, dicendo che i blocchi sono stati scritti su disco dove in realtà non lo sono. Per questo motivo, potresti non voler utilizzare la memorizzazione nella cache del write-back per un'applicazione transazionale, in particolare qualcosa che contiene dati mission-critical o finanziari in cui i problemi di integrità dei dati potrebbero avere gravi conseguenze per l'azienda.
SQL Server (in particolare) utilizza l'I / O in una modalità in cui un flag (chiamato FUA o Accesso di aggiornamento forzato) forza le scritture fisiche sul disco prima che la chiamata ritorni. Microsoft ha un programma di certificazione e molti fornitori di SAN producono hardware che onora queste semantiche (requisiti riassunti qui ). In questo caso, nessuna quantità di cache ottimizzerà le scritture su disco, il che significa che il traffico dei registri si bloccherà se si trova su un volume condiviso occupato.
Se l'applicazione genera molto traffico su disco, il suo set di lavoro potrebbe sovraccaricare la cache, causando anche problemi di conflitto di scrittura.
Se la SAN è condivisa con altre applicazioni (in particolare sullo stesso volume del disco), il traffico proveniente da altre applicazioni può generare colli di bottiglia nel registro.
Alcune applicazioni (ad es. Data warehouse) generano picchi di carico transitorio di grandi dimensioni che li rendono piuttosto anti-social sulle SAN.
Anche su una grande SAN volumi di log separati sono ancora raccomandati. Potresti evitare di preoccuparti del layout di un'applicazione leggermente utilizzata. Su applicazioni molto grandi, potresti persino trarre vantaggio da più controller SAN. Oracle pubblica una serie di case study sul layout del data warehouse in cui alcune delle configurazioni più grandi coinvolgono più controller.
Metti la responsabilità delle prestazioni a cui appartiene
Su qualcosa con grandi volumi o in cui le prestazioni potrebbero essere un problema, rendere responsabile il team SAN per le prestazioni dell'applicazione. Se ignoreranno i tuoi consigli per la configurazione, assicurati che la direzione sia consapevole di ciò e che la responsabilità delle prestazioni del sistema sia nel posto giusto. In particolare, stabilire linee guida accettabili per le statistiche chiave sulle prestazioni dei DB come attese di I / O o attese di blocco della pagina o SLA di I / O applicativi accettabili.
Si noti che avere la responsabilità della suddivisione delle prestazioni tra più team crea un incentivo a puntare il dito e passare il dollaro all'altra squadra. Questo è un anti-modello di gestione noto e una formula per problemi che si trascinano per mesi o anni senza mai essere risolti. Idealmente, dovrebbe esistere un unico architetto con l'autorità per specificare le modifiche alla configurazione dell'applicazione, del database e della SAN.
Inoltre, confronta il sistema sotto carico. Se riesci a organizzarlo, i server di seconda mano e gli array ad attacco diretto possono essere acquistati in modo abbastanza economico su Ebay. Se si imposta una casella come questa con uno o due array di dischi, è possibile utilizzare la configurazione del disco fisico e misurare l'effetto sulle prestazioni.
Ad esempio, ho fatto un confronto tra un'applicazione in esecuzione su una SAN di grandi dimensioni (uno squalo IBM) e una scatola a due socket con un array U320 a collegamento diretto. In questo caso, £ 3.000 di hardware acquistato da ebay hanno sovraperformato una SAN di fascia alta £ 1M di un fattore due - su un host con una configurazione di CPU e memoria approssimativamente equivalente.
Da questo particolare incidente, si potrebbe sostenere che avere qualcosa del genere in giro è un ottimo modo per mantenere onesti gli amministratori SAN.
Suppongo che il tag Equallogic e il contenuto della richiesta significhino che stai parlando di una SAN Equallogic. Ciò che segue riguarda specificamente Equallogic e non si applica ad altri tipi di SAN.
Con gli array Equallogic i dischi specifici utilizzati per i volumi non possono essere specificati nel modo più preciso possibile, ad esempio con gli array EMC Clariion, quindi l'approccio deve essere leggermente diverso.
L'architettura equallogica è molto automatizzata e dinamica. Il suo building block di base è l'unità di array e non i pacchetti / gruppi RAID all'interno di un array, come si vede in altre SAN. Ogni array è interamente configurato per RAID 5, 6, 10 o 50 sebbene ciò non implichi che esiste un solo gruppo RAID per array, non puoi mai decidere o interagire con loro a quel livello. Inserite array nei pool di archiviazione e i pool appartengono quindi a un gruppo di archiviazione. Il gruppo di archiviazione dispone di un cluster \ indirizzo IP virtuale che viene utilizzato come destinazione iSCSI Discovery per tutti i volumi all'interno di quel gruppo: il software di gestione del gruppo EQL e lo stack MPIO host gestiscono il reindirizzamento a livello ip necessario per instradare effettivamente alla porta più appropriata su le singole matrici quando richiedono blocchi di dati ma è qualcosa che si ha poca o nessuna capacità di controllo.
I volumi di archiviazione sono assegnati dallo spazio libero totale in ciascun pool. Tutti i volumi all'interno di un pool sono distribuiti su tutti gli array in quel pool (fino a un massimo di 4 array separati) al fine di distribuire IO di rete attraverso il numero totale di interfacce di rete (2-4 per array Eql a seconda del modello) e IO attraverso il maggior numero possibile di controller. Il software di gestione Equallogic monitora le prestazioni di volume \ array nel tempo e ottimizza dinamicamente la distribuzione dei blocchi attraverso gli array dei membri. In generale, a meno che tu non sappia cosa stai facendo, dovresti mettere tutti gli array in un singolo pool e lasciarlo fare la sua cosa, ricordati solo di assicurarti di configurare i tuoi dischi ad alta velocità (SAS 10k \ 15k) con RAID 10, media velocità con RAID 50 o 5 al fine di garantire che il processo di ottimizzazione scelga effettivamente le unità ad alte prestazioni reali.
Per un'approssimazione approssimativa si avrà da qualche parte tra 2500-5000 IOP per array PS a seconda del tipo di unità e del tipo RAID. Se fornisci un numero sufficiente di IOP totali, il processo di gestione automatizzata dovrebbe alla fine fornire buone prestazioni anche se si raccolgono semplicemente tutti i volumi in un singolo pool.
Tuttavia, se si desidera garantire che i registri, i database, gli archivi temporanei, le unità del sistema operativo ecc. Siano effettivamente isolati l'uno dall'altro, è possibile eseguire un paio di operazioni. Innanzitutto è possibile definire una preferenza RAID per un volume che garantirà che il volume specifico sia sempre archiviato solo su array di quel tipo di RAID (se sono presenti nel pool a cui appartiene il volume). In secondo luogo, è possibile definire pool di archiviazione a più livelli che contengono solo array che forniscono i vari gradi di prestazioni richiesti per quel determinato livello e quindi distribuire i volumi nei pool appropriati. L'avvertenza relativa alla salute fornita da questo approccio è che in genere sono necessari molti array per ottenere effettivamente prestazioni complessive migliori - che potrebbero essere meno importanti per te rispetto a garantire le prestazioni sui volumi critici, quindi spesso sono sempre le migliori scelta. L'architettura di riferimento di Dell per Oracle DB utilizza un pool con 2 array RAID 10 per dati, disco di votazione e OCR e un pool separato con un singolo array RAID 5 per l'area di ripristino Flash.
In ogni momento con Equallogic dovresti chiederti se le decisioni che stai prendendo in merito al partizionamento forzato forniranno migliori prestazioni aggregate per i tuoi volumi in termini di interfacce di rete disponibili, mandrini del disco e controller. Se non puoi rispondere, opta per il numero minimo di pool e lascia che gestisca i dettagli o richieda a uno specialista equallogico di realizzare un vero progetto. Se si dispone di un solo array, non è possibile eseguire alcuna operazione in termini di separazione dei volumi.
Archiviamo i nostri DB su singoli box SAN ma con dati separati, log e LUN di backup, ciascuno su diversi gruppi di dischi, suddivisi per velocità - con i nostri log su LUN RAID 10 15Krpm, dati su LUN RAID 1 10 / 15krpm e backup su RAID 5 LUN 7.2krpm. Presentiamo inoltre registri e dati attraverso controller diversi sulla stessa SAN.
Ottima domanda!
Per prima cosa dai un'occhiata al dibattito "Steel Cage BlogMatch" di Brent Ozar su questo tema.
Nella nostra azienda, per la maggior parte dei server, inseriamo dati e registri sulla stessa unità SAN e li lasciamo al team SAN per assicurarsi che tutto funzioni correttamente.
Sto iniziando a pensare che questa non sia la strategia migliore, soprattutto per i server di volume più elevato. Il problema di fondo è che non ho davvero modo di verificare che il team SAN stia davvero facendo altro che schiaffeggiare abbastanza unità per lo spazio di cui abbiamo bisogno. Non eseguiamo benchmark IO contro le unità SAN dalla nostra parte o altro, supponiamo che stiano "facendo il loro lavoro" (adattandosi alle prestazioni e allo spazio), il che è probabilmente un po 'ingenuo.
L'altro mio pensiero è che il tipo di accesso necessario ai dati rispetto ai registri sia diverso. Proverò a trovare l'articolo che ho letto di recente che parlava di come i due diversi tipi di unità dovrebbero essere ottimizzati in modi molto diversi (penso che uno necessitasse di ottimizzazione per le scritture sequenziali, l'altro necessitasse di ottimizzazione per letture casuali, qualcosa del genere .)
In breve, sì, creare volumi separati per file di dati, file di registro e dati TempDB e file di registro di SQL Server.
Poiché hai taggato la tua domanda con Equallogic, leggi la Guida all'architettura di riferimento Dell gratuita : distribuzione di Microsoft® SQL Server® con array di storage Dell ™ EqualLogic ™ serie PS5000 (è richiesta la registrazione) prima di progettare la soluzione. Spesso troverai che le indicazioni su configurazioni specifiche possono differire in modo significativo dai consigli generici .
Concordo con BradC (+1) in termini di prestazioni. In generale, una buona SAN avrebbe un I / O più grezzo di quanto ci si possa aspettare.
È comunque una buona idea separare i tuoi BACKUP dal tuo sistema live (ovvio lo so, ma se avessi un £ 1 per ogni volta che vedo questo ...)
Si consiglia inoltre di mantenere tempdb lontano dai file di registro. La tenda del ragazzo SAN a guardarti intorno quando inizi a desiderare "secchi diversi" (termine tecnico) per registri, dati e temp, ma se dici loro che è così puoi misurare la diversa quantità di dati IO andando in ogni area e convincili a mostrarti i loro fantastici grafici delle prestazioni!
Basta ricontrollare / ricontrollare che il ragazzo della SAN lo abbia impostato per te. Se si desidera RAID 10, insistere su di esso (l'ho fatto) anche se continuavano a dire che il loro RAID 5 non ha penalità per le prestazioni.
(Per operazioni "basate su file", RAID 5 va bene. Per le scritture intensive, non appena si riempie il buffer di scrittura, si è fregato!)
Siate consapevoli di tutte le combinazioni di termini qui pure ..
In generale, e molto semplice:
Puoi avere diversi volumi sullo stesso array, che è qualcosa da ricordare quando stai facendo ottimizzazioni di alto livello discusse in questo thread.
La chiave è ciò che molti altri hanno menzionato (non dimenticarlo), separare i dati / registro / backup su diversi mandrini di unità, non solo volumi separati.
Modifica: e Helvick sopra ti ha dato una grande risposta sulle SAN Equallogiche!