In a recent blog post, Mark Russinovich, cto of Microsoft Azure, announced a public preview feature called Azure Scale Sets. Azure Scale Sets are an Azure Compute resource which allow you to deploy and manage a group of virtual machines (VMs) as a collective group, or set.
For customers who deploy a set of identical VMs, this new service provides them with a consistent management experience when deploying and scaling these VMs out or in. With this service, you do not need to have additional VMs already provisioned.
Both Windows and Linux VMs, plus any VM extensions, can belong to an Azure Scale Set. Both custom and Azure Marketplace VMs are also supported. In order to create or deploy an Azure Scale Set, developers can use JSON-based ARM templates and deploy them via the Azure Resource Manager. Other deployment options include the use of Power Shell cmdlets or Azure Command Line (CLI) tool.
As part of defining your Azure Scale Set, customers need to define resources that are required including a resource group, network interfaces (NICs), scalable storage, extensions and load balancer, if applicable.
Image Source: https://azure.microsoft.com/en-us/blog/azure-vm-scale-sets-public-preview/
Administrators also need to provide VM Scale Set properties including the number (upper limit) of VMs that are anticipated and thresholds that dictate how the scale operations should be managed. However, as Russinovich explains “Unlike with single-instance VMs, you do not need to independently define and correlate network, storage and extension resources for individual VMs. “
The following image illustrates how properties can be defined within an ARM template including the capacity property.
Image Source: (Screenshot) https://www.youtube.com/watch?v=vh6sLvTNCCs
One of the scenarios that Guy Bowerman, senior program manager at Microsoft, has suggested as a good fit for this architecture is a multi-vm stateless web farm. In this scenario, a web client is able to connect to a load balancer that has an external IP address. In turn, the load balancer will route traffic, using a round robin algorithm, to a number of VMs that belong to this Azure Scale Set. In the event CPU utilization is high in this Scale Set, suppose greater than 60% for a period of 5 minutes, the platform will scale out another VM. Should workloads reduce, suppose less than 50% for 5 minutes, then the platform will scale back in.
The following image illustrates represents how this architecture can be represented.
Image Source: (Screenshot) https://www.youtube.com/watch?v=vh6sLvTNCCs
Another scenario, described by Bowerman, involves network address translation (NAT) which allows private, or internal, network ports to be represented differently to external clients. In this scenario, an administrator will define an external port range, such as 50000 to 50100. Internally, each VM will expose their traditional ports, such as 22 for SSH. Inbound NAT rules will provide a port mapping between the external port range and the internal VMs. For example port 50000 will belong to the first VM, port 50001 would belong to the second VM and so on. Using this approach reduces any affinity between an external port number and an internal server.
The following image illustrates how this configuration would be setup.
Image Source: (Screenshot) https://www.youtube.com/watch?v=vh6sLvTNCCs