Compartir vía

Configurar la compatibilidad con redes virtuales (VNet) en una instancia de Azure Cache for Redis de nivel Premium

  • Artículo

La implementación de Azure Virtual Network aporta mayor seguridad y aislamiento, junto con: subredes, directivas de control de acceso y otras características que restringen más el acceso. Si una instancia de Azure Cache for Redis se configura con una red virtual, no se puede acceder a ella de forma pública, solo desde máquinas virtuales y aplicaciones que se encuentren dentro de la red virtual. En este artículo se describe cómo configurar la compatibilidad con redes virtuales de una instancia de Azure Cache for Redis de nivel prémium.

Nota

El modelo de implementación clásica se retira en agosto de 2024. Para más información, consulte El modelo de implementación de Cloud Services (clásico) se retirará el 31 de agosto de 2024.

Importante

Azure Cache for Redis recomienda usar Azure Private Link, que simplifica la arquitectura de red y protege la conexión entre los puntos de conexión en Azure. Puede conectarse a una instancia de Azure Cache desde la red virtual a través de un punto de conexión privado, al que se le asigna una dirección IP privada en una subred dentro de la red virtual. Azure Private Links se ofrece en todos nuestros niveles, incluye compatibilidad con Azure Policy y administración simplificada de reglas de NSG. Para más información, consulte Documentación de Private Link. Para migrar las memorias caché de red virtual Private Link, consulte Migración de cachés de inserción de red virtual a Private Link cachés.

Limitaciones de la inserción de red virtual

  • La creación y mantenimiento de configuraciones de red virtual conlleva riesgo de errores. Solucionar problemas también tiene sus complicaciones. Las configuraciones de red virtual incorrectas pueden provocar problemas:
    • transmisión de métricas obstruidas desde las instancias de caché
    • error del nodo de réplica al replicar datos del nodo principal
    • posible pérdida de datos
    • error de operaciones de administración, como el escalado
    • errores intermitentes o completos de SSL/TLS
    • error al aplicar actualizaciones, incluidas las mejoras importantes de seguridad y confiabilidad
    • en los peores casos, pérdida de disponibilidad
  • Al usar una caché insertada de red virtual, debe mantener actualizada la red virtual para permitir el acceso a las dependencias de caché, como listas de revocación de certificados, infraestructura de clave pública, Azure Key Vault, Azure Storage, Azure Monitor, etc.
  • Las cachés inyectadas en VNet solo están disponibles para el nivel Premium de Azure Cache for Redis, pero no en otros niveles.
  • No se puede insertar una instancia existente de Azure Cache for Redis en una red virtual. Hay que seleccionar esta opción al crear la caché.

Configuración de la compatibilidad con redes virtuales

La compatibilidad con redes virtuales se configura en el panel New Azure Cache for Redis (Nueva instancia de Azure Cache for Redis) durante la creación de la memoria caché.

  1. Para crear una instancia de caché de nivel prémium, inicie sesión en Azure Portal y seleccione Crear un recurso. También se puede crear mediante las plantillas de Resource Manager, PowerShell o la CLI de Azure. Para más información sobre cómo crear una instancia de Azure Cache for Redis, consulte Creación de una caché.

    Captura de pantalla se muestra la opción Crear un recurso.

  2. En la página Nuevo, seleccione Bases de datos. Después, seleccione Azure Cache for Redis.

    Captura de pantalla que muestra la selección de Azure Cache for Redis.

  3. En la página Nueva caché en Redis, configure las opciones de la nueva instancia de caché de nivel prémium.

    Configuración Valor sugerido Descripción
    Nombre DNS Escriba un nombre único global. El nombre de la memoria caché debe ser una cadena de entre 1 y 63 caracteres, y solo puede contener números, letras o guiones. El nombre debe comenzar y terminar por un número o una letra y no puede contener guiones consecutivos. El nombre de host de la instancia de caché será \<DNS name>.redis.cache.windows.net.
    Suscripción Seleccione la suscripción en la lista desplegable. La suscripción en la que se creará esta nueva instancia de Azure Cache for Redis.
    Grupos de recursos Seleccione un grupo de recursos en la lista desplegable o seleccione Crear nuevo y escriba un nombre nuevo para el grupo de recursos. El nombre del grupo de recursos en el que se van a crear la caché y otros recursos. Al colocar todos los recursos de la aplicación en un grupo de recursos, puede administrarlos o eliminarlos fácilmente.
    Ubicación seleccione una ubicación en la lista desplegable. Seleccione una región cerca de otros servicios que vayan a usar la memoria caché.
    Tipo de caché Seleccione una instancia de caché de nivel prémium en la lista desplegable para configurar las características de dicho nivel. Para más información, consulte Precios de Azure Cache for Redis. El plan de tarifa determina el tamaño, el rendimiento y las características disponibles para la memoria caché. Para más información, consulte la introducción a Azure Cache for Redis.

  4. Seleccione la pestaña Redes o elija el botón Redes situado en la parte inferior de la página.

  5. En la pestaña Redes, seleccione Redes virtuales como método de conectividad. Para usar una nueva red virtual, primero es preciso crearla, para lo que debe seguir los pasos de Creación de una red virtual mediante Azure Portal o Creación de Virtual Network (clásica) mediante Azure Portal. Después, vuelva al panel Nuevo - Azure Cache for Redis para crear y configurar una instancia de caché de nivel prémium.

    Importante

    Si implementa una instancia de Azure Cache for Redis en una red virtual de Resource Manager, la memoria caché debe estar en una subred dedicada que no contenga otros recursos, salvo instancias de Azure Cache for Redis. Si se intenta implementar una instancia de Azure Cache for Redis en una subred de una red virtual de Resource Manager que contiene otros recursos, o bien que tiene una instancia de NAT Gateway asignada, se produce un error en la implementación. El error se debe a que Azure Cache for Redis usa un equilibrador de carga básico que no es compatible con una puerta de enlace NAT.

    Configuración Valor sugerido Descripción
    Red virtual Seleccione la red virtual en la lista desplegable. Seleccione una red virtual que esté en la misma suscripción y la misma ubicación que la memoria caché.
    Subred Seleccione la subred en la lista desplegable. Se debe usar la notación CIDR para el intervalo de direcciones de la subred (por ejemplo, 192.168.1.0/24). Debe incluirse en el espacio de direcciones de la red virtual.
    Dirección IP estática (Opcional) Escriba una dirección IP estática. Si no especifica una dirección IP estática, se elegirá una dirección IP automáticamente.

    Importante

    Azure reserva algunas direcciones IP dentro de cada subred y estas direcciones no se pueden usar. La primera y la última dirección IP de las subredes están reservadas para la conformidad con el protocolo, junto con otras tres direcciones usadas para los servicios de Azure. Para más información, consulte ¿Hay alguna restricción en el uso de direcciones IP en estas subredes?

    Además de las direcciones IP que usa la infraestructura de red virtual de Azure, cada instancia de Azure Cache for Redis de la subred usa dos direcciones IP por partición y una dirección IP adicional para el equilibrador de carga. Se considera que una instancia de caché que no está en clúster tiene una partición.

  6. Seleccione el botón Siguiente: Opciones avanzadas o haga clic en el botón Siguiente: Opciones avanzadas situado en la parte inferior de la página.

  7. En la pestaña Opciones avanzadas de la instancia de caché de nivel prémium, configure el puerto no TLS, la agrupación en clústeres y la persistencia de datos.

  8. Seleccione el botón Siguiente: Opciones avanzadas o elija el botón Siguiente: Etiquetas situado en la parte inferior de la página.

  9. Opcionalmente, en la pestaña Etiquetas, escriba el nombre y el valor si quiere clasificar el recurso.

  10. Seleccione Revisar + crear. Pasará a la pestaña Revisar y crear, donde Azure valida la configuración.

  11. Tras aparecer el mensaje verde Validación superada, seleccione Crear.

La caché tarda un tiempo en crearse. Puede supervisar el progreso en la página Información general de Azure Cache for Redis. Cuando Estado se muestra como En ejecución, la memoria caché está lista para su uso. Una vez que se crea la memoria caché, para ver la configuración de la red virtual es preciso seleccionar Virtual Network en el menú Recursos.

Virtual network

Preguntas más frecuentes sobre redes virtuales de Azure Cache for Redis

La lista siguiente contiene las respuestas a las preguntas más frecuentes sobre las redes de Azure Cache for Redis.

¿Cuáles son algunos de las incidencias comunes de configuración incorrecta con Azure Cache for Redis y las redes virtuales?

Cuando Azure Cache for Redis se hospeda en una red virtual, se usan los puertos de la tabla siguiente.

Importante

Si los puertos de las siguientes tablas están bloqueados, la memoria caché podría no funcionar correctamente. Tener bloqueados uno o varios de estos puertos es la incidencia más común de una configuración incorrecta cuando se utiliza Azure Cache for Redis en una red virtual.

Requisitos de puerto de salida

Hay requisitos de conectividad de red para Azure Cache for Redis necesarios para la conectividad saliente a otros servicios de dependencia necesarios para que la caché funcione, o incluso internos a la subred de Redis para la comunicación entre nodos.

Puertos Dirección Protocolo de transporte Propósito IP local Dirección IP remota
80, 443 Salida TCP Dependencias de Redis en Azure Storage, PKI (Internet), sistema operativo, infraestructura y antivirus (Subred de Redis) * 4
443 Salida TCP Dependencia de Redis en Azure Key Vault y Azure Monitor (Subred de Redis) AzureKeyVault, AzureMonitor 1
12000 Salida TCP Dependencia de Redis en Azure Monitor (Subred de Redis) AzureMonitor 1
53 Salida TCP/UDP Dependencias de Redis en DNS (Internet y red virtual) (Subred de Redis) 168.63.129.16 y 169.254.169.254 2 y cualquier servidor DNS personalizado para la subred 3
123 Salida UDP Dependencia del sistema operativo en NTP (Subred de Redis) *
1688 Salida TCP Dependencia del sistema operativo para la activación (Subred de Redis) *
8443 Salida TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)
10221-10231 Salida TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)
20226 Salida TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)
13000-13999 Salida TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)
15000-15999 Salida TCP Comunicaciones internas de Redis y replicación geográfica (Subred de Redis) (Subred de Redis) (Subred del mismo nivel de réplica geográfica)
6379-6380 Salida TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)

1 Puede usar las etiquetas de servicio AzureKeyVault y AzureMonitor con los grupos de seguridad de red de Resource Manager (NSG).

2 Estas direcciones IP que pertenecen a Microsoft se usan para dirigir la máquina virtual del host que trabaja con Azure DNS.

3 Esta información no es necesaria para aquellas subredes sin ningún servidor DNS personalizado o cachés en Redis que omiten los DNS personalizados.

4 Para más información, consulte Requisitos adicionales de conectividad de red virtual.

Requisitos de los puertos del mismo nivel en la replicación geográfica

Si usa la replicación geográfica entre memorias caché en redes virtuales de Azure: a) desbloquee los puertos 15000-15999 para toda la subred en las direcciones de entrada y salida, y b) a ambas memorias caché. Con esta configuración, todos los componentes de réplica de la subred pueden comunicarse directamente entre sí, incluso si hay una conmutación por error geográfica futura.

Requisitos de puerto de entrada

Existen ocho requisitos de intervalo de puertos de entrada. Las solicitudes entrantes de estos rangos provienen de otros servicios hospedados en la misma red virtual. O bien, son internas de las comunicaciones de subred de Redis.

Puertos Dirección Protocolo de transporte Propósito IP local Dirección IP remota
6379, 6380 Entrada TCP Comunicación del cliente con Redis, equilibrio de carga de Azure (Subred de Redis) (Subred de Redis), (subred de cliente), AzureLoadBalancer 1
8443 Entrada TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)
8500 Entrada TCP/UDP Equilibrio de carga de Azure (Subred de Redis) AzureLoadBalancer
10221-10231 Entrada TCP Comunicación de cliente con clústeres de Redis, comunicaciones internas para Redis (Subred de Redis) (Subred de Redis), (subred de cliente), AzureLoadBalancer
13000-13999 Entrada TCP Comunicación del cliente con clústeres de Redis, Equilibrio de carga de Azure (Subred de Redis) (Subred de Redis), (subred de cliente), AzureLoadBalancer
15000-15999 Entrada TCP Comunicación del cliente con los clústeres de Redis, el equilibrio de carga de Azure y la replicación geográfica (Subred de Redis) (Subred de Redis), (subred de cliente), AzureLoadBalancer, (subred del mismo nivel con replicación geográfica)
16001 Entrada TCP/UDP Equilibrio de carga de Azure (Subred de Redis) AzureLoadBalancer
20226 Entrada TCP Comunicaciones internas en Redis (Subred de Redis) (Subred de Redis)

1 Puede usar la etiqueta de servicio AzureLoadBalancer para Resource Manager o AZURE_LOADBALANCER para el modelo de implementación clásica para crear las reglas del grupo de seguridad de red.

Requisitos adicionales de conectividad de red virtual

Hay requisitos de conectividad de red para Azure Cache for Redis necesarios para la conectividad saliente a otros servicios de dependencia necesarios para que la caché funcione, o incluso internos a la subred de Redis para la comunicación entre nodos.

Azure Cache for Redis requiere todos los siguientes elementos de conectividad salientes para funcionar correctamente cuando se usa en una red virtual:

Nombre de host Protocolo Puerto de salida Fin Etiqueta de servicio
*.vault.azure.net HTTPS 443 Azure Key Vault AzureKeyVault
*.table.core.windows.net HTTPS 443 Azure Storage Storage
*.blob.core.windows.net HTTPS 443 Azure Storage Storage
*.queue.core.windows.net HTTPS 443 Azure Storage Storage
*.file.core.windows.net HTTPS 443 Azure Storage Storage
ocsp.digicert.com HTTP 80 Infraestructura de clave pública de Azure N/D
crl4.digicert.com HTTP 80 Infraestructura de clave pública de Azure N/D
ocsp.msocsp.com HTTP 80 Infraestructura de clave pública de Azure N/D
mscrl.microsoft.com HTTP 80 Infraestructura de clave pública de Azure N/D
crl3.digicert.com HTTP 80 Infraestructura de clave pública de Azure N/D
cacerts.digicert.com HTTP 80 Infraestructura de clave pública de Azure N/D
oneocsp.microsoft.com HTTP 80 Infraestructura de clave pública de Azure N/D
crl.microsoft.com HTTP 80 Infraestructura de clave pública de Azure N/D
cacerts.geotrust.com HTTP 80 Infraestructura de clave pública de Azure N/D
www.microsoft.com HTTP 80 Infraestructura de clave pública de Azure N/D
cdp.geotrust.com HTTP 80 Infraestructura de clave pública de Azure N/D
status.geotrust.com HTTP 80 Infraestructura de clave pública de Azure N/D
shoebox3.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
shoebox3-red.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
shoebox3-black.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis-red.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
azredis-black.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
global.prod.microsoftmetrics.com HTTPS 443 Azure Monitor AzureMonitor
gcs.prod.monitoring.core.windows.net HTTPS 443 Azure Monitor AzureMonitor
*.prod.warm.ingest.monitor.core.windows.net HTTPS 443 Azure Monitor AzureMonitor
*.servicebus.windows.net HTTPS 443 Azure Monitor EventHub
*.update.microsoft.com HTTPS 443 Servicio de actualización del sistema operativo AzureCloud
*.windowsupdate.com HTTP/HTTPS 80, 443 Servicio de actualización del sistema operativo N/D
*.delivery.mp.microsoft.com HTTP/HTTPS 80, 443 Servicio de actualización del sistema operativo AzureCloud
go.microsoft.com HTTP/HTTPS 80, 443 Antivirus N/D
*.wdcp.microsoft.com HTTPS 443 Antivirus AzureCloud
*.wdcpalt.microsoft.com HTTPS 443 Antivirus AzureCloud
*.wd.microsoft.com HTTPS 443 Antivirus AzureCloud
definitionupdates.microsoft.com HTTPS 443 Antivirus N/D
azurewatsonanalysis-prod.core.windows.net HTTPS 443 Diagnósticos internos AzureCloud
shavamanifestazurecdnprod1.azureedge.net HTTPS 443 Diagnósticos internos N/D
shavamanifestcdnprod1.azureedge.net HTTPS 443 Diagnósticos internos N/D
*.data.microsoft.com HTTPS 443 Diagnósticos internos AzureCloud
  • La configuración de DNS de la red virtual debe poder resolver todos los puntos de conexión y dominios mencionados en las entradas de la tabla anterior. Se pueden cumplir los requisitos de DNS al asegurar que se configura y se mantiene una infraestructura DNS válida para la red virtual.

¿Cómo se puede comprobar que la memoria caché funciona en una red virtual?

Importante

Cuando se conecta a una instancia de Azure Cache for Redis que se hospeda en una red virtual, los clientes de caché deben estar en la misma red virtual o en una red virtual con el emparejamiento de red virtual habilitado dentro de la misma región de Azure. El emparejamiento de red virtual global no se admite actualmente. Este requisito se aplica a cualquier aplicación de prueba o herramienta de diagnóstico con la que se hace ping. Independientemente de dónde se hospede la aplicación cliente, los grupos de seguridad de red u otras capas de red deben configurarse de modo que el tráfico de red del cliente pueda llegar a la instancia de Azure Cache for Redis.

Una vez configurados los requisitos de los puertos como se describe en la sección anterior, en la mayoría de los casos es necesario reiniciar el sistema para asegurarse de que los cambios se reflejan correctamente. De lo contrario, es posible que experimente algunos problemas de conectividad. Puede comprobar que la memoria caché funciona siguiendo estos pasos:

  • Reinicie todos los nodos de la caché. La memoria caché no se podrá reiniciar correctamente si no se pueden alcanzar todas las dependencias de caché necesarias (como se documenta en Requisitos del puerto de entrada y Requisitos de puerto de salida).
  • Después de que se hayan reiniciado los nodos de la memoria caché, como indica el estado de la memoria caché en Azure Portal, puede realizar las siguientes pruebas:

    • Hacer ping en el punto de conexión de caché con el puerto 6380 desde una máquina que esté dentro de la misma red virtual como la memoria caché, con tcping. Por ejemplo:

      tcping.exe contosocache.redis.cache.windows.net 6380

      Si la herramienta tcping informa de que el puerto está abierto, la memoria caché está disponible para su conexión en los clientes de la red virtual.

    • Otra forma de realizar la prueba: cree un cliente de caché de prueba que se conecte a la caché y que, después, agregue y recupere algunos elementos de la caché. El cliente de caché de prueba puede ser una aplicación de consola que use StackExchange.Redis. Instale la aplicación cliente de ejemplo en una máquina virtual que se encuentra en la misma red virtual que la memoria caché. A continuación, ejecútela para comprobar la conectividad con la caché.

Al intentar conectarme a la instancia de Azure Cache for Redis en una red virtual, ¿por qué aparece un error que indica que el certificado remoto no es válido?

Cuando intente conectarse a una instancia de Azure Cache for Redis en una red virtual, verá un error de validación de certificado como este:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

La causa podría ser que se está conectando al host mediante la dirección IP. Se recomienda usar el nombre de host. En otras palabras, use la siguiente cadena:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Evite el uso de la dirección IP similar a la cadena de conexión siguiente:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Si no puede resolver el nombre DNS, algunas bibliotecas de cliente incluyen opciones de configuración como sslHost, que proporciona el cliente StackExchange.Redis. Esta opción le permite invalidar el nombre de host utilizado para la validación del certificado. Por ejemplo:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Además, si la subred donde se hospeda Azure Cache for Redis está bloqueando las conexiones salientes TCP a través del puerto 80 para la funcionalidad SSL/TLS, los clientes podrían experimentar errores intermitentes de validación de certificados TLS.

¿Se pueden usar redes virtuales con una memoria caché básica o estándar?

Las redes virtuales solo se pueden usar con memorias caché de nivel prémium.

¿Por qué se produce un error al crear una instancia de Azure Cache for Redis en algunas subredes, pero no en otras?

Si se implementa una instancia de Azure Cache for Redis en una red virtual, la memoria caché debe estar en una subred dedicada que no contenga ningún otro tipo de recursos. Si se intenta implementar una instancia de Azure Cache for Redis en una subred de red virtual de Resource Manager que contiene otros recursos (como instancias de Azure Application Gateway y NAT de salida), lo habitual es que se produzca un error en la implementación. Antes de crear una instancia de Azure Cache for Redis, elimine los recursos existentes de otros tipos.

También debe tener suficientes direcciones IP disponibles en la subred.

¿Cuáles son los requisitos de espacio de direcciones de subred?

Azure reserva algunas direcciones IP dentro de cada subred y estas direcciones no se pueden usar. La primera y la última dirección IP de las subredes están reservadas para la conformidad con el protocolo, junto con otras tres direcciones usadas para los servicios de Azure. Para más información, consulte ¿Hay alguna restricción en el uso de direcciones IP dentro de estas subredes?

Además de las direcciones IP que usa la infraestructura de red virtual de Azure, cada instancia de Azure Cache for Redis de la subred usa dos direcciones IP por partición de clúster, además de direcciones IP adicionales para réplicas adicionales, en caso de que las haya. Se usa una dirección IP adicional para el equilibrador de carga. Se considera que una caché no en clúster tiene una partición.

¿Puedo conectarme a mi caché desde una red virtual emparejada?

Si las redes virtuales 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 de Azure emparejadas se encuentran en regiones diferentes: una máquina virtual cliente de la región 1 no puede acceder a la caché de la región 2 a través de su dirección IP con equilibrio de carga debido a una restricción con equilibradores de carga básicos. Es decir, a menos que sea una caché con un equilibrador de carga estándar, que actualmente es solo una caché que se creó con zonas de disponibilidad.

Para más información sobre las restricciones del emparejamiento de red virtual, consulte Red virtual - Emparejamiento - Requisitos y restricciones. Una solución es usar una conexión de red virtual a red virtual VPN Gateway, en lugar del emparejamiento de red virtual.

¿Funcionan todas las características de caché cuando una memoria caché se hospeda en una red virtual?

Cuando la memoria caché forma parte de una red virtual, solo los clientes de la red virtual pueden tener acceso a la memoria caché. Como resultado, las siguientes características de administración de la memoria caché no funcionan en este momento:

  • Consola de Redis: como la consola de Redis se ejecuta en el explorador local (normalmente en una máquina de desarrollador que no está conectada a la red virtual) no se puede conectar a la caché.

¿Se admite la inyección de VNet en una memoria caché en la que Azure Lighthouse está habilitado?

No, si la suscripción tiene habilitado Azure Lighthouse, no puede usar la inyección de VNet en una instancia de Azure Cache for Redis. En su lugar, use vínculos privados.

Uso de ExpressRoute con Azure Cache for Redis

Los clientes pueden conectar un circuito de Azure ExpressRoute a su infraestructura de red virtual. De esta manera, amplían su red local a Azure.

De forma predeterminada, los circuitos ExpressRoute recién creados no usan la tunelización forzada (anuncio de una ruta predeterminada, 0.0.0.0/0) en una red virtual. Como resultado, se permite la conectividad de salida a Internet directamente desde la red virtual. Las aplicaciones cliente pueden conectarse a otros puntos de conexión de Azure, entre los que se incluye una instancia de Azure Cache for Redis.

Una configuración de cliente común consiste en usar la tunelización forzada (anunciar una ruta predeterminada) que obliga a que el tráfico de salida de Internet fluya a nivel local. Este flujo de tráfico interrumpe la conectividad con Azure Cache for Redis si el tráfico de salida se bloquea en el entorno local debido a que la instancia de Azure Cache for Redis no se puede comunicar con sus dependencias.

La solución es definir una, o varias, rutas definidas por el usuario (UDR) en la subred que contiene la instancia de Azure Cache for Redis. Una ruta definida por el usuario define las rutas de subred específica que se respetarán en lugar de la ruta predeterminada.

Si es posible, use la siguiente configuración:

  • La configuración de ExpressRoute anuncia 0.0.0.0/0 y, de manera predeterminada, fuerza la tunelización de todo el tráfico saliente a local.
  • El UDR aplicado a la subred que contiene la instancia de Azure Cache for Redis define 0.0.0.0/0 con una ruta de trabajo para tráfico TCP/IP a Internet. Por ejemplo, establece el tipo de próximo salto en Internet.

El efecto combinado de estos pasos es que el UDR de nivel de subred tiene prioridad sobre la tunelización forzada de ExpressRoute y eso garantiza el acceso saliente a Internet desde la instancia de Azure Cache for Redis.

La conexión a una memoria caché de Azure Cache for Redis desde una aplicación local mediante ExpressRoute no es un escenario de uso típico debido a razones de rendimiento. Para obtener el mejor rendimiento, los clientes de Azure Cache for Redis deben estar en la misma región que la instancia de Azure Cache for Redis.

Importante

Las rutas definidas en una UDR deben ser lo suficientemente específicas para que tengan prioridad sobre cualquier otra ruta anunciada por la configuración de ExpressRoute. En el ejemplo siguiente se usa el intervalo de direcciones 0.0.0.0/0 amplio y, como tal, puede reemplazarse accidentalmente por los anuncios de ruta con intervalos de direcciones más específicos.

Advertencia

Azure Cache for Redis no es compatible con las configuraciones de ExpressRoute que anuncian incorrectamente rutas entre la ruta de acceso de emparejamiento de Microsoft y la ruta de acceso de emparejamiento privado. Las configuraciones de ExpressRoute con el emparejamiento de Microsoft configurado reciben anuncios de ruta de Microsoft para un amplio conjunto de intervalos de direcciones IP de Microsoft Azure. Si estos intervalos de direcciones se anuncian incorrectamente en la ruta de acceso de emparejamiento privado, el resultado es que se forzará incorrectamente la tunelización de todos los paquetes de red salientes desde la subred de la instancia de Azure Cache for Redis a la infraestructura de red local del cliente. Este flujo de red interrumpe Azure Cache for Redis. La solución a este problema consiste en detener rutas anunciadas entre la ruta de acceso de interconexión de Microsoft y la ruta de acceso de interconexión privada.

La información general sobre UDR está disponible en Enrutamiento del tráfico de redes virtuales.

Para más información sobre ExpressRoute, consulte Información técnica sobre ExpressRoute.

Contenido relacionado

Más información sobre las características de Azure Cache for Redis.