WEBVTT

0:00:02.540000 --> 0:00:07.580000
 In this video, we're going to talk
 about Azure Load Balancing.

0:00:07.580000 --> 0:00:11.880000
 The topics that we're going to cover,
 we're going to talk about what Azure

0:00:11.880000 --> 0:00:14.040000
 Load Balancer is, what it does.

0:00:14.040000 --> 0:00:20.020000
 We will also look at the elements of
 Azure Load Balancer, and then I'm

0:00:20.020000 --> 0:00:24.600000
 going to provision and configure
 and test an Azure Load Balancer.

0:00:24.600000 --> 0:00:29.700000
 So let's go ahead and let's jump right
 into this, talking about what Azure

0:00:29.700000 --> 0:00:32.140000
 Load Balancer is.

0:00:32.140000 --> 0:00:36.100000
 Load Balancing hopefully is a concept
 that's pretty straightforward, right?

0:00:36.100000 --> 0:00:42.700000
 I've got multiple back-end providers,
 VMs, carrying the workload.

0:00:42.700000 --> 0:00:45.200000
 I've got some load balancing
 tool in front of that.

0:00:45.200000 --> 0:00:47.320000
 Now there are many load
 balancers out there.

0:00:47.320000 --> 0:00:51.080000
 There are actually other load balancers
 from other vendors available in

0:00:51.080000 --> 0:00:52.440000
 the Azure platform.

0:00:52.440000 --> 0:00:57.380000
 The advantage of the Azure Load Balancer
 is that it is effectively kind

0:00:57.380000 --> 0:00:58.580000
 of platform as a service.

0:00:58.580000 --> 0:01:03.920000
 It's infrastructure, but you're not
 managing the virtual machine that's

0:01:03.920000 --> 0:01:07.360000
 running it. You're just setting
 it up as a service.

0:01:07.360000 --> 0:01:09.440000
 It's fairly simple.

0:01:09.440000 --> 0:01:14.660000
 I will tell you out of the gate that it
 only has one load balancing algorithm,

0:01:14.660000 --> 0:01:18.020000
 and that is a round
 robin algorithm.

0:01:18.020000 --> 0:01:21.080000
 Let's go ahead and dive in just in
 case you're not fully familiar with

0:01:21.080000 --> 0:01:22.480000
 the idea of a load balancer.

0:01:22.480000 --> 0:01:25.340000
 Start out with the idea and then
 jump into the components.

0:01:25.340000 --> 0:01:30.040000
 So here's the basic idea
 of a load balancer.

0:01:30.040000 --> 0:01:32.360000
 I've got a workload.

0:01:32.360000 --> 0:01:37.580000
 And let's say that workload just for
 simplicity is some kind of web app

0:01:37.580000 --> 0:01:42.880000
 running on a VM.

0:01:42.880000 --> 0:01:48.680000
 Now with one instance of that, if that
 instance fails, it of course goes

0:01:48.680000 --> 0:01:55.500000
 away, right? And I've got
 this user over here.

0:01:55.500000 --> 0:01:58.000000
 And user connects up to that.

0:01:58.000000 --> 0:01:59.900000
 That server goes down.

0:01:59.900000 --> 0:02:01.740000
 The user is no longer happy.

0:02:01.740000 --> 0:02:09.100000
 So of course, what we want is we want
 to have multiple instances of the

0:02:09.100000 --> 0:02:14.660000
 same workload, right?

0:02:14.660000 --> 0:02:17.220000
 Running on different hosts.

0:02:17.220000 --> 0:02:21.400000
 Therefore, if one goes down, the
 user can get to the other one.

0:02:21.400000 --> 0:02:27.080000
 But in order for that to be useful,
 we need some sort of component in

0:02:27.080000 --> 0:02:34.140000
 between. And that is where we
 have the Azure load balancer.

0:02:34.140000 --> 0:02:41.240000
 Now, the Azure load balancer is
 a layer four load balancer.

0:02:41.240000 --> 0:02:46.320000
 And what that means is it's going to
 balance based on protocol, but also

0:02:46.320000 --> 0:02:53.660000
 based on port. So you can have not just
 web apps as in this example, but

0:02:53.660000 --> 0:02:56.660000
 you might have custom applications
 that run on different ports.

0:02:56.660000 --> 0:03:00.180000
 And you can use an Azure
 load balancer with those.

0:03:00.180000 --> 0:03:03.680000
 The way this works of course is that
 the user, rather than connecting

0:03:03.680000 --> 0:03:09.300000
 directly to one of those back end services,
 the user connects to the load

0:03:09.300000 --> 0:03:16.900000
 balancer. And then the load balancer
 is configured with back ends of both

0:03:16.900000 --> 0:03:18.720000
 of these and both these servers.

0:03:18.720000 --> 0:03:22.960000
 And then of course, what ends up happening
 is that the requests that come

0:03:22.960000 --> 0:03:28.120000
 through are really forwarded over through
 the load balancer to one of

0:03:28.120000 --> 0:03:28.820000
 the back end hosts.

0:03:28.820000 --> 0:03:33.420000
 In this case, of course, web app response
 comes back and then goes back

0:03:33.420000 --> 0:03:34.660000
 to the user, right?

0:03:34.660000 --> 0:03:40.580000
 And that really is the basics
 of a load balancer.

0:03:40.580000 --> 0:03:45.220000
 So that we can connect up to it and
 balance our requests across multiple

0:03:45.220000 --> 0:03:49.840000
 back ends. I have two, of course, there
 can be many more back ends as

0:03:49.840000 --> 0:03:57.240000
 well. Now, in addition to being able
 to provide access to the back ends

0:03:57.240000 --> 0:04:03.480000
 through a load balance schema, the Azure
 load balancer can also provide

0:04:03.480000 --> 0:04:11.100000
 effectively a virtual interface
 for the back end.

0:04:11.100000 --> 0:04:16.540000
 So let's say, for example, this web
 app is running on a Linux host and

0:04:16.540000 --> 0:04:19.760000
 you want to be able to
 connect to it via SSH.

0:04:19.760000 --> 0:04:22.980000
 And you have to be able to come in, let's
 just say, for the sake of argument,

0:04:22.980000 --> 0:04:27.920000
 you need to come in over the internet
 to connect to that web app, right?

0:04:27.920000 --> 0:04:31.320000
 Well, what I don't necessarily want
 is I don't necessarily want a public

0:04:31.320000 --> 0:04:34.480000
 end point directly on the web app,
 although you could do that.

0:04:34.480000 --> 0:04:38.960000
 What you can do is you can set up what's
 called a NAT rule, and the NAT

0:04:38.960000 --> 0:04:41.500000
 rule can include port mapping.

0:04:41.500000 --> 0:04:45.640000
 So I create a NAT rule here,
 we'll just say NAT.

0:04:45.640000 --> 0:04:51.780000
 So that if you connect to a particular
 port, let's say I set that up as

0:04:51.780000 --> 0:05:02.700000
 50,000. And I map 50,000 to port
 22 over on a specific machine.

0:05:02.700000 --> 0:05:10.440000
 Then, whenever I connect to that point,
 I'm always going through the load

0:05:10.440000 --> 0:05:12.820000
 balancer directly to one machine.

0:05:12.820000 --> 0:05:16.160000
 So I connect to the public end point
 of the Azure load balancer in this

0:05:16.160000 --> 0:05:23.180000
 example on port 50,000, and that's going
 to map back to one specific instance,

0:05:23.180000 --> 0:05:27.680000
 and it's going to map back to a specified
 port, in this case 22, on that

0:05:27.680000 --> 0:05:31.220000
 instance. So the load balancer
 really provides two services.

0:05:31.220000 --> 0:05:36.160000
 One is a traditional round robin-based
 load balancing schema, and the

0:05:36.160000 --> 0:05:40.200000
 other is what we call NAT rules, giving
 you this really port mapping and

0:05:40.200000 --> 0:05:42.200000
 protection capability.

0:05:42.200000 --> 0:05:46.600000
 One thing off topic, but something
 interesting, and it's right now in

0:05:46.600000 --> 0:05:51.180000
 preview, if you are using a load balancer
 for that specifically to provide

0:05:51.180000 --> 0:05:55.480000
 administrative access to backends,
 you might want to take a look at a

0:05:55.480000 --> 0:05:59.480000
 new service, which is the
 Azure Bastion host.

0:05:59.480000 --> 0:06:03.380000
 Very cool, gives you a Bastion host,
 gives you actually web-based, secure

0:06:03.380000 --> 0:06:06.880000
 connectivity to either a Windows or
 a Linux server for administrative

0:06:06.880000 --> 0:06:11.180000
 purposes. But that's off topic,
 back to the story at hand.

0:06:11.180000 --> 0:06:15.300000
 So this is the basic concept
 of an Azure load balancer.

0:06:15.300000 --> 0:06:20.420000
 Let's take a look at what the actual
 components are, what are the elements

0:06:20.420000 --> 0:06:24.080000
 that make the Azure
 load balancer work.

0:06:24.080000 --> 0:06:27.700000
 And we start out, of course,
 we have a load balancer.

0:06:27.700000 --> 0:06:30.200000
 If I can get my mouse
 here, there we go.

0:06:30.200000 --> 0:06:32.440000
 All right, and so we're going to draw
 this a little differently here,

0:06:32.440000 --> 0:06:33.980000
 give myself a little more room.

0:06:33.980000 --> 0:06:36.360000
 Okay, so I've got the load balancer,
 we're going to kind of just put this

0:06:36.360000 --> 0:06:42.280000
 in the middle. All of these components
 are components of the load balancer.

0:06:42.280000 --> 0:06:45.000000
 So I'm going to kind of draw them out
 just so that they're spaced out

0:06:45.000000 --> 0:06:51.020000
 correctly, but know that you do have
 all of these are not independent.

0:06:51.020000 --> 0:06:56.320000
 The first thing that you need for load
 balancer is you need a front end

0:06:56.320000 --> 0:07:02.840000
 configuration. You can now have
 more than one of, right?

0:07:02.840000 --> 0:07:07.540000
 And the front end configuration really
 is effectively an IP address and

0:07:07.540000 --> 0:07:12.040000
 it can be either public
 or private.

0:07:12.040000 --> 0:07:20.900000
 Right? If I have a public IP address,
 then it's considered to be a public

0:07:20.900000 --> 0:07:25.480000
 load balancer. If I only have a private
 IP address, then it is considered

0:07:25.480000 --> 0:07:27.900000
 to be an internal load balancer.

0:07:27.900000 --> 0:07:31.240000
 And one thing that's pretty important
 to understand about this, there's

0:07:31.240000 --> 0:07:35.700000
 a really important differentiation between
 public and private IP as the

0:07:35.700000 --> 0:07:37.540000
 front end of the load balancer.

0:07:37.540000 --> 0:07:41.680000
 If you have a private IP address as
 the front end of the load balancer,

0:07:41.680000 --> 0:07:45.340000
 so let's say for example, you've got
 a back end service that you need

0:07:45.340000 --> 0:07:49.720000
 multiple instances of, but it's not a
 direct, if you will, consumer service.

0:07:49.720000 --> 0:07:51.860000
 It's supporting your
 web apps, right?

0:07:51.860000 --> 0:07:54.780000
 Your web apps need access to it
 and you want that load balance.

0:07:54.780000 --> 0:07:58.360000
 I could have an internal load
 balancer with a private IP.

0:07:58.360000 --> 0:08:03.620000
 If it uses a private IP address, it
 is part of a subnet and part of a

0:08:03.620000 --> 0:08:04.840000
 virtual network.

0:08:04.840000 --> 0:08:09.380000
 If it only uses a public, if I have a
 load balancer that only has a public

0:08:09.380000 --> 0:08:14.900000
 IP address, it is not considered part
 of any specific virtual network,

0:08:14.900000 --> 0:08:18.500000
 even though I'm only going to be able
 to connect it up to virtual, or

0:08:18.500000 --> 0:08:21.200000
 I may only be able to connect it up to
 virtual machines, all one specific

0:08:21.200000 --> 0:08:23.900000
 virtual network.

0:08:23.900000 --> 0:08:27.840000
 However, why that's important, you shouldn't
 say it, however, why that's

0:08:27.840000 --> 0:08:31.100000
 important is for NSG rules.

0:08:31.100000 --> 0:08:35.080000
 If I've got a private IP address, traffic
 coming through that is considered

0:08:35.080000 --> 0:08:39.160000
 to be local to the network and by default,
 through a standard network

0:08:39.160000 --> 0:08:41.900000
 security group or NSG is
 going to be allowed.

0:08:41.900000 --> 0:08:47.160000
 However, if I only have a public IP address
 on the load balancer, traffic

0:08:47.160000 --> 0:08:50.520000
 through the load balancer by default
 is not going to be allowed regardless

0:08:50.520000 --> 0:08:56.720000
 of the port. So I have to add NSG rules
 to allow that as though that traffic

0:08:56.720000 --> 0:08:58.800000
 is coming from the internet.

0:08:58.800000 --> 0:09:02.740000
 Assuming again, it's a public
 request that's coming in.

0:09:02.740000 --> 0:09:06.680000
 Now, one thing that you will notice
 with NSG is I know this is not an

0:09:06.680000 --> 0:09:09.400000
 NSG topic, but I think this is one of
 the important things to understand

0:09:09.400000 --> 0:09:11.600000
 with load balancing because probably
 the other thing is that it's not

0:09:11.600000 --> 0:09:11.600000
 going to be allowed.

0:09:11.600000 --> 0:09:14.780000
 Because it's something that threw me
 off when I was first doing this,

0:09:14.780000 --> 0:09:19.380000
 is that if you look at a standard NSG,
 it says it's got a rule that allows

0:09:19.380000 --> 0:09:20.980000
 a load balancer.

0:09:20.980000 --> 0:09:22.780000
 And when I first started,
 I thought that was cool.

0:09:22.780000 --> 0:09:25.240000
 That means that anything coming through
 the load balancer is good to go.

0:09:25.240000 --> 0:09:26.840000
 Not what it means at all.

0:09:26.840000 --> 0:09:30.320000
 The health probe that we're going to
 get to in just a moment is always

0:09:30.320000 --> 0:09:32.140000
 going to be allowed by default.

0:09:32.140000 --> 0:09:36.240000
 All right, so, and that's all that load
 balancer item is, and an NSG is

0:09:36.240000 --> 0:09:37.800000
 the health probe.

0:09:37.800000 --> 0:09:40.360000
 Speaking of which, let's break
 this down a little farther.

0:09:40.360000 --> 0:09:42.040000
 So we've got the front
 end configuration.

0:09:42.040000 --> 0:09:43.900000
 We've got the public private IP.

0:09:43.900000 --> 0:09:45.320000
 What else do we have?

0:09:45.320000 --> 0:09:56.480000
 Well, at the back end, we have
 what's called a back end pool.

0:09:56.480000 --> 0:10:06.600000
 And a back end pool is really just a set
 of destinations, typically, although

0:10:06.600000 --> 0:10:09.880000
 not exclusively, virtual machines.


0:10:09.880000 --> 0:10:14.700000
 So we're going, you know, this connection
 to the back end pool, which

0:10:14.700000 --> 0:10:20.140000
 basically says I've got connection
 to all of these.

0:10:20.140000 --> 0:10:21.740000
 That are available.

0:10:21.740000 --> 0:10:27.120000
 Now, the back end pool, in and of itself,
 I had to draw that differently

0:10:27.120000 --> 0:10:28.760000
 because that was just weird.

0:10:28.760000 --> 0:10:31.220000
 Rather have an, there we go.

0:10:31.220000 --> 0:10:34.220000
 All right, the back end pool in and
 of itself doesn't provide any load

0:10:34.220000 --> 0:10:41.520000
 balancing. In order to provide the load
 balancing, what we need is a load

0:10:41.520000 --> 0:10:53.900000
 balancing rule. There we go.

0:10:53.900000 --> 0:11:01.400000
 Okay, and the load balancing rule is
 going to connect a front end point,

0:11:01.400000 --> 0:11:06.320000
 front end IP configuration,
 to a back end pool.

0:11:06.320000 --> 0:11:09.800000
 And so it's based on
 many attributes.

0:11:09.800000 --> 0:11:13.400000
 And we'll take a look at this, but
 things like, okay, what's the port?

0:11:13.400000 --> 0:11:14.480000
 What's the incoming port?

0:11:14.480000 --> 0:11:15.740000
 What's the outgoing port?

0:11:15.740000 --> 0:11:17.200000
 What's the protocol?

0:11:17.200000 --> 0:11:21.300000
 And what's the front end IP configuration
 and back end that I'm gluing

0:11:21.300000 --> 0:11:24.540000
 together? Because that's really what
 the load balance rule does, is it

0:11:24.540000 --> 0:11:27.740000
 just kind of glues everything together
 from the front end through the

0:11:27.740000 --> 0:11:31.860000
 back end pool. However, if I have a
 load balance rule, I need one other

0:11:31.860000 --> 0:11:37.380000
 component. And that other component
 is called a health probe.

0:11:37.380000 --> 0:11:41.100000
 I'll draw that one
 in here as well.

0:11:41.100000 --> 0:11:44.060000
 I'm going to just say HP because I
 am not going to be able to type out

0:11:44.060000 --> 0:11:49.600000
 health probe. And the health probe is
 associated with a load balance rule.

0:11:49.600000 --> 0:11:52.260000
 In fact, I can have one health probe
 definition associated with multiple

0:11:52.260000 --> 0:11:53.820000
 load balance rules.

0:11:53.820000 --> 0:11:57.860000
 And the health probe does exactly
 what it sounds like.

0:11:57.860000 --> 0:12:05.160000
 It essentially reaches out and it's
 pinging whatever's on the back end

0:12:05.160000 --> 0:12:11.720000
 pool. And if, and you can set this, if
 it doesn't get appropriate response

0:12:11.720000 --> 0:12:16.180000
 within a certain number of requests,
 then a particular instance on the

0:12:16.180000 --> 0:12:20.080000
 back end is going to
 be marked as down.

0:12:20.080000 --> 0:12:25.540000
 As inaccessible until such time as it
 then will properly respond to the

0:12:25.540000 --> 0:12:29.820000
 health probes. So it's really not
 that complex of an architecture.

0:12:29.820000 --> 0:12:31.460000
 You've got the load balancer.

0:12:31.460000 --> 0:12:37.560000
 Load balancer has a front end configuration,
 has back end pool, and it

0:12:37.560000 --> 0:12:39.500000
 has a health probe.

0:12:39.500000 --> 0:12:43.360000
 And then of course the load balance
 rule to tie all of that together.

0:12:43.360000 --> 0:12:48.140000
 That's the more complex element
 of a load balancer.

0:12:48.140000 --> 0:12:53.260000
 But remember, I also said that you can
 use it for port mapping to provide

0:12:53.260000 --> 0:13:02.040000
 a essentially virtualized public interface,
 but what you can do in addition

0:13:02.040000 --> 0:13:05.600000
 to all of that is you can set up, and
 again, let's see if we should be

0:13:05.600000 --> 0:13:13.220000
 okay here. I can set up a NAT
 rule, and a little bit low.

0:13:13.220000 --> 0:13:19.520000
 And the NAT rule also associated with
 a public, well with a front end

0:13:19.520000 --> 0:13:23.680000
 configuration. The difference to the
 NAT rule is it's going to go to one

0:13:23.680000 --> 0:13:26.440000
 specific instance based
 on port mapping.

0:13:26.440000 --> 0:13:30.200000
 So incoming port and then outgoing
 port on the back end.

0:13:30.200000 --> 0:13:34.320000
 Those can be useful even internally
 if you, for example, use this with

0:13:34.320000 --> 0:13:37.140000
 a virtual machine scale set.

0:13:37.140000 --> 0:13:40.680000
 And that is something with the load
 balancer you want to know, where can

0:13:40.680000 --> 0:13:44.260000
 I use a load balancer?

0:13:44.260000 --> 0:13:49.100000
 And some of that depends on
 the tier of load balancers.

0:13:49.100000 --> 0:13:52.960000
 And what I want to do at the outset
 of the demonstration is I'm actually

0:13:52.960000 --> 0:13:55.100000
 going to bring up the load
 balancer pricing page.

0:13:55.100000 --> 0:13:58.380000
 It's a little bit weird for a demo,
 but it has some good information,

0:13:58.380000 --> 0:14:01.780000
 and there are some things you need to
 know that will go into your decision

0:14:01.780000 --> 0:14:06.180000
 on whether or not to use an Azure load
 balancer and what tier of load

0:14:06.180000 --> 0:14:07.660000
 balancer to use.

0:14:07.660000 --> 0:14:15.360000
 So with that, what I want to do is go ahead
 and pop over to our demonstration.

0:14:15.360000 --> 0:14:16.900000
 And kind of a two part
 demonstration.

0:14:16.900000 --> 0:14:21.400000
 The first part is I'm going to bring
 up the Azure pricing page for the

0:14:21.400000 --> 0:14:24.000000
 load balancer to kind of look at what
 it can do and what the different

0:14:24.000000 --> 0:14:28.100000
 tiers do. And then I'm going to go ahead
 and look at implementing an Azure

0:14:28.100000 --> 0:14:33.120000
 load balancer. All right,
 let's take a look.

0:14:33.120000 --> 0:14:35.960000
 Now I've got this set up
 for the second part.

0:14:35.960000 --> 0:14:38.140000
 We will get to that
 in just a moment.

0:14:38.140000 --> 0:14:47.020000
 But first, I'm simply going to take a
 look for Azure load balancer pricing.

0:14:47.020000 --> 0:14:51.980000
 I use a pricing page as a lot because
 they come up in my search.

0:14:51.980000 --> 0:14:56.240000
 And here's the pricing page
 for the load balancer.

0:14:56.240000 --> 0:15:05.060000
 And all I care about, not so much the
 pricing, but the differentiation

0:15:05.060000 --> 0:15:13.300000
 between the standard load balancer and
 the, oh, it doesn't even give me

0:15:13.300000 --> 0:15:17.960000
 the basic load balancer, but I can
 tell you what the differences are.

0:15:17.960000 --> 0:15:24.680000
 The standard load balancer has more
 flexible and larger back end pools.

0:15:24.680000 --> 0:15:28.360000
 That is absolutely true.

0:15:28.360000 --> 0:15:34.860000
 You can have, for example, with a basic
 load balancer, you can only balance

0:15:34.860000 --> 0:15:38.840000
 virtual machines or virtual or virtual
 machine scale sets that are in

0:15:38.840000 --> 0:15:41.820000
 a single virtual network.

0:15:41.820000 --> 0:15:45.760000
 With a standard load balancer, you
 can actually go beyond that.

0:15:45.760000 --> 0:15:47.420000
 In fact, let me take a step back.

0:15:47.420000 --> 0:15:48.280000
 Let me walk that back.

0:15:48.280000 --> 0:15:50.080000
 It's actually even more specific.

0:15:50.080000 --> 0:15:54.800000
 With a basic load balancer, you can
 only load balance virtual machines

0:15:54.800000 --> 0:15:58.420000
 that are in an availability set, not
 just the same network, but they have

0:15:58.420000 --> 0:16:02.180000
 to be in an availability set or a virtual
 machine scale set, which also

0:16:02.180000 --> 0:16:04.160000
 has an availability set.

0:16:04.160000 --> 0:16:06.100000
 With the standard, you have
 much more flexibility.

0:16:06.100000 --> 0:16:09.020000
 You can go across networks and have
 some other options as well.

0:16:09.020000 --> 0:16:13.980000
 You also have the idea of
 high availability ports.

0:16:13.980000 --> 0:16:16.500000
 In other words, that's a port where
 it's always going to go to the same

0:16:16.500000 --> 0:16:20.380000
 machine as long as it, or the same
 back end as long as it exists, but

0:16:20.380000 --> 0:16:25.040000
 you can actually have it have a secondary
 back end if the first one goes

0:16:25.040000 --> 0:16:29.540000
 down. You have cross
 zone load balancing.

0:16:29.540000 --> 0:16:33.540000
 If you have availability zones, if you're
 using availability zones, then

0:16:33.540000 --> 0:16:37.100000
 you can load balance across those with
 automatic zone redundant front

0:16:37.100000 --> 0:16:42.480000
 ends. Availability zones are a
 higher level of availability.

0:16:42.480000 --> 0:16:46.300000
 They give you a higher level of availability
 because you are spreading

0:16:46.300000 --> 0:16:49.860000
 your workload across multiple data centers
 in the same region, but multiple

0:16:49.860000 --> 0:16:52.940000
 data centers. If you're going to do
 that, you're going to want to load

0:16:52.940000 --> 0:16:56.780000
 balance it, and you're going to want
 to use a standard load balancer.

0:16:56.780000 --> 0:17:05.920000
 You also have integrated monitoring as
 part of the standard load balancer.

0:17:05.920000 --> 0:17:10.300000
 You pay for the load balancer
 by paying for rules.

0:17:10.300000 --> 0:17:15.720000
 A basic load balancer is free, but it
 is also, as the name implies, fairly

0:17:15.720000 --> 0:17:20.200000
 limited. Essentially, what you can
 use it for is simple load balancing

0:17:20.200000 --> 0:17:27.880000
 of a single availability set, whether
 it's a direct availability set,

0:17:27.880000 --> 0:17:30.800000
 or if it's implemented as part
 of virtual machine scale set.

0:17:30.800000 --> 0:17:35.240000
 The standard load balancer does cost
 some money, but it doesn't cost a

0:17:35.240000 --> 0:17:37.880000
 whole lot of money, two and
 a half cents per rule.

0:17:37.880000 --> 0:17:42.240000
 Initially, one cent per rule after the
 first five, one cent per rule per

0:17:42.240000 --> 0:17:43.860000
 hour, I should say.

0:17:43.860000 --> 0:17:48.820000
 But anyways, that is the differentiation
 with the standard load balancer,

0:17:48.820000 --> 0:17:51.080000
 and you can look up and get
 a bit more information.

0:17:51.080000 --> 0:17:56.640000
 Now, let's take a look at implementing
 a standard load balancer.

0:17:56.640000 --> 0:18:00.660000
 I'm going to jump back one more time,
 because I forgot to show this, kind

0:18:00.660000 --> 0:18:01.980000
 of a big picture.

0:18:01.980000 --> 0:18:05.580000
 This is a big picture overview
 of demonstration architecture.

0:18:05.580000 --> 0:18:11.420000
 If you've seen other demonstrations,
 this may be familiar, but what we're

0:18:11.420000 --> 0:18:15.700000
 going to do in this particular demonstration
 is we're going to focus on

0:18:15.700000 --> 0:18:17.200000
 these web servers.

0:18:17.200000 --> 0:18:21.700000
 I'm going to put a load balancer in front
 of the web servers with a public...

0:18:21.700000 --> 0:18:25.760000
 The right one there...

0:18:25.760000 --> 0:18:31.980000
 with a public IP, two load balance activity
 across those, simple as that.

0:18:31.980000 --> 0:18:40.640000
 And if we now go back, this is the
 topology view, which I love, within

0:18:40.640000 --> 0:18:44.520000
 Network Watcher, and
 again, same thing.

0:18:44.520000 --> 0:18:49.000000
 You can see over here, I've got my two
 web servers, and these are going

0:18:49.000000 --> 0:18:49.920000
 to be the two targets.

0:18:49.920000 --> 0:18:54.200000
 Now, right now, both of these web
 servers have public IP addresses.

0:18:54.200000 --> 0:18:57.140000
 And it is important, these are standard
 public IP addresses, otherwise

0:18:57.140000 --> 0:19:03.340000
 they would not be eligible for use
 in a standard load balancer.

0:19:03.340000 --> 0:19:06.120000
 They are not part of
 an availability set.

0:19:06.120000 --> 0:19:08.880000
 I actually, I thought I was, but I'm
 not even using availability zones

0:19:08.880000 --> 0:19:10.360000
 with them, but that's fine.

0:19:10.360000 --> 0:19:16.860000
 All right, let's go ahead and
 provision a load balancer.

0:19:16.860000 --> 0:19:26.440000
 This one got load balancer
 and create.

0:19:26.440000 --> 0:19:40.280000
 And we're going to put this in O1 tasks,
 and we're going to say web...

0:19:40.280000 --> 0:19:39.340000
 Load balancer...

0:19:39.340000 --> 0:19:43.460000
 Go in the East, because that's
 where I have everything.

0:19:43.460000 --> 0:19:49.620000
 Now, the type, and go internal or public,
 the skew can be basic or standard.

0:19:49.620000 --> 0:19:57.280000
 I have to choose a standard because
 I'm not in an availability set, or

0:19:57.280000 --> 0:19:59.400000
 using a... well, that's
 it right there.

0:19:59.400000 --> 0:20:04.440000
 I need a public IP address,
 which I'm going to create.

0:20:04.440000 --> 0:20:15.700000
 Pip. And just in case I'm going to
 go and make that zone redundant, I

0:20:15.700000 --> 0:20:18.640000
 am not going to use an
 IPV6 at this point.

0:20:18.640000 --> 0:20:24.480000
 I'm going to go ahead
 and review and create.

0:20:24.480000 --> 0:20:25.980000
 And then create.

0:20:25.980000 --> 0:20:28.980000
 And that'll take a few moments, and
 when it's done, we'll come back and

0:20:28.980000 --> 0:20:31.280000
 start configuring it.

0:20:31.280000 --> 0:20:42.400000
 All right, my load balancer
 is deployed.

0:20:42.400000 --> 0:20:47.480000
 I'm going to go over to the resource
 group that's got it sorted out so

0:20:47.480000 --> 0:20:53.760000
 I can find it, and there
 is my load balancer.

0:20:53.760000 --> 0:20:58.480000
 All right, not too terribly much going
 on with the load balancer right

0:20:58.480000 --> 0:21:01.900000
 now. I should have a front-end
 configuration, which I do.

0:21:01.900000 --> 0:21:06.260000
 Notice I can actually have multiple
 front-end IP configurations.

0:21:06.260000 --> 0:21:10.320000
 That's important, so I can actually
 use this for more than one thing.

0:21:10.320000 --> 0:21:12.600000
 We're going to leave
 that as is for now.

0:21:12.600000 --> 0:21:15.460000
 And I'm going to go to
 the back-end pool.

0:21:15.460000 --> 0:21:17.240000
 That's the first thing I'm going to add,
 because I already have the front

0:21:17.240000 --> 0:21:21.920000
-end pool. And I'm going to go ahead and
 add, and we're just going to call

0:21:21.920000 --> 0:21:26.420000
 this web beep, back-end pool.

0:21:26.420000 --> 0:21:35.280000
 And we're going to go and associate
 this with a virtual network, and we

0:21:35.280000 --> 0:21:40.780000
 want our web server.

0:21:40.780000 --> 0:21:51.960000
 And we want web server zero, and IP
 config one, and web server one, and

0:21:51.960000 --> 0:21:55.780000
 IP config one. And
 I'm going to add.

0:21:55.780000 --> 0:22:01.360000
 All right, and very simple, that is
 how I'm going to define a back-end

0:22:01.360000 --> 0:22:06.720000
 pool. And I'm going to wait for that
 back-end pool to finish before I

0:22:06.720000 --> 0:22:10.960000
 go on, because that is one thing a little
 interesting with the load balancer.

0:22:10.960000 --> 0:22:13.620000
 Even though it says save load balancer,
 you may be able to see that right

0:22:13.620000 --> 0:22:16.940000
 now. It's not actually done, and you
 have to wait until each process is

0:22:16.940000 --> 0:22:18.200000
 done before you do the next.

0:22:18.200000 --> 0:22:18.980000
 So we'll wait just a minute.

0:22:18.980000 --> 0:22:28.680000
 We'll come back, and next
 we'll set up the Help Pro.

0:22:28.680000 --> 0:22:34.700000
 All right, the next thing that I am
 going to do is I'm going to create

0:22:34.700000 --> 0:22:37.820000
 a health probe. The reason why I create
 a health probe next is because

0:22:37.820000 --> 0:22:41.620000
 I can't create a load balancing role
 until I have an associated health

0:22:41.620000 --> 0:22:44.420000
 probe. And that is
 easy enough to add.

0:22:44.420000 --> 0:22:48.780000
 I'm just going to click health probe
 and add, and I am going to configure

0:22:48.780000 --> 0:22:49.960000
 this. It's pretty simple.

0:22:49.960000 --> 0:22:57.980000
 We'll just say web-hp protocol
 choices TCP, HTTP, HTTPS.

0:22:57.980000 --> 0:23:05.740000
 Now, this is web, so the natural choice
 would probably be HTTP or HTTPS.

0:23:05.740000 --> 0:23:09.240000
 Now, the difference between
 TCP and the other two.

0:23:09.240000 --> 0:23:15.760000
 TCP is going to look for a TCP acknowledgment,
 so it is a lower level.

0:23:15.760000 --> 0:23:25.240000
 If I choose HTTP or HTTPS, it is going
 to look for a 200 series response

0:23:25.240000 --> 0:23:27.420000
 code. So it is a higher level.

0:23:27.420000 --> 0:23:28.700000
 We'll go ahead and go with that.

0:23:28.700000 --> 0:23:31.940000
 That's fine. You could actually
 send it to a different path.

0:23:31.940000 --> 0:23:36.180000
 If, for example, you had a page where
 maybe rather than just saying, oh,

0:23:36.180000 --> 0:23:39.800000
 yeah, okay, I can get to this, you might
 have a custom page that returns

0:23:39.800000 --> 0:23:44.900000
 a 500 level if the server is currently
 overloaded or whatever you need

0:23:44.900000 --> 0:23:47.980000
 to do there. So you do have, even though
 it's round robin, that does give

0:23:47.980000 --> 0:23:54.720000
 you the ability, particularly for HTTP
 or HTTPS, to be a little more creative.

0:23:54.720000 --> 0:23:57.880000
 So we're going to set the interval
 to five and the unhealthy threshold

0:23:57.880000 --> 0:24:02.000000
 to two, which means if you put those
 together, that at most it's going

0:24:02.000000 --> 0:24:06.520000
 to be 10 seconds, that a back end would
 be inaccessible before it would

0:24:06.520000 --> 0:24:11.280000
 be marked as no longer,
 or not good at the time.

0:24:11.280000 --> 0:24:16.200000
 So again, we're going to wait for that
 health probe to finish provisioning

0:24:16.200000 --> 0:24:25.240000
 before I go and provision
 a load balancing rule.

0:24:25.240000 --> 0:24:28.680000
 All right, I have my health probe.


0:24:28.680000 --> 0:24:32.340000
 Next, I'm going to define a load balancing
 rule, which again really just

0:24:32.340000 --> 0:24:34.620000
 ties everything together.

0:24:34.620000 --> 0:24:38.940000
 Go ahead and add a load balancing rule
 and we'll just stay consistent

0:24:38.940000 --> 0:24:42.440000
 here. LBR, load balancing rule.

0:24:42.440000 --> 0:24:43.760000
 It's going to be IPv6.

0:24:43.760000 --> 0:24:46.000000
 The front end is the only
 front end that we've got.

0:24:46.000000 --> 0:24:48.740000
 It's going to balance TCP.

0:24:48.740000 --> 0:24:53.000000
 I've got incoming port 80 back end port
 as well, which is actually pretty

0:24:53.000000 --> 0:24:56.480000
 cool. It picks up the only
 back end pull available.

0:24:56.480000 --> 0:24:59.160000
 It picks up the only health
 probe available.

0:24:59.160000 --> 0:25:03.280000
 And then I have the ability
 to set session persistence.

0:25:03.280000 --> 0:25:06.180000
 Session persistence is stickiness.


0:25:06.180000 --> 0:25:10.280000
 And there's actually three levels of
 stickiness that I can set up with

0:25:10.280000 --> 0:25:11.600000
 my load balancer.

0:25:11.600000 --> 0:25:13.320000
 The first is none.

0:25:13.320000 --> 0:25:16.780000
 And that means that requests from the
 same client are not necessarily

0:25:16.780000 --> 0:25:21.420000
 going to go to the same back end.

0:25:21.420000 --> 0:25:25.600000
 If I've got stickiness with either
 the client IP or the client IP and

0:25:25.600000 --> 0:25:30.900000
 protocol, then what that means, if I just
 use client IP, any request coming

0:25:30.900000 --> 0:25:35.320000
 to this end point from the same client
 IP is going to always go to the

0:25:35.320000 --> 0:25:40.200000
 same back end server within
 a certain session timeout.

0:25:40.200000 --> 0:25:45.480000
 If I choose the client IP and
 protocol, it's the same idea.

0:25:45.480000 --> 0:25:49.180000
 It just that it adds in
 the protocol as well.

0:25:49.180000 --> 0:25:52.680000
 Now, one thing to know about this,
 you may hear the word tuple, which

0:25:52.680000 --> 0:25:55.080000
 if nothing else is kind
 of a fun word to say.

0:25:55.080000 --> 0:26:02.200000
 These are considered tuples, which is a multi
-dimensional identifier effectively.

0:26:02.200000 --> 0:26:04.160000
 But that's what we've got.

0:26:04.160000 --> 0:26:06.920000
 And we're going to
 leave it as none.

0:26:06.920000 --> 0:26:11.260000
 Idle timeout. So that's that
 session I was talking about.

0:26:11.260000 --> 0:26:12.480000
 And then floating IP.

0:26:12.480000 --> 0:26:14.900000
 Floating IP is direct
 server return.

0:26:14.900000 --> 0:26:18.800000
 This is you would use the load balancer
 for the initial connectivity to

0:26:18.800000 --> 0:26:19.960000
 the back end server.

0:26:19.960000 --> 0:26:23.840000
 But once that is connected, then it's
 going to end up going direct to

0:26:23.840000 --> 0:26:26.040000
 that server and not through
 the load balance.

0:26:26.040000 --> 0:26:30.780000
 So that is a little bit beyond what
 we're going to cover in this video.

0:26:30.780000 --> 0:26:33.040000
 But know that it is there.

0:26:33.040000 --> 0:26:35.880000
 And now I go ahead and save that.

0:26:35.880000 --> 0:26:40.320000
 And then I wait for that
 update to finish.

0:26:40.320000 --> 0:26:48.140000
 Now I've got my load
 balancing rules.

0:26:48.140000 --> 0:26:51.720000
 So I'm load balancing port
 80 across my back ends.

0:26:51.720000 --> 0:26:56.740000
 And if I go to my overview, I
 have this public IP address.

0:26:56.740000 --> 0:27:02.660000
 I'm going to copy that because conceptually
 if I navigate to that IP address,

0:27:02.660000 --> 0:27:05.860000
 it should go through the load balancer
 to one of the back ends, which

0:27:05.860000 --> 0:27:07.580000
 is hopefully working.

0:27:07.580000 --> 0:27:13.180000
 There's my load balancer.

0:27:13.180000 --> 0:27:17.920000
 Sometimes it does take a moment
 or two while that's going.

0:27:17.920000 --> 0:27:23.840000
 Let's check my back end and make sure
 that in fact, sees both my virtual

0:27:23.840000 --> 0:27:28.140000
 machines. It does in fact see that
 both of these virtual machines are

0:27:28.140000 --> 0:27:31.020000
 running. It's good.

0:27:31.020000 --> 0:27:37.800000
 Although may take a moment or two
 for that to fully populate.

0:27:37.800000 --> 0:27:40.160000
 So we will wait for a moment.

0:27:40.160000 --> 0:27:41.520000
 It won't be much time for you.

0:27:41.520000 --> 0:27:42.440000
 But I'll wait for a moment.

0:27:42.440000 --> 0:27:58.640000
 We'll come back once this is fully
 populated throughout Azure.

0:27:58.640000 --> 0:28:04.520000
 All right. Now my web server traffic
 and I'm connecting up to you can

0:28:04.520000 --> 0:28:06.920000
 see web server one there.

0:28:06.920000 --> 0:28:09.240000
 I'll just bring that up so it's
 a little bit easier to see.

0:28:09.240000 --> 0:28:11.040000
 So I've got web server one.

0:28:11.040000 --> 0:28:14.280000
 I am connected through
 the load balancer.

0:28:14.280000 --> 0:28:18.900000
 So if I look at my overview again.


0:28:18.900000 --> 0:28:26.660000
 All right. I've got the 52, 188
 to 97, which is right here.

0:28:26.660000 --> 0:28:31.920000
 Now eventually if I were to refresh
 this quite a bit, it eventually is

0:28:31.920000 --> 0:28:34.860000
 going to come up with
 you web server one.

0:28:34.860000 --> 0:28:40.740000
 I will also tell you very important
 when running a front end against a

0:28:40.740000 --> 0:28:45.760000
 web server to make sure that you've
 actually run the web server on the

0:28:45.760000 --> 0:28:48.640000
 back ends. For some reason it
 shut down on both my machines.

0:28:48.640000 --> 0:28:52.600000
 Thus it would have taken a really long
 time for this demonstration to

0:28:52.600000 --> 0:28:53.840000
 complete. All right.

0:28:53.840000 --> 0:28:55.840000
 So eventually and I'm not going
 to make you wait for it.

0:28:55.840000 --> 0:28:59.840000
 I will ask if you want to test this
 out with a load balancer, you run

0:28:59.840000 --> 0:29:03.620000
 it for a while and you will find that
 it will in fact come up with both

0:29:03.620000 --> 0:29:06.520000
 of your back ends eventually.

0:29:06.520000 --> 0:29:10.440000
 So the round Robin by the way is not
 actually a, you know, every other

0:29:10.440000 --> 0:29:13.780000
 time. It just does it stochastically,
 which is, you know, fancy way of

0:29:13.780000 --> 0:29:19.820000
 saying statistically, that it's going
 to really, you know, distribute

0:29:19.820000 --> 0:29:22.440000
 those requests to the back end.

0:29:22.440000 --> 0:29:25.780000
 But that's what a load
 balancer does.

0:29:25.780000 --> 0:29:28.780000
 Create load balancer, set up the front
 end IP when you create the load

0:29:28.780000 --> 0:29:30.520000
 balancer or provision it.

0:29:30.520000 --> 0:29:35.320000
 Then add your back end pool, add your
 health probe or probes and add your

0:29:35.320000 --> 0:29:39.080000
 load balancing rules and then make sure
 that whatever is on the back end

0:29:39.080000 --> 0:29:39.840000
 is actually running.

0:29:39.840000 --> 0:29:42.820000
 And then you have a load
 balanced solution.