Noções básicas de quorum de cluster e de pool
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server
O Clustering de Failover do Windows Server fornece alta disponibilidade para cargas de trabalho em execução em clusters do Azure Stack HCI e do Windows Server. Esses recursos são considerados altamente disponíveis se os nós que hospedam os recursos estão ativos. Porém, para se encaixar na definição de quorum, o cluster geralmente requer que mais da metade dos nós estejam executando.
O quorum foi projetado para evitar cenários de divisão de cérebro que podem acontecer quando há uma partição na rede e subconjuntos de nós não podem se comunicar entre si. Isso pode fazer com que os dois 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 quorum do Clustering de Failover, que força apenas um desses grupos de nós a continuar em execução, portanto, apenas um desses grupos permanece online.
O quorum determina o número de falhas que pode ocorrer no cluster enquanto 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 grupo de recursos específico. Os nós que foram interrompidos podem mais uma vez se comunicar com o grupo de nós main e reingressarão automaticamente no cluster e iniciarão o 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:
- Quorum do cluster: opera no nível do cluster (ou seja, você pode perder nós e manter o cluster ativo)
- Quorum do pool: isso opera no nível do pool (ou seja, você pode perder nós e unidades e fazer com que o pool permaneça ativo). Os pools de armazenamento foram projetados para serem usados em cenários clusterizados e não clusterizados. Por isso têm um mecanismo de quorum diferente.
Visão geral do quorum do cluster
A tabela a seguir fornece uma visão geral dos resultados de quorum do 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 de nó de servidor simultâneas |
|---|---|---|---|
| 2 | 50/50 | No | Não |
| 2 + Testemunha | Sim | No | Não |
| 3 | Sim | 50/50 | No |
| 3 + Testemunha | Sim | Yes | Não |
| 4 | Sim | Yes | 50/50 |
| 4 + Testemunha | Sim | Yes | Yes |
| 5 e acima | Sim | Yes | Yes |
Recomendações para o quorum do cluster
- Se você tiver dois nós, será necessária uma testemunha.
- Se você tiver três ou quatro nós, recomenda-se fortemente uma testemunha.
- Se você tiver cinco nós ou mais, uma testemunha não será necessária e não fornecerá resiliência adicional.
- Se você tiver acesso à Internet, use uma testemunha de nuvem.
- Se você estiver em um ambiente de TI com outros computadores e compartilhamentos de arquivos, use uma testemunha de compartilhamento de arquivos.
Como funciona o quorum do cluster
Quando os nós falham ou quando um subconjunto de nós perde contato com outro subconjunto, os nós sobreviventes precisam verificar se eles são a maioria do cluster para permanecerem online. Se não puderem fazer essa verificação, eles ficarão offline.
O conceito de maioria só funciona de forma simples e clara quando o número total de nós no cluster é ímpar (por exemplo, três nós ativos em um cluster com cinco nós). O que ocorre com clusters com um número par de nós (digamos, um cluster com quatro nós)?
Há duas maneiras de o cluster converter o total de votos em um número ímpar:
- Ele pode aumentar um ao adicionar uma testemunha como um voto extra. Isso requer configuração do usuário.
- Ou, ele pode diminuir um ao zerar o voto de um nó aleatório (ocorre automaticamente conforme necessário).
Sempre que os nós sobreviventes verificam com sucesso que são a maioria, a definição da maioria é atualizada para estar entre apenas os sobreviventes. Isso permite que o cluster perca nós sucessivamente sem comprometer o conceito de maioria. Esse conceito de número total de votos que se adapta após falhas sucessivas é conhecido como Quorum dinâmico.
Testemunha dinâmica
A testemunha dinâmica alterna o voto da testemunha para garantir que o número total de votos permaneça ímpar. Se o número de votos for ímpar, a testemunha não é contada como um voto. Se houver um número par de votos, a testemunha tem um voto. A testemunha dinâmica reduz significativamente o risco de o cluster ficar inoperante devido à falha da testemunha. O cluster baseia-se no número de nós votantes para decidir se usa o voto da testemunha.
O quorum dinâmico funciona com uma testemunha dinâmica da maneira descrita abaixo.
Comportamento do quorum dinâmico
- Se houver um número par de nós e nenhuma testemunha, um dos nós terá o voto anulado. Por exemplo, apenas três dos quatro nós terão voto, então o número total de votos é três, e dois sobreviventes com voto são considerados a maioria.
- Se houver um número ímpar de nós e nenhuma testemunha, todos terão voto.
- Se houver um número par de nós e também uma testemunha, a testemunha votará, então o total será um número ímpar.
- Se houver um número ímpar de nós e também uma testemunha, a testemunha não votará.
O quorum dinâmico habilita a capacidade de atribuir um voto a um nó dinamicamente para evitar a perda da maioria dos votos e permitir que o cluster seja executado mesmo com um único nó (conhecido como o último ativo). Vejamos um exemplo de cluster com quatro nós. Suponha que o quorum exija três votos.
Nesse caso, o cluster ficaria offline se perdesse dois nós.
No entanto, o quorum dinâmico impede que isso aconteça. O número total de votos necessários para o quorum agora é determinado com base no número de nós disponíveis. Portanto, com o quorum dinâmico, o cluster permanece ativo mesmo que você perca 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. Quando os Espaços de Armazenamento Diretos estão habilitados, o cluster só pode suportar dois nós com falha. Isso é explicado com mais detalhes na seção sobre o quorum do pool.
Exemplos
Dois nós sem uma testemunha
O voto de um nó é anulado, então a maioria é determinada de um total de um voto. Se o nó sem voto ficar offline de repente, o nó ativo terá um voto de um total de um e o cluster sobreviverá. Se o nó com voto ficar offline de repente, o nó sobrevivente terá um voto anulado de um total de um e o cluster ficará offline. Se o nó com voto for desligado paulatinamente, o voto será transferido para o outro nó e o cluster sobreviverá. Por isso é fundamental configurar uma testemunha.
- Sobrevive a uma falha do servidor: 50% de chance.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Não.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Não.
Dois nós com uma testemunha
Ambos os nós e a testemunha têm voto, então a maioria é determinada de um total de três votos. Se um dos nós ficar offline, o nó ativo terá dois votos do total de três e o cluster sobreviverá.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Não.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Não.
Três nós sem uma testemunha
Todos os nós votam, então a maioria é determinada de um total de três votos. Se algum nó ficar offline, os nós ativos terão dois votos de um total de três e o cluster sobreviverá. Ele se torna um cluster com dois nós sem uma testemunha. Este é o Cenário 1.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: 50% de chance.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Não.
Três nós com uma testemunha
Todos os nós têm voto, então a testemunha não vota inicialmente. A maioria é determinada de um total de três votos. Após uma falha, o cluster fica com dois nós e uma testemunha. Este é o Cenário 2. Então, agora os dois nós e a testemunha votam.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Sim.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Não.
Quatro nós sem uma testemunha.
O voto de um nó é anulado, então a maioria é determinada de um total de três votos. Após uma falha, o cluster fica com três nós. Este é o Cenário 3.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Sim.
- Sobrevive a duas falhas do servidor ao mesmo tempo: 50% de chance.
Quatro nós com uma testemunha
Todos os nós e a testemunha têm voto, então a maioria é determinada de um total de cinco votos. Após uma falha, voltamos ao Cenário 4. Após duas falhas simultâneas, vamos para o Cenário 2.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Sim.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Sim.
Cinco nós e além
Todos os nós votam ou todos menos um vota, conforme necessário para obter um total ímpar. Espaços de Armazenamento Diretos não pode lidar com mais de dois nós para baixo de qualquer maneira, portanto, neste ponto, nenhuma testemunha é necessária ou útil.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Sim.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Sim.
Agora que entendemos como o quorum funciona, vamos examinar os tipos de testemunhas de quorum.
Tipos de testemunha de quorum
O Cluster de failover suporta três tipos de Testemunhas de Quorum:
- Testemunha de Nuvem – Armazenamento de Blobs no Azure, acessível por todos os nós do cluster. Ela mantém as informações de clustering em um arquivo witness.log, mas não armazena uma cópia do banco de dados do cluster.
- Testemunha de Compartilhamento de Arquivos – compartilhamento de arquivos SMB configurado em um servidor de arquivos que executa Windows Server. Ela mantém as informações de clustering em um arquivo witness.log, mas não armazena uma cópia do banco de dados do cluster.
- Testemunha de Disco – um pequeno disco clusterizado que está no grupo Armazenamento Disponível do Cluster. Esse disco é altamente disponível e pode fazer failover entre nós. Ele contém uma cópia do banco de dados do cluster. Não há suporte para uma testemunha de disco nos Espaços de Armazenamento Diretos.
Visão geral do quorum do pool
Acabamos de falar sobre o quorum do cluster, que opera no nível do cluster. Agora, vamos nos aprofundar no quorum do pool, que opera no nível do pool (ou seja, você pode perder nós e unidades e fazer com que o pool permaneça ativo). Os pools de armazenamento foram projetados para serem usados em cenários clusterizados e não clusterizados. Por isso têm um mecanismo de quorum diferente.
A tabela a seguir fornece uma visão geral dos resultados de quorum do pool 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 de nó de servidor simultâneas |
|---|---|---|---|
| 2 | Sim | No | Não |
| 2 + Testemunha | Sim | No | Não |
| 3 | Sim | No | No |
| 3 + Testemunha | Sim | No | Não |
| 4 | Sim | No | Não |
| 4 + Testemunha | Sim | Yes | Yes |
| 5 e acima | Sim | Yes | Yes |
Como funciona o quorum 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 constituem a maioria do pool para permanecer online. Se não puderem fazer essa verificação, elas ficarão offline. O pool decide se fica offline ou permanece online com base em se há disco suficiente para o quorum (50% + 1). O banco de dados de cluster pode ser o +1, desde que o próprio cluster seja quorate.
As diferenças entre o quorum do pool e o quorum do cluster são:
- O pool seleciona um subconjunto de unidades por nó para hospedar metadados
- O pool usa o banco de dados de cluster para interromper vínculos
- O pool não tem quorum dinâmico
- O pool não implementa sua própria versão de remoção de uma votação
Exemplos
Quatro nós com um layout simétrico
Cada uma das 16 unidades e o nó 2 têm voto (pois é o proprietário do recurso do pool). A maioria é determinada de um total de 16 votos. Se os nós 3 e 4 caírem, restarão um subconjunto com 8 unidades e o proprietário do recurso do pool, resultando em 9 votos de um total de 16. Portanto, o pool sobreviverá.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Sim.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Sim.
Quatro nós com um layout simétrico e falha de unidade
Cada uma das 16 unidades e o nó 2 têm voto (pois é o proprietário do recurso do pool). A maioria é determinada de um total de 16 votos. Primeiro, a unidade 7 cai. Se os nós 3 e 4 caírem, restarão um subconjunto com 7 unidades e o proprietário do recurso do pool, resultando em 8 votos de um total de 16. Então, o pool não tem a maioria e cai.
- Sobrevive a uma falha do servidor: Sim.
- Sobrevive a uma falha do servidor e, em seguida, a outra: Não.
- Sobrevive a duas falhas do servidor ao mesmo tempo: Não.
Recomendações para o quorum do pool
- Verifique se cada nó do cluster é simétrico (cada nó tem o mesmo número de unidades)
- Habilite espelho de três vias ou paridade dupla para que você possa tolerar duas falhas de nó 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 talvez não consigam acessar todas as três cópias de dados e, portanto, ficarão offline e se tornarão indisponíveis. É recomendável trazer de volta os servidores ou substituir os discos rapidamente para garantir a maior resiliência para todos os dados no volume.