Contoso configura un grupo de origen de Azure Front Door que contiene dos orígenes en diferentes regiones. Quieren que Front Door realice una conmutación por error de un origen después de dos fallos consecutivos de la sonda de estado. ¿Qué configuraciones de la sonda de estado deberían modificar en el grupo de origen para cumplir este requisito?

La opción correcta es establecer el 'Unhealthy Threshold' en 2. Este umbral determina cuántas fallas consecutivas de la sonda de estado deben ocurrir antes de que Azure Front Door marque un origen como no saludable y lo elimine de la rotación. Al configurarlo en 2, Front Door realizará la conmutación por error después de dos fallas consecutivas, cumpliendo con el requisito. El intervalo de la sonda define la frecuencia con la que Front Door envía solicitudes de sonda, y la ruta y el host de la sonda deben ser correctos para que las sondas funcionen. Las otras opciones son incorrectas: Aumentar el intervalo de la sonda o usar un "Failover threshold" en la configuración del host de frontend no es la configuración correcta para el umbral de salud del origen. No existe una "sonda de multidifusión personalizada" ni una configuración de "Maximum retries" para este propósito en Azure Front Door. Crear orígenes idénticos y confiar en el enrutamiento ponderado no aborda el requisito de conmutación por error basada en fallas de la sonda de estado; el enrutamiento ponderado es para la distribución de tráfico, no para la detección de salud.