Since we launched Hyperscale elastic pools preview at Build 2023, many customers have adopted it to achieve significant price-performance optimization of their Hyperscale databases. Today, we are pleased to announce that Hyperscale elastic pools now also support zone redundancy for even greater resiliency to outages.
The zone redundant configuration for Hyperscale elastic pools utilizes Azure Availability Zones to ensure that the various components in a Hyperscale elastic pool are placed in multiple physical locations within an Azure region. By selecting zone redundancy for a Hyperscale elastic pool, you can make it, and the Hyperscale databases within the pool, resilient to a much larger set of failures, including catastrophic datacenter outages. For more information see Hyperscale zone redundant availability.
Creating a zone redundant Hyperscale elastic pool
A zone redundant Hyperscale elastic pool can be created via the Azure portal, REST API, Azure PowerShell, or Azure CLI. It’s important to note that zone redundancy for Hyperscale elastic pools can only be specified at creation time and cannot be modified later.
The following image illustrates how to use Azure portal to configure a new zone redundant Hyperscale elastic pool. This can be configured in the Configure database page when creating a new elastic pool. At least one High-Availability Secondary Replica must be specified.
Creating a new Hyperscale database within a zone redundant Hyperscale elastic pool
When creating a new Hyperscale database within a zone redundant Hyperscale elastic pool, the only consideration is to select either Zone (ZRS) or Geo-zone (GZRS) storage redundancy, as shown in the following Azure portal screenshot.
Similarly, when using Azure PowerShell to create a new database within a zone redundant Hyperscale elastic pool, be sure to use the -BackupStorageRedundancy parameter and specify either Zone or GeoZone.
Adding existing Hyperscale databases to a zone redundant Hyperscale elastic pool
You can add an existing Hyperscale database to a zone redundant Hyperscale elastic pool on the same logical server, if it is either a standalone zone redundant Hyperscale database, or part of another zone redundant Hyperscale elastic pool. The database being added would therefore also have to be configured with zone redundant storage (ZRS) or geo-zone redundant storage (GZRS). Only databases which meet these requirements will be available for selection on the Add databases pane within the portal.
In the following example, the “hs_lrs_db” database is not available for being added to the zone redundant Hyperscale elastic pool.
You can use a database copy or point-in-time restore (PITR) to re-deploy the non-zone redundant Hyperscale databases to zone redundant databases before adding them to the zone redundant elastic pool.
Migrating existing non-Hyperscale databases to a zone redundant Hyperscale elastic pool
You can use the Azure portal to add non-Hyperscale databases to a zone redundant Hyperscale elastic pool. Databases can be added as long as a non-Hyperscale database has zone redundant storage (ZRS) and is also zone redundant. Any other non-Hyperscale databases cannot be selected on the Add databases pane in the portal:
You can still use Azure PowerShell or CLI and migrate the non-Hyperscale database to the zone redundant Hyperscale elastic pool, as shown in the following code sample. The key requirement in this case is to specify the -ElasticPoolName -BackupStorageRedundancy parameters:
Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName gp1 -ElasticPoolName "my-ZR-Hyperscale-EP" -BackupStorageRedundancy Zone
The “gp1” database would be migrated to a Hyperscale database with ZRS storage and would implicitly be zone redundant due to being part of the “my-ZR-Hyperscale-EP” zone redundant Hyperscale elastic pool.
Here are some more examples of working with Hyperscale elastic pools using Azure PowerShell and Azure CLI.
Regional availability
All Azure regions that have Availability Zones support zone redundant Hyperscale elastic pool with standard-series (Gen5) hardware. Zone redundant Hyperscale elastic pools with premium-series (PRMS), or premium-series, memory-optimized (MOPRMS) hardware can only be created in specific regions listed in Hyperscale premium-series availability.
Conclusion
In conclusion, this update to Hyperscale elastic pools is a critical part of ensuring resiliency for your database workloads. We look forward to you adopting zone redundant Hyperscale elastic pools. Our team is here to assist with any questions you may have. Please leave a comment on this blog and we’ll be happy to get back to you. Alternatively, you can also email us at sqlhsfeedback AT microsoft DOT com. We are eager to hear from you all!