Azure Load Balancer — Simply Explained

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.