what's a good native Azure service that I can use for Active/Passive load balancing on VM's with private endpoints? The application on these servers will cause issues if more than one node is active and we'd. The VM are in availability zones with connected via private endpoints only. We need connection to TCP ports so it's not just port 443 access.
Thank you
what's a good native Azure service that I can use for Active/Passive
load balancing on VM's with private endpoints?
You can use Azure Traffic Manager with the Private Endpoints for load balancing the Azure VM.
if you are using Azure Traffic Manager then you need to remember one thing that Health Monitor feature is not available for Azure Traffic manager with private End Points
Understanding Traffic Manager probes
Traffic Manager considers an endpoint to be ONLINE only when the probe receives an HTTP 200 response back from the probe path. If you application returns any other HTTP response code you should add that response code to Expected status code ranges of your Traffic Manager profile.
A 30x redirect response is treated as failure unless you have specified this as a valid response code in Expected status code ranges of your Traffic Manager profile. Traffic Manager does not probe the redirection target.
For HTTPs probes, certificate errors are ignored.
The actual content of the probe path doesn't matter, as long as a 200 is returned. Probing a URL to some static content like "/favicon.ico" is a common technique. Dynamic content, like the ASP pages, may not always return 200, even when the application is healthy.
A best practice is to set the probe path to something that has enough logic to determine that the site is up or down. In the previous example, by setting the path to "/favicon.ico", you are only testing that w3wp.exe is responding. This probe may not indicate that your web application is healthy. A better option would be to set a path to a something such as "/Probe.aspx" that has logic to determine the health of the site. For example, you could use performance counters to CPU utilization or measure the number of failed requests. Or you could attempt to access database resources or session state to make sure that the web application is working.
If all endpoints in a profile are degraded, then Traffic Manager treats all endpoints as healthy and routes traffic to all endpoints. This behavior ensures that problems with the probing mechanism do not result in a complete outage of your service.
Else you can even use Azure Front door premium as it supports traffic routing to private link. by which you need to use application gateway/load balancer as backend private IP's and front door as the routing methods.
Related
We have setup Azure Front Door (AFD), with an Azure Load Balancer (ALB) behind it, as what was recommended when taking the decision tree approach found here --> Decision tree for load balancing in Azure
Here is an image as well for quick reference:
We have configured everything and it is working from a resolving perspective and the websites are being presented and all.
We are struggling to configure session affinity as the backend websites and applications are using ASP.NET MVC 5.0 they require session based items. Therefore when a user requests the application, each subsequent request should be routed to the same backend.
We have enabled session affinity from AFD and we can see the cookies being set, and they stay constant between requests, but we assume that because the ALB is a layer 4 load balancer it does not respect cookies, and that is why the session affinity is being lost and each request is sent to another request in some scenarios. This creates the issue that the Session variable is not available anymore and the user is logged out due to this.
We have also enabled Client IP & Protocol affinity in ALB but this does not seem to help, again the assumption is that each request that comes through get either a new private IP and or PORT.
We are using Azure Private Link and IP between these services to ensure our VNET has not internet facing IP and is not reachable without our VPN.
We have thought of other solution such as replacing the ALB with Azure Application Gateway because it is also layer 7, but this needs a public IP which we are trying to get away from.
Any ideas on how to get this right?
Question: How do I host an endpoint in azure which allows me to redirect internet traffic at will between azure and aws services?
I am hosting two kubernetes clusters - one in Azure and the other in AWS. I want to be able to:
1. redirect the traffic at will to either aws or azure, whilst retaining the public dns endpoint.
2. fail over manually [and pref automatically too] to the aws cluster. What is the best way to host the endpoint in azure?
Requirements:
The traffic needs to be redirected immediately - no caching issues and stale loads!
Ability to configure failover - i.e. specify that Azure is hot and AWS is the failover service - the traffic should be automatically redirected as soon as Azure goes down.
I have looked at Traffic Manager, Load Balancers and Application Gateway. Not sure which one (if any) of these is best.
traffic manager wont work for you, since its a dns service, so caching will happen (admittedly its the best solution if you set dns cache to 5 seconds or something). application gateway allows you to specify an ip address as an endpoint, load balancers only work when attached to vms inside azure. But application gateways dont allow to failover at will. you would need to block the probe to failover.
Azure Front Door might be the solution for you (like the other answer mentions)
You can have a look into Azure Front Door Service for your usecase.
Look into this https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-overview
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
I created an Azure Traffic manager and routing with Priority.As per this
The Traffic Manager profile contains a prioritized list of service
endpoints. 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
My Traffic Manager monitoring
Low Priority
High Priority
I tried to increase the priority and decrease the priority but there is no change.
Still, you can see that traffic manager pointing towards the teststatic site alone
Another question from the above doc
If the primary endpoint is not available
Here what is mean by not available? As I'm using Azure Web Apps for my testing purpose, So I thought When Stopping my webapp could be not available. But I'm wrong, Even though I stop the web app, still, the traffic manager pointing the stopped web app. So I'm confused about what is mean by not available here?
In your screenshots, the test endpoint monitor status is always a Degraded status. This indicated that the endpoint is not included in DNS reponses and does not receive traffic. So the Traffic Manager is still pointing towards the teststatic site alone. Traffic Manager considers an endpoint to be ONLINE only when the probe receives an HTTP 200 response back from the probe path If the monitoring protocol is HTTP or HTTPS. Any other non-200 response is a failure.
You need to troubleshoot degraded state on Azure Traffic Manager and see Traffic Manager shows monitor status is degraded – Resolution
what is mean by not available here?
The traffic manager chooses an endpoint based on the status of each endpoint (disabled endpoint are not returned), the current health of each endpoint and the chosen traffic-routing method. If the endpoint is not available, that is to say the endpoint is not included the DNS response or is an unhealthy endpoint. But an exception to this is if all endpoints are degraded, in which case all of them will be considered to be returned in the query response. You can get more details from endpoint monitor status.
An endpoint is unhealthy when any of the following events occur: A
non-200 response is received (including a different 2xx code, or a
301/302 redirect); Request for client authentication; Timeout (the
timeout threshold is 10 seconds; Unable to connect.
Besides, Type ipconfig /flushdns to flush the DNS resolver cache when you verity the Traffic Manager Settings.
I am trying to find a powershell command which helps find out a way that there is no open connections or any traffic is flowing to endpoint1 or confirm traffic is moving smoothly to endpoint2 after disabling endpoint1:
$e[0].EndpointStatus = "Disabled"
Set-AzureRmTrafficManagerEndpoint -TrafficManagerEndpoint $e
Is there a command to do this? I am not able to find anything in google or should I use some wait command to wait for like a minute to flush out all open connections?
*Basically looking for a way to make sure all in-flight connections are drained from one endpoint before disabling it.
Traffic does not flow through your Traffic Manager instance. Therefore, the functionality you are asking for from Traffic Manager does not exist. Traffic Manager simply resolves DNS queries to an IP address of one of your endpoints using the routing method (priority, weighted, performance, etc) you configured it for.
After disabling an endpoint, you could still see traffic going to the disabled endpoint for a period of time measured by your Traffic Manager profile DNS TTL setting. For example, if you disable an endpoint at 3:01:00 and your DNS TTL setting is 90 seconds, then you could see traffic until 3:02:30 because that's how long it could take for any client's DNS cache to expire. One way to monitor this is through the Queries by Endpoint Returned metric described here. This should work in most cases. However, it's not 100%. Just because you disabled an endpoint in Traffic Manager won't stop a client that know's the IP address of your endpoint from calling it. You can decide whether or not this scenario is likely for your application and clients. So, to be absolutely certain there are no active clients using the endpoint, you will need some monitoring in place at the endpoint.
Finally, if you gracefully stop your web app, virtual machine, or other service hosting the endpoint you want disabled, then any active requests to your application will complete before the service shuts down, assuming your application completes requests in a reasonable time (a few seconds).
Documentation on how to test and verify your Traffic Manager settings is available here.