Noções básicas sobre quórum de cluster e pool
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server
Cluster de Failover do Windows Server fornece alta disponibilidade para tarefas de trabalho executadas em clusters do Azure Stack HCI e do Windows Server. Esses recursos são considerados altamente disponíveis se os nós que hospedam recursos estiverem ativos; no entanto, o cluster geralmente requer mais da metade dos nós para estar em execução, o que é conhecido como tendo quorum.
O Quorum está projetado para evitar cenários de de cérebro bipartido que podem acontecer quando há uma partição na rede e subconjuntos de nós não conseguem comunicar-se entre si. Isso pode fazer com que ambos os subconjuntos de nós tentem possuir a carga de trabalho e gravar no mesmo disco, o que pode levar a vários problemas. No entanto, isso é evitado com o conceito de quórum do Failover Clustering, que força apenas um desses grupos de nós a continuar em funcionamento, portanto, apenas um desses grupos permanece online.
O quórum determina o número de falhas que o cluster pode sustentar enquanto ainda permanece online. O Quorum foi projetado para lidar com o cenário quando há um problema com a comunicação entre subconjuntos de nós de cluster, para que vários servidores não tentem hospedar simultaneamente um grupo de recursos e gravar no mesmo disco ao mesmo tempo. Ao ter esse conceito de quorum, o cluster força o serviço de cluster a parar em um dos subconjuntos de nós para garantir que haja apenas um verdadeiro proprietário de um determinado grupo de recursos. Os nós que foram interrompidos podem se comunicar novamente com o grupo principal de nós e reingressarão automaticamente no cluster e iniciarão seu serviço de cluster.
No Azure Stack HCI e no Windows Server 2019, há dois componentes do sistema que têm seus próprios mecanismos de quorum:
- Quórum de Cluster: Funciona no nível do cluster (ou seja, você pode perder nós e fazer com que o cluster permaneça ativo)
- Pool Quorum: Funciona ao nível do pool (ou seja, pode perder nós e discos e o pool continua operacional). Os pools de armazenamento foram projetados para serem usados em cenários clusterizados e não clusterizados, e é por isso que eles têm um mecanismo de quorum diferente.
Visão geral do quórum de cluster
A tabela abaixo fornece uma visão geral dos resultados do quórum de cluster por cenário:
| Nós de servidor | Pode sobreviver a uma falha de nó de servidor | Pode sobreviver a uma falha de nó de servidor e, em seguida, a outra | Pode sobreviver a duas falhas simultâneas de nó de servidor |
|---|---|---|---|
| 2 | 50/50 | Não | Não |
| 2 + Testemunha | Sim | Não | Não |
| 3 | Sim | 50/50 | Não |
| 3 + Testemunha | Sim | Sim | Não |
| 4 | Sim | Sim | 50/50 |
| 4 + Testemunha | Sim | Sim | Sim |
| 5 e acima | Sim | Sim | Sim |
Recomendações de quórum de agrupamento
- Se você tiver dois nós, uma testemunha é necessária.
- Se você tiver três ou quatro nós, a testemunha é altamente recomendada.
- Se você tiver cinco nós ou mais, uma testemunha não é necessária e não fornece resiliência adicional.
- Se tiver acesso à internet, use uma testemunha de nuvem .
- Se você estiver em um ambiente de TI com outras máquinas e compartilhamentos de arquivos, use uma testemunha de compartilhamento de arquivos.
Como funciona o quórum de cluster
Quando os nós falham, ou quando algum subconjunto de nós perde contato com outro subconjunto, os nós sobreviventes precisam verificar se eles constituem a maioria do cluster para permanecerem online. Se não conseguirem verificar isso, ficarão offline.
Mas o conceito de maioria só funciona de forma limpa quando o número total de nós no cluster é ímpar (por exemplo, três nós em um cluster de cinco nós). Então, o que acontece com clusters com um número par de nós (digamos, um cluster de quatro nós)?
Há duas maneiras pelas quais o cluster pode fazer com que o número total de votos se torne ímpar:
- Primeiro, pode ir até adicionando uma testemunha com um voto extra. Isso requer a configuração do usuário.
- Ou, pode diminuir em um, reduzindo a zero o voto de um nó azarado (acontece automaticamente conforme necessário).
Sempre que os nós sobreviventes verificam com sucesso que são a maioria , a definição de maioria é atualizada para incluir apenas os sobreviventes. Isso permite que o cluster perca um nó, depois outro, depois outro e assim por diante. Este conceito de número total de votos que se adapta após sucessivas falhas é conhecido como quórum dinâmico.
Testemunha dinâmica
A testemunha dinâmica alterna o seu voto para garantir que o número total de votos seja ímpar. 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 testemunha dinâmica reduz significativamente o risco de que o cluster caia devido à falha da testemunha. O cluster decide se deve usar o voto do testemunho com base no número de nós de votação disponíveis no cluster.
O quórum dinâmico funciona com testemunho dinâmico da forma descrita abaixo.
Comportamento dinâmico de quórum
- Se você tiver um mesmo número de nós e nenhuma testemunha, um nó terá seu voto zerado. Por exemplo, apenas três dos quatro nós obtêm votos, então o número total de votos é de três, e dois sobreviventes com votos são considerados maioria.
- Se você tem um número ímpar de nós e nenhuma testemunha, todos eles obtêm votos.
- Se você tiver um número mesmo de nós mais testemunha, a testemunha vota, então o total é ímpar.
- Se tiveres um número ímpar de nodos mais testemunha, a testemunha não vota.
O quórum dinâmico permite atribuir um voto a um nó de forma dinâmica para evitar perder a maioria dos votos e permitir que o cluster funcione com apenas um nó (conhecido como o último nó em funcionamento). Vamos tomar um cluster de quatro nós como exemplo. Suponha que o quórum requer 3 votos.
Nesse caso, se perdesse dois nós, o cluster teria caído.
No entanto, o quórum dinâmico impede que isso aconteça. O número total de votos necessários para o quórum é agora determinado com base no número de nós disponíveis. Assim, com quórum dinâmico, o cluster permanece ativo mesmo se você perder três nós.
O cenário acima se aplica a um cluster geral que não tem os Espaços de Armazenamento Diretos habilitados. No entanto, quando o Storage Spaces Direct está ativado, o cluster só pode suportar duas falhas de nó. Isso é explicado mais detalhadamente na seção pool quorum.
Exemplos
Dois nós sem testemunha
O voto de um nó é anulado, de modo que o voto da maioria é determinado a partir de um total de 1 voto. Se o nó não votante cair inesperadamente, o sobrevivente fica com 1/1, e o cluster continua a funcionar. Se o nó de votação cair inesperadamente, o sobrevivente tem 0/1 e o cluster falha. Se o nó de votação for desligado de forma graciosa, o voto será transferido para o outro nó, e o cluster continuará a funcionar. É por isso que é fundamental configurar uma testemunha.
- Pode sobreviver a uma falha de servidor: Cinquenta por cento de chance.
- Pode sobreviver a uma falha de servidor, depois a outra: 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 um dos nós falhar, o sobrevivente fica com 2/3 e o cluster sobrevive.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Sem.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: No.
Três nós sem testemunha
Todos os nós votam, portanto, a maioria é determinada de um total de 3 votos. Se algum nodo falhar, permanecem 2/3 dos nós operacionais e o cluster sobrevive. O cluster se torna dois nós sem testemunha – nesse ponto, você está no Cenário 1.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Cinquenta 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 a partir de um total de 3 votos. Após uma falha, o cluster tem dois nós com uma testemunha, voltando ao Cenário 2. Então, agora os dois nós e a testemunha votam.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: No.
Quatro nós sem testemunha
O voto de um nó é anulado, de modo que a maioria é determinada a partir de um total de 3 votos . Após uma falha, o cluster se torna três nós e você está no Cenário 3.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Cinquenta por cento 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. Após uma falha, você está no Cenário 4. Após duas falhas simultâneas, você pula para o Cenário 2.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: 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, exceto um, votam, o que torna o total ímpar. O Storage Spaces Direct não pode lidar com mais de dois nós para baixo, portanto, neste momento, nenhuma testemunha é necessária ou útil.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Sim.
Agora que entendemos como funciona o quórum, vamos analisar os tipos de testemunhas de quórum.
Tipos de testemunhas do quórum
Cluster de Failover suporta três tipos de Testemunhas de Quórum:
- Cloud Witness - Armazenamento de Blob no Azure acessível a todos os nós do cluster. Ele mantém informações de cluster em um arquivo witness.log, mas não armazena uma cópia do banco de dados de cluster.
- File Share Witness – Uma partilha de ficheiros SMB configurada num gestor de ficheiros que executa o Windows Server. Ele mantém informações de cluster em um arquivo witness.log, mas não armazena uma cópia do banco de dados de cluster.
- Disk Witness - Um pequeno disco clusterizado que está no grupo de Armazenamento Disponível do Cluster. Este disco é altamente robusto e pode alternar entre nós. Ele contém uma cópia do banco de dados de cluster. Uma testemunha de disco não é suportada no Storage Spaces Direct.
Visão geral do quórum de pool
Acabamos de falar sobre o quórum de cluster, que opera ao nível do cluster. Agora, vamos mergulhar no quórum do pool, que opera ao nível do pool (ou seja, podes perder nós e unidades e o pool continuará operacional). Os pools de armazenamento foram projetados para serem usados em cenários clusterizados e não clusterizados, e é por isso que eles têm um mecanismo de quorum diferente.
A tabela abaixo apresenta uma visão geral dos resultados do quórum de pool por cenário:
| Nós de servidores | Pode sobreviver a uma falha de nó de servidor | Pode sobreviver a uma falha de nó de servidor e depois a outra. | Pode sobreviver a duas falhas simultâneas de nodo de servidor |
|---|---|---|---|
| 2 | Sim | 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 | Sim | Sim | Sim |
Como funciona o quórum do pool
Quando as unidades falham, ou quando algum subconjunto de unidades perde contato com outro subconjunto, as unidades sobreviventes que hospedam metadados precisam verificar se elas constituem a maioria do pool para permanecer online. Se não conseguirem verificar isso, ficarão offline. O pool é a entidade que fica offline ou permanece online com base em se tem discos suficientes para quorum (50% + 1). O banco de dados de cluster pode ser o +1, desde que o próprio cluster tenha quórum.
Mas o quórum de pool funciona de forma diferente do quórum de cluster das seguintes maneiras:
- O pool escolhe um conjunto de discos em cada nó para armazenar metadados
- O pool usa o banco de dados de cluster para quebrar laços
- O pool não tem quórum dinâmico
- O pool não implementa sua própria versão de remoção de um voto
Exemplos
Quatro nós com um layout simétrico
Cada um dos 16 discos tem um voto e o nó dois também tem um voto (uma vez que é o proprietário do recurso do pool). A maioria é determinada de um total de 16 votos. Se os nós três e quatro caírem, o subconjunto sobrevivente terá 8 unidades, com o proprietário do recurso do pool a ter 9/16 votos. Assim, a piscina sobrevive.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Sim.
Quatro nós com um layout simétrico e falha de disco
Cada uma das 16 unidades tem um voto e o nó 2 também tem um voto (já que é o proprietário do recurso de agrupamento). A maioria é determinada de um total de 16 votos. Primeiro, a unidade 7 desce. Se os nós três e quatro falharem, o subconjunto sobrevivente terá 7 unidades e o proprietário dos recursos do pool terá 8/16 votos. Então, a piscina não tem maioria e cai.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor, depois a outra: Não.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: No.
Recomendações para o quórum do grupo
- Certifique-se de que cada nó no seu cluster seja simétrico (cada nó tem o mesmo número de unidades)
- Habilite o espelho de três vias ou a paridade dupla para que você possa tolerar falhas de dois nós e manter os discos virtuais online.
- Se mais de dois nós estiverem inativos ou dois nós e um disco em outro nó estiverem inativos, os volumes podem não ter acesso a todas as três cópias de seus dados e, portanto, ficar offline e indisponíveis. Recomenda-se trazer de volta os servidores ou substituir os discos rapidamente para garantir a maior resiliência para todos os dados no volume.