Compartir a través de

Solución de errores intermitentes de conexión saliente en Azure App Service

Este artículo le ayuda a solucionar errores de conexión intermitentes y problemas de rendimiento relacionados en Azure App Service. Proporciona más información sobre las metodologías y la solución de problemas de agotamiento de los puertos de traducción de direcciones de red (SNAT) de origen. Si necesita más ayuda en cualquier momento de este artículo, póngase en contacto con los expertos de Azure en Soporte técnico de la comunidad de Azure. Como alternativa, puede registrar un incidente de soporte técnico de Azure. Vaya al soporte técnico de Azure y seleccione Enviar una incidencia de soporte técnico.

Síntomas

Las aplicaciones y las funciones hospedadas en Azure App Service pueden presentar uno o varios de los siguientes problemas:

  • Tiempos de respuesta lentos en todas o algunas de las instancias de un plan de servicio.
  • Errores 5xx o de Puerta de enlace incorrecta intermitentes.
  • Mensajes de error de tiempo de espera.
  • No se pudo conectar a puntos de conexión externos (como SQLDB, Service Fabric u otros servicios de aplicaciones).

Causa

La causa principal de los problemas de conexión intermitente es que se alcanza un límite al crear conexiones salientes nuevas. Los límites que se pueden alcanzar incluyen los siguientes:

  • Conexiones TCP: hay un límite en el número de conexiones salientes que se pueden realizar. El límite de conexiones salientes se asocia con el tamaño del trabajo usado.
  • Puertos SNAT: Conexiones salientes en Azure describe las restricciones de puertos SNAT y cómo afectan a las conexiones salientes. Azure usa la traducción de direcciones de red de origen (SNAT) y los equilibradores de carga (no expuestos a los clientes) para comunicarse con IP públicas. A cada instancia de Azure App Service se le asigna inicialmente un número predefinido de 128 puertos SNAT. El límite de puertos SNAT afecta a la apertura de conexiones a la misma combinación de dirección y puerto. Si la aplicación crea conexiones con una mezcla de combinaciones de direcciones y puertos, no se usarán los puertos SNAT. Los puertos SNAT se usan cuando hay llamadas repetidas a la misma combinación de dirección y puerto. Una vez liberado un puerto, el puerto está disponible para su reutilización según sea necesario. El equilibrador de carga de red de Azure reclama puertos SNAT de conexiones cerradas solo después de esperar cuatro minutos.

Cuando las aplicaciones o funciones abren rápidamente una nueva conexión, pueden agotar rápidamente su cuota asignada previamente de 128 puertos. Después, se bloquean hasta que un nuevo puerto SNAT esté disponible, ya sea a través de la asignación dinámica de más puertos SNAT o mediante la reutilización de un puerto SNAT reclamado. Si la aplicación se queda sin puertos SNAT, tiene problemas intermitentes de conectividad saliente.

Cómo evitar el problema

Hay algunas soluciones que permiten evitar las limitaciones de puertos SNAT. Incluyen:

  • Grupos de conexiones: al agrupar las conexiones, evita abrir nuevas conexiones de red para las llamadas a la misma dirección y puerto.
  • Puntos de conexión de servicio: no hay una restricción de puertos SNAT para los servicios protegidos con puntos de conexión de servicio.
  • Puntos de conexión privados: no hay restricción de puerto SNAT para los servicios protegidos con puntos de conexión privados.
  • NAT Gateway: con una instancia de NAT Gateway, tiene 64 000 puertos SNAT de salida que los pueden usar los recursos que envían tráfico a través de la instancia.

Para evitar el problema del puerto SNAT se previene la creación de conexiones repetidas a los mismos host y puerto. Los grupos de conexiones son una de las formas más obvias para resolver ese problema.

Si el destino es un servicio de Azure que admite puntos de conexión de servicio, puede evitar problemas de agotamiento de puertos SNAT mediante la integración de red virtual regional y los puntos de conexión de servicio o puntos de conexión privados. Cuando usas la integración de red virtual regional y colocas puntos de conexión de servicio en la subred de integración, el tráfico de salida de la aplicación hacia esos servicios no estará sujeto a restricciones de puerto SNAT de salida. Del mismo modo, si usa la integración con red virtual regional junto con puntos de conexión privados, no tendrá ningún problema con los puertos SNAT de salida en ese destino.

Si el destino es un punto de conexión externo fuera de Azure, el uso de una instancia de NAT Gateway proporciona 64 000 puertos SNAT de salida. También proporciona una dirección de salida dedicada que no se comparte con ningún otro usuario.

Si es posible, mejore el código para usar grupos de conexiones y evitar toda esta situación. No siempre es posible cambiar el código lo suficientemente rápido como para mitigar esta situación. En los casos en los que el código no se puede modificar a tiempo, aproveche las otras soluciones. La mejor solución para el problema es combinar todas las soluciones como mejor se pueda. Intente usar puntos de conexión de servicio y puntos de conexión privados para los servicios de Azure y NAT Gateway para el resto.

Para más información sobre las estrategias para mitigar el agotamiento de puertos SNAT, consulte Uso de SNAT para conexiones salientes. De estas estrategias, las siguientes se aplican a las funciones y aplicaciones hospedadas en el servicio Azure App Service.

Utilizar agrupación de conexiones

En los artículos siguientes se describe la implementación de la agrupación de conexiones mediante una pila de soluciones diferente.

Nodo

De manera predeterminada, las conexiones de Node.js no se mantienen activas.

Mantenimiento de conexiones HTTP

Java

Agrupación de conexiones JDBC (Java Database Connectivity)

Agrupación de conexiones HTTP

PHP

Aunque PHP no admite la agrupación de conexiones, puede intentar usar conexiones de base de datos persistentes en el servidor de backend.

Pitón

Agrupación de conexiones HTTP

  • La agrupación de conexiones HTTP y de mantenimiento están habilitadas de forma predeterminada en el módulo Solicitudes.
  • Urllib3

Reutilizar las conexiones

Para obtener más consejos y ejemplos sobre administrar conexiones en Azure Functions, consulte Administración de conexiones en Azure Functions.

Usar una lógica de reintento menos agresiva

Para más orientación y ejemplos, consulte Patrón para reintentos.

Uso de conexiones persistentes para restablecer el tiempo de espera de inactividad saliente

Para implementar keepalives para aplicaciones Node.js, consulte Mi aplicación de Node está realizando llamadas salientes excesivas.

Más instrucciones específicas de App Service

  • Una prueba de carga debe simular datos reales en una velocidad de alimentación estable. Probar aplicaciones y funciones bajo estrés real puede identificar y resolver problemas de agotamiento de puertos SNAT con antelación.
  • Asegúrese de que los servicios back-end puedan devolver respuestas con rapidez. Para solucionar problemas de rendimiento de base de datos de Azure SQL Database, revise Solución de problemas de rendimiento de Azure SQL Database con Intelligent Insights.
  • Escale horizontalmente el plan de App Service a más instancias. Para obtener más información sobre el escalado, consulte Escalado de una aplicación en Azure App Service. A cada instancia de trabajo de un plan de App Service se le asigna un número de puertos SNAT. Si distribuye el uso entre más instancias, es posible que consiga reducir el uso de puertos SNAT por instancia por debajo del límite recomendado de 100 conexiones salientes, por punto de conexión remoto único.
  • Considere la posibilidad de cambiar a App Service Environment (ASE), donde se le asigna una sola dirección IP de salida, y los límites de conexiones y puertos SNAT son mayores. En un ASE, el número de puertos SNAT por instancia se basa en la tabla de asignación previa del equilibrador de carga de Azure. Por ejemplo, un ASE con 1-50 instancias de trabajo tiene 1024 puertos asignados previamente por instancia, mientras que un ASE con 51-100 instancias de trabajo tiene 512 puertos asignados previamente por instancia.

Evitar los límites de TCP salientes es algo más fácil de resolver, ya que los límites se establecen en función del tamaño del trabajo. Puede ver los límites en Límites numéricos de máquina virtual entre espacios aislados: conexiones TCP.

Nombre del límite Descripción Pequeño (A1) Medio (A2) Grande (A3) Nivel aislado (ASE)
Conexiones Número de conexiones en toda la máquina virtual 1920 3968 8064 16 000

Para evitar los límites de TCP salientes, puede aumentar el tamaño de los trabajos o realizar un escalado horizontal.

Ayuda para la solución de problemas

Si conoce los dos tipos de límites de conexión de salida y lo que hace la aplicación, la solución de problemas debería ser más fácil. Si sabe que la aplicación realiza muchas llamadas a la misma cuenta de almacenamiento, podría sospechar de un límite de SNAT. Si la aplicación crea una gran cantidad de llamadas a puntos de conexión a través de Internet, sospecharía que está alcanzando el límite de máquinas virtuales.

Si no tiene suficiente información sobre el comportamiento de la aplicación para determinar la causa con rapidez, hay algunas herramientas y técnicas disponibles en App Service para ayudarle a determinarlo.

Búsqueda de información de asignación de puertos SNAT

Puede usar Diagnósticos de App Service para buscar información sobre la asignación de puertos SNAT y observar la métrica de asignación de puertos SNAT de un sitio de App Service. Para buscar información sobre la asignación de puertos SNAT, siga estos pasos:

  1. Para acceder al diagnóstico de App Service, vaya a la aplicación web de App Service o a App Service Environment en Azure Portal. En el menú de la barra lateral, seleccione Diagnosticar y resolver problemas.
  2. Seleccione la categoría Disponibilidad y rendimiento .
  3. Seleccione el icono de agotamiento del puerto SNAT en la lista de iconos disponibles en la categoría. El procedimiento consiste en mantenerlo por debajo de 128. Si lo necesita, puede abrir una incidencia y el ingeniero de soporte técnico obtendrá de forma automática la métrica de back-end.

Dado que el uso de puertos SNAT no está disponible como métrica, no es posible escalar automáticamente en función del uso de puertos SNAT ni configurar el escalado automático basado en la métrica de asignación de puertos SNAT.

Conexiones TCP y puertos SNAT

Las conexiones TCP y los puertos SNAT no están directamente relacionados. Se incluye un detector de uso de conexiones TCP en la página Diagnosticar y resolver problemas de cualquier aplicación de App Service. Busque la frase conexiones TCP para encontrarlo.

  • Los puertos SNAT solo se usan para flujos de red externos, mientras que el total de conexiones TCP incluye conexiones de bucle de retorno local.
  • Un puerto SNAT se puede compartir entre distintos flujos, si difieren en el protocolo, la dirección IP o el puerto. La métrica de conexiones TCP cuenta todas las conexiones TCP.
  • El límite de conexiones TCP se produce en el nivel de instancia de trabajo. El equilibrio de carga de salida de red de Azure no usa la métrica de conexiones TCP para la limitación de puertos SNAT.
  • Los límites de conexiones TCP se describen en Límites numéricos de máquinas virtuales entre espacios aislados: conexiones TCP.
  • Las sesiones TCP existentes dan error cuando se agregan nuevas sesiones TCP de salida desde el puerto de origen de Azure App Service. Para evitar conflictos, puede usar una única dirección IP o volver a configurar los miembros del grupo de back-end.
Nombre del límite Descripción Pequeño (A1) Medio (A2) Grande (A3) Nivel aislado (ASE)
Conexiones Número de conexiones en toda la máquina virtual 1920 3968 8064 16 000

WebJobs y conexiones de base de datos

Si se agotan los puertos SNAT y los WebJobs no se pueden conectar a SQL Database, no hay ninguna métrica para mostrar el número de conexiones abiertas por cada proceso de aplicación web individual. Para encontrar el trabajo web con el problema, puede transferir varios trabajos web a otro plan de App Service para ver si la situación mejora, o bien si un problema se mantiene en uno de los planes. Repita el proceso hasta que encuentre el trabajo web con el problema.

Contenido relacionado

  • Last updated on