Compartir a través de


Enrutamiento de difusión por proximidad (anycast) con Azure Route Server

El enrutamiento Anycast le permite anunciar la misma dirección IP desde varias regiones de Azure, mejorando la disponibilidad, el rendimiento y la resiliencia de las aplicaciones. Con Azure Route Server, puede implementar el enrutamiento anycast para dirigir automáticamente el tráfico a la instancia de aplicación más cercana o más óptima en función de las métricas de enrutamiento.

En este artículo se explica cómo implementar el enrutamiento de anycast con Azure Route Server para implementaciones de aplicaciones de varias regiones a través de redes privadas.

¿Qué es el enrutamiento de anycast?

El enrutamiento anycast es una metodología de direccionamiento y enrutamiento de red en la que se asigna la misma dirección IP a varios servidores o instancias de aplicación en diferentes ubicaciones. Cuando un cliente envía una solicitud a una dirección IP de difusión, la infraestructura de red enruta automáticamente el tráfico al servidor más cercano o óptimo en función de los protocolos de enrutamiento y las métricas.

Ventajas del enrutamiento de anycast

El enrutamiento Anycast proporciona varias ventajas para las implementaciones multi-región:

  • Rendimiento mejorado: el tráfico se enruta automáticamente a la instancia de aplicación más cercana, lo que reduce la latencia.
  • Disponibilidad mejorada: Si una región deja de estar disponible, el tráfico se redirige automáticamente a otras regiones.
  • Distribución de carga: el tráfico se puede distribuir entre varias regiones en función de las métricas de enrutamiento.
  • Configuración simplificada del cliente: los clientes se conectan a una única dirección IP independientemente de la ubicación real del servidor.
  • Compatibilidad con redes privadas: a diferencia de las soluciones basadas en DNS, Anycast funciona con direcciones IP privadas y redes.

Anycast frente a otros enfoques multirregionales

Aunque Azure ofrece varios servicios para implementaciones de varias regiones, como Azure Traffic Manager, Azure Front Door y Azure Cross-Region Load Balancer, estos servicios están diseñados para el tráfico público de Internet y el direccionamiento IP público.

El enrutamiento anycast con Azure Route Server está diseñado para:

  • Escenarios de red privada: aplicaciones que requieren direccionamiento IP privado
  • Conectividad híbrida: escenarios que implican conexiones ExpressRoute o VPN a redes locales
  • Administración del tráfico basada en enrutamiento: donde el almacenamiento en caché de DNS o el comportamiento del cliente podrían interferir con las soluciones basadas en DNS

Implementación de Anycast con Azure Route Server

Azure Route Server permite el enrutamiento anycast facilitando el anuncio de rutas idénticas desde varias regiones de Azure hacia redes locales a través de conexiones ExpressRoute o VPN.

Introducción a la arquitectura

La implementación de anycast usa los siguientes componentes:

  • Varias regiones de Azure: cada región hospeda una instancia de la aplicación
  • Azure Route Server: implementado en cada región para administrar anuncios de ruta
  • Aplicaciones virtuales de red (NVA): anuncie la dirección IP anycast en cada región.
  • Topología hub-and-spoke: proporciona conectividad entre el appliance virtual de red (NVA) y las instancias de aplicación.
  • ExpressRoute o VPN: conecta regiones de Azure a redes locales

Topología de implementación

En el diagrama siguiente se muestra una implementación típica de anycast con dos regiones de Azure. Cada región contiene:

  • Una red virtual hub con una NVA y Azure Route Server
  • Una red virtual spoke que hospeda la instancia de la aplicación
  • Conectividad de ExpressRoute a redes locales

Diagrama que muestra la implementación de enrutamiento anycast con Azure Route Server en dos regiones, demostrando cómo se anuncia la misma dirección IP desde varias ubicaciones.

Funcionamiento del enrutamiento de anycast

  1. Anuncio de ruta: las NVA de cada región anuncian el mismo prefijo de dirección IP (por ejemplo, a.b.c.d/32) a su instancia local de Azure Route Server
  2. Propagación de rutas: Azure Route Server propaga estas rutas a redes locales a través de conexiones ExpressRoute o VPN
  3. Selección de rutas: los protocolos de enrutamiento local seleccionan la mejor ruta de acceso para llegar a la dirección IP de difusión en función de las métricas de enrutamiento.
  4. Distribución del tráfico: el tráfico de cliente se enruta automáticamente a la región óptima en función de la ruta de acceso seleccionada.

Selección de rutas y equilibrio de carga

La selección de qué región recibe tráfico depende de los atributos de enrutamiento:

  • Ruta de acceso múltiple de igual costo (ECMP): cuando las rutas de varias regiones tienen métricas idénticas, el tráfico se distribuye uniformemente entre todas las rutas de acceso disponibles.
  • Preferencias de ruta de acceso BGP: puede influir en las decisiones de enrutamiento ajustando los atributos BGP, como la longitud de la ruta de acceso, las preferencias locales o los valores de MED.
  • Prependido de ruta de AS: alargar artificialmente la ruta de AS para rutas específicas para que sean menos preferidas, creando un escenario primario/secundario

Importante

Las NVA deben implementar mecanismos de comprobación de estado para dejar de anunciar rutas cuando la instancia local de aplicación deja de estar disponible. Esto impide que el tráfico se enrute a instancias con errores (blackholing).

Consideraciones sobre el tráfico de retorno

El control adecuado del tráfico de retorno es fundamental para las implementaciones de anycast correctas. El método depende de cómo el NVA procesa el tráfico entrante.

Métodos de procesamiento de tráfico

  • El modo de proxy inverso proporciona el flujo de tráfico más predecible cuando la aplicación virtual de red funciona como proxy inverso. En esta configuración, la NVA (aplicación virtual de red) finaliza la conexión original del cliente y establece una nueva conexión a la instancia de la aplicación. El tráfico de retorno fluye naturalmente a través de la misma NVA porque la NVA administra ambos lados de la conexión.

  • El modo de traducción de direcciones de red (NAT) requiere consideraciones diferentes cuando la NVA realiza la traducción de direcciones de red de destino (DNAT). La NVA traduce la dirección IP de destino de la IP de anycast a la dirección IP real de la aplicación. Si el dispositivo virtual de red (NVA) también realiza Source NAT (SNAT), los flujos de tráfico de retorno pasan a través del mismo dispositivo virtual de red (NVA). Sin embargo, si no se realiza ningún SNAT, se requiere una configuración adicional para garantizar el enrutamiento de tráfico devuelto adecuado.

Enrutamiento del tráfico de retorno

Cuando la aplicación recibe tráfico con la dirección IP del cliente original (sin SNAT), debes asegurarte de que el tráfico devuelto fluya a través del dispositivo virtual de red correcto. Las rutas definidas por el usuario (UDR) se pueden configurar en la subred de la aplicación para dirigir el tráfico a la NVA. Estas UDR deben cubrir los intervalos de direcciones IP locales y funcionar bien para implementaciones únicas de NVA.

En el caso de las implementaciones con varias instancias de NVA por región, las consideraciones sobre el tráfico asimétrico son importantes. Los NVAs sin estado pueden gestionar el tráfico asimétrico donde los flujos entrantes y salientes pasan por diferentes instancias. Sin embargo, las NVA con estado requieren un flujo de tráfico simétrico para mantener el estado de conexión. Las soluciones para NVA con estado incluyen el uso de mecanismos de afinidad de conexión, la implementación del uso compartido de sesiones entre instancias de NVA o la configuración de equilibradores de carga con persistencia de sesión.

Procedimientos recomendados para el flujo de tráfico

El seguimiento de estado debe implementar comprobaciones de estado sólidas para detectar rápidamente errores de la aplicación y NVA. El tiempo de conmutación por error requiere la configuración de temporizadores BGP adecuados para lograr un equilibrio entre una conmutación por error rápida y la estabilidad. La ingeniería de tráfico puede usar comunidades BGP u otros atributos para implementar directivas de tráfico. La supervisión completa y las alertas deben realizar un seguimiento de los anuncios de ruta y los patrones de tráfico entre regiones para garantizar un rendimiento óptimo y la detección rápida de problemas.

Consideraciones sobre la implementación

Requisitos previos y requisitos

Antes de implementar el enrutamiento anycast con Azure Route Server, debe planificar cuidadosamente la asignación de direcciones IP para asegurarse de que la dirección IP anycast no entre en conflicto con las redes locales o de Azure existentes. Una comprensión sólida de las directivas de enrutamiento BGP y su efecto en la distribución del tráfico es esencial para una implementación correcta. La arquitectura de la aplicación debe diseñarse para controlar el tráfico de varias regiones de forma eficaz y debe implementar una supervisión completa del estado de las aplicaciones y las aplicaciones virtuales de red para garantizar una operación confiable.

Procedimientos recomendados de implementación

Al implementar el enrutamiento anycast, se recomienda comenzar con una implementación simple de dos regiones antes de expandirse a otras regiones. Las pruebas periódicas de escenarios de conmutación por error ayudan a garantizar que el sistema cumple los requisitos de disponibilidad y se comporta según lo previsto durante las interrupciones. La supervisión de métricas de rendimiento, como la latencia y el rendimiento de diferentes ubicaciones locales, proporciona información valiosa sobre la eficacia de la configuración de enrutamiento. Mantener una documentación clara de las directivas de BGP y sus efectos previstos es fundamental para la administración continua y la solución de problemas.

Limitaciones y consideraciones

Se deben tener en cuenta varios factores al implementar el enrutamiento anycast con Azure Route Server. Los tiempos de convergencia de BGP pueden introducir retrasos durante los eventos de conmutación por error, lo que podría afectar a los objetivos de tiempo de recuperación. La complejidad adicional del enrutamiento de capa de red en comparación con las soluciones basadas en DNS requiere más experiencia y planificación cuidadosa. La solución de problemas de enrutamiento de capa de red puede ser más difícil que diagnosticar problemas de capa de aplicación, lo que requiere conocimientos y herramientas especializados. Además, los costos de infraestructura aumentan debido a la necesidad de más aplicaciones virtuales de red y instancias de Route Server en varias regiones.

Pasos siguientes