Azure Virtual Machines & Beyond

Starting from the basics……

What is a Virtual Machine?

A virtual machine (VM) is a virtual environment that works like a computer within a computer. It is called virtual because it is implemented in software on top of a real hardware platform and operating system.

A virtual machine (VM) is a virtual environment that functions as a virtual computer system with its own CPU, memory, network interface, and storage, created on a physical hardware system. A Software called a hypervisor separates the machine’s resources from the hardware and provisions them appropriately so they can be used by the Virtual Machine.

Difference between Virtual Machine and Azure Virtual Machine

Even though both of them are Virtual Machines it is just that Azure Virtual Machine is a VM provisioned on the resources (CPU, Memory, Disk) provided by Azure Cloud enhancing your productivity and making the workloads highly scalable which can be scaled on the fly, optimizing the cost, enhancing the security and much more.

Whereas the other one is usually provisioned on-premises or could also be on a local/personal system, increasing the maintenance work, making it less scalable, and thereby impacting productivity.

Following are the topics that would be covered in this blog

• Creating Virtual Machines
• State of VM & Temporary Disks
• Encryption of Disks
• Types of Disks
• Availability Sets & Availability Zones
• Custom Script Extensions, Cloud-Init & Run Services
• Confidential Computing & Azure Dedicated Host
• Virtual Machine Scale Set
• Proximity placement

Creating Azure Virtual Machine

Following are the steps involved in provisioning a Virtual Machine

1. Create an Azure Cloud account
2. Under Services, select Virtual machines.
3. On the Virtual machines page, select Create and then Virtual machine.
4. In the create a virtual machine page under the Basics tab, inside Project details, make sure the correct subscription is selected.
5. And then choose to create a new resource group or select an existing resource group from the dropdown.
6. Provide the credentials
7. Further, select an image (OS), size (CPU and Memory capacity), and then the disks.
8. Once these steps are followed the resource can be reviewed and provisioned.

For Reference

The core components of the VM include

OS disks

Data disks

Public IP

Virtual Network & Subnet

State of VM & Temporary Disks

The state of a Virtual Machine refers to either

• Started/Running or
• Stopped/Deallocated

Apart from the OS and data disks that are attached to the Virtual Machines, a temporary disk is also attached to the VM that varies according to the size of the VM.

As the disk is temporary unlike the Data and OS disks which are permanent the data in it is also of the same type and depends on the state of the VM, when the machine is in the running state or is restarted the data in the temporary VM remains as it is but when the state of the VM changes to stopped/deallocated the data is erased from the temporary disk attached.

One more component of the Virtual Machine which is the Public IP address and one amongst the 2 types offered varies according to the state of the VM. The 2 types are as follows -

• Dynamic — This type of IP changes after restart /deallocation of the VM
• Static — This type of IP remains static (does not change) even after the VM is restarted or stopped

Encryption of Disks

Azure Disk Encryption helps protect and safeguard your data to meet your organizational security and compliance commitments. This is amongst the security services offered by the Azure cloud for securing the data in the disks.

The disks encryption can be performed on managed disks for both OS and data disks usually by default the Server Side Encryption with Platform managed keys (SSE with PMK) but there is also an option to use customer-managed keys using Key Vault.

For Encrypting the disks after provisioning needs to be detached or the VM to which it has been attached should be in the deallocated state.

Following are the steps included for encrypting the disk with customer managed keys.

• Set up your Azure Key Vault
• Add an Azure RBAC role to the Key Vault
• Set up your disk encryption set

Types of Disks

There are 2 different types of disks categorization in the disks that are offered by Azure they are as follows

• Managed disks
• Unmanaged disks

The key differences between the two are

In unmanaged disks, the underlying infrastructure is the storage account, and to ensure high availability the user needs to create a storage account accordingly. Whereas in managed disks it is managed by Microsoft and is replicated in multiple places providing high availability.

For creating different disks such as Standard HDD or Premium SSD as an unmanaged disk the storage accounts should be created accordingly which works for Gen1 Machines.

In unmanaged disks, you only pay for what you use unlike in managed disks you are charged for the complete disk which has been allocated.

For reference

Availability Sets & Availability Zones

Availability Sets takes the virtual machine and configures multiple copies of it. Each copy is isolated within a separate physical server, compute rack, storage units and network switches within a single datacentre within an Azure Region.

When you create your virtual machine you can specify the Availability Set, you can’t change it or move it in or out of an Availability Set after creation. If you wanted to make changes you would need to start again and recreate the virtual machine. And Availability Sets only apply to virtual machines, they can’t be used for any other type of resource within Azure.

Using an Availability Set takes your acceptable downtime to around 22minutes a month. Which is a vast improvement over the single virtual machine deployment.

Each underpinning physical resource will be tagged to a specific fault domain in the Azure back-end. Each fault domain might share the same rack, network, and power source. When you add more than one VM to the availability set, the Azure platform ensures that VMs are spread across different fault domain.

The fault domain can protect your applications in the following scenarios.

• unplanned hardware maintenance.
• unexpected downtime.

Like the fault domain, each physical server is tagged with specific update domains. Azure performs maintenance on only one specific update domain at the time. This could be updating the host machines with the latest patches or fixing the vulnerability.

You get the default fault domain as 5 and it can be increased up to 20.

• Virtual machines get update domains automatically once they are put inside the availability set.
• All virtual machines within that update domain will reboot together.
• Only one update domain would be updated at the time.

The next level of availability for your virtual machines within Azure is Availability Zones. With Availability Zones utilized your acceptable downtime a month moves to less than 5 minutes as you’ve got a 99.99% SLA.

With Availability Zones, you are starting to use zone-aware services. Your workload will be spread out across the different zones that make up an Azure region.

An Azure region is made up of multiple datacenters and each zone is made up of one or more datacenters. Each datacenter is equipped with independent power, cooling and networking.

Custom Script Extensions, Cloud-Init & Run Services

The Custom Script Extension downloads and runs scripts on Azure virtual machines (VMs). This extension is useful for post-deployment configuration, software installation, or any other configuration or management task. You can download scripts from Azure Storage or GitHub, or provide them to the Azure portal at extension runtime.

The custom script extension has a time limit of 90 minutes post which the tasks specified fail. Also, there shouldn’t be any inclusion of reboot command statements as it will cause problems with other extensions that are being installed, and the extension won’t continue after the reboot.

Cloud-init is a widely used approach to customize a Linux VM as it boots for the first time. You can use cloud-init to install packages and write files, or to configure users and security. Because cloud-init is called during the initial boot process, there are no additional steps or required agents to apply your configuration.

it also works across distributions. For example, you don’t use apt-get install or yum install to install a package. Instead, you can define a list of packages to install. cloud-init automatically uses the native package management tool for the distro you select.

Run service for Azure VMs is used to execute commands. After you choose the command, select Run to run the script. After the script finishes, it returns the output and any errors in the output window.

Confidential Computing & Azure Dedicated Host

Azure Confidential Computing is a feature that allows you to isolate sensitive data when it is being processed in the cloud.

This feature is available for your virtual machines. In Confidential computing , a part of the CPU’s hardware is reserved for the portion of code and data in your application. This portion is known as an enclave.

There is a special series of virtual machines which support confidential computing. This is the DCsv2-Series

Azure Dedicated Hosts service provides physical servers to host virtual machines. The physical server is dedicate to the Azure subscription.

The benefits of Azure Dedicated Hosts is that no other virtual machines from any other customers would be placed on the physical server. You can also control the maintenance events that are initiated on the Azure platform.

Here the users are charged per dedicated host. This is irrespective of the number of virtual machines running on the physical server.

Virtual Machine Scale Set

Azure virtual machine scale sets let you create and manage a group of load balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets provide the following key benefits:

• Easy to create and manage multiple VMs
• Provides high availability and application resiliency by distributing VMs across availability zones or fault domains
• Allows your application to automatically scale as resource demand changes
• Works at large-scale
• Scale sets support up to 1,000 VM instances for standard marketplace images and custom images through the Azure Compute Gallery (formerly known as Shared Image Gallery). If you create a scale set using a managed image, the limit is 600 VM instances.
• For the best performance with production workloads, it is recommended to use Azure Managed Disks.

Proximity placement

Placing VMs in a single region reduces the physical distance between the instances. Placing them within a single availability zone will also bring them physically closer together. However, as the Azure footprint grows, a single availability zone may span multiple physical data centers, which may result in a network latency impacting your application.

To get VMs as close as possible, achieving the lowest possible latency, you should deploy them within a proximity placement group.

A proximity placement group is a logical grouping used to make sure that Azure compute resources are physically located close to each other. Proximity placement groups are useful for workloads where low latency is a requirement.

• Low latency between stand-alone VMs.
• Low Latency between VMs in a single availability set or a virtual machine scale set.
• Low latency between stand-alone VMs, VMs in multiple Availability Sets, or multiple scale sets. You can have multiple compute resources in a single placement group to bring together a multi-tiered application.
• Low latency between multiple application tiers using different hardware types. For example, running the backend using M-series in an availability set and the front end on a D-series instance, in a scale set, in a single proximity placement group.

References

https://docs.microsoft.com/en-us/azure/virtual-machines/

Azure portal - Enable customer-managed keys with SSE - managed disks - Azure Virtual Machines

Thanks for reading !

You can connect with me at https://www.linkedin.com/in/mubingirach/