Artículo
· 7 dic, 2023 Lectura de 4 min

El Balanceador de Carga de Azure (ILB) con HealthShare

Introducción

Con frecuencia nos encontramos con problemas de conectividad en las implementaciones de HealthShare (HS) en Microsoft Azure que tienen varios componentes de HealthShare (instancias o namespaces) instalados en la misma máquina virtual, especialmente cuando es necesario comunicarse con otros componentes de HS mientras se utiliza el balanceador de carga interno de Azure (ILB) para proporcionar la funcionalidad VIP (Virtual IP) de Mirroring. Los detalles sobre cómo y por qué se usa un balanceador de carga con Mirroring los podéis encontrar en este artículo de la Comunidad.

Según la documentación del Balanceador de Carga de Azure, el comportamiento predeterminado es el siguiente:

...si un flujo saliente de una máquina virtual del backend intenta establecer un flujo hacia el frontend del Balanceador de Carga interno en el que reside y se mapea de nuevo a sí mismo, ambos tramos del flujo no coincidirán y el flujo fallará.


Por lo tanto, en una implementación de HealthShare que tiene varias instancias o namespaces en una máquina virtual dada, en el conjunto de servidores del Balanceador de Carga Interno que necesitan comunicarse entre sí, se producirá un error.  Por ejemplo, este es un escenario con una instancia primaria (mirror) de HealthShare Unified Care Record (UCR) Registry y otra instancia primaria (mirror) de HealthShare Patient Index, ambas en la misma máquina virtual Azure.

   

En el ejemplo anterior, el UCR Registry inicia una conexión a 10.0.1.100 para poder comunicarse con la instancia de Patient Index. Hay un 50% de posibilidades de que esta conexión falle dependiendo de si los miembros primarios del mirror de las instancias están en el mismo servidor (10.0.1.10 en este caso).

Esta conexión falla porque el comportamiento NAT predeterminado de Azure ILB no realiza la Traducción de Direcciones de Red en Origen (Source-NAT o SNAT) y se conserva la IP de origen original. Los detalles están disponibles en el mismo enlace a la documentación de Microsoft:

Cuando el flujo se mapea de nuevo a sí mismo, el flujo saliente parece originarse desde la máquina virtual hacia el frontend y el flujo entrante correspondiente parece originarse desde la máquina virtual hacia sí mismo...  


Concretamente, el comportamiento predeterminado del ILB de Azure es el siguiente:

  • El Balanceador Interno de Azure no realiza la Traducción de Direcciones de Red en Origen (Source-NAT), por lo que se conserva la IP de origen original
  • Cuando se utiliza el conjunto de reglas predeterminado del balanceador de carga del DSR (alias la "IP flotante") deshabilitado, sí realiza la Traducción de Direcciones de Red en Destino (Destination-NAT o DNAT)

Lo que resulta en lo siguiente (de nuevo en el mismo enlace a la documentación de Microsoft):

Desde el punto de vista del SO huésped, las partes entrantes y salientes del mismo flujo no coinciden dentro de la máquina virtual. La pila TCP no reconocerá estas mitades del mismo flujo como parte del mismo flujo ya que el origen y el destino no coinciden.

Solución alternativa

Hay varias opciones disponibles para solucionar este problema del Balanceador Interno de Azure. En este artículo nos centraremos en un solo enfoque.

Añadir una segunda Tarjeta de Red (NIC)

Sólo son necesarios dos pasos para realizarlo:

  • Añadir una segunda NIC a la máquina virtual con una dirección IP diferente (en el siguiente diagrama se añadió una NIC y una dirección de .11)
  • Configurar una ruta estática local (a nivel del SO) forzando el tráfico destinado al VIP del Balanceador (10.0.1.100) desde el NIC secundario.  

 

Esto permite que la comunicación se realice correctamente ahora que el backend-to-frontend tiene una dirección IP de origen (10.0.1.11) y de destino (10.0.1.100 > DNAT > 10.0.1.10) diferente.

// show multiple NIC
c:\pstools>ipconfig | findstr /i "ipv4"
   IPv4 Address. . . . . . . . . . . : 10.1.0.10
   IPv4 Address. . . . . . . . . . . : 10.1.0.11
 
// static route traffic destined to LB front end out of second NIC
c:\pstools>route add 10.1.0.100 mask 255.255.255.255 10.1.0.1 if 18   ('if 18' indicates the interface to use for the outbound traffic)
 OK!


Nota. - La sintaxis exacta de vuestro comando "route add" variará dependiendo de la topología exacta de vuestra red y subred. Este ejemplo se ofrece solo con fines ilustrativos. Consultad la documentación sobre el comando Route en Windows y en Red Hat Enterprise Linux.

Comentarios (0)1
Inicie sesión o regístrese para continuar