I have a .NET Core application running on Azure AppService.
I have also a hosted service interacting with a table and updating it according to a given condition.
I am experiencing an increase of CPU usage of just one of the instances when my autoscaling rules kick in and start scaling out the AppService.
My question is if HostedService is automatically scaled-out too when new instances are warmed up by autoscaling.
Yes they are. When you scale out, you have multiple instances of the same application running.
I figured this out the hard way. I was running a hosted service that sent out reports through emails once a day. After I scaled out to 2 instances, clients started receiving the same email twice a day.
Related
I was wondering what would be the minimal recommended instance count for azure app service web app in production scenario ?
We currently have app services under Isolated app service plan with Autoscale rule in place (scaling up to 10 instances).
However the minimal instance count is currently set to 1.
I was wondering if this number shouldn't be higher (at least 2)? Can this impact SLA and apps availability somehow ?
If availability is a concern you should use 2 or 3 instance to minimize impact. Having just one instance can cause downtime. If you have a web app running on 1 instance the Azure Portal warns you with the following advice:
Distributing your web app across multiple instances
The webapp is currently configured to run on only one instance.
Since you have only one instance you can expect downtime because when the App Service platform is upgraded, the instance on which your web app is running will be upgraded. Therefore, your web app process will be restarted and will experience downtime.
Having 2 instances mitigates this, but can still cause downtime if one instance is not available due to a platform upgrade and one instance is not available due to a new deployment. 3 is best since in that regards.
Do note that if high availability is a must, then you need to also think multi-region. Think worst case scenario such as a natural disaster taking the one data center offline that you are using. It would be best to have something like Azure Traffic Manager (ATM) in front of two web apps (each with 3+ instances) and if ATM detects one of your web app regions is offline, it can reroute traffic to minimize downtime. Customer's who are running storefronts and the availability of their app is tied directly to their app being online will often take this approach.
(source)
I am using Azure App Service which hosts application that reads data from Event hub using EventProcessorHost. I have allocated 6 instances(Manual Scaling) to run. I checked the Metrics(CPU Time) in App Service and found only 5 instances are running.
I am getting different instances count for different metrics.
Data In metrics shows 6 instances while CPU Time metrics shows 5 instances. I am confused. Please suggest.
Regards,
Amit Agrawal
the AlwaysOn feature is used to keep your app loaded, particularly when it's not receiving any traffic.
However, I am aware of numerous instances of AppServices, across a number of Azure Regions, where the metrics were showing the instance count different to the number of instances deployed. This was since yesterday. I believe there have been underlying Azure issues.
In the Azure Portal, under the menu for your WebApp, you should be able to see the recent health of your WebApp within the 'Resource Health' section.
I would advise that you raise a ticket with Microsoft, just to be sure.
#azurefamily
I am using Azure App Service which hosts application that reads data from Event hub using EventProcessorHost. I have allocated 6 instances(Manual Scaling) to run. I checked the Metrics(CPU Time) in App Service and found only 5 instances are running.
I am getting different instances count for different metrics.
Data In metrics shows 6 instances while CPU Time metrics shows 5 instances. I am confused. Please suggest.
Regards,
Amit Agrawal
the AlwaysOn feature is used to keep your app loaded, particularly when it's not receiving any traffic.
However, I am aware of numerous instances of AppServices, across a number of Azure Regions, where the metrics were showing the instance count different to the number of instances deployed. This was since yesterday. I believe there have been underlying Azure issues.
In the Azure Portal, under the menu for your WebApp, you should be able to see the recent health of your WebApp within the 'Resource Health' section.
I would advise that you raise a ticket with Microsoft, just to be sure.
#azurefamily
My app deployed in Azure with basic tier having 10GB space. Now it showing the usage warning error in Server. So I want change the scale from basic to standard. Then which instance size should choose having ( Small-1 core, Medium-2cores and Large- 4 cores) ? Also while saving following notifications are showing
In Standard mode, if a web app is stopped, billing continues, and changing the scaling for an app affects other apps. Are you sure you want to continue?
This will scale the following web apps in the East US 2 region. This can take several minutes to complete. Your web apps will keep running during the process.
please help
To answer your question, here is a table with App Service sizes in which you can see that the Standard size has 50GB and the Premium has 500GB of disk space.
To answer your other questions:
The reality is that you pay for the App Service Plan, each plan can host dozens of Apps. Think of it as a Platform running all the time that hosts your Apps, if you stop one App, the Platform is still running (because you might have other Apps running on it), and thus, you are still charged for it.
Like I said, because what you pay is the App Service Plan, scaling the Plan will automatically scale all the Apps contained in it, that's the reason of the second message.
Think of the App Service Plan as a server in which you run your Apps, the moment you delete all the Apps in the Plan, the Plan stops billing, but as long as you have at least one App (running or stopped) in it, it will keep charging.
The company I work for is looking to develop a few apps against the cloud.
An ASP.NET Web Api application hosted in an Azure web role.
A Windows Server type application hosted in an Azure worker role.
We are completely new to web or cloud development and would like to know the following:
When being served to the consumer, is the same instance of the application being served to all, is it one per request or are multiple roles being created and served to consumers?
When being served to the consumer, is the same instance of the application being served to all?
That depends on how many instances you've asked Azure to run your application on. If you've only deployed to 1 instance, then it will of course be the same instance that responds to all requests. But if you deploy to multiple instances, requests will be load-balanced, which means you have no guarantee that multiple requests from the same user will be handled by the same instance.
When you're asking this question, it could be because you might be tempted to store local data on the machine running the instance. However, this is not a good idea. Windows Azure can at any time tear down your instance and start your application on a completely different machine. They call this "healing", because it usually happens because Windows Azure tries to be helpful and avoid any potential problem that could mean downtime for your instance. But it also happens if your machine for some reason locks up or something else bad happens. This process of healing means that anything that's not part of your deployment package will be lost. So for example, if you're logging to a file on the disk, this log will be lost if Azure "heals" your instance.
is it one per request or are multiple roles being created and served to consumers?
I'm not completely sure what you mean here, so I'll take a guess and risk interpreting your question wrongly. My guess is that you're asking if there will be one instance per user request. No, there will only be the number of instances that you have decided. Remember that you have to pay per instance that's running, so it's only fair that the number of instances running is dictated by you.
When you have your application packaged and ready to be deployed to Windows Azure, you can decide how many instances of each role you want to have running. You set this number in the deployment package, so that when your package is deployed, Azure will automatically start the requested number of instances. However, you can change the number of running instances of each role after deployment and on-the-fly. This makes it possible for you to scale with more instances within minutes.
I hope this helps and that I understood your questions correctly. :-)
Azure Web and Worker roles in an Azure Cloud Service are deployed on at least one instance (managed VM). Azure allows you to size (memory, CPU) and scale (number of instances). Azure actually lets you scale dynamically, i.e. add more instances on demand. You pay by the hour for the size & number of instances deployed.
For example, a Cloud service can have a single instance of a worker role (background processing) and multiple instances of the Web role. Multiple instances are handled behind a load balancer and the client is unaware of what instance they are using (all instances are created equal).
An Azure role instance is a VM with some specific payload.
For example, in your service you declare you want three instances of "Frontend" web role and two instances of "Backend" worker role. When Azure deploys your service it starts five VMs and three of them will run "Frontend" payload and have IIS started and two of them will run "Backend" payload and have no IIS started.
Now until you ask Azure to change that configuration it remains persistent no matter what requests come and what load occurs. You have five VMs with 3+2 configurations. To change the configuration you need some action on your part.
There're two way to have the configuration changed. You can use Management Portal or an external program to change the "instance count" in either or both roles. You can also add auto-scaling code that will gather metrics and make Management API requests to alter the "instance count". Either way when "instance count" goes up Azure starts more VMs with the same payload and when it goes down it stops some of the VMs.