Azure Managed Disks

Disk roles

In Azure, disks play three primary roles:

Operating system (OS) disk An OS disk is created by default for every VM you create in Azure. This disk contains the OS running on the VM as well as the boot volume. The OS disk supports partitioning with a master boot record (MBR) and GUID partition table (GPT) depending on the OS requirement. By default, most operating systems use partitioning with MBR, which limits the OS disk capacity to 2 TB. However, you can increase this to 4 TB by converting the disk from MBR to GPT.
Temporary disk Microsoft provides a temporary disk as a non-persistent disk for specific VM models in Azure. When selecting the VM size in Azure, you can see the size of the temporary disk provided with that VM type. Any data you store on the temporary disk should be data that you are willing to lose, such as page files, swap files, or temporary logs. Each time a VM undergoes a forced restart, maintenance, or a redeployment, data on the temporary disk is erased. The VM can retain data stored on these disks only during standard reboot operations. Temporary disks are not encrypted by default, although you can enable encryption if needed. These disks are mapped as D: in Windows VMs and /dev/sdb in Linux-based VMs.
Data disk Data disks are optional, and you can use them based on your workload requirements—for example, separating database installation files from data and log files, which can be stored on their own or individual data disks. As mentioned, OS disks have a maximum capacity of 4 TB, so any data-storage requirements that exceed that would require you to use data disks. The maximum disk capacity for a single data disk is currently 32,767 gigabytes (GB) for Standard HDD, Standard SSD, and Premium SSD disks. However, Ultra disks can be scaled up to 65,536 GB. The number and type of data disks that you can use with a VM depends on the size and type of the VM. Be sure to consider this when selecting the size for your VM.

Disk types

Azure offers four types of disks:

Standard HDD disks
Standard SSD disks
Premium SSD disks
Ultra disks

Standard HDD disks

Standard HDD disks are suitable for workloads that are less critical and are not latency sensitive and for dev/test environments. These disks provide write latencies of less than 10 milliseconds (ms) and read latencies of less than 20 ms. Their performance varies depending on numerous factors, including IO size and workload pattern. Standard HDD disks are the least expensive (per gigabyte) disk option in Azure.

Standard SSD disks

Standard SSD disks are a great alternative for customers that want better performance, scalability, availability, and reliability than is possible with Standard HDD disks. Standard SSD disks are a great choice for low-intensity workloads that require consistent performance, such as web servers, low-usage business applications, and low IOPS applications. Standard SSD disks of 512 GB or more support credit-based bursting, making them ideal for applications that require a burst of performance only on rare occasions. All Azure VMs support Standard SSD disks.

Premium SSD disks

Premium SSD disks offer the second highest level of disk performance, with single-digit millisecond latencies, targeted IOPS, and defined throughput 99.9% of the time. They are suitable for high-intensity workloads, such as production applications and databases.

Premium SSD disks come in different sizes, and the level of IOPS support differs depending on the size of the Premium SSD disk. For example, P1 4 GB to P4 32 GB disks provide 120 IOPS, P10 128 GB disks provide 500 IOPS, while P80 32 TB disks provide 20,000 IOPS. Disk throughput and burst performance also increase as the capacity of the Premium SSD disks go up.

A few more features of Premium SSD disks are as follows:

Premium SSD disks support one-year reservations to help you save on costs. You can set reservations for disks 1 TB and larger.
Premium SSD disks support on-demand and credit-based bursting models. Bursting enables the Premium SSD to increase its performance in the short term to meet workload requirements.
Only specific Azure VM types support Premium SSD disks. When you select a VM type, Azure shows you which types of disks that VM type supports. Because Microsoft adds and removes VM SKUs on an ongoing basis, I have not listed the VM types here, because they may change by the time you read this.

Ultra disks

Ultra disks currently provide the highest level of performance in terms of IOPS and disk throughput, with sub-millisecond latency 99.99% of the time. This makes Ultra disks suitable for critical high-performance workloads such as SAP HANA, mission-critical databases, and transaction-heavy applications.

By default, each Ultra disk can be scaled up to 32 TB. However, you can contact Azure support to request an increase of up to 64 TB. In terms of IOPS, each Ultra disk supports a minimum of 300 IOPS per gibibyte (GiB) and currently maxes out at 160,000 IOPS per disk.

Ultra disks allow you to adjust IOPS and throughput performance during runtime. You are permitted four adjustments every 24 hours. Each adjustment can take up to one hour to take effect and requires sufficient performance bandwidth capacity to prevent failures.

At present, Ultra disks have numerous limitations. These include lack of support for the following:

Availability sets
Azure Dedicated Host
Disk snapshots
Azure Backup
Azure Site Recovery
Disk exports
VM image creation

In addition, Ultra disks cannot be used as OS disks. They can only be set up as data disks. For high-performance workloads that call for the use of an Ultra disk, you will want to set up the OS disk as a Premium SSD disk and leverage Ultra disks for all your workload data.

Managed disk creation walkthrough

The following sections step you through the process of creating a managed disk using the Azure portal, Azure PowerShell, and the Azure CLI.

Using Azure portal

To create a managed disk using the Azure portal, follow these steps:

Log in to the Azure portal, type disks in the search box, and select the Disks option in the list that appears. (See Figure 3-1.)
FIGURE 3-1 Searching for the Disks service in the Azure portal.
On the Disks page (see Figure 3-2), click Create.
FIGURE 3-2 Creating a new disk.
In the Basics tab of the Create a Managed Disk wizard (see Figure 3-3), enter the following information:
- Subscription Select the subscription in which you want to create the new managed disk.
- Resource Group Select an existing resource group in which to create the new managed disk or create a new one.
- Disk Name Enter a unique name for the managed disk.
- Region Select the Azure region where you want to host the managed disk.
- Availability Zone Select the availability zone you want to use or leave this option set to None (the default).
- Source Type If the disk will be created from source data, such as a snapshot, storage blob, another disk, etc., select the source type.
FIGURE 3.3 The Basics tab of the Create a Managed Disk wizard.
To create a disk that is a different redundancy level, type, size, or performance tier from the default (1,024 GiB Premium SSD LRS), click the Change Size link in the Size section of the wizard’s Basics tab.
In the Select a Disk Size dialog box, open the Disk SKU drop-down list and choose a disk type/redundancy level pairing. (See Figure 3-4.)
FIGURE 3-4 Choose a disk type and redundancy level.
NOTE
For more on redundancy levels for managed disks, see the section “Disk redundancy” later in this chapter.
Click a size option in the list to select it. Alternatively, use the Custom Disk Size (GiB) and Performance Tier drop-down lists to choose a custom size/tier pairing. Then click OK. (See Figure 3-5.)
FIGURE 3.5 Selecting a different disk size and performance tier.
Back in the Basics tab of the Create a Managed Disk wizard, click Next.
In the Encryption tab of the Create a Managed Disk wizard (see Figure 3-6), open the Key Management drop-down list and choose Platform-Managed Key, Customer-Managed Key, or Platform-Managed and Customer-Managed Keys. Then click Next.
FIGURE 3.6 The Encryption tab of the Create a Managed Disk wizard.
NOTE
To use customer-managed keys, you must first generate and store the keys in the Azure Key Vault service.
In the Networking tab of the Create a Managed Disk wizard (see Figure 3-7), in the Network Access section, leave the Enable Public Access from All Networks option button selected and click Next.
FIGURE 3.7 The Networking tab of the Create a Managed Disk wizard.
In the Advanced tab of the Create a Managed Disk wizard (see Figure 3-8), enter the following information and click Next:
- Enable Shared Disk If you want to use this managed disk as a shared disk, select the Yes Option button. Then use the Max Shares drop-down list to specify how many VMs will share the disk.
FIGURE 3.8 The Advanced tab of the Create a Managed Disk wizard.
NOTE
For more on shared disks, see the section “Shared disks” later in this chapter.
- On-Demand Bursting If you want this managed disk to be capable of on-demand bursting, select the Enable On-Demand Bursting check box.
NOTE
The Enable On-Demand Bursting check box is available only if your managed disk is 512 GB or more. This option is covered in more detail later in this chapter.
- Enable Data Access Authentication Mode Optionally, select this check box to enable data access authentication. When you enable data access authentication, you can limit who can download the disk to admins who are authorized using Azure AD and authenticated using an approved account.
In the Tags tab (see Figure 3-9), enter any tags you want to associate with the managed disk and click Next.
FIGURE 3.9 The Tags tab of the Create a Managed Disk wizard.
In the Review + Create tab (see Figure 3-10), review your settings, and click Create to create the managed disk.
FIGURE 3-10 The Review + Create tab of the Create a Managed Disk wizard.
After the managed disk is created, click Go to Resource to access its page. (See Figure 3-11.)

FIGURE 3.11 Managed disk deployment completion.

Using Azure Powershell

Use the following Azure PowerShell code to create a managed disk:

#Define variables
$resourceGroup = "RG01"
$location = "EastUS2"
$vm = "SourceVM"
$MgdDiskName = "ManagedDisk01"
 
#Create a disk config object – Change the disk redundancy as needed
$MgdDiskConfig = New-AzDiskConfig `
    -Location $location `
    -CreateOption Empty `
    -DiskSizeGB 64 `
    -EncryptionType EncryptionAtRestWithPlatformKey `
    -PublicNetworkAccess true `
    -Architecture X64 `
    -SkuName Standard_LRS/Premium_LRS/StandardSSD_LRS/UltraSSD_LRS/Premium_ZRS/
StandardSSD_ZRS
 
#Create Data Disk
$MgdDisk = New-AzDisk `
    -ResourceGroupName $resourceGroup `
    -DiskName $MgdDiskName `
    -Disk $mgddiskConfig
 
#Verify disk
Get-AzDisk `
    -ResourceGroupName $resourceGroup `
    -DiskName $MgdDiskName

#Optional - Attach disk to VM
$Azvm = Get-AzVM `
    -ResourceGroupName $resourceGroup `
    -Name $vm
 
$Azvm = Add-AzVMDataDisk `
    -VM $vm `
    -Name $MgdDiskName `
    -CreateOption Attach `
    -ManagedDiskId $MgdDisk.Id `
    -Lun 1
 
Update-AzVM `
    -ResourceGroupName $resourceGroup `
    -VM $Azvm

Using Azure CLI

Use the following code to create a managed disk in the Azure CLI:

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
MgdDiskName="ManagedDisk01"
 
#Create managed disk – Change the disk redundancy as needed
az disk create                        --resource-group $resourceGroup                        --name $MgdDiskName                        --size-gb 64       --architecture x64       --encryption-type EncryptionAtRestWithPlatformKey       --location $location       --public-network-access Enabled       --sku Premium_LRS/PremiumV2_LRS/Premium_ZRS/StandardSSD_LRS/StandardSSD_ZRS/
Standard_LRS/UltraSSD_LRS
 
#Verify disk
mgddisk=$(az disk show                        --name $MgdDiskName                        --resource-group $resourceGroup)
 
#Optional - Attach disk to VM
az vm disk attach                        --disks $mgddisk       --name $MgdDiskName       --resource-group $resourceGroup                        --vm-name $vm

Private Link integration

Private Link provides secure connectivity to Azure PaaS services and Azure hosted services from your networks over a private endpoint. A private endpoint is a network interface connected to the Azure PaaS service or Azure hosted service, such as Managed Disks, that is attached to an Azure virtual network. With Private Link and private endpoints, you can safely and securely transfer managed disk files between regions using a private connection on the Microsoft backbone network instead of the public internet. You can also import VHD files from an on-premises environment directly to an empty managed disk in Azure over a private connection. Time-restricted Shared Access Signature (SAS) URLs can provide access to the unused managed disks and snapshots for transfer.

Private Link integration walkthrough

The following sections step you through the process of creating a private endpoint and integrating Private Link with the managed disk using the Azure portal and the Azure CLI.

Using Azure portal

To create a private endpoint and integrate Private Link with a managed disk using the Azure portal, follow these steps:

Log in to the Azure portal, type disk accesses in the search box, and select the Disk Access option from the list that appears. (See Figure 3-12.)
FIGURE 3-12 Searching for disk accesses in the Azure portal.
On the Disk Access page, click Create Disk Access. (See Figure 3-13.)
FIGURE 3-13 Create disk access.
In the Basics tab of the Create a Disk Access wizard (see Figure 3-14), enter the following information:
- Subscription Select the subscription in which you want to create the disk access resource.
- Resource Group Select an existing resource group in which to create the disk access resource or create a new one.
- Name Enter a unique name for the disk access resource.
- Region Select the Azure region where you want to host the disk access resource.
FIGURE 3.14 The Basics tab of the Create a Disk Access wizard.
Before you continue with the Create a Disk Access wizard, you need to create the private endpoint. You’ll do that next.
At the bottom of the Basics tab, click Add.
In the Create a Private Endpoint dialog box (see Figure 3-15), enter the following information and click OK:
- Subscription Select the subscription you want to use to create the private endpoint.
- Resource Group Select an existing resource group in which to create the private endpoint or create a new one.
- Location Select the Azure region where you want to host the private endpoint.
- Name Enter a unique name for the private endpoint.
- Target Resource Select Disks.
- Virtual Network Select the virtual network on which to create the private endpoint.
- Subnet Select the subnet on which to create the private endpoint.
- Integrate with Private DNS Zone Select Yes to integrate with a private DNS zone or select No if you plan to create a DNS record in your own DNS servers or on the host files of the workloads VMs. In this case, select Yes.
- Private DNS Zone Select the private DNS zone with which you want to integrate the private endpoint. In this case, leave it set to the default, privatelink.blob.core.windows.net.
FIGURE 3.15 The Create Private Endpoint dialog box.
Click the Tags tab (see Figure 3-16), enter any tags you want to associate with the private endpoint, and click Next.
FIGURE 3.16 The Tags tab of the Create a Disk Access wizard.
In the Review + Create tab (see Figure 3-17), review your settings and click Create to create the private endpoint.
FIGURE 3-17 The Review + Create tab of the Create a Disk Access wizard.
After the private endpoint is created, click Go to Resource to access its page. (See Figure 3-18.)
FIGURE 3.18 Private endpoint deployment completion.
In the left pane of the page for the managed disk you created earlier, under Settings, click Networking.
On the managed disk’s Networking page (see Figure 3-19), perform the following steps and click Save:

Network Access Select the Disable Public Access and Enable Private Access option button.
Disk Access Select the private endpoint you just created.

FIGURE 3.19 The managed disk’s Networking page.

Using Azure CLI

Use the following code to create a private endpoint and integrate Private Link with a managed disk in the Azure CLI:

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
MgdDiskName="ManagedDisk01"
diskAccess="ManagedDisk01-DiskAccess"
vnet="VNET-01"
subnet="default"
privateEndPoint="ManagedDisk01-DiskAccess-PrivateEndpoint01"
#Create disk access
az disk-access create                        --name $diskAccess                        --resource-group $resourceGroup                        --location $location
 
diskAccessId=$(az disk-access show                        --name $diskAccess                        --resource-group $resourceGroup                        --query [id] -o tsv)
 
#Create private endpoint
az network private-endpoint create 
    --resource-group $resourceGroup     --name $privateEndPoint     --vnet-name $vnet      --subnet $subnet     --private-connection-resource-id $diskAccessId     --group-ids disks     --connection-name $privateEndPoint
 
#Create Private DNS zone config
az network private-dns zone create     --resource-group $resourceGroup     --name "privatelink.blob.core.windows.net"
 
az network private-dns link vnet create     --resource-group $resourceGroup     --zone-name "privatelink.blob.core.windows.net"     --name $privateEndPoint-DNSLink     --virtual-network $vnet     --registration-enabled false 
 
az network private-endpoint dns-zone-group create    --resource-group $resourceGroup    --endpoint-name $privateEndPoint    --name $privateEndPoint-ZoneGroup    --private-dns-zone "privatelink.blob.core.windows.net"    --zone-name disks
 
#Update managed disk with Private Link config
diskAccessId=$(az resource show    --name $diskAccess    --resource-group $resourceGroup    --namespace Microsoft.Compute    --resource-type diskAccesses    --query [id] -o tsv)
 
az disk update    --name $diskName    --resource-group $resourceGroup    --network-access-policy AllowPrivate    --disk-access $diskAccessId

Encryption

Managed disks support two types of disk encryption:

Server-Side Encryption (SSE) SSE manages encryption on the storage layer and is handled by the Azure Storage service. It provides encryption-at-rest and during write operations to the underlying storage, thereby ensuring that disks stored in Azure are not readable in the event of data theft. SSE is enabled by default for all managed disks, snapshots, and images across all Azure regions. SSE supports two types of key management: Azure platform-managed keys or customer-managed keys. You can choose which type of key management you want to use for each managed disk you create.
Azure Disk Encryption (ADE) ADE refers to encryption within the system. It applies to the OS and data disks in an Azure IaaS VM. ADE encryption is performed using BitLocker technology in Windows and DM-Crypt technology in Linux. In both scenarios, the keys are integrated and stored in Azure Key Vault to make it easier for you to manage them.

Managed disk snapshots

Snapshots provide an easy way to back up a point-in-time copy of your managed disk for restore or cloning operations. Snapshots are read-only, crash-consistent copies of the disk. You can use them to create new managed disks without affecting the source managed disk in any way. Snapshots are, by default, stored as standard managed disks, but you can change this during the snapshot creation process.

The first time you take a snapshot of a managed disk, it will be a full snapshot. Subsequent snapshots, however, can be incremental. An incremental snapshot captures all changes to the managed disk since the last snapshot of the disk. This reduces your storage footprint. If you need to restore from a single incremental snapshot, Azure automatically identifies all the incremental and full snapshots preceding the current one to reconstruct the entire disk. This makes incremental snapshots extremely cost-effective, making them the preferred option for regular snapshot management.

Incremental snapshots can also be useful for disaster recovery between Azure regions—that is, you can identify changes between two snapshots of the same disk, and then transfer only the differential changes to the secondary region instead of the entire snapshot. Then, when you restore/rebuild in the secondary region, you can use the snapshot of the base blob of the managed disk in combination with these differential changes. (See Figure 3-20.) This strategy can reduce time, costs, and network requirements for disaster recovery for managed disks.

Thursday, 30 May 2024