Non prestare attenzione a quella SAN dietro il sipario

Una volta, ho creato i miei server SQL e ho avuto il controllo sulla configurazione dell'unità, sui livelli RAID, ecc. Il tradizionale consiglio di separazione di dati, registri, tempdb, backup (a seconda del budget!) È sempre stato una parte piuttosto importante del processo di progettazione del server SQL.

Ora con una SAN a livello aziendale, richiedo solo una quantità specifica di spazio su disco per un nuovo server SQL, diviso in unità logiche per dati, backup e condivisioni di file. Certamente rende il mio lavoro più semplice, ma c'è una parte di me che non si sente completamente a mio agio che non riesco davvero a sbirciare "dietro il sipario" per vedere cosa sta realmente succedendo lì dietro.

La mia comprensione è che il team SAN non configura diversi "tipi" di unità in modo diverso (ottimizzazione delle unità dati per l'accesso casuale rispetto alle unità log per le scritture in streaming). Alcuni di questi possono dipendere dal prodotto SAN stesso (abbiamo un HP XP12000 e un HP XP24000), ma mi è stato assicurato che il software HP esegue tutti i tipi di configurazione dinamica delle prestazioni (controllando gli hotspot IO e riconfigurando al volo per ottimizzare quei LUN), in modo che i team di app e i DBA non debbano preoccuparsi di nessuna di queste cose. Qualcosa sul "distribuire il carico di tutti i server su un numero enorme di mandrini" o qualcosa del genere.

Le mie domande / discussione:

1. Senza fare nemici nel team SAN, come posso rassicurare me stesso e gli sviluppatori di applicazioni che i nostri server SQL non soffrono di memoria configurata male? Usa solo le statistiche perfmon? Altri parametri di riferimento come sqlio?

2. Se carico test su queste unità SAN, ciò mi dà davvero una misura affidabile e ripetibile di ciò che vedrò quando andremo in diretta? (supponendo che il software SAN possa "configurare dinamicamente" in modo diverso in diversi momenti nel tempo.)

3. L'IO pesante in una parte della SAN (ad esempio il server Exchange) influisce sui miei server SQL? (supponendo che non stiano dando dischi dedicati a ciascun server, cosa che mi è stato detto che non lo sono)

4. La richiesta di separare le unità logiche per diverse funzioni unità logiche (dati vs log vs tempdb) sarebbe di aiuto in questo caso? La SAN vedrebbe le diverse attività IO su queste e le configurerebbe in modo ottimale in modo diverso?

5. In questo momento ci troviamo in una crisi di spazio. Ai team delle applicazioni viene chiesto di tagliare gli archivi di dati, ecc. Le preoccupazioni di spazio causerebbero il team SAN a prendere decisioni diverse su come configurare la memoria interna (livelli RAID, ecc.) Che potrebbero influire sulle prestazioni del mio server?

Grazie per i tuoi pensieri (argomento simile brevemente discusso in questa domanda SF )

Senza fare nemici nel team SAN, come posso rassicurare me stesso e gli sviluppatori di applicazioni che i nostri server SQL non soffrono di memoria configurata male? Usa solo le statistiche perfmon? Altri parametri di riferimento come sqlio?

In breve, probabilmente non c'è modo di esserne veramente sicuri. Quello che direi (sono un amministratore della SAN) è che se le tue applicazioni soddisfano le tue aspettative, non preoccuparti. Se si iniziano a vedere problemi di prestazioni che si ritiene possano essere correlati alle prestazioni di SAN / Disk IO, è consigliabile informarsi. Non uso molto spazio di archiviazione HP come te, ma nel mondo IBM / NetApp posso dire per esperienza che non ci sono molte opzioni che ti permetterebbero di configurarlo "male". La maggior parte dello storage aziendale in questi giorni richiede molte congetture per la costruzione di array di incursioni e non ti fa davvero sbagliare. A meno che non stiano mescolando velocità e capacità dell'unità all'interno degli stessi gruppi di raid, nella maggior parte dei casi puoi essere certo che il tuo disco sta andando bene.

Se carico test su queste unità SAN, ciò mi dà davvero una misura affidabile e ripetibile di ciò che vedrò quando andremo in diretta? (supponendo che il software SAN possa "configurare dinamicamente" in modo diverso in diversi momenti nel tempo.)

I test di carico dovrebbero essere molto affidabili. Basta tenere presente che quando si carica il test di una casella, quella su un array SAN / Disk condiviso che le sue prestazioni possono (e saranno) influenzate da altri sistemi che utilizzano lo stesso storage.

L'IO pesante in una parte della SAN (ad esempio il server Exchange) influisce sui miei server SQL? (supponendo che non stiano dando dischi dedicati a ciascun server, cosa che mi è stato detto che non lo sono)

Può. Non si tratta solo dei dischi o dei dischi su cui si trovano i server. Tutti i dati vengono offerti tramite un controller del disco e quindi uno switch SAN. Le prestazioni che vedrai dipendono in gran parte dal modo in cui il controller del disco è collegato ai corrispondenti shelf di dischi e alla SAN corrispondente. Se l'intero array si connette alla SAN backbone su un singolo filamento di fibra da 4 gbps, le prestazioni ne risentiranno chiaramente. Se l'array è collegato attraverso due SAN ridondanti che sono bilanciate in base al carico, utilizzando collegamenti trunked, sarebbe impossibile per il solo scambio risucchiare troppa larghezza di banda. Un'altra cosa che deve essere considerata è la quantità di IO / sec dell'array. Fintanto che l'array e la SAN a cui è connesso vengono ridimensionati correttamente,

La richiesta di separare le unità logiche per diverse funzioni unità logiche (dati vs log vs tempdb) sarebbe di aiuto in questo caso? La SAN vedrebbe le diverse attività IO su queste e le configurerebbe in modo ottimale in modo diverso?

Questa è probabilmente una questione di preferenza, e dipende anche in gran parte dalla configurazione degli amministratori di archiviazione. Potrebbero darti tre LUN nello stesso array o volume, nel qual caso è comunque lo stesso. Se ti fornissero LUN individuali su array diversi, in volumi diversi (dischi fisicamente diversi), potrebbe valerne la pena separarli.

In questo momento ci troviamo in una crisi di spazio. Ai team delle applicazioni viene chiesto di tagliare gli archivi di dati, ecc. Le preoccupazioni di spazio causerebbero il team SAN a prendere decisioni diverse su come configurare la memoria interna (livelli RAID, ecc.) Che potrebbero influire sulle prestazioni del mio server?

Non immagino che il tuo amministratore di archiviazione cambierebbe il livello del raid per liberare spazio. Se lo facesse, probabilmente dovrebbe essere licenziato. Le preoccupazioni di spazio possono portare a una configurazione diversa delle cose, ma normalmente non in modo tale da influire sulle prestazioni. Potrebbero solo diventare un po 'più stretti su quanto spazio ti danno. Potrebbero abilitare funzioni come la deduplicazione dei dati (se l'array lo supporta) che possono ostacolare le prestazioni dell'array durante l'esecuzione del processo, ma non tutto il giorno.

Il team SAN dovrebbe disporre di strumenti che possono aiutarti a rivelare se la tua app è in hot spot. Ovviamente, dovresti monitorare e misurare anche dalla tua parte.

La maggior parte della mia esperienza è con EMC, quindi YMMV. Ma quanto segue dovrebbe applicarsi alla maggior parte delle apparecchiature SAN.

Esistono solo così tante porte nell'array. A volte è presente un interruttore SAN tra cui è possibile definire le zone. Solo perché l'array è essenzialmente un grande pool di archiviazione non significa che non dovresti preoccuparti delle prestazioni di I / O.

Quindi, se ritieni di avere problemi di I / O, devi restringere il punto in cui si trova il collo di bottiglia. Se si trova a metà strada tra l'HBA e l'array, è quindi possibile capire se l'HBA è al massimo o se la porta SAN sul lato switch / array è sovrascritta. Inoltre, è necessario che il team SAN controlli i modelli di accesso per l'app, sia a partire da un avvio a freddo che a caldo.

Ovviamente, l'archiviazione sottostante fa la differenza se esegui RAID5 lento lento rispetto a RAID10 veloce poiché a un certo punto dovrai colpire il disco indipendentemente dai diversi livelli di cache.

HTH. Puoi eseguire il ping offline se hai un problema specifico in quanto ciò potrebbe richiedere del tempo per scavare.

Senza fare nemici nel team SAN, come posso rassicurare me stesso e gli sviluppatori di applicazioni che i nostri server SQL non soffrono di memoria configurata male? Usa solo le statistiche perfmon? Altri parametri di riferimento come sqlio?

La prima cosa che devi sapere prima di eseguire qualsiasi tipo di benchmarking è in quale tolleranza deve essere eseguito il tuo carico di lavoro. Quindi confronta le tue cose prima di provare il nuovo sistema. In questo modo se scopri che stai spingendo un massimo di, diciamo, 56 MB / s durante i carichi di picco (backup?), Scoprendo che l'array di dischi collegato alla SAN "solo" spinge 110 MB / s sotto carichi di picco simulati, puoi essere ha assicurato che il limite non sarà il canale I / O.

Durante il check out di un nuovo disk array ho eseguito questo tipo di test delle prestazioni. Il nuovo array utilizzava unità SATA anziché unità Fibre Channel (SCSI) e avevo bisogno di assicurarmi che avrebbe funzionato nel nostro ambiente. Ero profondamente dubbioso. Ma dopo la caratterizzazione, ho scoperto che il nuovo sistema aveva abbastanza sovraccarico di I / O sotto il picco per tenere il passo con il picco misurato sui dischi più affidabili. Mi ha sorpreso

Se carico test su queste unità SAN, ciò mi dà davvero una misura affidabile e ripetibile di ciò che vedrò quando andremo in diretta? (supponendo che il software SAN possa "configurare dinamicamente" in modo diverso in diversi momenti nel tempo.)

A causa della natura condivisa degli array di dischi collegati alla SAN, le prestazioni sono variabili durante la settimana. Se sai già quando è il carico di I / O di picco, esegui una serie di test di carico durante l'ora del giorno in cui è il carico di I / O di picco. In questo modo puoi caratterizzare meglio il tipo di overhead I / O disponibile nei periodi a cui sei maggiormente interessato. I test di carico durante le ore non di punta ti daranno un'idea di come andranno le cose "scattanti", ma i test di picco lo faranno ti dà il vero controllo dei limiti.

L'IO pesante in una parte della SAN (ad esempio il server Exchange) influisce sui miei server SQL? (supponendo che non stiano dando dischi dedicati a ciascun server, cosa che mi è stato detto che non lo sono)

Se i LUN di Exchange condividono i dischi con i tuoi LUN SQL, lo faranno assolutamente. Utilizziamo HP EVA, non XP, ma penso che utilizzino la stessa terminologia del "gruppo di dischi". I LUN nello stesso gruppo di dischi condividono i dischi e quindi contendono l'I / O su quei dispositivi fisici. Più dischi si inseriscono in un gruppo di dischi, più spazio di manovra l'array deve manipolare l'I / O. Gli array (almeno gli EVA fanno questo, e presumo che gli XP più costosi facciano lo stesso) distribuiscono blocchi LUN logici sui dischi fisici in modo non sequenziale. Ciò consente di eseguire ciò che viene suggerito, ovvero distribuire dinamicamente gruppi di blocchi a cui si accede frequentemente a diversi dispositivi fisici per aumentare il parallelismo e ridurre la contesa di I / O a livello del disco.

La domanda da porsi è la quantità di budget I / O di quel gruppo di dischi e se le applicazioni che utilizzano tali LUN sono state sottoscritte in eccesso per l'I / O. Questa è una domanda che gli amministratori di archiviazione dovranno tenere traccia. È possibile che l'I / O di picco per Exchange (probabilmente durante i backup) non coincida con i carichi SQL ed entrambi i sistemi possano coesistere felicemente.

La richiesta di separare le unità logiche per diverse funzioni unità logiche (dati vs log vs tempdb) sarebbe di aiuto in questo caso? La SAN vedrebbe le diverse attività IO su queste e le configurerebbe in modo ottimale in modo diverso?

Per gli array HP, è necessario inserire i diversi pattern I / O in diversi gruppi di dischi , non LUN. I modelli di I / O del database non dovrebbero coesistere con i modelli di accesso al servizio web, ad esempio. LUN diversi non migliorano notevolmente le prestazioni a meno che non si trovino in gruppi di dischi diversi. Se fanno parte dello stesso gruppo di dischi, l'unico vero vantaggio è il sistema operativo, in cui può eseguire la pianificazione degli I / O nel kernel per migliorare il parallelismo con il sottosistema del disco. Detto ciò...

Gli array HP, a mio avviso, sono comunque consapevoli dei diversi modelli di accesso ai LUN, ma prestano molta attenzione ai blocchi logici reali. Inserendo i log in un LUN diverso si pone un limite sui blocchi logici che otterranno quel tipo di traffico I / O e che faciliterà il compito di ordinare correttamente i blocchi logici sui dischi fisici.

In questo momento ci troviamo in una crisi di spazio. Ai team delle applicazioni viene chiesto di tagliare gli archivi di dati, ecc. Le preoccupazioni di spazio causerebbero il team SAN a prendere decisioni diverse su come configurare la memoria interna (livelli RAID, ecc.) Che potrebbero influire sulle prestazioni del mio server?

Decisamente. Se lo spazio è limitato, non otterrai gruppi di dischi dedicati per il tuo I / O (a meno che l'ambiente di archiviazione non sia abbastanza grande da giustificare la dedicazione di 7 TB di disco fisico per il tuo uso esclusivo, a quel punto potrebbe essere il caso ). Il dibattito Raid5 / Raid10 dipende in gran parte dalle politiche dell'organizzazione e chiedere è la soluzione migliore.

Ti suggerisco di aprire una finestra di dialogo con il tuo team SAN e il fornitore per rispondere alle tue preoccupazioni. Uno dei problemi che avrai con l'esecuzione dei tuoi parametri di riferimento è che i tuoi test potrebbero non avere attinenza con ciò che accade nella produzione, in particolare ai carichi di punta. La maggior parte delle SAN ha tonnellate di cache supportata da batteria, che in molti casi (in particolare quando si eseguono benchmark sintetici) significa che si sta scrivendo su RAM e si ottengono prestazioni eccezionali.

A seconda del proprio ambiente e della soluzione che si sta utilizzando, alcuni fornitori CE potrebbero essere appena arrivati ​​e impostare la SAN su qualsiasi standard preferisca. Succede più di quanto pensi. Dovrai scartare la shell "il team SAN sa tutto" fino a quando non avrai la certezza che la soluzione soddisfi le tue esigenze.

In bocca al lupo.

Una volta ero a una conferenza sull'oracolo con un discorso su questo argomento - SAN sana per i database.

Gist of the talk è disponibile in questo file PDF o sul sito degli autori qui