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 antes de marzo de 2027. Para obtener más información, consulte retirada de Azure Front Door (clásico).

Azure Front Door admite cuatro métodos de enrutamiento del tráfico para determinar 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, se aplica el método de enrutamiento configurado para garantizar que las solicitudes se reenvíen al mejor recurso de back-end.

Nota

Cuando en este artículo se mencione al origen o al grupo de orígenes, se estará haciendo referencia, respectivamente, al back-end y al grupo de back-end de la configuración de Azure Front Door (clásico).

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

• Latencia: El enrutamiento basado en la latencia garantiza que las solicitudes se enviarán a los orígenes con la menor latencia que sean aceptables de acuerdo con un intervalo de confidencialidad. Es decir, las solicitudes se enviarán al conjunto de orígenes más cercano en función de la latencia de red.

• Prioridad: Si desea configurar un origen principal que dé servicio a todo el tráfico, puede establecer una prioridad para los orígenes. El origen secundario puede ser una copia de seguridad que puede usarse si el origen principal deja de estar disponible.

• Ponderado: Si desea distribuir el tráfico a través de un conjunto de orígenes, ya sea uniformemente o según los coeficientes ponderados, puede asignar un valor ponderado a los orígenes. El tráfico se distribuirá en función del valor ponderado si las latencias de los orígenes se encuentran dentro del intervalo de confidencialidad de latencia aceptable que se establezca para el grupo de orígenes.

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

Nota

Cuando en los niveles de servicio Estándar y Premium de Azure Front Door se menciona al nombre del punto de conexión, se hace referencia al host de front-end de la configuración de Azure Front Door (clásico).

Todas las configuraciones de Front Door incluyen procesos de seguimiento de estado de los orígenes y procesos de conmutación por error global instantánea automatizada. Para obtener más información, consulte el artículo Supervisión de back-end de Front Door. Azure Front Door puede usarse con un único método de enrutamiento. Sin embargo, en función de las necesidades de la aplicación, es posible combinar varios métodos de enrutamiento para crear una topología de enrutamiento óptima.

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: seleccione todos los orígenes que estén habilitados y devuelvan un estado correcto (200 OK) en el sondeo de estado.
   • Ejemplo: Supongamos que hay seis orígenes A, B, C, D, E y F. Entre ellos, el origen C devuelve un estado incorrecto y E está deshabilitado. En este caso, la lista de orígenes disponibles se compondrá de A, B, D y F.
2. Prioridad: se seleccionan los orígenes de mayor prioridad entre los que están disponibles.
   • Ejemplo: Supongamos que los orígenes A, B y D tienen prioridad 1 y el origen F tiene prioridad 2. A continuación, 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. Esta señal 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: Supongamos que Front Door ha medido la latencia del entorno donde la solicitud llegó al origen A a 15 ms, mientras que la latencia de B es de 30 ms y la de D es de 60 ms. Si la sensibilidad a la latencia del grupo de origen se establece en 30 ms, el grupo de latencia más bajo consta de los orígenes A y B, porque D está más allá de 30 ms del origen más cercano que es A.
4. Ponderaciones: por último, Azure Front Door realiza una distribución round robin del tráfico entre el grupo seleccionado definitivo de orígenes con la proporción de ponderaciones especificadas.
   • Ejemplo: Si el origen A tiene una ponderación de 3 y el origen B tiene una ponderación de 7, entonces 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 indicado 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 capacidad de respuesta de las aplicaciones puede mejorarse con la implementación de orígenes en dos o más ubicaciones en distintos puntos del planeta, ya que estos enrutarán el tráfico hacia el destino "más cercano" a los usuarios finales. La configuración de Front Door utiliza el método de enrutamiento del tráfico por latencia de forma predeterminada. Este método de enrutamiento reenvía las solicitudes de los usuarios finales al origen más cercano asociado con Azure Front Door. La combinación de este método de enrutamiento con la arquitectura de difusión por proximidad de Azure Front Door garantiza que todos los usuarios finales obtienen el mejor rendimiento en función de su ubicación.

El origen "más cercano" no es necesariamente el más próximo en términos de la distancia geográfica. En su lugar, Azure Front Door mide la latencia de red para determinar cuál es el origen más cercano. Para obtener más información, consulte el artículo Introducción a la arquitectura de enrutamiento.

Cada entorno de Front Door mide la latencia de origen por separado. Esto significa que los distintos usuarios de diferentes ubicaciones se enrutan al origen con el mejor rendimiento para ese entorno.

Nota

El valor de la propiedad de sensibilidad a la latencia se establece en 0 ms de forma predeterminada. Con esta configuración, la solicitud siempre se reenviará a los orígenes más rápidos disponibles y las ponderaciones solo se usarán si dos orígenes presentan la misma latencia de red.

Enrutamiento de tráfico basado en la prioridad

Habitualmente, las organizaciones desean ofrecer alta disponibilidad de sus servicios y, para ello, implementan varios servicios de reserva en caso de que su servicio principal se vuelva inactivo. En la sector, este tipo de topología también se conoce como topología de implementación activa/en espera o activa/pasiva. El método de enrutamiento del tráfico en función de Prioridad le permitirá implementar fácilmente este patrón de conmutación por error.

Las instancias predeterminadas de Azure Front Door contienen una lista de orígenes con la misma prioridad. De forma predeterminada, Azure Front Door solo envía el tráfico a los orígenes de prioridad superior (los que tienen el valor de prioridad más bajo), que conforman el conjunto principal de orígenes. Si los orígenes principales no están disponibles, Azure Front Door enrutará el tráfico al conjunto secundario de orígenes (los que tengan el segundo valor de prioridad más bajo). Si tanto los orígenes principales como los secundarios no están disponibles, el tráfico pasará al conjunto terciario, y así sucesivamente. La disponibilidad del origen depende del estado configurado y del estado de mantenimiento del origen en curso que determinan los sondeos de estado.

Configuración de la prioridad de los orígenes

Cada uno de los orígenes pertenecientes al grupo de orígenes configurado en Azure Front Door presenta una propiedad llamada Prioridad, que admite un valor del 1 al 5. Azure Front Door permite configurar la prioridad de cada origen explícitamente empleando esta propiedad. Esta propiedad es un valor comprendido entre 1 y 5. Cuanto menor sea el valor, mayor será la prioridad. Los orígenes pueden compartir valores de prioridad.

Método de enrutamiento de tráfico Ponderado

El método de enrutamiento de tráfico Ponderado le permite distribuir el tráfico uniformemente o utilizar una ponderación predefinida.

Para emplear el método de enrutamiento del tráfico ponderado, deberá asignar una ponderación a cada origen a través de la configuración del grupo de orígenes en Azure Front Door. El valor de la ponderación debe ser un número entero del 1 al 1000. El valor predeterminado de este parámetro es de 50.

A partir de la lista de orígenes disponibles con una sensibilidad a la latencia aceptable, el tráfico se distribuye con un mecanismo round-robin en función de la proporción de las ponderaciones especificadas. Si la sensibilidad a la latencia se establece en 0 milisegundos, esta propiedad solo surtirá efecto cuando dos orígenes presenten la misma latencia de red.

El método ponderado permite algunos escenarios útiles:

• Actualización gradual de aplicaciones: Se proporciona un porcentaje del tráfico que será redirigido a un nuevo origen y se aumenta el tráfico gradualmente hasta que esté a la par con los otros orígenes.
• Migración de aplicaciones a Azure: Se crea un grupo de orígenes a partir de orígenes de Azure y orígenes externos. A continuación, se ajustan los valores de ponderación para dar preferencia a los nuevos orígenes. Para configurar este escenario gradualmente, se pueden deshabilitar los nuevos orígenes y asignarles la menor ponderación. A continuación, esta se va aumentando lentamente hasta llegar a los niveles en los que se encargan de la mayor parte del tráfico. Por último, se deshabilitan los orígenes de menor preferencia y se eliminan del grupo.
• Expansión de la nube para conseguir capacidad adicional: expanda rápidamente una implementación local en la nube colocándola detrás de Front Door. Si necesita capacidad adicional en la nube, puede agregar o habilitar más orígenes y especificar qué porción del tráfico debe llegar a cada uno.

Afinidad de sesión

La afinidad de sesión está desactivada de forma predeterminada. Por este motivo, Azure Front Door reenviará las solicitudes que procedan de un mismo cliente a diferentes orígenes. En algunas aplicaciones con estado, o en determinados escenarios en los que se producen varias solicitudes de un mismo usuario, se prefiere usar el mismo origen que procesó la solicitud inicial. La característica de afinidad de sesión a partir de cookies le resultará útil cuando quiera que una sesión de usuario permanezca en el mismo origen. Si se usan cookies administradas que se identifican con un hash SHA256 de la dirección URL del origen, Azure Front Door podrá dirigir todo el tráfico procedente de una sesión de usuario al mismo origen para su procesamiento.

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á una cookie a la sesión del usuario. Las cookies se denominan ASLBSA y ASLBSACORS. La afinidad de sesión a partir de cookies permite que Front Door identifique a los distintos usuarios, aunque estos estén usando la misma dirección IP. Esto, a su vez, permite realizar una distribución más uniforme del tráfico entre los diferentes orígenes.

La duración de la cookie es la misma que la sesión del usuario, porque Front Door actualmente solo admite cookies de sesión.

Nota

Independientemente de dónde esté configurada, la afinidad de sesión se recordará en el nivel de dominio a partir de la cookie de sesión del explorador. Los subdominios que pertenezcan al mismo dominio con comodín podrán compartir la afinidad de sesión siempre y cuando el mismo 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. El motivo es que, para establecer una sesión, Front Door tiene que agregar una cookie de afinidad de sesión a la respuesta, lo que no se puede realizar si la respuesta se puede almacenar en caché porque interrumpiría las cookies de otros clientes que soliciten el mismo recurso. Para evitar este problema, la afinidad de sesión no se establecerá si, al intentarlo, el origen envía una respuesta almacenable en caché. Si la sesión ya se ha establecido, no importará si la respuesta del origen puede almacenarse en caché.

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 debe incluir el encabezado Cache-Control de no-store.
• Si la respuesta contiene un encabezado Authorization, no debe expirar.
• 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.