Partager via

Got VM Scale Sets? aka.ms/Azure/VMSS

  • Article

VM Scale Sets enable you to deploy and manage multiple VMs as a set. Instead of provisioning multiple individual VMs, you provision a Scale Set based on an image, just like a regular VM. The Azure platform then provisions and de-provisions VMs based on that image as needed. High availability, load balancing, and scaling are managed by the Azure platform by integrating with Azure Autoscale and the Azure Load Balancer. This makes VM Scale Sets ideal for server clusters or farms that need to scale automatically, such as a farm of web servers, rendering capacity for animations, etc.

Since this was previewed last March, we are seeing VM Scale Sets (VMSS) being used in lots of places not only within Microsoft, but also among many of our largest consumers of Cloud services. As you all know the stories are constantly evolving and changing based on what our customers tell us they need. To help us decide if VM Scale Sets are appropriate to use for VMs, I made this comparison list for myself and my customers to look at the Pros and Cons (for now) that should be considered.  As to when the "cons" will become "pros"; that is a closely guarded secret.  I will just say this much: Stay tuned and watch MS Ignite this September and someone may tell you something that may happen :)

WHY VM Scale Sets versus Virtual Machines?

VMSS VM
Deployment at scale Deployment per VM
Autoscale Scale fixed set of VMs
Pattern based name Permanent name/IP
Public IP per VMSS Public IP per VM
Idential Extension parameters Per VM Extension parameters
Rolling Upgrade Per VM upgrade

 

Now, let's take a look at the Pros and Cons of using VM Scale Sets.

PROS

  • VM Scale Sets utilizes Horizontal Scaling aka Scale In and Scale Out
    • Where the number of VMs is altered depending on the workload
      • You can also scale based on other criteria like date/time
    • A scale out event will only take place when the average CPU across all the VMs in a scale set exceeds the threshold value, over the time internal defined in the Autoscale rules.
      • If CPU is the performance metric you choose. You can scale on a range of metrics.
  • You can do Vertical Scaling which is…
  • Autoscale currently limited to CPU% performance within x minutes
    ...this is only a portal limitation.
  • Best for Stateless applications
    • Stateful PaaS services like Service Fabric run on scale sets. Stateful applications run on scale sets, though the application has to take on some state management.
  • VM scale set is created inside a VNET and individual VMs in the scale set are not allocated public IP addresses.
    • This is a good thing because
      • you don't generally want the expense and management overhead of allocating separate public IP addresses to all the stateless resources in your compute grid
      • and you can easily connect to these VMs from other resources in your VNET
      • including ones which have public IP addresses like load balancers or standalone virtual machines.
  • Implicitly set for 5 Fault and Update Domains
  • Anywhere you can run a VM, you can run
  • Integrate with Webhooks

CONS

  • No current support to attach Data Disks, but in preview now, so coming soon!
  • Vertical Scaling takes a little bit of messaging and is not automatic
  • Limited to 20 disks per Storage Accounts, versus 40 - but can be overridden
    • If you turn off overprovisioning, you can go up to 40
    • To turn overprovisioning off, ensure you have the following string in your template: "overprovision": "false"
  • Currently no Public IP per VM, only at the Load Balancer
  • Currently no disk encryption
  • VM Extension sequencing can be a problem with Autoscale
    • particularly with Apt-Get, since it can only run one process at a time and Autoscale would try to run in parallel
    • Read about this and workarounds at Extension sequencing in Azure VM Scale Sets
      • Extension sequencing support is planned this year.

RELATED TOOLS & TEMPLATES