Timeout del disco di Windows ed Exchange Server 2010
Articolo originale pubblicato giovedì 17 nov. 2011
Qualche mese fa Bruce Langworthy ha scritto un eccellente articolo riguardo alcuni nuovi consigli per l'impostazione del valore di timeout del disco di Windows: https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx.
Questo post mi ha indotto a riflettere su Exchange e su come trattiamo i problemi di I/O. Per chi non avesse letto l'articolo, in esso Bruce spiega che il valore predefinito di timeout del disco pari a 60 secondi implica che Windows non segnali l'interruzione di I/O per 60 secondi e non ritenti l'I/O per 8 minuti. Otto minuti è un tempo di attesa di gran lunga eccessivo prima di un nuovo tentativo di ripristinare un'interruzione di IO, così Microsoft sta rilasciando nuove istruzioni, consigliando di modificare l'impostazione del timeout del disco di Windows portandola su un valore adeguato alla propria architettura di archiviazione.
La domanda che mi ponevo riguardo a Exchange era semplice in che modo questo comportamento del timeout del disco influisce sulle distribuzioni di gruppi di disponibilità del database (DAG) di Exchange DAGe, più nello specifico, devo diminuire il valore di timeout del disco di Windows sui miei server Exchange in base ai nuovi consigli o devo lasciare le cose come stanno?
Per rispondere a questa domanda mi sono rivolto ad alcuni dei nostri sviluppatori ESE per avere la loro opinione… e questo è quanto è emerso da questi colloqui…
- Il valore di timeout del disco di Windows è finalizzato principalmente alla registrazione eventi e per i nuovi tentativi di I/O.
- Prima di Exchange Server 2010, Exchange non intraprendeva alcuna azione in caso di I/O lento oltre alla segnalazione nel registro eventi.
- Exchange Server 2010 RTM ha introdotto l'applicazione preventiva di patch delle pagine (sovrascrittura delle pagine pulite) per le pagine interessate da un I/O lento.
- Exchange Server 2010 SP1 è la prima versione di Exchange a includere un'intelligence per trattare le interruzioni di I/O ed esegue il controllo degli errori del server se l'interruzione di I/O interessa database attivi su un nodo DAG.
Ho deciso che per stabilire come procedere in merito all'impostazione di timeout del disco prima è necessario comprendere l'intelligence introdotta con Exchange Server 2010 SP1 e in che modo questa può interagire con i timeout del disco.
Ripristino di Exchange Server 2010 SP1 Estensibile Strage Angine per interruzioni di IO
Exchange Server 2010 SP1 ha introdotto alcuni interessanti miglioramenti per il modo in cui vengono trattate le interruzioni di I/O. Questi miglioramenti sono illustrati in dettaglio nel seguente articolo di TechNet https://technet.microsoft.com/en-US/librare/ff625233.aspx:
“Exchange 2010 SP1 include una nuova logica di ripristino che utilizza il comportamento predefinito di controllo degli errori di Windows quando si verificano alcune condizioni, in particolare quando si verifica un'interruzione di I/O. In SP1, Extensible Storage Engine (ESE) è stato aggiornato per rilevare le interruzioni di IO e intraprendere l'azione correttiva di ripristino automatico del server. ESE gestisce un thread del watchdog di I/O che rileva quando un I/O è rimasto in attesa per un periodo di tempo specifico. Per impostazione predefinita, se un I/O per un database è rimasto in attesa per oltre un minuto, ESE registra un evento. Se un I/O di un database resta in attesa per oltre 4 minuti, ESE registra un evento di errore specifico, qualora sia possibile. Gli eventi ESE 507, 508, 509 e 510 possono essere o non essere registrati a seconda della natura dell'interruzione di I/O. Se la natura del problema è tale per cui vengono interessati il volume del sistema operativo o la possibilità di scrittura nel registro eventi gli eventi non vengono registrati. Nel caso in cui gli eventi vengano registrati, il servizio Microsoft Exchange Replication (MSExchangeRepl.exe) rileva tale condizione e determina intenzionalmente un controllo degli errori di Windows terminando il processo wininit.exe.”
Che cosa significa quindi tutto questo? Beh, dopo alcune discussioni (e alcune ricerche del codice ESE), è stata creata la tabella seguente per agevolare la comprensione di questo comportamento (ho inserito le versioni precedenti di Exchange come riferimento).
Nota: desidero ringraziare sentitamente a questo punto Alexandre Costa e Brett Shirley, entrambi sviluppatori ESE del team di Exchange e senza i quali questo articolo non sarebbe stato possibile. Grazie ragazzi!!
|
Versione di Exchange |
Tipo di I/O |
Tempo di I/O |
Comportamento |
|
Exchange Server 2003 |
Completato |
>60 secondi |
|
|
Exchange Server 2007 |
Completato |
>60 secondi |
|
|
Exchange Server 2010 RTM |
Completato |
>60 secondi |
|
|
Exchange Server 2010 SP1 |
Al volo |
>60 secondi |
|
|
>4 minuti |
| ||
|
Completato |
>30 secondi |
|
Nota: la dicitura "I/O al volo" indica un'operazione di I/O lenta non completata correttamente. "I/O completato" indica un I/O lento che è stato completato, ma per il quale sono stati necessari oltre 30 secondi. È importante notare qui che prima di Exchange Server 2010 non esisteva il concetto di rilevare I/O lenti al volo, ma veniva solo segnalato il completamento dell'I/O una volta avvenuto.
Non mi piace questo nuovo comportamento, in che modo posso procedere?
Come per la maggior parte delle cose, il mio consiglio è di non modificare il nuovo comportamento a meno di avere individuato un motivo convincente per farlo… Tuttavia, se è proprio necessario il nuovo comportamento di ripristino di Storage Engine Recovery per interruzioni di I/O, esistono alcune chiavi di registro/attributi di Active Directory che consentono di eseguire queste modifiche e sono documentati qui.
Conclusione
Tornando al motivo per cui ho deciso di scrivere questo articolo, si trattava di stabilire se sia opportuno diminuire il valore di timeout del disco di Windows sui nodi dei server dei DAG di Exchange come consigliato qui.
Dopo avere parlato con Matt Gossage del team di Exchange (Matt sa tutto su Exchange e I/O), mi ha spiegato che una delle funzioni del timeout del disco è proteggere l'host dagli storm di reimpostazione del bus. Uno degli effetti collaterali interessanti quando un I/O raggiunge il valore di timeout del disco di Windows è il fatto che il driver disk.sys dà luogo a una reimpostazione del bus, che interessa tutti i LUN sul server, non solo il LUN che non risponde.
Lo scenario più comune in cui è stato osservato questo comportamento riguarda Exchange 2010 e l'archiviazione JBOD. Nel caso in cui sia distribuita una soluzione RAID, il controller del disco è in grado di gestire letture errate del blocco leggendo i dati da un altro disco o ricalcolando i dati dalla parità. Questo rallenta l'I/O, ma non in misura significativa. Con JBOD esiste una sola copia del blocco di dati, quindi esiste la possibilità che un blocco errato causi un'interruzione di I/O mentre si attende che il disco tenti di leggere i dati. La conclusione è quindi che con una distribuzione JBOD non è opportuno diminuire il valore di timeout del disco e che anzi potrebbe anche essere necessario aumentarlo per ridurre gli effetti di uno storm di reimpostazione del bus nel caso in cui uno degli spindle del disco JBOD disk inizino a presentare errori.
Nella tabella che segue sono riportate le operazioni consigliate per l'impostazione di HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue per i server che eseguono il ruolo di cassetta postale di Exchange Server 2010.
| Scenario | Operazione consigliata |
| Matrice di archiviazione diretta |
|
| Archiviazione RAID su SAN |
|
| Archiviazione JBOD |
|
Neil Johnson
Senior Consultant, UK MCS
Questo è un post di blog localizzato. L'articolo originale è disponibile inWindows Disk Timeouts and Exchange Server 2010