Cluster AlwaysOn do MS SQL 2016 no failover do Win2012R2 - AGs se a Testemunha de Compartilhamento de Arquivos estiver inativa

Question

Nossa configuração atual inclui:

• oito (8) nós do Windows 2012 R2 em um único cluster de failover, sem armazenamento compartilhado, testemunha de compartilhamento de arquivos (no DC)

• MS SQL 2016 AlwaysOn com alguns grupos de AG

• políticas padrão 'Se o recurso falhar'

Relatório de validação de cluster mostra alguns avisos menores (diferença nas atualizações, etc.), mas no geral tudo parece estar bem.

Recentemente, devido a aproximadamente meia hora de inatividade de DC e a consequente indisponibilidade de Testemunha de Compartilhamento de Arquivo, um dos AGs faliu. O que não é exatamente o que esperávamos, já que nossa ideia era que o quorum dos oito nós ainda persistia, portanto, nenhum failover era esperado.

Depois de ler aparentemente toda a documentação disponível sobre quorum / FSW / etc, ainda não tenho uma resposta clara ou entender por que o failover aconteceu.

Os registros de eventos do FC contêm, entre outros, a seguinte ambigüidade:

FailoverClustering Event ID:1069 Resource Control Manager

Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed.

Based on the failure policies for the resource and role, the cluster service may try to bring the resource online on this node or move the group to another node of the cluster and then restart it. Check the resource and group state using Failover Cluster Manager or the Get-ClusterResource Windows PowerShell cmdlet.

No nó que trocou para secundário (NODE5), o log de eventos do sistema contém:

16.03.2017 12:39:47 Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed due to an attempt to block a required state change in that cluster resource.

16.03.2017 12:39:47 File share witness resource 'File Share Witness' failed to arbitrate for the file share '\DC\CLUSTER'. Please ensure that file share '\DC\CLUSTER' exists and is accessible by the cluster.

16.03.2017 12:39:48 The Cluster service failed to bring clustered role 'Cluster Group' completely online or offline. One or more resources may be in a failed state. This may impact the availability of the clustered role.

16.03.2017 12:39:48 Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed due to an attempt to block a required state change in that cluster resource.

16.03.2017 12:39:48 File share witness resource 'File Share Witness' failed to arbitrate for the file share '\DC\CLUSTER'. Please ensure that file share '\DC\CLUSTER' exists and is accessible by the cluster.

E log de eventos do Cluster de Failover:

Cluster resource 'File Share Witness' in clustered role 'Cluster Group' has transitioned from state Terminating to state Failed.

<...>

The Cluster service is attempting to fail over the clustered role 'Cluster Group' from node 'NODE5' to node 'NODE6'.

<...>

Clustered role 'db5' is moving to cluster node 'NODE6'.

Na minha opinião, isso basicamente significa que o failover foi causado pelo fato de o File Share Witness ter ficado offline. Mas por quê?

E estamos imaginando se existem maneiras de corrigir esse comportamento. Qualquer esclarecimento ou conselho é bem-vindo, obrigado!

    

Answer 1

To my mind this basically means that the failover was caused by the fact that File Share Witness gone offline. But - why?

Não é isso que significa. Lendo os logs que foram postados, posso ver que o grupo de clusters principais falhou em outro nó (na esperança de que ele conserte o problema de conectividade com a testemunha), no entanto, não há nada em relação ao SQL Server. Você precisará encontrar onde os logs do SQL Server tiveram a falha e rastreá-los de volta para ver por que o cluster decidiu iniciar uma falha automática.

O fato de que ocorreu uma falha automática significa que o cluster tinha quorum. Se isso não ocorresse, a falha automática não teria acontecido.

And we're wondering are there ways to fix this behaviour. Any clarification or advice is welcome, thanks!

Nada a corrigir, já que isso não está acontecendo. Olhe no log para ver qual foi o motivo da falha automática, por isso falhou - não porque não foi possível verificar o FSW.