Modos de quórum do WSFC e configuração de votação (SQL Server)

Aplica-se:SQL Server

Tanto os grupos de disponibilidade Always On do SQL Server quanto as FCIs (Instâncias de Cluster de Failover) Always On utilizam o WSFC (Windows Server Failover Clustering) como tecnologia de plataforma. O WSFC usa uma abordagem baseada em quorum para monitorar a integridade geral do cluster e maximizar a tolerância a falhas em nível de nó. Uma compreensão fundamental dos modos de quórum do WSFC e da configuração de votação dos nós é fundamental para projetar, operar e solucionar problemas da sua solução Always On de alta disponibilidade e recuperação de desastres.

Detecção da saúde do cluster por quórum

Cada nó em um cluster do WSFC participa da comunicação de pulsação periódica para compartilhar o status de integridade do nó com os outros nós. Nós não responsivos são considerados em estado de falha.

Um conjunto de nós de quorum corresponde à maioria dos nós com direito a voto e das testemunhas no cluster do WSFC. A saúde geral e o status de um cluster WSFC são determinados por uma votação de quórum periódica. A presença de um quórum significa que o cluster está saudável e é capaz de oferecer tolerância a falhas em nível de nó.

A ausência de um quórum indica que o cluster não está saudável. A saúde geral do cluster WSFC deve ser mantida para garantir que nós secundários íntegros estejam disponíveis para que os nós primários façam failover para eles. Se a votação de quórum falhar, o cluster WSFC será colocado em modo offline como medida de precaução. Isso também fará com que todas as instâncias do SQL Server registradas com o cluster sejam interrompidas.

Importante

Se um cluster WSFC for definido offline devido a uma falha de quorum, a intervenção manual será necessária para colocá-lo online novamente.

Para obter mais informações, consulte: Recuperação de desastre do WSFC por meio de quorum forçado (SQL Server).

Modos de quorum

Um modo de quorum é configurado no nível do cluster WSFC que dita a metodologia usada para votação de quorum. O utilitário Gerenciador de Cluster de Failover recomendará um modo de quórum com base no número de nós do cluster.

Os seguintes modos de quorum podem ser usados para determinar o que constitui um quorum de votos:

  • Maioria de nós Mais da metade dos nós com direito a voto no cluster precisam votar afirmativamente para que o cluster seja considerado saudável.

  • Maioria de compartilhamentos de nós e arquivos. Semelhante ao modo de quorum Maioria de Nó, exceto pelo fato de um compartilhamento de arquivo remoto também ser configurado como uma testemunha de votação e a conectividade de qualquer nó com esse compartilhamento também ser contada como um voto afirmativo. Mais da metade dos votos possíveis deve ser afirmativa para que o cluster seja íntegro.

    Como prática recomendada, o compartilhamento de arquivos de testemunha não deve ficar localizado em nenhum nó do cluster e deve estar visível para todos os nós do cluster.

  • Maioria de nós e discos. Semelhante ao modo de quorum Maioria de Nó, exceto pelo fato de um recurso de cluster de disco compartilhamento também ser designado como uma testemunha de votação e a conectividade de qualquer nó com esse disco compartilhado também ser contada como um voto afirmativo. Mais da metade dos votos possíveis deve ser afirmativa para que o cluster seja íntegro.

  • Apenas o disco. Um recurso de cluster de disco compartilhado é designado como testemunha, e a conectividade de qualquer nó com esse disco compartilhado é contabilizada como um voto afirmativo.

Dica

Ao usar uma configuração de armazenamento assimétrico para os grupos de disponibilidade Always On, em geral, você deve usar o modo de quorum Maioria de Nós quando houver um número ímpar de nós com direito a voto, ou o modo de quorum Maioria de Nó e Compartilhamento de Arquivos quando houver um número par de nós com direito a voto.

Nós de votação e não votação

Por padrão, cada nó no cluster WSFC é incluído como membro do quórum do cluster; cada nó tem um único voto na determinação da integridade geral do cluster, e cada nó tentará continuamente estabelecer quórum. A discussão de quorum até esse ponto qualificou cuidadosamente o conjunto de nós do cluster WSFC que votam na integridade do cluster como nós de votação.

Nenhum nó isolado em um cluster WSFC pode determinar de forma definitiva se o cluster como um todo está saudável ou não. A qualquer momento, na perspectiva de cada nó, alguns dos outros nós podem parecer estar offline, parecer estar em processo de failover ou parecer sem resposta devido a uma falha de comunicação de rede. Uma função chave do voto de quorum é determinar se o estado aparente de cada nó no cluster WSFC é de fato o estado real desses nós.

Para todos os modelos de quorum, exceto 'Somente Disco', a efetividade de um voto de quorum depende das comunicações confiáveis entre todos os nós de votação no cluster. As comunicações de rede entre os nós na mesma sub-rede física devem ser consideradas confiáveis; o voto de quorum deve ser confiável.

No entanto, se um nó em outra sub-rede for considerado sem resposta em uma votação de quórum, mas na verdade estiver online e funcionando normalmente, isso provavelmente se deve a uma falha na comunicação de rede entre as sub-redes. Dependendo da topologia de cluster, do modo de quorum e da configuração da política de failover, essa falha de comunicação de rede pode criar efetivamente mais de um conjunto (ou subconjunto) de nós de votação.

Quando mais de um subconjunto de nós de votação consegue estabelecer um quórum por conta própria, isso é conhecido como cenário de split-brain. Nesse cenário, os nós nos quóruns separados podem se comportar de maneira diferente e entrar em conflito entre si.

Observação

A condição de split-brain só é possível quando um administrador de sistema executa manualmente uma operação de quórum forçado ou, em circunstâncias muito raras, realiza um failover forçado, subdividindo explicitamente o conjunto de nós de quórum.

Para simplificar sua configuração de quórum e aumentar o tempo de atividade, talvez seja interessante ajustar a configuração de NodeWeight de cada nó para que o voto do nó não seja contado para fins de quórum.

Importante

Para usar configurações de NodeWeight, é necessário aplicar o seguinte hotfix para todos os servidores no cluster WSFC:

KB2494036: Há um hotfix disponível para permitir que você configure um nó de cluster que não tenha votos de quorum em Windows Server 2008 e em Windows Server 2008 R2

Ajustes recomendados para votação por quórum

Ao habilitar ou desabilitar o voto de um nó WSFC específico, siga estas diretrizes:

  • Nenhum voto, por padrão. Assuma que cada nó não deve votar sem justificativa explícita.

  • Inclua todas as réplicas primárias. Cada nó WSFC que hospeda uma réplica primária do grupo de disponibilidade ou é o proprietário preferencial de uma FCI deve ter um voto.

  • Inclua possíveis proprietários de failover automático. Cada nó que possa hospedar uma réplica primária, em decorrência de um failover automático de grupo de disponibilidade ou de um failover de FCI, deve ter um voto. Se houver apenas um grupo de disponibilidade no cluster WSFC e as réplicas de disponibilidade forem hospedadas apenas por instâncias autônomas, essa regra incluirá somente a réplica secundária que é o destino do failover automático.

  • Exclua nós de site secundários. Em geral, não atribua votos a nós do WSFC que estão localizados em um site secundário de recuperação de desastres. Você não deseja que os nós no site secundário colaborem para uma decisão de colocar o cluster offline quando não houver nada errado com o site primário.

  • Número ímpar de votos. Se necessário, adicione um compartilhamento de arquivos de testemunha, um nó de testemunha ou um disco de testemunha ao cluster e ajuste o modo de quorum para evitar possíveis empates na votação de quorum.

  • Reavalie as atribuições de voto após o failover. Você não vai querer fazer failover para uma configuração de cluster que não oferece suporte a um quórum saudável.

Importante

Ao validar a configuração de voto de quórum do WSFC, o Assistente de Grupo de Disponibilidade Always On exibirá um aviso se qualquer uma das seguintes condições for verdadeira:

  • O nó do cluster que hospeda a réplica primária não tem direito a voto
  • Uma réplica secundária está configurada para failover automático e seu nó de cluster não tem direito a voto.
  • O KB2494036 não está instalado em todos os nós do cluster que hospedam as réplicas de disponibilidade. Este patch é necessário para adicionar ou remover votos dos nós do cluster em implantações em vários sites. No entanto, em implantações de site único, ele geralmente não é necessário, e você pode ignorar o aviso sem nenhum problema.

Dica

O SQL Server expõe várias exibições de gerenciamento dinâmico do sistema (DMVs) que podem ajudá-lo a gerenciar configurações relacionadas à configuração do cluster WSFC e à votação de quórum de nós.

Para obter mais informações, confira: sys.dm_hadr_cluster, sys.dm_hadr_cluster_members, sys.dm_os_cluster_nodes e sys.dm_hadr_cluster_networks

Tarefas Relacionadas

Conteúdo relacionado

  • Last updated on