Compreensão de cluster e piscina de quórum

• 01/18/2019
• 11 minutos de leitura
• • um
  • e
  • v
  • C
  • J
  • +3

Aplica-se a: Windows Server 2019, Windows Server 2016

o Windows Server Failover Clustering fornece alta disponibilidade para cargas de trabalho. Estes recursos são considerados altamente disponíveis se os nós que hospedam os recursos estão; no entanto, o cluster geralmente requer mais de metade dos nós para estar em execução, que é conhecido como tendo quórum.

quórum é projetado para evitar cenários de divisão do cérebro que podem acontecer quando há uma partição na rede e subconjuntos de nós não podem se comunicar uns com os outros. Isso pode fazer com que ambos os subconjuntos de nós para tentar possuir a carga de trabalho e escrever para o mesmo disco que pode levar a inúmeros problemas. No entanto, isso é impedido com o conceito de quórum do clustering de Failover, que força apenas um desses grupos de nós a continuar em execução, de modo que apenas um desses grupos vai ficar on-line.

Quorum determina o número de falhas que o cluster pode sustentar enquanto ainda permanece on-line. Quorum é projetado para lidar com o cenário quando há um problema com a comunicação entre subconjuntos de nós de cluster, de modo que vários servidores não tentam simultaneamente hospedar um grupo de recursos e escrever para o mesmo disco ao mesmo tempo. Ao ter este conceito de quórum, o cluster forçará o serviço de cluster a parar em um dos subconjuntos de nós para garantir que existe apenas um verdadeiro proprietário de um grupo de recursos particular. Uma vez que os nós que foram parados podem mais uma vez se comunicar com o grupo principal de nós, eles vão se juntar automaticamente ao cluster e iniciar o seu serviço de cluster.

no Windows Server 2019 e no Windows Server 2016, existem dois componentes do sistema que têm seus próprios mecanismos de quórum:

• Cluster Quorum: isto opera ao nível de cluster (i.e. você pode perder nós e fazer com que o cluster fique em cima)
• quórum do Pool: isto funciona no nível do pool quando os espaços de armazenamento direto está habilitado (ou seja, você pode perder nós e drives e ter o pool ficar em cima). Os grupos de armazenamento foram concebidos para serem utilizados tanto em cenários agrupados como em cenários Não agrupados, razão pela qual têm um mecanismo de quórum diferente.

quorum overview

the table below gives an overview of the Cluster Quorum outcomes per scenario:

Quorum de Cluster recomendações

• Se você tem dois nós, um testemunho é necessária.
• se você tem três ou quatro nós, o testemunho é fortemente recomendado.
• Se você tiver acesso à Internet, usar uma nuvem de testemunha
• Se você estiver em um ambiente de TI com outras máquinas e compartilhamentos de arquivo, use uma testemunha de compartilhamento de arquivos

Como de quórum de cluster funciona

Quando nós falhar, ou quando algum subconjunto de nós perde o contato com o outro subconjunto, nós sobreviventes necessário verificar de que eles constituem a maioria do cluster para permanecer online. Se não conseguirem verificar, vão desligar-se.

mas o conceito de maioria só funciona limpo quando o número total de nós no aglomerado é ímpar (por exemplo, três nós em um aglomerado de cinco nós). Então, e os aglomerados com um número par de nós (digamos, um aglomerado de quatro nós)?

há duas formas de o conjunto fazer o número total de votos ímpar:

1. primeiro, pode subir um, adicionando uma testemunha com um voto extra. Isto requer a configuração do utilizador.
2. ou, pode descer um por zerar um voto de um nó azarado (acontece automaticamente conforme necessário).Sempre que os nós sobreviventes verificam com sucesso que eles são a maioria, A definição de maioria é atualizada para estar entre apenas os sobreviventes. Isto permite que o aglomerado perca um nó, depois outro, depois outro, e assim por diante. Este conceito de número total de votos que se adaptam após sucessivas falhas é conhecido como quórum dinâmico.
   

   Dynamic witness

   Dynamic witness toggles the vote of the witness to make sure that the total number of votes is odd. Se houver um número ímpar de votos, a testemunha não tem voto. Se houver um número par de votos, a testemunha tem um voto. A Dynamic witness reduz significativamente o risco de o grupo cair por causa do fracasso da testemunha. O cluster decide se deve usar o voto de testemunhas com base no número de nós de votação que estão disponíveis no cluster.

   o quórum dinâmico funciona com o Dynamic witness da forma descrita abaixo.

   comportamento dinâmico do quórum

   • se você tem um número par de nós e nenhuma testemunha, um nó recebe seu voto zero. Por exemplo, apenas três dos quatro nós recebem votos, então o número total de votos é de três, e dois sobreviventes com votos são considerados uma maioria.Se você tem um número ímpar de nós e nenhuma testemunha, todos eles recebem votos.Se você tem um número par de nós mais testemunha, a testemunha vota, então o total é estranho.Se tiver um número ímpar de nós mais testemunhas, a testemunha não vota.

   o quórum dinâmico permite a capacidade de atribuir um voto a um nó dinamicamente para evitar perder a maioria dos votos e permitir que o aglomerado funcione com um nó (conhecido como “last-man standing”). Tomemos um conjunto de quatro nós como exemplo. Suponha que o quórum requer 3 votos.

   neste caso, o aglomerado teria caído se você perdesse dois nós.

   

   no entanto, dynamic quorum previne this from happening. O número total de votos necessários para quórum é agora determinado com base no número de nós disponíveis. Então, com quórum dinâmico, o grupo vai ficar de pé mesmo que você perca três nós.

   

   o cenário acima aplica-se a um conjunto geral que não tem espaços de armazenamento ativados diretamente. No entanto, quando espaços de armazenamento direto é ativado, o cluster só pode suportar duas falhas de nós. Isto é explicado mais na seção de quórum do pool.

   exemplos

   dois nós sem uma testemunha.

   o voto de um nó é zero, por isso o voto maioritário é determinado de um total de 1 voto. Se o nó sem voto cair inesperadamente, o sobrevivente tem 1/1 e o aglomerado sobrevive. Se o nó de votação cair inesperadamente, o sobrevivente tem 0/1 e o conjunto cai. Se o nó de votação é graciosamente desligado, o voto é transferido para o outro nó, e o aglomerado sobrevive. É por isso que é fundamental configurar uma testemunha.

   

   • pode sobreviver a uma falha do servidor: 50% de chance.
   • pode sobreviver a uma falha do servidor, em seguida, outro: não.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: No.

   dois nós com uma testemunha.

   ambos os nós votam, mais os votos das Testemunhas, de modo que a maioria é determinada de um total de 3 votos. Se cada nó cair, o sobrevivente tem 2/3 e o aglomerado sobrevive.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: não.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: No.

   três nós sem uma testemunha.

   todos os nós votam, de modo que a maioria é determinada de um total de 3 votos. Se algum nó cair, os sobreviventes são 2/3 e o aglomerado sobrevive. O aglomerado torna – se dois nós sem uma testemunha-nesse ponto, você está no Cenário 1.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outra: 50 por cento de chance.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: No.

   três nós com uma testemunha.

   todos os nós votam, então a testemunha não vota inicialmente. A maioria é determinada de um total de 3 votos. Depois de uma falha, o grupo tem dois nós com uma testemunha – que é de volta ao cenário 2. Agora, os dois nós e a testemunha votam.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: Sim.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: No.

   quatro nós sem uma testemunha

   o voto de um nó é zero, então a maioria é determinada de um total de 3 votos. Depois de uma falha, o conjunto torna-se três nós, e você está no cenário 3.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: Sim.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: 50% de chance.

   quatro nós com uma testemunha.

   todos os nós votam e as testemunhas votam, de modo que a maioria é determinada de um total de 5 votos. Depois de uma falha, estás no cenário 4. Depois de duas falhas simultâneas, você passa para o cenário 2.

   

   • Pode sobreviver a uma falha de servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: Sim.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: sim.

   Cinco nós e mais além.

   todos os nós votam, ou todos menos um voto, o que torna o total estranho. Espaços de armazenamento direto não pode lidar com mais de dois nós para baixo de qualquer maneira, então neste ponto, nenhuma testemunha é necessária ou útil.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: Sim.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: sim.

   agora que entendemos como o quórum funciona, vamos olhar para os tipos de testemunhas de quórum.

   Quórum witness types

   Failover Clustering supports three types of Quórum Witnesses:

   • Cloud Witness-Blob storage in Azure accessible by all nodes of the cluster. Mantém informações agrupadas numa testemunha.ficheiro de registo, mas não armazena uma cópia da base de dados do cluster.
   • File Share Witness – uma partilha de ficheiros SMB que é configurada num servidor de ficheiros a correr o Windows Server. Mantém informações agrupadas numa testemunha.ficheiro de registo, mas não armazena uma cópia da base de dados do cluster.
   • testemunha de Disco – um pequeno disco agrupado que está no grupo de armazenamento disponível. Este disco está altamente disponível e pode falhar entre nós. Contém uma cópia da base de dados do cluster. Uma testemunha de disco não é suportada com espaços de armazenamento direto.

   Pool quorum overview

   we just talked about Cluster Quorum, which operates at the cluster level. Agora, vamos mergulhar no quórum da piscina, que opera no nível da piscina (ou seja, você pode perder nós e drives e ter a piscina ficar em cima). Os grupos de armazenamento foram concebidos para serem utilizados tanto em cenários agrupados como em cenários Não agrupados, razão pela qual têm um mecanismo de quórum diferente.

   o quadro abaixo apresenta uma panorâmica dos resultados do quórum por cenário:

   nós de Servidor	Pode sobreviver a um servidor falha de nó	Pode sobreviver a um nó de servidor de falha, em seguida, outro	Pode sobreviver a duas em simultâneo nó de servidor de falhas
   2	Não	Não	Não
   2 + Testemunha	Sim	Não	Não
   3	Sim	Não	Não
   3 + Testemunha	Sim	Não	Não
   4	Sim	Não	Não
   4 + Testemunha	Sim	Sim	Sim
   5 e acima de	Sim	Sim	Sim

   Como pool de quórum obras

   Quando as unidades falhar, ou quando algum subconjunto de unidades perde o contato com o outro subconjunto, sobrevivendo unidades necessário verificar de que eles constituem a maioria da piscina para permanecer online. Se não conseguirem verificar, vão desligar-se. O pool é a entidade que fica offline ou permanece online com base em se tem Discos suficientes para quórum (50% + 1). O proprietário de recursos do pool (nó de cluster ativo) pode ser o +1.

   mas o quórum funciona de forma diferente do quórum de grupo nas seguintes formas::

   • piscina usa um nó no cluster como um testemunho como um desempate para sobreviver metade das unidades de ido (esse nó que é o pool de recursos proprietário)
   • a piscina NÃO tem dinâmica de quórum
   • a piscina NÃO implementar a sua própria versão de remoção de um voto

   Exemplos

   Quatro nós com um layout simétrico.

   cada uma das 16 unidades tem um voto e o nó dois também tem um voto (uma vez que é o proprietário de recursos do pool). A maioria é determinada de um total de 16 votos. Se os nós três e quatro descerem, O subconjunto sobrevivente tem 8 unidades e o proprietário do recurso do pool, que é 9/16 votos. Então, a piscina sobrevive.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: Sim.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: sim.

   quatro nós com uma disposição simétrica e falha de acionamento.

   cada uma das 16 unidades tem um voto e o nó 2 também tem um voto (uma vez que é o proprietário de recursos do pool). A maioria é determinada de um total de 16 votos. Primeiro, o drive 7 vai abaixo. Se os nós três e quatro descerem, O subconjunto sobrevivente tem 7 unidades e o proprietário do recurso do pool, que é de 8/16 votos. Então, a piscina não tem Maioria e cai.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outro: não.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: No.

   quatro nós com uma disposição não simétrica.

   cada uma das 24 unidades tem um voto e o nó dois também tem um voto (uma vez que é o proprietário de recursos do pool). A maioria é determinada de um total de 24 votos. Se os nós três e quatro descerem, O subconjunto sobrevivente tem 8 unidades e o proprietário do recurso do pool, que é 9/24 votos. Então, a piscina não tem Maioria e cai.

   

   • pode sobreviver a uma falha do servidor: Sim.
   • pode sobreviver a uma falha do servidor, em seguida, outra: **depende * * (não pode sobreviver se ambos os nós três e quatro descem, mas pode sobreviver a todos os outros cenários.
   • pode sobreviver a duas falhas de servidor ao mesmo tempo: ** Depende * * (não pode sobreviver se ambos os nós três e quatro caírem, mas pode sobreviver a todos os outros cenários.

   Piscina quórum recomendações

   • Garantir que cada nó no cluster é simétrico (cada nó tem o mesmo número de unidades)
   • Ativar espelho de três vias ou dupla paridade, de modo que você pode tolerar um nó de falhas e manter os discos virtuais on-line. Veja nossa página de guia de volume para mais detalhes.
   • se mais de dois nós estão em baixo, ou dois nós e um disco em outro nó estão em baixo, volumes podem não ter acesso a todas as três cópias de seus dados, e, portanto, ser desligados e estar indisponível. Recomenda-se trazer os servidores de volta ou substituir os discos rapidamente para garantir a maior resiliência para todos os dados no volume.