Tempo Limite de Disco do Windows e Exchange Server 2010

Artigo original publicado na quinta-feira, 17 de novembro de 2011

Há alguns meses, Bruce Langworthy redigiu um excelente artigo relacionado a algumas novas recomendações para definir o valor de Tempo Limite de Disco do 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.

Essa postagem me fez pensar sobre o Exchange e como nós lidamos com problemas de I/O. Se você ainda não leu o artigo de Bruce, ele explica que o tempo limite de disco padrão de 60 segundos significa que o Windows não irá relatar o travamento de I/O por 60 segundos e não irá tentar executar o I/O novamente por 8 minutos. Oito minutos é muito tempo para aguardar antes de tentar executar um I/O travado novamente, portanto, a Microsoft está lançando novas orientações, recomendando a alteração da definição do Tempo Limite de Disco do Windows para um valor que esteja alinhado com sua arquitetura de armazenamento.

A dúvida em minha cabeça sobre o Exchange era simples, como este comportamento de tempo limite do disco afeta as implantações do DAG do Exchange; mais especificamente eu devo reduzir o Tempo Limite de Disco do Windows nos meus servidores Exchange de acordo com as novas recomendações ou deixar como está? ?

Para responder essa pergunta, eu abordei alguns de nossos desenvolvedores ESE para saber o que eles pensam... isso é o resultado da discussão…

• O valor de Tempo Limite de Disco do Windows é principalmente destinado para log de eventos e ou novas tentativas de I/O.
• Antes do Exchange Server 2010, o Exchange não realizava qualquer ação para I/O lento a não ser reportar no log de evento.
• O RTM do Exchange Server 2010 introduziu uma correção de página preemptiva (limpar substituição da página) para páginas afetadas pelo I/O lento.
• O Exchange Server 2010 SP1 é a primeira versão do Exchange a incluir inteligência para lidar com o travamento de I/O e irá interromper ativamente (verificação de bug) o servidor se o travamento de I/O estiver afetando os bancos de dados ativos em um nó do DAG.

Eu decidi que antes de podermos determinar o que fazer com nossas definições de tempo limite de disco, devemos entender o que a inteligência do Exchange Server 2010 SP1 introduziu e como pode interagir com tempos limites de disco.

Recuperação do mecanismo de armazenamento extensível em travamento IO do Exchange Server 2010 SP1

O Exchange Server 2010 SP1 trouxe algumas excelentes melhorias sobre como lidar com o travamento de I/O. Essas melhorias são discutidas em detalhes no seguinte artigo TechNet https://technet.microsoft.com/en-us/library/ff625233.aspx:

“O Exchange 2010 SP1 inclui uma nova lógica de recuperação que aproveita o comportamento de verificação de bug integrado do Windows quando ocorrem determinadas condições, especificamente quando ocorre o travamento de IO. No SP1, o Mecanismo de Armazenamento Extensível (ESE) foi atualizado para detectar travamentos de IO e para realizar ações corretivas para recuperar o servidor automaticamente. O ESE mantém um thread watchdog do IO, que detecta quando um IO está pendente por um período determinado de tempo. Por padrão, se um IO de um banco de dados está pendente por mais de um minuto, o ESE irá registrar um evento. Se um banco de dados possui um IO pendente por mais de 4 minutos, irá registrar um evento de falha específico, se for possível fazê-lo. O evento ESE 507, 508, 509 ou 510 pode ou não ser registrado, dependendo da natureza do travamento de IO. Se a natureza do problema é que o volume do SO é afetado ou a capacidade de gravar no log de evento é afetada, os eventos não serão registrados. Se os eventos são registrados, o serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) irá detectar esta condição e causar uma verificação de bug intencional do Windows encerrando o processo wininit.exe.”

Então, o que isso significa? Bem, após algumas discussões (e algumas pesquisas do código ESE), a seguinte tabela foi criada para tornar o comportamento mais fácil de compreender (eu incluí versões anteriores do Exchange para referência).

Observação: eu realmente desejo agradecer muito ao Alexandre Costa e a Brett Shirley, dois desenvolvedores de ESE na equipe do Exchange e sem os quais este informe não teria sido possível – obrigado, pessoal!

Observação: o I/O em andamento descreve uma operação de I/O lenta que não foi concluída com êxito. O I/O concluído representa um I/O lento que foi concluído, mas levou mais de 30 segundos. É importante observar aqui que, antes do Exchange Server 2010, não havia conceito para detectar I/O lentos em andamento, nós reportamos apenas uma vez que o I/O foi concluído.

Eu não gosto deste novo comportamento. O que posso fazer sobre isso?

Como a maioria das coisas, eu gostaria de aconselhar contra a mudança do novo comportamento a não ser que você tenha uma razão muito clara e convincente para fazer isso… No entanto, se você realmente precisa modificar um novo comportamento da Recuperação do mecanismo de armazenamento extensível no travamento de IO, existem algumas chaves de registro/atributos do Active Directory que permitem que você faça a mudança, o que está documentado aqui.

Conclusão

Se voltarmos para o motivo que me levou a redigir este artigo, era para avaliar se podíamos reduzir o Valor do Tempo Limite de Disco do Windows nos nós do servidor do DAG do Exchange, conforme recomendado aqui.

Após conversar com Matt Gossage da equipe do Exchange (Matt conhece tudo sobre o Exchange e o I/O), ele explicou que uma das coisas que o tempo limite de disco faz é proteger o host de tempestades de redefinição de barramento. Um dos efeitos colaterais interessantes quando um I/O atinge o Valor de Tempo Limite de Disco do Windows é que a unidade disk.sys irá emitir uma redefinição de barramento. Essa redefinição afeta todos os LUNs no servidor, não apenas o LUN que está falhando ao responder.

O cenário mais comum em que esse comportamento foi observado é com o Exchange 2010 e o armazenamento JBOD. Onde uma solução RAID é implantada, o controlador de disco pode lidar com leituras de blocos ruins lendo os dados de outro disco ou recalculando os dados de paridade. Isso atrasa o I/O, mas não significantemente. Com o JBOD, existe apenas uma única cópia do bloco de dados e, portanto, há a possibilidade de blocos ruins causarem um travamento de I/O enquanto aguardamos que o disco tente e leia os dados – resumindo, com uma implementação JBOD não queremos reduzir o Valor de Tempo Limite de disco e, de fato, podemos desejar até aumentá-lo para reduzir os efeitos de uma tempestade de redefinição de barramento se um dos eixos do disco JBOD começar a falhar.

A tabela a seguir destaca as recomendações para a definição do HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue para servidores que realizam o papel de caixa de correio do Exchange Server 2010.

Neil Johnson
Consultor Sênior, MCS Reino Unido

Esta é uma postagem do blog traduzida. Encontre o artigo original em Windows Disk Timeouts and Exchange Server 2010