Alta disponibilidad y equilibrio de carga de los conectores y aplicaciones de red privada
En este artículo se explica cómo funciona la distribución del tráfico con la implementación de un proxy de aplicación. Aprenda cómo se distribuye el tráfico entre los usuarios y los conectores, junto con sugerencias para optimizar el rendimiento de los conectores. Aprenda cómo fluye el tráfico entre los conectores y los servidores de aplicaciones de back-end, con recomendaciones para el equilibrio de carga entre varios servidores de back-end.
Distribución del tráfico entre conectores
Los conectores establecen sus conexiones en función de principios de alta disponibilidad. No hay ninguna garantía de que el tráfico se distribuya uniformemente entre conectores y no hay afinidad de sesión. Sin embargo, el uso varía y las solicitudes se envían aleatoriamente a las instancias de servicio de proxy de aplicación. Como resultado, el tráfico se distribuye por lo general de manera casi uniforme entre los conectores. En el diagrama y los pasos se muestra cómo se establecen las conexiones entre los usuarios y los conectores.
- Un usuario de un dispositivo cliente intenta acceder a una aplicación local publicada a través del proxy de aplicación.
- La solicitud pasa por una instancia de Azure Load Balancer para determinar qué instancia de servicio de proxy de aplicación debe llevarla a cabo. Hay decenas de instancias disponibles por región para aceptar las solicitudes para todo el tráfico de la región. Este método ayuda a distribuir uniformemente el tráfico entre las instancias de servicio.
- La solicitud se envía a Service Bus.
- Service Bus señala a un conector disponible. A continuación, el conector recoge la solicitud de Service Bus.
- En el paso 2, las solicitudes van a diferentes instancias de servicio de proxy de aplicación, por lo que es más probable que las conexiones se realicen con conectores diferentes. Como resultado, los conectores se usan de manera casi uniforme dentro del grupo.
- El conector pasa la solicitud al servidor back-end de la aplicación. A continuación, la aplicación envía la respuesta de vuelta al conector.
- El conector completa la respuesta abriendo una conexión de salida a la instancia de servicio desde donde llegó la solicitud. Después, esta conexión se cierra inmediatamente. De forma predeterminada, cada conector está limitado a 200 conexiones de salida simultáneas.
- A continuación, la respuesta se devuelve al cliente desde la instancia de servicio.
- Para las solicitudes posteriores de la misma conexión se repiten los pasos.
Una aplicación suele tener muchos recursos y abre varias conexiones cuando se carga. Cada conexión sigue los pasos para su asignación a una instancia de servicio. Si la conexión no estuviera emparejada con un conector, seleccione un nuevo conector disponible.
Procedimientos recomendados para la alta disponibilidad de los conectores
Debido al modo en que se distribuye el tráfico entre los conectores para lograr una alta disponibilidad, es esencial que un grupo de conectores cuente siempre al menos con dos conectores. Se prefieren tres conectores para proporcionar búfer adicional entre los conectores. Para determinar el número correcto de conectores que necesita, siga la documentación de planeamiento de capacidad.
Sitúe los conectores en diferentes conexiones de salida, para evitar un único punto de error. Si los conectores usan la misma conexión de salida, un problema de red en ella afectará a todos los conectores que la usen.
Evite forzar el reinicio de los conectores cuando se conectan a aplicaciones de producción. Si se hace, esto podría afectar negativamente a la distribución del tráfico entre conectores. El reinicio de los conectores hace que haya menos conectores disponibles y fuerza las conexiones con el conector disponible restante. El resultado es un uso inicialmente desigual de los conectores.
Evite todo tipo de inspecciones insertadas en las comunicaciones de Seguridad de la capa de transporte (TLS) salientes entre los conectores y Azure. Este tipo de inspección insertada provoca la degradación en el flujo de la comunicación.
Asegúrese de mantener las actualizaciones automáticas en ejecución para los conectores. Si el servicio de actualizar el conector de red privado se está ejecutando, los conectores se actualizan automáticamente y reciben la actualización más reciente. Si no ve el servicio Connector Updater en el servidor, debe volver a instalar el conector con el fin de obtener las actualizaciones.
Flujo de tráfico entre los conectores y los servidores de aplicaciones de back-end
Otra área clave donde la alta disponibilidad es un factor es la conexión entre los conectores y los servidores back-end. Cuando se publica una aplicación a través del proxy de aplicaciones de Microsoft Entra, el tráfico de los usuarios a las aplicaciones fluye a través de tres saltos:
- El usuario se conecta al punto de conexión público del servicio del proxy de aplicaciones de Microsoft Entra en Azure. La conexión se establece entre la dirección IP (pública) del cliente de origen y la dirección IP del punto de conexión proxy de la aplicación.
- El conector de red privada extrae la solicitud HTTP del cliente del servicio de proxy de aplicación.
- El conector de red privada se conecta a la aplicación de destino. El conector utiliza su propia dirección IP para establecer la conexión.
Consideraciones sobre el campo de encabezado X-Forwarded-For
En algunas situaciones (como la auditoría, el equilibrio de carga, etc.), se debe cumplir el requisito de compartir la dirección IP de origen del cliente externo con el entorno local. Para solucionar el requisito, el conector de red privada de Microsoft Entra agrega el campo de encabezado X-Forwarded-For con la dirección IP del cliente de origen (pública) a la solicitud HTTP. El dispositivo de red adecuado (equilibrador de carga, firewall), el servidor web o la aplicación de back-end pueden leer y usar la información.
Procedimientos recomendados para el equilibrio de carga entre varios servidores de aplicaciones
El equilibrio de carga será importante cuando el grupo de conectores asignado a la aplicación del proxy de aplicaciones tenga dos o más conectores. El equilibrio de carga también es importante cuando se ejecute la aplicación web de back-end en varios servidores.
Escenario 1: la aplicación de back-end no requiere persistencia de sesión
El escenario más sencillo es aquel en el que la aplicación web de back-end no necesita permanencia de la sesión (persistencia de la sesión). Una instancia de aplicaciones de back-end controla las solicitudes de usuario en la granja de servidores. Puede usar un equilibrador de carga de nivel 4 y configurarlo sin afinidad. Entre las opciones, se incluyen el equilibrio de carga de red de Microsoft y Azure Load Balancer o un equilibrador de carga de otro proveedor. Como alternativa, configure una estrategia de Sistema de nombres de dominio (DNS) round robin.
Escenario 2: La aplicación de back-end requiere la persistencia de la sesión
En este escenario, la aplicación web de back-end requiere la permanencia de la sesión (persistencia de la sesión) durante la sesión autenticada. La instancia de aplicaciones de back-end controla las solicitudes de usuario. Las solicitudes se ejecutan en el mismo servidor de la granja de servidores. Este escenario puede resultar más complicado, porque por lo general el cliente establece varias conexiones al servicio de proxy de aplicación. Las solicitudes en distintas conexiones pueden llegar a diferentes conectores y servidores de la granja. Dado que cada conector utiliza su propia dirección IP para esta comunicación, el equilibrador de carga no puede garantizar la permanencia de la sesión en función de la dirección IP de los conectores. Tampoco se puede usar la afinidad de la IP de origen. Estas son algunas opciones para el escenario 2:
Opción 1: basar la persistencia de la sesión en una cookie de sesión establecida por el equilibrador de carga. Se recomienda esta opción porque permite que la carga se extienda de manera más uniforme entre los servidores back-end. Requiere un equilibrador de carga de nivel 7 con esta capacidad, que puede controlar el tráfico HTTP y finalizar la conexión TLS. Puede usar Azure Application Gateway (Afinidad de sesión) o un equilibrador de carga de otro proveedor.
Opción 2: basar la persistencia de la sesión en el campo de encabezado X-Forwarded-For. Esta opción requiere un equilibrador de carga de nivel 7 con esta capacidad, que puede controlar el tráfico HTTP y finalizar la conexión TLS.
Opción 3: configurar la aplicación de back-end para que no requiera la persistencia de la sesión.
Para conocer los requisitos de equilibrio de carga de la aplicación de back-end, consulte la documentación del proveedor de software.