Azure Storage Accounts are a vital component in many Azure environments, serving as a versatile solution for various needs – from storing log files to providing data for applications. In my daily work, however, I primarily use them for a very specific purpose: storing user profiles with FSLogix. These profiles play a crucial role in ensuring a high-performing and seamless end-user experience, especially in virtual desktop environments like Azure Virtual Desktop (AVD).
One often overlooked but critical aspect is the choice of redundancy for the Storage Account. In the past, the Nerdio Manager for Enterprise only allowed the creation of Storage Accounts with locally redundant storage (LRS). As a result, many existing FSLogix implementations still rely on LRS storage. However, this configuration carries risks, particularly in environments designed for availability across multiple Azure Availability Zones.
In this post, I want to take a closer look at why LRS is often insufficient in such scenarios and what impact this can have on the availability of user profiles.
Distribution of AVD host pools via availability zones
A proven method to increase the resilience of Azure Virtual Desktop (AVD) environments is to distribute the virtual machines (VMs) of a host pool across multiple Availability Zones. This setup ensures that, in the event of a zone failure, a portion of the host pool capacity remains available, allowing users to continue working.
This architecture takes full advantage of the high availability Azure offers within a region while minimizing the risk that a zone outage impacts the entire environment. However, it is often overlooked that the availability of user profiles – and consequently the users’ ability to log in – plays an equally critical role. If the profiles are stored in a Storage Account that is only locally redundant, a zone failure can still result in user downtime, even if sufficient host pool capacity is available.
This critical relationship between the distribution of VMs and the choice of the correct storage model for FSLogix profiles is often underestimated, despite being essential to overall availability.
Why LRS can be wrong for profiles
Locally redundant storage (LRS) ensures that data is replicated three times within a single data center. While this provides protection against failures within that zone, a significant risk remains: if the entire Azure Availability Zone goes down, data stored in an LRS Storage Account becomes unavailable.
In cross-zone AVD environments, where virtual machines are distributed across multiple zones, this can pose a major problem. The advantage of allowing a portion of users to continue working during a zone outage is negated by the reliance on an LRS Storage Account. If the user profile is inaccessible, users cannot log in or may experience limited functionality – regardless of whether the VM itself is still operational.
To ensure higher availability and resilience, it is essential to choose a more redundant storage option for FSLogix profiles, such as zone-redundant storage (ZRS). ZRS provides data replication across multiple zones, mitigating the risk of profile unavailability during a zone failure.
For environments requiring geo-redundancy, it is advisable to achieve this through dedicated host pools and separate Storage Accounts for each region. This approach ensures that users always work with locally available infrastructure without relying on the higher latency and potential limitations of GRS or GZRS. These strategies not only offer better control over data flow but also enable efficient handling of regional outages.
In the next section, I’ll show how to use PowerShell to migrate from LRS to ZRS storage to create more redundancy in existing environments.
Migration from LRS to ZRS with PowerShell
Migrating existing Storage Accounts from locally redundant storage (LRS) to zone-redundant storage (ZRS) can be achieved primarily through two methods: by submitting a support ticket or using PowerShell. Below, I’ll share the PowerShell script I use for these migrations.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
$storageAccounts = [System.Collections.ArrayList]@() $null = $storageAccounts.add(@{storageAccountName = ''; resourceGroupName = ''; subscriptionId = ''; targetSKU = 'Premium_ZRS' }) $migrate = $false If ($migrate) { ForEach ($storageAccount in $storageAccounts) { # Check to subscription if not the current subscription if ((Get-AzContext).Subscription.Id -ne $storageAccount.subscriptionId) { Write-Host "Switching to $($storageAccount.subscriptionId)" $null = Select-AzSubscription -SubscriptionId $storageAccount.subscriptionId } Write-Host "Starting migration of $($storageAccount.storageAccountName) in $($storageAccount.resourceGroupName) to $($storageAccount.targetSKU)" Start-AzStorageAccountMigration ` -AccountName $storageAccount.storageAccountName ` -ResourceGroupName $storageAccount.resourceGroupName ` -TargetSku $storageAccount.targetSKU ` -Name "Migration of $($storageAccount.storageAccountName)" ` -AsJob } } Else { ForEach ($storageAccount in $storageAccounts) { # Check to subscription if not the current subscription if ((Get-AzContext).Subscription.Id -ne $storageAccount.subscriptionId) { Write-Host "Switching to $($storageAccount.subscriptionId)" $null = Select-AzSubscription -SubscriptionId $storageAccount.subscriptionId } # Check if the migration is completed $migrationStatus = Get-AzStorageAccount ` -AccountName $storageAccount.storageAccountName ` -ResourceGroupName $storageAccount.resourceGroupName if ($migrationStatus.Sku.Name -eq $storageAccount.targetSKU) { Write-Host "Migration of $($storageAccount.storageAccountName) in $($storageAccount.resourceGroupName) to $($storageAccount.targetSKU) is completed" continue } else { $status = Get-AzStorageAccountMigration ` -AccountName $storageAccount.storageAccountName ` -ResourceGroupName $storageAccount.resourceGroupName Write-Host "Migration of $($storageAccount.storageAccountName) in $($storageAccount.resourceGroupName) to $($storageAccount.targetSKU) is not completed. Status: $($status.DetailMigrationStatus)" } } } |
With an array, multiple Storage Accounts can be migrated simultaneously. To do this, the name, resource group, and subscription of each Storage Account are required. I typically use Premium_ZRS as the target SKU, as my Storage Accounts are usually already on Premium_LRS and are optimized for profiles.
Important: The $migrate parameter is initially used for validation only. To actually start the migration, the parameter must be set to $true. Once the migration is complete, it should be set back to $false to avoid accidental multiple executions of the migration.
To execute the code, I open the Azure portal, start the cloud shell and paste the code there. The output then looks like this:
If the script is executed later with the parameter $migrate and the value set to $false, the migration progress can be checked:
Further information
Before proceeding with the migration, it’s important to review the available migration scenarios for Storage Accounts. This can be checked in the article Changing redundancy configuration.
Additionally, ensure that the Storage Account is located in a region that supports Availability Zones and zone-redundant storage (ZRS). You can verify this using the reference Azure regions that support zone-redundant storage (ZRS).
In some cases, a migration may not be completed within 5 days. If this happens, a support ticket should be created. We have experienced situations where Azure Support had to review and initiate the migration manually, especially in heavily utilized regions. For us, this occurred in a region under high demand.
New Storage Accounts
Since version 6.0 of Nerdio Manager for Enterprise, it has been possible to create new Storage Accounts directly with zone-redundant storage (ZRS). This enhancement significantly simplifies the setup process, as ZRS is now available as a redundancy option from the outset, eliminating the need for manual post-migration.
Conclusion
Migrating Storage Accounts can be a complex process, especially when the target regions are unsupported or specific features block the migration. In such special cases, it is essential to carefully review the official documentation and perform a trial migration with a test Storage Account beforehand.
Nonetheless, I hope I have been able to demonstrate why such a migration is worthwhile and how it can be successfully carried out.