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

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:

1. 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.)

   

2. On the Disks page (see Figure 3-2), click Create.

   

3. 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.

   

4. 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.

5. 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.)

   

6. 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.)

   

7. Back in the Basics tab of the Create a Managed Disk wizard, click Next.

8. 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.

   

9. 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.

   

10. 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.

    

    • On-Demand Bursting If you want this managed disk to be capable of on-demand bursting, select the Enable On-Demand Bursting check box.

    • 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.

11. In the Tags tab (see Figure 3-9), enter any tags you want to associate with the managed disk and click Next.

    

12. In the Review + Create tab (see Figure 3-10), review your settings, and click Create to create the managed disk.

    

13. After the managed disk is created, click Go to Resource to access its page. (See Figure 3-11.)

Using Azure Powershell

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

Click here to view code image

#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:

Click here to view code image

#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:

1. 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.)

   

2. On the Disk Access page, click Create Disk Access. (See Figure 3-13.)

   

3. 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.

   

   Before you continue with the Create a Disk Access wizard, you need to create the private endpoint. You’ll do that next.

4. At the bottom of the Basics tab, click Add.

5. 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.

   

6. Click the Tags tab (see Figure 3-16), enter any tags you want to associate with the private endpoint, and click Next.

   

7. In the Review + Create tab (see Figure 3-17), review your settings and click Create to create the private endpoint.

   

8. After the private endpoint is created, click Go to Resource to access its page. (See Figure 3-18.)

   

9. In the left pane of the page for the managed disk you created earlier, under Settings, click Networking.

10. 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.

Using Azure CLI

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

Click here to view code image

#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.

Incremental snapshots are a great feature, but they do have some limitations that exist at the time of this writing. By the time you read this, these limitations may have been addressed. Be sure to review Microsoft’s latest guidance before finalizing your snapshot management strategy. Some key limitations at present include the following:

• Unlike full snapshots, incremental snapshots always use Standard HDD disks, regardless of the disk type used for the full snapshot.

• A single managed disk supports a maximum of 500 incremental snapshots.

• Each managed disk limits you to creating seven incremental snapshots, with a wait time of 5 minutes between each snapshot.

• The managed disk and snapshots must all be part of the same subscription.

• If you want to move a managed disk to another subscription, you will not be able to do so if the disk has incremental snapshots. You will need to keep this in mind when planning any such migrations.

• Differentials do not work for disks larger than 4 TB.

#Define variables
$resourceGroup = "RG01"
$location = "EastUS2"
$vm = "SourceVM"
$snapshotName = "SourceVM-Snapshot-20230228"

#get the VM
$vminfo = Get-AzVM `
    -ResourceGroupName $resourceGroup `
    -Name $vm

#Create the snapshot configuration
$snapshotconfig =  New-AzSnapshotConfig `
    -SourceUri $vminfo.StorageProfile.OsDisk.ManagedDisk.Id `
    -Location $location `
    -CreateOption copy

#Take the snapshot.
New-AzSnapshot `
    -Snapshot $snapshotconfig `
    -SnapshotName $snapshotName `
    -ResourceGroupName $resourceGroup

#Verify snapshot
Get-AzSnapshot `
    -ResourceGroupName $resourceGroup

#Define variables
resourceGroup="RG01"
location="EastUS2"
vm="SourceVM"
snapshotName="SourceVM-Snapshot-20230228"

#get the VM
DiskInfo=$(az vm show 
   --resource-group $resourceGroup 
   --name $vm 
   --query "storageProfile.osDisk.managedDisk.id" 
   -o tsv)

#Take the snapshot.
az snapshot create 
   --resource-group $resourceGroup 
                       --source "$DiskInfo" 
                       --name $snapshotName

#Verify snapshot
az snapshot list 
   --resource-group $resourceGroup 
   -o table

Managed images

Managed images enable you to create hundreds of copies of customized VMs in Azure without having to create multiple copies of the underlying disks associated with each VM or manage any storage accounts to host them. You can easily create managed images out of managed disks; the resulting managed image will contain the configuration of the source VM, including all the managed disks associated with that source VM. This helps you to scale your VM resources using features like VMSS or Azure Virtual Desktop Session Host Pools, where capacity is added as load increases.

The primary difference between managed disks and managed images is that an image is built from a generalized VM and includes all the associated disks, whereas a snapshot is specific to a single disk and is a point-in-time copy of that disk. Generalizing a VM removes machine and user-specific information from the VM. So, for a VM that has multiple disks using disk spanning, a snapshot currently does not support a coordinated restore of all the disks and, therefore, might not be the right solution.

Managed images walkthrough

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

Using Azure portal

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

1. On the Overview page of the VM for which you want to create an image, click Capture. (See Figure 3-30.)

   

2. In the Basics tab of the Create an Image wizard (see Figure 3-31), enter the following information and click Next:

   • Resource Group Select an existing resource group in which to create the new managed image or create a new one.

   • Share Image to Azure Compute Gallery For this walkthrough, select the No, Capture Only a Managed Image option button.

   • Automatically Delete this Virtual Machine After Creating the Image Leave this checkbox unchecked (the default).

   • Zone Resiliency Select this check box if you want to create a zone redundant image.

   • Name Enter a unique name for the managed image.

   

3. In the Tags tab (see Figure 3-32), enter any tags you want to associate with the managed image and click Next.

   

4. In the Review + Create tab (see Figure 3-33), review your settings, and click Create to create the managed image.

   

   The source VM will be stopped automatically if you haven’t turned it off already. (See Figure 3-34.) Azure will then generalize the VM and create the image.

   

5. After the managed image is created, click Go to Resource to access its page. (See Figure 3-35.)

   

   The managed image’s Overview page displays the properties of the managed image as well as Create VM, Clone to a VM Image, Delete, and Refresh options. (See Figure 3-36.)

Using Azure Powershell

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

Click here to view code image

#Define variables
$vm = "SourceVM"
$resourcegroup = RG01
$location = "EastUS2"
$imageName = "SourceVM-Image-20221203"

#VM has been deallocated
Stop-AzVM -ResourceGroupName $resourcegroup -Name $vm -Force

#Set the status of the virtual machine to Generalized.
Set-AzVm -ResourceGroupName $resourcegroup -Name $vm -Generalized

#Create the image configuration.
$vminfo = Get-AzVM -Name $vm -ResourceGroupName $resourcegroup
$vmimage = New-AzImageConfig -Location $location -SourceVirtualMachineId $vminfo.Id

#Create the image.
New-AzImage -Image $vmimage -ImageName $imageName -ResourceGroupName $resourcegroup

Using Azure CLI

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

Click here to view code image

#Define variables
vm="SourceVM"
resourcegroup=$RG01
location="EastUS2"
imageName="SourceVM-Image-20221203"

#VM has been deallocated
az vm deallocate 
    --resource-group $resourcegroup 
    --name $vm

#Set the status of the virtual machine to Generalized.
az vm generalize 
    --resource-group $resourcegroup 
    --name $vm

#Create the image.
az image create 
    --resource-group $resourcegroup 
--location $location 
--zone-resilient false 
 --name $imageName --source $vm

Performance tiering

When you create a managed disk, Azure automatically assigns a default performance target for that disk. This is based on predefined targets associated with the disk provisioned for the managed disk. This determines the IOPS and throughput available for that managed disk. This default performance target is not the maximum performance available for that managed disk, however. You can change the performance tier for a managed disk, without having to change the size of the disk. This can be beneficial in scenarios when you are running workloads that require high IOPS but do not require a lot of space for data storage.

You should use performance tiering in combination with disk bursting (discussed later in this chapter) to determine the ideal performance targets for your managed disks. If you observe your managed disks consistently requiring burst capacity to handle workload traffic, it is highly recommended that you compare any additional costs you are incurring to the costs of permanently changing the performance tier for that managed disk.

Using performance tiering does have some limitations. These include the following:

• Performance tiering is supported only for Premium SSD managed disks.

• Currently, P60 and higher performance tiers can be used only by 4 TB or larger disks.

• Shared disks cannot use performance tiering.

• On managed disks created before June 2020, the performance tier can only be changed to the baseline tier for the managed disk size.

#Define variables
$resourceGroup = "RG01"
$location = "EastUS2"
$MgdDiskName = "ManagedDisk01"
$performanceTier='P40'
#Update disk performance tier
$newmgddiskconfig = New-AzDiskUpdateConfig -Tier $performanceTier
Update-AzDisk 
                       -ResourceGroupName $resourceGroup 
                       -DiskName $MgdDiskName 
                       -DiskUpdate $newmgddiskconfig

#Define variables
resourcegroup="RG01"
location="EastUS2"
vm="SourceVM"
mgddiskname="ManagedDisk01"
performancetier="P40"
#Update disk performance tier
az disk update 
                       --name $mgddiskname 
                       --resource-group $resourcegroup 
                       --set tier=$performancetier

Disk redundancy

The Azure Managed Disks service supports two disk-redundancy options:

• Locally-redundant storage (LRS) With LRS, three replicas of the managed disk is maintained in a single datacenter within your primary Azure region. This protects against local storage hardware, server rack, or network component failures. However, because all three replicas of the managed disk are stored in the same datacenter, if that datacenter experiences some type of disaster, all data stored on those managed disks could be lost. LRS disks have an SLA of at least 99.999999999% (11 nines) of durability over a given year.

• Zone-redundant storage (ZRS) Like an LRS managed disk, a ZRS managed disk synchronously commits and maintains three replicas in your primary Azure region. However, instead of being in a single datacenter, the replicas are spread across three availability zones. An availability zone is an independent datacenter in your Azure primary region with its own power, cooling, and networking components. So, if a disaster occurs in one availability zone, replicas of your managed disk will still be accessible (unless the disaster also affects the other availability zones). You can also share ZRS managed disks between VMs for clustering databases or distributed applications, such as SQL Failover Clustering and Remote Desktop Services User Profile Disks. At present, only Standard SSD disks and Premium SSD disks support ZRS. ZRS disks have an SLA of at least 99.9999999999% (12 nines) of durability over a given year.

Although ZRS managed disks provide higher redundancy, their write latency is higher than LRS managed disks, because their write operations are performed across multiple availability zones rather than within the same datacenter. Apart from that, ZRS managed disks are identical to LRS managed disks.

You can set the disk redundancy option for a managed disk in two different ways:

• Using the Create a Managed Disk wizard As described earlier in this chapter, you can set a managed disk’s redundancy level at the time of creation. To do so, you click the Change Size link the Size section of the wizard’s Basics tab. Then, in the Select a Disk Size dialog box, you use the Disk SKU drop-down list to choose a disk type/redundancy level pairing.

• Using the Create Virtual Machine wizard You can set a managed disk’s redundancy level when you create a virtual machine that will use that disk. You do so in the wizard’s Disks tab by setting the OS Disk Type option. (See Figure 3-40.)

Shared disks

You can use certain types of Azure managed disks as shared disks. These allow you to attach the same disk to multiple VMs simultaneously. In this way, you can deploy or migrate databases or applications that require clustering capabilities.

Clustered applications use SCSI Persistent Reservations (SCSI PR) to reserve the active node in the cluster. This node determines which VM will perform read and write operations to the shared disk. SCSI PR is an industry standard, and applications designed to run on storage area network (SAN) storage are built to this standard. This makes it possible to migrate clustered applications to Azure or to deploy them in Azure and migrate the required code or databases later.

As described earlier in this chapter, you can share a managed disk at the time of creation using the Create a Managed Disk wizard. (In the Advanced tab, click the Yes option button next to Enable Shared Disk. Then use the Max Shares drop-down list to specify how many VMs will share the disk.) You can also change an existing managed disk so it becomes a shared disk.

Shared disks have numerous limitations, including the following:

• Only Ultra, Premium, and Standard SSD disks can be used as shared disks.

• Shared disks do not support Azure Disk Encryption (ADE). They only support Server-Side encryption (SSE).

• Azure Site Recovery is not supported to replicate shared disks. You must use Azure Disk Backup to build any redundancy plans.

• Host caching isn’t available for Premium and Standard SSDs.

Both Windows and Linux support shared disks. In the case of Windows, Windows Server 2008 and above support shared disks. For Linux, shared disks are supported by a few different distributions:

• SUSE SLE HA 15 SP1 and above

• Ubuntu 18.04 and above

• RHEL 8.3 and above

• Oracle Enterprise Linux

Shared disks walkthrough

The following sections step you through the process of setting up an existing managed disk as a shared disk using the Azure portal, Azure PowerShell, and the Azure CLI.

Using Azure portal

To set up an existing managed disk as a shared disk using the Azure portal, follow these steps:

1. In the Overview page for the managed disk that you want to share, under Settings, click Configuration.

2. On the managed disk’s Configuration page (see Figure 3-41), enter the following information and click Save:

   • Enable Shared Disk Select the Yes option button.

   • Max Shares Use this drop-down list to specify the number of VMs that will share the disk (in this case, select 2).

Using Azure Powershell

Use the following Azure PowerShell code to convert an existing managed disk to a shared disk:

Click here to view code image

#Converting an existing managed disk to shared
#Define variables
$region = "EastUS"
$resourcegroup = "RG01"
$diskname = "ManagedDisk01"
#Define Shared disk config
$shareddiskconfig = Get-AzDisk -DiskName $Diskname
$shareddiskconfig.maxShares = 2
#Update disk config to shared
Update-AzDisk -ResourceGroupName $ResourceGroup -DiskName $Diskname -Disk
$shareddiskconfig

Using Azure CLI

Use the following code to convert an existing managed disk to a shared disk in the Azure CLI:

Click here to view code image

#Converting an existing managed disk to shared
#Define variables
region="EastUS"
resourcegroup="RG01"
diskname="ManagedDisk01"
#Update disk config to shared
az disk update --name $diskname --max-shares 2 --resource-group $resourcegroup

Managed disk bursting

Premium and Standard SSDs managed disks support disk bursting. This important feature allows managed disks to handle additional IOPS and MB/s in bursts to boost their performance when faced with a sudden spike in resource requirements or a resource crunch. Disk bursting is great for tackling common problems like sudden unplanned traffic spikes on application and web servers, batch jobs that require additional capacity during processing, increased IOPS requirements at server startup, and simultaneous profile logins in virtual desktop infrastructure environments.

Azure offers two forms of disk bursting:

• On-demand bursting Premium SSD managed disks that are 512 GB or larger can use on-demand bursting to boost their IOPS and MB/s performance when needed to meet workload requirements. Microsoft levies charges for additional consumption used at the end of every billing cycle. On-demand bursting is ideal for critical workloads for which an occasional spike in performance is anticipated.

• Credit-based bursting By default, when a Standard or Premium SSD managed disk that is 512 GB or smaller consumes less IOPS and/or MB/s than its performance target, it accrues credits. The managed disk can then “spend” these credits on credit-based bursting to boost its IOPS and MB/s performance to meet higher workload requirements as needed, at no extra charge. Once the credits are consumed, the managed disk will be limited to the performance target defined for it.

Managed disk backup

Azure Backup provides a simple and cost-effective cloud-native backup solution for regular backups of managed disks. It provides snapshot lifecycle management of managed disks by performing incremental snapshots—as often as multiple times a day—which are retained for the period defined in the backup policy. It is an agent-less backup solution that does not interact with or affect the application performance.

You can use managed disk backup in conjunction with the once-a-day application-consistent VM-level backups via Azure Backup for a comprehensive backup solution. You can back up disks whether they are connected and actively in use by a VM or unattached to any workload. Because no backup agents, custom scripts, or service accounts are required to carry out these backups, they are considered to be highly secure.

Backup walkthrough

The following sections step you through the process of creating a backup of a managed disk using the Azure portal.

Using Azure portal

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

1. Log into the Azure portal, type backup center in the search box, and select Backup Center from the list that appears. (See Figure 3-42.)

   

2. On the Backup Center’s Overview page (see Figure 3-43), click Backup.

   

3. In the Basics tab of the Configure Backup wizard (see Figure 3-44), enter the following information:

   • Datasource Type Select Azure Disks.

   • Vault You can select an existing backup vault or create a new one. In this example, click Create Vault to create a new one.

   

4. In the Basics tab of the Create Backup Vault wizard (see Figure 3-45), enter the following information and click Next:

   • Subscription Select the subscription in which you want to host the vault.

   • Resource Group Select the resource group you want to use to host the vault. Alternatively, to create a new resource group, click the Create New link and follow the prompts.

   • Backup Vault Name Enter a unique name for the vault. If the name you type is already in use, the wizard will prompt you to select another name.

   • Region Select the Azure region in which you want to host the vault.

   • Backup Storage Redundancy Select the redundancy level for the backup storage.

   

5. In the Vault Properties tab (see Figure 3-46), enter the following information and click Next:

   • Enable Soft Delete Select this check box if you want to enable the soft delete feature (recommended).

   • Retention Period Specify how many days data should be retained before it is permanently deleted.

   

6. In the Tags tab (see Figure 3-47), enter any tags you want to associate with the backup vault and click Next.

   

7. In the Review + Create tab (see Figure 3-48), review your settings and click Create.

   

8. Back in the Basics tab of the Configure Backup wizard, click Next.

9. In the Backup Policy tab (see Figure 3-49), you can select an existing backup policy or create a new one. In this example, click Create New to create a new one.

   

10. In the Basics tab of the Create a Backup Policy wizard (see Figure 3-50), in the Policy Name box, enter a unique name for the policy. Then click Next.

    

11. In the Schedule + Retention tab (see Figure 3-51), choose the Hourly or Daily option button next to Backup Frequency and choose the desired option from the Time drop-down list.

    

12. Click the Add Retention Rule link (see Figure 3-52), set up a custom backup retention policy based on your retention requirements, and click Next.

    

13. In the Review + Create tab (see Figure 3-53), review your settings and click Create.

    

14. Back in the Basics tab of the Configure Backup wizard, click Next.

15. Back in the Backup Policy tab of the Configure Backup wizard (see Figure 3-54), click Next.

16. In the Datasources tab (see Figure 3-55), click Add.

    

    

17. On the Select Resources to Backup page (see Figure 3-56), select the managed disks you want to back up and click OK.

    

18. Back in the Datasources tab of the Configure Backup wizard (see Figure 3-57), open the Snapshot Resource Group drop-down list and select the resource group where the managed disk’s snapshots are stored. Then click Validate.

    

    For the sake of example, let’s step through what happens if the validation fails.

19. If the validation fails, click the View Details link on the right-most side of the managed disk’s entry in the list of data sources. (See Figure 3-58.)

    

    As shown in Figure 3-58, the reason for the failure is a role assignment error. To fix this, you must assign the correct role.

20. Select the check box next to the entry for the managed disk. Then click Assign Missing Roles. (See Figure 3-59.)

    

21. In the Grant Missing Permissions dialog box (see Figure 3-60), open the Scope drop-down list and select a scope for the role assignment—Resource, Resource Group, or Subscription. Then click Confirm.

22. Click the Validate button under Snapshot Resource Group a second time.

23. Assuming the validation is successful (see Figure 3-61), click Next.

    

    

24. In the Review + Configure tab (see Figure 3-62), review your settings and click Configure Backup to configure the backup.

    

25. After the backup is configured, click Go to Resource. (See Figure 3-63.)

    

    Backup instances are listed in the Backup Instances page of the Backup Center. (See Figure 3-64.) You can wait for your backup instance to trigger automatically based on the backup policy you created. Alternatively, you can trigger the backup manually. We’ll do that next.

    

26. Click the entry for the backup instance.

27. On the page for the backup instance (see Figure 3-65), click Backup Now.

    

28. On the Backup Now page (see Figure 3-66), select the retention policy you want to use for the backup job. Then click Backup Now.

    

29. Back on the page for the backup instance, you will see the on-demand backup job you just triggered is in progress. (See Figure 3-67.) Click the In Progress link.

    

30. The Backup Jobs page shows more details on the status of the backup job. (See Figure 3-68.)