Microsoft’s Azure cloud is previewing an Elastic SAN service offering high-availability iSCSI-access block storage.
This storage instance is designed, Microsoft said, “for large scale IO-intensive workloads and top tier databases such as SQL, MariaDB, and supports hosting the workloads on virtual machines, or containers such as Azure Kubernetes Service.”
It should help on-premises apps using iSCSI storage migrate to the Azure cloud.
Think of it as a logical external SAN array for Azure compute instances, which is built from Azure storage drives and has the ability to scale compute (IOPS and GB/sec throughput) and capacity in lockstep or separately. Performance can go up to millions of IOPS at SAN level, 64,000 IOPS at volume level, double-digit GB/sec bandwidth, and <10ms latency.
The overall SAN performance is shared across all of its volumes as long as the SAN’s upper limits aren’t exceeded. If the volumes are large enough capacity-wise, each volume can scale up to 64,000 IOPs so long as the sum of volume IOPS does not exceed the SAN’s IOPS maximum.
We’re told that the Elastic SAN’s iSCSI protocol enables volumes “to bypass the IOPS limit of an Azure VM and offers high throughput limits.” Finding out an Azure VM’s IOPS limit is complex as it varies with cached and uncached VMs. You can find out more here.
Elastic SAN is built from volumes, logical storage drives that can be put into volume groups to which you can grant access and apply Azure virtual network rules.
Storage is provisioned in TiB units with base capacity and/or additional capacity. Provisioning base capacity provides both capacity and compute power, meaning IOPS and throughput (MB/sec). Additional capacity provisioning provides only capacity; it has no compute associated with it, and costs less than base capacity.
Microsoft provides an 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.”
A volume is a partitioned section of your SAN’s capacity. Microsoft said: “The maximum performance of an individual volume is determined by the amount of storage allocated to it … the total IOPS and throughput of all your volumes can’t exceed the total IOPS and throughput your SAN has.”
The 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.”
Azure Elastic SAN supports 256-bit AES encryption at rest, but not in transit, and both LRS (Locally Redundant Storage) and ZRS (Zone-Redundant Storage) redundancy types. With LRS, every SAN is stored three times within an Azure storage cluster while with ZRS three copies of each SAN are stored in three distinct and physically isolated storage clusters in different Azure availability zones.
AWS block storage and Google Cloud
AWS has its Elastic Block Store (EBS) providing block-level storage volumes for use with EC2 instances and also Instance Store, which is directly attached, block-device storage for use with EC2 instance types. “The instance store is ideal for temporary storage, because the data stored in instance store volumes is not persistent through instance stops, terminations, or hardware failures.” This differs from EBS as “EBS volumes preserve their data through instance stops and terminations, can be easily backed up with EBS snapshots, can be removed from one instance and reattached to another, and support full-volume encryption.”
Amazon also has a Virtual Storage Array (VSA) construct in its cloud: “AWS instances connect to the VSA through a subnet which forms a SAN, and can share access for a number of high-powered instances. The only limit to the storage performance of a particular instance is 1) the network between the client instance and the VSA, and 2) the number of VSA controllers.”
This has compute presented as VSA controllers and capacity expressed as volumes which can use NVMe drives. AWS’s block storage does not expose an iSCSI access method.
Google Cloud provides Persistent Disks for block storage and these are equivalent to direct-attached disk or solid state storage drives. It does not have the equivalent of SAN storage.
