I am building a multitenant application and I would need to know if I can achieve this in Azure.
Assuming the application will be deployed to multiple regions/datacenters. The tenant will be identified by the subdomain: tenant1.domain.com, tenant2.domain.com and tenant3.domain.com. My question is how can I make the redirect so that tenant1.domain.com will be redirected to an application hosted in an US datacenter, tenant2.domain.com to a datacenter in EU and tenant3.domain.com to a datacenter in Australia for example?
I will guess here I have to use Azure Traffic Manager and DNS? Can somebody point me to correct path?
One possibility would be to use Azure DNS (or any DNS with an API really) to setup the CNAME record for a tenant so that it points to the right datacenter.
You would then have to add that as a custom domain on the app if you run on App Service.
Though it does have a limit on the number of domains, max 500 according to: https://stackoverflow.com/a/31565429/1658906.
If you run on virtual machines, you can of course configure the server to accept traffic to *.domain.com.
Can't really do that with App Service, since you would only be able to map the wildcard record to one region.
You can't really use Traffic Manager in this case I think, since your tenant's data really is in one datacenter.
Unless you have replication to a secondary, in which case you could use a TM profile per region in Failover mode.
Related
In a bid to reduce our Azure costs we are looking to remove unused resources.
We have an app service that is part of a traffic manager setup, reachable when users type x.com in their browser. Two app services exist:
eus-x-com.azurewebsites.net
wus-x-com.azurewebsites.net
These are added to a traffic manager profile, and when they were added to TM they were configured to have custom domains to both be x.com
DNS for x.com points to x-com.trafficmanager.net, the name of the traffic manager endpoint that manages these two sites.
This means there is now:
//sites under Traffic Manager control of x.com
EastUS App Service Plan 1
eus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
WestUS App Service Plan 1
wus-x-com.azurewebsites.net (with custom domain x.com -> x-com.trafficmanager.net)
//sites not assigned to a traffic manager
EastUS App Service Plan 2
y-com.azurewebsites.net (with custom domain y.com -> y-com.azurewebsites.net)
z-com.azurewebsites.net (with custom domain z.com -> z-com.azurewebsites.net)
After some years it seems that eus-x-com.azurewebsites.net has never failed and it's not used much, so we're looking at having East US Service Plan 2 host one instance of x.com, plus the other sites it hosts and getting rid of the traffic manager, and the east/west service plan 1 leaving just service plan 2
The idea was to:
create a new app service in EastUS App Service Plan 2 called x-com.azurewebsites.net
deploy the code to it so it will work
give it a custom domain of x.com (i.e. the equivalent of adding a host header in IIS)
change DNS to point to x-com.azurewebsites.net so that traffic gradually starts coming to the new web app as DNS servers around the world update
delete the whole TM infrastructure at some point
I hit a problem: even though I can validate DNS domain ownership I come up against a restriction that two different app services, even in different app service plans, cannot have the same custom domain setting unless they're part of a traffic manager setup. I get a "x.com custom domain is already in use on an app service eus-x-com.azurewebsites.net" when trying to add a custom domain of x.com to x-com.azurewebsites.net
This is a bit annoying as I foresee no reason why it should be technically impossible to have the same custom domain on two app services in different plans, if all it is (in old IIS terms) is a host header/binding; which app service is actually in use depends on which IP address traffic arrives at based on DNS. The custom domain binding is a routing mechanism to know which app service to pass traffic to when it arrives at an IIS hosting multiple sites. While I think it sensible that azure prevents multiple app services within the same plan from having the same custom domain assigned, I cannot see how it is logical to prohibit app services in different app service plans from having the same custom domain setting
Instead I looked at doing:
create a new site in EastUS App Service Plan 2 called x-com.azurewebsites.net
deploy the code to it so it will work
add it to the traffic manager so that I can then set the custom domain of x.com on it (because it's allowed to re-use custom domains if sites are on the same traffic manager profile)
change DNS so that traffic gradually starts coming to the new web app directly, bypassing TM
delete the whole TM infrastructure at some point
This is where I get another problem:
Two app services in the same region (regardless of whether they're on a different app service plan) cannot belong to the same traffic manager profile. Even though these sites are on different app service plans, those plans are in the same region (EUS) and the error message in the portal is:
Traffic manager configuration is not valid because one or more domains do not belong to subscription 'xxx'
A github discussion from an MSFT employee said that this is a bogus error message that should be interpreted as "you can't have two app services in the same region be part of the same TM". You can have it if one of them is an external endpoint, but then it doesn't add the custom domain for you, which is the only thing I wanted out of adding the new site to TM
I then found out that I can, instead, edit the TM and change where the endpoint points to:
//existing setup
TM
east-us-x-endpoint -> eus-x-com.azurewebsites.net
west-us-x-endpoint -> wus-x-com.azurewebsites.net
//proposed setup
TM
east-us-x-endpoint -> x-com.azurewebsites.net //edit it to point to the new x-com
//delete the west US one
I've done this, and edited the endpoint to target a different app service. Though the portal says the change has been made there are problems:
the traffic manager is definitely still sending traffic to the old app service, because the site works even though the new app service doesn't have any code on it yet
stopping the old eus-x-com.azurewebsites.net app service (not configured in any TM endpoint any more) causes the web site to stop working with HTTP 503
Things might have worked out if I hadn't deleted west us already. Though not ideal because it was slower (database in East US) I could probably have deleted eus-x-com out of TM and let wus-x-com take the load, then added x-com (which is in EUS) to TM and made it priority 1, it would have got a custom domain, all good.. except there is no west us setup any more. I might have to add it back
I'm now stuck; I basically need two app services, in the same region, on different service plans, to have the same custom domain for a while so I can switch over the DNS then dismantle one of them. Or I need another way to set up a new app service so that it ready to take traffic, get all traffic to start going to it, and then remove the old setup
What steps can I take to get a new app service up and running, give a custom domain to it and then switch DNS over so that all traffic goes to the new site, without causing any downtime?
As far as I know, either the DNS name of Traffic Manager or App service is globally unique. We can not have the same custom domain to use for two different app services. Read ICANN.
So you still need a load balancer to route upper DNS level incoming traffic for your backend app services when you want to use the same custom domain. I also don't think you can switch DNS for app services in Azure without traffic manager. If you want to route traffic to app services in the same region, you could use nested Traffic Manager profiles. Read this answer for more details.
I want to have the following setup in Azure.
* Main Traffic manager
- WebAppA (West Europe)
- Nested Endpoint
* WebAppB (West Europe)
WebappA has a custom domain name linked with a CName to the main traffic manager.
Now WebAppB also needs this custom domain name, but I'm not possible to add this.
I receive the message "Hostname is already being used in the following App WebAppA".
What I want to achieve is to have 2 WebApps running in the same datacenter with a Traffic manager on top to have better control control over the setup while doing BlueGreen deployments.
We currently have a setup spread over 2 datacenters, but we experience a lot of latency while hopping to the SQL server in WestEurope from UKSouth?
Is there any setup what can make this work?
I would suggest you to raise a support ticket where MS engineers can force add the Custom Domain if you are able to prove your Domain ownership.
The error which you are getting has nothing to do with the Traffic Manager Nested configuration. Since you have added the Custom Domain to the WebApp A, you are not able to add it to the Web App B due to some validation check.
There are probably two methods.
You could associate the same hostname to multiple web apps regardless of subscription (or even AAD tenant!) using the awverify method of validating domains. That is to create two TXT records for your two web app services.
Hostname — awverify.targethostname.yourdomain.com
Set type = TXT
value = <yourwebappname>.azurewebsites.net
TTL — short. Like seconds or minutes.
You could get more details from this blog: Azure Traffic Manager with Web Apps in different subscriptions.
Another option is to assign the same hostname to Web Apps in different app service plans. 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. Read the details in the the SO answer.
I am trying to experiment a little bit the different configuration possibilities in Azure and I am stuck trying to correctly configure SSL custom domains when using more than one Web Site (App Service) behind a Traffic Manager.
Without problem, I was able to:
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net )
Attach a custom domain ( subdomain.mydomain.com ) to an Azure App Service ( subdomain1.azurewebsites.net ) behind a Traffic Manager ( subdomain.trafficmanager.net) (addressed here)
But when I try to add a second App Service behind the Traffic Manager, I get the following issues:
1. Cannot attach my custom domain ( subdomain.mydomain.com ) to the second App Service ( subdomain2.azurewebsites.net ). Error message is:
Failed to update hostname bindings:
The host name subdomain.mydomain.com is already assigned to another Azure website: subdomain1.
I don't understand how SSL will work with the second website if I can't add subdomain.mydomain.com in the list of domains it listens to (and in fact, it doesn't if you don't add it).
2. Cannot add the second App Service to the Traffic Manager's list of endpoints. Error message is:
Failed to save configuration changes to Traffic Manager profile 'mytrafficmanager'.
Error: Some of the provided Azure Website endpoints are not valid: One or more conflicts detected in traffic manager configuration. Multiple domains point to region "West Europe": subdomain1.azurewebsites.net, subdomain2.azurewebsites.net
But when I read the documentation it does seem possible to add more than one endpoint in the same region:
If your profile contains multiple endpoints in the same Azure region, then traffic directed to that region is distributed evenly across the available endpoints (based on the configured endpoint enabled/disabled status and the ongoing endpoint monitoring). If you prefer a different traffic distribution within a region, this can be achieved using nested Traffic Manager profiles.
The example using Traffic Manager and App Service on MSDN's documentation only shows how to do it with one App Service.
Am I doing anything wrong? If yes, what is the right way to add several websites/App Services behind a traffic manager in Azure?
Traffic Manager does support multiple endpoints in the same region. The challenge is that the App Service has restrictions on multiple Apps in the same region sharing the same custom domain. This impacts on Traffic Manager, since the Traffic Manager profile DNS name is automatically added as a custom domain in your apps when adding them to Traffic Manager.
We are in the process of publishing new documentation that covers this exact scenario. Pasting the new text below:
Can I use Traffic Manager with more than one web apps in the same region?
Typically, Traffic Manager is used to direct traffic to applications deployed in different regions. However, it can also be used where an application has more than one deployment in the same region.
In the case of Web Apps, the Traffic Manager ‘Azure Endpoints’ type does not permit more than one Web App endpoint from the same Azure region to be added to Traffic Manager. The following steps provide a workaround to this constraint:
Check that your Web Apps within the same region are in different web app 'scale units', i.e. different instances of the Web App service. To do this, check the DNS path for the <...>.azurewebsites.net DNS entry, the scale unit will look something like ‘waws-prod-xyz-123.vip.azurewebsites.net’. A given domain name must map to a single site in a given scale unit, and for this reason two Web Apps in the same scale unit cannot share a Traffic Manager profile.
Assuming each Web App is in a different scale unit, add your vanity domain name as a custom hostname to each Web App. This requires all Web Apps to belong to the same subscription.
Add one (and only one) Web App endpoint as you normally would to your Traffic Manager profile, as an Azure Endpoint.
Add each additional Web App endpoint to your Traffic Manager profile as an External Endpoint. This requires you to use the ARM experience for Traffic Manager, not ASM.
Create a DNS CNAME record from your vanity domain (as used in step 2 above) to your Traffic Manager profile DNS name (<…>.trafficmanager.net).
Access your site via the vanity domain name, not the Traffic Manager profile DNS name.
Regards,
Jonathan Tuliani, Program Manager, Azure Traffic Manager
Jonathan,
This issue is still confusing when integrating SSL.. I'm not trying to add instances to the same region, but diff regions.
https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#traffic-manager-example
This article does a good job of explaining the routing, but minus the SSL..
From the image. Say this is my configuration.. I have a *.contoso.com wildcard SSL. Of the 3 endpoints, contoso-us, contoso-eu, contoso-asia - which one do I install the SSL? Preferably all 3, but I can't set the all to use the custom domain and the SSL..
What am I missing here?
I have a VM setup on Azure (classic VM running CentOS). I am developing my mobile app that connect with RESTful API's hosted on Azure VM. My mobile app performance was slow and on investigation, I found DNS lookup to the FQDN of my Azure VM is too long (about 5-5.5 seconds per lookup) and very frequent. Attached is the output of "dig" tool on my Mac.
Dig tool output
Is there a way I can control TTL for the Azure VM's? Would it help if I buy a static IP and map it to my Azure VM's FQDN? Also, is there a way to reduce the DNS lookup time?
Thanks,
Giri
The TTL is associated to the domain name. If you want to increase the TTL you would need to purchase a domain name and associate it with the domain. With your own domain name you can set whatever TTL you require.
You would be far better developing against a domain name as this will give you the most flexibility with regards to developing against it, since you are able to move the location that your application points to, and should your app be particularly successful you would need a domain name for load balancing etc.
Is it possible to use an Azure virtual machine that's setup as a domain controller to manage virtual machines hosted on other Azure subscriptions?
Personally I have never tried this before, but do not immediately see an issue with it.
I assume your Domain Controller is deployed using Microsoft's guidelines including assigning a static IP address?
With the ability to connect one VNet to another VNet (See: https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-configure-vnet-to-vnet-connection/) you can create the required network connectivity.
What you probably need to do is use your own DNS server for name resolution (See: https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-name-resolution-for-vms-and-role-instances/) in all connected VNets. I would recommend running DNS on your Domain Controller.
One thing to consider however is the generated traffic for authentication and name resolution. Do know that Azure is charging for traffic traversing from one Azure region to another.
Hope this helps you moving forward.
in this scenario is it required to create DNS server per subscription or one DNS server is enough for multiple subscription.