Compartilhar via

Configuração de modos de quorum WSFC e votação (SQL Server)

  • Artigo

Os grupos de disponibilidade SQL ServerAlways On e FCI (Instâncias de Cluster de Failover AlwaysOn) aproveitam o WSFC (Windows Server Failover Clustering) como uma tecnologia de plataforma. O WSFC usa uma abordagem baseada em quorum para monitorar integridade de cluster geral e maximizar a tolerância a falhas no nível do nó. Um entendimento fundamental dos modos de quorum do WSFC e a configuração de votação de nó são muito importantes para o design, a operação e a resolução de problemas da sua solução de alta disponibilidade e recuperação de desastre AlwaysOn.

Neste tópico:

Detecção de integridade de cluster por quorum

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 sem resposta são considerados como em estado com falha.

Um conjunto de nós de quorum é uma maioria dos nós de votação e testemunhas no cluster WSFC. A integridade geral e o status de um cluster WSFC são determinados por um voto de quorumperiódico. A presença de um quorum significa que o cluster está íntegro e é capaz de fornecer tolerância a falhas no nível de nó.

A ausência de um quorum indica que o cluster não está íntegro. A integridade do cluster WSFC geral deve ser mantida para assegurar que os nós secundários de integridade estejam disponíveis para nós primários para failover. Se o voto de quorum falhar, o cluster WSFC será definido offline por 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 quorum com base no número de nós no 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 de votação no cluster precisam votar afirmativamente para o cluster ser íntegro.

  • 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 uma prática recomendada, o compartilhamento de arquivo de testemunha não deve residir em nenhum nó no cluster e deve estar visível para todos os nós no 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.

  • Somente Disco. Um recurso de cluster de disco compartilhamento é designado como uma testemunha e a conectividade por qualquer nó com esse disco compartilhado é contada como um voto afirmativo.

Dica

Ao usar uma configuração de armazenamento assimétrica para grupos de disponibilidade Always On, você geralmente deve usar o modo de quorum maioria de nós quando tiver um número ímpar de nós de votação ou o modo de quorum Maioria de Nós e Compartilhamento de Arquivos quando você tiver um número par de nós de votação.

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

Por padrão, cada nó no cluster WSFC é incluso como membro do quorum de cluster; cada nó tem um único voto na determinação da integridade de cluster geral e cada nó tentará continuamente estabelecer um quorum. 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ó individual em um cluster WSFC pode determinar definitivamente se o cluster como um todo é íntegro ou não íntegro. A qualquer momento, da perspectiva de cada nó, alguns dos outros nós podem aparecer offline ou talvez pareça que estão em processo de failover ou não respondentes 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 visto como não respondente em um voto de quorum, mas na verdade estiver online e, de outra forma, íntegro, isso ocorre muito provavelmente devido a uma falha de comunicação de rede entre 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 quorum próprio, ele é conhecido como cenário de separação. Nesse cenário, os nós nos quorums separados podem se comportar de modo diferente e conflitante.

Observação

O cenário de separação somente é possível quando um administrador de sistema executa manualmente uma operação de quorum forçado ou em circunstâncias muito raras, um failover forçado; subdividindo explicitamente o conjunto de nós de quorum.

Para simplificar sua configuração de quorum e aumentar o tempo de atividade, talvez você queira ajustar a configuração NodeWeight de cada nó para que o voto do nó não seja contado na direção do quorum.

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 indicados para votação de quorum

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 pode hospedar uma réplica primária, como resultado de um failover de grupo de disponibilidade automático ou 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 dê votos para nós WSFC que residem em um site de recuperação de desastre secundário. 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úmeros de votos ímpares. Se necessário, adicione um compartilhamento de arquivo testemunha, um nó testemunha ou um disco testemunha ao cluster e ajuste o modo de quorum para prevenir possíveis empates no voto de quorum.

  • Reavalie as atribuições de voto após o failover. Você não deseja o failover em uma configuração de cluster sem suporte para um quorum íntegro.

Importante

Quando a configuração de voto de quorum do WSFC for validada, o Assistente para Grupo de Disponibilidade AlwaysOn exibirá um aviso se um das condições a seguir for verdadeira:

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

Dica

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

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

Related Tasks

Conteúdo relacionado

Consulte Também

Recuperação de desastres WSFC por meio de quorum forçado (SQL Server)
WSFC (Windows Server Failover Clustering) com o SQL Server