We are planning to have a web app hosted in 2 web servers in 2 different azure regions and I am planning to use either traffic manager or Azure front door for load balancing.
We want to distribute traffic based on priority so if app at one region goes down, LB can shift to other instance.
Suppose I have one instance hosted in Central US and other in Europe and using Traffic manager or Front door in India region.
I want to set Central Us instance as primary and Europe as Secondary, So LB can route traffic to Central Us and fail over to Europe in disaster.
What happens when user gets connected to Central Us region and it goes down, how does load balancer handle the session management? is it handled by load balancer automatically or any configuration needed for the same?
I do not want to go with Azure front door Sticky sessions as I want to use Priority based routing.
As traffic manager acts at DNS level, can I use it for my use case?
Yes, the Priority traffic-routing method of Azure traffic manager is exactly doing the trick in your scenario.
Select Priority when you want to use a primary service endpoint for all traffic, and provide backups in case the primary or the backup endpoints are unavailable.
By default, Traffic Manager sends all traffic to the primary (highest-priority) endpoint. If the primary endpoint is not available, Traffic Manager routes the traffic to the second endpoint. If both the primary and secondary endpoints are not available, the traffic goes to the third, and so on. Availability of the endpoint is based on the configured status (enabled or disabled) and the ongoing endpoint monitoring.
Reference: Tutorial: Configure priority traffic routing method in Traffic Manager
Update
Since Azure TM works at the DNS layer, it has no way to track individual clients, and cannot implement 'sticky' sessions. If you still persist to use it for sticky sessions, you need to have an extra configuration on your web apps.
So, in this case, the Azure front door is a better-recommended method for Sticky sessions and it also supports Priority-based traffic-routing.
Each backend in your backend pool of the Front Door configuration has
a property called 'Priority', which can be a number between 1 and 5.
With Azure Front Door, you configure the backend priority explicitly
using this property for each backend. This property is a value between
1 and 5. Lower values represent a higher priority. Backends can share
priority values.
When you add a backend web app in the backend pool, you just need to specify the priority in the Azure front door UI.
Related
Just wanted the recommendations in using azure frontdoor or azure traffic manager for my 2 different web apps hosted on different regions? Can we use both together?
Both Azure front door and traffic manager are deployed in a region agnostic way by azure to help load balance instances between region pairs. If you are hosting web applications using azure app service, the recommend solution for load balancing between regions is Front Door since your traffic is Http(s). (whereas a traffic manager would work nice if you are running virtual machines in different regions and want to load balance between them)
And if you want to further load balance traffic between different web apps in the same region, use an azure application gateway. (your front door directs user traffic to a region, and within that region, the application gateway directs traffic to a healthy web app.)
You can read this for a decision tree of the load balancing options provided by microsoft : https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview#decision-tree-for-load-balancing-in-azure
IMHO you should use the one that makes more sense. Traffic Manager you can work with different algorithms when routing to the right region, while Front Door you don't have this flexibility.
On the other hand, Front Door offers some features like Web Application Firewall (WAF) and SSL Offloading that may be interesting in your scenario.
Currently, I am trying to setup a traffic manager profile for our company needs. Although I read the articles and documentation, I did no find an answer. Our goal is the following:
Route traffic based on domain name/website:
abc.com - routed to West Europe / West US is a backup
def.com - routed to West US / West Europe is a backup
Do we need to create separate traffic manager profile for each website we want to route to these regions. As I understand with custom headers it is possible to monitor different websites inside the profile, but obviously not to direct traffic using different rules for each website.
Probably, I am missing something out.
Thank you in advance.
Azure traffic manager supports the following traffic routing methods:
Priority, Weighted, Performance, Geographic, Multivalue, Subnet.
If you want to direct traffic based on the domain name, you need to create a separate traffic manager profile for each domain. Then create two endpoints by selecting Priority routing rules in each profile.
In addition, you could have a look at the Azure front door. With Front Door, you can transform your global consumer and enterprise applications into robust, high-performing personalized modern applications with content that reach a global audience through Azure. It supports URL-path based routing for requests. You also could assign priorities to your different backends when you want to use a primary service backend for all traffic.
We are designing a multi-location deployment within Azure that requires users to be sent to their closest origin. At the moment we are using a traffic manager however that is causing us some issues with another layer in the client's infrastructure.
Another option we are investigating is Front Door however that introduces a new challenge - how can we prevent our origins from being publicly available?
For traffic manager, Microsoft publish a list of probe ip's which we can whitelist within our webapps: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#what-are-the-ip-addresses-from-which-the-health-checks-originate
Does front-door offer a similar thing? The ideal outcome would be a set of ip address (ala https://azuretrafficmanagerdata.blob.core.windows.net/probes/azure/probe-ip-ranges.json) which we could import into our webapps firewalls.
You can lock down access to your origins by whitelisting the Anycast IP address ranges used by Azure FrontDoor Service:
IPv4 - 147.243.0.0/16
IPv6 - 2a01:111:2050::/44
Source: How do I lock down the access to my backend to only Azure Front Door Service?
You can now use Azure Front Door service tags to manage the scenario of restricting traffic to your backend to AFD only. Overview of service tags:
A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change
Also available in the above doc are the service tags for AFD, to restrict access in the way described you can use the AzureFrontDoor.Backend service tag.
Assuming your backend can support it, you can also add a further filter which ensures the traffic hitting your backend not only comes from AFD's IP range but also that it's your AFD! See this doc:
...restrict the traffic on your backend to the specific value of the header 'X-Azure-FDID' sent by Front Door
The ID of your AFD can be retrieved in the following ways:
Perform a GET operation on your Front Door with the API version 2020-01-01 or higher. In the API call, look for frontdoorID field. Filter on the incoming header 'X-Azure-FDID' sent by Front Door to your backend with the value as that of the field frontdoorID. You can also find Front Door ID value under the Overview section from Front Door portal page.
Azure Front Door Service provides dynamic website acceleration (DSA) including global HTTP load balancing. Front Door Service is mixed of ADC and CDN networking. When do a health probe, the Front Door environments will send a probe, this DOC states that there are about 90 Front Door environments or POPs globally. It seems that the document could not describe which specific probe IP address are in the Front Door environments. You could look at this issue on Github.
Currently, the Front Door service is the public preview, it may take some time for release. Also, It's not recommended to use it in the production environment.
We have a set-up an azure gateway of tier WAF V2 (so it would be zone-redundant). It has a backend pool containing 2 WebApps -AppServices (supposedly a Primary and a Secondary).
The idea behind it was to use the gateway similarly to priority traffic manager: Routing usually to the primary WebApp, and only routing to the secondary WebApp in case the first one goes down.
The Problem is that the only way I found to do that is to order the rules associated with the listeners of the backend pool (because I believe azure prioritizes them according to the order they are listed). But given that both Apps are in the same backend pool, Im unsure of how to do that.
So now the gateway randomly routes to either the first or second WebApp.
Any advice or suggestions would be much appreciated,
Thank you
Note: Also we have tried setting a traffic manager in between the gateway and the WebApps, but the gateway keeps connecting to the primary WebApp even when its down and its probe becomes of health status unknown.
Application Gateway is a layer 7 load balancer, which means it works with web traffic only (HTTP/HTTPS/WebSocket). It supports capabilities such as SSL termination, cookie-based session affinity, and round robin for load balancing traffic. This indicated that the application gateway frontend randomly distribute the incoming traffics to the endpoint if both endpoints are healthy. So you could see the gateway randomly routes to either the first or second WebApp. See the application gateway FAQ. The app gateway does not work like priority-based traffic manager which always requests to the primary web app unless the primary web app is unhealthy.
About the health status unknown, the most common reason is that access to the backend is being blocked by an NSG or custom DNS. Ref: Troubleshooting bad gateway errors in Application Gateway
If two logic apps are there in two different regions and I want to do load balancing between these two how to do this.
Through some source, I got to know that it is possible through API management but they have not mentioned how to do this.
So, how to do load balancing between two logic apps?
Well...why do you want to do this? "Load Balancing" especially with LogicApps is fundamentally different on Azure than on-premise or self hosted. It's not wrong, just different ;)
What they were probably referring to was Azure Load Balancer which appears as a Networking Service, not APIM.
This, you can use to distribute requests as you would with traditional load balancers.
Since you want to load balance across regions I would look into Azure Traffic Manager. Traffic Manager is a DNS load balancer that sits outside/above Azure regions and allows you to have traffic balanced based on various performance profiles (i.e. Weighted, Performance, etc.)
High Level / General steps are:
Setup Logic Apps in 2 Regions
Create and register public dns domain for the logic apps - apps.foo.com (done outside Azure typically)
Point your DNS record for apps.foo.com to Azure Traffic Manager
Add endpoints to Azure Traffic Manager for Logic App in Region 1 and Logic App in Region 2 and setup your traffic manager profile
Calls to the Logic App start with the custom DNS domain get routed to ATM which then distributes to the regions based on your configured profile.