Compreender o quórum do cluster e do conjunto
Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server
O Clustering de Ativação Pós-falha do Windows Server fornece elevada disponibilidade para cargas de trabalho em execução em clusters do Azure Stack HCI e do Windows Server. Estes recursos são considerados de elevada disponibilidade se os nós que alojam recursos estiverem disponíveis; no entanto, geralmente, o cluster requer mais de metade dos nós em execução, que é conhecido como tendo quórum.
O quórum foi concebido para impedir cenários de cérebro dividido que podem acontecer quando há uma partição na rede e os subconjunto de nós não conseguem comunicar entre si. Isto pode fazer com que ambos os subconjuntos de nós tentem possuir a carga de trabalho e escrever no mesmo disco, o que pode levar a inúmeros problemas. No entanto, isto é evitado com o conceito de quórum do Clustering de Ativação Pós-falha, que força apenas um destes grupos de nós a continuar em execução, pelo que apenas um destes grupos permanece online.
O quórum determina o número de falhas que o cluster pode suportar enquanto permanece online. O quórum foi concebido para lidar com o cenário quando existe um problema de comunicação entre subconjunto de nós de cluster, para que vários servidores não tentem alojar simultaneamente um grupo de recursos e escrever no mesmo disco ao mesmo tempo. Ao ter este conceito de quórum, o cluster força o serviço de cluster a parar num dos subconjunto de nós para garantir que existe apenas um verdadeiro proprietário de um determinado grupo de recursos. Os nós que foram parados podem comunicar novamente com o grupo principal de nós e voltar a associar-se automaticamente ao cluster e iniciar o respetivo serviço de cluster.
No Azure Stack HCI e no Windows Server 2019, existem dois componentes do sistema que têm os seus próprios mecanismos de quórum:
- Quórum do Cluster: isto funciona ao nível do cluster (ou seja, pode perder nós e fazer com que o cluster permaneça em cima)
- Quórum do Conjunto: isto funciona ao nível do conjunto (ou seja, pode perder nós e unidades e manter o conjunto em pé). Os agrupamentos de armazenamento foram concebidos para serem utilizados em cenários agrupados e não agrupados, razão pela qual têm um mecanismo de quórum diferente.
Descrição geral do quórum do cluster
A tabela abaixo apresenta uma descrição geral dos resultados do quórum do cluster por cenário:
| Nós de servidor | Pode sobreviver a uma falha de nó do servidor | Pode sobreviver a uma falha de nó do servidor e, em seguida, a outra | Pode sobreviver a duas falhas simultâneas do nó do servidor |
|---|---|---|---|
| 2 | 50/50 | No | No |
| 2 + Testemunha | Yes | No | No |
| 3 | Yes | 50/50 | No |
| 3 + Testemunha | Yes | Yes | No |
| 4 | Yes | Yes | 50/50 |
| 4 + Testemunha | Yes | Yes | Yes |
| 5 e superior | Yes | Yes | Yes |
Recomendações de quórum do cluster
- Se tiver dois nós, é necessária uma testemunha.
- Se tiver três ou quatro nós, a testemunha é vivamente recomendada.
- Se tiver cinco nós ou mais, uma testemunha não é necessária e não fornece resiliência adicional.
- Se tiver acesso à Internet, utilize um testemunho na cloud.
- Se estiver num ambiente de TI com outras máquinas e partilhas de ficheiros, utilize um testemunho de partilha de ficheiros.
Como funciona o quórum do cluster
Quando os nós falham ou quando algum subconjunto de nós perde o contacto com outro subconjunto, os nós sobreviventes têm de verificar se constituem a maioria do cluster para permanecer online. Se não conseguirem verificar, 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 num cluster de cinco nós). E os clusters com um número par de nós (por exemplo, um cluster de quatro nós)?
Existem duas formas de o cluster tornar o número total de votos ímpar:
- Primeiro, pode subir um ao adicionar uma testemunha com um voto extra. Isto requer a configuração do utilizador.
- Ou, pode descer um ao zero o voto de um nó azarado (acontece automaticamente conforme necessário).
Sempre que os nós sobreviventes verificarem com êxito se são a maioria, a definição da maioria é atualizada para estar entre apenas os sobreviventes. Isto permite que o cluster perca um nó, depois outro, depois outro, etc. Este conceito do número total de votos a adaptar-se após falhas sucessivas é conhecido como Quórum dinâmico.
Testemunho dinâmico
A testemunha dinâmica alterna o voto da testemunha para garantir que o número total de votos é estranho. Se houver um número estranho de votos, a testemunha não tem voto. Se houver um número par de votos, a testemunha tem um voto. O testemunho dinâmico reduz significativamente o risco de o cluster ficar inativo devido à falha do testemunho. O cluster decide se deve utilizar o voto de testemunho com base no número de nós de voto disponíveis no cluster.
O quórum dinâmico funciona com um testemunho dinâmico da forma descrita abaixo.
Comportamento de quórum dinâmico
- Se tiver um número par de nós e nenhum testemunho, um nó terá o seu voto zero. Por exemplo, apenas três dos quatro nós obtêm votos, pelo que o número total de votos é três e dois sobreviventes com votos são considerados maioria.
- Se tens um número estranho de nós e nenhuma testemunha, todos eles recebem votos.
- Se tiver um número par de nós mais testemunha, a testemunha vota, então o total é estranho.
- Se tiver um número estranho de nós mais testemunha, a testemunha não vota.
O quórum dinâmico permite atribuir um voto a um nó dinamicamente para evitar perder a maioria dos votos e permitir que o cluster seja executado com um nó (conhecido como último homem de pé). Vejamos um cluster de quatro nós como exemplo. Suponha que o quórum requer 3 votos.
Neste caso, o cluster teria desativado se tivesse perdido dois nós.
No entanto, o quórum dinâmico impede que isto 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 o quórum dinâmico, o cluster mantém-se atualizado mesmo que perca três nós.
O cenário acima aplica-se a um cluster geral que não tem Espaços de Armazenamento Direto ativado. No entanto, quando Espaços de Armazenamento Direto está ativada, o cluster só pode suportar duas falhas de nós. Isto é explicado mais na secção quórum do conjunto.
Exemplos
Dois nós sem uma testemunha
O voto de um nó está nulo, pelo que a maioria dos votos é determinada a partir de um total de 1 votos. Se o nó que não vota cair inesperadamente, o sobrevivente tem 1/1 e o cluster sobrevive. Se o nó de voto cair inesperadamente, o sobrevivente tem 0/1 e o cluster fica inativo. Se o nó de voto for corretamente desligado, a votação será transferida para o outro nó e o cluster sobreviverá. É por isso que é fundamental configurar um testemunho.
- Pode sobreviver a uma falha do servidor: 50% de probabilidade.
- Pode sobreviver a uma falha do 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, pelo que a maioria é determinada num total de 3 votos. Se um dos nós 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 e, em seguida, 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, pelo que a maioria é determinada num total de 3 votos. Se algum nó cair, os sobreviventes são 2/3 e o aglomerado sobrevive. O cluster torna-se dois nós sem um testemunho – nessa altura, está no Cenário 1.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha de servidor e outra: 50% de probabilidade.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Não.
Três nós com uma testemunha
Todos os nós votam, por isso 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 um testemunho , que está de volta ao Cenário 2. Então, agora os dois nós e o voto da testemunha.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do 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ó está nulo, pelo que a maioria é determinada num total de 3 votos. Após uma falha, o cluster torna-se três nós e está no Cenário 3.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do servidor e, em seguida, a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: 50% de probabilidade.
Quatro nós com uma testemunha
Todos os nós votam e os votos das testemunhas, pelo que a maioria é determinada num total de 5 votos. Após uma falha, está no Cenário 4. Após duas falhas simultâneas, avance para o Cenário 2.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do 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 fizer o total estranho. Espaços de Armazenamento Direto não consegue lidar com mais de dois nós, por isso, neste momento, não é necessária nenhuma testemunha ou útil.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do servidor e, em seguida, a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Sim.
Agora que compreendemos como funciona o quórum, vamos analisar os tipos de testemunhas de quórum.
Tipos de testemunho de quórum
O Clustering de Ativação Pós-falha suporta três tipos de Testemunhas de Quórum:
- Cloud Witness - Armazenamento de blobs no Azure acessível por todos os nós do cluster. Mantém as informações de clustering num ficheiro de witness.log, mas não armazena uma cópia da base de dados do cluster.
- Testemunho de Partilha de Ficheiros – uma partilha de ficheiros SMB configurada num servidor de ficheiros com o Windows Server. Mantém as informações de clustering num ficheiro de witness.log, mas não armazena uma cópia da base de dados do cluster.
- Testemunho de Disco – um pequeno disco agrupado que se encontra no grupo Armazenamento Disponível do Cluster. Este disco está altamente disponível e pode efetuar a ativação pós-falha entre nós. Contém uma cópia da base de dados do cluster. Um Testemunho de Disco não é suportado com Espaços de Armazenamento Direto.
Descrição geral do quórum do conjunto
Acabámos de falar do quórum do cluster, que funciona ao nível do cluster. Agora, vamos aprofundar o quórum do conjunto, que funciona ao nível do conjunto (ou seja, pode perder nós e unidades e fazer com que o conjunto permaneça em pé). Os agrupamentos de armazenamento foram concebidos para serem utilizados em cenários em cluster e não agrupados, razão pela qual têm um mecanismo de quórum diferente.
A tabela abaixo apresenta uma descrição geral dos resultados do quórum do conjunto por cenário:
| Nós do servidor | Pode sobreviver a uma falha de nó do servidor | Pode sobreviver a uma falha de nó do servidor e, em seguida, a outro | Pode sobreviver a duas falhas simultâneas do nó do servidor |
|---|---|---|---|
| 2 | Yes | No | No |
| 2 + Testemunho | Yes | No | No |
| 3 | Yes | No | No |
| 3 + Testemunho | Yes | No | No |
| 4 | Yes | No | No |
| 4 + Testemunho | Yes | Yes | Yes |
| 5 e superior | Yes | Yes | Yes |
Como funciona o quórum do conjunto
Quando as unidades falham ou quando algum subconjunto de unidades perde o contacto com outro subconjunto, as unidades sobreviventes que alojam metadados têm de verificar se constituem a maioria do conjunto para permanecerem online. Se não conseguirem verificar, ficarão offline. O conjunto é a entidade que fica offline ou permanece online com base no facto de ter discos suficientes para quórum (50% + 1). A base de dados do cluster pode ser o +1, desde que o próprio cluster seja quorate.
Mas o quórum do conjunto funciona de forma diferente do quórum do cluster das seguintes formas:
- O conjunto seleciona um subconjunto de unidades por nó para alojar metadados
- O conjunto utiliza a base de dados do cluster para quebrar os laços
- O conjunto não tem quórum dinâmico
- O conjunto não implementa a sua própria versão de remoção de um voto
Exemplos
Quatro nós com um esquema 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 do recurso do agrupamento). 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 agrupamento, que é 16/09 votos. Então, a piscina sobrevive.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do servidor e, em seguida, a outra: Sim.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Sim.
Quatro nós com um esquema simétrico e uma falha na unidade
Cada uma das 16 unidades tem um voto e o nó 2 também tem um voto (uma vez que é o proprietário do recurso do agrupamento). A maioria é determinada de um total de 16 votos. Primeiro, a unidade 7 vai para baixo. Se os nós três e quatro descerem, o subconjunto sobrevivente tem 7 unidades e o proprietário do recurso do agrupamento, que é de 8/16 votos. Então, a piscina não tem maioria e vai para baixo.
- Pode sobreviver a uma falha do servidor: Sim.
- Pode sobreviver a uma falha do servidor e, em seguida, a outra: Não.
- Pode sobreviver a duas falhas de servidor ao mesmo tempo: Não.
Recomendações de quórum do conjunto
- Certifique-se de que cada nó no cluster é simétrico (cada nó tem o mesmo número de unidades)
- Ative o espelho tridirecional ou a paridade dupla para que possa tolerar duas falhas de nós e manter os discos virtuais online.
- Se mais de dois nós estiverem inativos ou dois nós e um disco noutro nó estiverem inativos, os volumes poderão não ter acesso às três cópias dos respetivos dados, pelo que serão colocados offline e indisponíveis. É recomendado trazer de volta os servidores ou substituir os discos rapidamente para garantir a maior resiliência para todos os dados no volume.