Disegno del disco di SQL Server su una ISCSI SAN

La sua pratica standard è quella di separare i file di log e dati per separare i dischi dal sistema operativo (tempdb, backup e file di swap anche). Questa logica ha ancora senso quando le unità sono tutte basate su SAN e le tue LUNS non sono intagliate da specifici dischi o raid – sono solo una parte del numero di unità x della SAN e il LUN è solo l'allocazione dello spazio

7 Solutions collect form web for “Disegno del disco di SQL Server su una ISCSI SAN”

I registri e le unità di dati dispongono di diversi templates di accesso ai dati che sono in conflitto tra loro (alless in teoria) quando condividono un'unità.

Scrive il registro

L'accesso al registro è costituito da un numero molto elevato di piccole scritture sequenziali. In un certo senso, i log DB sono anelli di anello contenenti un elenco di istruzioni per scrivere elementi di dati in luoghi particolari sul disco. Il model di accesso consiste in un gran numero di piccole scritture sequenziali che devono essere garantite per completare – per cui sono scritte su disco.

Idealmente, i registri dovrebbero essere su un volume RAID-1 o RAID-10 silenzioso (cioè non condiviso con altro). In modo logico, è ansible visualizzare il process come le principali voci di registro di DBMS e uno o più thread di lettori di log che consumano i registri e le modifiche apportte ai dischi di dati (in pratica il process è ottimizzato in modo che i dati siano scritti fuori where ansible). Se c'è un altro traffico nei dischi di registro, le teste vengono spostate da questi altri accessi e le scritture di registro sequenziale diventano scrive casuali di registro. Questi sono molto più lenti, così i dischi di log occupati possono creare un hotspot che funge da collo di bottiglia su tutto il sistema.

Scrittura dei dati

(aggiornato) Le scritture di registro devono essere impegnate sul disco (indicato come supporti stabili) per una transazione valida e ammissibile a impegnarsi. Si può logicamente considerare che le voci di registro vengono scritte e quindi utilizzate come istruzioni per scrivere le pagine di dati sul disco mediante un process asincrono. In pratica, le scritture di una pagina disco sono effettivamente preparate e tamponate al momento della creazione del registro, ma non devono essere scritte immediatamente affinché la transazione venga commessa. I buffer del disco vengono scritti su un supporto stabile (disco) dal process di Lazy Writer (grazie a Paul Randal per indicarlo) che questo articolo di Technet discute in un po 'più in dettaglio.

Questo è un model di accesso fortemente random, quindi condividere gli stessi dischi fisici con i registri può creare un collo di bottiglia artificiale sulle performance del sistema. Le voci di registro devono essere scritte affinché la transazione venga commessa, per cui avendo un tentativo random di rallentare questo process (l'I / O random è molto più lento rispetto all'account I / O di sequenza), il registro verrà trasformato da un sequenziale in un dispositivo di accesso random. Ciò crea un gravi bottleneck di performance su un sistema occupato e dovrebbe essere evitato. Lo stesso vale per la condivisione di aree temporanee con i volumi di log.

Il ruolo della cache

I controllori SAN tendono ad avere grandi cache RAM, che possono assorbire il traffico di accesso random in una certa misura. Tuttavia, per l'integrità transazionale è auspicabile disporre di un disco da un DBMS garantito per essere completato. Quando un controller è impostato per utilizzare la memorizzazione nella cache di scrittura, i blocchi sporchi vengono memorizzati nella cache e la chiamata di I / O viene riportta come completa all'host.

Questo può rendere omogenei molti problemi di contesa poiché la cache può assorbire un sacco di I / O che altrimenti wheresse andare al disco fisico. Può anche ottimizzare la lettura e la scrittura di parità per RAID-5, che riduce l'effetto sulle performance che i volumi RAID-5 hanno.

Queste sono le caratteristiche che guidano la scuola di "Let the SAN deal it", anche se questa visione ha alcune limitazioni:

  • La memorizzazione nella cache di scrittura ha ancora modi di errore in grado di perdere dati e il controller è entrato nel DBMS, dicendo che i blocchi sono stati scritti su disco, in realtà non lo hanno fatto. Per questo motivo, non si desidera utilizzare la memorizzazione nella cache di scrittura 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 I / O in una modalità in cui una bandiera (chiamata FUA o Forced Update Access) impone la scrittura fisica sul disco prima che la chiamata restituisca. Microsoft ha un programma di certificazione e molti produttori SAN producono hardware che onorano queste semantiche (requisiti qui riassunti). In questo caso nessuna quantità di cache ottimizza le scritture del disco, il che significa che il traffico di registro trionferà se è seduto su un volume condiviso occupato.

  • Se l'applicazione genera un sacco di traffico su disco, il set di lavoro potrebbe sovrascrivere la cache, che causerà anche problemi di contestazione.

  • Se la SAN viene condivisa con altre applicazioni (in particolare sullo stesso volume di disco), il traffico da altre applicazioni può generare bottleneck del log.

  • Alcune applicazioni (ad es. Magazzini di dati) generano grandi picchi di carico transitori che li rendono piuttosto anti-sociali sulle SAN.

Anche su un grande volume di registro separato SAN sono ancora consigliati. Puoi allontanarsi da non preoccuparti del layout su un'applicazione leggermente usata. Su applicazioni veramente grandi, puoi anche beneficiare di diversi controller SAN. Oracle pubblica una serie di case case di layout di data warehouse in cui alcune delle configurazioni più grandi coinvolgono più controllori.

Metta la responsabilità per le performance in cui appartiene

Su qualcosa con grandi volumi o where le performance potrebbero essere un problema, rendere il team SAN responsabile per l'esecuzione dell'applicazione. Se dovranno ignorare le tue raccomandazioni per la configuration, assicurati che la gestione sia a conoscenza di questa e che la responsabilità per le performance del sistema si trova nel luogo appropriato. In particolare, definire le linee guida accettabili per le statistiche principali delle performance del DB come le uscite di I / O o le pagine di block delle pagine o le applicazioni SLA di I / O accettabili.

Si noti che la responsabilità per la divisione delle performance in più squadre crea un incentivo al punto dito e passa il buck all'altra squadra. Questo è un anti-pattern di gestione noto e una formula per problemi che trascinano per mesi o anni senza mai essere risolti. Idealmente, dovrebbe essere un singolo architetto con l'autorità per specificare le applicazioni, il database e le modifiche alla configuration SAN.

Inoltre, benchmark il sistema sotto carico. Se è ansible organizzarlo, i server secondari e gli arrays diretti possono essere acquistati abbastanza a buon mercato su Ebay. Se si imposta una casella come questa con uno o due arrays di dischi è ansible eseguire la configuration del disco fisico e misurare l'effetto sulle performance.

Ad esempio, ho fatto un confronto tra un'applicazione in esecuzione su una grande SAN (uno Shark IBM) e una casella a due socket con un arrays diretto U320. In questo caso, un valore di £ 3.000 di hardware acquistato off ebay ha superato una SAN da £ 1M di fascia alta di due fattori – in un host con configuration equivalente di CPU e memory.

Da questo particolare incidente, si potrebbe sostenere che avere qualcosa di simile in giro è un ottimo modo per mantenere gli amministratori SAN onesti.

Suppongo che il tag Equalogic e il contenuto della richiesta significa che stai allenando su una SAN Equalogica. Quello che segue è specificamente riguardo a Equallogic e non si applica ad altri tipi di SAN.

Con gli arrays di Equalogic, i dischi specifici utilizzati per i volumi non possono essere specificati con precisione come possono, ad esempio, arrays EMC Clariion, per cui l'approccio deve essere un po 'diverso.

L'architettura equallogica è molto automatizzata e dynamic. Il relativo elemento di base è l'unità di matrix non RAID pack \ gruppi all'interno di un arrays come si vede in altre SAN. Ogni arrays è interamente configurata per RAID 5, 6, 10 o 50, anche se ciò non implica che esista un solo gruppo RAID per arrays, non potrai mai decidere o interagire con loro a quel livello. Inserisci gli arrays in Pool di archiviazione e le tue piscine appartengono a un gruppo di archiviazione. Il gruppo di archiviazione dispone di un cluster \ indirizzo IP virtuale che utilizzi come objective iSCSI Discovery per tutti i volumi di quel gruppo: il software di gestione del gruppo EQL e lo stack MPIO host gestiscono il redirection del livello ip necessario per effettivamente percorrere la port più appropriata i singoli arrays durante la richiesta di blocchi di dati, ma questo è qualcosa che hai poca o nessuna capacità di controllare.

I volumi di archiviazione vengono assegnati dallo spazio libero totale in each pool. Tutti i volumi all'interno di una piscina sono distribuiti su tutti gli arrays di quel pool (fino ad un massimo di 4 arrays separati) per distribuire IO di networking per il numero totale di interfacce di networking (2-4 per arrays Eql a seconda del model) e IO attraverso quanti più controllori ansible. Il software di gestione Equalogic monitora le performance del volume \ arrays nel tempo e ottimizza in modo dinamico la distribuzione di blocchi attraverso gli arrays dei membri. In generale, a less che non sappia cosa stai facendo, dovresti mettere tutti gli arrays in una singola piscina e lasciare che fare la sua cosa, basta ricordarsi di configurare i tuoi dischi ad alta velocità (SAS 10k \ 15k) con RAID 10, velocità media con RAID 50 o 5 per assicurare che il process di ottimizzazione in realtà sceglie le unità reali ad alte performance. Può impiegare parecchi giorni (7+) per arrivare ad uno stato ottimale ma in generale dovrebbe colpire una distribuzione equilibrata, poiché distribuisce immediatamente i volumi su tante matrici (fino a 4) quando sono inizialmente creato.

A una approssimazione approssimativa avrai da qualche parte tra 2500-5000 IOP per arrays PS a seconda del tipo di drive e del tipo RAID. Se si fornisce un numero sufficiente di IOP, allora il process di gestione automatizzato dovrebbe darti una buona prestazione anche se semplicemente affina tutti i volumi in una singola piscina.

Tuttavia, se si desidera garantire che i tuoi registri, database, negozi di temp, drive OS ecc sono effettivamente isolati gli uni dagli altri si può fare un paio di cose. In primo luogo è ansible definire una preferenza RAID per un volume che garantisca che il volume specifico sia sempre memorizzato solo su arrays di quel tipo RAID (se sono presenti nel pool di cui il volume appartiene). In secondo luogo è ansible definire pool di archiviazione tiered che contengono solo arrays che offrono i vari gradi di performance necessari per quel particolare livello e quindi distribuire i tuoi volumi nelle piscine appropriate. L'avvertimento sulla salute che viene fornito con questo approccio è che in genere è necessario disporre di un sacco di arrays per fornire performance migliori in termini generali – che può essere less importnte di quello che garantisce le performance dei volumi critici anche se spesso è ancora la migliore scelta. L'architettura di riferimento di Dell per Oracle DB utilizza una piscina con due arrays RAID 10 per Data, disco di voto e OCR e una piscina separata con un singolo arrays RAID 5 per l'Area di ripristino di Flash.

In tutti i punti di tempo con Equalogic si dovrebbe chiedersi se le decisioni che si stanno facendo in materia di partizionamento forzato stanno per fornire migliori performance aggregate per i tuoi volumi in termini di interfacce di networking disponibili, mandrini e controllori. Se non potete rispondere, scegliete quindi il numero minimo di piscine e lasciate che gestisca i dettagli o ottenga uno specialist Equalogico per fare un disegno reale. Se hai solo una matrix, non puoi fare nulla in termini di separazione dei volumi.

Memorizziamo i nostri DB in singole caselle SAN, ma con dati separati, log e backup LUNs, ognuno dei diversi gruppi di dischetti, in ordine di velocità – con i nostri log su RAID 10 15Krpm LUN, dati su RAID 1 10 / 15krpm LUNs e backup su RAID 5 7.2krpm LUN. Inoltre presentiamo registri e dati tramite diversi controller sulla stessa SAN.

Grande domanda!

Primo uno sguardo al dibattito di Brent Ozar sul "Steel Cage BlogMatch" su questo tema.

Nella nostra azienda, per la maggior parte dei server, mettiamo dati e registri sulla stessa unità SAN e lo lasciamo al team SAN per assicurarci che tutto funzioni correttamente.

Sto cominciando a pensare che questa non è la migliore strategia, soprattutto per i server di volume superiore. Il problema sottostante è che non ho veramente modo di verificare che il team SAN sta realmente facendo qualcosa di più che schiaffeggiare unità sufficienti per lo spazio necessario. Non eseguiamo i benchmark IO contro gli azionamenti SAN da parte nostra, o qualsiasi altra cosa, pnetworkingndiamo semplicemente che stiamo facendo il loro lavoro (aggiustamento per performance e spazio), probabilmente un po 'ingenuo.

Il mio altro pensiero è che il tipo di accesso che i dati rispetto ai registri hanno bisogno è diverso. Cercherò di trovare l'articolo che ho letto di recente che stava parlando di come i due tipi di unità veramente verranno ottimizzati in modi molto diversi (credo che ci serviva un'ottimizzazione per le scritture sequenziali, l'altra necessaria ottimizzazione per le letture casuali, qualcosa di simile .)

Insum, si creerebbe volumi separati per i file di dati di SQL Server, i file di registro e i dati TempDB e i file di registro.

Dal momento che hai contrassegnato la tua domanda con Equallogic, leggere la guida gratuita di Dell Reference Architecture: Distribuire Microsoft® SQL Server® con arrays di storage di serie Dell ™ EqualLogic ™ PS5000 (logging richiesta) prima di progettare la soluzione. Spesso trovenetworking che le indicazioni sulle configurazioni specifiche possono differire in modo significativo dai consigli generici .

Concordo con BradC (+1) in termini di performance. Generalmente, una buona SAN avrebbe più I / O crudi di quanto si possa prevedere di utilizzare.

È ancora una buona idea separare i tuoi BACKUP dal tuo sistema live (ovviamente lo so, ma se avessi un £ per each volta che vedo questo …)

Inoltre, è consigliabile mantenere tempdb lontano dai file di registro. La tenda del ragazzo SAN per riavvolgere gli occhi quando si inizia a volere "secchi diversi" (termine tecnico) per i registri, i dati e il temp, ma se dite loro è così è ansible misurare la diversa quantità di dati IO in each area e convincerli a mostrarti i loro grafici di performance fantasiosi!

Basta controllare il doppio / doppio che il ragazzo SAN lo ha impostato proprio per te. Se si desidera RAID 10, insistere su di esso (ho fatto) anche se continuavano a dire che il loro RAID 5 non ha alcuna penalità sul rendimento.

(Per le operazioni "basate su file", RAID 5 va bene. Per le scritture intensive, non appena riempite il buffer di scrittura il tuo avvitato!)

Essere consapevoli di tutte le miscele di termini qui come bene ..

Generalmente e molto fondamentali:

  • Array = un pool di dischi in un'impostazione RAID (come RAID5)
  • Volume = una porzione di un arrays presentato all'host sulla SAN con un LUN

Puoi disporre di diversi volumi sulla stessa matrix, cosa da ricordare quando fai ottimizzazioni di alto livello discusse in questo thread.

La chiave è quella che molti altri hanno menzionato (non dimenticate), separa i dati / log / backup su diversi mandrini dell'unità, non solo volumi separati.

Edit: e Helvick sopra ha dato una risposta -Great su SAN Equalogic!

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.