Skill 1.3: Scale ARM VMs

Similar to Azure Web Apps, Azure Virtual Machines provides the capability to scale in terms of both instance size and instance count and supports auto-scale on the instance count. However, unlike Websites that can automatically provision new instances as a part of scale out, Virtual Machines on their own must be pre-provisioned in order for auto-scale to turn instances on or off during a scaling operation. To achieve scale-out without having to perform any pre-provisioning of VM resources, Virtual Machine Scale Sets should be deployed.

 

This skill covers how to:

 Scale up and scale down VM sizes

 Deploy ARM VM Scale Sets (VMSS)

 Configure auto-scale on ARM VM Scale Sets

 

Scale up and scale down VM sizes

Using the portal or Windows PowerShell, you can scale VM sizes up or down to alter the capacity of the VM, which collectively adjusts:

 The number of data disks that can be attached and the total IOPS capacity

 The size of the local temp disk

 The number of CPU cores

 The amount of RAM memory available

 The network performance

 The quantity of network interface cards (NICs) supported

 

More Info: Limits by VM Size

To view the detailed listing of limits by VM size, see https://docs.microsoft.com/azure/virtual-machines/windows/sizes.

 

Scaling up and scaling down VM size using the Portal

To scale a VM up or down in the portal, complete these steps:

1. Navigate to the blade of your VM in the portal accessed via https://portal.azure.com.

2. From the menu, select Size.

3. On the Choose a size blade, select the new size you would like for the VM.

4. Choose Select to apply the new size.

Scaling up and scaling down VM size using Windows PowerShell

The instance size can also be adjusted using the following Windows PowerShell script:

Click here to view code image

$ResourceGroupName = "examref"
$VMName = "vmname"
$NewVMSize = "Standard_A5"
$vm = Get-AzureRmVM -ResourceGroupName $ResourceGroupName -Name $VMName
$vm.HardwareProfile.vmSize = $NewVMSize
Update-AzureRmVM -ResourceGroupName $ResourceGroupName -VM $vm

In the previous script, you specify the name of the Resource Group containing your VM, the name of the VM you want to scale, and the label of the size (for example, “Standard_A5”) to which you want to scale it.

You can get the list of VM sizes available in each Azure region by running the following PowerShell (supplying the Location value desired):

Click here to view code image

Get-AzureRmVmSize -Location "East US" | Sort-Object Name |
ft Name, NumberOfCores, MemoryInMB, MaxDataDiskCount -AutoSize

Deploy ARM VM Scale Sets (VMSS)

Virtual Machine Scale Sets enable you to automate the scaling process. During a scale-out event, a VM Scale Set deploys additional, identical copies of ARM VMs. During a scale-in it simply removes deployed instances. No VM in the Scale Set is allowed to have any unique configuration, and can contain only one size and tier of VM, in other words each VM in the Scale Set will also have the same size and tier as all the others in the Scale Set.

VM Scale Sets support VMs running either Windows or Linux. A great way to understand Scale Sets is to compare them to the features of standalone Virtual Machines:

 In a Scale Set, each Virtual Machine must be identical to the other, as opposed to stand alone Virtual Machines where you can customize each VM individually.

 You adjust the capacity of Scale Set simply by adjusting the capacity property, and this in turn deploys more VMs in parallel. In contrast, scaling out stand alone VMs would mean writing a script to orchestrate the deployment of many individual VMs.

 Scale Sets support overprovisioning during a scale out event, meaning that the Scale Set will actually deploy more VMs than you asked for, and then when the requested number of VMs are successfully provisioned the extra VMs are deleted (you are not charged for the extra VMs and they do not count against your quota limits). This approach improves the provisioning success rate and reduces deployment time. For standalone VMs, this adds extra requirements and complexity to any script orchestrating the deployment. Moreover, you would be charged for the extra standalone VM’s and they would count against your quota limits.

 Scale Set can roll out upgrades using an upgrade policy across the VMs in your Scale Set. With standalone VMs you would have to orchestrate this update process yourself.

 Azure Autoscale can be used to automatically scale a Scale Set, but cannot be used against standalone VMs.

 The Networking of Scale Sets is similar to standalone VMs deployed in a Virtual Network. Scale Sets deploy the VMs they manage into a single subnet of a Virtual Network. To access any particular Scale Set VM you either use an Azure Load Balancer with NAT rules (e.g. where each external port can map to a Scale Set instance VM) or you deploy a publicly accessible “jumpbox” VM in the same Virtual Network subnet as the Scale Set VMs, and access the Scale Set VMs via the jumpbox (to which you are either RDP or SSH connected).

The maximum number of VMs to which a VM Scale Set can scale, referred to as the capacity, depends on three factors:

 Support for multiple placement groups

 The use of managed disks

 If the VM’s use an image from the Marketplace or are created from a user supplied image

Placement groups are a Scale Set specific concept that is similar to Availability Sets, where a Placement group is implicitly an Availability Set with five fault domains and five update domains, and supports up to 100 VM’s. When you deploy a Scale Set you can restrict to only allow a single placement group, which will effectively limit your Scale Set capacity to 100 VM’s. However, if you allow multiple placement groups during deployment, then your Scale Set may support up to 1,000 VM’s, depending on the other two factors (managed disks and image source).

During Scale Set deployment, you can also choose whether to use unmanaged (for example, the traditional disks in an Azure Storage Account you control) or managed disks (where the disk itself is the resource you manage, and the Storage Account is no longer a concern of yours). If you choose unmanaged storage, you will also need to be limited to using a single placement group, and therefore the capacity of your Scale Set limited to 100 VMs. However, if you opt to use managed disks then your Scale Set may support up to 1,000 VMs subject only to our last factor (the image source).

The final factor affecting your Scale Set’s maximum capacity is the source of the image used when the Scale Set provisions the VMs it manages. If the image source is a Marketplace image (like any of the baseline images for Windows Server or Linux) then your Scale Set supports up to 1,000 VMs. However, if your VMs will be based off of a custom image you supply then your Scale Set will have a capacity of 100 VMs.

Deploy ARM VM Scale Sets using the Portal

To deploy a Scale Set using the Azure Portal, you deploy a Scale Set and as a part of that process select the Marketplace image to use for the VMs it will manage. You cannot select a VM Marketplace image and then choose to include it in a Scale Set (as you might when selecting a Resource Group). To deploy a Scale Set in the portal, complete these steps (Figure 1-8):

1. Navigate to the portal accessed via https://portal.azure.com.

2. Select + New and in the Search the Marketplace box, enter “scale sets” and select the “Virtual machine scale set” item that appears.

3. On the Virtual machine scale set blade, select Create.

4. In the Basics property group, provide a name for the scale set.

5. Select the OS type (Window or Linux).

6. Choose your Subscription, Resource group and Location. Note that the Resource group you select for the Scale Set must either be empty or be created new with Scale Set.

7. Enter a user name and password (for Windows), an SSH user name and password (for Linux) or an SSH public key (for Linux).

FIGURE 1-8 The Basics properties for the VM Scale Set

1. In the Instances and Load Balancer property group, set the instance count to the desired number of instances to deploy initially.

2. Select the virtual machine instance size for all machines in the Scale Set.

3. Choose whether to limit to a single placement group or not by selecting the option to Enable scaling beyond 100 instances. A selection of “No” will limit your deployment to a single placement group.

4. Select to use managed or unmanaged disks. If you chose to sue multiple placement groups, then managed disks are the only option and will be automatically selected for you.

5. If you chose to use a single placement group, configure the public IP address name you can use to access VMs via a Load Balancer. If you allowed multiple placement groups, then this option is unavailable.

6. Similarly, if you chose to use a single placement group, configure the public IP allocation mode (which can be Dynamic or Static) and provide a label for your domain name. If you allowed multiple placement groups, then this option is unavailable (Figure 1-9).

FIGURE 1-9 The Instances And Load Balancer properties for a VM Scale Set

1. In the Autoscale property group, leave Autoscale set to Disabled.

2. Select Create.

 

More Info: Deploying a Scale set Using Powershell or Azure CLI

You can also deploy a Scale Set using PowerShell or the Azure CLI. For the detailed step by step instructions, see https://docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-create.

 

Deploying a Scale Set using a Custom Image

To deploy a Scale Set where the VMs are created from custom or user-supplied image you must perform the following:

1. Generalize and capture an unmanaged VM disk from a standalone VM. The disk is saved in an Azure Storage Account you provide.

 

More Info: Creating a Generalized VM Disk

To generalize and capture a VM from a VM you have already deployed in Azure, see https://docs.microsoft.com/azure/virtual-machines/windows/sa-copy-generalized.

 

1. Create an ARM Template that at minimum:

   1. Creates a managed image based on the generalized unmanaged disk available in Azure Storage. Your template needs to define a resource of type “Microsoft.Compute/images” that references the VHD image by its URI. Alternately, you can pre-create the managed image (which allows you to specify the VHDs for the OS Disk and any Data Disks), for example by creating an image using the Portal, and omit this section in your template.

   2. Configures the Scale Set to use the managed image. Your template needs to defines a resource of type “Microsoft.Compute/virtualMachineScaleSets” that, in its “storageProfile” contains a reference to the image you defined previously.

2. Deploy the ARM template. Deploy the ARM template using the approach of your choice (for example, Portal, PowerShell or by using the Azure CLI).

 

More Info: Deploying ARM Templates

For instructions on deploying an ARM template, see https://docs.microsoft.com/azure/azure-resource-manager/resource-group-template-deploy-portal#deploy-resources-from-custom-template.

 

The following code snippet shows an example of a complete ARM template for deploying a VM Scale Set that uses Linux VMs, where the authentication for the VM’s is username and password based, and the VHD source is a generalized, unmanaged VHD disk stored in an Azure Storage Account. When the template is deployed, the user needs to specify the admin username and password to establish on all VMs in the Scale Set, as well as the URI to the source VHD in Azure Storage blobs.

Click here to view code image

{
  "$schema": "http://schema.management.azure.com/schemas/
2015-01-01/deploymentTemplate.json",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "adminUsername": {
      "type": "string"
    },
    "adminPassword": {
      "type": "securestring"
    },
    "sourceImageVhdUri": {
      "type": "string",
      "metadata": {
        "description": "The source of the generalized blob containing the custom image"
      }
    }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Compute/images",
      "apiVersion": "2016-04-30-preview",
      "name": "myCustomImage",
      "location": "[resourceGroup().location]",
      "properties": {
        "storageProfile": {
          "osDisk": {
            "osType": "Linux",
            "osState": "Generalized",
            "blobUri": "[parameters('sourceImageVhdUri')]",
            "storageAccountType": "Standard_LRS"
          }
        }
      }
    },
    {
      "type": "Microsoft.Network/virtualNetworks",
      "name": "myVnet",
      "location": "[resourceGroup().location]",
      "apiVersion": "2016-12-01",
      "properties": {
        "addressSpace": {
          "addressPrefixes": [
            "10.0.0.0/16"
          ]
        },
        "subnets": [
          {
            "name": "mySubnet",
            "properties": {
              "addressPrefix": "10.0.0.0/16"
            }
          }
        ]
      }
    },
    {
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "myScaleSet",
      "location": "[resourceGroup().location]",
      "apiVersion": "2016-04-30-preview",
      "dependsOn": [
        "Microsoft.Network/virtualNetworks/myVnet",
        "Microsoft.Compute/images/myCustomImage"
      ],
      "sku": {
        "name": "Standard_A1",
        "capacity": 2
      },
      "properties": {
        "upgradePolicy": {
          "mode": "Manual"
        },
        "virtualMachineProfile": {
          "storageProfile": {
            "imageReference": {
              "id": "[resourceId('Microsoft.Compute/images', 'myCustomImage')]"
            }
          },
          "osProfile": {
            "computerNamePrefix": "vm",
            "adminUsername": "[parameters('adminUsername')]",
            "adminPassword": "[parameters('adminPassword')]"
          },
          "networkProfile": {
            "networkInterfaceConfigurations": [
              {
                "name": "myNic",
                "properties": {
                  "primary": "true",
                  "ipConfigurations": [
                    {
                      "name": "myIpConfig",
                      "properties": {
                        "subnet": {
                          "id": "[concat(resourceId('Microsoft.Network/virtualNetworks',
                           'myVnet'), '/subnets/mySubnet')]"
                        }
                      }
                    }
                  ]
                }
              }
            ]
          }
        }
      }
    }
  ]
}

 

More Info: Template Source

You can download the ARM template shown from: https://github.com/gatneil/mvss/blob/custom-image/azuredeploy.json.

 

Configure Autoscale

Autoscale is a feature of the Azure Monitor service in Microsoft Azure that enables you to automatically scale resources based on rules evaluated against metrics provided by those resources. Autoscale can be used with Virtual Machine Scale Sets to adjust the capacity according to metrics like CPU utilization, network utilization and memory utilization across the VMs in the Scale Set. Additionally, Autoscale can be configured to adjust the capacity of the Scale Set according to metrics from other services, such as the number of messages in an Azure Queue or Service Bus queue.

Configuring Autoscale when provisioning VM Scale Set using the Portal

You can configure a Scale Set to autoscale when provisioning a new Scale Set in the Azure Portal. When configuring it during provisioning, the only metric you can scale against is CPU utilization. To provision a Scale Set with CPU based autoscale, complete the following steps:

1. Navigate to the portal accessed via https://portal.azure.com.

2. Select + New and in the Search the Marketplace box, enter “scale sets” and select the “Virtual machine scale set” item that appears.

3. On the Virtual machine scale set blade, select Create.

4. In the Basics property group, provide a name for the scale set.

5. Select the OS type (Window or Linux).

6. Choose your Subscription, Resource group and Location. Note that the Resource group you select for the Scale Set must either be empty or be created new with Scale Set.

7. Enter a user name and password (for Windows), an SSH user name and password (for Linux) or an SSH public key (for Linux).

8. In the Instances and Load Balancer property group, set the instance count to the desired number of instances to deploy initially.

9. Select the virtual machine instance size for all machines in the Scale Set.

10. Choose whether to limit to a single placement group or not by selecting the option to Enable scaling beyond 100 instances. A selection of “No” will limit your deployment to a single placement group.

11. Select to use managed or unmanaged disks. If you chose to sue multiple placement groups, then managed disks are the only option and will be automatically selected for you.

12. If you chose to use a single placement group, configure the public IP address name you can use to access VMs via a Load Balancer. If you allowed multiple placement groups, then this option is unavailable.

13. Similarly, if you chose to use a single placement group, configure the public IP allocation mode (which can be Dynamic or Static) and provide a label for your domain name. If you allowed multiple placement groups, then this option is unavailable.

14. In the Autoscale property group, chose to enable autoscale. If you enable autoscale, provide the desired VM instance count ranges, the scale out or scale in CPU thresholds and instance counts to scale out or scale in by (Figure 1-10).

FIGURE 1-10 The Autoscale settings for a VM Scale Set

1. Select Create.

Configuring Autoscale on an existing VM Scale Set using the Portal

You can configure a Scale Set to Autoscale after it is deployed using the Portal. When configuring this way, you can scale according to any of the available metrics. To further configure Autoscale on an existing Scale Set with Autoscale already enabled, complete the following steps:

1. Navigate to the portal accessed via https://portal.azure.com.

2. Navigate to your Virtual machine scale set in the Portal.

3. From the menu, under Settings, select Scaling.

4. Select Add Default Scale Condition or Add A Scale Condition. The default scale condition (Figure 1-11) will run when none of the other scale conditions match.

5. For the scale condition, choose the scale mode. You can scale based on a metric or scale to a specific instance count.

FIGURE 1-11 The Default scale condition

1. When choosing to scale based on a metric (Figure 1-12):

 Select Add rule to define the metric source (e.g., the Scale Set itself or another Azure resource), the Criteria (e.g., the metric name, time grain and value range), and the Action (e.g., to scale out or scale in).

FIGURE 1-12 Adding a Scale Rule

1. When choosing to scale to a specific instance count:

 For the default scale condition, you can only specify the target instance count to which the Scale Set capacity will reset.

 For non-default scale conditions, you specify the desired instance count and a time based schedule during which that instance count will apply. Specify the time by using a start and end dates or according to a recurring schedule that repeats during a time range on selected days of the week (Figure 1-13).

FIGURE 1-13 Adding a Scale Condition

1. Select Save in the command bar to apply your Autoscale settings.

 

More Info: VM Scale set and Autoscale Deployment with Powershell

For an end-to-end example walking thru of the steps to create a VM Scale Set configured with Autoscale showing how to deploy with PowerShell, see: https://docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-windows-autoscale.