I was reading about ARR affinity in Azure and saw that stateful apps should have ARR affinity enabled:
I assume this is so the same VM is used for future requests for that client.
But is it even possible to store state on VM?
I thought we don't have access to those low level details in our app service.
What would be an example of a stateful app in Azure where you'd be able to store state on the VM?
A Stateful service when it make use of some existing data, it means service has a memory. Its output is not 100% the function of an input. In order to function, the service needs to retain and access some set of stored information over some period of time.
Azure App Service enables you to easily create enterprise-ready web and mobile apps for any platform or device and deploy them on a scalable cloud infrastructure.
Suggest you to refer below articles for detail understanding.
Common web application architectures
Scalable web application
What is ARR affinity:
ARR identifies the user by assigning them a special cookie (called as an affinity cookie), which allows the service to choose the right instance the user was using to serve subsequent requests made by that user. Which means if we have the ARR Affinity enabled, a client is tied to a specific web worker until the session finishes.
Azure WebApps by default have ARR Affinity cookie enabled, this cookie pairs a client request to a specific server. However, Azure Web Apps is a stateless platform and, in an environment, where we are scaling the Website across multiple instances, the ARR Affinity cookie will be bound to a specific server. It’s advisable to avoid the use ARR cookies in a scaled environment where we have multiple instances that serve our application requests.
Disabling ARR cookies is a sustainable resolution for issues related to ARR Affinity cookies in scaled environments, where these cookies rely on the relationship with the worker machine they are paired with.
Also, this is good for legacy application compatibility as they may not have been designed with load balancing in mind.
But if your app has been designed for load balancing (i.e. your app is stateless, session state stored elsewhere), you should disable this.
Related
I have an Asp.Net MVC big e-learning site app that is hosted on azure(app service) with 10 instances.
We disabled ARR Affinity to improve performance and enabled traffic manager also.
Now I want to clear cache in every instance so how can I make a request for a specific instance? or is there any way we can clear cache using some receiver/messaging system?
If I enable ARR Affinity then I can make a request using a cookie.
I a host web application on Azure. I have a basic plan where only one instance works. After I've published my app into cloud, I've noticed an automatically generated cookie called ARRAffinity. So even with single instance of hosted web application there will be always generated ARRAffinity cookie? Is that right? Or it doesn't matter how many instances are around and the Azure web application always generates the cookie?
It's always there by default.
There are ways to Disable Session affinity cookie (ARR cookie) for Azure web apps
Here's an explanation: Azure: ARRAffinity makes affinity cookies!
Affinity Cookies are used to aid people who need to stay with a certain instance of web app or web site in Azure. The reason for this is that we strive for statelessness, but do not always achieve it. This means that the user must stay on the particular instance that they using till they break state and then things are saved at that time.
This can be disabled without adding the Arr-Disable-Session-Affinity header that was mentioned in the blog post in the other answer. Azure has an option to turn this off under Settings > Configuration > General Settings > Platform settings.
How can I maintain users to get redirected to the same Server in a Load-Balanced Web Apps
Your answer will be very helpful
Traffic Manager directs the user to the appropriate region, but assuming you have your web app scaled out to at least two instances, ARR (Application Request Routing) is what directs each request to a specific instance of the app.
ARR has a feature called Session Affinity which is enabled by default. It uses an ARRAffinity cookie to attempt to route all requests from a client to the same instance of your application. I say "attempt" because, the cloud being what it is, instances of your app can come and go due to autoscaling or maintenance activities.
Your best bet is to use Azure Traffic manager. When setup correctly it will route users to the proper cloud service in their region and provide them with the best possible experience.
More information can be found here
Azure Traffic Manager
Azure Traffic Manager Documentation
Traffic Routing Methods
If Azure App Service plans are virtual machines dedicated to the Web, API, Logic, and Mobile apps defined within them, does that mean that a web app in an app service plan is an instance of a virtual web server in IIS on that virtual machine?
Assuming this is the case and that each virtual web site gets it's own application pool, is there an Azure scaling strategy or scenario where more than one worker process in that app pool will run, creating a web garden? My understanding of web app scale out is that it results in additional VMs being allocated and not additional worker processes.
The scaling strategy will depend upon the pricing tier you have opted for.
Basically each Service Plan will contain a collection of Web, API, Logic, Mobile apps. These will form a web garden within the Service Plan server you choose.
If you initially choose a single B1 Basic Service Plan, you will get a single virtual machine with all of your applications running on that. As the load on that server increases, you can scale it up to larger servers, but it will still be running on a single server.
If you then choose to create a second instance (and a 3rd, 4th, 5th...) that second server will be a replica of the first server, with the load being balanced between the two. (3,4...)
While I've not seen documentation for this, I would imagine that each Web, API, etc app is run under its own application pool / worker process, and scale out is simply duplicated instances.
I'm not sure what a Virtual Server is, but each app runs in its own dedicated application pool and w3wp.exe process. There is only a single w3wp.exe process per application pool, so no web gardens.
Is there a specific reason you think you need these to scale your apps? In most cases, using web gardens is the wrong way to scale, as adding more processes can cause unnecessary overhead (amongst other problems - you can find some useful resources on the web). You almost always want to prefer threads over processes for improving concurrency. If you're running out of physical resources (CPU, memory, etc), then the correct way to scale is to add additional VMs.
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/