Estamos planejando atualizar nosso SQL 2012 para SQL 2014. Atualmente, usamos um espelho para nossos bancos de dados de produção, mas estamos planejando mudar para grupos de disponibilidade. Estaremos executando 2 SQL Servers em nosso site primário e uma única réplica assíncrona em DR.
Nosso link para DR às vezes é bastante irregular e, portanto, não queremos contar com DR para ter um quorum, que também é o conselho da Microsoft: https://msdn.microsoft.com/en-us/library/hh270280. aspx . Para fornecer um número ímpar de votos, estamos planejando ter uma maioria de compartilhamento de arquivos e nós (2 nós + 1 compartilhamento de arquivos no site primário = 3 votos).
Algumas vezes por ano, precisamos fazer failover para DR, seja para teste ou devido ao trabalho de manutenção (Elétrico/Conectividade/etc) em nosso site principal.
Para fazer failover para DR, podemos definir a réplica de DR para ser síncrona, esperar que ela seja atualizada e, em seguida, fazer o failover usando um script ou o assistente de failover. Configurei um teste usando 4 servidores em Hyper-v (3x SQL + 1x AD). Assim que faço o failover para DR e, em seguida, desligo os SQL Servers, o cluster fica offline.
Percebo que o mesmo artigo msdn que mencionei acima diz
• Reavalie as atribuições de voto após o failover. Você não deseja fazer failover em uma configuração de cluster que não oferece suporte a um quorum íntegro.
Quais seriam os melhores ajustes a serem feitos para manter o quorum após um failover planejado para DR e o site Primário ficar completamente offline (incluindo os 2 nós SQL primários e o compartilhamento de arquivo)?
Parece que a resposta é Server 2012 R2. 2012 R2 inclui apenas o compartilhamento de arquivos quando há um número par de nós. Portanto, se o DR ficar offline, o compartilhamento de arquivos será incluído no quorum até o momento em que o DR volte a ficar online.
Também parece do teste que, se você desligar normalmente as conexões no secundário, o primário permanecerá ativo. Portanto, executar a partir do DR para uma interrupção planejada significa que poderíamos fazer o failover normalmente e, em seguida, desligar os servidores no site principal. Como o DR se tornou o principal, ele permanecerá ativo como o último nó em pé até o momento em que o quorum for restaurado (e a sincronização for concluída)