Azure Files geo-redundancy for large file shares
Azure Files geo-redundancy for large file shares significantly improves capacity and performance for standard SMB file shares when using geo-redundant storage (GRS) and geo-zone redundant storage (GZRS) options.
Azure Files has offered 100 TiB standard SMB shares for years with locally redundant storage (LRS) and zone-redundant storage (ZRS). However, geo-redundant file shares had a 5 TiB capacity limit and were sometimes throttled due to IO operations per second (IOPS) and throughput limits. Now, geo-redundant standard SMB file shares support up to 100 TiB capacity with improved IOPS and throughput limits.
Applies to
File share type | SMB | NFS |
---|---|---|
Standard file shares (GPv2), LRS/ZRS | ||
Standard file shares (GPv2), GRS/GZRS | ||
Premium file shares (FileStorage), LRS/ZRS |
Geo-redundant storage options
Azure maintains multiple copies of your data to ensure durability and high availability. For protection against regional outages, you can configure your storage account for GRS or GZRS to copy your data asynchronously in two geographic regions that are hundreds of miles apart. This feature adds GRS and GZRS support for standard storage accounts that have the large file shares feature enabled.
Geo-redundant storage (GRS) copies your data synchronously three times within a single physical location in the primary region. It then copies your data asynchronously to a single physical location in the secondary region. Within the secondary region, your data is copied synchronously three times.
Geo-zone-redundant storage (GZRS) copies your data synchronously across three Azure availability zones in the primary region. It then copies your data asynchronously to a single physical location in the secondary region. Within the secondary region, your data is copied synchronously three times.
If the primary region becomes unavailable for any reason, you can initiate an account failover to the secondary region.
Note
Azure Files doesn't support read-access geo-redundant storage (RA-GRS) or read-access geo-zone-redundant storage (RA-GZRS). If a storage account is configured to use RA-GRS or RA-GZRS, the file shares will be configured as GRS or GZRS. The file shares won't be accessible in the secondary region unless a failover occurs.
New limits for geo-redundant shares
All standard SMB file shares that are geo-redundant (both new and existing) now support up to 100TiB capacity and have higher performance limits:
Attribute | Previous limit | New limit |
---|---|---|
Capacity per share | 5 TiB | 100 TiB (20x increase) |
Max IOPS per share | 1,000 IOPS | Up to storage account limits (20x increase) |
Max throughput per share | Up to 60 MiB/s | Up to storage account limits (150x increase) |
Region availability
Azure Files geo-redundancy for large file shares is generally available in all regions.
Pricing
Pricing is based on the standard file share tier and redundancy option configured for the storage account. To learn more, see Azure Files Pricing.
Configure geo-redundancy and 100 TiB capacity for standard SMB file shares
In all regions that support geo-redundancy:
- Standard SMB file shares (new and existing) support up to 100 TiB capacity and you can select any redundancy option supported in the region. Since all standard SMB file shares now support up to 100 TiB capacity, the large file share (LargeFileSharesState) property on storage accounts is no longer used and will be removed in the future.
- If you have existing file shares, you can now increase the file share size up to 100 TiB (share quotas aren't automatically increased).
- Performance limits (IOPS and throughput) for your file shares have automatically increased to the storage account limits.
Perform the following steps to configure 100TiB shares and geo-redundancy for new and existing SMB file shares:
Create a new storage account and file share
Perform the following steps to configure geo-redundancy for a new storage account and Azure file share.
- Create a standard storage account and select geo-redundant storage (GRS) or geo-zone redundant storage (GZRS) for the Redundancy option.
- Create an SMB Azure file share. New file shares that are created default to 100 TiB.
Existing storage accounts with a redundancy option of LRS or ZRS
- Change the redundancy option for your storage account to GRS or GZRS.
- Increase the file share quota up to 100 TiB. New file shares that are created default to 100 TiB.
Existing storage accounts with a redundancy option of GRS, GZRS, RA-GRS, or RA-GZRS
- Increase the file share quota up to 100 TiB. New file shares that are created default to 100 TiB.
Snapshot and sync frequency
To ensure file shares are in a consistent state when a failover occurs, a system snapshot is created in the primary region every 15 minutes and is replicated to the secondary region. When a failover occurs to the secondary region, the share state is based on the latest system snapshot in the secondary region. Due to geo-lag or other issues, the latest system snapshot in the secondary region may be older than 15 minutes.
The Last Sync Time (LST) property on the storage account indicates the last time that data from the primary region was written successfully to the secondary region. For Azure Files, the Last Sync Time is based on the latest system snapshot in the secondary region. You can use PowerShell or Azure CLI to check the Last Sync Time for a storage account.
It's important to understand the following about the Last Sync Time property:
- The Last Sync Time property on the storage account is based on the service (Files, Blobs, Tables, Queues) in the storage account that's the furthest behind.
- The Last Sync Time isn't updated if no changes have been made on the storage account.
- The Last Sync Time calculation can time out if the number of file shares exceeds 100 per storage account. Less than 100 file shares per storage account is recommended.
Failover considerations
This section lists considerations that might impact your ability to fail over to the secondary region.
- Storage account failover is blocked if a system snapshot doesn't exist in the secondary region.
- Storage account failover is blocked if the storage account contains more than 100,000 file shares. To failover the storage account, open a support request.
- File handles and leases aren't retained on failover, and clients must unmount and remount the file shares.
- File share quota might change after failover. The file share quota in the secondary region will be based on the quota that was configured when the system snapshot was taken in the primary region.
- Copy operations in progress are aborted when a failover occurs. When the failover to the secondary region completes, retry the copy operation.
To failover a storage account, see initiate an account failover.