In this post, we are going to discuss Azure Virtual Machine Scale Sets (VMSS).

We will learn:

  • What VM scale sets are
  • How are VM scale sets configured
  • When to use VM scale sets

Scale sets provide an ability to deploy and manage multiple identical VMs. Scaling in and out allows Azure administrators to increase or decrease the number of VMs in a set based on various parameters used to monitor the performance of the application. This means that during peak hours, additional VMs can be added to a scale set and removed during off hours. This ensures optimal performance of hosted applications while maintaining minimum cost.

Some restrictions and best practice recommendations to keep in mind:

  • The maximum number of VMs in a Scale Set based on Microsoft-provided configurations can be 1000. This number decreases to 100 if the VM image is custom built.
  • To avoid any limitation related to the storage accounts like IOPS/account, usage of Managed Disks is recommended as it provides the possibility to create 1000s of disks needed for up to 1000 VMs in a scale set.
  • For better performance, Azure recommends using premium storage instead of standard storage. Caveat that premium storage costs more.

Scaling in and scaling out use the autoscale function.

The benefits of autoscaling are:

  • Higher fault tolerance – unhealthy VMs are taken out of the load balancer and allow auto-scaling rules to kick in additional healthy VMs
  • Higher availability – ensuring sure that the application that uses the scale set with the autoscale has always the resources it needs
  • Improved cost management – scaling in and scaling out makes sure that unneeded VMs will not incur any unnecessary cost

One interesting option in VMSS is overprovisioning. When turned on, during scaling out events, Azure will spin up more VMs than the number of requested machines. The amount of overprovisioned VMs varies and depends on the number of VMs and the OS. Once the requested number has started up, Azure will remove unnecessary VMs. This ensures that scale-out events have more chance to bring up stable VMs. There is no additional charge for any VMs that were brought up and then deallocated in excess of requested amount. While this is a useful feature and it is ON by default, there are some implications that one needs to consider. CloudMonix auto-scaling engine may get confused by the increased number of VMs during scale-out periods. If CloudMonix’s auto-scaling is used and this feature is not critical to have, it is recommended that it is disabled.

Typically, the scale sets are agnostic worker roles. They are just platform independent compute resources that a user can customize to meet the user requirements and perform very specific tasks.

Let us cover a use case how a web application that is deployed on Azure can take advantage of scale set:

In this diagram, all web servers need to do handle HTTP requests from mobile users, hence these servers have same characteristics in terms of setup, computing specifications, CPU, memory.

Using VM scale sets, users can spin multiple VMs and not worry about managing each VM separately.

Considering that the traffic hitting the scale set is load balanced across all the scale set members, higher availability and higher fault tolerance will allow the application to perform better.

Let us cover another use case for VM scale sets and that is the usage together with Azure Service Fabric.

The Service Fabric is a distributed platform that allows to deploy and manage microservices in a scalable and reliable way. Microservices give the possibility to scale different parts of the application and to develop or change independently different parts of the application.

A Service Fabric has multiple components, but we will cover briefly only the infrastructure concepts: the cluster and the node. The cluster is a set of network-connected virtual machines or physical servers on which the microservices run. Just as a side note, inside the node, containers provide another level of virtualization inside VMs and inside these containers the microservices will run allowing hyper-scalability of hundreds of thousands of microservices.

The foundation of the cluster is the node as mentioned, it can be a virtual machine or a physical server.

And here is where VM Scale Sets come into play. Every node from the cluster can be part a separate scale set. This will allow, if needed, different VMs for each cluster node to have similar characteristics and to be managed together as a single virtual unit. Microservices with the same requirements can start instantly on identical VMs that come from the same scale set.

Let us quickly see what deploying VM scale sets involves.

From the Azure Portal, select Virtual Machine scale set service:

Next select “Virtual Machine scale set” from the list:

Fill in the name of the VM scale set along with the name of the administrator account on the VMs:

Specify the DNS label assigned to the public IP along with the number of the instances in the scale set. Enable or leave disabled the autoscale function:

Check what you have configured and go ahead and create the VM scale set:

You can see in the notifications section that the VM scale set deployment is in progress:

We saw some use cases and how can scale sets are making the life easier. In a future post, we will see how CloudMonix can monitor and take actions based on specific availability/usage triggers.

 

 

Reference:

  1. What are virtual machine scale sets in Azure?
  2. Azure Virtual Machine Scale Sets GA
  3. Designing VM Scale Sets For Scale