Azure Elastic Storage Area Network (SAN) is Microsoft's answer to the problem of workload optimization and integration between your large-scale databases and performance-intensive mission-critical applications. Elastic SAN (preview) is a fully integrated solution that simplifies deploying, scaling, managing, and configuring a SAN while also offering built-in cloud capabilities like high availability.
Elastic SAN is designed for large-scale IO-intensive workloads and top-tier databases such as SQL and MariaDB and supports hosting the workloads on virtual machines or containers such as Azure Kubernetes Service.
Benefits of Elastic SAN
Compatibility
Azure Elastic SAN volumes can connect to various compute resources using the Internet Small Computer Systems Interface (iSCSI) protocol. Because of this, rather than having to configure storage for each of your compute options, you can configure an Elastic SAN to serve as the storage solution for multiple compute options and manage it separately from each option.
Simplified provisioning and management
Elastic SAN simplifies deploying and managing storage at scale through grouping and policy enforcement. With volume groups, you can manage a large number of volumes from a single resource. For instance, you can create virtual network rules on the volume group and grant access to all your volumes.
Performance
With an Elastic SAN, it's possible to scale your performance up to millions of IOPS, with double-digit GB/s throughput and single-digit millisecond latency. The performance of an SAN is shared across all of its volumes, and as long as the SAN's caps aren't exceeded and the volumes are large enough, each volume can scale up to 64,000 IOPs. Elastic SAN volumes connect to your clients using the iSCSI protocol, which allows them to bypass the IOPS limit of an Azure VM and offers high throughput limits.
Cost optimization and consolidation
Cost optimization can be achieved with Elastic SAN since you can increase your SAN storage in bulk. You can either increase your performance along with the storage capacity or increase the storage capacity without increasing the SAN's performance, potentially offering a lower total cost of ownership. With Elastic SAN, you generally won't need to overprovision volumes because you share the performance of the SAN with all its volumes.
Elastic SAN resources
Each Azure Elastic SAN has two internal resources: Volume groups and volumes.
The following diagram illustrates the relationship and mapping of an Azure Elastic SAN's resources to the resources of an on-premises SAN:
Elastic SAN
When you configure an Elastic SAN, you select the redundancy of the entire SAN and provision storage. The storage you provide determines how much performance your SAN has and the total capacity that can be distributed to each volume within the SAN.
Your Elastic SAN's name has some requirements. The name may only contain lowercase letters, numbers, hyphens and underscores and must begin and end with a letter or a number. Each hyphen and underscore must be preceded and followed by an alphanumeric character. The name must be between 3 and 24 characters long.
Volume groups
Volume groups are management constructs that you use to manage volumes at scale. Any settings or configurations applied to a volume group, such as virtual network rules, are inherited by any volumes associated with that volume group.
Your volume group's name has some requirements. The name may only contain lowercase letters, numbers, and hyphens, and it must begin and end with a letter or a number. Each hyphen must be preceded and followed by an alphanumeric character. The name must be between 3 and 63 characters long.
Volumes
You partition the SAN's storage capacity into individual volumes. These individual volumes can be mounted to your clients with iSCSI.
The name of your volume is part of their iSCSI IQN. The name may only contain lowercase letters, numbers, hyphens and underscores and must begin and end with a letter or a number. Each hyphen and underscore must be preceded and followed by an alphanumeric character. The name must also be between 3 and 63 characters long.
Support for Azure Storage features
The following table indicates support for Azure Storage features with Azure Elastic SAN.
The status of items in this table may change over time.
Storage feature | Supported for Elastic SAN |
Encryption at rest | ✔️ |
Encryption in transit | ⛔ |
✔️ | |
Private endpoints | ⛔ |
Grant network access to specific Azure virtual networks | ✔️ |
Soft delete | ⛔ |
Snapshots | |
Scale Target
There are three main components to an elastic storage area network (SAN): the SAN itself, volume groups, and volumes.
The Elastic SAN
An Elastic SAN (preview) has three attributes that determine its performance: total capacity, IOPS, and throughput.
Capacity
The total capacity of your Elastic SAN is determined by two different capacities: the base capacity and the additional capacity. Increasing the base capacity also increases the SAN's IOPS and throughput but is more costly than increasing the additional capacity. Increasing additional capacity doesn't increase IOPS or throughput.
The maximum total capacity of your SAN is determined by the region where it's located and by its redundancy configuration. The minimum total capacity for an Elastic SAN is one tebibyte (TiB). Base or additional capacity can be increased in increments of 1 TiB.
IOPS
The IOPS of an Elastic SAN increases by 5,000 per base TiB. So, if you had an Elastic SAN that has 6 TiB of base capacity, that SAN could still provide up to 30,000 IOPS. That same SAN would still provide 30,000 IOPS whether it had 50 TiB of additional capacity or 500 TiB of additional capacity since the SAN's performance is only determined by the base capacity. The IOPS of an Elastic SAN is distributed among all its volumes.
Throughput
The throughput of an Elastic SAN increases by 80 MB/s per base TiB. So, if you had an Elastic SAN that has 6 TiB of base capacity, that SAN could still provide up to 480 MB/s. That same SAN would provide 480-MB/s throughput whether it had 50 TiB of additional capacity or 500 TiB of additional capacity since the SAN's performance is only determined by the base capacity. The throughput of an Elastic SAN is distributed among all its volumes.
Elastic SAN scale targets
The appliance scale targets vary depending on the region and redundancy of the SAN itself. The following table breaks out the scale targets based on whether the SAN's redundancy is set to locally-redundant storage (LRS) or zone-redundant storage (ZRS) and what region the SAN is in.
LRS
Resource | France Central | Southeast Asia | West US 2 |
Maximum number of Elastic SAN that can be deployed per subscription per region | 5 | 5 | 5 |
Maximum total capacity (TiB) | 100 | 100 | 600 |
Maximum base capacity (TiB) | 100 | 100 | 400 |
Minimum total capacity (TiB) | 1 | 1 | 1 |
Maximum total IOPS | 500,000 | 500,000 | 2,000,000 |
Maximum total throughput (MB/s) | 8,000 | 8,000 | 32,000 |
ZRS is only available in France Central and West US 2.
Resource | France Central | West US 2 |
Maximum number of Elastic SAN that can be deployed per subscription per region | 5 | 5 |
Maximum total capacity (TiB) | 200 | 200 |
Maximum base capacity (TiB) | 100 | 100 |
Minimum total capacity (TiB) | 1 | 1 |
Maximum total IOPS | 500,000 | 500,000 |
Maximum total throughput (MB/s) | 8,000 | 8,000 |
Volume group
An Elastic SAN can have a maximum of 20 volume groups, and a volume group can contain up to 1,000 volumes.
Volume
The performance of an individual volume is determined by its capacity. The maximum IOPS of a volume increases by 750 per GiB, up to a maximum of 64,000 IOPS. The maximum throughput increases by 60 MB/s per GiB, up to a maximum of 1,024 MB/s. A volume needs at least 86 GiB to be capable of using 64,000 IOPS. A volume needs at least 18 GiB in order to be capable of using the maximum of 1,024 MB/s. The combined IOPS and throughput of all your volumes can't exceed the IOPS and throughput of your SAN.
Volume scale targets
Supported capacities | Maximum potential IOPS | Maximum potential throughput (MB/s) |
1 GiB - 64 TiB | 750 - 64,000 (increases by 750 per GiB) | 60 - 1,024 (increases by 60 per GiB) |
Plan for deploying an Elastic SAN
Before deploying an Elastic SAN (preview), consider the following:
How much storage do you need?
What level of performance do you need?
What type of redundancy do you require?
Answering those three questions can help you successfully provision an SAN that meets your needs.
Storage and performance
There are two layers when it comes to performance and storage: the total storage and performance that an Elastic SAN has and the performance and storage of individual volumes.
Elastic SAN
There are two ways to provision storage for an Elastic SAN: You can either provision base capacity or additional capacity. Each TiB of base capacity also increases your SAN's IOPS and throughput (MB/s) but costs more than each TiB of additional capacity. Increasing additional capacity doesn't increase your SAN's IOPS or throughput (MB/s).
When provisioning storage for an Elastic SAN, consider how much storage you require and how much performance you require. Using a combination of base capacity and additional capacity to meet these requirements allows you to optimize your costs. For example, if you needed 100 TiB of storage but only needed 250,000 IOPS and 4,000 MB/s, you could provision 50 TiB in your base capacity and 50 TiB in your additional capacity.
Volumes
You create volumes from the storage that you provisioned to your Elastic SAN. When you create a volume, think of it like partitioning a section of the storage of your Elastic SAN. The maximum performance of an individual volume is determined by the amount of storage allocated to it. Individual volumes can have fairly high IOPS and throughput, but the total IOPS and throughput of all your volumes can't exceed the total IOPS and throughput your SAN has.
Using the same example of a 100 TiB SAN that has 250,000 IOPS and 4,000 MB/s. Say this SAN had 100 1 TiB volumes. You could potentially have three of these volumes operating at their maximum performance (64,000 IOPS, 1,024 MB/s) since this would be below the SAN's limits. But if four or five volumes all needed to operate at maximum at the same time, they wouldn't be able to. Instead, the performance of the SAN would be split evenly among them.
Networking
In Preview, Elastic SAN supports public endpoint from selected virtual networks, restricting access to specified virtual networks. You configure volume groups to allow network access only from specific Vnet subnets. Once a volume group is configured to allow access from a subnet, this configuration is inherited by all volumes belonging to the volume group. You can then mount volumes from any clients in the subnet using the internet Small Computer Systems Interface (iSCSI) protocol. Note that you need to first enable [service point for Azure Storage] (../../virtual-network/virtual-network-service-endpoints-overview.md) in your virtual network before setting up the network rule on the volume group.
Redundancy
To protect the data in your Elastic SAN against data loss or corruption, all SANs store multiple copies of each file as they're written. Depending on the requirements of your workload, you can select additional degrees of redundancy. The following data redundancy options are currently supported:
Locally-redundant storage (LRS)
With LRS, every SAN is stored three times within an Azure storage cluster. This protects against loss of data due to hardware faults, such as a bad disk drive. However, if a disaster such as fire or flooding occurs within the data center, all replicas of an Elastic SAN using LRS may be lost or unrecoverable.
Zone-redundant storage (ZRS)
With ZRS, three copies of each SAN are stored in three distinct and physically isolated storage clusters in different Azure availability zones. Availability zones are unique physical locations within an Azure region. Each zone is made up of one or more data centers equipped with independent power, cooling, and networking. A write request to storage that is using ZRS happens synchronously. The write operation only returns successfully after the data is written to all replicas across the three availability zones.
Encryption
All data stored in an Elastic SAN is encrypted at rest using Azure storage service encryption (SSE). Storage service encryption works similarly to BitLocker on Windows: data is encrypted beneath the file system level. SSE protects your data and helps you to meet your organizational security and compliance commitments. Data stored in Elastic SAN is encrypted with Microsoft-managed keys. With Microsoft-managed keys, Microsoft holds the keys to encrypt/decrypt the data and is responsible for rotating them regularly.
Data in an Azure Elastic SAN is encrypted and decrypted transparently using 256-bit AES encryption, one of the strongest block ciphers available, and is FIPS 140-2 compliant. Encryption is enabled for all Elastic SANs and can't be disabled. Because your data is secured by default, you don't need to modify your code or applications to take advantage of SSE. There's no extra cost for SSE.