One of the greatest advantages of Cloud computing is flexibility. Its flexibility helps you to assimilate changes in the workload. Azure incorporates various services that support flexibility. One of the latest of such services is the Azure Virtual Machine Scale Sets. For Azure Architects, two major parameters for architectural decision-making are scalability and availability.
Ready to dive in? Explore our Free Demo Content and join our Azure Certification, trusted by over many scholars! The following article familiarizes you with thorough details of VM scale set, availability sets, availability zone, and regions in Azure. So, let’s go through each of these sections:
What Are Virtual Machine Scale Sets (VMSS)?
One of the interesting services by Azure i.e. Virtual Machine Scale Sets (VMSS) assists to develop and manage a set of alike, auto-scaling Virtual Machines (VMs). Depending on the scheduled conditions, the number of VM instances could automatically increase or decrease. Azure VM Scale Sets are extensively used by Cloud administrators or IT professionals.
In simple terms, VM Scale sets in Microsoft Azure are clusters of distinct virtual machines (VMs) in the Microsoft Azure public cloud. These VMs can be configured and managed by IT administrators as a single unit. It is possible to create VM scale sets using the JSON templates, Azure portal, and REST APIs.
In Microsoft Azure, a VM scale set service is used to design sets of identical and load-balanced Virtual Machines (VMs). Essentially, it works as a fully managed platform with the capability to raise or decline the number of VM instances depending on schedule or demand. Since it is an Azure Cloud Service, the Scale set possesses high availability. Moreover, the Azure VM scale set assists in developing large-scale services for the organization in certain areas like Computation, Big Data, and container workloads.
The automatic process of scaling up or down the VM instances decreases the monitoring and supervising of the overhead of the applications. The users can build up or schedule the event to add/remove the VM instances at a predetermined time depending on certain rules. For increasing or decreasing the number of VMs in the scale set, the users can modify the capacity property and reorganize the template.
In Azure VM, the auto-scale users own the ability to denote a maximum and the minimum number of VM instances. Moreover, they can use using maximum and minimum instances to automatically scale amongst these two loads. Therefore, they can generate VM. Every time the rules and conditions are fulfilled, Azure activates the autoscale actions. Consequently, VM gets added or removed.
Azure Administrators can utilize Azure VM Scale Sets to set up comprehensive Azure services instead of duplicating the same VMs. To understand better, for example, an Azure VM Scale Set for a Web application service may comprise of application servers, web servers, network address translation servers, database servers, load balancing, and a few other functionalities. With the help of Azure VM Scale Sets, all such instances can be installed as a unit. This will allow Azure administrators to systematize and administer VMs as higher-level services instead of manually cobbling them together. Though Azure VM Scale Sets are typically deployed as a group, Azure administrators can use and interact with distinct VMs, if needed, to supervise and twist the individual instances.
The question may arise i.e. where the Azure VM Scale Sets are being used? Well, they are created to support large-scale computing services like big data processing and customer-oriented mobile or web applications. All these can benefit from processing which is shared across multiple virtual machines.
To benefit from the scalability, Azure administrators can merge Azure VM Scale Sets with some other Azure services like Autoscale in Azure Insights. Doing this facilitates automatic scaling up or down of the resources according to the change in the workload. It is possible that administrators state the VM limit, or define and tailor scaling events which not directly supported by Autoscale.
Note that any virtual machine which we deploy and is the element of the virtual machine scale set would not be assigned with a public IP address. The reason is occasionally the VM scale set would possess a front-end balancer that would administer the load and the same would possess a public IP address. The public IP address can be used and connected to fundamental virtual machines within the VM scale set. Also, note that a VM scale set is designed within VNET, and distinct VMs in the scale set are not assigned with public IP addresses.
Types of Autoscaling rules:
Autoscale allows the users to dynamically assign or remove resources depending on the load present on the services. They can state the minimum and maximum number of instances to be executed and add/remove VMs by following a set of rules in the rage.
Here is the description of Autoscaling rules:
i. Metric based Autoscaling:
It fundamentally quantifies the application usage or load and then carries out autoscaling of VM instances. For example, it facilitates performing some action when CPU usage reaches higher than 70%.
ii. Time based Autoscaling:
It is a scheduled-based auto-scaling that is activated whenever an application observes a particular time pattern or it is scheduled at a specific interval. For example, you can set it to be activated at a specific event like at 10 AM.
Here are the steps to be performed in Autoscaling:
Step-1: The first step is to choose time or metric. Based on this choice, it will turn out to be metric-based or schedule-based autoscaling. You can define metrics like CPU utilization whereas you can define time like 6 AM.
If you want to decrease the number of servers then schedule-based auto-scaling is useful. But to perform autoscaling according to load, metric-based auto-scaling is useful.
Step-2: The second step in the auto-scaling is to specify a rule with the condition. To understand better, for example, if the CPU utilization exceeds 70% then it is necessary to spin off a new instance. After the condition is fulfilled, some actions can be performed. These can be adding/removing VMs or delivering email to a system administrator, etc. It is vital to choose the type of autoscaling and define the actions and rules which must be followed when the condition in that specific rule is met.
Now let’s understand the types of Azure VM scale sets:
Types of Azure VM Scale Sets:
1. Horizontal Scaling:
It defines the process of adding/removing single or multiple VMs from a scale set based on the load present in the application. This scaling is used whenever users demand a specific VM for a certain time interval during which the load present on the application is higher and then discard the machines after the particular period is over. Here, rules to perform autoscaling are mostly metric-based as adding or removing the machines depends on the application’s demand.
2. Vertical Scaling:
It is the process of adding the resources of machines like CPU power, RAM, disks space, etc., to a scale set as per the load of the application. Typically, resources are added to boost the capacity of the machines. To accomplish vertical scaling, it usually happens that the system needs to reboot or restart the specific machines in which resources are already added. The same can momentarily influence the overall performance of the VM scale set.
Vertical scaling is used when the user wants to boost the performance of the specific scale set owing to the degradation in CPU performance. So, CPU resources are appended to the specific VM scale set to boosts the size of machines.
Reasons to use virtual machine scale sets:
To offer enhanced performance and redundancy, applications are usually spanned across multiple instances. A load balancer helps customers to access your application. This component allocates requests to any one of the application instances.
Keep in mind that if you intend to carry out maintenance or update any application instance, your customers should be shared with another accessible application instance. Moreover, to fulfil the additional customer demand, you might have to boost the number of application instances that operate your application.
Azure VM scale sets offer management abilities to those applications that operate across several VMs, load balancing of traffic, and automatic scaling of resources.
Let’s dive deep into the reasons to use VM scale sets:
i. Ease of creating and managing multiple VMs:
When there are several VMs that execute your application, it becomes vital to maintain a uniform configuration throughout your Azure environment. To make sure your application offers reliable performance, the parameters like disk configuration, VM size, and application installs must match throughout all the VMs.
With the implementation of VM scale sets, every VM instance are prepared from the same base OS image as well as configuration. This tactic assists you to deal with tons of VMs without making any additional configuration tasks or adopting any network management technique.
VM scale sets to support the usage of Azure load balancer for basic layer-4 traffic distribution. It also supports Azure Application Gateway for more advanced layer-7 traffic distribution as well as TLS termination.
ii. Offers application resiliency and high availability:
VM scale sets are extensively used to execute multiple instances of an application. In case any of such VM instances depict any problem, the customers would continue to access your application using any other VM instances.
To benefit from high availability, Availability Zones can be used to automatically share VM instances in a scale set in a single datacenter or throughout multiple datacenters.
iii. Automatically scaling of the application according to changes in resource demands:
All through the day or week, the customer demand for the application you designed may change. To fulfil their demand, VM scale sets can automatically elevate the number of VM instances according to the increase in demand of the application. Subsequently, it decreases the number of instances as demand declines.
Autoscale also reduces the number of superfluous VM instances which execute your application whenever demand is low. In this case, customers persist to obtain a satisfactory level of performance with the rise in demand, and also, the additional VM instances are added automatically. So, this feature helps in cost reduction and competently creates Azure resources as needed.
iv. Ease of scalability:
Scalability assures that resources can deal with the load, depending on the modification of work quantity. It also assures that resources are flexible to deal with the load.
v. Operates at large-scale:
VM scale sets allow a maximum of 1,000 VM instances for standard marketplace images as well as custom images via the Azure Compute Gallery. So, if you intend to develop a scale set with the help of a managed image, note that the limit would be 600 VM instances. You can use the Azure Managed Disks to obtain outstanding performance with production workloads.
vi. Ease of grouping multiple VMs:
It is possible to group multiple VMs beneath a single scale set. For instance, you may have two VMs with applications belonging to the travel domain. You can place both of them underneath a single scale set and then define an identical scale set for both.
Similarly, you can club VMs that share accounting domain applications into a different scale set. Consequently, it becomes simple to handle multiple VMs in form of a group to delineate and manage their scalability by maintaining a uniform configuration throughout your environment. At this point, you need to define scalability across scale sets instead of individual VMs in it. This way, it is possible to handle thousands of VMs.
What is Availability in Azure?
Availability guarantees that resources exist whenever you access them. Since Azure is a cloud service provider, it presents varying availability benchmarks for varied services. These availability ratings are usually published as 99.99xx%.
What are Availability Sets in Azure?
In the process of creating a Virtual Machine, availability sets make sure every VM is secluded with distinct physical servers, storage units, compute racks, and network switches in a single datacenter in an Azure Region. A group consisting of two or more VMs in the same Data Center is known as Availability Set. At least one of the VMs being hosted on Azure will be available in all other VMs going down. The corresponding configuration provides 99.95% SLA.
To understand better, for example, you have 3 VMs within Availability Set. In case one VM set of computer racks or physical servers or network switches or storage units go down, the resources of the remaining 2 VMs will continue working. Since each VM is deployed in a distinct resource, if one of them goes down, it will not influence the overall performance.
It is important to note that this availability applies in a single region in a particular data center. If the entire data center goes down, you will lose the whole availability.
In other words, an Availability Set represents a logical grouping ability for secluding VM resources from one another while they are deployed.
With the deployment of your VMs over multiple hardware nodes, Azure guarantees that whenever software or hardware failure takes place in Azure, only one sub-set of your VM is influenced. Your overall network setup stays safe and continues working.
It offers redundancy for your VMs. An Availability set spans your VMs throughout multiple update domains and fault domains.
One important aspect to note is that when you create your VM, you can mention the Availability Set. However, you can’t modify it or transfer it in or out of an Availability Set once created. If you intend to make changes, you can start again and also recreate the VM. Availability Sets are only applicable to VM; they can’t be employed for any other kind of resource in Azure.
The implementation of an Availability Set reduces your system’s tolerable downtime to approx. 22 minutes per month. This can be considered as a significant improvement than a single VM deployment.
Types of Availability Sets:
i. Fault Domain: It denotes a cluster of VMs that share common power sources and identical networks.
ii. Updated Domain: It denotes a group of Virtual Machines that simultaneously accomplish activities like reboot, maintenance, and update. If you want to obtain maximum availability, you need to deploy VMs across multiple Fault Domains.
The following table shows availability (%) as per the VM instance in Azure:
Single VM with premium SSD 99.9% Availability
Single VM with standard SSD 99.5% Availability
Single VM with standard HDD 95% Availability
Create 2 VM instances in the same Availability set 99.95% Availability
Note: 99.99% availability is also known as four 9’s availability
How to configure an Availability Set?
An Availability Set can only be configured when you deploy a new VM. You can’t add VM to an existing Availability Set. It is straightforward to configure an Availability Zone from the Azure Portal. All you have to do is choose the number of Zones that the VMs would use.
Scale Set vs. Availability Set: Differences:
VM Scale Set consists of a set of identically configured VMs.
Scale Set Availability Set
VM Scale set comprises a set of similarly configured VMs spanned across fault domains (a scale set can be considered as an implicit availability set consisting of 5 fault domains).
Availability Set comprises a set of distinct VMs that possess their unique properties and names. However, they are spanned across fault domains. This implies that when you have multiple VM in as et, it decreases the odds of losing all your VMs in the situation of a hardware failure within the rack or host.
Since VMs are identical, it is quite straightforward to add/remove VMs from the set without compromising on availability. Hence, it becomes easy to execute autoscale and to carry out operations on the entire set or a subset of VMs. VM Scale Sets also support re-imaging and upgrading VMs which allows you to release an update as well as keep the system running.
They are extensively useful for cloud architectures that demand deploying huge numbers of identical VMs.
You can deploy an availability set when there is a predictable workload to be protected against downtime. It implies that if you know that your solution can execute on a single VM, you will prepare two VMs in an availability set. Doing this ensures that a minimum of one VM would continue to run at all times and there will be a load balancer to direct traffic to an active VM.
Scale sets contain 5 update domains and 5 fault domains per placement group. These domains are automatically allocated when machines are scaled out. It is possible to modify this default setting by contacting Azure support.
Each Availability Set comes with 5 update domains and 3 fault domains.
The next important topic of this article is Availability Zone, let’s explore it:
What is the Availability Zone in Azure?
All that we discussed regarding availability applies to the Availability Zone. However, this availability applies in a single region across multiple data centers. Multiple data centers can be present within a single zone or throughout multiple zones. It is possible that these data centers can fall under a single region and region replication is also possible.
Whenever all those data centers are down, the whole availability will be lost. Each Availability zone comprises multiple data centers. You need to determine how to replicate over data centers as well as availability zones in the specific region.
With the implementation of Availability Zones, your system’s tolerable downtime per month drops to less than 5 minutes. The reason is it covers 99.99% VM uptime SLA (Service Level Agreement).
With the use of Availability Zones, you begin to use Zone Aware services. Note that your workload will be spanned out over diverse zones that contribute to an Azure region. Fundamentally, an Azure region is composed of multiple datacenters and every zone is composed of one or multiple datacenters. Categorizing further, each datacenter is implemented with independent power, networking, and cooling. Availability Zones in a particular region are connected through low latency links.
Note that not every Azure region has Availability Zones.
The following table shows Availability Zones as per region:
Region Availability Zones
East US 3
West Europe 3
Southeast Asia 3
West Central US 0
Here are the 3 key benefits of using Availability Zones:
• Low Latency
• High Availability
• Global Deployment
In other words, Azure Availability Zones represent a high-availability offering that protects your applications as well as data against datacenter failures. They are distinct physical locations in an Azure region. They can be deployed with the help of single or multiple VMs in an Azure region. Moreover, zone-redundant services duplicate your applications as well as data throughout the Azure Zones. The motive behind this is to protect them against single-points-of-failure.
Two categories of Availability Zones:
i. Zonal Services: They add the resource to a particular zone. Examples include VMs, IP addresses, and managed disks.
ii. Zone-redundant services: They work on automatic replication across zones. They are enabled for zone-redundant storage and SQL Database.
How to configure an Availability Zone?
It is quite simple to configure an Availability Zone from the Azure Portal. You just have to choose the number of the Zones that the VMs would use.
You need to make this selection from the Availability Zone drop-down. It is possible to simultaneously deploy your managed disk and your public IP (if you have one).
Note: To benefit from a 99.99% SLA, you should deploy a minimum of two VMs in at least two diverse zones.
Availability Set vs. Availability Zone: Differences:
SLA 99.95 % SLA 99.99%
Protects against hardware failures in data centers Protects against whole data center failure
What are Azure Regions?
An Azure region is a set of data centers that are deployed in a latency-defined perimeter as well as connected via a separate regional low-latency network.
Boasting more global regions compared to any other cloud provider, certainly, Azure benefits the customers with great flexibility to deploy applications where they require to. Typically, Azure is available in 52 regions throughout the world with plans declared for 6 additional regions.
Characteristically, multiple Azure Regions exist in a single Geography. Moreover, Azure Regions are paired for redundancy of certain low-level Azure services like Storage Accounts. For example, Australia has four Azure Regions i.e. Southeast and Australia East (paired) with Australia Central 1 & 2 that are paired. Azure Regions slightly differ from the way AWS delineates and deploys Regions.
What is Azure Region Pairing?
Every Azure region pairs with another region in the same geography to create a regional pair. Moreover, Azure serializes platform updates to make sure only one region gets updated at a time. Those Azure Regions present in a Pair come with direct connections that provide extra benefits to use collectively. Azure offers more than 60 regions throughout the globe.
Every Azure Region in a pair is always situated at a distance of more than 300 miles when possible.
Here are 3 key advantages of Multiple Azure Regions:
• Low Latency
• High Availability
• Data Redundancy
Examples of region pairs are
• South-East Asia paired with East Asia
• West US paired with East US
Deploying and managing identical VMs is possible with the VM Scale Sets. These Azure compute resources are specifically designed to facilitate virtual machine auto-scaling. Availability Set makes sure at least one VM will be available although other VMs are down. Deploying VMs and applications across different regions is possible with Azure Regions. Availability Sets and Availability Zones can be deployed using PowerShell and Azure Portal.
Check out our free courses on Microsoft Azure Training to get an edge over the competition.
Take our free azure skill challenge to evaluate your skill
In less than 5 minutes, with our skill challenge, you can identify your knowledge gaps and strengths in a given skill.