Azure Virtual Machine

Azure Availability Set

  • An availability set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability.

  • It recommended that two or more VMs are created within an availability set to provide for a highly available application and to meet the 99.95% Azure SLA.

  • There is no cost for the Availability Set itself, you only pay for each VM instance that you create.

  • Availability sets offer improved VM to VM latencies compared to availability zones, since VMs in an availability set are allocated in closer proximity. Availability sets have fault isolation for many possible failures, minimizing single points of failure, and offering high availability. Availability sets are still susceptible to certain shared infrastructure failures, like datacenter network failures, which can affect multiple fault domains

  • For more reliability than availability sets offer, use availability zones. Availability zones offer the highest reliability since each VM is deployed in multiple datacenters, protecting you from loss of either power, networking, or cooling in an individual datacenter. If your highest priority is the best reliability for your workload, replicate your VMs across multiple availability zones.

  • Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform. Each availability set can be configured with up to 3 fault domains and 20 update domains.

  • Update domains: groups of virtual machines and underlying physical hardware that can be rebooted at the same time

  • Fault domains: group of virtual machines that share a common power source and network switch

  • Retrieve list of fault domains per region:

az vm list-skus --resource-type availabilitySets --query '[?name==`Aligned`].{Location:locationInfo[0].location, MaximumFaultDomainCount:capabilities[0].value}' -o Table
  • A shared fault domain might be caused by the completing following sequence when you deployed the VMs:

    • Deploy the first VM.

    • Stop/deallocate the first VM.

    • Deploy the second VM.

  • To avoid this issue, don't stop/deallocate VMs between deployments.

  • https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-overview

Azure Availability Zone

  • Many Azure regions provide availability zones, which are separated groups of datacenters within a region. Availability zones are close enough to have low-latency connections to other availability zones. They're connected by a high-performance network with a round-trip latency of less than 2ms. However, availability zones are far enough apart to reduce the likelihood that more than one will be affected by local outages or weather. Availability zones have independent power, cooling, and networking infrastructure. They're designed so that if one zone experiences an outage, then regional services, capacity, and high availability are supported by the remaining zones. They help your data stay synchronized and accessible when things go wrong

  • https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview?tabs=azure-cli

Zonal and zone-redundant services

  • Zonal resources are pinned to a specific availability zone.

    • You can combine multiple zonal deployments across different zones to meet high reliability requirements.

    • You're responsible for managing data replication and distributing requests across zones. If an outage occurs in a single availability zone, you're responsible for failover to another availability zone.

  • Zone-redundant resources are spread across multiple availability zones.

    • Microsoft manages spreading requests across zones and the replication of data across zones.

    • If an outage occurs in a single availability zone, Microsoft manages failover automatically

Disk Type

Disk Type Comparison

Ultra disk
Premium SSD v2
Premium SSD
Standard SSD
Standard HDD

Disk type

SSD

SSD

SSD

SSD

HDD

Scenario

IO-intensive workloads such as SAP HANA, top tier databases (for example, SQL, Oracle), and other transaction-heavy workloads.

Production and performance-sensitive workloads that consistently require low latency and high IOPS and throughput

Production and performance sensitive workloads

Web servers, lightly used enterprise applications and dev/test

Backup, non-critical, infrequent access

Max disk size

65,536 GiB

65,536 GiB

32,767 GiB

32,767 GiB

32,767 GiB

Max throughput

4,000 MB/s

1,200 MB/s

900 MB/s

750 MB/s

500 MB/s

Max IOPS

160,000

80,000

20,000

6,000

2,000, 3,000*

Usable as OS Disk?

No

No

Yes

Yes

Yes

  • https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types

Disk Redundancy Options

Locally redundant storage for managed disks

  • Locally redundant storage (LRS) replicates your data three times within a single data center in the selected region.

  • LRS protects your data against server rack and drive failures. LRS disks provide at least 99.999999999% (11 9's) of durability over a given year.

  • To protect an LRS disk from a zonal failure like a natural disaster or other issues, take the following steps:

    • Use applications that can synchronously write data to two zones, and automatically failover to another zone during a disaster.

      • An example would be SQL Server Always On.

    • Take frequent backups of LRS disks with ZRS snapshots.

    • Enable cross-zone disaster recovery for LRS disks via Azure Site Recovery. However, cross-zone disaster recovery doesn't provide zero Recovery Point Objective (RPO).

If your workflow doesn't support application-level synchronous writes across zones, or your application must meet zero RPO, then ZRS disks would ideal.

Zone-redundant storage for managed disks

  • Zone-redundant storage (ZRS) synchronously replicates your Azure managed disk across three Azure availability zones in the region you select. Each availability zone is a separate physical location with independent power, cooling, and networking. ZRS disks provide at least 99.9999999999% (12 9's) of durability over a given year.

  • A ZRS disk lets you recover from failures in availability zones. If a zone went down, a ZRS disk can be attached to a virtual machine (VM) in a different zone. ZRS disks can also be shared between VMs for improved availability with clustered or distributed applications like SQL FCI, SAP ASCS/SCS, or GFS2. A shared ZRS disk can be attached to primary and secondary VMs in different zones to take advantage of both ZRS and availability zones. If your primary zone fails, you can quickly fail over to the secondary VM using SCSI persistent reservation.

  • For more information on ZRS disks, see Zone Redundant Storage (ZRS) option for Azure Disks for high availability: https://www.youtube.com/watch?v=RSHmhmdHXcY&feature=youtu.be

  • https://learn.microsoft.com/en-us/azure/virtual-machines/disks-redundancy

Run Command

  • Run Command uses the virtual machine (VM) agent to run scripts within an Azure Windows or Linux VM for general machine or application management

  • https://docs.microsoft.com/en-us/azure/virtual-machines/run-command-overview

Monitor VM

  • Requirement: have required resource enabled, have log analytics workspace

  • Search Subscriptions > Click Subscription > Resource Providers, select the following

    • Microsoft.AlertsManagement

    • microsoft.insights

  • Virtual Machine > Diagnostic settings

Image

VM Image Builder

Create a legacy managed image of a generalized VM in Azure

  • https://learn.microsoft.com/en-us/azure/virtual-machines/capture-image-resource

Log Analytics Workspace

  • Agent configuration: add performance counter

Automation Accounts

  • Update management: to update VM automatically, also requires Log Analytics workspace

  • Runbook Gallery: different runbooks>>

Manual installation of monitoring agent

  • On Linux: sudo snap install stress-ng

Converting OVA to VHD file

  • Extract the ova file to get vmdk

  • Use qemu-img to convert vmdk to vhd

Last updated