I have a web app hosted in app service in Azure with auto scale out rules defined and it works as expected - when the memory usage reaches the threshold. An VM instance is added automatically
The problem is that, we discovered that when a new VM instance is added, a new instance of our web app is also added - we do not want this, as our web app is not designed to be horizontally scaled out. We only want one instance of the app.
On Azure portal when I click on Scale up (App service plan), I can only choose another app service plan, it seems to me there is no way I can do something like when a threshold is reached, automatically scale up to the next level of app service plan but keep the number of VM instance.
I am wondering why there is no such option available in Azure?
Or even our conclusion that when scale out, the number of web app instance also increases is true?
You're right, there's no automatic way to scale up and when you scale out, the number of web app instance also increases.
Yes, there is no out of the box option for this and that could be because there is a chance to have latency issues during the scale up / down operation and Azure might want the consumer to make this decision consciously. Having said that, I use the below approach to achieve the vertical scaling you are looking for.
Step 1: Create an Automation account
Step 2: Create a PowerShell Runbook in the automation account you created in previous step. This script would scale up your app service
plan
Step 3: Create an alert rule using the Azure Monitor for your criteria. say, alert
to be fired when Memory usage % is more that 40% or CPU utilization more than 5%)
Step 4: Create an action group that will invoke a runbook you created in
Step #2
Step 5: Associate this action group to the alert you have created in Step #3.
This will do what you are looking for. when the memory utilization is over 40% the alert is triggered which in turn will call you runbook to scale up your app service plan.
You can refer to my article here for detailed description of how to create an automation account and also for the PowerShell script to scale up an app service plan
Related
I have function app which process XML files from Azure blob and put the data in Azure SQL DB. This is working fine when the Size of the file is in kb ( we have told the sender to send the file up to 100kb).
The problem comes when the file size increases to “2MB to 3MB”. The problem is it gets stuck in middle of processing and as the job runs in every 2hours, the blob receives files in every 2 hours - then everything stuck ( the current processing files and the new files as well )
I can’t change the schedule from 2hours to more. considering this, Is there anyway to scale up or scale out the app service plan so that it can process the larger size in 2hours time? Will there be a code or configuration change required for this ? Also, if yes, what is the costing plan for this?
Or, is there any other way to handle such situations?
Please note, the current app service plan is S2:2 and all deployment slots are in same app service plan.
Thank you Roman Kiss and Anupam Chand. Posting your suggestions as answer to help other community members.
The hosting plan you choose dictates the following behaviors:
How your function app is scaled.
The resources available to each function app instance.
Support for advanced functionality, such as Azure Virtual Network connectivity.
Check Hosting Options for further information.
Here is the pricing calculator for moving P1V2 to P1V3.
Below image will help you in scaling up your app service
If you app depends on other services like SQL and Storage you need to Scale up these resources separately.
In the Resource Group link go to summary and select the resource to scale up.
For further information click Scale up in Azure App Service.
Very similar to (but not a duplicate of!) this question: Limit number of instances of an azure webjob when scaling out
I would like to be able to limit the number of instances of a webjob within our standard webapp. I am aware of the possibility of having a singleton instance but would like to be able to limit this to a number other than 1.
Is such a thing possible? If not, are there any sensbile workarounds for the type of scenario described in q. 45067648 for those of us running on the Standard App Service?
Footnote on why this isn't a duplicate of q. 45067648:
I asked the previous question without considering that there could be a different answer depending on whether the app service was running on a premium or standard SKU. The answer Amor gave would be an ideal answer for those running on the premium SKU but is unsuitable for those running the standard SKU. I considered amending the original question but, after advice on meta (here and here), discovered this is best posed as a new question
limit the number of instances of a webjob within our standard webapp.
Under "Create a continuously running WebJob" section in the article, you can see: "If your web app runs on more than one instance, a continuously running WebJob will run on all of your instances". And it enables us to make continuous WebJob to run on only one instance.
To limit the number of instances that continuous WebJob run on, Amor has gave you a workaround in this thread: using Per app scaling feature (available only for Premium SKU App Service plans). If you do not want to scale your Standard SKU App Service plan to Premium SKU App Service plan, you can create another new Standard SKU App Service plan with specific number of instance that you want to run your WebJob, in this way, your WebJob will not cause resource contention with other web apps.
Besides, you can give a feedback on Azure UserVoice.
I have an Azure function to call the SpeechToText cognitive server. I need to ensure that no more than 4 instances of the function spin up. Is there any way to set the degree of parallelism?
You could try modifying the app's service plan: https://learn.microsoft.com/en-us/azure/app-service/azure-web-sites-web-hosting-plans-in-depth-overview
Navigate to the function app that you want to update.
In the Menu, look for the App Service Plan section.
Select Change App Service plan to start the process.
Navigate to scale out.
Enable autoscale.
Set the desired instance limits.
I have one Resource Group. In it:
I have two Web Applications (A and B).
I have two Application Service Plans (PlanA and PlanB).
Each Web Application is alone in its Application Service plan. (A in PlanA, B in PlanB)
Both A and B consume between 1 and 9 GB of disk space each.
When I set both PlanA and PlanB to level B1, both A and B run fine.
When I stop the service for B, A continues to run fine, and B is shut down.
When I scale PlanB down to the Free level (and thus exceed its quota), B does not run.
However - Web App A (which is running in Service Plan PlanA) throws out of disk errors. These errors go away when I change PlanB back to B1. I thought the whole idea of Application Service Plans was to separate resource consumption between groups of applications. What am I missing here?
I thought the whole idea of Application Service Plans was to separate resource consumption between groups of applications.
Firstly, the resource group is just a container that holds related resources for an Azure solution. It is used to easily manage your resources and deploy. The service plan in the resource group will not affect another service plan.
Secondly, the service plan will not affect another service plan. Each service plan use its own physical server resources.
Besides, an app in App Service can be associated with only one App Service plan at any given time.
So the plan B will not affect the plan A.
I guess there maybe another reason causes the plan A web app show disk error.
I suggest you could firstly check the quota of your web app to make sure there are enough disk space to run your wen app. More details about how to check it, you could refer to this article.
If the service plan has enough disk and still show this error. I suggest you could try to scale up the service plan A then scale down.
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.