^{Courtesy Alif Consulting}

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, MariaDB, and support 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 a wide variety of compute resources using the internet Small Computer Systems Interface (iSCSI) protocol. Because of this, rather than having to configure storage for each of compute options, it 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 Elastic SAN can manage a large number of volumes from a single resource. For instance, it can create virtual network rules on the volume group and grant access to all the required 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 have single-digit millisecond latency. The performance of a SAN is shared across all of its volumes, 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 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 which can increase the SAN storage in bulk. Therefore, SAN can either increase 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, generally won't need to overprovision volumes, because it shares 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 configuring an Elastic SAN, select the redundancy of the entire SAN and provision storage. The storage provisioned determines how much performance SAN has, and the total capacity that can be distributed to each volume within the SAN.

The 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 are used 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.

In addition, volume group's name has some requirements. The name may only contain lowercase letters, numbers and hyphens, and 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

Partition the SAN's storage capacity into individual volumes. These individual volumes can be mounted to clients with iSCSI.

The name of the 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.

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 the 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 SAN is determined by the region where it's located and by its redundancy configuration. The minimum total capacity for an Elastic SAN is 1 tebibyte (TiB). Base or additional capacity can be increased in increments of 1 TiB.

IOPS

The IOPS of an Elastic SAN increase by 5,000 per base TiB. Therefore if 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 are distributed among all its volumes.

Throughput

The throughput of an Elastic SAN increases by 80 MB/s per base TiB. If, for example 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 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

ZRS is only available in France Central and West US 2.

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 increase 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 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

Plan for deploying an Elastic SAN

Before deploying an Elastic SAN (preview), consider the following:

• How much storage required?
• What level of performance do needed?
• What type of redundancy is required?

Answering those three questions can help you to successfully provision a 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: 

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

2. When provisioning storage for an Elastic SAN, consider how much storage is required and how much performance needed require. Using a combination of base capacity and additional capacity to meet these requirements allows for the optimization of costs. For example, the requirement is for100 TiB of storage but only needed 250,000 IOPS and 4,000 MB/s, 50 TiB in the base capacity and 50 TiB in the additional capacity.

Volumes

Volumes are created from the storage that is provisioned to the Elastic SAN. When creating a volume, think of it like partitioning a section of the storage of the 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 volumes can't exceed the total IOPS and throughput the SAN has.

Using the same example of a 100 TiB SAN that has 250,000 IOPS and 4,000 MB/s. For example, a particular SAN had 100 1 TiB volumes and an organization 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 network, restricting access to specified virtual networks. Therefore, 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. From there it can then mount volumes from any clients in the subnet, with the internet Small Computer Systems Interface (iSCSI) protocol. 

Note: first requirement is enable [service point for Azure Storage] (../../virtual-network/virtual-network-service-endpoints-overview.md) in the virtual network before setting up the network rule on volume group.

Redundancy

To protect the data in the Elastic SAN against data loss or corruption, all SANs store multiple copies of each file as they're written. Depending on the requirements of the workload, 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, i.e. data is encrypted beneath the file system level. SSE protects the data and to helps to meet the 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. As the data is secured by default, it is not necessary to modify the code, or applications to take advantage of SSE. 

There's no extra cost for SSE.