Is there a way to exclude an AppService instance from the Load Balancer:
Via the portal?
Via the SDK?
Via the SDK would be ideal, then we could set the MakeVisibleToLoadBalance flag (if such a thing existed) once all initialization completed.
If it's only available via the portal, it would be good to set n seconds after an instance is loaded before it becomes visible to the load balancer.
Reason:
When we restart an instance (e.g. via advanced restart), the metrics show a significant increase in response times, every time.
I believe the cause is the load balancer thinks the machine is available but it really hasn't completed initialization, so requests that the load balancer sends to that instance are significantly delayed.
Another reason is we may observe an instance is performing poorly, it would be great if we could exclude that instance until either it recovered or was restarted.
//As per the discussion with wallismark in the 'comments'. Copied the helpful comments to answer.
To fix the 'reason'/scenarios you have mentioned above, you could leverage ApplicationInitialization method. Every time your application starts, this can be because of a new worker coming online (horizontal scaling) or even just a cold start caused by a new deployment, config change etc. The ApplicationInitialization will be executed to warm up the site before accepting requests on that worker.
So the Application Initialization Module, handy feature that allows you to warm your app prior to the application receiving requests to help avoid the cold-start or slow initial load times when the app is restarted. Please checkout - https://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/
- It has also been implemented for all other operations in which a new worker is provisioned (such as auto scale, manual scale or Azure fabric maintenance). But, you cannot exclude the instance from the load balancer.
If your requirement fits, you could leverage ARR affinity; in a multi-instance deployment, ensures that the client is routed to the same instance for the life of the session. You can set this option to Off for stateless applications.
Typically, the Scale-out (trigger) -multiple running copies of your WebApps and handle the load balancing configurations necessary to distribute incoming requests across all instances. When you have more than one instance a request made to your WebApp can go to any of them using a load-balancer that will decide which instance to route the request based on how busy each instance is at the time.
To share more information on this feature - On load-balancer is that once a request from your browser is made to the site, it will add a ARRAffinity cookie to it (with the response) containing the specific instance id that will make the next request from this browser go to the same instance. You can use this feature to send a request to a specific instance of our site. You can find the setting in the App Service's Application Settings:
When multiple apps are run in the same App Service plan, each scaled-out instance runs all the apps in the plan.
Related
Health Check can restart an instance. Auto-Heal also can restart an instance.
So, when should I use Health Check and when should I use Auto-Heal. Should I use them both together?
The Health Check feature is pretty basic compared to Auto-Heal. Basically it makes a request to a predefined url and if it does not get a succesful response it will take that instance out of the load balancer pool. If it remain unhealthy it will be replaces with a new instance. It works only if scale-out is applied to the web app.
Auto-Heal is much more sophisticated: instead of pinging a url it can be configured to restart an instance when a certain memory or cpu usage limit is reached, or when the response time is degraded during a certain period.
I have one Azure App Service in which I have created 5 instances using App Service Plan
Scale Out option. Now I am not sure how does Azure load balances requests between this instances? I am not seeing any load balancer for it.
Also how can I know that which request is being served by which instance?
The load balancer is created automatically and you can't see it.
Basically it sends the requests to instances at random, though it can be made "sticky" with ARR Affinity.
You can find the setting in the App Service's Application Settings:
If it is on, the load balancer will attach a cookie to responses if they don't already have it.
It makes it so that future requests hit the same instance.
Though of course if the instance is no longer there (because of auto-scale for example), then it will again go to a random instance.
The WEBSITE_INSTANCE_ID environment variable can tell you in the back-end which instance is handling the request.
You can find a list of available variables here: https://github.com/projectkudu/kudu/wiki/Azure-runtime-environment
We deployed a Node.js Azure Web App and defined a minimum of 2 instances (for scalability and high-availability).
It seems like the LB is balancing the load between the instances, but it doesn't react on instance error (crash) and seems to insist balancing the load between all the instances including the one which crashed.
Is there a way to set a fail-over mechanism for high-availability?
The load balancer used by Azure App Service will continue to send requests to individual web servers as long as the underlying virtual machines are up and running.
To workaround the issue you are running into, you can try configuring the "auto-heal" feature. If the scenario is that the app gets "stuck" in a permanently broken state, auto-heal rules can be configured to automatically restart the app.
More details on auto-heal here:
Auto-heal for Azure Web Sites
If I deploy a web app (formerly known as an Azure WebSite) to an App Hosting Plan in Azure with a couple of instances (scale = 2) will the load balancer in front of the instances care if any of the instances is unhealthy?
I'm troubleshooting an issue that sometimes causes my site to return an http 503 ~50% of the time. My thinking here is that one of two of my instances has failed but the load balancer hasn't noticed.
If the load balancer does care, what does it look for? I can't find anyway to specify a ping url, for instance.
Note: this question has nothing to do with Traffic Manager.
Yes, Azure Web Apps monitors the health of the workers by making internal requests to it and verifying that they're healthy.
However, we don't check status codes that the web app returns to user requests (like 500, etc) since that could easily be an app specific issue rather than a problem with the machine.
So the answer you're looking for is: We continuously test whether or not the instances (VMs) are healthy and take them down if they're not. However, those tests do not rely on error codes the customer's site returns
I am trying to scale a web app on Azure from a single web instance to multiple instances. The web app does a fair amount of processing of per-user state, it's also fairly interactive so latency is important. We currently have a single database, testing has shown it is not the bottleneck so for this question let's assume we don't have to worry about scaling it, all instances will hit the same database. In this case, I think per-user load balancing is the best option, as per-request will result in per-user state being duplicated in lots of web instances. Apart from the issue of maintaining consistency, I am concerned this would result in unacceptable latency for end users.
This link says that ARR does per-user load balancing by default on Azure. However, the Traffic Manager, which from what I can gather is automatically enabled when you spin up multiple web instances on Azure, does per-request load balancing.
So my question is, which of these two load balancing schemes will I be using if I add a few more instances to my Web Hosting Plan? If I need to manually disable the Traffic Manager, what is the best way to do this?
Calum - you can leverage the standard SQL Session State Provider in Azure or you could look at the Azure Redis Cache provider as well for backing stores for user session state.
When deploying to Cloud Service Web Roles you automatically get a load balancer instance in front of your hosts. It's relatively transparent other than configuration of Endpoints. Each newly added/removed auto-scaled instance gets added to the Cloud Service and is automatically added/removed to the load balancer.
As others have said, Azure Traffic Manager provides a higher level service which can direct traffic to multiple Azure Regions (data centers) and even on-premises endpoints.
A good overview of Load Balancing can be found here: http://azure.microsoft.com/blog/2014/04/08/microsoft-azure-load-balancing-services/