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.