Enrutamiento de difusión por proximidad (anycast) con Azure Route Server
Puede implementar la aplicación en zonas de disponibilidad de una sola región de Azure para alcanzar mayor disponibilidad, pero a veces es posible que tenga que implementar las aplicaciones en varias regiones, ya sea para lograr una mayor resistencia, un mejor rendimiento para los usuarios de todo el mundo o una mejor continuidad empresarial. Hay diferentes enfoques que se pueden adoptar para dirigir a los usuarios a una de las ubicaciones en las que se implementa una aplicación de varias regiones: enfoques basados en DNS, como Azure Traffic Manager, servicios basados en enrutamiento como Azure Front Door o el equilibrador de carga entre regiones de Azure.
Los anteriores servicios de Azure se recomiendan para que los usuarios puedan llegar a la mejor ubicación de la aplicación a través de la red pública de Internet mediante direcciones IP públicas, pero no admiten redes privadas ni direcciones IP. En este artículo se explora el uso de un enfoque basado en rutas (difusión por proximidad [anycast] de IP) para proporcionar implementaciones de aplicaciones en red privada y en varias regiones.
La difusión por proximidad (anycast) de IP consiste básicamente en anunciar exactamente la misma dirección IP desde más de una ubicación, de modo que los paquetes de los usuarios de la aplicación se enrutan a la región más cercana (en términos de enrutamiento). Proporcionar capacidad de alcance en varias regiones a través de cualquier difusión por proximidad (anycast) ofrece algunas ventajas con respecto a los enfoques basados en DNS, como no tener que depender de que los clientes no tengan que almacenar en caché sus respuestas DNS y que no necesiten modificar el diseño DNS de la aplicación.
Topología
En el diseño de este escenario, se anuncia la misma dirección IP desde redes virtuales de diferentes regiones de Azure, donde las aplicaciones virtuales de red (NVA) anuncian la dirección IP de la aplicación a través de Azure Route Server. En el diagrama siguiente se muestran dos topologías simples de red en estrella tipo hub-and-spoke, cada una en una región de Azure diferente. Una NVA en cada región anuncia la misma ruta (a.b.c.d/32 en este ejemplo) a su instancia de Azure Route Server local (el prefijo de la ruta no se debe superponer con Azure y las redes locales). Las rutas se propagan aún más a la red local a través de ExpressRoute. Cuando los usuarios de la aplicación quieren acceder a la aplicación desde el entorno local, la infraestructura de DNS (que no se trata este documento) resuelve el nombre DNS de la aplicación en la dirección IP de difusión por proximidad (anycast) (a.b.c.d), que los dispositivos de red locales enrutan a una de las dos regiones.
La decisión de cuál de las regiones disponibles está seleccionada se basa completamente en los atributos de enrutamiento. Si las rutas de ambas regiones son idénticas, la red local normalmente usa un enrutamiento multidireccional de igual costo (ECMP) para enviar cada flujo de aplicación a cada región. También es posible modificar los anuncios que generan las NVA en Azure para hacer que una de las regiones sea la preferida. Por ejemplo, con la ruta de acceso de AS de BGP antepuesta para establecer una ruta de acceso determinista desde el entorno local a la carga de trabajo de Azure.
Importante
Las NVA que anuncian las rutas deben incluir algún mecanismo de comprobación de estado para dejar de anunciar la ruta cuando la aplicación no está disponible en sus respectivas regiones para evitar el filtrado del tráfico.
Devolución del tráfico
Cuando el tráfico de la aplicación desde el cliente local llega a una de las NVA de Azure, la aplicación virtual de red realiza el proxy inverso de la conexión o la traducción de direcciones de red de destino (DNAT). A continuación, envía los paquetes a la aplicación real, que normalmente residirá en una red virtual de radio emparejada a la red virtual de centro en la que se implementa la NVA. El tráfico de vuelta desde la aplicación regresa a través de la NVA, lo que sucede de forma natural si la NVA redirige mediante proxy inversamente la conexión (o realiza la traducción de direcciones de red de origen además de la traducción de direcciones de red de destino).
De lo contrario, el tráfico que llega a la aplicación sigue siendo el origen de la dirección IP del cliente local original. En este caso, los paquetes se pueden enrutar de nuevo a la NVA con rutas definidas por el usuario (UDR). Debe tener especial cuidado si hay más de una instancia de NVA en cada región, ya que el tráfico podría ser asimétrico (el tráfico entrante y saliente que pasa a través de diferentes instancias de NVA). El tráfico asimétrico no suele ser un problema si las NVA no tienen estado, pero provoca errores si las NVA realizan un seguimiento de los estados de conexión, como los firewalls.