Failover Cluster Heartbeat Explicado em 5 tópicos!

Olá Pessoal!

Estou postando alguns posts explicando como o Failover Cluster funciona, então não deixe de ver nosso artigo “10 conceitos que você precisa saber sobre Quorum de Cluster”

Agora vamos ao que importa:

Failover Cluster Heartbeat Explicado em 5 tópicos!

 

1.O Heartbeat valida a disponibilidade dos nós que fazem parte do Cluster

A função principal da comunicação hertbeat é garantir que todos os nós que fazem parte do cluster estão respondendo. Caso um nó não responda ao total de pacotes heartbeat definido como limite de tolerância, inicia-se uma operação chamada “Cluster Regroup”, que tem por finalidade validar se os nós responsivos constituem quorum suficiente para manter o serviço de cluster, e remover do grupo de membros os nós não responsivos, distribuindo os recursos afetados entre os demais e garantindo a disponibilidade das funções principais.

A comunicação heartbeat também serve para validar rotas de comunicação disponíveis, definindo os caminhos com melhor tempo de resposta para comunicação do cluster.

2. Não Existe uma “Rede de Heartbeat”

Existe um mecanismo chamado “NETFT” responsável por definir rotas de comunicação entre os nós do cluster baseado em todas as redes disponíveis e autorizadas  para comunicação. Desta forma, mesmo que uma das redes definidas para comunicação do cluster fique indisponível, o NETFT irá direcionar a comunicação do cluster para outra rede que permaneça disponível.

Por exemplo, imagine o cenário onde você possui 2 redes disponíveis para cada nós do cluster:

Cluster Interna – Destinada a comunicação exclusiva dos nós do cluster

Cluster and client – Disponível para comunicação com os clientes.

Note que na configuração da rede, ambas permitem a comunicação entre os nós do cluster:

3. A comunicação heartbeat consiste em pacotes de rede de 134 k, direcionada a porta UDP 3343 de cada nó do cluster, enviados por padrão a cada 1 segundo.

Embora exista um tráfego constante de heartbeat, o tamanho dos pacotes transitando na rede é muito pequeno, não resultando assim em alto consumo. Os pacotes de heartbeat são sensíveis a latência, neste contexto a taxa de banda é irrelevante, mas a qualidade de serviço (QoS) faz toda diferença.

Imagine que por padrão, a perda de 5 pacotes heartbeat consecutivos resulta no clusterregroup, failover dos recursos, e remoção do nó do grupo de membros ativos. Considerando 5 pacotes de 1 segundo, caso o nó do cluster fique 5 segundos não responsivo, ele é removido do grupo de nós ativos.

 

 

4. O intervalo de envio e tolerância de perda dos pacotes heartbeat pode ser customizado de acordo com as particularidades do ambiente

É possível definir configuração de intervalo e tolerância diferentes para nós que fazem parte da mesma rede e nós que estão alocados em redes diferentes.

Abaixo os valores padrões do Windows Server 2012 R2 e Widnows Server 2016:

SameSubnetDelay – Intervalo de heartbeat enviado para nós dentro da mesma rede

SameSubnetThreshould – Tolerância de pacotes perdidos antes de iniciar a operação de “cluster regroup”, e remover o nó não responsivo do grupo de nós ativos. Valido para nós dentro da mesma rede

CrossSubnetDelay – Intervalo de heartbeat enviado para nós em redes diferentes

CrossSubnetTrheshoud – Tolerância de pacotes perdidos antes de iniciar a operação de “cluster regroup”, e remover o nó não responsivo do grupo de nós ativos. Valido para nós em redes diferentes

CrossSiteDelay – Parâmetro exclusivo do Windows Server 2016, permite definir intervalo de heartbit entre nós em sites diferentes

CrossSiteTrheshould – Parâmetro exclusivo do Windows Server 2016, permite definir tolerância de perda de heartbeat entre nós de diferentes sites.

 

5. Para redes com alta latência, é recomendado “relaxar” os threshoulds de heartbeat

Embora a recomendação seja que exista ao menos 2 redes que permitam a comunicação do cluster, muitos ambientes não possuem essa possibilidade, e é ai que entra o desafio. Como garantir a resiliência dos pacotes de heartbeat em uma rede onde este tráfego é transmitido em conjunto com o consumo demais aplicações? Ou ainda, redes que possuem alta latência, como evitar failovers indevidos?

A única alternativa é customizar os threshoulds, de maneira a torna-los mais tolerantes.

Revisando os valores padões do Windows Server 2012 R2, podemos notar que o tempo de tolerância na comunicação de rede é de 5 segundos, tanto para nós na mesma rede, quanto nós em redes diferentes:

CrossSubnetDelay  1000

CrossSubnetThreshold  5

SameSubnetDelay  1000

SameSubnetThreshold  5

 

Uma alternativa aqui é customizar estes threshoulds para suportar 40 segundos de latência para nós no mesmo site, e 160 segundos em nós alocados em sites diferentes:

PS C:\Windows\system32> (get-cluster).SameSubnetDelay = 2000

PS C:\Windows\system32> (get-cluster).SameSubnetThreshold= 20

PS C:\Windows\system32> (get-cluster).CrossSubnetDelay= 4000

PS C:\Windows\system32> (get-cluster).CrossSubnetThreshold= 40

 

Referências

Tuning Failover Cluster Network Thresholds

Failover Cluster Communication Failures

No such thing as a Heartbeat Network

Configuring Windows Failover Cluster Networks

 

 

 

Dúvidas? Deixa ai nos comentários!

Deixe uma resposta

%d blogueiros gostam disto: