Azure Traffic Manager and Sitecore 9.2.0 PaaS

Question

Background

We are trying to create a "lightweight" failover setup, consisting of a failover CD instance with the core + web database being replicated (Azure SQL failovergroup). Additionally, that means adding an Azure Traffic Manager infront of the two CDs. I call this a lightweight setup, since I just want the CD site to be available in case any outages in our primary Azure region.

What we tried

We tried to setup the two CD instances, lets call them:

north-europe.azurewebsites.net

west-europe.azurewebsites.net

as endpoints in the traffic manager (e.g. my.trafficmanager.net). We also added these two instances as valid hostnames in the Sitecore config.

Both endpoints appear with "online" status in the traffic manager.

I verified that the trafficmanager binding "my.trafficmanager.net" appears on both app service bindings in the Azure Portal.

Our website is a multi-site solution, with configuration like this: (for CD site)

<sites env:require="TestCD">
    <site name="site1">
      <patch:attribute name="targetHostName">tst-site1.contoso.com</patch:attribute>
      <patch:attribute name="hostName">tst-site1.contoso.com|north-europe.azurewebsites.net|west-europe.azurewebsites.net</patch:attribute>
    </site>
    <site name="site2">
      <patch:attribute name="targetHostName">tst-site2.contoso.com</patch:attribute>
      <patch:attribute name="hostName">tst-site2.contoso.com</patch:attribute>
    </site>
  </sites>

The problem

When I browse the my.traffimanager.net, I expected to see my Sitecore application from either of the endpoints (depending on which the traffic manager selected). However, it seems that Sitecore always resolves to the scheduler site. Do I also need to add the trafficmanager (my.trafficmanager.net) as hostname for each Sitecore site or did I misconfigure something?

Answer 1

TLDR; Yes - you have to add the my.trafficmanager.net to the site definitions of your website (considering that in your case you have added the actual bindings to the website site removing the catch-all rule for Sitecore. If that is not the case and you have the website site untouched - there might be a deeper problem with the actual resolution happening on the sites)

The reason for this actually lies inside the entire mechanism that Azure Traffic Manager works. And especially the part

The client connects to the application service endpoint directly, not through Traffic Manager. 

which is happening after the DNS resolution happened.

In real case scenario you are probably going to have your real domain name (i.e. www.example.com) pointed towards the ATM and it will be responsible for handling the actual traffic that is coming for your website. As ATM is not acting as a reverse proxy it will just redirect the request to the responsible node keeping the hostname that was requested.

In order for Sitecore to be able to resolve the website - it is going to use hostname that the node was requested with - which in your case is going to be my.traffimanager.net. Meaning that you have to bind it in your site definition.

So basically each website is going to get resolved by the hostname coming from the Azure Traffic Manager.

In case you have multi-website solution and you want to handle the traffic routing for multiple websites - you should use the Azure Traffic Manager profiles and make sure each site definition has the correct hostName correctly bound to match the one coming from ATM.