Is it possible to setup Azure Application Gateway to use one server as fallback if the first server is unhealthy?
We currently have this setup in our path-based rules:
/images/* -> server 1 (only server in pool 1)
/* -> server 2 (only server in pool 2)
If we take down server 1, images will return 502 gateway error even if server 2 should be able to handle it. I expected unhealthy servers to be temporarily removed from the path-based rules until they are healthy.
Yes, It's possible to use Application Gateway to achieve that.But you need to add the two VMs in one backend pool.
Just go to one backend pool and then add the second VM into the pool. Then click save.
Also,it's necessary to configure VNet and probe, etc.
More about how to use Application Gateway to offer various layer 7 load balancing capabilities for VMs, refer to this document.
Related
I have a service fabric cluster that hosts some number of identical applications. The application has two main components - a stateless service that hosts web api (it listens on unique port number) and an actor service.
In front of it there is an application gateway instance with multisite listeners to reach proper application instance based on the url. The scale set for the service faberic cluster is set as backend pool for the application gateway.
For each application I have separate http settings with a unique backend port to reach. One of the configuration options for a listener is a health probe that check the web api health, by default on each backend node.
There is no problem when the api is deployed on each node on the backend, but when the api is deployed only on subset of nodes, for the nodes without it the health probe reports this app as unhealthy.
Is there a supported way to configure the application gateway health probe to check health only on a subset of backend nodes. For apps running on a service fabric cluster like in my case it will be strongly desired.
I recommend that you use a reverse proxy on the cluster for this. You can use the built-in reverse proxy, or Traefik for this.
This ensures that all incoming traffic is routed to the services.
It does introduce an additional network hop, so there is a performance impact.
Working on a project where we are starting to use Deployment Slots in our App Services.
All our Prod apps are located behind Application Gateway, and we would like to also have our Slots located behind Application Gateway.
I understand we can not do this using "App Services" as target type in the Backend Pools as of now, but wondered if it is doable using "IP Address or FQDN" as target type.
I have tried to set it up, with various changes in the "HTTP Settings", Probe and so, but haven´t gotten it up spinning.
Can anyone confirm if this is possible, and have any tips on how this should be configured?
Thanks!
I was able to get this working on one of my slots.
Basically setup the listener with your necessary protocol, port cert, hostname, etc... I'm using multi-site listeners so I can have multiple URLs for the one AppGW/Public IP.
The rule points to the listenter, backend pool and appropriate http setting.
The HTTP setting should be configured to connect to your app service URL accordingly. I'm using the azurewebsite.net URL, so I use well known CA cert & override hostname from backend target:
The backend pool then points to the azurewebsites.net URL:
Make sure that GET / works on your app service and returns 200-399 HTTP status codes. Anything outside that range is a failure and the backend pool will be removed. If you need to create a custom health probe to a URL that will respond properly, or adjust the acceptable HTTP status code (if 401 or 403 due to required auth, then just override it with that for testing purposes for now).
I'm trying to do it again with a second slot and running into 502 errors from the App Gateway... However, I'm also waiting on DNS changes from my network team. My first one with my company domain works via hosts file edit, but the 2nd slot (which has 2 different URLs/listeners configured in the AppGW) doesn't want to work the same way for some reason.
In a web application deployed on several Azure VMs, load is balanced using Application Gateway. The selection of Application Gateway is mainly because the application requires cookie-based session affinity.
For a function in the application, a specific VM in the Backend Pool needs to be chosen. So I think giving the user a different login page URL could help me route things properly.
I've tried using different rules, but since a listener can have only one rule this doesn't work in my case.
What I want to achieve is:
https://myapplication/mycontext
Balanced between all the VMs
While https://myapplication/mycontext/process
Directed to a specific VM
Path rewritten to https://myapplication/mycontext
What should the configuration of a Path-Based Rule be to achieve this behavior?
You would need to create 2 backend pool, one to server all content (A) and one specific pool for /process requests (B).
Create a path based rule, a default rule to forward /mycontext/* to the backend pool A
another rule to forward /mycontext/process/* to another backend pool B.
What am I trying to do
I have to azure apps deployed as App services. To make rest post easy let's call them "blog" and "landing_page". Both of them are hosted, so they URL are blog.azurewebsites.net and landing_page.azurewebsites.net.
I want to configure "something" in Azure with following rules:
if user access http://mydomain/ - content of landing_page.azurewebsites.net
if user access http://mydomain/blog - content of blog.azurewebsites.net
What I tried
After reading documentation, I have to reject Traffic Manager because it works on DNS level. From the other two I decided to use Application Gateway, because it should work on eny Endpoint (Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service).
I configured my Application Gateway setting backend to: landing_page.azurewebsites.net. But in "Backend health" the app status is unhealthy. I tried also:
blog.azurewebsites.net - unhealthy
www.wp.pl (polish news portal) - is working
gazeta.pl (polish news portal) - is working
stapp.space (my blog) - this is same as piotrstapp.azurewebsites.net and status is unhealthy
Question :)
What did I wrong? Maybe should I use something else on Azure? Or am I missing something?
Make sure that custom probes is turned on and configured in the HTTP settings of the WAF for your site. If you don't the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won't work and will throw the probe into an unhealthy state resulting in a "502 Gateway Proxy" error.
There is a great article here
You may want to check out Azure's application gateway path-based rules function:
Create a path-based rule for an application gateway by using the Azure portal
Currently I have a Service Fabric cluster with 2 stateless services hosting Asp Web APIs. While creating the cluster also appropriate Azure Load Balancers got created.
Now I would like to add Application Gateway in front of my cluster for various reasons like SSL offloading, url-routing etc.
I'd like to understand how to configure the Application Gateway correctly. I see 2 options, not sure which one is valid:
Application Gateway replaces the existing Load Balancer and points directly to SF services hosting WebApi
I keep existing LB configuration and Application Gateway points to this LB (seems like 1 LB solution too many)
Which one is correct? Any advise how to configure?
Approach 2 is what we are using, We have kept the load balancer and that is routing any request received from the Application Gateway. We found this to be easiest and simplest choice, as this involves minimum changes to be done in Application Gateway.
Your two web api's can run on every node in the VM scale set. The Azure Load Balancer is used to distribute traffic over those nodes. Targeting a single service on a single node will reduce scalability and fault tolerance.
You could use the App Gateway to translate incoming request to different ports on the Load Balancer. (E.g. direct traffic to API 1 #url ~/1/ and API 2 #url ~/2/)
Favor using load balancing rules (using all nodes) over NAT redirections (to single nodes). This way you'll have a performant, reliable system.
Solution 2 would also provide possibly to create VPN connection e.g to manage your cluster. Then no need to expose management endpoint to the public. Internal lb also brings on additional features to utilize in the future.
I would go with your first option and to implement it create / modify your ARM template so that it doesn't contain the load balancer and instead contains the application gateway.
Here is a link to the quick starts for ARM templates which you can use. There isn't an out of the box example for service fabric with a gateway but it will give you a great starting place.
link