Introduction

VM Scale Sets are an Azure Compute resource you can use to deploy and manage a collection of virtual machines as a set. Scale sets are well suited for building large-scale services targeting big compute, big data, and containerized workloads - all of which are increasing in significance as cloud computing continues to evolve. Scale set VMs are configured identically, you just choose how many you need, which enables them to scale out and in rapidly and automatically. The elastic nature of VM Scale Sets makes them ideal for supporting scale-out workloads like stateless web front ends and container orchestration or microservices clusters. The main real-world problem with Scale Sets is "staleness" of the source Image.

Creating a Source Image

Scale Sets are based on a Virtual Machine image. Images provided by the cloud platform are preferable, however this is often not practicable in the case of COTS packages or OS hardening processes. Correctly creating an Image results in the destruction of the source VM. This is due to the need to run Sysprep (or Linux equivalent) to generalize the machine by removing computer-specific information . Performing this task is generally manual because automation is generally difficult and time-consuming to script reliably.

Staleness Examples

OS Hardening

Once an image is created, that Image is used to create new VM's within a Scale Set. Due to the difficulty of creating an Image, a new VM may be based on an OS many months out of date.

Consider the following real-world scenario:

1. January 1:

● A VM is created

● OS patches are applied

● An Image is created

● A Production Scale Set is initialized with five VM's.

2. September 30

● Due to changes in workload, the Scale Set spins up four additional VM's.

Picture 24

At this point the four additional production VM's have been initialized. OS hardening is 10 months out of date leaving the enterprise vulnerable to attack. The new VM's may take days to apply all OS patches. During this time many OS restarts may be required.

COTS Packages

Many COTS packages support installation via automation. This process can be cumbersome and time-consuming to script. Many other COTS packages do not support automated installation at all. In this scenario, the COTS package could be a Web Application or Application server.

Consider the following real-world scenario:

1. January 1:

● A VM is created

● OS patches are applied

● A COTS packages 1.0 is installed and configured

● An Image is created

● A Production Scale Set is initialized with five VM's.

2. March 31

● A VM is created

● OS patches are applied

● A COTS packages 1.1 is installed and configured

● An Image is created

● A Production Scale Set is re-initialized with five VM's.

3. July 31

● A VM is created

● OS patches are applied

● A COTS packages 1.2 is installed and configured

● An Image is created

● A Production Scale Set is re-initialized with five VM's.

4. September 1

● A VM is created

● OS patches are applied

● A COTS packages 1.3 is installed and configured

● An Image is created

● A Production Scale Set is re-initialized with five VM's.

5. Due to changes in workload, the Scale Set spins up four additional VM's.

Picture 25

Nine production VM's have been initialized. OS hardening is up to date. However, due to the manual nature of the COTS installation, a problem exists in the Scale Set. It will take a long time for the operator to determine the cause. If a patch had been installed instead of a full install, the problem would likely be avoided. For each quarterly release, the operations team has to do a lot of error-prone work that could be avoided.