Skip to content

Azure VM

Disk types

VM will use 3 disks; of which 2 comes by default

  • OS disk: The comes with a VM and store OS files. Its C: drive in windows and /dev/sda for Unix-like systems.
  • Temporary disks: They also come by default and store non-persistent data like swap and page files. During a planned maintenance event, redeployment, or host change, the data stored in the temporary disk will be erased. Data will be available during normal reboots, though.

    Any data on the drive should not be critical to you as it is prone to loss. In Windows, the temporary disk will be labeled as the D: drive, and in Linux, the disk will be labeled as /dev/sdb

  • Data disk: These are additional disks for persistentstores like data files. These disks are VHDs (Virtual Hard Disks). They are page blobs in the blob service.

    These disks can be labeled with any letter in Windows, and in Linux data disks are labeled from /dev/sdc onward

(Un)/managed disks

Microsoft has two offerings in the case of storage disks

  1. Managed disk: An ARM managed resources with Azure managed Storage Accounts. Since you don’t manage the storage account, the storage account limits don’t apply.
  2. Unmanaged disk: In Unmanaged Disk storage, you must create a storage account in resources to hold the disks (VHD files) for your Virtual Machines.

Custom data

Why do we need it?

You might need to inject a script or other metadata into a Microsoft Azure virtual machine (VM) at provisioning time. In other clouds, this concept is often called user data. Microsoft Azure has a similar feature called custom data.

Custom data is made available to the VM during the first startup or setup, which is called provisioning. Provisioning is the process where VM creation parameters (for example, hostname, username, password, certificates, custom data, and keys) are made available to the VM. A provisioning agent, such as the Linux Agent or cloud-init, processes those parameters.

Custom data is sent to the VM along with the other provisioning configuration information such as the new hostname, username, password, certificates, and keys, etc. This data is passed to the Azure API as base64-encoded data. On Windows, this data ends up in %SYSTEMDRIVE%\AzureData\CustomData.bin as a binary file. On Linux, this data is passed to the VM via the ovf-env.xml file, which is copied to the /var/lib/waagent directory during provisioning.

How to pass data

To use custom data, you must Base64-encode the contents before passing the data to the API--unless you're using a CLI tool that does the conversion for you, such as the Azure CLI. The size can't exceed 64 KB. In the CLI, you can pass your custom data as a file, as the following example shows. The file will be converted to Base64.

az vm create \
    --resource-group myResourceGroup \
    --name centos74 \
    --image OpenLogic:CentOS-CI:7-CI:latest \
    --custom-data cloud-init.txt \
    --generate-ssh-keys

Proximity Placement groups

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.

Why to use proximity placement groups?

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.

How to use placement group?

A proximity placement group is a resource in Azure. You need to create one before using it with other resources. Once created, it could be used with virtual machines, availability sets, or virtual machine scale sets. You specify a proximity placement group when creating compute resources providing the proximity placement group ID.

How to move existing resources?

You can also move an existing resource into a proximity placement group. When moving a resource into a proximity placement group, you should stop (deallocate) the asset first since it will be redeployed potentially into a different data center in the region to satisfy the co-location constraint.

Cloud Init

Tldr

By default, this agent will process custom data. It accepts multiple formats of custom data, such as cloud-init configuration and scripts.

Similar to the Linux Agent, if errors happen during the execution of the configuration processing or scripts when cloud-init is processing the custom data, that's not a fatal provisioning failure. You'll need to create a notification path to alert you of the completion state of the script.

Currently, only the Ubuntu images in the Microsoft Azure Gallery have cloud-init preinstalled and configured to act on the custom data sent during provisioning. This means that for Ubuntu you can use custom data to provision a VM using a cloud-init configuration file, or just simply send a script that will be executed by cloud-init during provisioning.

HA solutions in VM

Various HA solutions are:

  1. VMSS
  2. Availability Set
  3. Availability Zone

VMSS (Scale Sets)

Azure Virtual Machine Scale Sets (VMSS) provide the management capabilities for applications that run across many VMs, automatic scaling of resources, and load balancing of traffic. With scale sets, you create a virtual machine configuration model, automatically add or remove additional instances based on CPU or memory load, and automatically upgrade to the latest OS version

Why to use VMSS?

  • With scale sets, all VM instances are created from the same base OS image and configuration. This approach lets you easily manage hundreds of VMs without extra configuration tasks or network management.
  • Scale sets are used to run multiple instances of your application. If one of these VM instances has a problem, customers continue to access your application through one of the other VM instances with minimal interruption.
  • Scale sets are backed with Azure load balancer for auto-scaling

How many VMs can I have in a scale set?

A scale set can have 0 to 1,000 virtual machines (VMs) based on platform images or 0 to 600 VMs based on custom images.

Availability Set

In short, an availability set is a logical grouping of the VMs hosting our application. Since there are multiple instances, you are eliminating the Single Point Of Failure (SPOF)

Availability set consists of

  1. Fault domains (FD)
  2. Update domain (UD)

How many FD and UD per set?

Every virtual machine that you create will be associated with a UD and FD. You can configure up to 3 FDs and 20 UDs in an availability set.

Fault domain (FD)

Fault domains represent a set of virtual machines that share a common network switch, power, and air conditioning. FDs can be configured up to a maximum of 3, and this is the default value while setting up availability sets.

They vary by region

The number of managed disk fault domains varies by region - either 2 or 3 managed disk fault domains per region.

Update domain (UD)

UDs represent a group of VMs and the underlying host that can be updated and rebooted at the same time. This will ensure that only one UD is rebooted at a time during planned maintenance events such as patching, firmware updates, etc.

Updating VMs in UD

The default number of UDs is 5, and if you are creating more than 5 VMs, the 6th VM will be placed on the 1st UD, the 7th will be on the 2nd, and so 4th depending upon the number of instances. While a UD is getting rebooted, it’s given 30 minutes to recover before the maintenance task is started on a different domain

AS vs AZ

Why do we need AS in addition to AZ?

An availability set avoids service downtime caused by hardware failure or planned maintenance. However, the protection offered is limited to the datacenter level. What if the entire datacenter is unavailable due to a power outage, natural disaster, or any other reasons? Since the datacenter is down, your workloads will not be available and that is why we need AZ

You can use AS and AZ at the same time while creating a VM.

Availability Zone (for HA)

Within Azure regions, you have unique physical locations named zones. Each zone comprises one or more datacenters. Also, each zone has independent cooling, power, and networking. As these zones are physically isolated and located in different parts of the region, you can deploy our applications to availability zones to protect from datacenter failures.

Azure availability zones are connected by a high-performance network with a round-trip latency of less than 2ms. They help your data stay synchronized and accessible when things go wrong.

In case of AZ failure

AZs are designed so that if one zone is affected, regional services, capacity, and high availability are supported by the remaining two zones.

Regions

In Azure, every region comprises a set of datacenters that are interconnected with a regional low-latency network

Auto-scaling

VMSS

When you have many VMs that run your application, it’s important to maintain a consistent configuration across your environment. For the reliable performance of your application, the VM size, disk configuration, and application installs should match across all VMs.

Virtual Machines Scale Sets provide a logical grouping of platform-managed virtual machines. With scale sets, you create a virtual machine configuration model, automatically add or remove additional instances based on CPU or memory load, and automatically upgrade to the latest OS version.

We can set scale-out (increase VM count by 1) and scale-in (decrease VM count by 1 for example) configuration in VMSS. Also, the scale-in policy can be defined as oldest VM or newest VM, or by instance id, etc to make sure which VM gets deleted when the load decreases.

Flexible

With Flexible orchestration, Azure provides a unified experience across the Azure VM ecosystem. Flexible orchestration offers high availability guarantees (up to 1000 VMs) by spreading VMs across fault domains in a region or within an Availability Zone. This enables you to scale out your application while maintaining fault domain isolation that is essential to run quorum-based or stateful workloads

Uniform

With uniform orchestration, virtual machine scale sets use a virtual machine profile or template to scale up to desired capacity. While there is some ability to manage or customize individual virtual machine instances, uniform uses identical VM instances.

Automate VM deployment

This can be done using IaC (Infra as Code) - ARM templates: We can download a template from a running VM - Terraform scripts - Bicep

We can use the concept of Golden Image for this where A golden image is a template for a virtual machine, virtual desktop, server, or hard disk drive. Golden images are also known as ghost images, clones, master images, or base images. To create a golden image, an administrator first sets up the computing environment with the exact specifications needed and then saves the disk image as a pattern for future copies.

Azure Bastion (Jump box)

Hardening the jumpbox VM and keeping it away from vulnerabilities are always tedious tasks for the administrator. Azure offers a life-saver service called Azure Bastion to solve this problem.

Tldr

With Azure Bastion, you can connect to Azure virtual machines without the need to have public IP addresses. The catch here is Azure Bastion, which is a PaaS solution; this means you don’t have to worry about hardening the infrastructure, as this will be handled by Microsoft Azure

  1. The Bastion host is deployed to the virtual network in a separate subnet.
  2. The user connects to the Azure portal using any HTML5 browser.
  3. The user navigates to the Azure virtual machine to RDP/SSH.
  4. Connect Integration - Single-click RDP/SSH session inside the browser
  5. No public IP is required on the Azure VM

Some useful tips on bastion host

  • It's a fully managed PaaS in Azure that provides RDP/SSH connectivity over TLS/SSL
  • It makes sure that no public IP is exposed.
  • The VMs does not need to have a public IP. The Bastion service will open the RDP/SSH session/connection to your virtual machine over the private IP of your virtual machine, within your virtual network.
  • NSG is not needed because the bastion is hardened internally (they are optional)
  • It is deployed per VNET, earlier it was deployed for each VM and now the process is made more streamlined by Microsoft. Bastion provides secure RDP and SSH connectivity to all the VMs in the virtual network in which it is provisioned
  • It only supports IPV4 addresses
  • There is a separate bastion host subnet to host the jump box.
  • There is a concurrent connection limit with the bastion host (25 for RDP and 50 for SSH)
  • The minimum AzureBastionSubnet size is /26 or larger (/25, /24, etc.)
  • Bastion connectivity to Azure Virtual Desktop (WVD) isn't supported.

VM Extensions

The post-deployment configuration and automation tasks on Azure VMs can be accomplished using small applications that are called vm extensions. Two main extensions are: CSE and DSC

CSE

Custom Script Extension for Linux (CSE): It is used to automatically invoke scripts and run them on virtual machines post-deployment.

DSC

Desired State Configuration(DSC) : In the case of CSE, you cannot deal with complex installation procedures such as reboots. Desired State Configuration helps you overcome this crisis and define a state for your virtual machines instead of writing scripts.

You can define the state of a machine and enforce the state using the DSC extension handler. You could store these configuration files in Azure Storage, in internal storage, or even in source control. The handler is responsible for pulling the configuration and implementing the desired state on the virtual machine. Even if there are installations that require reboots, DSC will continue the execution of the remaining scripts after reboot

Spot instance

These are low-priority VMs that are allocated from Azure’s excess capacity in the region. Using spot instances can reduce the cost of instances rather than running them as regular instances.

Windows Setup Scripts

Setupcomplete.cmd and ErrorHandler.cmd are custom scripts that run during or after the Windows Setup process. They can be used to install applications or run other tasks by using cscript/wscript scripts.

  • %WINDIR%\Setup\Scripts\SetupComplete.cmd: This script runs with local system permissions and starts immediately after the user sees the desktop.
  • %WINDIR%\Setup\Scripts\ErrorHandler.cmd: This script runs automatically when Setup encounters a fatal error. It runs with local system permission.

Notes

  • For a Windows VM, it can be up to 15 characters, and Linux VMs can support up to 64 characters.
  • VM name can’t be changed once the VM is deployed, except re-deployment.
  • If you shut down the VM from the operating system—for example, by clicking the Windows button and select Shutdown, then you will be charged for the VM as the hardware allocated is not released.
  • You can use your existing licenses purchased from Software Assurance to cut down this cost. This reduction method is called Azure Hybrid Benefit (AHUB). AHUB can be used for Windows, Linux (RHEL and SUSE), and SQL virtual machine licenses.
  • You can connect to Windows machines using two options, namely, Remote Desktop Protocol (RDP) for GUI and Windows Remote Management (WinRM) for CLI
  • The public key will end with the extension .pub, and the private key will not have any extension.
  • ssh to vm using ssh -i <path-to-private-key> username@publicIP
  • An availability set is free of cost, and you pay only for the instances that you are deploying.
  • Uploads a virtual hard disk from an on-premises machine to Azure (managed disk or blob) using Add-AzVhd
  • If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client.]
  • The Set-AzureStaticVNetIP cmdlet sets the static virtual network (VNet) IP address information for a virtual machine object.
  • New-AzureADMSInvitation is used to invite a new external user to your directory.

Was this page helpful?
-->