6

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?

5

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.

  • Thank you for the great answer. I added my site configuration to the question text, because you are ofcourse right - we do use a custom domain name for the actual sites. We have a multi-site solution, with the sites defined as shown in the question. However, I cannot find the site named "website" (default site) in our configuration, so maybe that is a flaw in our configuration? Anyhow, could you add some info on considerations for multi-site solutions? I will make sure to mark your answer as accepted – Hos Nov 16 at 9:43
  • Updated for multisite, solutions :). The lack of website is not a problem - considering that your multisite solution registers their own websites - and clearly they are patched correctly. (i.e. on a position where they will get resolved properly - which is usually before the website site :)). – nsgocev Nov 16 at 10:06
  • 1
    Thank you for the great insights :) – Hos Nov 16 at 10:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.