Solución de problemas de conectividad

  • Artículo

En este artículo, se proporciona ayuda para la solución de problemas de conexión de la aplicación cliente a Azure Cache for Redis. Los problemas de conectividad se dividen en dos tipos: problemas de conectividad intermitentes y problemas de conectividad continua.

Problemas de conectividad intermitentes

Es posible que la aplicación cliente tenga problemas de conectividad intermitentes causados por eventos como la aplicación de revisiones o picos en el número de conexiones.

Mantenimiento del servidor.

A veces, la caché se somete a un mantenimiento planeado o no planeado del servidor. La aplicación puede verse afectada negativamente durante el mantenimiento. Puede validarlo si comprueba la métrica Errors (Type: Failover) en el portal. Para minimizar los efectos de las conmutaciones por error, vea Resistencia de conexión.

Número máximo de clientes conectados

Compruebe si el agregado máximo de la métrica Connected Clients es cercano o mayor que el número máximo de conexiones permitidas para un tamaño de caché determinado. Para más información sobre el tamaño de las conexiones cliente, vea Rendimiento de Azure Cache for Redis.

Aplicaciones hospedadas de Kubernetes

  • Si la aplicación cliente está hospedada en Kubernetes, compruebe que el pod que ejecuta la aplicación cliente o los nodos del clúster no están bajo presión de memoria, CPU o red. Un pod que ejecuta la aplicación cliente puede verse afectado por otros pods que se ejecutan en el mismo nodo y limitan las conexiones de Redis o las operaciones de E/S.
  • Si usa Istio o cualquier otra malla de servicio, compruebe que el proxy de la malla de servicio reserva el puerto 13000-13019 o 15000-15019. Estos puertos los usan los clientes para comunicarse con nodos de Azure Cache for Redis agrupados y podrían causar problemas de conectividad en esos puertos.

Aplicación cliente basada en Linux

El uso de la configuración de TCP optimista en Linux puede hacer que las aplicaciones cliente experimenten problemas de conectividad. Vea Connection stalls lasting for 15 minutes (Detenciones de conexión que duran 15 minutos).

Conectividad continua

Si la aplicación no se puede conectar a Azure Cache for Redis, es posible que alguna configuración de la caché no sea correcta. En las secciones siguientes se ofrecen sugerencias sobre cómo asegurarse de que la caché está configurada correctamente.

Prueba de la conectividad mediante redis-cli

Pruebe la conectividad mediante redis-cli. Para más información sobre la CLI, vea Uso de la herramienta de línea de comandos de Redis con Azure Cache for Redis.

Prueba de la conectividad mediante PSPING

Si redis-cli no se puede conectar, puede probar la conectividad mediante PSPING en PowerShell.

psping -q <cache DNS endpoint>:<Port Number>

Puede confirmar que el número de paquetes enviados es igual a los paquetes recibidos. La confirmación garantiza que la conectividad no se ha reducido.

Configuración de redes virtuales

Pasos para comprobar la configuración de la red virtual:

  1. Compruebe si hay una red virtual asignada a la caché en la sección "Red virtual" de Configuración en el menú Recurso de Azure Portal.
  2. Asegúrese de que la máquina host cliente está en la misma red virtual que Azure Cache for Redis.
  3. Cuando la aplicación cliente está en una red virtual diferente de la de Azure Cache for Redis, ambas redes virtuales deben tener habilitado el emparejamiento de redes virtuales dentro de la misma región de Azure.
  4. Compruebe que las reglas de entrada y salida cumplen el requisito.
  5. Para más información, vea Configuración de una red virtual: instancia de Azure Cache for Redis de nivel prémium.

Configuración de puntos de conexión privados

Pasos para comprobar la configuración del punto de conexión privado:

  1. La marca Public Network Access está deshabilitada de forma predeterminada al crear un punto de conexión privado. Asegúrese de que ha establecido Public Network Access correctamente. Cuando tenga la caché en Azure Portal, busque este valor en Punto de conexión privado en el menú Recurso de la izquierda.
  2. Si intenta conectarse al punto de conexión privado de caché desde fuera de la red virtual de la caché, Public Network Access debe estar habilitado.
  3. Si ha eliminado el punto de conexión privado, asegúrese de que el acceso a la red pública está habilitado.
  4. Compruebe si el punto de conexión privado está configurado correctamente. Para más información, vea Creación de un punto de conexión privado con una nueva instancia de Azure Cache for Redis.
  5. Compruebe si la aplicación se conecta al <cachename>.redis.cache.windows.net en el puerto 6380. Se recomienda evitar el uso de <cachename>.privatelink.redis.cache.windows.net en la configuración o la cadena de conexión.
  6. Ejecute un comando como nslookup <hostname> desde la red virtual que está vinculada al punto de conexión privado para comprobar que el comando se resuelve en la dirección IP privada de la memoria caché.

Reglas de firewall

Si tiene un firewall configurado para Azure Cache for Redis, asegúrese de que la dirección IP del cliente se agrega a las reglas de firewall. Puede comprobar Firewall en el menú Recurso en Configuración en Azure Portal.

Firewall de terceros o proxy externo

Cuando use un firewall o proxy de terceros en la red, compruebe que el punto de conexión de Azure Cache for Redis, *.redis.cache.windows.net, está permitido junto con los puertos 6379 y 6380. Es posible que tenga que permitir más puertos al usar una caché en clúster o una replicación geográfica.

Cambio de dirección IP pública

Si ha configurado algún recurso de red o de seguridad para usar la dirección IP pública de la memoria caché, compruebe si dicha dirección IP pública ha cambiado. Para obtener más información, consulte Confiar en el nombre de host, no en la dirección IP pública para la caché.

Replicación geográfica mediante inyección de VNet con cachés Premium

Aunque es posible usar la inyección de VNet con las memorias caché Premium, se recomienda Azure Private Link.

Para más información, vea:

La replicación geográfica de memorias caché en redes virtuales es compatible con advertencias:

  • Se admite la replicación geográfica entre memorias cachés de la misma VNet.
  • También se admite la replicación geográfica entre memorias cachés en distintas redes virtuales.
    • Si las VNet están en la misma región, puede conectarlas mediante un emparejamiento de la red virtual o una conexión de red virtual a red virtual de VPN Gateway.
    • Si las redes virtuales están en regiones diferentes, no se admite la replicación geográfica mediante el emparejamiento de VNET. Una máquina virtual cliente de la red virtual 1 (región 1) no puede acceder a la memoria caché de la red virtual 2 (región 2) mediante su nombre DNS debido a una restricción de los equilibradores de carga internos básicos. Para obtener más información sobre las restricciones de emparejamiento de redes virtuales, consulte Red virtual - Emparejamiento - Requisitos y restricciones. Se recomienda usar una conexión de red virtual a red virtual de VPN Gateway.

Para configurar su VNet de manera eficaz y evitar problemas de replicación geográfica, debe configurar correctamente los puertos de entrada y salida. Para más información sobre cómo evitar las incidencias más comunes de configuración de red virtual, consulte Requisitos de puerto del mismo nivel de replicación geográfica.

Contenido relacionado

En estos artículos se proporciona más información sobre conectividad y resistencia: