O que fazer quando o cluster Always On perde o quorum?

Eu estava revisando os procedimentos de DR de nossa empresa e, quando procurava on-line por soluções para um quorum de perda do Always On Cluster, para comparar. Eu estava com três páginas nos resultados do google antes de encontrar a primeira publicação do SE sobre o assunto Clustering vs. replicação transacional vs. grupos de disponibilidade, que abordam apenas levemente o assunto de quorum perdido.

Embora todos concordem que o quorum perdedor é ruim, e existem algumas sugestões para diminuir o potencial, ele ainda pode acontecer. Estou procurando uma boa resposta revisada por pares para o melhor caminho para a recuperação de uma perda de quorum do cluster Always On.

Os AGs são baseados no Windows Clustering. Os procedimentos do WSFC para perda de quorum se aplicam.

• Recuperação de falhas do WSFC por meio de quorum forçado
• Forçar um cluster do WSFC a iniciar sem um quorum

Depois que o WSFC estiver em execução, você poderá forçar o AG, se necessário. Execute um failover manual forçado de um grupo de disponibilidade :

Após forçar o quorum no cluster do WSFC (quorum forçado), é necessário forçar o failover em cada grupo de disponibilidade (com possível perda de dados). É necessário forçar o failover porque o estado real dos valores do cluster WSFC pode ter sido perdido. No entanto, você pode evitar a perda de dados se forçar o failover na instância do servidor que hospedava a réplica que era a réplica principal antes de você forçar o quorum ou em uma réplica secundária que foi sincronizada antes de você forçar o quorum. Para obter mais informações, consulte Maneiras potenciais de evitar a perda de dados após o quorum ser forçado .

O que fazer quando o cluster AlwaysOn perde o quorum?

Eu já estive nessa situação especialmente com o clustering de várias sub-redes em diferentes países (NY-LD-HK).

Como evitar a perda de quorum em um cluster de várias sub-redes?

• Altere a configuração padrão do cluster para um estado de monitoramento mais descontraído, especialmente as configurações de Pulsação de Cluster usando CrossSubnetDelayou a CrossSubnetThresholdpropriedade desse hotfix .
• A AG usa o WSFC, que usa a abordagem baseada em quorum para determinar a integridade do cluster. Certifique-se de escolher e configurar adequadamente o quorum . Esta postagem do blog mergulha mais fundo na configuração de votação do Quorum para o AlwaysON

• As coisas mudam no Windows server 2016 com a introdução de clusters com reconhecimento de site e testemunha na nuvem .

  Os nós em clusters estendidos agora podem ser agrupados com base em sua localização física (site). O reconhecimento de site do cluster aprimora as principais operações durante o ciclo de vida do cluster, como comportamento de failover, políticas de posicionamento, pulsação entre os nós e comportamento do quorum.

  O Cloud Witness é um novo tipo de testemunha de quorum do Failover Cluster que utiliza o Microsoft Azure como ponto de arbitragem. Ele usa o Armazenamento de Blob do Microsoft Azure para ler / gravar um arquivo de blob que é usado como um ponto de arbitragem em caso de resolução de cérebro dividido.

O que fazer quando o Quorum está perdido?

• Se o cluster ficar inativo devido a uma interrupção / desastre não planejada, será necessária uma intervenção manual. Um administrador do Windows ou um administrador de cluster precisa forçar manualmente o quorum (vinculando à resposta do @ Remus, conforme aborda esse ponto) e colocar os nós sobreviventes online.

Como sempre, para fazer uma análise de causa raiz (RCA), reúna os logs do cluster do Windows para o AlwaysON RCA - use os logs de diagnóstico do cluster de failover do SQL Server . Estes arquivos no diretório SQL Server Log ter o seguinte formato: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Uma vez eu estive envolvido em uma interrupção em que nossos servidores espelhados perderam a conectividade. Uma das coisas com que se preocupar é garantir que seus aplicativos sejam apontados para uma única instância. Em uma interrupção de rede, é possível ter todos os nós de um cluster Always On ativos, mas não é possível se comunicar. Você força um failover para um secundário e, desde que haja uma interrupção, você pode ter dois nós primários, pois o primário original não saberá sobre o failover forçado.

Dependendo dos locais dos servidores de aplicativos, da configuração e da capacidade de acessar um servidor SQL, em teoria, você pode ter dois nós acreditando que são primários e que os dados foram alterados ao mesmo tempo. Depois de corrigir os problemas de rede e os nós retomarem a conectividade, todos os dados alterados no primário original serão substituídos no nó para o qual o failover foi forçado. Isso pode resultar na perda de dados críticos.

Eu já vi essa situação uma vez com o SQL 2005 e o espelhamento. E decidimos não forçar o failover e deixá-lo inalcançável. Na pior das hipóteses, se tivéssemos que fazer backup e restaurar para reiniciar o espelhamento, seria um processo de dois dias para nós, com riscos de o log de transações ficar cheio e não conseguir expandir o disco no qual estava sentado.