Infrastructure as a service (IaaS) is an important way to make your projects “go cloud.” However, many real-world projects don’t fit so neatly into one category. When it comes to projects that require flexible scenarios and come with lots of specific requirements, I’ve found Azure Virtual Machines to be a good choice for deployment. In this post, we will look at deploying multiple virtual machines (VMs) on Azure to improve availability and scalability using an Azure Resource Manager Template or VM scale sets.
Virtual Machines and the Cloud
Azure Virtual Machines is one of several types of on-demand, scalable computing resources offered by Azure. Azure VMs provide you with an operating system, storage, and networking capabilities, and they can run a wide range of applications.
Compared to a traditional on-premises virtual machine, a cloud VM allows you to quickly scale up and down with demand. This means that you pay only for what you use on the cloud, and you don’t need to buy and maintain the physical hardware that runs the virtual machine. You still need to maintain the virtual machine by configuring, patching, and maintaining the software that runs on the VM. However, it’s flexible pricing makes it more efficient in terms of time and costs.
Comparing App Service, Cloud Service, and Azure Virtual Machine
As I mentioned in my post, Azure App Service in Action, the main differences between Azure VM and App Service is the amount of control they offer over the OS and the supported features for your environment.
|App Service||Scalable Web Apps, Mobile Apps, API Apps, and Logic Apps for any device|
|Cloud Services||Highly available, scalable n-tier cloud apps with more control of the OS|
|Virtual Machines||Customized Windows and Linux VMs with complete control of the OS|
Classic Azure VMs vs. ARM Azure VMs
When you interact with classic mode resources from a command line such as Azure PowerShell, you are using Azure Service Management API calls (ASM). ASM is a traditional way of accessing Azure resources. Both the classic portal and Azure PowerShell use ASM API calls to manage Azure resources.
Another option is the Azure Resource Manager (ARM), which plays an important role in managing resources as a single unit. The ARM allows you to deploy Azure resources in groups called Resource Groups. With the new Azure portal, you can work with both classic and ARM Resources. When you interact with ARM using command-line tools such as Azure PowerShell, you are using ARM API calls. We still have some services in the classic model that we can virtualize via the new Azure portal, but we should match the deployment mode type.
Generally, the ARM model allows you to:
- Deploy, manage, and monitor Azure resources as a group.
- Deploy resources repeatedly.
- Create templates. Templates can be created to include a set of resources to be deployed as part of a cloud solution.
- Define dependencies between resources so they are deployed in the correct order.
- Apply role-based access control (RBAC) policies to all resources in a Resource Group.
- Specify “tags” to resources for programmatic purposes.
Deploying Multiple Virtual Machines on Azure
Let’s look at how to start deploying Virtual Machine on Azure.
Workloads that can or cannot be deployed on Azure VM
Certain types of workloads are a better fit for hosting in an Azure IaaS environment than others. Here are some examples:
- Highly available service workloads such as commercial online stores.
- Unpredictable growth workloads like those experienced by small, but rapidly expanding organizations or short-term increased sales of fad items.
- Spiking workloads, such as those experienced by sites providing news services.
- Steady workload scenarios where organizations simply want to offload their infrastructure to the cloud.
- Periodic workloads such as retail sales spurts during holidays.
However, not every application or service is a suitable fit for the cloud. Here are some examples:
- Low volume or limited growth workloads where it might be cheaper for the organization to run the service or application on commodity hardware on-premises.
- Regulated environment workloads where the type of data that can be hosted in the cloud is regulated (by the organization itself, by local government, etc.). However, these cases might be suitable candidates for a hybrid solution where only some highly available data is hosted in Azure and the more sensitive, regulated data is kept on-premises.
All Microsoft software installed in the Azure virtual machine environment must be licensed correctly. The Microsoft server software support for Microsoft Azure virtual machines page lists the currently supported products and versions.
Identify the size of your VM
You can configure virtual machines with a variety of options for CPU, memory, and IOPS. Windows virtual machines are available in several different size families. When your requirements change, it is easy to resize the VM.
Access official Azure documentation for more information about Sizes for Windows virtual machines in Azure. I would also recommend this article about sizing considerations for Azure machines: Azure A-SERIES, D-SERIES and G-SERIES: Consistent Performances and Size Change Considerations.
Dv3 and Ev3 for Nested Virtualization
In May 2017, Microsoft announced that Azure VMs such as Azure VM sizes Dv3 and Ev3 & will support nested virtualization. This feature allows you to install the Hyper-V feature inside a Windows Server running on Azure VMs, making it very useful for training and demo scenarios.
“Burstable” B-Series: A more affordable Azure VM
One of the most common complaints about Azure Virtual Machine pricing is that it’s too expensive for small workloads. Its “Burstable” B-Series as an even more cost-effective and affordable cloud for lightweight workloads. This is for smaller workloads that do not utilize the full CPUs allocated, such as for web servers, small databases, or development, test, or QA environments.
The B-Series VMs work much differently than the other options in the VM Series. You pay for a baseline of vCPU performance utilization with the number of vCPU cores allocated. The new B-Series is $5 per month for the smallest size; the Standard B1s and the Standard B8ms offer 8 “burstable” vCPU cores for approximately $139 per month with a baseline of 135%. This means that the B8ms at its base is similar to other Single vCPU Core VM sizes, but it can burst to 800% vCPU performance utilization and use all 8 cores at 100% each for short periods.
Different ways of Creating Virtual Machines
Because virtual machines are suited for different users and purposes, Azure offers Azure Portal, Azure PowerShell, ARM Template, Virtual Studio, etc. to create a virtual machine. Take Azure CLI with Azure Cloud Shell, for example. Azure CLI is used to create and manage Azure resources such as Azure Virtual Machine from the command line or in scripts.Azure Cloud Shell is a web-based shell that is preconfigured to simplify using Azure tools. With Cloud Shell, you always have the most up-to-date version of the tools available, and you don’t have to install, update, or separately log in. To learn more, refer to the official documentation for creating Create an Azure virtual machine with Azure CLI and CloudShell.
Multi-Azure VM in action: Configuring Azure VMs
Configuring Availability using Availability Sets
There are two types of Microsoft Azure platform events that can affect the availability of your virtual machines:
- Planned maintenance: When VMs are restarted due to Microsoft updates to the underlying platform
- Unplanned maintenance: When there is a hardware failure
To provide redundancy to your application, we recommend that you group two or more virtual machines in an Availability Set, which is a logical grouping of two or more virtual machines. This configuration ensures that during either a planned or unplanned maintenance event, at least one virtual machine is available and meets the 99.95% Azure SLA.
When creating Availability Sets, Microsoft recommends the following best practices:
- For redundancy, configure multiple virtual machines in an Availability Set.
- Configure each application tier into separate Availability Sets.
- Combine a Load Balancer with Availability Sets.
Scale up or Scale out: Configuring Scalability
There two ways to scale out Azure VM:Provision additional VMs and put them in the load balancer’s back-end address pool or use a virtual machine Scale Set.
To learn more about how to configure load-balanced VMs for scalability, this article from the official Azure documentation is an excellent resource: Run load-balanced VMs for scalability and availability.
Multi-Azure VM In action: Deploy Multi-VM via VM Scale Sets:
VM Scale Sets help you deploy and manage a set of identical VMs. There are two basic ways to configure VMs deployed in a Scale Set:
- Use extensions to configure the VM after it is provisioned.
- Create a custom image. This option requires you to keep the image up to date. A scale set built on a custom image must create all OS disk VHDs within one storage account.
For additional considerations, please refer to Designing VM Scale Sets for Scale.
Let’s take a look at how to create a Virtual Machine Scale Set (VMSS). When we are in the Azure Portal, we can search ‘Virtual machine scale set,’ then click ‘Create.’ Because VMSS is only available in the ARM model, we can only select ‘Resource Manager’ as the deployment model.
Then we can fill the basic information in the Basic blade.For the Placement Group, if you choose True, the Scale Set will be limited to 1 placement group WITH a max capacity of 100. If you choose False, the Scale Set can span Placement Groups. This allows for capacity up to 1,000, but it changes the availability guarantees of the Scale Set.
Next, we’ll create a new Resource Group, which we will name ‘testCloudRG.’ I’ll keep the default location as West Europe since I am based in Paris.
On to the Configuration blade. There is a public IP address for the Load Balancer in front of the scale set. We can configure this IP as Dynamic or Static.
We should also enter a desired domain name label. This is the base of the FQDN for the load balancer in front of the scale set. FQDN, or fully qualified domain name, is a domain name that specifies its exact location in the tree hierarchy of the Domain Name System (DNS). This label must be unique across all Azure. Here, we will enter an appropriate name.
Next, you can choose an operating system disk image, which will be used for all the virtual machines in the VMSS.
The instance count is the number of virtual machines in the Scale Set, which ranges from 1 to 100.
For the disk type, there are two options: managed and unmanaged. Managed disks hide the underlying storage accounts and instead show the abstraction of a disk. Unmanaged disks expose the underlying storage accounts and VHD blobs. In our case, we will choose “unmanaged here.”
We can also scale up the VMs by modifying machine size. We can choose from the different pricing plans provided by Azure, the different supported disk type HDD or SSD, the number of minimum cores, and the minimum memory to help you find a plan that meets your technical requirements.
Configuring scale out and scale up when creating VMSS
Finally, you can also enable or disable autoscale. If you choose to enable it, you should configure the necessary information such as the minimum or maximum number of VMs and especially the CPU percentage threshold, which is an important rule when scaling out and scaling. Then click OK.
Once you’ve confirmed that all the information you have entered on the Summary blade is correct, you can click OK to start the Scale Set deployment. The deployment will last about 5 to 10 minutes.
After the deployment, we can see that there are some related resources in the same resource group of the VMSS: We have created a public IP for the load balancer and a virtual network for our VMSS.
Even after the creation of VMSS, we can scale it up and out, and we can add a scale condition for the VM in the same VMSS.
Scale Sets support auto-scaling based on performance metrics. As the load on the VMs increases, additional VMs are automatically added to the load balancer. Consider Scale Sets if you need to quickly scale out VMs or if you need to autoscale. For more information on Scale Sets, please refer to What are virtual machine scale sets in Azure?
As companies transition to the cloud, knowing how to deploy multiple virtual machines will continue to be useful as you add flexibility and customization to your deployments, and especially as you think about topics like disaster recovery and high availability. Over time, I believe that we’ll turn to more and more serverless, which is what I’m working on now. I’m currently looking for new solutions for my n-tier applications, and I may potentially work with App Service or Service Fabric, etc.
The cloud is our future, and making it “normal” and easy to use and apply is our mission. I hope you’ll continue learning with me! Check out my previous post in this series on Microsoft Azure: Getting started with Azure.