Noções básicas de quorum de cluster e de pool

O Clustering de Failover do Windows Server fornece alta disponibilidade para cargas de trabalho em execução em clusters locais do Azure e do Windows Server. Esses recursos serão considerados altamente disponíveis se os nós que hospedam recursos estiverem em alta; no entanto, o cluster geralmente requer mais da metade dos nós a serem executados, o que é conhecido como quorum.

O quorum foi projetado para evitar cenários de cérebro dividido 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 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. Porém, isso é evitado com o conceito do quorum do Clustering de Failover, que força apenas um desses grupos de nós a continuar em execução, por isso, apenas um desses grupos permanece online.

O quorum 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 do 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 mais uma vez com o grupo principal de nós e retornarão automaticamente ao cluster e iniciarão o serviço de cluster.

No Azure Local e no Windows Server 2019, há dois componentes do sistema que têm seus próprios mecanismos de quorum:

• Quorum do cluster: isso opera no nível do cluster (ou seja, você pode perder nós e fazer com que o cluster permaneça 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, razão pela qual eles 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:

Recomendações para o quórum do clúster

• Se você tem dois nós, uma testemunha é necessária.
• Se você tiver três ou quatro nós, é altamente recomendável testemunhar.
• 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 algum subconjunto de nós perde contato com outro subconjunto, os nós sobreviventes precisam verificar se constituem a maioria do cluster para permanecer online. Se eles não puderem verificar isso, eles 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, e os clusters com um número par de nós (digamos, um cluster de quatro nós)?

Há duas maneiras de o cluster tornar o número total de votos ímpar:

1. Primeiro, pode subir um adicionando uma testemunha com um voto extra. Isso requer configuração do usuário.
2. Ou, pode cair um , zerando o voto de um nó azarado (acontece automaticamente conforme necessário).

Sempre que os nós sobreviventes verificam com êxito que são a maioria, a definição da maioria é atualizada para estar apenas entre os sobreviventes. Isso permite que o cluster perca um nó, depois outro, outro e assim por diante. Esse conceito do número total de votos que se adaptam 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 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 o cluster ficar inoperante devido à falha da testemunha. O cluster decide se deseja usar o voto de testemunha com base no número de nós de votação disponíveis no cluster.

O quorum dinâmico funciona com a testemunha dinâmica da maneira descrita abaixo.

Comportamento dinâmico de quorum

• 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 recebem votos, portanto, 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ê tem um número par de nós mais testemunha, a testemunha vota, então o total é estranho.
• Se você tem um número ímpar de nós mais testemunha, a testemunha não vota.

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). Vamos usar um cluster de quatro nós como exemplo. Suponha que o quorum exija 3 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 quorum agora é determinado com base no número de nós disponíveis. Portanto, com quorum 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 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 mais na seção de quorum do pool.

Examples

Dois nós sem uma testemunha

O voto de um nó é zerado, portanto, o voto da maioria é determinado de um total de 1 votos. 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 normalmente, 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: 50% de chance.
• Pode sobreviver a uma falha de servidor e, em seguida, 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, então a maioria é determinada de um total de 3 votos. Se um dos nós ficar offline, o nó ativo terá dois de três votos e o cluster sobreviverá.

• Pode sobreviver a uma falha de servidor: Sim.
• Pode sobreviver a uma falha de servidor e, em seguida, a outra: Não.
• Pode sobreviver a duas falhas de servidor ao mesmo tempo: Não.

Três nós sem uma testemunha

Todos os nós votam, portanto, a maioria é determinada de um total de 3 votos. Se algum nó ficar offline, os nós ativos terão dois de três votos e o cluster sobreviverá. O cluster se torna dois nós sem uma 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: 50% 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 têm voto, então, a testemunha não vota inicialmente. A maioria é determinada de um total de 3 votos. Depois de uma falha, o cluster tem dois nós com uma testemunha - o que leva 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 uma testemunha

O voto de um nó é zerado, portanto, 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: 50% de chance.

Quatro nós com uma testemunha

Todos os nós votam e a testemunha vota, então 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ê passa 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

Todos os nós votam, ou todos menos um voto, o que torna o total ímpar. De qualquer forma, os Espaços de Armazenamento Diretos não conseguem lidar com mais de dois nós inativos, portanto, nesse ponto, 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 o quorum funciona, vamos examinar os tipos de testemunhas de quorum.

Tipos de testemunha de quorum

O Clustering 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.
• File Share Witness – um compartilhamento de arquivos SMB configurado em um servidor de arquivos que executa o 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 os 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 quórum do grupo

Acabamos de analisar 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, razão pela qual eles 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:

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 maior parte do pool para permanecer online. Se eles não puderem verificar isso, eles ficarão offline. O pool é a entidade que fica offline ou permanece online com base em se ele tem discos suficientes para o quorum (50% + 1). O banco de dados do cluster pode ser o +1, desde que o próprio cluster esteja com o quórum.

Mas o quorum do pool funciona de forma diferente do quorum do cluster das seguintes maneiras:

• O pool seleciona um subconjunto de unidades por nó para hospedar metadados
• O pool usa o banco de dados do 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

Examples

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 forem reduzidos, o subconjunto sobrevivente terá oito unidades e o proprietário do recurso do pool, que é de nove de 16 votos. Então, 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 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.

• Pode sobreviver a uma falha de servidor: Sim.
• Pode sobreviver a uma falha de servidor e, em seguida, a outra: Não.
• Pode sobreviver a duas falhas de servidor ao mesmo tempo: Não.

Recomendações para o quorum do pool

• Verifique se cada nó no seu cluster é simétrico (cada nó tem o mesmo número de unidades)
• Habilite o espelhamento em três vias ou a 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 inoperantes, os volumes poderão não ter acesso a todas as três cópias de seus dados e, portanto, serem colocados offline e 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.

Próximas etapas

• Configurar e gerenciar quorum
• Configurar uma testemunha de cluster