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.
[caption id="" align="aligncenter" width="626"]
Imagem representando um cluster cruzado[/caption]
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
[caption id="" align="aligncenter" width="661"]
Instâncias distribuídas uniformemente em um cenário onde não há qualquer problema.[/caption]
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
[caption id="" align="aligncenter" width="729"]
Cenário com failover da instância SQL-CRIT-01, tendo a mesma sendo movia para um NODE impróprio para a situação.[/caption]
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
[caption id="" align="aligncenter" width="709"]
Cenário ideal, com a configuração da propriedade "AntiAffinityClassNames" nas instâncias críticas.[/caption]
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