0

I am attempting to set up an Azure Application Gateway (with WAF) that points to a pool of 2 IIS servers (IaaS VMs) in the backend pool. These servers host a number of websites and I am trying to figure out the best way to set up probes for the health monitor. Essentially what I want is the AGW to remove only the routing for a particular site when its health goes bad, not the whole server. Typically I have seen a single probe added where the -HostName is just the domain (contoso.com) which my understanding would remove the entire server from the backend pool if the health went bad.

Since there are multiple subdomains (a.contoso.com, b.contoso.com etc), would it be better to have a probe set for each one, as well as a rule and listener for each one that leverages the probe? Or would it be best to just stick with the entire domain for probe, listener and rules and just drop the whole server on updates etc?

Essentially its an IIS box running quite a few APIs that are separated by subdomains rather than a single subdomain with custom routes to each API. For performance I would rather keep all the api's reachable in case just one is being updated and down temporarily or has an issue while the others are not.

CoreyZ
  • 189
  • 2
  • 3
  • 11

1 Answers1

1

You can achieve this with multiple http settings, each with its own probe. For example if you have a.domain.com and b.domain.com running on the same set of backend servers, you would create two http settings and two custom probes. Probe1 would probe on a.domain.com as host name and probe2 with b.domain.com. Your backend pool will be a single backend pool with the two servers. Now you can create two rules and attach the two probes & settings to the rules and point them to the same backend pool. The probe will only mark down a.domain.com or b.domain.com but not the whole VM. Hope that helps.

amsriva-msft
  • 319
  • 1
  • 5
  • It does as that is how I was hoping it would work. When creating the 1)AGW I would add both servers to the backend address pool 2) Create a probe for each subdomain 3) Create a backendhttpsetting with each probe? Or create with no probe? – CoreyZ Mar 13 '18 at 10:59
  • Sorry, fat fingers and no sleep so that comment couldnt get edited in time It does as that is how I was hoping it would work. When creating the AGW I would : 1) Add both servers to the backend address pool 2) Create a probe for each subdomain 3) Create a backendhttpsetting with each probe 4) Create listener for each subdomain 5) Create rule for each listener/backendhttp setting combo Thanks Amsriva – CoreyZ Mar 13 '18 at 11:10
  • This all makes sense - but my Application Gateway continues to resolve to the Default Website in IIS. The individual sites respond as anticipated, but when configured through the AG - the only site visible is the Default. VM is internal only (no configured public IP). DNS is managed via DNS Zone. Can browse sites when connected via VPN Gateway with Point-to-Site connection. Any suggestions to troubleshoot my issue? – AndyZez Jun 11 '18 at 19:02
  • The issue was not with the Application Gateway, but with the IIS config on the VM. I had expected the App Gateway to recursively route to the VM domain name based on configuration - which it did - but it did not send the internal domain name. The public domain name (listener) was passed to the VM. When a domain name binding was added to the VM IIS site config for the App Gateway domain (i.e., the public domain name), the expected site rendered. – AndyZez Jun 12 '18 at 20:02