Azure Elastic SAN — Simply Explained

Azure Elastic SAN addresses a storage problem that often appears only after an Azure environment begins to grow. One virtual machine with one Managed Disk is simple. But as more VMs, databases, and applications appear, each workload can end up with separate disks, separate performance limits, and separate capacity decisions. The result can be inefficient: one workload may be paying for storage performance it rarely uses while another workload needs additional capacity that it cannot borrow. Azure Elastic SAN approaches this differently by providing high-performance block storage through a shared pool. ㅤ WHY SEPARATE DISKS CAN BECOME A PROBLEM Azure Managed Disks work extremely well for many individual virtual machines. The challenge appears when environments contain many workloads with different performance patterns. A SQL database might experience its highest load at month-end. A reporting server could become busy every morning. Backup workloads might consume significant storage bandwidth overnight while other systems remain almost idle. When every workload is sized individually for its own peak, organizations can end up paying for performance that remains unused for much of the time. ㅤ UNDERSTANDING IOPS AND THROUGHPUT Two important concepts when discussing storage performance are IOPS and throughput. IOPS means input and output operations per second. It describes how many individual storage operations can be performed each second. Databases frequently generate large numbers of small reads and writes, making IOPS particularly important. Throughput describes how much data can move during a period of time, usually measured in megabytes per second. Large backups, file transfers, and analytical workloads may depend heavily on throughput. Different workloads require different combinations of both. ㅤ THE VM CAN ALSO BECOME THE BOTTLENECK Adding more or faster disks doesn't automatically solve every storage-performance problem. Azure virtual machines themselves have limits for total disk IOPS and throughput depending on their size. That means you can attach powerful disks and still encounter a bottleneck because the VM cannot process additional storage traffic. The storage might theoretically provide more performance while the path through the virtual machine has already reached its limit. ㅤ WHAT IS A STORAGE AREA NETWORK? Traditional data centers have addressed similar challenges for years using Storage Area Networks, commonly called SANs. Instead of giving every server completely independent storage infrastructure, organizations create centralized storage systems that multiple servers can access. Azure Elastic SAN brings this familiar shared-storage model into Azure without requiring organizations to purchase storage controllers, install physical storage arrays, wire racks, or maintain SAN hardware themselves. ㅤ WHAT IS AZURE ELASTIC SAN? Azure Elastic SAN is managed block storage in Azure designed around a shared storage pool. Think of it as a central storage room. Inside that storage environment, individual workloads receive their own separate volumes. The workloads remain logically separated, but the underlying storage capacity and performance can be managed as part of a larger shared resource. A virtual machine can access an Elastic SAN volume similarly to a disk, format it, and store application or database data on it. ㅤ WHAT IS BLOCK STORAGE? Block storage allows applications to read and write small blocks of data directly. This is particularly important for applications such as SQL Server. A database doesn't simply need somewhere to store ordinary files. It performs large numbers of controlled reads and writes against database files, transaction logs, indexes, and other data structures. Elastic SAN provides this disk-like block-storage model through a network connection. ㅤ HOW ISCSI CONNECTS THE STORAGE Azure Elastic SAN volumes connect to workloads using iSCSI. iSCSI stands for Internet Small Computer Systems Interface. The terminology sounds complicated, but the basic concept is straightforward: iSCSI carries storage commands between the server and the Elastic SAN across a network connection. The VM requests a particular block of data or sends a write operation. That request travels to Elastic SAN, and the storage system responds. From the workload's perspective, the result behaves much like locally attached block storage. ㅤ ELASTIC SAN VS OTHER AZURE STORAGE SERVICES Elastic SAN doesn't replace every other Azure storage service. Azure Blob Storage is designed for object storage such as images, videos, backups, and other files. Azure Files provides network-accessible shared file systems. Azure Managed Disks remain a straightforward choice when an individual VM needs its own dedicated block-storage disk. Elastic SAN occupies a different position: centralized high-performance block storage for workloads that can benefit from sharing a larger storage pool. ㅤ THE SHARED PERFORMANCE MODEL One of the most important differences is how Elastic SAN handles performance. According to the episode material, every 1 TiB of base capacity contributes 5,000 IOPS and 200 MB per second of throughput to the SAN. That performance belongs to the SAN pool rather than being reserved exclusively for one individual workload. This allows different volumes to consume available performance according to their needs, provided the overall SAN and individual volume limits aren't exceeded. ㅤ THE THREE BUILDING BLOCKS Azure Elastic SAN has three primary organizational layers: SAN. Volume groups. Volumes. The SAN represents the overall storage resource. Volume groups organize related workloads and their connectivity. Volumes provide the actual block-storage units that applications and servers consume. ㅤ THE SAN The SAN is the top-level Azure resource. This is where you define overall storage capacity, available performance, and redundancy choices. Instead of creating every piece of storage as an entirely independent resource, you establish the larger SAN and then organize the storage required by individual applications underneath it. ㅤ VOLUME GROUPS Volume groups provide a management boundary for related storage volumes. For example, an organization might create one volume group for production SQL Server databases, another for development environments, and another for Azure Kubernetes Service workloads. Different groups can have different network connectivity requirements. By applying connection rules at the volume-group level, new volumes can inherit the appropriate configuration instead of administrators repeatedly configuring connectivity for every new volume. ㅤ VOLUMES Volumes are the actual storage units consumed by workloads. A SQL Server might use one volume for database files and another for transaction logs. An AKS application could use a volume for persistent application data. Clustered applications can use volumes according to their supported shared-storage architecture. Each volume remains separate even though multiple volumes share the same underlying SAN. ㅤ SHARED DOES NOT MEAN ONE GIANT DISK A common misunderstanding is that a shared SAN means every application writes to the same storage volume. That's not how Elastic SAN works. Each volume remains its own storage unit with its own size and performance limitations. The SAN provides the wider pool of storage capacity and performance, while individual volumes define what specific workloads can connect to and consume. ㅤ PRIVATE STORAGE ACCESS Elastic SAN storage isn't designed to be exposed directly to the public internet. Organizations establish private network paths and control which workloads can connect through volume groups. This provides a defined network boundary around the storage environment and helps organizations control which systems are allowed to access individual groups of volumes. ㅤ HOW SHARED PERFORMANCE CHANGES STORAGE DESIGN Imagine four SQL databases. The sales database is busiest during normal business hours. Finance generates heavy reports around month-end. A warehouse system performs intensive processing overnight. Another database experiences a large weekly import. With individually provisioned disks, each workload might need enough storage performance for its own maximum demand. Elastic SAN allows those volumes to draw from a shared performance budget. When finance requires additional IOPS while the warehouse system is quiet, finance can potentially use more of the available SAN performance. Later, the available performance can shift toward another workload. ㅤ SHARED PERFORMANCE IS NOT UNLIMITED PERFORMANCE Pooling resources doesn't create unlimited storage performance. If several workloads become extremely busy simultaneously and their combined demand exceeds what the SAN can provide, the additional requests can be throttled. This can increase latency and reduce application performance. Administrators therefore need to understand not only the individual workloads but also their combined peak demand. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.