Cenário:
Cluster de três nós (nada compartilhado) no Windows Server 2012. Dois nós no data center principal, ambos com votos (peso do nó = 1) e uma testemunha de compartilhamento de arquivos. O terceiro nó está em um data center remoto e não tem votos (peso do nó de 0).
Problema: Um nó de cluster (que possuía o nome do cluster) foi desativado para atualizações automáticas. O nome do cluster falhou no nó do datacenter remoto e o nó remoto pôde obter um bloqueio no arquivo testemunha de compartilhamento de arquivos. Nesse momento, o nosso túnel VPN caiu. O único nó que estava no data center principal (e tinha serviços em execução) percebeu que o nó do cluster remoto estava inativo e tentou colocar o nome do cluster online. O arquivo testemunha de compartilhamento de arquivos ainda estava bloqueado pelo nó remoto, e o nó de cluster visível em execução no data center primário não conseguiu colocar o nome do cluster online e encerrou o serviço de cluster em si mesmo.
Advertências: Firewalling do compartilhamento de arquivos do nó remoto não é uma opção devido a outros processos que o utilizam.
Eu considerei tentar remover o nó do cluster remoto de possíveis proprietários do nome do cluster, mas eu não fiz ou testei isso antes e não quero explodir meu cluster de produção. É possível remover um nó de cluster de possíveis proprietários para o nome do cluster? Se tivermos que descartar nossos serviços para o datacenter remoto, haverá várias partes móveis que precisam ser coordenadas, portanto, não quero um failover de serviço "automatizado" para o data center remoto. A razão pela qual o nó remoto está em um cluster é para os Grupos de Disponibilidade do SQL Server, para gerenciar a replicação para o nó remoto.
Eu também considerei remover a testemunha de compartilhamento de arquivos e dar um voto ao nó remoto. O novo quorum dinâmico "deve" manter o cluster online se um nó ficar inativo por uma reinicialização e a conectividade de rede for perdida para o centro de dados remoto.
Dado meu cenário, qual opção (ou outras alternativas) me dará a maior disponibilidade.
Eu realmente gosto de dar um voto ao nodo remoto porque isso tornaria os failovers planejados muito mais fáceis. Você pode migrar bancos de dados & recursos para o datacenter remoto e, em seguida, desligue gradualmente os nós no datacenter principal, e você não precisaria mexer com a votação para que ela funcionasse. Além disso, você não está preocupado com a alta disponibilidade no compartilhamento de arquivos.
Então eu estou com o Brent aqui. Eu nunca fui um fã de remover um nó como eleitor, a menos que você esteja absolutamente 100% certo de que você não se importa com isso. A única coisa que você deve se esforçar para fazer é manter o grupo de clusters WSFC onde sua réplica primária deve evitar dividir o cérebro.
Remover o nó do cluster como um possível proprietário do WSFC é uma má ideia. Se você precisar fazer isso, remova o nó do cluster. Majo ruim e ruim.
Com o Windows Server 2012, você também tem quorum dinâmico, a menos que suas falhas sejam simultâneas, você pode ir ao último homem (com avisos, é claro).
Além disso, resolvo problemas de rede. Eles serão assassinos em uma situação geograficamente dispersa, como você pode ver.