question

GagnonAlexandreNC-2861 avatar image
0 Votes"
GagnonAlexandreNC-2861 asked AlexGagnon-6808 commented

Priority of backend not respected when service is restored

Hi there, we have a frontdoor instance with two application gateway instances in separate regions as the backends. We would like to use the active/failover model of disaster recovery, where the secondary AG instance receives no traffic unless the primary becomes unavailable. We've got the primary with priority 1, weight 50, and the secondary with priority 2, weight 50, and neither FD or AG is using session affinity. Initially it works as expected, and we can shift all traffic to the secondary by manually causing the primary to fail by updating the backend to a non-resolvable host. However when we restore the primary, at that point the traffic seems to be doing a 50/50 split, instead of returning 100% of the traffic to the primary. I've fiddled around with connection draining, but it doesn't seem to change things. Any suggestions?

azure-application-gatewayazure-front-door
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

ChaitanyaNaykodiMSFT-9638 avatar image
0 Votes"
ChaitanyaNaykodiMSFT-9638 answered AlexGagnon-6808 commented

Hello @GagnonAlexandreNC-2861, Thank you for reaching out and apologies for the delayed response here.

As per the documentation Azure Front Door routes traffic to backend based on priority given that it is marked as enabled and healthy first. Health probe request determine the health of the backend and can be controlled by Load balancing settings, based on these settings and responses Azure Front Door determines the backend health. Please have a look if these settings are causing the observation above. If this is not what is causing the issue I will suggest that you create a support request for this issue, if you do not have a support plan please let me know.. Thank you!


· 3
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks! In the Load balancing settings link, there's this part which I think relates to my problem:

If health probes fail for every backend in a backend pool, then Front Door considers all backends healthy and routes traffic in a round robin distribution across all of them.

Looking through the logs, it does appear that the health probe is returning a 404 for both AG instances, which likely explains the behaviour I'm seeing. Does Application Gateway have a health endpoint that Frontdoor can hit that would return a 200, without having to actually hit a backend of Application Gateway?

0 Votes 0 ·

Hello @GagnonAlexandreNC-2861, apologies for the delay I was discussing the issue within the team. I am sorry but we did not understand even when the primary is up why Application Gateway is sending 404 response? Regarding AG, I do not think that AG has health endpoint that Frontdoor can hit that would always return a 200, but you can explore the option of using custom health probes for AG and see if it satisfies the requirement.


0 Votes 0 ·
AlexGagnon-6808 avatar image AlexGagnon-6808 ChaitanyaNaykodiMSFT-9638 ·

Hi! It was returning at 404 because the backend of AG was returning a 404 (we're using storage account, SA). For example, it looks like the current behaviour for an FD health probe using our set up is FD -> AG -> SA, meaning the health probe sent to AG must be to one of AGs valid backends that returns 2xx or 3xx, which isn't always the case. It would seem one solution would be to have a permanent dummy file in SA that is there to provide something that could return a 200. But yeah it would be nice to have AG itself expose a health endpoint so that FD doesn't need to know implementation details of AG's backend. For example, FD could ping AG, which returns it's own status, rather than the status of a specific endpoint in it's backends.

0 Votes 0 ·