Perché un'applicazione a uso intensivo di disco dovrebbe essere eseguita più velocemente su una SAN che su un disco fisico?


21

Perché un'applicazione a uso intensivo di disco dovrebbe essere eseguita più velocemente su una SAN che su un disco fisico? Mi sarei aspettato che il disco fisico fosse leggermente più veloce, ma in realtà il processo è stato eseguito 100 volte più veloce quando l'unità di lavoro è stata impostata su una partizione sulla SAN.

La nostra ipotesi è che la SAN sia ottimizzata per essere veloce, mentre le impostazioni di ottimizzazione del disco fisico sono legate al sistema operativo (Solaris) e non sono state toccate o il sistema operativo è stato patchato.

Durante l'attività più elevata, l'I / O del disco era in esecuzione al 100% e il tempo necessario per completare una scrittura era di oltre 2 secondi poiché diversi processi scrivevano contemporaneamente sul disco.

(A proposito dell'applicazione in questione era Informatica PowerCenter)

Risposte:


23

Non sono affatto sorpreso. Gli array SAN in genere hanno MOLTO dischi coinvolti. Il fattore limitante per l'I / O del disco è la velocità del singolo disco e questi stack. 6 unità localmente in un RAID10 funzioneranno meglio di 2 e 80 unità su una SAN funzioneranno meglio di 10 unità localmente. Naturalmente ci sono variabili, ma è così che dovrebbe funzionare.

Inoltre, se la SAN ha degli SSD coinvolti, le cose diventano davvero scattanti.


15

È quasi certamente dovuto alla memorizzazione nella cache. Il probabile DAS ha una cache minima, in cui la maggior parte delle SAN Enterprise hanno più gigabyte di cache. Immagino che l'app stia saturando la cache del DAS, ma non quella della SAN.


1
L'evidente latenza sulla SAN sta andando più a lungo della DAS ma la velocità complessiva è più elevata sulla SAN con tutta la sua memorizzazione nella cache. Buona risposta.
Matt

e poi c'è spesso una cache di lettura anticipata, quindi le sue letture / scritture casuali hanno il maggior successo e quindi puoi scrivere nella cache in modo che le sue uniche letture casuali vengano influenzate, comunque un ritardo piuttosto piccolo.
Silverfire,

1
Un sottosistema di archiviazione correttamente configurato sulla SAN che non sia sovraccaricato dovrebbe fornire tempi di scrittura casuali intorno a 1-2 ms.
MikeyB,

@MikeyB Non sono in disaccordo con te. 1-2ms scrivere su SAN sembra giusto. Ma la configurazione SAN di Charles era 100 volte più veloce dei suoi dischi fisici sovraccarichi (le scritture erano> 2sec per quest'ultimo). Quindi anche le sue prestazioni SAN non sono così buone, a 20ms anziché a 1-2ms ...?
Ellie Kesselman,

9

Concettualmente sembra sempre che servire il disco da SAN dovrebbe essere più lento che servirlo localmente. Tuttavia, ci sono molti fattori che possono invertire questa situazione e rendere la SAN un'opzione molto più veloce. Alcuni di questi fattori sono:

  • Il tuo carico di lavoro richiede tempi di ricerca rapidi o velocità effettiva elevata o entrambi?
  • Quanti mandrini su SAN LUN rispetto al disco locale?
  • Quale velocità del bus tra SAN LUN e il server rispetto all'interfaccia del disco locale?
  • Quanta cache di lettura / scrittura è disponibile sul SAN LUN rispetto al disco locale?
  • A quale velocità girano i dischi sul SAN LUN rispetto al disco locale?
  • Quali altre attività di I / O si svolgono sul SAN LUN rispetto al disco locale?
  • A quale livello RAID sono gli array sulla SAN e sulla memoria locale?

Tutto ciò influirà sulle prestazioni su SAN e disco locale.


1

Tutto dipende da quanti mandrini sono disponibili .... Maggiore è il numero di mandrini più veloce è accedere a un dato dato. se si utilizza intensamente l'IO, in particolare se si è un'app di database, è possibile seppellire abbastanza facilmente le prestazioni del disco locale con una soluzione SAN che può avere un numero molto più elevato di set di dischi per la gestione di dati core, indici e simili.

Con il sottosistema del disco locale è anche probabile che tu condivida l'accesso alle testine di lettura / scrittura con altre operazioni, come r / w per scambiare, accesso al file locale del sistema operativo e della libreria, accesso all'applicazione, ecc. Mentre sei veloce individualmente, il tempo collettivo perché tutte le azioni di lettura / scrittura per spostare le testine di lettura / scrittura da un'area del disco in modo da coprire una serie di azioni in un'altra per soddisfare i requisiti della tua applicazione, possono sicuramente battere sulle prestazioni.

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.