Azure Load Balancer (ILB) com o HealthShare

Visão geral

Muitas vezes enfrentamos problemas de conectividade com implantações do HealthShare (HS) no Microsoft Azure que possuem vários componentes do HealthShare (instâncias ou namespaces) instalados na mesma VM, principalmente quando precisamos nos comunicar com outros componentes do HS enquanto usamos o Azure Load Balancer (ILB) para fornecer a funcionalidade VIP de espelho.  Para detalhes sobre como e por que um balanceador de carga é usado com o espelhamento de banco de dados, confira este artigo da comunidade.

De acordo com a documentação do Azure Load Balancer, https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview#limitations, o comportamento padrão do Azure Internal Load Balancer é o seguinte:

Portanto, uma implantação do HealthShare com várias instâncias ou namespaces em uma determinada VM no pool de servidores do ILB que precisam se comunicar entre si falhará.  Por exemplo, aqui está um caso com a instância de espelho primário do Registro Unified Care Record (UCR) do HealthShare e a instância de espelho primário do HealthShare Patient Index, ambas na mesma VM do Azure.

No exemplo acima, o Registro UCR inicia uma conexão com 10.0.1.100 para que possa se comunicar com a instância do Patient Index. Há 50% de chance dessa conexão falhar, dependendo se os membros espelho primários de cada Patient Index e Registro UCR estão no mesmo host (10.0.1.10, nesse caso). 

Essa conexão falha porque o comportamento NAT padrão do ILB do Azure não executa o Source-NAT (SNAT) de entrada, e o IP de origem original é preservado. Os detalhes estão disponíveis no mesmo link da documentação da Microsoft acima:

Especificamente, o comportamento padrão do ILB do Azure é o seguinte:

• O ILB do Azure não executa o Source-NAT de entrada e, portanto, o IP de origem original é preservado
• Ao usar o conjunto de regras do balanceador de carga padrão para desabilitar o DSR (também conhecido como "IP flutuante"), ele executa o Destination-NAT (DNAT)

Isso resulta no seguinte (novamente, do link da documentação original acima):

Solução alternativa

Há várias opções disponíveis para solucionar esse problema do ILB do Azure, mas este artigo focará em apenas uma abordagem.

Adicionar um NIC secundário

São necessárias apenas duas etapas para fazer isso, da seguinte maneira:

• Adicione um NIC secundário à VM com um endereço IP diferente (no diagrama a seguir, um NIC e endereço de .11 foram adicionados)
• Configure o tráfego que força a rota estática (nível do SO) local destinado ao VIP do ILB (10.0.1.100) do NIC secundário

Isso permite que a comunicação seja bem-sucedida, agora que o back-end para o front-end tem endereços IP de origem (10.0.1.11) e destino diferentes (10.0.1.100 > DNAT > 10.0.1.10).

**Observação: a sintaxe do seu comando "route add" exato varia dependendo da sua rede exata e topologia de subnet.  Esse exemplo serve apenas para fins ilustrativos.  A documentação sobre o comando Route no Windows pode ser encontrada aqui e o Red Hat Enterprise Linux pode ser encontrado aqui.