Artigo original publicado no domingo, dia 20 de novembro de 2011

No início de agosto deste ano, a equipe do Windows SE liberou o artigo da Base de Dados de Conhecimento (KB) a seguir e o hotfix do software que acompanha sobre um problema nos clusters de failover do Windows Server 2008 R2:

KB2550886 - Uma falha de comunicação transitória faz com que um cluster de failover do Windows Server 2008 R2 pare de funcionar

Esse hotfix é altamente recomendado para todos os grupos de bancos de dados de disponibilidade que são alongados em múltiplos datacenters. Para DAGs que não são alongados em múltiplos datacenters, também é recomendável ter esse hotfix. O artigo descreve um problema de deadlock da condição de corrida e do banco de dados de cluster que pode ocorrer quando um cluster de failover do Windows encontra uma falha de comunicação transitória. Há uma condição de corrida na lógica de reconexão de nós de cluster que se manifesta quando o cluster tem falhas de comunicação. Quando isso ocorre, ele faz com que o banco de dados de cluster trave, resultando em perda de quórum do cluster de failover.

Conforme descrito no TechNet, um grupo de disponibilidade de banco de dados (DAG) depende da funcionalidade de cluster específica, incluindo o banco de dados de cluster. Para que um DAG seja capaz de funcionar e fornecer alta disponibilidade, o cluster e o banco de dados de cluster também devem estar funcionando corretamente.

A Microsoft encontrou cenários nos quais uma falha de rede transiente ocorre (uma falha de comunicações de rede durante 60 segundos) e, como resultado, todo o cluster está com deadlock e todos os bancos de dados no DAG são desmontados. Como não é muito fácil determinar qual nó do cluster está realmente com deadlock, se um cluster de failover tiver deadlock como um resultado da reconexão da corrida lógica, o único curso de ação disponível será reiniciar todos os membros de todo o cluster para resolver a condição de deadlock.

O problema geralmente se manifesta na forma de perda de quórum de cluster devido a uma falha de comunicação assimétrica (quando dois nós não podem se comunicar entre si, mas ainda podem se comunicar com outros nós). Se houver atrasos entre outros nós no recebimento de mensagens de reagrupamento de cluster a partir do Gerenciador de Atualização Global (GUM) do cluster, as mensagens de reagrupamento poderão acabar sendo recebidas em ordem inesperada. Quando isso acontece, o cluster perde quórum em vez de executar o comportamento esperado, que é retirar um dos nós que sofreram a falha de comunicação inicial do cluster.

Geralmente, esse bug se manifesta quando há latência assimétrica (por exemplo, onde metade dos membros do DAG tem latência de 1 ms, enquanto a outra metade dos membros do DAG tem latência de 30 ms) nos dois nós do cluster que descobrem uma conexão interrompida entre si. Se o primeiro nó detectar uma perda de conexão bem antes do segundo nó, uma condição de corrida poderá ocorrer:

  • O primeiro nó iniciará uma reconexão do fluxo entre os dois nós. Isso fará com que o segundo nó adicione o novo fluxo aos seus dados.
  • Adicionar o novo fluxo destrói o antigo fluxo e configura o manipulador de falhas para ser ignorado. Em caso de falha, o fluxo antigo é o fluxo com falha que não foi detectado ainda.
  • Quando o intervalo de conexão é detectado no segundo nó, o segundo nó inicia uma sequência de reconexão própria. Se o intervalo de conexão for detectado na janela de corrida adequada, o manipulador de falhas do fluxo com falha não será configurado para ser ignorado e o processo de reconexão não iniciará uma reconexão. No entanto, ele pausará a fila de envio, o que impedirá que as mensagens sejam enviadas entre os nós. Quando as mensagens são interrompidas, o GUM para de funcionar corretamente, e ocorre uma reinicialização forçada do cluster.

Se esse problema ocorrer, as consequências serão muito ruins para os DAGs. Como resultado, recomendamos que você implante este hotfix em todos os servidores da sua Caixa de Correio que são membros de um DAG, especialmente se o DAG estiver esticado em datacenters. Esse hotifx também poderá beneficiar os ambientes que executam Clusters de Cópia Única e Replicação Contínua em Cluster do Exchange 2007.

Além de corrigir o problema descrito acima, o KB2550886 também inclui outros hotfixes importantes do Windows Server 2008 R2 que também são recomendados para DAGs:

Esta é uma postagem de blog localizada. O artigo original encontra-se em Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2