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
Importante
O Azure Stack HCI agora faz parte do Azure Local. A renomeação da documentação do produto está em andamento. No entanto, as versões mais antigas do Azure Stack HCI, por exemplo 22H2, continuarão a fazer referência ao Azure Stack HCI e não refletirão a alteração de nome. Mais informações.
O Clustering de Failover do Windows Server fornece alta disponibilidade para cargas 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 ter quórum.
O Quorum foi projetado para evitar cenários de divisão cerebral 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 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 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 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: opera no nível do cluster (ou seja, você pode perder nós e fazer com que o cluster permaneça ativo)
- Quórum da piscina: opera no nível da piscina (ou seja, você pode perder nós e unidades e fazer com que a piscina fique no ar). 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 do 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 | No | Não |
| 2 + Testemunha | Sim | No | Não |
| 3 | Sim | 50/50 | Não |
| 3 + Testemunha | Sim | Sim | No |
| 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, o testemunho é altamente recomendado.
- Se você tiver cinco nós ou mais, uma testemunha não é necessária e não fornece resiliência adicional.
- Se você tiver acesso à internet, use uma testemunha na 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 permanecer online. Se não conseguirem verificar isso, ficarão offline.
Mas o conceito de maioria só funciona corretamente 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 tornar o número total de votos ímpar:
- Primeiro, pode subir um adicionando uma testemunha com um voto extra. Isso requer a configuração do usuário.
- Ou, pode descer um zerando 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 estar apenas entre os sobreviventes. Isso permite que o cluster perca um nó, depois outro, depois outro e assim por diante. Este conceito de adaptação do número total de votos após sucessivas falhas é conhecido como quórum dinâmico.
Testemunha dinâmica
A testemunha dinâmica alterna o voto da testemunha 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 deseja usar o voto testemunha 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 número par 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 recebem votos.
- Se você tiver um número par de nós mais testemunha, a testemunha vota, então o total é ímpar.
- Se você tiver um número ímpar de nós mais testemunha, 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 cluster funcione com um nó (conhecido como último homem em pé). Vamos tomar um cluster de quatro nós como exemplo. Suponha que o quórum requer 3 votos.
Nesse caso, o cluster teria caído se você perdesse dois nós.
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á habilitado, o cluster só pode suportar duas falhas de nó. Isso é explicado mais detalhadamente na seção de quórum do pool.
Exemplos
Dois nós sem testemunha
O voto de um nó é zerado, de modo que o voto da maioria é determinado de um total de 1 voto. Se o nó sem votação cair inesperadamente, o sobrevivente tem 1/1 e o cluster sobrevive. Se o nó de votação cair inesperadamente, o sobrevivente tem 0/1 e o cluster desce. Se o nó de votação estiver normalmente desligado, o voto será transferido para o outro nó e o cluster sobreviverá. É 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: Não.
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 descer, o sobrevivente tem 2/3 e o cluster sobrevive.
- 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: Não.
Três nós sem testemunha
Todos os nós votam, de modo que a maioria é determinada de um total de 3 votos. Se algum nó descer, os sobreviventes são 2/3 e o aglomerado 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: Não.
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. Após uma falha, o cluster tem dois nós com uma testemunha – que está de volta 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 e, em seguida, a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Não.
Quatro nós sem testemunha
O voto de um nó é zerado, de modo que a maioria é determinada 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 e, em seguida, 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 e, em seguida, 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 voto, 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 e, em seguida, 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
O Clustering de Failover suporta três tipos de Testemunhas de Quórum:
- Cloud Witness - Armazenamento de Blob no Azure acessível por 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.
- Testemunha de Compartilhamento de Arquivos – Um compartilhamento de arquivos SMB configurado em um servidor de arquivos 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 Armazenamento Disponível em Cluster. Este disco é altamente disponível e pode fazer failover entre nós. Ele contém uma cópia do banco de dados de cluster. Uma testemunha de disco não é compatível com os Espaços de Armazenamento Diretos.
Visão geral do quórum de pool
Acabamos de falar sobre o quórum de cluster, que opera no nível de cluster. Agora, vamos mergulhar no quórum de piscina, que opera no nível da piscina (ou seja, você pode perder nós e unidades e fazer com que a piscina fique ativa). 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 do 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 | Sim | No | Não |
| 2 + Testemunha | Sim | No | Não |
| 3 | Sim | No | Não |
| 3 + Testemunha | Sim | No | Não |
| 4 | Sim | No | Não |
| 4 + Testemunha | Sim | Sim | Sim |
| 5 e acima | Sim | Sim | Sim |
Como funciona o quórum de 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 permanecerem 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 seja quorate.
Mas o quórum de pool funciona de forma diferente do quórum de cluster das seguintes maneiras:
- O pool seleciona um subconjunto de unidades por nó para hospedar 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 uma das 16 unidades tem um voto e o nó dois também tem um voto (já 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 e o proprietário do recurso do pool, que é de 9/16 votos. Assim, a piscina sobrevive.
- Pode sobreviver a uma falha de servidor: Sim.
- Pode sobreviver a uma falha de servidor e, em seguida, 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 unidade
Cada uma das 16 unidades tem um voto e o nó 2 também tem um voto (já que é o proprietário do recurso do pool). A maioria é determinada de um total de 16 votos. Primeiro, a unidade 7 desce. Se os nós três e quatro caírem, o subconjunto sobrevivente terá 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 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: Não.
Recomendações de quórum de pool
- Certifique-se de que cada nó no cluster é 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.