Diseño de una arquitectura de red distribuida geográficamente
En una aplicación distribuida, es esencial asegurarse de que los componentes puedan comunicarse de forma fiable y que las solicitudes puedan enrutarse a otro componente o región cuando se produzca un error.
Hemos decidido rediseñar nuestro portal de envío en Azure para reducir su vulnerabilidad ante un error regional. Queremos asegurarnos de que la aplicación conmuta por error sobre los componentes de una región secundaria cuando la región primaria no está disponible. La conmutación por error debe provocar una interrupción mínima en la entrega del servicio a los usuarios.
Aquí veremos la manera en que Azure DNS, Traffic Manager, Front Door y Azure CDN admiten la arquitectura de aplicaciones de nuestra empresa de transportes.
Azure DNS
Recuerde que no necesitamos realizar ningún cambio en la implementación de Azure DNS. Usaremos Azure DNS para hospedar los registros de nombre de dominio que identifican nuestra aplicación.
Azure DNS proporciona resolución de nombres en su totalidad mediante la infraestructura de Azure. Este servicio es intrínsecamente multirregional, por lo que no es necesario modificar la configuración de Azure DNS existente para admitir la característica en nuestro nuevo diseño arquitectónico.
Además, el Acuerdo de Nivel de Servicio de Azure DNS garantiza al 100 % que las solicitudes de DNS válidas recibirán una respuesta de al menos un servidor de nombres de Azure DNS en todo momento.
Selección de un enrutador de tráfico
Necesitamos un servicio que pueda equilibrar la carga y redirigir el tráfico entre varias regiones con aplicaciones web distribuidas.
Azure proporciona varios servicios diferentes que pueden enrutar el tráfico entre los componentes de front-end. Recuerde que necesitamos reemplazar nuestra instancia de Azure Application Gateway, ya que está enlazada a una sola región. Si se produce un error en esa región, no hay nada que pueda llevar a cabo el enrutamiento.
Hay dos enrutadores de tráfico en Azure que pueden realizar el enrutamiento global entre varias regiones y que no son vulnerables a una interrupción de una sola región:
- Azure Traffic Manager
- Azure Front Door
Veamos estos servicios con más detalle para poder elegir el enrutador adecuado para nuestra aplicación.
¿Qué es Azure Traffic Manager?
Azure Traffic Manager es un equilibrador de carga global que usa registros DNS para enrutar el tráfico a destinos en varias regiones de Azure.
Podemos configurar Traffic Manager para enrutar todas las solicitudes a nuestra región primaria y supervisar la capacidad de respuesta de App Service en esa región. Si se produce un error en App Service en la región primaria, Traffic Manager redirige automáticamente las solicitudes de usuario a la instancia de App Service en la región secundaria. Al redirigirlas, se ejecuta una conmutación por error que garantiza un servicio continuado. Esta solución se denomina modo de enrutamiento por prioridad.
Dado que Traffic Manager usa el sistema DNS para enrutar el tráfico, enruta cualquier protocolo, no solo el tráfico HTTP. Pero Traffic Manager no puede enrutar ni filtrar el tráfico en función de las propiedades HTTP, como los códigos de país de cliente o los encabezados de agente de usuario. Tampoco puede realizar la terminación del protocolo de Seguridad de la capa de transporte (TLS), en la que el enrutador descifra las solicitudes y cifra las respuestas para aliviar esa carga de los servidores virtuales de App Service. Si necesitamos cualquiera de estas características, tendremos que usar Azure Front Door.
Traffic Manager usa una supervisión de los puntos de conexión muy configurable. Por ejemplo, podemos definir el protocolo, el puerto, la ruta de acceso, la configuración de encabezados personalizada, los intervalos de códigos de estado esperados y el número de errores tolerados. La supervisión de los puntos de conexión nos da una idea continua del mantenimiento general de todas las partes de nuestra aplicación.
¿Qué es Azure Front Door?
Como Traffic Manager, Azure Front Door es un equilibrador de carga global. A diferencia de Traffic Manager, funciona en el nivel de aplicación de red, el nivel 7, y usa las propiedades HTTP y HTTPS para realizar el filtrado y el enrutamiento.
Con Front Door, podemos realizar muchos tipos de enrutamiento que Traffic Manager no admite. Por ejemplo, es posible enrutar el tráfico en función del código de país del explorador. Front Door también admite la terminación del protocolo TLS.
Aun así, hay una excepción. Si queremos enrutar el tráfico de un protocolo que no sea HTTP y HTTPS, tendremos que usar Traffic Manager.
Front Door nos permite asignar prioridades a los distintos back-ends que componen el portal de seguimiento. Estas prioridades permiten a Front Door enrutar las solicitudes según sea necesario. Asignaremos los servicios de la región primaria con una prioridad máxima y el servicio de la región secundaria con una prioridad más baja.
Front Door implementa sondeos de mantenimiento para supervisar el estado de mantenimiento de los servicios y, si se produce un error, puede enrutar el tráfico correctamente. El modo de enrutamiento por prioridad y la supervisión de los puntos de conexión en Front Door son similares a las características de Traffic Manager, con la diferencia de que los sondeos de mantenimiento siempre funcionan a través de HTTP.
Todo el tráfico de la interfaz de usuario web de nuestro portal de envío y sus API se realiza a través de HTTPS y nos permite desactivar Azure Traffic Manager con Front Door. También configuraremos Front Door con la asignación de back-end por prioridad.
Azure CDN
En nuestra arquitectura de una sola región, usamos Azure CDN para almacenar en caché contenido estático de Azure Blob Storage. El servicio Azure CDN es una red global de servidores que almacena en caché el contenido estático cerca de los usuarios. No es necesario modificar este servicio para la arquitectura de varias regiones. Aun así, en la siguiente unidad trataremos una serie de consideraciones relativas a la cuenta de Azure Storage.