Have a several IaaS VM running under an internal load balancer in Azure, for scaling, is it possible to set an initial instance count rather than starting from the minimum count. Thanks
This isn't quite as easy as "set it in the portal", but it should still be relatively easy. If you go to one of the VMSS templates in the Azure Quickstart Templates repo (e.g. https://github.com/Azure/azure-quickstart-templates/tree/master/201-vmss-windows-nat), and click on "Deploy To Azure", it will take you to portal and allow you to deploy with the parameters you want from the UI. One caveat is that you won't be able to change the size from portal though.
Hope this helps :)
Actually, thinking about this a bit more, you might be able to change the size from the UI once it's been created. If you deploy the VMSS, then at a later point in time click on the "Deploy To Azure" button again, it will take you to the portal again. If you deploy with the exact same parameters but just change the capacity, it might scale the VMSS to the number of VMs you desire (theoretically, deployments are supposed to only deploy the parts of infrastructure that haven't already been deployed, but I haven't tested it with this particular template, so it's possible that something breaks).
If you are using the classic auto-scaling option that has been available for a while now, you should take a look at the templates and Azure Scale Sets functionality - https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-vmss-walkthrough/ It appears to allow to you provide a starting instance count.
Related
I have 4 VMs in azure and I am trying to set up a schedule to lower the RAMs and CPU cores for after-hours and revert them back to their original size during business hours.
can someone guide me through the steps or share a how-to resource, please? I can't find any documents and I am sure my search key is not correct.
Thanks
As suggested by #harshavmb, you can make use of VMSS.
In Azure, Auto-Scaling is possible if you make use of Virtual Machine Scale-Sets.
Virtual Machine Scale-Sets allows you to automatically scale as resource demand changes.
Based on schedules, you can create auto scale rules.
These schedule-based rules allow you to automatically scale the number of VM resources at fixed times.
To create the Auto-Scale rule, you can make use of following tools:
Azure PowerShell
Azure CLI
Azure template
Otherwise, you can create an automation account in Azure and execute runbooks as mentioned in below link if helpful:
Automatically Resize an Azure VM - Automation account
i am a newbie and am planning to host iis server for my client in azure with auto-scale functionality.
we will test modules and update once in a week in iis server, my question is how to sync the files between vms while on auto-scaling and if we can use auto-scale only for identicals vms, then please suggest me the solution for this scenario. we will start min 2 max 10 vms in auto-scale.
Regards,
Kumar B
I first would ask why a VM, things do get more complicated using VMs. Scale Set would help support this however you still will have issues when you want to deploy new code. You said IIS so I am presuming Windows. Desired State Configuration is a great choice you can make a PowerShell script that will "configure" your VM for you, and potentially pull in any code updates. This is also where things like chef/puppet/salt can come into play to ensure the server is configured.
You could look at creating a custom image that every time you deploy new code gets baked into the image. Then you are basically doing a rolling update where you spin up a new server and then destroy one until they all have been updated. Technically this could be done, either way, just if they are baked into the image you would have a quicker start time.
https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
https://adamtheautomator.com/azure-vm-scale-sets-powershell/
Automatic - VMs may be rebooted in a random order even taking all VMs temporarily down at the same time.
Rolling - The scale set deploys updates to instances in batches with an optional pause time between batches.
Manual - Nothing happens to existing VMs when an update is initiated.
What files are you trying to sync if they are not code files, Azure Files would be a great fit as that supports SMB or you could just use cloud storage.
You can deploy your application to a virtual machine scale set using desired state configuration. See: https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-deploy-app
Not what you asked, but you should consider why you are hosting your app in IIS on VMs. If you are using Azure, then Azure App Service may be a better fit. See: https://learn.microsoft.com/en-us/azure/app-service/
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.
We have written a high scalable Cloudservice for MS Azure with two roles: "WebsiteRole" and "WebsiteWorkerRole". For better performance we deploy this Cloudservice in multiple regions (2x US, 2x EU, 1x JP). We have different configuration files for each region (EuWestProductive.azurePubxml, ServiceConfiguration.CloudEuWest.cscfg, Web.ReleaseEuWest.config).
Now the Problem: In each Region we have running the "WebsiteRole" and "WebsiteWorkerRole". But the "WebsiteWorkerRole" has only very small tasks, so that one extra small instance in one region is more than enough.
We tried to set the Role instance count to zero (ServiceConfiguration.CloudEuWest.cscfg). But this is not allowed:
Azure Feedback: Allow a Role instance count of 0
Is there an other way to remove a role when deploy the Cloudservice?
No, as you've discovered, a cloud service does not allow for scale to zero. You have to effectively remove the deployment. To have the minimum change to what you already have in place you could separate the two roles into two different deployments. Then have an Azure Automation Script, or set of scripts run elsewhere, that handles deploying the worker role when needed and decommissioning when it's not needed.
Depending on the type of workload that worker is doing you could also look at taking another route of using something like Azure Automation to perform the work. This is especially true if it's a small amount of processing that occurs only a few times a day. You're charged by the minute for the automation script, so just make sure it's going to run less than the actual current instance does.
It really boils down to what that worker is doing, how much processing it really needs to do, how much resources it needs and how often it needs to be running. There are a lot of options, such as Azure Automation, another thread on the web role, a separate cloud service deployment, etc. Each with their own pros and cons. One option might even to look at the new Azure Functions they just announced (in preview and charged by the execution).
The short answer is separate the worker from the WebSiteRole deployment, then decide the best hosting mechanism for that worker role making sure that the option includes the ability to only run when you need it to.
Thanks #MikeWo, your idea to separate the deployments was great!
I have verified this with an small example project and it works just fine. Now it is also possible to change the VM size and other configurations per region.
(Comments do not allow images)
It is possible to delete azure app hosting plan to stop being charged, but I am wondering if it's possible to disable it somehow. If you delete it, then you lose configuration, etc. But I did not find any options to kind of turn it off, and then put it back online (I suppose it's possible with virtual machines e.g.), or reduce the instance count to 0 somehow. Did someone find a way to do it?
P.S. Sometimes it's possible to switch to free plan, but e.g. it won't work when you have deployment slots, etc.
The only way to 'turn off' an Azure App Hosting Plan is to delete it! While it is up and running you will be charged.
The best solution you've got is to shrink it down to a single small server. The price for that is reasonably low.
The alternative is to automate the whole thing, If you keep the sites you host in Github etc you can create a hosting plan and deploy deployment slots etc from a script. You can host the scripts in Azure Automation, and it becomes a few minutes to redeploy your site. Although this does take a little time to create.