Aug. 9, 2026
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.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
1
00:00:00,000 --> 00:00:02,680
Most Azure storage problems don't start with a big failure.
2
00:00:02,680 --> 00:00:05,460
They start with one virtual machine and one managed disk.
3
00:00:05,460 --> 00:00:06,540
It seems simple.
4
00:00:06,540 --> 00:00:08,940
Your VM needs a place for its operating system,
5
00:00:08,940 --> 00:00:10,460
app data or database files,
6
00:00:10,460 --> 00:00:12,460
so you attach a disk and forget about it.
7
00:00:12,460 --> 00:00:13,740
Then your company grows.
8
00:00:13,740 --> 00:00:16,780
More VMs show up, more databases need faster storage,
9
00:00:16,780 --> 00:00:19,060
and each machine gets its own set of disks,
10
00:00:19,060 --> 00:00:21,620
its own performance limits, and its own settings.
11
00:00:21,620 --> 00:00:24,540
Soon you find yourself paying for performance on quiet disks
12
00:00:24,540 --> 00:00:26,860
while one busy database waits for more capacity.
13
00:00:26,860 --> 00:00:27,940
That's the tricky part.
14
00:00:27,940 --> 00:00:30,220
You might be paying for storage speed you aren't even using
15
00:00:30,220 --> 00:00:32,580
while another workload can't borrow that spare capacity.
16
00:00:32,580 --> 00:00:34,780
Think of it like separate filing cabinets.
17
00:00:34,780 --> 00:00:36,140
Each one locked to its own worker
18
00:00:36,140 --> 00:00:37,940
with no way to borrow unused space.
19
00:00:37,940 --> 00:00:40,700
That's the problem Azure Elastic Sand is designed to solve.
20
00:00:40,700 --> 00:00:42,740
Azure Elastic Sand takes a different approach.
21
00:00:42,740 --> 00:00:45,380
It puts high performance block storage into a shared pool
22
00:00:45,380 --> 00:00:48,100
instead of locking it inside separate VM disks.
23
00:00:48,100 --> 00:00:50,020
But shared storage only saves money
24
00:00:50,020 --> 00:00:51,940
when your workloads use it the right way.
25
00:00:51,940 --> 00:00:53,220
So let's start with the old layout
26
00:00:53,220 --> 00:00:55,260
and see whether pressure builds.
27
00:00:55,260 --> 00:00:57,860
Why separate disks turn into a storage problem?
28
00:00:57,860 --> 00:00:59,140
Let's walk through a scenario.
29
00:00:59,140 --> 00:01:02,100
Imagine you run a small app on one Azure virtual machine.
30
00:01:02,100 --> 00:01:04,940
You attach a managed disk, choose a type in size,
31
00:01:04,940 --> 00:01:07,180
and the VM sees it like a local hard drive.
32
00:01:07,180 --> 00:01:08,980
For a single server that works well.
33
00:01:08,980 --> 00:01:10,980
It's easy to understand, easy to set up,
34
00:01:10,980 --> 00:01:12,220
and usually the right choice.
35
00:01:12,220 --> 00:01:13,460
But here's where things change.
36
00:01:13,460 --> 00:01:15,620
The trouble begins when that one server turns
37
00:01:15,620 --> 00:01:16,980
into a group of systems.
38
00:01:16,980 --> 00:01:20,060
Maybe you now run SQL Server for your main business app.
39
00:01:20,060 --> 00:01:22,740
You have app servers that write logs and process files.
40
00:01:22,740 --> 00:01:25,340
You have cluster nodes that need fast shared data.
41
00:01:25,340 --> 00:01:27,060
You may also have Kubernetes workloads
42
00:01:27,060 --> 00:01:29,620
that create and remove storage as app scale.
43
00:01:29,620 --> 00:01:31,900
None of these systems stay busy the same way.
44
00:01:31,900 --> 00:01:34,380
Your SQL database might work hard as that month end.
45
00:01:34,380 --> 00:01:36,820
A reporting server may spike early in the morning.
46
00:01:36,820 --> 00:01:40,060
A backup job can push large amounts of data overnight.
47
00:01:40,060 --> 00:01:42,620
Meanwhile, other disks sit mostly quiet.
48
00:01:42,620 --> 00:01:43,580
The goal is simple.
49
00:01:43,580 --> 00:01:46,500
Keep every workload fast enough when it needs storage.
50
00:01:46,500 --> 00:01:48,420
The obstacle, managed disks are usually
51
00:01:48,420 --> 00:01:51,420
planned one disk at a time, and each VM has a limit
52
00:01:51,420 --> 00:01:53,460
on how much disk work it can handle as a whole.
53
00:01:53,460 --> 00:01:55,740
So you'll often hear two terms in this conversation.
54
00:01:55,740 --> 00:01:57,260
Iops and throughput.
55
00:01:57,260 --> 00:01:58,900
Let's clear up what those mean.
56
00:01:58,900 --> 00:02:02,020
Iops stands for input and output operations per second.
57
00:02:02,020 --> 00:02:05,020
In plain English, it counts how many small read or write requests
58
00:02:05,020 --> 00:02:07,140
your storage can handle each second.
59
00:02:07,140 --> 00:02:09,660
A database often sends lots of small requests,
60
00:02:09,660 --> 00:02:12,340
reading a record, updating an order, checking an index.
61
00:02:12,340 --> 00:02:14,500
High Iops helps when many of those small jobs
62
00:02:14,500 --> 00:02:15,260
arrive quickly.
63
00:02:15,260 --> 00:02:16,940
throughput measures the amount of data that
64
00:02:16,940 --> 00:02:18,140
moves each second.
65
00:02:18,140 --> 00:02:19,780
Think of copying a large backup file
66
00:02:19,780 --> 00:02:21,140
or reading a huge report.
67
00:02:21,140 --> 00:02:23,780
You might not need a massive number of tiny requests,
68
00:02:23,780 --> 00:02:26,300
but you do need a wide enough pipe to move a lot of data.
69
00:02:26,300 --> 00:02:29,380
That's throughput, usually measured in megabytes per second,
70
00:02:29,380 --> 00:02:32,180
both matter, but different workloads need different mixes.
71
00:02:32,180 --> 00:02:34,060
And the challenge is that your workloads don't all
72
00:02:34,060 --> 00:02:35,380
fit the same pattern.
73
00:02:35,380 --> 00:02:37,940
Now, picture a company with rows of filing cabinets.
74
00:02:37,940 --> 00:02:39,700
Every employee gets their own cabinet,
75
00:02:39,700 --> 00:02:41,620
and each cabinet has a fixed number of drawers
76
00:02:41,620 --> 00:02:43,420
and a fixed speed for opening them.
77
00:02:43,420 --> 00:02:46,260
One person has a cabinet packed with urgent work.
78
00:02:46,260 --> 00:02:47,980
The cabinet beside it has empty drawers
79
00:02:47,980 --> 00:02:49,100
and no one touching it.
80
00:02:49,100 --> 00:02:51,180
Yet the busy person can't use that spare capacity
81
00:02:51,180 --> 00:02:52,540
because it belongs to someone else.
82
00:02:52,540 --> 00:02:54,500
That's what can happen with separate disks.
83
00:02:54,500 --> 00:02:56,340
You end up paying for a cabinet with extra drawers
84
00:02:56,340 --> 00:02:58,060
that nobody uses while another person
85
00:02:58,060 --> 00:02:59,500
struggles with a slow cabinet.
86
00:02:59,500 --> 00:03:02,300
You might choose a larger or faster disk for a database
87
00:03:02,300 --> 00:03:05,020
because it needs a short burst of performance once a day.
88
00:03:05,020 --> 00:03:06,900
For the rest of the day, much of that performance
89
00:03:06,900 --> 00:03:08,140
sits unused.
90
00:03:08,140 --> 00:03:10,220
Then you repeat that choice for another database,
91
00:03:10,220 --> 00:03:12,700
just in case it also gets busy.
92
00:03:12,700 --> 00:03:15,220
The bill grows from all that just in case performance.
93
00:03:15,220 --> 00:03:17,620
A common answer is fine, add more disks.
94
00:03:17,620 --> 00:03:18,820
Sometimes that helps.
95
00:03:18,820 --> 00:03:21,140
A VM can spread work across several disks
96
00:03:21,140 --> 00:03:23,380
and software inside the VM can combine them,
97
00:03:23,380 --> 00:03:25,860
but adding disks doesn't remove every limit.
98
00:03:25,860 --> 00:03:27,940
The VM itself still has a total disk iOps
99
00:03:27,940 --> 00:03:30,300
and throughput ceiling based on its size.
100
00:03:30,300 --> 00:03:32,820
The VM's disk limit acts like a bottleneck.
101
00:03:32,820 --> 00:03:34,620
No matter how fast the disk is,
102
00:03:34,620 --> 00:03:37,220
the road to the VM can only carry so much traffic.
103
00:03:37,220 --> 00:03:39,580
So you can buy faster disks, attach more of them,
104
00:03:39,580 --> 00:03:41,540
and still find that the VM can't push
105
00:03:41,540 --> 00:03:43,460
the amount of storage traffic you expected.
106
00:03:43,460 --> 00:03:45,340
That's frustrating because the storage may have room
107
00:03:45,340 --> 00:03:47,380
to work harder, but the route through the VM
108
00:03:47,380 --> 00:03:49,700
has reached its limit on premises data centers
109
00:03:49,700 --> 00:03:52,980
dealt with this for years through a storage area network or sand.
110
00:03:52,980 --> 00:03:54,500
Instead of treating every server storage
111
00:03:54,500 --> 00:03:57,180
like a private cabinet, teams built a central storage room
112
00:03:57,180 --> 00:03:59,140
that many servers could connect to.
113
00:03:59,140 --> 00:04:02,300
Azure Elastic Sand brings that shared room idea into Azure
114
00:04:02,300 --> 00:04:05,340
without asking you to buy storage controllers, wire up racks,
115
00:04:05,340 --> 00:04:06,900
or look after sand hardware.
116
00:04:06,900 --> 00:04:08,540
And that's why separate disks can turn
117
00:04:08,540 --> 00:04:10,260
into a real storage problem.
118
00:04:10,260 --> 00:04:12,700
What Azure Elastic Sand actually is?
119
00:04:12,700 --> 00:04:14,820
So what actually is Azure Elastic Sand?
120
00:04:14,820 --> 00:04:17,540
In plain English, it's managed block storage in Azure,
121
00:04:17,540 --> 00:04:20,660
designed as a shared pool for workloads that need fast storage.
122
00:04:20,660 --> 00:04:22,620
Here's a simple way to think about it.
123
00:04:22,620 --> 00:04:25,540
Imagine an office building with one central record's room.
124
00:04:25,540 --> 00:04:28,620
Inside that room, there are many locked drawers with clear labels.
125
00:04:28,620 --> 00:04:31,700
The finance team has its drawers, the sales system has its drawers,
126
00:04:31,700 --> 00:04:33,300
a database has its own drawers too.
127
00:04:33,300 --> 00:04:34,660
They keep their own files separate,
128
00:04:34,660 --> 00:04:36,420
but the building manages the room
129
00:04:36,420 --> 00:04:38,740
and it's available storage power in one place.
130
00:04:38,740 --> 00:04:40,140
The Elastic Sand works the same way.
131
00:04:40,140 --> 00:04:41,420
It's the central storage room.
132
00:04:41,420 --> 00:04:43,140
You create separate volumes inside it,
133
00:04:43,140 --> 00:04:45,580
and each volume acts like a block device
134
00:04:45,580 --> 00:04:47,460
that a workload can use as storage,
135
00:04:47,460 --> 00:04:50,700
a virtual machine sees that volume much like it sees a local disk,
136
00:04:50,700 --> 00:04:52,860
then formats it and stores data on it.
137
00:04:52,860 --> 00:04:54,420
Block storage means the workload reads
138
00:04:54,420 --> 00:04:56,420
and writes small chunks of data directly.
139
00:04:56,420 --> 00:04:58,540
That matters for systems like databases.
140
00:04:58,540 --> 00:05:00,420
SQL Server doesn't want to save a document
141
00:05:00,420 --> 00:05:02,340
in a shared folder and hope for the best.
142
00:05:02,340 --> 00:05:05,580
It needs controlled, fast reads and writes to data files,
143
00:05:05,580 --> 00:05:08,580
log files, and other pieces that keep the database running.
144
00:05:08,580 --> 00:05:11,500
Elastic Sand gives workloads that disc-like storage experience,
145
00:05:11,500 --> 00:05:13,100
but the storage connects over the network
146
00:05:13,100 --> 00:05:15,780
instead of attaching as a standard Azure managed disk.
147
00:05:15,780 --> 00:05:18,620
That connection uses something called ICSI.
148
00:05:18,620 --> 00:05:21,740
ISSI stands for Internet Small Computer Systems Interface,
149
00:05:21,740 --> 00:05:22,980
but don't worry about the full name.
150
00:05:22,980 --> 00:05:24,180
Think of it as a private route
151
00:05:24,180 --> 00:05:26,100
that carries storage commands between a server
152
00:05:26,100 --> 00:05:27,740
and the Elastic Sand.
153
00:05:27,740 --> 00:05:28,980
Your VM sends a request.
154
00:05:28,980 --> 00:05:31,180
Read this data block, write this database log entry,
155
00:05:31,180 --> 00:05:32,540
return this part of the file.
156
00:05:32,540 --> 00:05:35,060
The request travels over a dedicated network connection
157
00:05:35,060 --> 00:05:37,180
to the SAN and the SAN response.
158
00:05:37,180 --> 00:05:39,020
To the workload, it looks like another local disk.
159
00:05:39,020 --> 00:05:40,500
This doesn't mean Elastic Sand replaces
160
00:05:40,500 --> 00:05:42,100
every Azure storage service.
161
00:05:42,100 --> 00:05:44,020
Blob storage is built for objects like backups,
162
00:05:44,020 --> 00:05:45,220
images, and video files.
163
00:05:45,220 --> 00:05:47,860
It's more like a warehouse where you store named boxes.
164
00:05:47,860 --> 00:05:49,460
Azure files gives you shared folders
165
00:05:49,460 --> 00:05:51,700
that people and apps can access over a network.
166
00:05:51,700 --> 00:05:53,500
It behaves like a company file share.
167
00:05:53,500 --> 00:05:55,380
Managed disks are still the simple choice
168
00:05:55,380 --> 00:05:58,340
for many virtual machines that meet their own dedicated disk.
169
00:05:58,340 --> 00:06:00,940
Elastic SAN sits in a different part of the picture.
170
00:06:00,940 --> 00:06:03,300
It provides central high-performance block storage
171
00:06:03,300 --> 00:06:05,140
for workloads that benefit from sharing
172
00:06:05,140 --> 00:06:06,500
a larger storage pool.
173
00:06:06,500 --> 00:06:08,140
And because Azure runs the service,
174
00:06:08,140 --> 00:06:10,540
you don't manage the physical SAN equipment behind it.
175
00:06:10,540 --> 00:06:12,900
No storage racks to order, no controllers to replace,
176
00:06:12,900 --> 00:06:15,740
no physical cables between servers and the storage array.
177
00:06:15,740 --> 00:06:18,060
Azure handles the hardware behind the scenes
178
00:06:18,060 --> 00:06:20,660
while you configure the capacity, performance level,
179
00:06:20,660 --> 00:06:22,860
network path, and volumes your workloads need.
180
00:06:22,860 --> 00:06:24,860
The performance model is where this gets interesting.
181
00:06:24,860 --> 00:06:26,900
Elastic SAN includes base capacity,
182
00:06:26,900 --> 00:06:29,660
and that base capacity brings performance with it.
183
00:06:29,660 --> 00:06:31,620
For every one TIE-B of base capacity,
184
00:06:31,620 --> 00:06:35,380
the SAN receives 5,000 IOPS and 200 medabyte per second
185
00:06:35,380 --> 00:06:36,300
of throughput.
186
00:06:36,300 --> 00:06:39,300
These numbers belong to the SAN pool, not just one volume.
187
00:06:39,300 --> 00:06:40,740
So if you build a larger pool,
188
00:06:40,740 --> 00:06:42,380
you create more shared room for workloads
189
00:06:42,380 --> 00:06:44,660
that need fast reads and writes at different times.
190
00:06:44,660 --> 00:06:45,820
You still need to plan carefully
191
00:06:45,820 --> 00:06:48,340
because all workloads can't demand the full pool at once
192
00:06:48,340 --> 00:06:49,460
without consequences.
193
00:06:49,460 --> 00:06:51,260
But the storage isn't one giant disc
194
00:06:51,260 --> 00:06:53,580
that every app touches without structure.
195
00:06:53,580 --> 00:06:55,020
Azure divides it into layers,
196
00:06:55,020 --> 00:06:57,420
and the next layer explains how you keep related workloads
197
00:06:57,420 --> 00:07:00,180
organized and control who can connect.
198
00:07:00,180 --> 00:07:01,940
The three building blocks.
199
00:07:01,940 --> 00:07:04,620
SAN, volume groups, and volumes.
200
00:07:04,620 --> 00:07:07,540
Inside Azure Elastic SAN, you work with three layers,
201
00:07:07,540 --> 00:07:09,540
the SAN, volume groups, and volumes.
202
00:07:09,540 --> 00:07:11,820
Think of the SAN as the top-level storage space.
203
00:07:11,820 --> 00:07:14,300
This is where you set the overall capacity,
204
00:07:14,300 --> 00:07:15,740
total performance for the pool,
205
00:07:15,740 --> 00:07:17,380
and redundancy choice for the data.
206
00:07:17,380 --> 00:07:19,180
It's the main Azure resource you create
207
00:07:19,180 --> 00:07:20,980
before any workload connects.
208
00:07:20,980 --> 00:07:23,580
A SAN can hold many related storage volumes.
209
00:07:23,580 --> 00:07:25,220
That means you no longer need to treat
210
00:07:25,220 --> 00:07:27,540
every piece of storage as a separate thing
211
00:07:27,540 --> 00:07:30,540
with separate network settings and separate management work.
212
00:07:30,540 --> 00:07:32,780
You start with one larger storage resource,
213
00:07:32,780 --> 00:07:34,740
then organize its contents to match the teams
214
00:07:34,740 --> 00:07:35,900
and apps that use it.
215
00:07:35,900 --> 00:07:37,900
Under the SAN, you create volume groups.
216
00:07:37,900 --> 00:07:39,860
A volume group is a management boundary
217
00:07:39,860 --> 00:07:40,980
for related volumes.
218
00:07:40,980 --> 00:07:43,260
You might create one for production SQL Server workloads,
219
00:07:43,260 --> 00:07:45,300
another for test and development databases,
220
00:07:45,300 --> 00:07:48,580
and a third for an Azure Kubernetes Service or AKS environment.
221
00:07:48,580 --> 00:07:51,140
Those workloads can live in the same elastic SAN,
222
00:07:51,140 --> 00:07:53,300
but they don't need to share the same connection rules.
223
00:07:53,300 --> 00:07:54,980
For example, your production SQL servers
224
00:07:54,980 --> 00:07:57,340
might sit on one private network and your test servers
225
00:07:57,340 --> 00:07:58,020
on another.
226
00:07:58,020 --> 00:08:00,220
Instead of setting up network access over and over
227
00:08:00,220 --> 00:08:01,620
for every new database volume,
228
00:08:01,620 --> 00:08:04,100
you set the connection rules on the right volume group.
229
00:08:04,100 --> 00:08:06,900
Then the volumes inside that group follow those settings.
230
00:08:06,900 --> 00:08:09,140
That inheritance saves time when storage grows.
231
00:08:09,140 --> 00:08:11,540
Imagine a database team creates 10 new volumes
232
00:08:11,540 --> 00:08:12,900
over the next few months.
233
00:08:12,900 --> 00:08:15,500
If the volumes belong to the production SQL volume group,
234
00:08:15,500 --> 00:08:17,300
they can use the same approved network path
235
00:08:17,300 --> 00:08:19,100
and connection setup as the rest of that group.
236
00:08:19,100 --> 00:08:21,260
You don't rebuild the same access rules 10 times
237
00:08:21,260 --> 00:08:22,740
and hope every setting matches.
238
00:08:22,740 --> 00:08:24,460
It also makes ownership clearer.
239
00:08:24,460 --> 00:08:26,340
When someone opens the elastic SAN resource,
240
00:08:26,340 --> 00:08:28,620
they can see which area belongs to production,
241
00:08:28,620 --> 00:08:31,340
which to testing, and which to a container platform.
242
00:08:31,340 --> 00:08:33,860
Storage doesn't turn into a long, confusing list
243
00:08:33,860 --> 00:08:35,700
of volumes with names that only made sense
244
00:08:35,700 --> 00:08:36,940
to the person who created them.
245
00:08:36,940 --> 00:08:38,580
At the bottom layer, you have volumes.
246
00:08:38,580 --> 00:08:40,700
A volume is the actual block storage unit
247
00:08:40,700 --> 00:08:42,260
that a workload connects to.
248
00:08:42,260 --> 00:08:45,060
You create a volume with a size, place it inside a volume group,
249
00:08:45,060 --> 00:08:47,380
and then connected to an approved VM cluster
250
00:08:47,380 --> 00:08:49,860
or supported platform through ISCSI.
251
00:08:49,860 --> 00:08:52,220
A SQL server might use one volume for database files
252
00:08:52,220 --> 00:08:54,180
and another for transaction logs.
253
00:08:54,180 --> 00:08:57,060
An AKS storage setup may create volumes for application data
254
00:08:57,060 --> 00:08:59,260
that needs to persist even when a container restarts.
255
00:08:59,260 --> 00:09:01,340
A clustered workload may connect to storage
256
00:09:01,340 --> 00:09:03,980
designed for its shared storage pattern.
257
00:09:03,980 --> 00:09:06,540
Each volume remains its own separate storage unit.
258
00:09:06,540 --> 00:09:07,860
That point can confuse people.
259
00:09:07,860 --> 00:09:09,820
A shared SAN doesn't mean every workload
260
00:09:09,820 --> 00:09:11,780
writes into one huge common drive.
261
00:09:11,780 --> 00:09:14,940
Volumes keep data separate, and each volume has its own size
262
00:09:14,940 --> 00:09:16,540
and own performance limits.
263
00:09:16,540 --> 00:09:18,260
The SAN provides the wider pool.
264
00:09:18,260 --> 00:09:21,420
The volume defines what one workload can connect to and use,
265
00:09:21,420 --> 00:09:23,140
so there are limits at more than one level.
266
00:09:23,140 --> 00:09:25,620
A volume must be large enough for the data it holds,
267
00:09:25,620 --> 00:09:27,500
but it must also have the right size
268
00:09:27,500 --> 00:09:28,740
for the performance it needs.
269
00:09:28,740 --> 00:09:30,100
At the same time, the whole SAN
270
00:09:30,100 --> 00:09:32,300
must have enough total capacity and performance
271
00:09:32,300 --> 00:09:33,620
for all its volumes together.
272
00:09:33,620 --> 00:09:35,420
You can't create a tiny volume and expect it
273
00:09:35,420 --> 00:09:37,660
to behave like an unlimited storage device,
274
00:09:37,660 --> 00:09:39,540
just because it sits inside a large SAN.
275
00:09:39,540 --> 00:09:41,340
Access also stays private.
276
00:09:41,340 --> 00:09:43,300
You don't expose an elastic SAN volume
277
00:09:43,300 --> 00:09:45,100
to the public internet like a web page.
278
00:09:45,100 --> 00:09:46,780
You set up private network paths,
279
00:09:46,780 --> 00:09:48,740
then allow approved workload connections
280
00:09:48,740 --> 00:09:49,860
through the volume group.
281
00:09:49,860 --> 00:09:53,100
That gives you a clear boundary around who can reach the storage.
282
00:09:53,100 --> 00:09:54,420
So the structure is simple.
283
00:09:54,420 --> 00:09:56,060
The SAN is the overall resource.
284
00:09:56,060 --> 00:09:57,380
Volume groups organize workloads
285
00:09:57,380 --> 00:09:59,100
and apply shared connection rules.
286
00:09:59,100 --> 00:10:01,060
Volumes are the individual storage units
287
00:10:01,060 --> 00:10:02,300
that workloads use.
288
00:10:02,300 --> 00:10:04,300
That handles organization and access.
289
00:10:04,300 --> 00:10:06,220
The next part is what changes the design,
290
00:10:06,220 --> 00:10:08,420
how the available storage performance gets shared
291
00:10:08,420 --> 00:10:10,980
when different workloads needed at different times.
292
00:10:10,980 --> 00:10:13,380
How shared performance changes the design?
293
00:10:13,380 --> 00:10:16,580
Imagine you have four SQL databases in the same business.
294
00:10:16,580 --> 00:10:18,580
The sales database gets busy during the day
295
00:10:18,580 --> 00:10:21,020
while finance runs heavy reports near month end.
296
00:10:21,020 --> 00:10:22,980
A warehouse system works hardest overnight
297
00:10:22,980 --> 00:10:24,500
and another database barely moves
298
00:10:24,500 --> 00:10:26,100
except during a weekly import.
299
00:10:26,100 --> 00:10:28,660
With separate disks, each database needs enough performance
300
00:10:28,660 --> 00:10:30,140
for its own worst moment.
301
00:10:30,140 --> 00:10:31,700
That often means buying more speed
302
00:10:31,700 --> 00:10:33,780
than each disk uses most of the time.
303
00:10:33,780 --> 00:10:36,700
So the storage stays ready, but much of it sits idle.
304
00:10:36,700 --> 00:10:38,220
Elastic SAN changes that pattern
305
00:10:38,220 --> 00:10:40,860
because the volumes draw from a shared performance budget.
306
00:10:40,860 --> 00:10:42,580
If the finance volume needs more IOPS
307
00:10:42,580 --> 00:10:44,300
while the warehouse volume stays quiet,
308
00:10:44,300 --> 00:10:46,940
finance can use more of the SANs available pool.
309
00:10:46,940 --> 00:10:48,460
When the workload shifts later,
310
00:10:48,460 --> 00:10:50,700
the available performance can shift too.
311
00:10:50,700 --> 00:10:51,660
That can reduce waste,
312
00:10:51,660 --> 00:10:53,820
but it also changes what you need to monitor.
313
00:10:53,820 --> 00:10:56,380
Instead of looking only at one disk and one VM,
314
00:10:56,380 --> 00:10:57,940
you watch the whole say N
315
00:10:57,940 --> 00:10:59,740
because every volume connected to it
316
00:10:59,740 --> 00:11:02,700
can affect the others when demand rises at the same time.
317
00:11:03,580 --> 00:11:05,180
Managed disks use a different model.
318
00:11:05,180 --> 00:11:07,060
A disk has its own performance level
319
00:11:07,060 --> 00:11:08,660
and the VM has an overall limit
320
00:11:08,660 --> 00:11:10,460
for disk IOPS and throughput.
321
00:11:10,460 --> 00:11:12,300
Do you plan each server around those boundaries
322
00:11:12,300 --> 00:11:13,820
which gives clear isolation
323
00:11:13,820 --> 00:11:16,060
but can also force you to buy a larger VM
324
00:11:16,060 --> 00:11:18,900
or faster disks just to reach a storage target?
325
00:11:18,900 --> 00:11:22,620
Elastic SAN volumes connect over the network through ISCSI.
326
00:11:22,620 --> 00:11:25,580
That means they don't use the usual managed disk slots
327
00:11:25,580 --> 00:11:27,700
and they don't depend on the VM's normal disk
328
00:11:27,700 --> 00:11:29,500
throughput limits in the same way.
329
00:11:29,500 --> 00:11:31,780
Instead, the design depends on the SANs total performance,
330
00:11:31,780 --> 00:11:33,340
the performance limit of each volume
331
00:11:33,340 --> 00:11:35,780
and the network capacity between the workload and the SAN.
332
00:11:35,780 --> 00:11:37,780
So you've moved the limit, not removed it,
333
00:11:37,780 --> 00:11:40,700
a shared pool doesn't create unlimited storage speed.
334
00:11:40,700 --> 00:11:43,340
If several busy volumes ask for more IOPS and throughput
335
00:11:43,340 --> 00:11:45,740
then the SAN can supply Azure Throttles the extra work,
336
00:11:45,740 --> 00:11:48,300
request take longer and your apps may feel slower.
337
00:11:48,300 --> 00:11:49,740
The SAN needs enough headroom
338
00:11:49,740 --> 00:11:51,980
for the combined peak demand you expect.
339
00:11:51,980 --> 00:11:53,180
Each volume has limits too.
340
00:11:53,180 --> 00:11:57,460
It can reach up to 80,000 IOPS and 1,180 Mbps,
341
00:11:57,460 --> 00:11:58,820
but only when it's size,
342
00:11:58,820 --> 00:12:01,780
the SAN configuration and the connection setup supported.
343
00:12:01,780 --> 00:12:03,020
Notice that first part.
344
00:12:03,020 --> 00:12:04,500
When its size supports it.
345
00:12:04,500 --> 00:12:07,380
With Elastic SAN, a volume's possible performance rises
346
00:12:07,380 --> 00:12:09,380
with its size until it reaches the service limit.
347
00:12:09,380 --> 00:12:11,100
So if a workload needs very high IOPS
348
00:12:11,100 --> 00:12:13,060
you can't create a tiny volume and expect it
349
00:12:13,060 --> 00:12:14,500
to pull that much from the pool.
350
00:12:14,500 --> 00:12:16,340
Here's the thing, think of it like a loading dock.
351
00:12:16,340 --> 00:12:18,220
The whole building may have a large number of workers
352
00:12:18,220 --> 00:12:19,300
and trucks available,
353
00:12:19,300 --> 00:12:21,060
but a small loading bay only has room
354
00:12:21,060 --> 00:12:22,700
for so much activity at once.
355
00:12:22,700 --> 00:12:24,700
The SAN is the building's total capacity,
356
00:12:24,700 --> 00:12:26,940
the volume is the loading bay for one workload
357
00:12:26,940 --> 00:12:28,420
and both need enough room.
358
00:12:28,420 --> 00:12:30,340
Let's make that practical.
359
00:12:30,340 --> 00:12:32,820
A company runs several SQL server databases.
360
00:12:32,820 --> 00:12:35,380
One handles customer orders during business hours,
361
00:12:35,380 --> 00:12:37,580
another runs payroll every second Friday
362
00:12:37,580 --> 00:12:40,700
and a third receives large data imports overnight.
363
00:12:40,700 --> 00:12:43,300
With separate disks, the team might size all three
364
00:12:43,300 --> 00:12:44,620
for their individual peak
365
00:12:44,620 --> 00:12:46,620
even though those peaks rarely happen together.
366
00:12:46,620 --> 00:12:48,820
With Elastic SAN, they can measure the actual timing
367
00:12:48,820 --> 00:12:51,620
and size a shared pool around the likely combined demand.
368
00:12:51,620 --> 00:12:53,660
So one database can use more performance
369
00:12:53,660 --> 00:12:55,100
while the others stay quiet,
370
00:12:55,100 --> 00:12:58,860
without paying for the same unused peak capacity three times.
371
00:12:58,860 --> 00:13:01,580
But more storage performance won't repair every slow system.
372
00:13:01,580 --> 00:13:04,620
A poor SQL query can still scan far too much data
373
00:13:04,620 --> 00:13:06,740
and a missing index can still delay a report.
374
00:13:06,740 --> 00:13:09,260
A VM with two little CPU can still struggle
375
00:13:09,260 --> 00:13:12,060
and a weak network path can slow ISC-SI traffic
376
00:13:12,060 --> 00:13:14,060
before the SAN even gets a chance to help.
377
00:13:14,060 --> 00:13:16,380
Storage only fixes a storage problem.
378
00:13:16,380 --> 00:13:18,740
That's why planning starts with real measurements.
379
00:13:18,740 --> 00:13:21,060
Look at I/OPS, throughput, latency
380
00:13:21,060 --> 00:13:22,940
and when each workload gets busy.
381
00:13:22,940 --> 00:13:25,780
Base capacity gives your SAN its starting performance pool
382
00:13:25,780 --> 00:13:28,500
so adding capacity can also add more performance headroom.
383
00:13:28,500 --> 00:13:30,820
Watch the demand before you grow the pool.
384
00:13:30,820 --> 00:13:33,260
Shared performance can lower wasted spend
385
00:13:33,260 --> 00:13:36,500
but only when the workloads truly take turns using it.
386
00:13:36,500 --> 00:13:38,620
Where Elastic SAN fits and where it doesn't.
387
00:13:38,620 --> 00:13:41,060
Elastic SAN works best when you have several workloads
388
00:13:41,060 --> 00:13:42,460
that need fast block storage
389
00:13:42,460 --> 00:13:46,180
and their storage demand doesn't peak at the same time.
390
00:13:46,180 --> 00:13:48,940
A group of SQL server databases is a good example.
391
00:13:48,940 --> 00:13:50,620
You may have separate database servers
392
00:13:50,620 --> 00:13:53,900
for orders, reporting, finance and internal apps.
393
00:13:53,900 --> 00:13:55,580
They all need reliable storage
394
00:13:55,580 --> 00:13:57,300
but their busiest hours can differ,
395
00:13:57,300 --> 00:13:59,300
which gives a shared SAN room to work.
396
00:13:59,300 --> 00:14:01,740
It can also fit clustered SQL server designs
397
00:14:01,740 --> 00:14:04,460
including SQL server failover cluster instances
398
00:14:04,460 --> 00:14:05,780
which expect shared storage
399
00:14:05,780 --> 00:14:07,820
that more than one cluster node can reach.
400
00:14:07,820 --> 00:14:09,940
Elastic SAN gives you a managed Azure option
401
00:14:09,940 --> 00:14:11,420
for that familiar SAN pattern
402
00:14:11,420 --> 00:14:14,380
without asking you to build and run storage hardware yourself.
403
00:14:14,380 --> 00:14:16,420
For database teams moving workloads
404
00:14:16,420 --> 00:14:18,140
from an on-premises data center,
405
00:14:18,140 --> 00:14:19,340
this can feel more natural
406
00:14:19,340 --> 00:14:21,060
than redesigning every storage layout
407
00:14:21,060 --> 00:14:22,660
around separate VM disks.
408
00:14:22,660 --> 00:14:25,380
Azure VMWare solution is another strong use case.
409
00:14:25,380 --> 00:14:27,660
VMWare environments often use data stores
410
00:14:27,660 --> 00:14:29,340
and storage growth can become tied
411
00:14:29,340 --> 00:14:31,060
to adding more cluster hosts.
412
00:14:31,060 --> 00:14:34,140
With Elastic SAN, you can connect external ISCSI storage
413
00:14:34,140 --> 00:14:36,580
as a data store, meaning you can add storage capacity
414
00:14:36,580 --> 00:14:38,700
without automatically adding compute capacity
415
00:14:38,700 --> 00:14:39,900
that you may not need.
416
00:14:39,900 --> 00:14:41,060
That separation can matter
417
00:14:41,060 --> 00:14:43,420
when your virtual machines need more room for data
418
00:14:43,420 --> 00:14:46,460
but the AVS cluster already has enough CPU and memory.
419
00:14:46,460 --> 00:14:48,420
Kubernetes can use Elastic SAN too
420
00:14:48,420 --> 00:14:50,140
through supported storage designs.
421
00:14:50,140 --> 00:14:51,220
Containers come and go
422
00:14:51,220 --> 00:14:53,260
but some applications need data to remain
423
00:14:53,260 --> 00:14:54,900
after a container restarts.
424
00:14:54,900 --> 00:14:57,180
A database running in a container, for example,
425
00:14:57,180 --> 00:14:59,380
can't treat its data as temporary.
426
00:14:59,380 --> 00:15:01,180
So the storage design needs to match
427
00:15:01,180 --> 00:15:03,580
the Kubernetes platform, the application
428
00:15:03,580 --> 00:15:05,700
and the supported Azure connection method.
429
00:15:05,700 --> 00:15:08,900
Don't treat Elastic SAN as a generic container storage switch.
430
00:15:08,900 --> 00:15:11,620
Check the storage driver, access mode, network path
431
00:15:11,620 --> 00:15:14,460
and recovery design before you put an application into production
432
00:15:14,460 --> 00:15:16,660
because Kubernetes adds its own layer of rules
433
00:15:16,660 --> 00:15:18,820
and the storage needs to fit those rules.
434
00:15:18,820 --> 00:15:20,660
Data protection also comes into the picture.
435
00:15:20,660 --> 00:15:23,740
Elastic SAN supports point in time snapshots of volumes
436
00:15:23,740 --> 00:15:25,220
which record changes over time
437
00:15:25,220 --> 00:15:26,460
and can help you restore a volume
438
00:15:26,460 --> 00:15:28,300
or create a new volume from a recovery point.
439
00:15:28,300 --> 00:15:30,820
That can be useful when a database refresh goes wrong.
440
00:15:30,820 --> 00:15:32,180
A test environment needs a copy
441
00:15:32,180 --> 00:15:34,700
or a team needs to recover from a bad change.
442
00:15:34,700 --> 00:15:36,420
Still, a snapshot isn't the same thing
443
00:15:36,420 --> 00:15:37,940
as a complete backup plan.
444
00:15:37,940 --> 00:15:40,340
Your workload may need application-aware backups,
445
00:15:40,340 --> 00:15:43,100
copies kept for a longer period, recovery tests
446
00:15:43,100 --> 00:15:44,860
and a plan for a wider outage.
447
00:15:44,860 --> 00:15:47,740
A database can have data on storage that looks healthy
448
00:15:47,740 --> 00:15:50,540
while its transaction state still needs careful recovery
449
00:15:50,540 --> 00:15:52,060
so the storage layer can help
450
00:15:52,060 --> 00:15:54,300
but it can't decide that process for you.
451
00:15:54,300 --> 00:15:56,620
Azure also encrypts Elastic SAN data address
452
00:15:56,620 --> 00:15:58,620
and you can choose redundancy options based
453
00:15:58,620 --> 00:16:00,700
on what's available for your region and design
454
00:16:00,700 --> 00:16:03,100
while access stays on private network paths
455
00:16:03,100 --> 00:16:05,540
keeping storage traffic away from the public internet.
456
00:16:05,540 --> 00:16:07,100
Those controls reduce risk
457
00:16:07,100 --> 00:16:09,820
but they don't replace good network design or monitoring.
458
00:16:09,820 --> 00:16:12,020
So when does Elastic SAN not make sense?
459
00:16:12,020 --> 00:16:14,020
A small app server with one modest data disk
460
00:16:14,020 --> 00:16:15,220
usually doesn't need it
461
00:16:15,220 --> 00:16:18,220
and a simple VM with steady, low storage demand
462
00:16:18,220 --> 00:16:19,620
doesn't need it either.
463
00:16:19,620 --> 00:16:22,300
In those cases, manage disks remain easier to set up,
464
00:16:22,300 --> 00:16:24,820
easier to reason about and often cheaper.
465
00:16:24,820 --> 00:16:26,860
The same applies when a workload needs strict performance
466
00:16:26,860 --> 00:16:27,620
isolation.
467
00:16:27,620 --> 00:16:29,780
With a shared pool, you need to plan for other workloads
468
00:16:29,780 --> 00:16:30,780
using the same sense.
469
00:16:30,780 --> 00:16:32,620
So if one application must always have its own
470
00:16:32,620 --> 00:16:34,740
fixed storage performance and there's no wider group
471
00:16:34,740 --> 00:16:37,300
to share with, a dedicated managed disk design
472
00:16:37,300 --> 00:16:38,740
may be the cleaner choice.
473
00:16:38,740 --> 00:16:40,220
The cost rules stay simple.
474
00:16:40,220 --> 00:16:42,660
Pooling helps when many workloads can share capacity
475
00:16:42,660 --> 00:16:45,660
and performance but if you only need one small private disk,
476
00:16:45,660 --> 00:16:48,220
a shared SAN can add setup work and cost
477
00:16:48,220 --> 00:16:49,660
without giving you much back.
478
00:16:49,660 --> 00:16:51,620
So Elastic SAN doesn't remove the need
479
00:16:51,620 --> 00:16:53,820
for backups, network planning, workload testing
480
00:16:53,820 --> 00:16:55,580
or watching performance over time.
481
00:16:55,580 --> 00:16:57,380
It gives you a different storage model
482
00:16:57,380 --> 00:16:59,780
and whether that model fits depends on the workloads you
483
00:16:59,780 --> 00:17:00,700
place inside it.
484
00:17:00,700 --> 00:17:02,740
We'll explore each of these use cases in more detail
485
00:17:02,740 --> 00:17:03,980
in future episodes.
486
00:17:03,980 --> 00:17:05,260
So stay tuned.
487
00:17:05,260 --> 00:17:06,660
A simple way to decide.
488
00:17:06,660 --> 00:17:08,860
Grab a list of the workloads you already run.
489
00:17:08,860 --> 00:17:10,700
Note how much storage each one needs,
490
00:17:10,700 --> 00:17:13,380
its peak IOPS and throughput and when those busy periods
491
00:17:13,380 --> 00:17:14,540
actually hit.
492
00:17:14,540 --> 00:17:16,420
Don't guess based on one quiet day,
493
00:17:16,420 --> 00:17:19,140
pull monitoring data from normal operations, batch jobs,
494
00:17:19,140 --> 00:17:20,940
reporting cycles, and backups.
495
00:17:20,940 --> 00:17:22,220
That gives you the real picture.
496
00:17:22,220 --> 00:17:23,380
Now look for a pattern.
497
00:17:23,380 --> 00:17:25,220
Do you have several performance heavy workloads
498
00:17:25,220 --> 00:17:26,780
that all need block storage and do their
499
00:17:26,780 --> 00:17:28,860
busiest times avoid overlapping?
500
00:17:28,860 --> 00:17:31,300
If so, Elastic SAN is worth a closer look.
501
00:17:31,300 --> 00:17:32,420
Here's the real test.
502
00:17:32,420 --> 00:17:34,260
Compare it against the managed disk design
503
00:17:34,260 --> 00:17:35,620
you would otherwise build.
504
00:17:35,620 --> 00:17:38,060
Factor in disk charges, VM disk limits,
505
00:17:38,060 --> 00:17:40,860
the hours spent wrangling dozens of separate disks
506
00:17:40,860 --> 00:17:43,020
and all that performance you end up paying for,
507
00:17:43,020 --> 00:17:44,140
but never using.
508
00:17:44,140 --> 00:17:45,820
Before you commit, run a small test
509
00:17:45,820 --> 00:17:47,580
with one related workload group.
510
00:17:47,580 --> 00:17:49,980
Measure latency, IOPS, throughput
511
00:17:49,980 --> 00:17:53,060
and how the SAN handles total demand under realistic load.
512
00:17:53,060 --> 00:17:54,380
Test recovery too.
513
00:17:54,380 --> 00:17:56,220
Once the numbers back the design,
514
00:17:56,220 --> 00:17:57,540
you can scale from there.
515
00:17:57,540 --> 00:17:59,700
When the pattern fits, you end up with storage
516
00:17:59,700 --> 00:18:01,540
that's easier to organize and file a scatter
517
00:18:01,540 --> 00:18:03,060
across individual servers.
518
00:18:03,060 --> 00:18:04,020
That's the payoff.
519
00:18:04,020 --> 00:18:06,940
So what exactly is Azure Elastic SAN?
520
00:18:06,940 --> 00:18:08,820
It takes high performance block storage
521
00:18:08,820 --> 00:18:11,500
and turns it into a managed shared pool inside Azure.
522
00:18:11,500 --> 00:18:14,300
You create one SAN, organize access through volume groups
523
00:18:14,300 --> 00:18:16,780
and connect individual volumes to approved workloads
524
00:18:16,780 --> 00:18:18,140
over ISC ESI.
525
00:18:18,140 --> 00:18:20,060
This works well for groups of databases,
526
00:18:20,060 --> 00:18:21,860
clustered apps, VMware setups
527
00:18:21,860 --> 00:18:23,660
and supported container designs.
528
00:18:23,660 --> 00:18:25,140
Anywhere you need fast storage
529
00:18:25,140 --> 00:18:27,620
and the workloads can share performance sensibly.
530
00:18:27,620 --> 00:18:29,620
Your practical next step, pick one group
531
00:18:29,620 --> 00:18:31,820
of related database or clustered workloads,
532
00:18:31,820 --> 00:18:33,500
compare their combined peak demand
533
00:18:33,500 --> 00:18:36,340
against the separate managed disks they used today
534
00:18:36,340 --> 00:18:38,580
and check whether those peaks really overlap.
535
00:18:38,580 --> 00:18:40,660
If they don't, the pool approach wins.
536
00:18:40,660 --> 00:18:42,540
For everything else, Azure managed disks
537
00:18:42,540 --> 00:18:44,380
with a private disk per VM
538
00:18:44,380 --> 00:18:46,100
might still be the better fit.
00:00:00,000 --> 00:00:02,680
Most Azure storage problems don't start with a big failure.
2
00:00:02,680 --> 00:00:05,460
They start with one virtual machine and one managed disk.
3
00:00:05,460 --> 00:00:06,540
It seems simple.
4
00:00:06,540 --> 00:00:08,940
Your VM needs a place for its operating system,
5
00:00:08,940 --> 00:00:10,460
app data or database files,
6
00:00:10,460 --> 00:00:12,460
so you attach a disk and forget about it.
7
00:00:12,460 --> 00:00:13,740
Then your company grows.
8
00:00:13,740 --> 00:00:16,780
More VMs show up, more databases need faster storage,
9
00:00:16,780 --> 00:00:19,060
and each machine gets its own set of disks,
10
00:00:19,060 --> 00:00:21,620
its own performance limits, and its own settings.
11
00:00:21,620 --> 00:00:24,540
Soon you find yourself paying for performance on quiet disks
12
00:00:24,540 --> 00:00:26,860
while one busy database waits for more capacity.
13
00:00:26,860 --> 00:00:27,940
That's the tricky part.
14
00:00:27,940 --> 00:00:30,220
You might be paying for storage speed you aren't even using
15
00:00:30,220 --> 00:00:32,580
while another workload can't borrow that spare capacity.
16
00:00:32,580 --> 00:00:34,780
Think of it like separate filing cabinets.
17
00:00:34,780 --> 00:00:36,140
Each one locked to its own worker
18
00:00:36,140 --> 00:00:37,940
with no way to borrow unused space.
19
00:00:37,940 --> 00:00:40,700
That's the problem Azure Elastic Sand is designed to solve.
20
00:00:40,700 --> 00:00:42,740
Azure Elastic Sand takes a different approach.
21
00:00:42,740 --> 00:00:45,380
It puts high performance block storage into a shared pool
22
00:00:45,380 --> 00:00:48,100
instead of locking it inside separate VM disks.
23
00:00:48,100 --> 00:00:50,020
But shared storage only saves money
24
00:00:50,020 --> 00:00:51,940
when your workloads use it the right way.
25
00:00:51,940 --> 00:00:53,220
So let's start with the old layout
26
00:00:53,220 --> 00:00:55,260
and see whether pressure builds.
27
00:00:55,260 --> 00:00:57,860
Why separate disks turn into a storage problem?
28
00:00:57,860 --> 00:00:59,140
Let's walk through a scenario.
29
00:00:59,140 --> 00:01:02,100
Imagine you run a small app on one Azure virtual machine.
30
00:01:02,100 --> 00:01:04,940
You attach a managed disk, choose a type in size,
31
00:01:04,940 --> 00:01:07,180
and the VM sees it like a local hard drive.
32
00:01:07,180 --> 00:01:08,980
For a single server that works well.
33
00:01:08,980 --> 00:01:10,980
It's easy to understand, easy to set up,
34
00:01:10,980 --> 00:01:12,220
and usually the right choice.
35
00:01:12,220 --> 00:01:13,460
But here's where things change.
36
00:01:13,460 --> 00:01:15,620
The trouble begins when that one server turns
37
00:01:15,620 --> 00:01:16,980
into a group of systems.
38
00:01:16,980 --> 00:01:20,060
Maybe you now run SQL Server for your main business app.
39
00:01:20,060 --> 00:01:22,740
You have app servers that write logs and process files.
40
00:01:22,740 --> 00:01:25,340
You have cluster nodes that need fast shared data.
41
00:01:25,340 --> 00:01:27,060
You may also have Kubernetes workloads
42
00:01:27,060 --> 00:01:29,620
that create and remove storage as app scale.
43
00:01:29,620 --> 00:01:31,900
None of these systems stay busy the same way.
44
00:01:31,900 --> 00:01:34,380
Your SQL database might work hard as that month end.
45
00:01:34,380 --> 00:01:36,820
A reporting server may spike early in the morning.
46
00:01:36,820 --> 00:01:40,060
A backup job can push large amounts of data overnight.
47
00:01:40,060 --> 00:01:42,620
Meanwhile, other disks sit mostly quiet.
48
00:01:42,620 --> 00:01:43,580
The goal is simple.
49
00:01:43,580 --> 00:01:46,500
Keep every workload fast enough when it needs storage.
50
00:01:46,500 --> 00:01:48,420
The obstacle, managed disks are usually
51
00:01:48,420 --> 00:01:51,420
planned one disk at a time, and each VM has a limit
52
00:01:51,420 --> 00:01:53,460
on how much disk work it can handle as a whole.
53
00:01:53,460 --> 00:01:55,740
So you'll often hear two terms in this conversation.
54
00:01:55,740 --> 00:01:57,260
Iops and throughput.
55
00:01:57,260 --> 00:01:58,900
Let's clear up what those mean.
56
00:01:58,900 --> 00:02:02,020
Iops stands for input and output operations per second.
57
00:02:02,020 --> 00:02:05,020
In plain English, it counts how many small read or write requests
58
00:02:05,020 --> 00:02:07,140
your storage can handle each second.
59
00:02:07,140 --> 00:02:09,660
A database often sends lots of small requests,
60
00:02:09,660 --> 00:02:12,340
reading a record, updating an order, checking an index.
61
00:02:12,340 --> 00:02:14,500
High Iops helps when many of those small jobs
62
00:02:14,500 --> 00:02:15,260
arrive quickly.
63
00:02:15,260 --> 00:02:16,940
throughput measures the amount of data that
64
00:02:16,940 --> 00:02:18,140
moves each second.
65
00:02:18,140 --> 00:02:19,780
Think of copying a large backup file
66
00:02:19,780 --> 00:02:21,140
or reading a huge report.
67
00:02:21,140 --> 00:02:23,780
You might not need a massive number of tiny requests,
68
00:02:23,780 --> 00:02:26,300
but you do need a wide enough pipe to move a lot of data.
69
00:02:26,300 --> 00:02:29,380
That's throughput, usually measured in megabytes per second,
70
00:02:29,380 --> 00:02:32,180
both matter, but different workloads need different mixes.
71
00:02:32,180 --> 00:02:34,060
And the challenge is that your workloads don't all
72
00:02:34,060 --> 00:02:35,380
fit the same pattern.
73
00:02:35,380 --> 00:02:37,940
Now, picture a company with rows of filing cabinets.
74
00:02:37,940 --> 00:02:39,700
Every employee gets their own cabinet,
75
00:02:39,700 --> 00:02:41,620
and each cabinet has a fixed number of drawers
76
00:02:41,620 --> 00:02:43,420
and a fixed speed for opening them.
77
00:02:43,420 --> 00:02:46,260
One person has a cabinet packed with urgent work.
78
00:02:46,260 --> 00:02:47,980
The cabinet beside it has empty drawers
79
00:02:47,980 --> 00:02:49,100
and no one touching it.
80
00:02:49,100 --> 00:02:51,180
Yet the busy person can't use that spare capacity
81
00:02:51,180 --> 00:02:52,540
because it belongs to someone else.
82
00:02:52,540 --> 00:02:54,500
That's what can happen with separate disks.
83
00:02:54,500 --> 00:02:56,340
You end up paying for a cabinet with extra drawers
84
00:02:56,340 --> 00:02:58,060
that nobody uses while another person
85
00:02:58,060 --> 00:02:59,500
struggles with a slow cabinet.
86
00:02:59,500 --> 00:03:02,300
You might choose a larger or faster disk for a database
87
00:03:02,300 --> 00:03:05,020
because it needs a short burst of performance once a day.
88
00:03:05,020 --> 00:03:06,900
For the rest of the day, much of that performance
89
00:03:06,900 --> 00:03:08,140
sits unused.
90
00:03:08,140 --> 00:03:10,220
Then you repeat that choice for another database,
91
00:03:10,220 --> 00:03:12,700
just in case it also gets busy.
92
00:03:12,700 --> 00:03:15,220
The bill grows from all that just in case performance.
93
00:03:15,220 --> 00:03:17,620
A common answer is fine, add more disks.
94
00:03:17,620 --> 00:03:18,820
Sometimes that helps.
95
00:03:18,820 --> 00:03:21,140
A VM can spread work across several disks
96
00:03:21,140 --> 00:03:23,380
and software inside the VM can combine them,
97
00:03:23,380 --> 00:03:25,860
but adding disks doesn't remove every limit.
98
00:03:25,860 --> 00:03:27,940
The VM itself still has a total disk iOps
99
00:03:27,940 --> 00:03:30,300
and throughput ceiling based on its size.
100
00:03:30,300 --> 00:03:32,820
The VM's disk limit acts like a bottleneck.
101
00:03:32,820 --> 00:03:34,620
No matter how fast the disk is,
102
00:03:34,620 --> 00:03:37,220
the road to the VM can only carry so much traffic.
103
00:03:37,220 --> 00:03:39,580
So you can buy faster disks, attach more of them,
104
00:03:39,580 --> 00:03:41,540
and still find that the VM can't push
105
00:03:41,540 --> 00:03:43,460
the amount of storage traffic you expected.
106
00:03:43,460 --> 00:03:45,340
That's frustrating because the storage may have room
107
00:03:45,340 --> 00:03:47,380
to work harder, but the route through the VM
108
00:03:47,380 --> 00:03:49,700
has reached its limit on premises data centers
109
00:03:49,700 --> 00:03:52,980
dealt with this for years through a storage area network or sand.
110
00:03:52,980 --> 00:03:54,500
Instead of treating every server storage
111
00:03:54,500 --> 00:03:57,180
like a private cabinet, teams built a central storage room
112
00:03:57,180 --> 00:03:59,140
that many servers could connect to.
113
00:03:59,140 --> 00:04:02,300
Azure Elastic Sand brings that shared room idea into Azure
114
00:04:02,300 --> 00:04:05,340
without asking you to buy storage controllers, wire up racks,
115
00:04:05,340 --> 00:04:06,900
or look after sand hardware.
116
00:04:06,900 --> 00:04:08,540
And that's why separate disks can turn
117
00:04:08,540 --> 00:04:10,260
into a real storage problem.
118
00:04:10,260 --> 00:04:12,700
What Azure Elastic Sand actually is?
119
00:04:12,700 --> 00:04:14,820
So what actually is Azure Elastic Sand?
120
00:04:14,820 --> 00:04:17,540
In plain English, it's managed block storage in Azure,
121
00:04:17,540 --> 00:04:20,660
designed as a shared pool for workloads that need fast storage.
122
00:04:20,660 --> 00:04:22,620
Here's a simple way to think about it.
123
00:04:22,620 --> 00:04:25,540
Imagine an office building with one central record's room.
124
00:04:25,540 --> 00:04:28,620
Inside that room, there are many locked drawers with clear labels.
125
00:04:28,620 --> 00:04:31,700
The finance team has its drawers, the sales system has its drawers,
126
00:04:31,700 --> 00:04:33,300
a database has its own drawers too.
127
00:04:33,300 --> 00:04:34,660
They keep their own files separate,
128
00:04:34,660 --> 00:04:36,420
but the building manages the room
129
00:04:36,420 --> 00:04:38,740
and it's available storage power in one place.
130
00:04:38,740 --> 00:04:40,140
The Elastic Sand works the same way.
131
00:04:40,140 --> 00:04:41,420
It's the central storage room.
132
00:04:41,420 --> 00:04:43,140
You create separate volumes inside it,
133
00:04:43,140 --> 00:04:45,580
and each volume acts like a block device
134
00:04:45,580 --> 00:04:47,460
that a workload can use as storage,
135
00:04:47,460 --> 00:04:50,700
a virtual machine sees that volume much like it sees a local disk,
136
00:04:50,700 --> 00:04:52,860
then formats it and stores data on it.
137
00:04:52,860 --> 00:04:54,420
Block storage means the workload reads
138
00:04:54,420 --> 00:04:56,420
and writes small chunks of data directly.
139
00:04:56,420 --> 00:04:58,540
That matters for systems like databases.
140
00:04:58,540 --> 00:05:00,420
SQL Server doesn't want to save a document
141
00:05:00,420 --> 00:05:02,340
in a shared folder and hope for the best.
142
00:05:02,340 --> 00:05:05,580
It needs controlled, fast reads and writes to data files,
143
00:05:05,580 --> 00:05:08,580
log files, and other pieces that keep the database running.
144
00:05:08,580 --> 00:05:11,500
Elastic Sand gives workloads that disc-like storage experience,
145
00:05:11,500 --> 00:05:13,100
but the storage connects over the network
146
00:05:13,100 --> 00:05:15,780
instead of attaching as a standard Azure managed disk.
147
00:05:15,780 --> 00:05:18,620
That connection uses something called ICSI.
148
00:05:18,620 --> 00:05:21,740
ISSI stands for Internet Small Computer Systems Interface,
149
00:05:21,740 --> 00:05:22,980
but don't worry about the full name.
150
00:05:22,980 --> 00:05:24,180
Think of it as a private route
151
00:05:24,180 --> 00:05:26,100
that carries storage commands between a server
152
00:05:26,100 --> 00:05:27,740
and the Elastic Sand.
153
00:05:27,740 --> 00:05:28,980
Your VM sends a request.
154
00:05:28,980 --> 00:05:31,180
Read this data block, write this database log entry,
155
00:05:31,180 --> 00:05:32,540
return this part of the file.
156
00:05:32,540 --> 00:05:35,060
The request travels over a dedicated network connection
157
00:05:35,060 --> 00:05:37,180
to the SAN and the SAN response.
158
00:05:37,180 --> 00:05:39,020
To the workload, it looks like another local disk.
159
00:05:39,020 --> 00:05:40,500
This doesn't mean Elastic Sand replaces
160
00:05:40,500 --> 00:05:42,100
every Azure storage service.
161
00:05:42,100 --> 00:05:44,020
Blob storage is built for objects like backups,
162
00:05:44,020 --> 00:05:45,220
images, and video files.
163
00:05:45,220 --> 00:05:47,860
It's more like a warehouse where you store named boxes.
164
00:05:47,860 --> 00:05:49,460
Azure files gives you shared folders
165
00:05:49,460 --> 00:05:51,700
that people and apps can access over a network.
166
00:05:51,700 --> 00:05:53,500
It behaves like a company file share.
167
00:05:53,500 --> 00:05:55,380
Managed disks are still the simple choice
168
00:05:55,380 --> 00:05:58,340
for many virtual machines that meet their own dedicated disk.
169
00:05:58,340 --> 00:06:00,940
Elastic SAN sits in a different part of the picture.
170
00:06:00,940 --> 00:06:03,300
It provides central high-performance block storage
171
00:06:03,300 --> 00:06:05,140
for workloads that benefit from sharing
172
00:06:05,140 --> 00:06:06,500
a larger storage pool.
173
00:06:06,500 --> 00:06:08,140
And because Azure runs the service,
174
00:06:08,140 --> 00:06:10,540
you don't manage the physical SAN equipment behind it.
175
00:06:10,540 --> 00:06:12,900
No storage racks to order, no controllers to replace,
176
00:06:12,900 --> 00:06:15,740
no physical cables between servers and the storage array.
177
00:06:15,740 --> 00:06:18,060
Azure handles the hardware behind the scenes
178
00:06:18,060 --> 00:06:20,660
while you configure the capacity, performance level,
179
00:06:20,660 --> 00:06:22,860
network path, and volumes your workloads need.
180
00:06:22,860 --> 00:06:24,860
The performance model is where this gets interesting.
181
00:06:24,860 --> 00:06:26,900
Elastic SAN includes base capacity,
182
00:06:26,900 --> 00:06:29,660
and that base capacity brings performance with it.
183
00:06:29,660 --> 00:06:31,620
For every one TIE-B of base capacity,
184
00:06:31,620 --> 00:06:35,380
the SAN receives 5,000 IOPS and 200 medabyte per second
185
00:06:35,380 --> 00:06:36,300
of throughput.
186
00:06:36,300 --> 00:06:39,300
These numbers belong to the SAN pool, not just one volume.
187
00:06:39,300 --> 00:06:40,740
So if you build a larger pool,
188
00:06:40,740 --> 00:06:42,380
you create more shared room for workloads
189
00:06:42,380 --> 00:06:44,660
that need fast reads and writes at different times.
190
00:06:44,660 --> 00:06:45,820
You still need to plan carefully
191
00:06:45,820 --> 00:06:48,340
because all workloads can't demand the full pool at once
192
00:06:48,340 --> 00:06:49,460
without consequences.
193
00:06:49,460 --> 00:06:51,260
But the storage isn't one giant disc
194
00:06:51,260 --> 00:06:53,580
that every app touches without structure.
195
00:06:53,580 --> 00:06:55,020
Azure divides it into layers,
196
00:06:55,020 --> 00:06:57,420
and the next layer explains how you keep related workloads
197
00:06:57,420 --> 00:07:00,180
organized and control who can connect.
198
00:07:00,180 --> 00:07:01,940
The three building blocks.
199
00:07:01,940 --> 00:07:04,620
SAN, volume groups, and volumes.
200
00:07:04,620 --> 00:07:07,540
Inside Azure Elastic SAN, you work with three layers,
201
00:07:07,540 --> 00:07:09,540
the SAN, volume groups, and volumes.
202
00:07:09,540 --> 00:07:11,820
Think of the SAN as the top-level storage space.
203
00:07:11,820 --> 00:07:14,300
This is where you set the overall capacity,
204
00:07:14,300 --> 00:07:15,740
total performance for the pool,
205
00:07:15,740 --> 00:07:17,380
and redundancy choice for the data.
206
00:07:17,380 --> 00:07:19,180
It's the main Azure resource you create
207
00:07:19,180 --> 00:07:20,980
before any workload connects.
208
00:07:20,980 --> 00:07:23,580
A SAN can hold many related storage volumes.
209
00:07:23,580 --> 00:07:25,220
That means you no longer need to treat
210
00:07:25,220 --> 00:07:27,540
every piece of storage as a separate thing
211
00:07:27,540 --> 00:07:30,540
with separate network settings and separate management work.
212
00:07:30,540 --> 00:07:32,780
You start with one larger storage resource,
213
00:07:32,780 --> 00:07:34,740
then organize its contents to match the teams
214
00:07:34,740 --> 00:07:35,900
and apps that use it.
215
00:07:35,900 --> 00:07:37,900
Under the SAN, you create volume groups.
216
00:07:37,900 --> 00:07:39,860
A volume group is a management boundary
217
00:07:39,860 --> 00:07:40,980
for related volumes.
218
00:07:40,980 --> 00:07:43,260
You might create one for production SQL Server workloads,
219
00:07:43,260 --> 00:07:45,300
another for test and development databases,
220
00:07:45,300 --> 00:07:48,580
and a third for an Azure Kubernetes Service or AKS environment.
221
00:07:48,580 --> 00:07:51,140
Those workloads can live in the same elastic SAN,
222
00:07:51,140 --> 00:07:53,300
but they don't need to share the same connection rules.
223
00:07:53,300 --> 00:07:54,980
For example, your production SQL servers
224
00:07:54,980 --> 00:07:57,340
might sit on one private network and your test servers
225
00:07:57,340 --> 00:07:58,020
on another.
226
00:07:58,020 --> 00:08:00,220
Instead of setting up network access over and over
227
00:08:00,220 --> 00:08:01,620
for every new database volume,
228
00:08:01,620 --> 00:08:04,100
you set the connection rules on the right volume group.
229
00:08:04,100 --> 00:08:06,900
Then the volumes inside that group follow those settings.
230
00:08:06,900 --> 00:08:09,140
That inheritance saves time when storage grows.
231
00:08:09,140 --> 00:08:11,540
Imagine a database team creates 10 new volumes
232
00:08:11,540 --> 00:08:12,900
over the next few months.
233
00:08:12,900 --> 00:08:15,500
If the volumes belong to the production SQL volume group,
234
00:08:15,500 --> 00:08:17,300
they can use the same approved network path
235
00:08:17,300 --> 00:08:19,100
and connection setup as the rest of that group.
236
00:08:19,100 --> 00:08:21,260
You don't rebuild the same access rules 10 times
237
00:08:21,260 --> 00:08:22,740
and hope every setting matches.
238
00:08:22,740 --> 00:08:24,460
It also makes ownership clearer.
239
00:08:24,460 --> 00:08:26,340
When someone opens the elastic SAN resource,
240
00:08:26,340 --> 00:08:28,620
they can see which area belongs to production,
241
00:08:28,620 --> 00:08:31,340
which to testing, and which to a container platform.
242
00:08:31,340 --> 00:08:33,860
Storage doesn't turn into a long, confusing list
243
00:08:33,860 --> 00:08:35,700
of volumes with names that only made sense
244
00:08:35,700 --> 00:08:36,940
to the person who created them.
245
00:08:36,940 --> 00:08:38,580
At the bottom layer, you have volumes.
246
00:08:38,580 --> 00:08:40,700
A volume is the actual block storage unit
247
00:08:40,700 --> 00:08:42,260
that a workload connects to.
248
00:08:42,260 --> 00:08:45,060
You create a volume with a size, place it inside a volume group,
249
00:08:45,060 --> 00:08:47,380
and then connected to an approved VM cluster
250
00:08:47,380 --> 00:08:49,860
or supported platform through ISCSI.
251
00:08:49,860 --> 00:08:52,220
A SQL server might use one volume for database files
252
00:08:52,220 --> 00:08:54,180
and another for transaction logs.
253
00:08:54,180 --> 00:08:57,060
An AKS storage setup may create volumes for application data
254
00:08:57,060 --> 00:08:59,260
that needs to persist even when a container restarts.
255
00:08:59,260 --> 00:09:01,340
A clustered workload may connect to storage
256
00:09:01,340 --> 00:09:03,980
designed for its shared storage pattern.
257
00:09:03,980 --> 00:09:06,540
Each volume remains its own separate storage unit.
258
00:09:06,540 --> 00:09:07,860
That point can confuse people.
259
00:09:07,860 --> 00:09:09,820
A shared SAN doesn't mean every workload
260
00:09:09,820 --> 00:09:11,780
writes into one huge common drive.
261
00:09:11,780 --> 00:09:14,940
Volumes keep data separate, and each volume has its own size
262
00:09:14,940 --> 00:09:16,540
and own performance limits.
263
00:09:16,540 --> 00:09:18,260
The SAN provides the wider pool.
264
00:09:18,260 --> 00:09:21,420
The volume defines what one workload can connect to and use,
265
00:09:21,420 --> 00:09:23,140
so there are limits at more than one level.
266
00:09:23,140 --> 00:09:25,620
A volume must be large enough for the data it holds,
267
00:09:25,620 --> 00:09:27,500
but it must also have the right size
268
00:09:27,500 --> 00:09:28,740
for the performance it needs.
269
00:09:28,740 --> 00:09:30,100
At the same time, the whole SAN
270
00:09:30,100 --> 00:09:32,300
must have enough total capacity and performance
271
00:09:32,300 --> 00:09:33,620
for all its volumes together.
272
00:09:33,620 --> 00:09:35,420
You can't create a tiny volume and expect it
273
00:09:35,420 --> 00:09:37,660
to behave like an unlimited storage device,
274
00:09:37,660 --> 00:09:39,540
just because it sits inside a large SAN.
275
00:09:39,540 --> 00:09:41,340
Access also stays private.
276
00:09:41,340 --> 00:09:43,300
You don't expose an elastic SAN volume
277
00:09:43,300 --> 00:09:45,100
to the public internet like a web page.
278
00:09:45,100 --> 00:09:46,780
You set up private network paths,
279
00:09:46,780 --> 00:09:48,740
then allow approved workload connections
280
00:09:48,740 --> 00:09:49,860
through the volume group.
281
00:09:49,860 --> 00:09:53,100
That gives you a clear boundary around who can reach the storage.
282
00:09:53,100 --> 00:09:54,420
So the structure is simple.
283
00:09:54,420 --> 00:09:56,060
The SAN is the overall resource.
284
00:09:56,060 --> 00:09:57,380
Volume groups organize workloads
285
00:09:57,380 --> 00:09:59,100
and apply shared connection rules.
286
00:09:59,100 --> 00:10:01,060
Volumes are the individual storage units
287
00:10:01,060 --> 00:10:02,300
that workloads use.
288
00:10:02,300 --> 00:10:04,300
That handles organization and access.
289
00:10:04,300 --> 00:10:06,220
The next part is what changes the design,
290
00:10:06,220 --> 00:10:08,420
how the available storage performance gets shared
291
00:10:08,420 --> 00:10:10,980
when different workloads needed at different times.
292
00:10:10,980 --> 00:10:13,380
How shared performance changes the design?
293
00:10:13,380 --> 00:10:16,580
Imagine you have four SQL databases in the same business.
294
00:10:16,580 --> 00:10:18,580
The sales database gets busy during the day
295
00:10:18,580 --> 00:10:21,020
while finance runs heavy reports near month end.
296
00:10:21,020 --> 00:10:22,980
A warehouse system works hardest overnight
297
00:10:22,980 --> 00:10:24,500
and another database barely moves
298
00:10:24,500 --> 00:10:26,100
except during a weekly import.
299
00:10:26,100 --> 00:10:28,660
With separate disks, each database needs enough performance
300
00:10:28,660 --> 00:10:30,140
for its own worst moment.
301
00:10:30,140 --> 00:10:31,700
That often means buying more speed
302
00:10:31,700 --> 00:10:33,780
than each disk uses most of the time.
303
00:10:33,780 --> 00:10:36,700
So the storage stays ready, but much of it sits idle.
304
00:10:36,700 --> 00:10:38,220
Elastic SAN changes that pattern
305
00:10:38,220 --> 00:10:40,860
because the volumes draw from a shared performance budget.
306
00:10:40,860 --> 00:10:42,580
If the finance volume needs more IOPS
307
00:10:42,580 --> 00:10:44,300
while the warehouse volume stays quiet,
308
00:10:44,300 --> 00:10:46,940
finance can use more of the SANs available pool.
309
00:10:46,940 --> 00:10:48,460
When the workload shifts later,
310
00:10:48,460 --> 00:10:50,700
the available performance can shift too.
311
00:10:50,700 --> 00:10:51,660
That can reduce waste,
312
00:10:51,660 --> 00:10:53,820
but it also changes what you need to monitor.
313
00:10:53,820 --> 00:10:56,380
Instead of looking only at one disk and one VM,
314
00:10:56,380 --> 00:10:57,940
you watch the whole say N
315
00:10:57,940 --> 00:10:59,740
because every volume connected to it
316
00:10:59,740 --> 00:11:02,700
can affect the others when demand rises at the same time.
317
00:11:03,580 --> 00:11:05,180
Managed disks use a different model.
318
00:11:05,180 --> 00:11:07,060
A disk has its own performance level
319
00:11:07,060 --> 00:11:08,660
and the VM has an overall limit
320
00:11:08,660 --> 00:11:10,460
for disk IOPS and throughput.
321
00:11:10,460 --> 00:11:12,300
Do you plan each server around those boundaries
322
00:11:12,300 --> 00:11:13,820
which gives clear isolation
323
00:11:13,820 --> 00:11:16,060
but can also force you to buy a larger VM
324
00:11:16,060 --> 00:11:18,900
or faster disks just to reach a storage target?
325
00:11:18,900 --> 00:11:22,620
Elastic SAN volumes connect over the network through ISCSI.
326
00:11:22,620 --> 00:11:25,580
That means they don't use the usual managed disk slots
327
00:11:25,580 --> 00:11:27,700
and they don't depend on the VM's normal disk
328
00:11:27,700 --> 00:11:29,500
throughput limits in the same way.
329
00:11:29,500 --> 00:11:31,780
Instead, the design depends on the SANs total performance,
330
00:11:31,780 --> 00:11:33,340
the performance limit of each volume
331
00:11:33,340 --> 00:11:35,780
and the network capacity between the workload and the SAN.
332
00:11:35,780 --> 00:11:37,780
So you've moved the limit, not removed it,
333
00:11:37,780 --> 00:11:40,700
a shared pool doesn't create unlimited storage speed.
334
00:11:40,700 --> 00:11:43,340
If several busy volumes ask for more IOPS and throughput
335
00:11:43,340 --> 00:11:45,740
then the SAN can supply Azure Throttles the extra work,
336
00:11:45,740 --> 00:11:48,300
request take longer and your apps may feel slower.
337
00:11:48,300 --> 00:11:49,740
The SAN needs enough headroom
338
00:11:49,740 --> 00:11:51,980
for the combined peak demand you expect.
339
00:11:51,980 --> 00:11:53,180
Each volume has limits too.
340
00:11:53,180 --> 00:11:57,460
It can reach up to 80,000 IOPS and 1,180 Mbps,
341
00:11:57,460 --> 00:11:58,820
but only when it's size,
342
00:11:58,820 --> 00:12:01,780
the SAN configuration and the connection setup supported.
343
00:12:01,780 --> 00:12:03,020
Notice that first part.
344
00:12:03,020 --> 00:12:04,500
When its size supports it.
345
00:12:04,500 --> 00:12:07,380
With Elastic SAN, a volume's possible performance rises
346
00:12:07,380 --> 00:12:09,380
with its size until it reaches the service limit.
347
00:12:09,380 --> 00:12:11,100
So if a workload needs very high IOPS
348
00:12:11,100 --> 00:12:13,060
you can't create a tiny volume and expect it
349
00:12:13,060 --> 00:12:14,500
to pull that much from the pool.
350
00:12:14,500 --> 00:12:16,340
Here's the thing, think of it like a loading dock.
351
00:12:16,340 --> 00:12:18,220
The whole building may have a large number of workers
352
00:12:18,220 --> 00:12:19,300
and trucks available,
353
00:12:19,300 --> 00:12:21,060
but a small loading bay only has room
354
00:12:21,060 --> 00:12:22,700
for so much activity at once.
355
00:12:22,700 --> 00:12:24,700
The SAN is the building's total capacity,
356
00:12:24,700 --> 00:12:26,940
the volume is the loading bay for one workload
357
00:12:26,940 --> 00:12:28,420
and both need enough room.
358
00:12:28,420 --> 00:12:30,340
Let's make that practical.
359
00:12:30,340 --> 00:12:32,820
A company runs several SQL server databases.
360
00:12:32,820 --> 00:12:35,380
One handles customer orders during business hours,
361
00:12:35,380 --> 00:12:37,580
another runs payroll every second Friday
362
00:12:37,580 --> 00:12:40,700
and a third receives large data imports overnight.
363
00:12:40,700 --> 00:12:43,300
With separate disks, the team might size all three
364
00:12:43,300 --> 00:12:44,620
for their individual peak
365
00:12:44,620 --> 00:12:46,620
even though those peaks rarely happen together.
366
00:12:46,620 --> 00:12:48,820
With Elastic SAN, they can measure the actual timing
367
00:12:48,820 --> 00:12:51,620
and size a shared pool around the likely combined demand.
368
00:12:51,620 --> 00:12:53,660
So one database can use more performance
369
00:12:53,660 --> 00:12:55,100
while the others stay quiet,
370
00:12:55,100 --> 00:12:58,860
without paying for the same unused peak capacity three times.
371
00:12:58,860 --> 00:13:01,580
But more storage performance won't repair every slow system.
372
00:13:01,580 --> 00:13:04,620
A poor SQL query can still scan far too much data
373
00:13:04,620 --> 00:13:06,740
and a missing index can still delay a report.
374
00:13:06,740 --> 00:13:09,260
A VM with two little CPU can still struggle
375
00:13:09,260 --> 00:13:12,060
and a weak network path can slow ISC-SI traffic
376
00:13:12,060 --> 00:13:14,060
before the SAN even gets a chance to help.
377
00:13:14,060 --> 00:13:16,380
Storage only fixes a storage problem.
378
00:13:16,380 --> 00:13:18,740
That's why planning starts with real measurements.
379
00:13:18,740 --> 00:13:21,060
Look at I/OPS, throughput, latency
380
00:13:21,060 --> 00:13:22,940
and when each workload gets busy.
381
00:13:22,940 --> 00:13:25,780
Base capacity gives your SAN its starting performance pool
382
00:13:25,780 --> 00:13:28,500
so adding capacity can also add more performance headroom.
383
00:13:28,500 --> 00:13:30,820
Watch the demand before you grow the pool.
384
00:13:30,820 --> 00:13:33,260
Shared performance can lower wasted spend
385
00:13:33,260 --> 00:13:36,500
but only when the workloads truly take turns using it.
386
00:13:36,500 --> 00:13:38,620
Where Elastic SAN fits and where it doesn't.
387
00:13:38,620 --> 00:13:41,060
Elastic SAN works best when you have several workloads
388
00:13:41,060 --> 00:13:42,460
that need fast block storage
389
00:13:42,460 --> 00:13:46,180
and their storage demand doesn't peak at the same time.
390
00:13:46,180 --> 00:13:48,940
A group of SQL server databases is a good example.
391
00:13:48,940 --> 00:13:50,620
You may have separate database servers
392
00:13:50,620 --> 00:13:53,900
for orders, reporting, finance and internal apps.
393
00:13:53,900 --> 00:13:55,580
They all need reliable storage
394
00:13:55,580 --> 00:13:57,300
but their busiest hours can differ,
395
00:13:57,300 --> 00:13:59,300
which gives a shared SAN room to work.
396
00:13:59,300 --> 00:14:01,740
It can also fit clustered SQL server designs
397
00:14:01,740 --> 00:14:04,460
including SQL server failover cluster instances
398
00:14:04,460 --> 00:14:05,780
which expect shared storage
399
00:14:05,780 --> 00:14:07,820
that more than one cluster node can reach.
400
00:14:07,820 --> 00:14:09,940
Elastic SAN gives you a managed Azure option
401
00:14:09,940 --> 00:14:11,420
for that familiar SAN pattern
402
00:14:11,420 --> 00:14:14,380
without asking you to build and run storage hardware yourself.
403
00:14:14,380 --> 00:14:16,420
For database teams moving workloads
404
00:14:16,420 --> 00:14:18,140
from an on-premises data center,
405
00:14:18,140 --> 00:14:19,340
this can feel more natural
406
00:14:19,340 --> 00:14:21,060
than redesigning every storage layout
407
00:14:21,060 --> 00:14:22,660
around separate VM disks.
408
00:14:22,660 --> 00:14:25,380
Azure VMWare solution is another strong use case.
409
00:14:25,380 --> 00:14:27,660
VMWare environments often use data stores
410
00:14:27,660 --> 00:14:29,340
and storage growth can become tied
411
00:14:29,340 --> 00:14:31,060
to adding more cluster hosts.
412
00:14:31,060 --> 00:14:34,140
With Elastic SAN, you can connect external ISCSI storage
413
00:14:34,140 --> 00:14:36,580
as a data store, meaning you can add storage capacity
414
00:14:36,580 --> 00:14:38,700
without automatically adding compute capacity
415
00:14:38,700 --> 00:14:39,900
that you may not need.
416
00:14:39,900 --> 00:14:41,060
That separation can matter
417
00:14:41,060 --> 00:14:43,420
when your virtual machines need more room for data
418
00:14:43,420 --> 00:14:46,460
but the AVS cluster already has enough CPU and memory.
419
00:14:46,460 --> 00:14:48,420
Kubernetes can use Elastic SAN too
420
00:14:48,420 --> 00:14:50,140
through supported storage designs.
421
00:14:50,140 --> 00:14:51,220
Containers come and go
422
00:14:51,220 --> 00:14:53,260
but some applications need data to remain
423
00:14:53,260 --> 00:14:54,900
after a container restarts.
424
00:14:54,900 --> 00:14:57,180
A database running in a container, for example,
425
00:14:57,180 --> 00:14:59,380
can't treat its data as temporary.
426
00:14:59,380 --> 00:15:01,180
So the storage design needs to match
427
00:15:01,180 --> 00:15:03,580
the Kubernetes platform, the application
428
00:15:03,580 --> 00:15:05,700
and the supported Azure connection method.
429
00:15:05,700 --> 00:15:08,900
Don't treat Elastic SAN as a generic container storage switch.
430
00:15:08,900 --> 00:15:11,620
Check the storage driver, access mode, network path
431
00:15:11,620 --> 00:15:14,460
and recovery design before you put an application into production
432
00:15:14,460 --> 00:15:16,660
because Kubernetes adds its own layer of rules
433
00:15:16,660 --> 00:15:18,820
and the storage needs to fit those rules.
434
00:15:18,820 --> 00:15:20,660
Data protection also comes into the picture.
435
00:15:20,660 --> 00:15:23,740
Elastic SAN supports point in time snapshots of volumes
436
00:15:23,740 --> 00:15:25,220
which record changes over time
437
00:15:25,220 --> 00:15:26,460
and can help you restore a volume
438
00:15:26,460 --> 00:15:28,300
or create a new volume from a recovery point.
439
00:15:28,300 --> 00:15:30,820
That can be useful when a database refresh goes wrong.
440
00:15:30,820 --> 00:15:32,180
A test environment needs a copy
441
00:15:32,180 --> 00:15:34,700
or a team needs to recover from a bad change.
442
00:15:34,700 --> 00:15:36,420
Still, a snapshot isn't the same thing
443
00:15:36,420 --> 00:15:37,940
as a complete backup plan.
444
00:15:37,940 --> 00:15:40,340
Your workload may need application-aware backups,
445
00:15:40,340 --> 00:15:43,100
copies kept for a longer period, recovery tests
446
00:15:43,100 --> 00:15:44,860
and a plan for a wider outage.
447
00:15:44,860 --> 00:15:47,740
A database can have data on storage that looks healthy
448
00:15:47,740 --> 00:15:50,540
while its transaction state still needs careful recovery
449
00:15:50,540 --> 00:15:52,060
so the storage layer can help
450
00:15:52,060 --> 00:15:54,300
but it can't decide that process for you.
451
00:15:54,300 --> 00:15:56,620
Azure also encrypts Elastic SAN data address
452
00:15:56,620 --> 00:15:58,620
and you can choose redundancy options based
453
00:15:58,620 --> 00:16:00,700
on what's available for your region and design
454
00:16:00,700 --> 00:16:03,100
while access stays on private network paths
455
00:16:03,100 --> 00:16:05,540
keeping storage traffic away from the public internet.
456
00:16:05,540 --> 00:16:07,100
Those controls reduce risk
457
00:16:07,100 --> 00:16:09,820
but they don't replace good network design or monitoring.
458
00:16:09,820 --> 00:16:12,020
So when does Elastic SAN not make sense?
459
00:16:12,020 --> 00:16:14,020
A small app server with one modest data disk
460
00:16:14,020 --> 00:16:15,220
usually doesn't need it
461
00:16:15,220 --> 00:16:18,220
and a simple VM with steady, low storage demand
462
00:16:18,220 --> 00:16:19,620
doesn't need it either.
463
00:16:19,620 --> 00:16:22,300
In those cases, manage disks remain easier to set up,
464
00:16:22,300 --> 00:16:24,820
easier to reason about and often cheaper.
465
00:16:24,820 --> 00:16:26,860
The same applies when a workload needs strict performance
466
00:16:26,860 --> 00:16:27,620
isolation.
467
00:16:27,620 --> 00:16:29,780
With a shared pool, you need to plan for other workloads
468
00:16:29,780 --> 00:16:30,780
using the same sense.
469
00:16:30,780 --> 00:16:32,620
So if one application must always have its own
470
00:16:32,620 --> 00:16:34,740
fixed storage performance and there's no wider group
471
00:16:34,740 --> 00:16:37,300
to share with, a dedicated managed disk design
472
00:16:37,300 --> 00:16:38,740
may be the cleaner choice.
473
00:16:38,740 --> 00:16:40,220
The cost rules stay simple.
474
00:16:40,220 --> 00:16:42,660
Pooling helps when many workloads can share capacity
475
00:16:42,660 --> 00:16:45,660
and performance but if you only need one small private disk,
476
00:16:45,660 --> 00:16:48,220
a shared SAN can add setup work and cost
477
00:16:48,220 --> 00:16:49,660
without giving you much back.
478
00:16:49,660 --> 00:16:51,620
So Elastic SAN doesn't remove the need
479
00:16:51,620 --> 00:16:53,820
for backups, network planning, workload testing
480
00:16:53,820 --> 00:16:55,580
or watching performance over time.
481
00:16:55,580 --> 00:16:57,380
It gives you a different storage model
482
00:16:57,380 --> 00:16:59,780
and whether that model fits depends on the workloads you
483
00:16:59,780 --> 00:17:00,700
place inside it.
484
00:17:00,700 --> 00:17:02,740
We'll explore each of these use cases in more detail
485
00:17:02,740 --> 00:17:03,980
in future episodes.
486
00:17:03,980 --> 00:17:05,260
So stay tuned.
487
00:17:05,260 --> 00:17:06,660
A simple way to decide.
488
00:17:06,660 --> 00:17:08,860
Grab a list of the workloads you already run.
489
00:17:08,860 --> 00:17:10,700
Note how much storage each one needs,
490
00:17:10,700 --> 00:17:13,380
its peak IOPS and throughput and when those busy periods
491
00:17:13,380 --> 00:17:14,540
actually hit.
492
00:17:14,540 --> 00:17:16,420
Don't guess based on one quiet day,
493
00:17:16,420 --> 00:17:19,140
pull monitoring data from normal operations, batch jobs,
494
00:17:19,140 --> 00:17:20,940
reporting cycles, and backups.
495
00:17:20,940 --> 00:17:22,220
That gives you the real picture.
496
00:17:22,220 --> 00:17:23,380
Now look for a pattern.
497
00:17:23,380 --> 00:17:25,220
Do you have several performance heavy workloads
498
00:17:25,220 --> 00:17:26,780
that all need block storage and do their
499
00:17:26,780 --> 00:17:28,860
busiest times avoid overlapping?
500
00:17:28,860 --> 00:17:31,300
If so, Elastic SAN is worth a closer look.
501
00:17:31,300 --> 00:17:32,420
Here's the real test.
502
00:17:32,420 --> 00:17:34,260
Compare it against the managed disk design
503
00:17:34,260 --> 00:17:35,620
you would otherwise build.
504
00:17:35,620 --> 00:17:38,060
Factor in disk charges, VM disk limits,
505
00:17:38,060 --> 00:17:40,860
the hours spent wrangling dozens of separate disks
506
00:17:40,860 --> 00:17:43,020
and all that performance you end up paying for,
507
00:17:43,020 --> 00:17:44,140
but never using.
508
00:17:44,140 --> 00:17:45,820
Before you commit, run a small test
509
00:17:45,820 --> 00:17:47,580
with one related workload group.
510
00:17:47,580 --> 00:17:49,980
Measure latency, IOPS, throughput
511
00:17:49,980 --> 00:17:53,060
and how the SAN handles total demand under realistic load.
512
00:17:53,060 --> 00:17:54,380
Test recovery too.
513
00:17:54,380 --> 00:17:56,220
Once the numbers back the design,
514
00:17:56,220 --> 00:17:57,540
you can scale from there.
515
00:17:57,540 --> 00:17:59,700
When the pattern fits, you end up with storage
516
00:17:59,700 --> 00:18:01,540
that's easier to organize and file a scatter
517
00:18:01,540 --> 00:18:03,060
across individual servers.
518
00:18:03,060 --> 00:18:04,020
That's the payoff.
519
00:18:04,020 --> 00:18:06,940
So what exactly is Azure Elastic SAN?
520
00:18:06,940 --> 00:18:08,820
It takes high performance block storage
521
00:18:08,820 --> 00:18:11,500
and turns it into a managed shared pool inside Azure.
522
00:18:11,500 --> 00:18:14,300
You create one SAN, organize access through volume groups
523
00:18:14,300 --> 00:18:16,780
and connect individual volumes to approved workloads
524
00:18:16,780 --> 00:18:18,140
over ISC ESI.
525
00:18:18,140 --> 00:18:20,060
This works well for groups of databases,
526
00:18:20,060 --> 00:18:21,860
clustered apps, VMware setups
527
00:18:21,860 --> 00:18:23,660
and supported container designs.
528
00:18:23,660 --> 00:18:25,140
Anywhere you need fast storage
529
00:18:25,140 --> 00:18:27,620
and the workloads can share performance sensibly.
530
00:18:27,620 --> 00:18:29,620
Your practical next step, pick one group
531
00:18:29,620 --> 00:18:31,820
of related database or clustered workloads,
532
00:18:31,820 --> 00:18:33,500
compare their combined peak demand
533
00:18:33,500 --> 00:18:36,340
against the separate managed disks they used today
534
00:18:36,340 --> 00:18:38,580
and check whether those peaks really overlap.
535
00:18:38,580 --> 00:18:40,660
If they don't, the pool approach wins.
536
00:18:40,660 --> 00:18:42,540
For everything else, Azure managed disks
537
00:18:42,540 --> 00:18:44,380
with a private disk per VM
538
00:18:44,380 --> 00:18:46,100
might still be the better fit.
