Controlando seu failover cluster com a propriedade AntiAffinityClassNames

Quando configuramos um failover cluster é comum que utilizemos a propriedade de “preferred owners” para definir onde queremos que cada cluster group “resida” em caso de failover, seguindo uma lista sequencial dos “donos” preferenciais.

Preferred Owners

Veja na figura acima que, utilizando essa propriedade, podemos definir a ordem dos nós preferenciais através dos botões “Up” e “Down”, além de selecionar os nós na listagem.

O “problema” dessa configuração é que ela não previne, por exemplo, que dois serviços façam um failover para o mesmo nó, tornando o mesmo sobrecarregado, mesmo havendo um outro nó ainda “vago”.

Para tal situação podemos utilizar a propriedade “AntiAffinityClassNames”. Essa propriedade é uma lista de strings que por padrão vem com o valor NULL. Ela pode conter nenhum ou vários valores, definidos pelo usuário e funciona da seguinte forma.

Definimos para cada cluster group o valor de “AntiAffinityClassNames” e, no momento de um failover, os valores dessa propriedades do cluster group que tenta o failover para o nó e dos cluster groups que já estão no nó são comparados. Caso pelo menos um dos valores dessa propriedade coincidam, o cluster considera esses cluster groups “sem afinidade” e não permite que “residam” no mesmo nó, levando então o cluster group a tentar um outro nó, de acordo com a sequência definida em “preferred owners“.

Sendo assim, principalmente em ambientes onde temos N cluster groups e N+1 nós, ou seja, onde temos um nó de “hot spare“, podemos utilizar a propriedade “AntiAffinityClassNames” para garantir que um cluster group migre para o nó vazio ou preferencial, sem termos que controlar manualmente os failovers.

Imagine então um ambiente node temos três nós, N1, N2 e N3, e temos 2 cluster groups de SQL Server que vamos chamar de SQL1 e SQL2. Vamos considerar que o valor de “preferred owners” de cada cluster group esteja configurado dessa forma.

SQL1 – NÓ1, NÓ2, NÓ3

SQL2 – NÓ2, NÓ3, NÓ1

Vamos também considerar que SQL1 está em NÓ1 e que SQL2 está em NÓ2.

Para impedir que SQL1 e SQL2 residam no mesmo nó e, automaticamente migrem para o nó que estiver vazio, definiremos o valor de “AntiAffinityClassNames” de ambos os cluster groups para “SQL”.

Para definir o valor de “AntiAffinityClassNames” precisamos utilizar uma ferramenta de linha de comando, seja o cluster.exe, ou seja via powershell. No nosso caso o comando ficaria da seguinte forma:

cluster group “SQL1″ /Prop AntiAffinityClassNames=”SQL”
cluster group “SQL2″ /Prop AntiAffinityClassNames=”SQL”

Caso queira consultar o valor de “AntiAffinityClassNames” basta utilizar o comando

cluster group “nome do cluster group” /Prop

e seus valores ficam armazenados na chave de registro “Reg_Multi_SZ” em “HKEY_LOCAL_MACHINE\Cluster\Groups\Guid\AntiAffinityClassNames” como pode ser visto na figura abaixo:

AntiAffinityClassNames no Registro

Com esses valores configurados imagine então que haja um problema no NÓ1 fazendo com que o cluster group SQL1 que está hospedado no mesmo execute um failover.

Como o mesmo está no NÓ1 que é o primeiro NÓ de sua lista de “preferred owners“, ele vai então tentar migrar para o próximo da lista, NÓ2.

Ao tentar o failover para NÓ2, ele compara o valor de “AntiAffinityClassNames” do cluster group que deseja ir para tal nó (SQL1) e o valor da propriedade dos cluster groups que já estão em tal nó (SQL2).

Nesse exemplo, o cluster verá que há strings em ambos que coincidem, definindo então que não há afinidade entre os cluster groups e, então, tentará realizar o failover de SQL1 no próximo NÓ da lista de “preferred owners” deste, no caso, NÓ3.

Como não há serviço em NÓ3 o SQL1 migrará para o mesmo.

Agora imagine que haja um problema em NÓ2 e que o cluster group SQL2 precise também fazer um failover. Nesse caso, seguindo a sequência de “preferred owners“, ele irá tentar primeiro o NÓ3. Novamente, ao comparar os valores de “AntiAffinityClassNames”, ele verá que os cluster groups são incompatíveis e irá então migrar SQL2 para NÓ1, caso esse esteja disponível.

Ai vem uma característica importante! Caso NÓ1 não esteja disponível, “AntiAffinityClassNames” não impede que os dois cluster groups possam residir no mesmo nó, isso acontece apenas caso haja algum outro nó disponível para o failover. Sendo assim, em nosso exemplo, caso NÓ1 não estivesse disponível, SQL2 iria SIM para NÓ3.

Outra característica importante é que, imagine em nosso exemplo que NÓ1 e NÓ2 não estão disponíveis e SQL1 e SQL2 estão em NÓ3. Nesse caso temos 2 cluster groups “sem afinidade” residindo no mesmo nó. Caso um nó “com afinidade” para um ou ambos os cluster groups volte a funcionar, um destes irá AUTOMATICAMENTE realizar um failover para tal nó, evitando assim que cluster groups “sem afinidade” residam no mesmo nó.

Obs1: a propriedade “AntiAffinityClassNames” pode ser utilizada inclusive para controlar a localização de VMs em um ambiente de cluster Hyper-V!

Obs2: esse ambiente com N cluster groups e N+1 nós configurado da forma que fizemos também é conhecido como “floating hot spare“.

Artigos relacionados:

• http://msdn.microsoft.com/pt-br/library/windows/desktop/aa369651(v=vs.85).aspx
• http://blogs.technet.com/b/antiaffinityclassname_and_the_case_of_floating_hot_spare1/archive/2012/06/21/antiaffinityclassnames-and-the-case-of-floating-hot-spare.aspx
• http://support.microsoft.com/kb/296799/en-us
• http://www.windowsitpro.com/blog/virtualization-pro-tips-blog-35/virtualization2/need-to-separate-hyper-v-vms-use-antiaffinityclassname-137299