Azure Elastic SAN for Storage Architecture

Azure Elastic SAN is a fully managed, cloud-native Storage Area Network (SAN) service that provides scalable, high-performance block storage for Azure compute resources. It is designed for workloads that require consistent low-latency performance, large capacity, and the ability to scale performance and capacity independently. Unlike Azure Managed Disks, which are attached to a single VM and have fixed performance tiers, Elastic SAN allows you to create a pool of storage that can be shared across multiple VMs, with performance (IOPS and throughput) that scales linearly with the provisioned capacity and performance units.

Traditional Azure Managed Disks have limitations: each disk has a maximum IOPS and throughput based on its size and tier, and scaling performance often requires migrating to a larger disk or adding more disks with striping. For large-scale databases (e.g., SQL Server, Oracle), SAP HANA, or analytics workloads that need consistent performance across many VMs, managed disks can become complex and costly. Elastic SAN solves this by decoupling storage performance from individual VM disks, allowing a single SAN to serve multiple VMs with predictable performance. It also provides built-in redundancy and high availability without requiring application-level replication.

Azure Elastic SAN is built on a distributed storage architecture. The SAN consists of a group of storage nodes (physical or virtual) that pool their capacity and performance. When you create an Elastic SAN, you define a total capacity (e.g., 50 TiB) and a performance tier (e.g., Premium, with specific IOPS per GiB). The system then allocates storage resources across multiple nodes in an Azure region, within an availability zone if specified. The SAN exposes iSCSI targets (volumes) that can be connected to VMs over the Azure network. Each volume has its own LUN (Logical Unit Number) and is accessed via iSCSI initiators on the VMs.

Internally, data is striped across multiple nodes for performance and redundancy. The SAN uses a distributed metadata store to track the location of data blocks. When a VM sends a read or write request, the iSCSI initiator forwards it to the SAN's front-end load balancer, which routes it to the appropriate storage node. The node processes the request, and if the data is replicated synchronously (for Premium), it writes to multiple nodes before acknowledging the write. This ensures durability and consistency.

To create an Elastic SAN using Azure CLI:

# Create a resource group
az group create --name MyRG --location eastus

# Create an Elastic SAN
az elastic-san create --resource-group MyRG --name MySAN --location eastus --sku-tier Premium --capacity 10240 --base-size 10240

# Create a volume group
az elastic-san volume-group create --resource-group MyRG --san-name MySAN --name MyVolGroup --network-acls default-action=Allow

# Create a volume
az elastic-san volume create --resource-group MyRG --san-name MySAN --volume-group-name MyVolGroup --name MyVolume --size 1024

# List iSCSI targets for a volume group
az elastic-san volume-group list-iscsi-target --resource-group MyRG --san-name MySAN --volume-group-name MyVolGroup

To connect a Linux VM to the SAN:

# Install iSCSI initiator
sudo apt-get install open-iscsi

# Discover targets
sudo iscsiadm -m discovery -t st -p <target-ip>:3260

# Login to target
sudo iscsiadm -m node -T <target-name> -p <target-ip>:3260 -l

# Verify connection
sudo iscsiadm -m session -o show

Verification: Use az elastic-san list to see SANs, and az elastic-san volume list to see volumes. Monitor performance metrics via Azure Monitor (e.g., IOPS, throughput, latency).

Elastic SAN integrates with: - Azure Private Link: For private connectivity between VNets and the SAN. - Azure Backup: Supports backup of Elastic SAN volumes using Azure Backup. - Azure Site Recovery: Can replicate volumes to another region for disaster recovery. - Azure Kubernetes Service (AKS): Can be used as persistent storage for stateful workloads via CSI driver. - Azure NetApp Files: Another enterprise-grade file and block storage service, but with different performance profiles (NetApp uses NFS and SMB, while Elastic SAN is iSCSI only).

Elastic SAN is NOT a replacement for Azure Files (file shares) or Azure Blob (object storage). It is strictly block storage accessed over iSCSI.

Performance is determined by the total provisioned capacity and the performance tier. Because performance scales linearly, you can increase IOPS by adding more capacity (even if you don't need the space). However, this increases cost. Alternatively, you can choose a higher performance tier (e.g., Premium vs. Standard). The SAN also supports bursting: when workloads exceed baseline, they can burst up to the maximum performance for short periods (up to 30 minutes), similar to managed disks.

Elastic SAN supports locally redundant storage (LRS) and zone-redundant storage (ZRS). LRS replicates data three times within a single availability zone. ZRS replicates across three availability zones in the same region, providing higher availability. For disaster recovery, you must replicate data to another region using Azure Site Recovery or backup.

You pay for the provisioned capacity (in TiB) per month, plus the performance tier premium. There is no charge for IOPS or throughput beyond the baseline (they are included in the capacity price). For example, a 10 TiB Premium SAN costs more than a 10 TiB Standard SAN. You can also reserve capacity for 1 or 3 years to save up to 40%.

A financial services company runs hundreds of SQL Server databases across multiple VMs. Each database requires high IOPS (e.g., 50,000 IOPS) and low latency (sub-millisecond). Previously, they used P60 managed disks (16 TiB each, 75,000 IOPS), but the cost was high and they had to overprovision capacity to get the performance. They migrated to Azure Elastic SAN: a single 50 TiB Premium SAN providing 3 million IOPS baseline. They created volume groups for different environments (prod, dev, test) and connected each SQL VM via iSCSI. They configured CHAP authentication for security. The result: consistent performance, lower cost (no overprovisioning), and the ability to scale IOPS by increasing SAN capacity without touching VMs. Common misconfiguration: not enabling multipathing (MPIO) on the VMs, leading to single-path failures and lower throughput. They also set up Azure Backup for volume-level backups.

An enterprise runs SAP HANA on Azure using a scale-out architecture with multiple worker nodes. HANA requires high throughput and low latency for log writes. They use Azure Elastic SAN as shared storage for the HANA data and log volumes. Each worker node connects to the same SAN volumes via iSCSI. The SAN is configured with ZRS for high availability within the region. They provisioned a 30 TiB SAN with Premium tier. The key benefit: independent scaling of compute and storage. When they needed more HANA memory, they added more VMs without migrating data. When they needed more storage, they increased the SAN capacity. Pitfall: forgetting to set the volume group's network ACLs correctly, causing connectivity issues. They also use Azure Private Link to ensure traffic stays within the Microsoft backbone.

A media company uses Azure Batch to render videos. Each render job writes large files to shared storage. They need high throughput (multiple GB/s) for reading and writing. They use Elastic SAN with Standard tier (lower cost) because latency is less critical. They provision a 100 TiB SAN (max default) and create multiple volumes striped across VMs using software RAID. The SAN provides 50 GB/s throughput baseline. They connect each render VM via iSCSI. The challenge: iSCSI overhead can reduce CPU efficiency for rendering, so they use larger VMs with dedicated iSCSI offload. They also monitor the SAN's throughput to avoid hitting the limit. When they hit the limit, they increase capacity (and thus throughput) by adding more capacity, even if they don't need the space. This is a common exam scenario: knowing that performance scales with capacity.