Image by Thought Catalog

Post Details

  • ALIF Consulting

What is Azure Elastic SAN

Updated: 14 hours ago

About Alif : Alif empowers Microsoft MSP-CSP partners to provide exceptional IT services to their clients to ensure that the partners reduce their costs and focus on their business. We provide white-labelled managed services for technologies like Microsoft Azure, Microsoft 365, Microsoft Dynamics 365, Microsoft Security, SharePoint, Power Platform, SQL, Azure DevOps and a lot more. Our headquarter is in Pune, India whereas we work with over 50 partners across the globe that trust us with their client delivery.


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 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 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 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 provision 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 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 1 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 are 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 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 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


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 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: 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 network, 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, with 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 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 to help 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.



5 views0 comments