Usamos um Grupo de Disponibilidade (AG) do SQL Server 2016 em um cluster de failover de várias sub-redes do Windows Server 2012 para HA/DR. Há dois nós em nosso datacenter de Nova York (sub-rede 10.7.xx) e um nó em nosso datacenter de Colorado (sub-rede 10.8.xx). O servidor Colorado é principalmente para recuperação de desastres ou manutenção estendida onde NY está offline, portanto, atualmente definimos o Quorum NodeWeight/Votes para o nó CO-SQL01 como zero para evitar que ele se aproprie automaticamente do cluster ou AG se houver algum problema .
Minha pergunta é esta: devemos alterar as configurações padrão no Gerenciador de cluster de failover, especificamente os proprietários preferenciais da função AG e os possíveis proprietários dos recursos IP do ouvinte AG? Os padrões usados parecem entrar em conflito com nossos objetivos de alta disponibilidade usando os dois nós em NY e usando apenas o nó CO para recuperação de desastres.
Aqui estão as configurações padrão para os proprietários preferenciais do nosso Multi-Subnet AG:
Devemos adicionar uma verificação ao lado de NY-SQL02 e movê-la acima de CO-SQL01 para que seja preferida? E quanto a outras funções, podemos definir os proprietários preferenciais dos recursos do cluster principal (como o nome do cluster)?
E aqui estão as configurações padrão para os recursos IP do SQL-StackOverflow_AG:
Devemos remover as marcas de seleção ao lado dos servidores que estão em uma sub-rede diferente desse endereço IP?
Essa pergunta surgiu em um horário comercial recente , mas é algo que pensamos que pode ajudar a evitar o tempo de inatividade quando nosso cluster tiver problemas. Recentemente, tivemos uma interrupção de 5 minutos quando substituímos nosso hardware de servidor CO-SQL01 e ele foi adicionado de volta ao cluster de failover (mas não ao AG) sem remover seu voto. O servidor CO-SQL01 sofreu uma falha grave (achamos que foi um bug do driver NVMe/PCIe sob carga pesada) e conseguiu derrubar o AG com ele (acreditamos que o CO-SQL01 se apossou dos recursos do cluster principal quando chegou de volta online).
Para ser honesto, tivemos vários problemas inesperados com o uso de grupos de disponibilidade de cluster de failover de várias sub-redes e parece que os proprietários de funções preferenciais padrão e os possíveis proprietários de recursos podem estar incorretos ou pelo menos não ideais para nosso cenário. Atualmente, estamos analisando o uso do novo recurso Distributed Availability Groups no SQL Server 2016 para dividir nosso AG de várias sub-redes em dois AGs de sub-rede únicos (um para cada datacenter) como forma de evitar esses problemas no futuro. Também achamos que isso nos permitirá atualizar o sistema operacional do cluster com o mínimo de tempo de inatividade .
NUNCA marque ou desmarque os proprietários preferenciais ou possíveis para recursos de AG. Ao usar o SQL Server 2016, a lista de proprietários preferenciais pode ser movida para cima e para baixo para controlar os destinos de failover preferenciais, devido à alteração de vários destinos de failover, mas nunca marque ou desmarque nenhuma caixa com Grupos de Disponibilidade. Período.
Se você marcar e desmarcar coisas assim, seu AG não funcionará corretamente. Quando ensino a aula do Grupo de Disponibilidade, sempre mostro como isso funciona, por que funciona e por que NUNCA queremos fazer isso (alerta de spoiler: o AG provavelmente falhará, difícil).
Deixe-me explicar isso, no entanto, para torná-lo um pouco mais claro.
Proprietários Preferenciais e Possíveis
Esses valores são definidos pelo SQL Server com base nas configurações do Grupo de Disponibilidade. O cluster tem sua própria cópia dos metadados de como as coisas devem funcionar e o SQL Server também tem uma cópia de como acredita que as coisas devem funcionar.
Isso é ótimo na maioria das vezes, quando ninguém muda nada e tanto o SQL Server quanto o cluster continuam a funcionar.
No entanto, o SQL Server sabe o que acredita que deve e não deve ser o proprietário dos recursos com base nas configurações do AG e reflete isso chamando APIs de cluster para definir o comportamento esperado. Você verá isso refletido no
HADR_CLUSAPI_CALLtipo de espera.Três réplicas assíncronas
Vejamos o SQL Server com uma configuração de AG para que haja três réplicas de confirmação assíncrona. Se fizermos isso, nosso recurso de AG e função deve ter a seguinte aparência:
Lembre-se, as réplicas de confirmação assíncrona não podem ter failover automático. Assim, isso faz sentido; nosso proprietário de função atual é o único proprietário possível e preferencial. Como o SQL Server está configurado para que a única maneira de fazer failover seja forçá-lo, não queremos que nenhuma outra réplica seja selecionada e comece a ser executada com isso, impondo isso no nível de cluster.
Dois failover manual síncrono, um assíncrono - Demo
Os resultados serão os mesmos da demonstração Three Async. Por quê?
Esta é a mesma explicação das três réplicas assíncronas, ainda não temos failover automático, então não queremos que ninguém assuma AUTOMATICAMENTE . Assim, as configurações são as mesmas.
Dois failover automático assíncrono, um assíncrono - Demo
Aqui é onde as coisas mudam e ficam interessantes! Como agora estamos introduzindo o failover automático - e essa é uma das funções do WSFC (junto com verificação de integridade, distribuição de metadados etc.) - vamos querer ter proprietários preferenciais e possíveis.
Outras respostas
Você removeu especificamente o voto do CO e só restava 1 outro eleitor e teve uma falha inesperada. Parece que estava funcionando como deveria.
Vou ser brutalmente honesto aqui. Os Grupos de Disponibilidade não são uma bala de prata, consertam tudo de HA e DR. Parece que a tecnologia está sendo usada, mas não se sabe muito sobre como ela funciona ou por que ela faz essas coisas tanto no nível AG quanto no nível WSFC, então concordo completamente que pode não estar configurado corretamente ... está funcionando como está configurado - não posso culpar o cluster por fazer o que deveria estar fazendo.
Se você está tendo tantos problemas com Grupos de Disponibilidade, eu não entraria em Grupos de Disponibilidade Distribuídos por conta própria. Pode ou não se adequar aos seus casos de uso - mas se eu fosse você, traria alguém que ajudasse a arquitetar esses tipos de soluções e ter seus casos de uso prontos. Caso contrário, você vai fazer outro post como este.
Um dos casos de uso para Grupos de Disponibilidade Distribuídos é para migrações entre clusters com tempo de inatividade extremamente baixo, você está correto. Se você estiver usando o Windows Server 2012R2, poderá fazer atualizações de cluster sem interrupção [NÃO disponível em 2012, deve ser R2] sem precisar fazer grupos de disponibilidade distribuídos.
Sim, não toque neles :) Deixe-os como estão.