Métodos de enrutamiento del tráfico en el origen

Importante

Azure Front Door (clásico) se retirará el 31 de marzo de 2027. Para evitar cualquier interrupción del servicio, es importante migrar los perfiles de Azure Front Door (clásico) al nivel Estándar o Premium de Azure Front Door para marzo de 2027. Para obtener más información, consulte retirada de Azure Front Door (clásico).

Azure Front Door admite cuatro métodos diferentes de enrutamiento del tráfico para gestionar cómo debe distribuirse el tráfico HTTP y HTTPS entre orígenes diferentes. Cuando las solicitudes de usuario llegan a las ubicaciones perimetrales de Front Door, el método de enrutamiento configurado garantiza que las solicitudes se reenvíen al mejor recurso de back-end.

Nota:

En este artículo, el término origen hará referencia al back-end, mientras que el término grupo de orígenes hará referencia al grupo de back-end de la configuración de una instancia de Azure Front Door (clásico).

Los cuatro métodos de enrutamiento del tráfico son:

• Latencia: enruta las solicitudes a los orígenes con la latencia más baja dentro de un intervalo de sensibilidad aceptable, lo que garantiza que las solicitudes se envíen a los orígenes más cercanos en términos de latencia de red.

• Prioridad: permite establecer una prioridad para los orígenes, designando un origen principal para gestionar todo el tráfico y un origen secundario como copia de seguridad en caso de que el principal no esté disponible.

• Ponderado: asigna una ponderación a cada origen para distribuir el tráfico uniformemente o según coeficientes de ponderación especificados. El tráfico se distribuye en función de los valores de ponderación si las latencias de los orígenes se encuentran dentro del rango de sensibilidad aceptable.

• Afinidad de sesión: garantiza que las solicitudes de un mismo usuario final se envíen al mismo origen mediante la configuración de la afinidad de sesión para los hosts o dominios de front-end.

Nota:

En los niveles Estándar y Premium de Azure Front Door, el término nombre de punto de conexión hace referencia al host de front-end de Azure Front Door (clásico).

Todas las configuraciones de Front Door incluyen la supervisión del estado del back-end y la conmutación por error global automatizada. Para obtener más información, consulte el artículo Supervisión de back-end de Front Door. Azure Front Door puede usar un único método de enrutamiento o combinar varios métodos para crear una topología de enrutamiento óptima en función de las necesidades de la aplicación.

Nota:

Cuando use el motor de reglas de Front Door, puede configurar una regla que invalide las configuraciones de ruta de los niveles Estándar y Premium de Azure Front Door o que invalide el grupo de back-end de Azure Front Door (clásico) para procesar una solicitud. Los grupos de orígenes o grupos de back-end que se establezcan con el motor de reglas invalidarán el proceso de enrutamiento descrito en este artículo.

Flujo general para la toma de decisiones

En el siguiente diagrama se muestra el flujo general para la toma de decisiones:

Los pasos para tomar decisiones son:

1. Orígenes disponibles: seleccionar todos los orígenes que estén habilitados y devuelvan un estado correcto (200 OK) en el sondeo de estado.
   • Ejemplo: Si hay seis orígenes A, B, C, D, E y F, pero el origen C devuelve un estado incorrecto y el origen E está deshabilitado, los orígenes disponibles son A, B, D y F.
2. Prioridad: seleccionar los orígenes de mayor prioridad entre los que están disponibles.
   • Ejemplo: si los orígenes A, B y D tienen prioridad 1 y el origen F tiene prioridad 2, los orígenes seleccionados son A, B y D.
3. Señal de latencia (basada en el sondeo de estado): seleccione los orígenes dentro del intervalo de latencia permitido desde el entorno de Front Door donde llegó la solicitud. Se basa en la configuración de la sensibilidad a la latencia en el grupo de origen y en la latencia de los orígenes más cercanos.
   • Ejemplo: si la latencia del origen A es de 15 ms, en B es de 30 ms y en D es de 60 ms y la sensibilidad a la latencia se establece en 30 ms, los orígenes seleccionados son A y B, ya que D supera el intervalo de 30 ms.
4. Ponderaciones: distribuir el tráfico entre los orígenes finales seleccionados en función de las relaciones de ponderación especificadas.
   • Ejemplo: Si el origen A tiene una ponderación de 3 y el origen B tiene una ponderación de 7, el tráfico se distribuye siguiendo una proporción de 3/10 al origen A y de 7/10 al origen B.

Si la afinidad de sesión está habilitada, la primera solicitud de una sesión sigue el flujo explicado anteriormente. Las solicitudes posteriores se envían al origen seleccionado en la primera solicitud.

Enrutamiento del tráfico basado en la latencia más baja

La implementación de orígenes en varias ubicaciones globales puede mejorar la capacidad de respuesta de la aplicación mediante el enrutamiento del tráfico al origen "más cercano" a los usuarios finales. El método de enrutamiento por latencia es el predeterminado para las configuraciones de Azure Front Door. Este método dirige las solicitudes de usuario al origen con la latencia de red más baja, en lugar de la ubicación geográfica más cercana, lo que garantiza un rendimiento óptimo.

La arquitectura de difusión por proximidad de Azure Front Door, combinada con el método de enrutamiento por latencia, garantiza que cada usuario obtenga el mejor rendimiento en función de su ubicación. Cada entorno de Front Door mide de forma independiente la latencia en los orígenes, por lo que se enruta a los usuarios de distintas ubicaciones al origen que ofrezca el mejor rendimiento para su entorno específico.

Nota:

El valor de la propiedad de sensibilidad a la latencia se establece en 0 ms de forma predeterminada. Con esta configuración, las solicitudes siempre se reenvían a los orígenes más rápidos disponibles. Las ponderaciones de los orígenes solo tienen efecto si dos orígenes tienen la misma latencia de red.

Para obtener más información, consulte Arquitectura de enrutamiento de Azure Front Door.

Enrutamiento de tráfico basado en la prioridad

Para garantizar una alta disponibilidad, las organizaciones suelen implementar servicios de copia de seguridad que asumen el control si se produce un error en el servicio principal. Esta configuración se conoce como implementación activa/en espera o activa/pasiva. El método de enrutamiento del tráfico de Prioridad de Azure Front Door permite implementar este patrón de conmutación por error eficazmente.

De forma predeterminada, Azure Front Door enruta el tráfico a los orígenes con la prioridad más alta (valor de prioridad más bajo). Si estos orígenes primarios dejan de estar disponibles, enruta el tráfico a los orígenes secundarios (siguiente valor de prioridad más bajo). Este proceso continúa con los orígenes terciarios si los orígenes primarios y secundarios no están disponibles. Los sondeos de estado supervisan la disponibilidad de los orígenes en función de los estados configurados.

Configuración de la prioridad de los orígenes

Cada origen del grupo de origen de Azure Front Door tiene una propiedad Priority, que se puede establecer en un valor entre 1 y 5. Los valores inferiores indican mayor prioridad. Varios orígenes pueden compartir el mismo valor de prioridad.

Método de enrutamiento de tráfico Ponderado

El método de enrutamiento de tráfico Ponderado permite distribuir el tráfico en función de las ponderaciones predefinidas.

Con este método, se asigna un valor de ponderación a cada origen del grupo de origen de Azure Front Door. El valor de ponderación es un entero entre 1 y 1000, con un valor predeterminado de 50.

El tráfico se distribuye entre los orígenes disponibles mediante un mecanismo round robin basado en las relaciones de ponderación especificadas, siempre que los orígenes se encuentren dentro de la sensibilidad a la latencia aceptable. Si la sensibilidad a la latencia se establece en 0 milisegundos, las ponderaciones solo tienen efecto si dos orígenes tienen la misma latencia de red.

El método ponderado admite varios escenarios:

• Actualización gradual de aplicaciones: se enruta un porcentaje del tráfico a un nuevo origen y se aumenta gradualmente con el tiempo.
• Migración de aplicaciones a Azure: Se crea un grupo de orígenes a partir de orígenes de Azure y orígenes externos. Ajuste los valores de ponderación para dar preferencia a los nuevos orígenes, aumentando gradualmente su cuota de tráfico hasta que gestionen la mayor parte del tráfico y, a continuación, deshabilite y quite los orígenes menos preferidos.
• Expansión de la nube para obtener capacidad adicional: se expanden las implementaciones locales a la nube agregando o habilitando más orígenes y especificando la distribución del tráfico.

Afinidad de sesión

De forma predeterminada. Azure Front Door reenviará las solicitudes que procedan de un mismo cliente a diferentes orígenes. Sin embargo, la afinidad de sesión es útil para las aplicaciones con estado o los escenarios en los que las solicitudes posteriores del mismo usuario las debe procesar el mismo origen. Esta características garantiza que la sesión de un usuario la gestione un mismo origen, lo que resulta ventajoso en la autenticación de clientes, entre otros escenarios.

Azure Front Door usa la afinidad de sesión basada en cookies, con la que se usan cookies administradas con SHA256 de la dirección URL de origen como identificador. Esto dirige el tráfico posterior de una sesión de usuario al mismo origen.

La afinidad de sesión puede habilitarse en el nivel de grupo de orígenes de Azure Front Door en los niveles de servicio Estándar y Premium, así como en el nivel de host de front-end de Azure Front Door (clásico), para cada uno de los dominios (o subdominios) configurados. Cuando esta se habilite, Azure Front Door agregará las cookies llamadas ASLBSA y ASLBSACORS a la sesión del usuario. Estas cookies ayudan a identificar a diferentes usuarios incluso aunque compartan la misma dirección IP, lo que permite una distribución más uniforme del tráfico entre orígenes.

La cookie dura lo mismo que la sesión del usuario, ya que Front Door solo admite cookies de sesión.

Nota:

La afinidad de sesión se mantiene a través de la cookie de sesión del explorador en el nivel de dominio. Los subdominios que pertenezcan al mismo dominio con comodín podrán compartir la afinidad de sesión siempre y cuando el explorador del usuario envíe solicitudes cuyo objetivo sea el mismo recurso del origen.

Los servidores proxy públicos pueden interferir con la afinidad de sesión, ya que para establecer una sesión es necesario que Front Door agregue una cookie de afinidad de sesión a la respuesta. Esto no se puede hacer si la respuesta se puede almacenar en caché, ya que interrumpiría las cookies para otros clientes que soliciten el mismo recurso. Para evitar esto, la afinidad de sesión no se establecerá si el origen envía una respuesta almacenable en caché. Si la sesión ya está establecida, no importa la capacidad de almacenamiento en caché de la respuesta.

La afinidad de sesión se establecerá en las siguientes circunstancias más allá de los escenarios estándar no almacenables en caché:

• La respuesta incluye el encabezado Cache-Control con no-store.
• La respuesta contiene un encabezado Authorization válido.
• La respuesta es un código de estado HTTP 302.

Pasos siguientes

• Aprenda a crear una instancia de Azure Front Door.
• Obtenga más información acerca del funcionamiento de Azure Front Door.