Azure VM

Instance Types

#

• D series: General Purpose; S for SSD
• M / E series: Memory optimized
• F series: Compute optimized
• H series: HPC
• L series: Disk optimized
• N series: GPU (NVIDIA)

DNS Formats

#

• internal: <vm-name>.internal.cloudapp.azure.com
• public: <vm-name>.<region>.cloudapp.azure.com

SetupComplete.cmd

#

• Runs once during the Windows out-of-box experience (OOBE) setup
• Used for one-time configuration tasks after Windows installation
• Similar to cloud-init in Linux environments
• Location: %WINDIR%\Setup\Scripts\SetupComplete.cmd
• Runs with SYSTEM privileges

GPO - Logon Scripts: Runs every time a user logs into the computer (User Context) GPO - Start Scripts: Runs every time the computer starts (SYSTEM privileges)

When deciding between these options:

• If the task needs to be performed only once after installation, use SetupComplete.cmd
• For recurring tasks or configurations that need to be enforced regularly, use GPO scripts
• SetupComplete.cmd is useful in imaging and deployment situation where we want to perform actions immediately after installation

Desired State Configuration

#

It is similar to Chef for Configuration Management.

We can enable DSC at “Extension” section

When setup DSC, VM need to be in running state

For example,

It can be used for configuration management (install Nginx) on Windows

Save InstallNginx.ps1

Configuration InstallNginx {
    Node "localhost" {
        Package Nginx {
            Ensure = "Present"
            Name = "nginx"
            Source = "https://nginx.org/packages/windows/"
        }
    }
}

Update InstallNginx.ps1.zip to storage account

Add DSC Extension to run the script

Set-AzVMDscExtension -ResourceGroupName "MyResourceGroup" `
                     -VMName "MyVM" `
                     -ArchiveBlobName "InstallNginx.ps1.zip" `
                     -ArchiveStorageAccountName "mystorageaccount" `
                     -ConfigurationName "InstallNginx" `
                     -Version "2.76"

Although we can Azure Custom Script Extension to install Nginx as well, DSC is more suitable for maintaining a desired configuration state, while Custom Script Extension is better for one-time script execution.

Redeploy

#

Any data stored on the temporary disk will be lost when the VM is redeployed, resized / restarted.

On Windows, the temporary disk is assigned to drive D:\`` On Linux, it's located at /dev/sdb1`

Import VHDx to Azure

#

• Convert the VHDx to VHD before importing it
• Ensure the VHD is in fixed-size format, not dynamically expanding.

Convert VDHX to VHD

Convert-VHD -Path "C:\Path\To\Your\DiskFile.vhdx" -DestinationPath "C:\Path\To\Output\DiskFile.vhd" -VHDType Fixed

Verify the conversion

Get-VHD -Path "C:\Path\To\Output\DiskFile.vhd"

Import to Azure

Add-AzVhd -ResourceGroupName "MyResourceGroup" -LocalFilePath "C:\Path\To\Output\DiskFile.vhd" -Destination "https://mystorageaccount.blob.core.windows.net/vhds/DiskFile.vhd"

Disk Operations

#

Data Disks:

• Can be detached from a running VM without stopping it.

OS disk

• Requires the VM to be stopped and deallocated to make changes.

Host Groups

#

• Is a collection of dedicated hosts
• All hosts in a group must be of the same size (e.g., DSv3, ESv3)
• Located within a single Availability Zone in a region

Dedicated Hosts:

• Physical hosts in Azure datacenters dedicated to us (rent the whole physical server!)

ScaleSet

#

There are two mode for managing VMSS:

• Orchestration: VMs are managed automatically by Azure
• VM: we need to manually add or remove VM instances

Scaling Mechanisms

#

It supports both manual and automatic scaling based on defined rules and metrics.

There are 2 key concepts about the scaling:

• Duration: The period over which the metric is observed.
• Cooldown: The period to wait after a scale-out or scale-in action before another scaling action can occur

For Example, we have scaling rule:

• If CPU > 70% for 5 minutes, scale up by 1 instance.
• Minimum instances: 1
• Maximum instances: 3
• Default instances: 1
• Cooldown period: 5 minutes

CPU > 70% lasted for 15 minutes

• 5min: Scale up by 1 instance (total: 2)
• 5-10min: 5 min cooldown period
• 10min: Scale up by 1 instance (total: 3)
• 10-15min: 5 min cooldown period
• 15min: No scale up happened as Max instances is reach

Host Groups

#

We can create VMSS using host group

• The scale set can only exist in a single AZ. As all hosts in a host group are in the same AZ
• To achieve HA across multiple AZs, we need to create multiple scale sets
• Each scale set would use a host group in a different AZ
• We can use Azure Load Balancer or an Application Gateway to distribute traffic across these multiple scale sets

Planned Upgrade

#

• No more than 20% of the scale set is upgrading at any time.
• For a scale set with 10 VMs, a maximum of 2 VMs are upgraded at a time, leaving 8 VMs operational.

Placement Group

#

A placement group must be in the same region (location) as the scale set it’s associated with.

Availability Set

#

Availability sets:

• Provide high availability within a single data center
• Use fault domains and update domains to distribute VMs across different physical hardware
• Protect against hardware failures and planned maintenance events

Availability zones:

• Provide HA across multiple data centers within a region
• Each zone is a separate physical location with independent power, cooling, and networking
• Protect against data center-level failures.

Fault and Update Domains

#

• Fault Domain is for unplanned outage
• Update Domain is for planned outage

Limitation:

• When Fault Domains is set to 1, Update Domains can only be 1
• If Fault Domains is > 2, Update Domains can be up to 20

For example:

• Fault Domain: 2
• Update Domain: 10
• Total VMs: 11

Max no of unavailable VMs during planned maintenance is 2 VMs (as 1: 2 VMs)

Max no of unavailable VMs during unplanned maintenance is 6 VMs (as 1: 6 VMs)

Resizing Availability Set

#

• Stop and deallocate all VMs in the availability set
• Resize the availability set
• Restart the VMs