1 00:00:00,000 --> 00:00:04,800 Welcome to another episode of Microsoft Knowledge Nuggets here on M365 FFM, I'm your host, 2 00:00:04,800 --> 00:00:05,800 Mucopeters. 3 00:00:05,800 --> 00:00:09,560 In this series, we take one Microsoft technology and explain it in plain English. 4 00:00:09,560 --> 00:00:13,360 Today's topic is one that almost everyone has heard of, but very few people actually 5 00:00:13,360 --> 00:00:15,680 understand as you're a load balancer. 6 00:00:15,680 --> 00:00:17,840 Imagine running a restaurant with only one chef. 7 00:00:17,840 --> 00:00:19,880 If they call in sick, the kitchen shuts down. 8 00:00:19,880 --> 00:00:24,160 If a crowd shows up, the orders pile up, and nobody gets fed, that's the problem with 9 00:00:24,160 --> 00:00:25,880 running your app on a single server. 10 00:00:25,880 --> 00:00:29,560 Most people think a single server is fine for low traffic apps until it isn't. 11 00:00:29,560 --> 00:00:31,120 And by then, it's too late. 12 00:00:31,120 --> 00:00:34,640 By the end of this episode, you'll understand what Azure Load Balancer actually does, why 13 00:00:34,640 --> 00:00:38,280 you need one, and how it keeps your apps running even when things break. 14 00:00:38,280 --> 00:00:41,160 Think of it as the smart reception desk for your servers. 15 00:00:41,160 --> 00:00:44,640 That mental model is going to carry us through everything that follows. 16 00:00:44,640 --> 00:00:47,840 Why your app needs a bouncer, the case for load balancing? 17 00:00:47,840 --> 00:00:52,080 Here's the thing, when you start a new app, it's easy to just put everything on one server. 18 00:00:52,080 --> 00:00:53,560 One VM handles all the traffic. 19 00:00:53,560 --> 00:00:54,240 It's simple. 20 00:00:54,240 --> 00:00:56,520 It works, until it doesn't. 21 00:00:56,520 --> 00:01:00,440 That single server has three problems it can't solve on its own. 22 00:01:00,440 --> 00:01:02,840 First availability, what if the server crashes? 23 00:01:02,840 --> 00:01:04,040 The app goes down. 24 00:01:04,040 --> 00:01:05,040 Second, performance. 25 00:01:05,040 --> 00:01:06,160 What if traffic spikes? 26 00:01:06,160 --> 00:01:09,240 The server gets overwhelmed and your users get a spinning wheel of death. 27 00:01:09,240 --> 00:01:10,720 Third, maintenance. 28 00:01:10,720 --> 00:01:13,840 How do you update the software without taking the app offline? 29 00:01:13,840 --> 00:01:15,600 You can't, because there's only one server. 30 00:01:15,600 --> 00:01:19,560 The solution is obvious when you step back, spread the work across multiple servers, and 31 00:01:19,560 --> 00:01:23,040 put something in front that decides which server handles each request. 32 00:01:23,040 --> 00:01:24,560 That something is a load balancer. 33 00:01:24,560 --> 00:01:26,280 Let me give you a real example. 34 00:01:26,280 --> 00:01:28,880 Imagine a small e-commerce site during Black Friday. 35 00:01:28,880 --> 00:01:31,880 One server buckles under the traffic, pages load slowly. 36 00:01:31,880 --> 00:01:32,880 Customers leave. 37 00:01:32,880 --> 00:01:36,080 But with multiple servers behind a load balancer, nobody notices. 38 00:01:36,080 --> 00:01:37,080 Traffic gets spread out. 39 00:01:37,080 --> 00:01:40,120 Every server handles its share, and the site stays fast. 40 00:01:40,120 --> 00:01:43,000 One server fails, the load balancer sends traffic to the others. 41 00:01:43,000 --> 00:01:44,440 The customers never even know. 42 00:01:44,440 --> 00:01:46,160 So how does Azure actually do this? 43 00:01:46,160 --> 00:01:47,960 Let's build a mental model. 44 00:01:47,960 --> 00:01:49,320 The Smart Reception Desk. 45 00:01:49,320 --> 00:01:51,560 Your mental model for Azure Load Balancer. 46 00:01:51,560 --> 00:01:54,960 Think of Azure Load Balancer as the reception desk in a busy office building. 47 00:01:54,960 --> 00:01:57,560 The front end IP is the building's street address. 48 00:01:57,560 --> 00:02:00,000 It's the one single door that everyone knocks on. 49 00:02:00,000 --> 00:02:03,200 When someone visits your app, they hit this address, they don't know about the servers behind 50 00:02:03,200 --> 00:02:04,200 the scenes. 51 00:02:04,200 --> 00:02:07,720 The back end pool is the group of employees who actually do the work. 52 00:02:07,720 --> 00:02:08,880 These are your virtual machines. 53 00:02:08,880 --> 00:02:11,440 They sit in the back, ready to handle whatever comes in. 54 00:02:11,440 --> 00:02:15,000 Health probes are the receptionist checking if each employee is awake and able to take 55 00:02:15,000 --> 00:02:16,000 work. 56 00:02:16,000 --> 00:02:20,400 Every few seconds, the receptionist looks over and says, hey, are you still with us? 57 00:02:20,400 --> 00:02:23,960 If an employee doesn't respond, the receptionist stops sending people their way. 58 00:02:23,960 --> 00:02:26,640 Load balancing rules are the instructions for who goes where? 59 00:02:26,640 --> 00:02:31,200 The receptionist has a set of rules that say, anyone asking about billing goes to desk three, 60 00:02:31,200 --> 00:02:33,400 anyone with a delivery goes to desk five. 61 00:02:33,400 --> 00:02:37,880 In Azure, these rules say, anyone hitting port 80 goes to port 80 on a VM in the back end 62 00:02:37,880 --> 00:02:38,880 pool. 63 00:02:38,880 --> 00:02:40,000 Here's the thing to remember. 64 00:02:40,000 --> 00:02:41,760 The load balancer itself doesn't do the work. 65 00:02:41,760 --> 00:02:43,600 It's a traffic cop, not a worker. 66 00:02:43,600 --> 00:02:47,040 It just directs traffic to the servers that actually handle the requests. 67 00:02:47,040 --> 00:02:51,840 It operates at layer four of the network model, which means it works with TCP and UDP traffic. 68 00:02:51,840 --> 00:02:54,720 It doesn't read your web traffic or inspect what's inside the packets. 69 00:02:54,720 --> 00:02:58,280 It just looks at IP addresses and ports and makes a decision. 70 00:02:58,280 --> 00:03:02,280 Now let's break down each part of this reception desk one at a time. 71 00:03:02,280 --> 00:03:04,920 Frontend IP, back end pool and the rules that connect them. 72 00:03:04,920 --> 00:03:08,120 So you've got this reception desk, but how does it actually work? 73 00:03:08,120 --> 00:03:10,480 Let's walk through the three pieces that make it tick. 74 00:03:10,480 --> 00:03:12,120 First, the frontend IP. 75 00:03:12,120 --> 00:03:14,280 This is the address your user actually connect to. 76 00:03:14,280 --> 00:03:19,200 It can be a public IP if your app faces the internet or a private IP if it only lives inside your 77 00:03:19,200 --> 00:03:20,200 virtual network. 78 00:03:20,200 --> 00:03:23,240 You can even have multiple frontend IPs on the same load balancer. 79 00:03:23,240 --> 00:03:26,440 Think of it like having a main entrance and a loading dock, different traffic, different 80 00:03:26,440 --> 00:03:27,960 doors, same building. 81 00:03:27,960 --> 00:03:29,160 Second, the back end pool. 82 00:03:29,160 --> 00:03:32,080 This is where you put your virtual machines or VM scale sets. 83 00:03:32,080 --> 00:03:35,760 The load balancer only sends traffic to members of this pool that are healthy. 84 00:03:35,760 --> 00:03:39,560 If a VM is in the pool but not responding, it doesn't get traffic, simple as that. 85 00:03:39,560 --> 00:03:41,280 Third, the load balancing rules. 86 00:03:41,280 --> 00:03:42,880 These are the glue that connects everything. 87 00:03:42,880 --> 00:03:46,960 A rule says anyone hitting port 80 on this frontend IP gets sent to port 80 on a VM in this 88 00:03:46,960 --> 00:03:48,200 back end pool. 89 00:03:48,200 --> 00:03:49,200 That's it. 90 00:03:49,200 --> 00:03:53,120 You define the frontend, you define the back end and the rule tells the load balancer how 91 00:03:53,120 --> 00:03:54,520 to connect them. 92 00:03:54,520 --> 00:03:55,520 Here's a concrete example. 93 00:03:55,520 --> 00:03:57,840 Say you have a web app running on port 80. 94 00:03:57,840 --> 00:04:01,080 You create a frontend IP, let's call it 40.40404040. 95 00:04:01,080 --> 00:04:03,040 You create a back end pool with two VMs. 96 00:04:03,040 --> 00:04:07,920 Then you create a rule that says traffic to 40404040 on port 80 goes to port 80 on the 97 00:04:07,920 --> 00:04:09,240 back end pool. 98 00:04:09,240 --> 00:04:12,560 Now when someone visits your site, the load balancer picks one of those two VMs and 99 00:04:12,560 --> 00:04:14,080 sends the request there. 100 00:04:14,080 --> 00:04:16,960 There's also something called inbound in-at rules. 101 00:04:16,960 --> 00:04:21,400 These let you map specific ports on the frontend IP to specific VMs in the back end pool. 102 00:04:21,400 --> 00:04:26,400 So if you need to RDP into VM number one, you can hit port 5,001 on the frontend and 103 00:04:26,400 --> 00:04:30,360 the load balancer sends you directly to port 3389 on that VM. 104 00:04:30,360 --> 00:04:32,280 No public IP needed on the VM itself. 105 00:04:32,280 --> 00:04:36,840 It's a clean way to manage remote access without exposing your VMs directly to the internet. 106 00:04:36,840 --> 00:04:40,560 But how does the receptionist know which employee is actually ready to work? 107 00:04:40,560 --> 00:04:42,440 That's where health probes come in. 108 00:04:42,440 --> 00:04:43,440 Who's listening? 109 00:04:43,440 --> 00:04:45,080 Health probes and why they matter. 110 00:04:45,080 --> 00:04:47,760 This is the feature that makes high availability possible. 111 00:04:47,760 --> 00:04:51,440 Without health probes, your load balancer would just blindly send traffic to every server 112 00:04:51,440 --> 00:04:53,200 in the pool, even the dead ones. 113 00:04:53,200 --> 00:04:54,200 Here's how it works. 114 00:04:54,200 --> 00:04:58,000 The load balancer sends a ping to each back end server every few seconds. 115 00:04:58,000 --> 00:05:00,800 Think of it like the receptionist checking in on each employee. 116 00:05:00,800 --> 00:05:01,800 You still there? 117 00:05:01,800 --> 00:05:02,800 You still able to work? 118 00:05:02,800 --> 00:05:05,080 If the server responds great, it stays in rotation. 119 00:05:05,080 --> 00:05:09,000 If it doesn't respond within a certain window, the load balancer removes it from the pool 120 00:05:09,000 --> 00:05:10,000 immediately. 121 00:05:10,000 --> 00:05:12,880 More traffic gets sent to it until it starts responding again. 122 00:05:12,880 --> 00:05:14,120 There are two types of probes. 123 00:05:14,120 --> 00:05:15,840 TCP probes just check if the port is open. 124 00:05:15,840 --> 00:05:17,760 They say, "Hey, is port 80 listening?" 125 00:05:17,760 --> 00:05:19,120 If yes, the server is healthy. 126 00:05:19,120 --> 00:05:22,040 HTTP and HTTPS probes go a step further. 127 00:05:22,040 --> 00:05:25,680 They actually send a request to a specific endpoint and check for a valid response. 128 00:05:25,680 --> 00:05:29,800 This is useful when you want to make sure the application itself is running, not just the 129 00:05:29,800 --> 00:05:30,800 operating system. 130 00:05:30,800 --> 00:05:32,640 Here's where beginners get tripped up. 131 00:05:32,640 --> 00:05:37,400 You set up a probe, you configure everything correctly, but the backend keeps showing as unhealthy. 132 00:05:37,400 --> 00:05:39,920 Nine times out of ten, the problem is the network security group. 133 00:05:39,920 --> 00:05:45,800 The probe traffic comes from a specific Azure IP address, 168.63, 129.16. 134 00:05:45,800 --> 00:05:48,400 If your NSG blocks that IP, the probe can't reach your server. 135 00:05:48,400 --> 00:05:51,640 The server is running fine, but the load balancer thinks it's dead. 136 00:05:51,640 --> 00:05:52,640 Traffic stops flowing. 137 00:05:52,640 --> 00:05:55,720 It's a simple fix once you know to look for it, but it catches almost everyone the first 138 00:05:55,720 --> 00:05:56,720 time. 139 00:05:56,720 --> 00:05:58,360 The real impact of health probes is this. 140 00:05:58,360 --> 00:06:01,120 When a server fails, users see zero downtime. 141 00:06:01,120 --> 00:06:05,920 The load balancer detects the failure, removes that server from rotation, and sends all traffic 142 00:06:05,920 --> 00:06:07,760 to the remaining healthy servers. 143 00:06:07,760 --> 00:06:09,360 Your users never know anything happened. 144 00:06:09,360 --> 00:06:11,040 That's the whole point of a load balancer. 145 00:06:11,040 --> 00:06:14,040 Now how does the load balancer decide which server gets each visitor? 146 00:06:14,040 --> 00:06:15,920 It's not random. 147 00:06:15,920 --> 00:06:17,920 Distribution logic, how traffic gets spread. 148 00:06:17,920 --> 00:06:21,960 So you've got a load balancer, you've got healthy servers in the backend pool, and you've 149 00:06:21,960 --> 00:06:24,200 got health probes keeping everyone honest. 150 00:06:24,200 --> 00:06:27,560 But how does the load balancer actually decide which server gets each visitor? 151 00:06:27,560 --> 00:06:29,320 Here's the thing, most people get wrong. 152 00:06:29,320 --> 00:06:31,600 Azure load balancer does not use round robin. 153 00:06:31,600 --> 00:06:35,040 It doesn't just take turns sending traffic to each server like a schoolteacher calling on 154 00:06:35,040 --> 00:06:36,200 students. 155 00:06:36,200 --> 00:06:39,240 Instead it uses something called a hash based distribution. 156 00:06:39,240 --> 00:06:40,400 Here's how it works. 157 00:06:40,400 --> 00:06:43,560 When a request comes in, the load balancer looks at five things. 158 00:06:43,560 --> 00:06:48,560 The source IP address, the source port, the destination IP address, the destination port, 159 00:06:48,560 --> 00:06:49,560 and the protocol. 160 00:06:49,560 --> 00:06:51,120 That's called the five tuple hash. 161 00:06:51,120 --> 00:06:55,120 It runs those five values through a mathematical function and gets a number. 162 00:06:55,120 --> 00:06:58,160 That number determines which backend server gets the request. 163 00:06:58,160 --> 00:07:00,920 The key insight is that this is per flow, not per packet. 164 00:07:00,920 --> 00:07:03,560 Every packet in a single connection goes to the same backend server. 165 00:07:03,560 --> 00:07:07,680 You don't want packets from the same user session bouncing between different servers. 166 00:07:07,680 --> 00:07:08,680 That would break things. 167 00:07:08,680 --> 00:07:13,040 Once the load balancer decides which server handles a connection, all packets in that connection 168 00:07:13,040 --> 00:07:14,400 stay with that server. 169 00:07:14,400 --> 00:07:17,840 Now there's something called session persistence or client IP affinity. 170 00:07:17,840 --> 00:07:21,880 When you enable this, all requests from the same client go to the same backend server. 171 00:07:21,880 --> 00:07:23,800 This is important for stateful applications. 172 00:07:23,800 --> 00:07:24,840 Think about a shopping cart. 173 00:07:24,840 --> 00:07:27,480 You add items, you browse around, you come back. 174 00:07:27,480 --> 00:07:31,160 If each request went to a different server, your cart would keep disappearing. 175 00:07:31,160 --> 00:07:34,880 Session persistence keeps you tied to one server, so your state stays intact. 176 00:07:34,880 --> 00:07:35,880 But here's the catch. 177 00:07:35,880 --> 00:07:39,160 Your load balancer does not enable session persistence by default. 178 00:07:39,160 --> 00:07:43,360 You have to explicitly turn it on and you should only do that when you actually need it. 179 00:07:43,360 --> 00:07:46,560 Because session persistence can cause uneven traffic distribution. 180 00:07:46,560 --> 00:07:50,800 If one client makes a thousand requests, they all go to the same server, even if the other 181 00:07:50,800 --> 00:07:52,280 servers are sitting idle. 182 00:07:52,280 --> 00:07:56,360 For most applications, the default hash based distribution is actually better. 183 00:07:56,360 --> 00:08:00,400 It spreads traffic more evenly across your backend servers, especially when you have a large 184 00:08:00,400 --> 00:08:01,720 number of connections. 185 00:08:01,720 --> 00:08:06,000 So to summarize, hash based distribution, per flow routing and session persistence only 186 00:08:06,000 --> 00:08:07,000 when you need it. 187 00:08:07,000 --> 00:08:08,480 That's how traffic gets spread. 188 00:08:08,480 --> 00:08:11,480 The load balancer we've been talking about handles traffic from the internet. 189 00:08:11,480 --> 00:08:14,120 But what about traffic between your own services? 190 00:08:14,120 --> 00:08:16,800 Public versus internal, two flavors, same engine. 191 00:08:16,800 --> 00:08:19,760 So far, we've been talking about a public load balancer. 192 00:08:19,760 --> 00:08:23,560 Someone on the internet hits your front end IP and the load balancer sends them to a backend 193 00:08:23,560 --> 00:08:24,560 server. 194 00:08:24,560 --> 00:08:25,560 But that's only half the story. 195 00:08:25,560 --> 00:08:30,000 There are actually two flavors of Azure load balancer and they use the exact same engine. 196 00:08:30,000 --> 00:08:31,440 The only difference is the front end. 197 00:08:31,440 --> 00:08:34,680 A public load balancer has a front end with a public IP address. 198 00:08:34,680 --> 00:08:38,120 Users from anywhere on the internet can hit that IP and reach your application. 199 00:08:38,120 --> 00:08:41,520 This is what you use for anything that faces the outside world. 200 00:08:41,520 --> 00:08:44,160 Your website, your API, your customer facing app. 201 00:08:44,160 --> 00:08:48,560 An internal load balancer has a front end with a private IP inside your virtual network. 202 00:08:48,560 --> 00:08:50,560 Only resources inside your vnet can reach it. 203 00:08:50,560 --> 00:08:51,560 No internet access. 204 00:08:51,560 --> 00:08:53,600 This is what you use for internal services. 205 00:08:53,600 --> 00:08:57,920 Your databases, your APIs between application tiers, your microservices that talk to each other 206 00:08:57,920 --> 00:08:59,160 behind the scenes. 207 00:08:59,160 --> 00:09:00,360 Here's where it gets interesting. 208 00:09:00,360 --> 00:09:02,360 Both types use the exact same logic. 209 00:09:02,360 --> 00:09:03,680 Both use health probes. 210 00:09:03,680 --> 00:09:05,600 Both use the same distribution algorithm. 211 00:09:05,600 --> 00:09:07,480 Both support the same rules and features. 212 00:09:07,480 --> 00:09:09,840 The only difference is the IP address at the front. 213 00:09:09,840 --> 00:09:11,720 Public or private, that's it. 214 00:09:11,720 --> 00:09:13,720 In a real world architecture, you'd use both. 215 00:09:13,720 --> 00:09:17,720 A public load balancer at the web tier handles incoming traffic from users. 216 00:09:17,720 --> 00:09:21,760 Behind that, your web servers process requests and send them to an internal load balancer 217 00:09:21,760 --> 00:09:23,560 at the business logic tier. 218 00:09:23,560 --> 00:09:27,240 That internal load balancer distributes work across your application servers. 219 00:09:27,240 --> 00:09:31,920 So behind those, another internal load balancer might connect to your database cluster. 220 00:09:31,920 --> 00:09:35,680 Each tier gets its own load balancer and traffic flows from public to private. 221 00:09:35,680 --> 00:09:37,480 Each step handled by the right tool. 222 00:09:37,480 --> 00:09:40,320 But Azure gives you more than one type of load balancer. 223 00:09:40,320 --> 00:09:44,400 Let's clear up the difference between standard gateway and the retired one. 224 00:09:44,400 --> 00:09:46,840 Standard versus gateway versus the dead basic. 225 00:09:46,840 --> 00:09:49,480 So we've covered public and internal load balancers. 226 00:09:49,480 --> 00:09:53,040 But Azure actually gives you three different types of load balancers and knowing which one 227 00:09:53,040 --> 00:09:54,040 to use matters. 228 00:09:54,040 --> 00:09:58,200 The one you should use for pretty much everything new is the standard load balancer. 229 00:09:58,200 --> 00:10:02,200 It's zone redundant, meaning it can survive an entire Azure data center going down. 230 00:10:02,200 --> 00:10:06,800 It supports HA ports, which lets you load balance all ports and protocols at once for things 231 00:10:06,800 --> 00:10:08,520 like network virtual appliances. 232 00:10:08,520 --> 00:10:12,040 It can handle up to a thousand backend instances in a single pool. 233 00:10:12,040 --> 00:10:15,160 And it gives you advanced diagnostics so you can actually see what's happening with your 234 00:10:15,160 --> 00:10:16,160 traffic. 235 00:10:16,160 --> 00:10:17,440 Standard is the default choice. 236 00:10:17,440 --> 00:10:19,560 If you're building something new, start here. 237 00:10:19,560 --> 00:10:21,480 Then there's the gateway load balancer. 238 00:10:21,480 --> 00:10:22,720 This one is more specialized. 239 00:10:22,720 --> 00:10:26,320 It's not designed to distribute traffic directly to your application servers. 240 00:10:26,320 --> 00:10:29,560 Instead it's a middleman that hands traffic off to a security appliance before it reaches 241 00:10:29,560 --> 00:10:30,560 your app. 242 00:10:30,560 --> 00:10:34,240 Think firewalls, intrusion detection systems or packet inspection tools. 243 00:10:34,240 --> 00:10:37,880 The gateway load balancer sits in the traffic path, sends everything through the appliance 244 00:10:37,880 --> 00:10:40,360 first and then forwards the clean traffic to your application. 245 00:10:40,360 --> 00:10:42,320 You don't need this for a simple web app. 246 00:10:42,320 --> 00:10:46,320 But if you have strict security requirements and need to chain multiple network appliances 247 00:10:46,320 --> 00:10:48,280 together, this is the tool. 248 00:10:48,280 --> 00:10:49,920 And then there's the basic load balancer. 249 00:10:49,920 --> 00:10:50,920 Don't use it. 250 00:10:50,920 --> 00:10:51,920 You can use it for a simple web app. 251 00:10:51,920 --> 00:10:52,920 You can use it for a simple web app. 252 00:10:52,920 --> 00:10:53,920 You can use it for a simple web app. 253 00:10:53,920 --> 00:10:54,920 You can use it for a simple web app. 254 00:10:54,920 --> 00:10:55,920 You can use it for a simple web app. 255 00:10:55,920 --> 00:10:56,920 You can use it for a simple web app. 256 00:10:56,920 --> 00:10:57,920 You can use it for a simple web app. 257 00:10:57,920 --> 00:10:58,920 You can use it for a simple web app. 258 00:10:58,920 --> 00:10:59,920 You can use it for a simple web app. 259 00:10:59,920 --> 00:11:00,920 You can use it for a simple web app. 260 00:11:00,920 --> 00:11:01,920 You can use it for a simple web app. 261 00:11:01,920 --> 00:11:02,920 You can use it for a simple web app. 262 00:11:02,920 --> 00:11:03,920 You can use it for a simple web app. 263 00:11:03,920 --> 00:11:04,920 You can use it for a simple web app. 264 00:11:04,920 --> 00:11:05,920 You can use it for a simple web app. 265 00:11:05,920 --> 00:11:06,920 You can use it for a simple web app. 266 00:11:06,920 --> 00:11:07,920 You can use it for a simple web app. 267 00:11:07,920 --> 00:11:08,920 You can use it for a simple web app. 268 00:11:08,920 --> 00:11:23,920 You can use it for a simple web app. 269 00:11:23,920 --> 00:11:24,920 You can use it for a simple web app. 270 00:11:24,920 --> 00:11:26,920 You can use it for a simple web app. 271 00:11:26,920 --> 00:11:27,920 You can use it for a simple web app. 272 00:11:27,920 --> 00:11:28,920 You can use it for a simple web app. 273 00:11:28,920 --> 00:11:30,920 You can use it for a simple web app. 274 00:11:30,920 --> 00:11:31,920 You can use it for a simple web app. 275 00:11:31,920 --> 00:11:32,920 You can use it for a simple web app. 276 00:11:32,920 --> 00:11:33,920 You can use it for a simple web app. 277 00:11:33,920 --> 00:11:34,920 You can use it for a simple web app. 278 00:11:34,920 --> 00:11:35,920 You can use it for a simple web app. 279 00:11:35,920 --> 00:11:36,920 You can use it for a simple web app. 280 00:11:36,920 --> 00:11:37,920 You can use it for a simple web app. 281 00:11:37,920 --> 00:11:40,920 You can figure the health probe, but the backend servers keep showing as unhealthy. 282 00:11:40,920 --> 00:11:44,920 Nine times out of ten, the problem is that your NSG is blocking the probe traffic. 283 00:11:44,920 --> 00:11:49,920 The probe comes from a specific Azure IP address 168.63, 129.16. 284 00:11:49,920 --> 00:11:52,920 If that IP isn't allowed in your NSG rules, the probe can't reach your server. 285 00:11:52,920 --> 00:11:55,920 The server is running fine, but the load balancer thinks it's dead. 286 00:11:55,920 --> 00:11:56,920 The server is running fine, but the load balancer thinks it's dead. 287 00:11:56,920 --> 00:11:57,920 The server is running fine, but the load balancer thinks it's dead. 288 00:11:57,920 --> 00:12:01,920 The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port. 289 00:12:01,920 --> 00:12:02,920 The fix is simple, just add an inbound rule that allows traffic from that Azure IP on your probe port. 290 00:12:02,920 --> 00:12:03,920 That's it. 291 00:12:03,920 --> 00:12:04,920 Next up is the wrong probe protocol of port. 292 00:12:04,920 --> 00:12:09,920 You set up a TCP probe on port 80, but your application is actually listening on port 8080. 293 00:12:09,920 --> 00:12:14,920 The probe checks port 80, gets no response, and marks the server as unhealthy. 294 00:12:14,920 --> 00:12:15,920 The server is fine. 295 00:12:15,920 --> 00:12:17,920 The probe is just looking in the wrong place. 296 00:12:17,920 --> 00:12:20,920 Make sure your probe protocol and port match what your application is actually doing. 297 00:12:20,920 --> 00:12:23,920 If your app listens on 8080, probe port 8080. 298 00:12:23,920 --> 00:12:27,920 If your app expects an HTTP response, use an HTTP probe instead of TCP. 299 00:12:27,920 --> 00:12:31,920 As QMS match is another common one, you create a standard load balancer, 300 00:12:31,920 --> 00:12:36,920 but attach a basic public IP. They don't match, and the deployment fails or behaves unpredictably. 301 00:12:36,920 --> 00:12:38,920 The rule is simple. Keep your SKUs consistent. 302 00:12:38,920 --> 00:12:43,920 Standard with standard, basic with basic, and since basic is retired, just use standard for everything. 303 00:12:43,920 --> 00:12:46,920 Session persistence left on by mistake can cause uneven traffic distribution. 304 00:12:46,920 --> 00:12:49,920 You enable sticky sessions because you read somewhere that it's good for performance, 305 00:12:49,920 --> 00:12:51,920 but your application doesn't actually need it. 306 00:12:51,920 --> 00:12:54,920 Now one server gets hammered with traffic while the other sit idle. 307 00:12:54,920 --> 00:12:57,920 The fix is to understand your application's state requirements. 308 00:12:57,920 --> 00:13:01,920 If your app stores session state in a database or distributed cache, 309 00:13:01,920 --> 00:13:04,920 you don't need session persistence at the load balancer level. 310 00:13:04,920 --> 00:13:06,920 Only enable it when you absolutely have to. 311 00:13:06,920 --> 00:13:10,920 User defined routes or UDRs can silently break your load balancer. 312 00:13:10,920 --> 00:13:14,920 You set up a custom root table that sends traffic through a firewall or a network appliance. 313 00:13:14,920 --> 00:13:17,920 The problem is that your probe traffic also follows those routes. 314 00:13:17,920 --> 00:13:20,920 If the root sends probe packets somewhere they shouldn't go, 315 00:13:20,920 --> 00:13:23,920 the backend appears unhealthy even though the application is running perfectly. 316 00:13:23,920 --> 00:13:27,920 Always check your root tables when troubleshooting load balancer issues. 317 00:13:27,920 --> 00:13:28,920 And here's a classic one. 318 00:13:28,920 --> 00:13:31,920 Someone sets up a load balancer with a single VM in the backend pool. 319 00:13:31,920 --> 00:13:35,920 They tested traffic flows, everything looks good, then they stopped the VM to simulate a failure, 320 00:13:35,920 --> 00:13:36,920 and the app goes down. 321 00:13:36,920 --> 00:13:38,920 They think the load balancer is broken. 322 00:13:38,920 --> 00:13:42,920 It's not. A load balancer with one backend server provides zero redundancy. 323 00:13:42,920 --> 00:13:45,920 If that server goes down, there's nowhere else to send traffic. 324 00:13:45,920 --> 00:13:47,920 Always have at least two instances in your backend pool. 325 00:13:47,920 --> 00:13:50,920 That's the whole point of having a load balancer in the first place. 326 00:13:50,920 --> 00:13:54,920 So here's your troubleshooting checklist. Check the NSG rules, check the probe protocol in port, 327 00:13:54,920 --> 00:13:59,920 check the root tables, and check the application health directly from another VM in the same network. 328 00:13:59,920 --> 00:14:02,920 Nine times out of ten, the problem is in one of those four places. 329 00:14:02,920 --> 00:14:06,920 When to choose load balancer versus app gateway versus traffic manager. 330 00:14:06,920 --> 00:14:08,920 So you understand what a load balancer does. 331 00:14:08,920 --> 00:14:12,920 But as your actually gives you four different services for distributing traffic, 332 00:14:12,920 --> 00:14:15,920 and each one has a specific job as your load balancer is layer four. 333 00:14:15,920 --> 00:14:19,920 It handles any TCP or UDP protocol within a single region. 334 00:14:19,920 --> 00:14:23,920 Use it for internal services, non-HTTP workloads, or when you just need simple distribution. 335 00:14:23,920 --> 00:14:24,920 It's your foundation. 336 00:14:24,920 --> 00:14:28,920 Application gateway is layer seven HTP and HTTP only. 337 00:14:28,920 --> 00:14:34,920 Think of it like a hotel concierge who knows exactly where each guest should go based on what they're asking for. 338 00:14:34,920 --> 00:14:37,920 It can route traffic by URL path, handle SSL termination, 339 00:14:37,920 --> 00:14:40,920 and protect your web apps with a web application firewall. 340 00:14:40,920 --> 00:14:43,920 Use it when you need smart routing for web traffic. 341 00:14:43,920 --> 00:14:47,920 Traffic manager works at the DNS level. It's like a travel agent who sends you to the nearest office. 342 00:14:47,920 --> 00:14:50,920 If your users are in Europe, it routes them to your European servers. 343 00:14:50,920 --> 00:14:54,920 If your European data center goes down, it sends them to the next closest region. 344 00:14:54,920 --> 00:14:57,920 As your front door is the global version of application gateway. 345 00:14:57,920 --> 00:15:01,920 It gives you layer seven routing, acceleration, and WAF protection at the edge. 346 00:15:01,920 --> 00:15:05,920 Use it for global web applications where performance and security matter. 347 00:15:05,920 --> 00:15:07,920 Here's the practical rule of thumb. 348 00:15:07,920 --> 00:15:09,920 Use load balancer for non-HTTP traffic. 349 00:15:09,920 --> 00:15:12,920 Use application gateway for web apps in one region. 350 00:15:12,920 --> 00:15:14,920 Use front door or traffic manager for global distribution. 351 00:15:14,920 --> 00:15:20,920 Start with load balancer as your foundation and layer the other services on top as your needs grow. 352 00:15:20,920 --> 00:15:22,920 So now you have it. 353 00:15:22,920 --> 00:15:25,920 Azure load balancer is the smart reception desk for your servers. 354 00:15:25,920 --> 00:15:27,920 The front end IP is the door everyone knocks on. 355 00:15:27,920 --> 00:15:30,920 The backend pool is your team doing the work and health probes keep everyone honest. 356 00:15:30,920 --> 00:15:33,920 Next time you set up a VM in Azure, ask yourself one question. 357 00:15:33,920 --> 00:15:35,920 What happens if this one VM fails? 358 00:15:35,920 --> 00:15:37,920 If the answer is downtime, you need a load balancer. 359 00:15:37,920 --> 00:15:41,920 Start with a standard load balancer in front of at least two VMs. 360 00:15:41,920 --> 00:15:42,920 Add health probes. 361 00:15:42,920 --> 00:15:45,920 Test by stopping one VM and watch the traffic keep flowing. 362 00:15:45,920 --> 00:15:47,920 That's all for this episode of Microsoft Knowledge Nuggets. 363 00:15:47,920 --> 00:15:51,920 Subscribe on your favorite podcast platform and share this with someone starting their journey. 364 00:15:51,920 --> 00:15:53,920 Next time we'll cover application gateway. 365 00:15:53,920 --> 00:15:54,920 Simply explained.