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:

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:

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):

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.

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.