- Scalability and availability for Azure Web Apps - Wed, Jun 28 2017
- Managing Azure Virtual Machine scale sets - Wed, May 31 2017
- Azure virtual machine scale sets - Mon, May 8 2017
Once you design your highly available application, the next step should be to consider scalability options. An auto-scaled cloud infrastructure will be able to add and remove identical virtual machine (VM) instances in response to demand changes.
Azure allows your application to scale both up and out to handle changing demand. You can increase the power of VM instances by scaling up (vertically), or you can simply add additional instances by scaling out (horizontally).
As your website or application grows, you need to consider either of these scaling methods to handle increased traffic. From a management perspective, scaling out is quite a straightforward process. Most of the time, it is also a more cost-effective option compared to scaling up.
Virtual Machine Scale Sets is a feature of Azure you can use to deploy identical VMs manually or automatically. For instance, you can start with just two VMs to host your web application. By using Scale Sets and the auto-scale feature, your infrastructure can dynamically adapt to changes in demand. Azure will maintain application performance by launching more VMs during demand spikes. It will also remove unused instances when demand is low again to lower your computing costs.
Settings in the Azure portal allow you to set maximum and minimum instance counts and CPU thresholds for the auto-scale feature to work.
Scale Set scope
We also need to have some important architectural discussions when it comes to your application design. To use the auto-scale feature, you need to configure identical VMs. Therefore, it's better to design your application to support horizontal scaling. This requires some key architectural decisions such as making your tiers (especially web and app ones) stateless so that they will store no static data. Every identical VM in the pool should be able to serve the same content to the end user. Therefore, you can add a virtually unlimited number of identical VMs without worrying about persistent data.
In some cases, you may need to think about storing session data on the application VMs, for instance in a shopping basket scenario. For this, you have to think about designing a separate persistent tier just to store session information in a database. (NoSQL would be a good option here for performance considerations.) The whole point is to make your tiers as stateless as possible for an easy auto-scale process. are important points I will discuss in another post.
Today, we are going to look at how to create Azure Virtual Machine Scale Sets using different methods and also explore some important configuration steps.
Creating virtual machine scale sets
There are multiple ways to create virtual machine scale sets (VMSS). You can use the new Azure Portal, Azure CLI, Azure PowerShell, as well as Resource Manager templates. I will show you some of these options below.
You can use the new Azure Portal to create VMSS configurations. Just search for scale sets and click "Virtual machine scale sets."
Creating scale sets in Azure Portal
The next screen is important for configuring the general settings of identical VMs.
Scale set basic settings
The user name and password you provide will apply to all the VMs within this VMSS.
By default, you can have a maximum of 100 VMs running for each VMSS. If you would like to scale out to more than 100 VMs (up to a maximum of 1000), you need to configure your placement group limit setting. We call this configuration a "large scale set." Common use cases for large scale sets are big data deployments or distributed computing scenarios where you need simple management of a large pool of worker nodes. By using a single large scale set, you can have tremendous computing power with a basic deployment action.
For this scenario, you need to configure the Limit to a single placement group setting. If this setting is False, the scale set will span across multiple placement groups and has a range of 0–1000 VMs. The default setting is True, which limits the maximum VMs to 100.
It is important to note that before deciding whether to use large scale sets, you need to consider the requirements below:
- Large scale sets are designed to work with Azure Managed Disks. If you use this configuration, you won't be able to choose traditional disks on the next page.
- Using your own custom VM images will limit you to 100 VMs again.
- From a load-balancing point of view, your only choice is the Azure Application Gateway, which is a Layer 7 load balancer. The default Azure Load Balancer does not yet support this feature.
- You need to plan your subnet accordingly. A scale set uses a single subnet, so you need to make sure you have a large enough address space to support a large number of VMs.
On the next screen, you need to request a public IP address and specify a globally unique domain name label. Your load balancer will put this in front of the scale set.
Scale set VM and auto scale settings
You also need to choose an operating system image, which will be the base image for each identical VM in this VMSS.
You can decide to use either a managed disk or an unmanaged disk. As I mentioned before, if you would like to span across multiple placement groups to support more than 100 VMs, you need to use the managed disk type.
And the last setting is quite important when it comes to automating scale processes. Basically, you need to specify a minimum and a maximum number of VMs in this VMSS. As per the CPU threshold you defined, Azure will place VMs within this range. For the example above, I would like to start with three VM instances for my web application.
If the average CPU percentage is lower than 25%, Azure will remove one VM from the pool. I also would like to make sure the minimum VM count for my application is two to provide basic high availability.
If the CPU threshold is higher than 75%, Azure will add an additional VM to the scale set up to a maximum of ten VMs.
The beauty of the elasticity in cloud environments is that Azure takes care of scalability on your behalf. By configuring the auto-scale feature, you are actually using the performance and cost-optimization benefits of cloud technologies at the same time.
Once you initiate the deployment, Azure will create three identical VMs using the configuration you specified and will then start to monitor CPU metrics for auto-scaling in or out.
You can also deploy the configuration above using Azure Resource Manager (ARM) templates so that you can redeploy the same configuration. The Azure Quickstart Templates repository is a great place to start. Here you can find a bunch of different ARM templates for various scenarios. You can easily start with the 201-vmss-win-app-ssl template to deploy two Windows VMSSs, configure Windows features like IIS or the .NET Framework, and download application deployment packages automatically.
Whether you use an existing template or develop your own ARM template, you can easily deploy them using the PowerShell command below:
New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroupName ‑TemplateFile $templateFilePath -TemplateParameterFile $parametersFilePath
Another easy way to begin deploying VMSSs for Windows and Linux machines is to use Visual Studio (VS) prebuilt templates.
Creating an Azure Resource Manager project in Visual Studio
You can select Azure Templates within the Visual Studio New Project wizard.
Creating VMSS templates in Visual Studio
This simply creates a predefined ARM template and parameter JSON files that you can edit or start deploying right away.
VMSS ARM Template in Visual Studio
It is important to be aware of the auto-scale settings in ARM templates. Some ARM templates don't have the auto-scale setting configured. In such cases you cannot use the auto-scale feature for your application without configuring the setting.
To configure auto-scaling in ARM templates, you can simply use the Microsoft.Insights/autoscaleSettings resource. Below is a sample section you can use to configure the auto-scale feature and respective CPU thresholds for our scenario.
{
"type": "Microsoft.Insights/autoscaleSettings",
"apiVersion": "2015-04-01",
"name": "[concat(parameters('resourcePrefix'),'as1')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachineScaleSets/',parameters('vmSSName'))]"
],
"properties": {
"enabled": true,
"name": "[concat(parameters('resourcePrefix'),'as1')]",
"profiles": [
{
"name": "Profile1",
"capacity": {
"minimum": "1",
"maximum": "10",
"default": "3"
},
"rules": [
{
"metricTrigger": {
"metricName": "\\Processor(_Total)\\% Processor Time",
"metricNamespace": "",
"metricResourceUri": "[concat('/subscriptions/',subscription().subscriptionId,'/resourceGroups/',resourceGroup().name,'/providers/Microsoft.Compute/virtualMachineScaleSets/',parameters('vmSSName'))]",
"timeGrain": "PT1M",
"statistic": "Average",
"timeWindow": "PT5M",
"timeAggregation": "Average",
"operator": "GreaterThan",
"threshold": 75.0
},
"scaleAction": {
"direction": "Increase",
"type": "ChangeCount",
"value": "1",
"cooldown": "PT5M"
}
}
]
}
],
"targetResourceUri": "[concat('/subscriptions/',subscription().subscriptionId,'/resourceGroups/', resourceGroup().name,'/providers/Microsoft.Compute/virtualMachineScaleSets/',parameters('vmSSName'))]"
}
}
The ARM section above helps you use the Processor(_Total)\% Processor Time counter to measure processor usage in VMs and scale out if the usage is higher than 75%, up to a maximum of ten VMs. We configured this same setting in the Azure Portal.
Once you are done with your template, you can simply right-click your project in VS and choose Deploy. Here you can define parameters you specified in the parameter.json file.
Subscribe to 4sysops newsletter!
Deploying a VMSS ARM template in Visual Studio
Wrap-up
When it comes to managing virtual machines in a VMSS, there are some important differences compared to traditional VM management. In my next post, I'll illustrate these differences with some real-life use cases.
