Tradicionalmente diretores, presidentes e os “donos” do negócio querem (e estão muito certos nesse ponto) otimizar os investimentos realizados para terem garantia de disponibilidade, segurança, alta performance e outros, evitando que equipamentos fiquem ociosos ou subutilizados. Quando o investimento em questão é realizado em uma solução para alta disponibilidade do SQL Server, uma das opções é a utilização do Windows server Failover Cluster (WSFC), rodando instalações clusterizadas do SQL Server (Failover Cluster Instances).

Originalmente o SQL Server Failover Cluster Instances, trabalha de forma a agrupar um conjunto de recursos (disco, nome virtual, serviços, MSDTC, etc) e trabalhar de forma “ativa” em um servidor (NODE) por vez, deixando os demais servidores do WSFC em estado “passivo”, aguardando por uma falha para que seguindo regras de configurações de propriedades como “preferred owner” e “possible owner” possam assumir automaticamente uma “ROLE” onde o SQL Server FCI passe a estar em execução.

Uma das formas de se evitar que um ou mais servidores fiquem ociosos simplesmente aguardando a falha do servidor onde o SQL Server está ativo, é realizar a configuração cruzada do cluster, onde uma instância clusterizada (SQL1) ativa em um servidor A tenha o servidor B como passivo, e uma outra instância clusterizada (SQL2) ativa no Servidor B tenha o servidor A como passivo.

NÃO EXISTE CLUSTER ATIVO x ATIVO COM SQL SERVER FCI

d

O problema

Um grande problema em configurar um cluster cruzado com vários NODES e várias instâncias FCI do SQL Server, é que eventualmente duas ou mais instâncias críticas podem estar ativas no mesmo servidor físico, o que pode causar depreciação na performance, dependendo do workload dessas instâncias, e em horários de pico de processamento, pode gerar grandes transtornos aos usuários finais de aplicações possivelmente críticas.

Exemplos do cenário supracitado

A imagem acima mostra (CENÁRIO NORMAL) um ambiente com 3 servidores físicos rodando 3 instâncias SQL Server FCI, cada instância ativa em um servidor distinto e tendo os dois outros como NODES passivos.

d

Já no CENÁRIO DE FAILOVER, o NODE 1 teve um problema fazendo com que a instância SQL-CRIT-01 que é crítica, fosse movida para o NODE 2, onde já se encontrava o SQL-CRIT-02 que também é uma instância crítica com workload pesado, quando o ideal seria que o move fosse direcionado para o NODE 3, onde encontra-se atualmente o SQL-LIGHT-01 que é uma instância com workload baixo e com baixa criticidade, conforme representado pela imagem abaixo.

d

Contornando o problema

Uma das principais soluções para o problema exposto é a utilização de uma propriedade do WSFC, a AntiAffinityClassNames que permite que através da configuração de uma string qualquer, quaisquer ROLES do cluster que tenham uma determinada string idêntica configurada para essa propriedade, preferencialmente não fiquem ativas no mesmo NODE do cluster, evitando-se assim uma sobrecarga de um servidor específico e degradação na performance de aplicações críticas.

Seguindo a ordem configurada em “prefferred owner” a(s) instância(s) ativa(s) no NODE que falhou fará o failover para o próximo na lista de preferência, caso já uma dessas instâncias possua uma string AntiAffinityClassNames, o próximo NODE da lista é escolhido para ser o destino do failover dessa instância.

Caso não existam NODES disponíveis para atender à preferencialidade de que duas instâncias com a mesma string na propriedade AntiAffinityClassNames, não fiquem juntas no mesmo NODE, esta propriedade é simplesmente ignorada e então as instâncias ficarão online (mesmo que com possível degradação de performance) no mesmo NODE.

Para configurar a propriedade, siga os passos abaixo:

• Abra o Powershell com elevação de privilégios (Administrador) e com permissões para alterar propriedades no cluster.
• Execute o comando abaixo, para alterar a propriedade.
• • PS C:\Users\BTS-NOTE> (Get-Cluster NOMEDOSEUCLUSTER | Get-ClusterGroup “SQL-CRIT-01“).AntiAffinityClassNames = “Qualquer Texto Aqui”
• • PS C:\Users\BTS-NOTE> (Get-Cluster ORACLE_WEAK | Get-ClusterGroup “SQL-CRIT-01“).AntiAffinityClassNames = “Qualquer Texto Aqui”

• Para verificar que a propriedade foi corretamente configurada, execute também via powershell o comando abaixo:
• • PS C:\Users\BTS-NOTE> Get-Cluster NOMEDOSEUCLUSTER | Get-ClusterGroup | ft Name, AntiaffinityClassNames -AutoSize

Também é possível utilizar o programa cluster.exe para realizar a alteração, porém o mesmo encontra-se com status de “deprecated“, e deve ser descontinuado em breve, por este motivo, estou mostrando apenas exemplos de configuração via powershell.

No link abaixo, há um mapeamento de todos os comandos do cluster.exe para o powershell, que deve substituí-lo em breve.

https://technet.microsoft.com/pt-br/library/ee619744(v=ws.10).aspx

d

E por último, também é possível fazer a configuração via alteração direta nas chaves de registro, o que torna o processo arriscado e mais complexo. Resumindo, quer fazer, use o powershell =).

Espero que tenha gostado, se chegou até aqui, deixe seu joinha (ou crítica) nos comentários.

Até o próximo…

d

Referências

• https://msdn.microsoft.com/en-us/library/aa369651(v=vs.85).aspx
• PowerShell module for configuring AntiAffinityClassNames in Failover Clustering