I have been looking at setting up Geo DNS routing using Azure Traffic Manager (Performance mode). Basically I have an application (Web App and Azure SQL Database) set-up in East US, North Europe and Australia East. For compliance reasons data cannot be shared between data centres, and I do not want the user to have to make a choice regarding which data centre the use:
us.app.com
eu.app.com
au.app.com
I want to be able to use app.com and then have that routed based on the user location. All of which Traffic Manager does - however it will also fail over to other data centres if the closest data centre is unavailable. I don't want the fail-over behaviour - if for some reason the Web App is down in the closest region, I want the user to receive an error.
Has anyone experience of any other providers that offer such a facility? Can the fail-over behaviour be turned off on Traffic Manager.
Interesting question!
Firstly, please note that the 'Performance' mode routing in Traffic Manager is not guaranteed to route a given user to the same data center if that use travels...for example, if an EU user accesses the service whilst visiting the US, they will be routed to the US endpoint. For this reason, where there is a strong constraint to link a user with a particular region, an application-level re-direct may be required.
To address the question you actually asked...there's no built-in ability to disable endpoint monitoring / failover in Traffic Manager today. As a workaround, I suggest making a placeholder site that hosts an error page using Azure Web Apps, then using nested Traffic Manager profiles as follows
3 child profiles, each with 2 endpoints - one of your service endpoints plus the error page web app. These will use the 'Priority' traffic-routing method (aka 'failover' if you're using the old ASM APIs)
1 parent profile, with 3 endpoints, namely the 3 child profiles above. This should use the 'Performance' traffic-routing method. You'll have to specify the location of each endpoint, which should be the same as the app that it contains.
In this way, if one of your apps fails, traffic will be directed to the error page site instead of to the other apps.
Configuring nested Traffic Manager profiles isn't supported in the Azure Portal today. You will need to use Azure PowerShell or Azure CLI (which supports Windows, Linux and Mac OS)
Regards,
Jonathan Tuliani
Program Manager
Azure Networking - DNS and Traffic Manager
Related
Hello I have 3 different web app. Each web app has a different application with a different endpoint. I need to replicate all of these app services in multiples region. My question is. Do I need to have one Traffic manager for each replication application?
The other alternative that I had was. I could have one traffic manager in front of all applications, and Behind the traffic manager but ahead of the all application for integrating all app service in a one, I could have one API gateway. In that case, I suppose that I could have only one traffic manager instead of three.
Does somebody have one recommendation for this type of architecture?
Azure traffic manager is designed as a global service,not bound to a location. If you have 3 webapps located in different regions, use one traffic manager to route all requests will be ok. This reference architecture will be helpful: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/multi-region
I'm using Azure App Service to setup my website. I have 2 Azure App Service instances and 2 Azure SQL.
1 App Service instance is in the Central US and 1 App Service instance Central India. 1 SQL instance is in the Central US and the other is in Central India.
I use Traffic Manager to route traffic to either region.
What confuses me is that, when I access the Indian server directly the page seems to load at pretty much the same speed as the server in the US.
And both seem to load relatively quickly. Around 250-350ms each to load a page with no styling that performs one database query.
Does this mean that deploying in multiple regions is overkill? Would I be better deploying a larger instance in a single region?
A multi-region architecture can provide higher availability than deploying to a single region.
If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region.
This architecture can also help if an individual subsystem of the application fails.
Also, when you configure you Traffic Manager, create a health probe endpoint that reports the overall health of the application and use this endpoint for the health probe.
The endpoint should check critical dependencies such as the App Service apps, storage queue, and SQL Database.
Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing.
For more details, you could refer to this article.
What i want to do is:
have two domains been served by the same code (pointing to the same folder)
each one using its own database and theme (css, images)
separate clients been registered in US to interact with databases based in US from those been registered in EU to interact with databases based in EU. Even if they try to login from an other region.
I don't know if that is possible with Azure, what structure i need, or what tools to use.
Azure Traffic Manager works at the DNS level and enables us to control the distribution of traffic across our application endpoints according to one of several traffic-routing methods, you could try to use it. This blog explained how to use scale Azure Websites globally with Traffic Manager, please refer to it.
I have a custom domain www.abc.com configured for web app webapp-a, and I'd like to transfer it to webapp-b without downtime.
If I try to add the domain to webapp-b, I am getting
The host name www.abc.com is already assigned to another Azure website: webapp-a
It there a way to let webapp-a continues to serve the requests, until the DNS cache expires?
Edit: The domain has IP based SSL binding, and the DNS is caching the virtual IP.
I faced the same issue, and was able to solve it in a tricky way.
I created new App Service Plan (previously known as Web Hosting Plan), and assigned "new" Web App to it (you can do it via new portal, or you can create Service Plan during Web App creation).
Then, I was able to assign the same host name to Web Apps in different hosting plans.
Thinking about this, I feel it logical: most probably Service Plan is mapped to physical IIS machine, and you cannot have two sites with the same host name in the same IIS for the obvious reason.
After migration from one DNS to another is done, you can remove unused Service Plan (as you basically pay for each separately).
According to a blog post by the Azure App Service Team in June 2017, it would appear that Azure now supports adding the same custom domain to multiple web apps:
There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
You can read the entire blog post at https://blogs.msdn.microsoft.com/appserviceteam/2017/06/21/custom-hostnames-with-app-service/. The quote above was taken from the Adding the same custom hostname to multiple web apps section.
This should help in scenarios such as this where you want to transfer a custom domain name from one web app to another. You can simply add the same custom domain name to both web apps, add any required SSL bindings, and then change the DNS to point to the new web app. As the DNS change propagates, traffic should gradually move over to the new web app without any downtime.
I've tested this myself in the North Europe region and had no problems. Both web apps were in different App Service Plans. I have not tested this scenario with both web apps in the same App Service Plan. Bear in mind that if you're using IP addresses/A records in your DNS, you'd need both web apps to have different IP addresses for the DNS to be able to differentiate between your web apps.
Try assigning the domain to Azure Traffic Manager and have the traffic manager forward the request to the second site. Azure Traffic Manager and Web Apps are two different systems so you might be able to assign the same domain name to a web app and a traffic manager.
Once the DNS cache has expired remove the domain from the old Azure web app and add it to the new one, then finally delete the Traffic Manager account.
Option 2
Set the TTL to something very small, say 5 seconds (I believe your hostname provider should let you set that up), wait for the new TTL to propagate through all the caches. Then switch the custom domain from one app to another, and set the TTL back to it's original value.
This will result in just a few seconds of downtime for any customers, but if you do it at a low-traffic time the effect shouldn't be too bad.
I'm currently developing a mobile app which will be pushed world-wide across the app stores. This app uses a WebAPI REST service as the backend which I currently have running on MS Azure in Europe (which backs onto a database also in Europe).
My problem is, I'd like to create multiple Azure WebApi endpoints (i.e. Australia, US, etc for latency reasons), each with their own database which has geo-replication enabled.
Does anyone know a method/product/service I could use which allows me from the app to either:
Connect to a single domain which behind the scenes picks the closest server to the user.
OR
The app itself is able to determine based on a given list the closest server and connect to that?
I've looked at Azure CDN but this is for static content which is great but I need something for dynamic content.
What you're looking at is Traffic Manager. Traffic manager enables that exact scenario, of finding the closest service that hosts your REST API.
Keep in mind though, that the database replication is (for the time being) a thing you have to do yourself, although we do provide you with the tooling and guidance on how.