WEBVTT

1
00:00.000 --> 00:03.200
So now that we have our virtual service set up here with

2
00:03.200 --> 00:06.760
the virtual IP address of 10, 1, 0, 1, 0, 5,

3
00:06.760 --> 00:10.240
and I have these three servers on the back end that are up and

4
00:10.240 --> 00:11.840
ready to go on that segment,

5
00:11.840 --> 00:16.440
we could test this by having a client connect to the virtual IP address of 10.1

6
00:16.440 --> 00:17.680
, 0, 1.0,

7
00:17.680 --> 00:20.560
0.5, which is associated with our virtual service,

8
00:20.560 --> 00:25.120
and then the service engine should go ahead and be able to proxy those requests

9
00:25.120 --> 00:26.520
down to one of the available servers.

10
00:26.520 --> 00:29.960
So before we ask you to test, let's head over to the controller.

11
00:29.960 --> 00:34.600
Just to confirm that those three back end servers in the pool are reachable and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.960 --> 00:34.600
Just to confirm that those three back end servers in the pool are reachable and

12
00:34.600 --> 00:36.040
appear as available.

13
00:36.040 --> 00:39.520
So back here at the controller interface for the load balancer,

14
00:39.520 --> 00:43.270
the top left tab of applications is selected and the dashboard is selected by

15
00:43.270 --> 00:43.680
default,

16
00:43.680 --> 00:45.520
and here is showing us our web app.

17
00:45.520 --> 00:50.080
Now the yellow is better than all red, so that means that our health score is

18
00:50.080 --> 00:50.600
68.

19
00:50.600 --> 00:54.430
And so those points off, for example, if my web servers have been up for a long

20
00:54.430 --> 00:54.640
time,

21
00:54.640 --> 00:57.680
in fact, this is showing the health score for the past six hours.

22
00:57.680 --> 01:01.470
And as they continue to be up and available or time, that health score will
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
00:57.680 --> 01:01.470
And as they continue to be up and available or time, that health score will

23
01:01.470 --> 01:02.040
improve.

24
01:02.040 --> 01:05.240
So we can either click right here on this virtual service,

25
01:05.240 --> 01:07.850
and that would take us to the details of it, or we could click care in the

26
01:07.850 --> 01:08.760
virtual services,

27
01:08.760 --> 01:11.240
and it would list it, and then we could click on it here.

28
01:11.240 --> 01:13.960
So let me move this little mini topology out of the way.

29
01:13.960 --> 01:16.680
And let me remove a couple of columns so we can see it better.

30
01:16.680 --> 01:18.080
I'll click on the gear here.

31
01:18.080 --> 01:20.440
So let me remove a few of those and click on save.

32
01:20.440 --> 01:23.350
And for a little more room, I'm going to go ahead and push the left-hand column

33
01:23.350 --> 01:23.800
over.

34
01:23.800 --> 01:27.220
So for this service, which is went up a little bit because those servers are

35
01:27.220 --> 01:27.680
now up,

36
01:27.680 --> 01:29.480
it has a health score of 71.

37
01:29.480 --> 01:32.200
It's supporting a service port of 80 and check this out.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:29.480 --> 01:32.200
It's supporting a service port of 80 and check this out.

38
01:32.200 --> 01:33.240
Total service engines.

39
01:33.240 --> 01:37.240
It has one service engine at the moment that's supporting that and doing the

40
01:37.240 --> 01:38.440
actual data plan work.

41
01:38.440 --> 01:41.820
So if we were to expand the left-hand side here, and if we went back to

42
01:41.820 --> 01:42.720
infrastructure,

43
01:42.720 --> 01:44.640
then the left here is our cloud.

44
01:44.640 --> 01:48.290
And on the left below that, if we go to cloud resources and click on service

45
01:48.290 --> 01:48.840
engine,

46
01:48.840 --> 01:52.760
here's showing us all of our service engines, and that's for the default cloud.

47
01:52.760 --> 01:53.760
So we use the dropdown.

48
01:53.760 --> 01:55.640
Here's our NSX cloud.

49
01:55.640 --> 01:58.200
And currently we have two service engines.

50
01:58.200 --> 02:02.320
One of those is being used to support the load balancing for those servers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
01:58.200 --> 02:02.320
One of those is being used to support the load balancing for those servers.

51
02:02.320 --> 02:06.280
And the default method it uses for calculating how many actual service engines

52
02:06.280 --> 02:09.240
to use is called N plus M.

53
02:09.240 --> 02:11.840
So if each of these columns represents a service engine.

54
02:11.840 --> 02:16.480
So each service engine can support one or more virtual services.

55
02:16.480 --> 02:19.680
So let's imagine we configured our services engine so they can support one, two

56
02:19.680 --> 02:22.360
, three, four, five virtual services

57
02:22.360 --> 02:23.680
per service engine.

58
02:23.680 --> 02:28.260
And furthermore, let's imagine that we had 15 virtual services configured and

59
02:28.260 --> 02:28.960
running.

60
02:28.960 --> 02:32.320
Also, if you notice in the background, our health score continues to improve.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:28.960 --> 02:32.320
Also, if you notice in the background, our health score continues to improve.

61
02:32.320 --> 02:34.520
The longer those backend servers are up.

62
02:34.520 --> 02:38.370
So if we have 15 virtual services that are set up, the calculation that the

63
02:38.370 --> 02:39.360
load balancer does

64
02:39.360 --> 02:43.080
is 15 divided by how many could be supported by a single SE.

65
02:43.080 --> 02:47.880
So if each of our SEs can support five virtual services, that equals three,

66
02:47.880 --> 02:51.610
which is the end part of the equation, and then for fault tolerance, we want to

67
02:51.610 --> 02:52.240
add one more.

68
02:52.240 --> 02:53.800
That's the M part of the equation.

69
02:53.800 --> 02:57.760
So for the controller to calculate how many SEs are needed, the formula would

70
02:57.760 --> 02:59.960
be for 15 virtual services

71
02:59.960 --> 03:02.200
or each service engine can support five of those.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
02:59.960 --> 03:02.200
or each service engine can support five of those.

72
03:02.200 --> 03:05.600
We'd need a total of four service engines to be deployed.

73
03:05.600 --> 03:07.320
So let's go ahead and do 15.

74
03:07.320 --> 03:14.700
There's one, two, three, four, five, six, seven, eight, nine, 10, 11, 12, 13,

75
03:14.700 --> 03:16.000
14, 15.

76
03:16.000 --> 03:20.760
And again, this calculation of four here is the number of virtual services

77
03:20.760 --> 03:24.610
divided by how many virtual services each service engine will support plus one

78
03:24.610 --> 03:25.160
more.

79
03:25.160 --> 03:29.240
So with this formula, the load balancer would deploy four service engines

80
03:29.240 --> 03:31.360
because that gives us fault tolerance.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:29.240 --> 03:31.360
because that gives us fault tolerance.

81
03:31.360 --> 03:34.680
Because if we lost one of our virtual machines, one of our service engines,

82
03:34.680 --> 03:38.560
and it was supporting four of the virtual services, those virtual services

83
03:38.560 --> 03:39.760
could then be deployed here.

84
03:39.760 --> 03:43.000
There's one, two, three, and four.

85
03:43.000 --> 03:46.560
And one cool thing about the controller is that it will automatically deploy

86
03:46.560 --> 03:48.040
additional SEs

87
03:48.040 --> 03:52.800
to support the load and using the N plus M option is going to deploy enough.

88
03:52.800 --> 03:56.280
So if it loses a single service engine, it can still have fault tolerance

89
03:56.280 --> 03:59.680
when it moves those virtual services over to other service engines.

90
03:59.680 --> 04:03.920
And if this service engine really did go down, it then also start the process
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
03:59.680 --> 04:03.920
And if this service engine really did go down, it then also start the process

91
04:03.920 --> 04:06.280
of bringing up another service engine.

92
04:06.280 --> 04:08.240
So once again, we'd have fault tolerance.

93
04:08.240 --> 04:10.880
And again, our score is getting better and better here.

94
04:10.880 --> 04:14.720
So if we go back to applications and virtual services

95
04:14.720 --> 04:17.360
and we click on our virtual service here, as the service engine

96
04:17.360 --> 04:21.080
starts to begin doing load balancing and forwarding traffic on the data plane,

97
04:21.080 --> 04:22.160
that'll show up right here.

98
04:22.160 --> 04:25.440
So also we can hover over this virtual service right here.

99
04:25.440 --> 04:30.200
And it'll show us in the pop up exactly who the current service engine is.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
04:25.440 --> 04:30.200
And it'll show us in the pop up exactly who the current service engine is.

100
04:30.200 --> 04:36.600
Right here, showing us it's the our NSX lab, AVI, SE, IZ, V, S, G.

101
04:36.600 --> 04:39.970
That's the primary service engine that's currently supporting this virtual

102
04:39.970 --> 04:40.600
service.

103
04:40.600 --> 04:42.040
Here's the service port.

104
04:42.040 --> 04:45.200
Here's the virtual IP address associated with this virtual service.

105
04:45.200 --> 04:48.360
Also right here, if we wanted to go ahead and scale out effectively,

106
04:48.360 --> 04:51.520
use additional service engines to support this virtual service,

107
04:51.520 --> 04:53.480
we can click scale out right here.

108
04:53.480 --> 04:56.640
And then if you have multiple virtual IP addresses associated with the service,

109
04:56.640 --> 04:58.800
you choose the one you want to scale out for.

110
04:58.800 --> 05:00.600
And then you can specify where you want to scale out to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

110
04:58.800 --> 05:00.600
And then you can specify where you want to scale out to.

111
05:00.600 --> 05:02.960
So that's our other service engine.

112
05:02.960 --> 05:03.760
Or we could say, you know what?

113
05:03.760 --> 05:06.400
I want to create a whole new service engine.

114
05:06.400 --> 05:08.920
So here, if we check that box and said create service engine

115
05:08.920 --> 05:13.400
and click on scale out a way it goes, the controller is in the process

116
05:13.400 --> 05:17.600
of deploying a brand new service engine because we asked it to.

117
05:17.600 --> 05:21.440
So if we go back to the vSphere client and look at running tasks,

118
05:21.440 --> 05:24.920
here's in the process of deploying yet another service engine.

119
05:24.920 --> 05:28.480
And it'll put in that same folder, AVI, SE folder right there.

120
05:28.480 --> 05:30.800
So if we want to take a peek, we can open that up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:28.480 --> 05:30.800
So if we want to take a peek, we can open that up.

121
05:30.800 --> 05:35.440
And sure enough, there's our third SE being deployed right there.

122
05:35.440 --> 05:38.280
All right, before we send some traffic through,

123
05:38.280 --> 05:40.200
let's go ahead and edit this virtual service.

124
05:40.200 --> 05:42.560
So I'm clicking on the pencil for the virtual service.

125
05:42.560 --> 05:45.200
And then here we have some sub tabs for analytics.

126
05:45.200 --> 05:48.240
I want to go ahead and log all headers for the lab.

127
05:48.240 --> 05:51.680
And also I want to do logging for non-significant logs.

128
05:51.680 --> 05:53.080
And for the zero here for the duration,

129
05:53.080 --> 05:56.160
it means it's going to do logging indefinitely

130
05:56.160 --> 05:57.800
regarding non-significant logs.

131
05:57.800 --> 06:00.160
So that's a lot of detail that we can tear into.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
05:57.800 --> 06:00.160
So that's a lot of detail that we can tear into.

132
06:00.160 --> 06:01.760
So initially, if you're setting something up

133
06:01.760 --> 06:03.480
or need to look at the details,

134
06:03.480 --> 06:06.360
you can turn logging all the way up to get more information.

135
06:06.360 --> 06:09.760
So with those logs enabled, let me go ahead and click on save.

136
06:09.760 --> 06:13.880
And then I'll go ahead and say, please display for the past 30 minutes.

137
06:13.880 --> 06:16.880
So let's generate some traffic that's going to go through the load balancer.

138
06:16.880 --> 06:20.360
So my management computer is over here at .151 on the management network.

139
06:20.360 --> 06:22.920
And I have a specific static route that says,

140
06:22.920 --> 06:26.360
hey, dear Mr. Management Computer, if you need to get to 10 anything,

141
06:26.360 --> 06:30.920
go ahead and use this interface right here on the tier one right gateway,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:26.360 --> 06:30.920
go ahead and use this interface right here on the tier one right gateway,

142
06:30.920 --> 06:34.480
which would then route it over to the T0 down the T1 left,

143
06:34.480 --> 06:37.080
and down here to where our virtual address is.

144
06:37.080 --> 06:41.520
So the address that we're going to hit is 10.101.0.5.

145
06:41.520 --> 06:45.320
That's the virtual IP address being supported by the virtual service.

146
06:45.320 --> 06:48.240
And then on the back end, we have three servers that are available.

147
06:48.240 --> 06:50.960
And once we start sending some traffic through, if we go to logs,

148
06:50.960 --> 06:53.280
we'll have a little bit more to look at right here.

149
06:53.280 --> 06:56.840
So currently it says no logs available for this time frame and filters.

150
06:56.840 --> 06:59.000
And currently I'm looking at the last 15 minutes.

151
06:59.000 --> 07:00.360
So let's generate some traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
06:59.000 --> 07:00.360
So let's generate some traffic.

152
07:00.360 --> 07:02.000
So what's happening is for my client,

153
07:02.000 --> 07:07.120
I'm actually going to the IP address 10.101.0.5.

154
07:07.120 --> 07:09.040
And then we have the load balancer right there,

155
07:09.040 --> 07:11.360
who is then forwarding off to one of our three servers.

156
07:11.360 --> 07:13.760
So at the moment, it's taking over 2.53.

157
07:13.760 --> 07:17.440
So I intentionally made the web page a little bit different on each of the

158
07:17.440 --> 07:18.240
servers,

159
07:18.240 --> 07:20.920
just so it shows visually which server we're connected to.

160
07:20.920 --> 07:23.240
So if I do a control shift R a few times,

161
07:23.240 --> 07:27.280
it should take us eventually to one of the other servers.

162
07:27.280 --> 07:30.040
So now we're at .52 and you're going to do,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

162
07:27.280 --> 07:30.040
So now we're at .52 and you're going to do,

163
07:30.040 --> 07:33.200
let me go ahead and change the policy and have it round Robin.

164
07:33.200 --> 07:34.880
And that way we can go around the horn.

165
07:34.880 --> 07:36.360
So here for our virtual service,

166
07:36.360 --> 07:40.040
although I didn't select it and we'll edit and we'll scroll down.

167
07:40.040 --> 07:41.360
So here's the name of the service.

168
07:41.360 --> 07:43.280
Here's our virtual IP information.

169
07:43.280 --> 07:45.400
If we scroll down, we could go down to the pool.

170
07:45.400 --> 07:47.680
Here's our web app pool.

171
07:47.680 --> 07:49.080
And let me go ahead and edit that.

172
07:49.080 --> 07:51.800
And I'm going to change the default policy for how it's making a choice.

173
07:51.800 --> 07:55.040
So here for the pool, if we click on servers,

174
07:55.040 --> 07:58.000
here it's showing us the servers, if we get a health monitor.

175
07:58.000 --> 08:01.590
So here for the health monitor, if we didn't want to do a system HTTP health
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

175
07:58.000 --> 08:01.590
So here for the health monitor, if we didn't want to do a system HTTP health

176
08:01.590 --> 08:02.040
check,

177
08:02.040 --> 08:03.280
we have some others we could choose from,

178
08:03.280 --> 08:04.720
including just doing a ping.

179
08:04.720 --> 08:07.880
And that way we wouldn't be validating whether or not HTTP was running.

180
08:07.880 --> 08:09.400
So I'll leave that in place.

181
08:09.400 --> 08:13.110
But what I do want to change is how we're choosing which server we're being

182
08:13.110 --> 08:14.000
spun off to.

183
08:14.000 --> 08:17.640
So that is right here, the load balance algorithm.

184
08:17.640 --> 08:20.920
So let me change that instead of saying lease connections,

185
08:20.920 --> 08:24.240
then I go ahead and choose round Robin.

186
08:24.240 --> 08:26.920
So what that should do every time we do a forced refresh,

187
08:26.920 --> 08:29.480
that should send us off to get a different server.

188
08:29.480 --> 08:33.800
And that way we can verify we're going to all three as a property of our pool
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

188
08:29.480 --> 08:33.800
And that way we can verify we're going to all three as a property of our pool

189
08:33.800 --> 08:34.880
of three servers.

190
08:34.880 --> 08:38.960
So we'll click on save, click on save again, and let's go back to my browser.

191
08:38.960 --> 08:42.600
So here at the browser, we're currently at server dot 52.

192
08:42.600 --> 08:43.880
And then you go ahead and do a refresh.

193
08:43.880 --> 08:46.480
So then we're at dot 53, I'll do a control shift R.

194
08:46.480 --> 08:49.720
So I'm going to do a control shift R and just keep doing that.

195
08:49.720 --> 08:53.400
And sure enough, the cycling is through round Robin through all three servers.

196
08:53.400 --> 08:56.320
And if we were to take one of the servers out of the mix,

197
08:56.320 --> 09:00.040
for example, this is the little web server at dot 53.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

197
08:56.320 --> 09:00.040
for example, this is the little web server at dot 53.

198
09:00.040 --> 09:03.900
So if I just turned off the web service here and I'll do that with a quick

199
09:03.900 --> 09:05.080
click right there.

200
09:05.080 --> 09:08.600
So in the background, because the health monitor is actually checking for HTTP

201
09:08.600 --> 09:09.560
services,

202
09:09.560 --> 09:13.720
after just a very short period of time, the load balancer, the service engine,

203
09:13.720 --> 09:16.640
should realize, hey, dot 53 is no longer available.

204
09:16.640 --> 09:20.920
And that way we just round Robin for the remaining two, which should be dot 51

205
09:20.920 --> 09:21.920
and dot 52.

206
09:21.920 --> 09:23.680
So they move that out of the way.

207
09:23.680 --> 09:28.520
Let's go back to my browser, let me do a control shift R and let me just cycle

208
09:28.520 --> 09:29.600
through what's left.

209
09:29.600 --> 09:31.800
So there's 51 fantastic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

209
09:29.600 --> 09:31.800
So there's 51 fantastic.

210
09:31.800 --> 09:33.280
And there's 52.

211
09:33.280 --> 09:36.040
And as we continue cycling, there's 51 again.

212
09:36.040 --> 09:37.560
And there's 52.

213
09:37.560 --> 09:40.800
And it's not even trying 53 anymore because that has failed to health check.

214
09:40.800 --> 09:45.150
And as a result, the service engine is no longer proxying down to that third

215
09:45.150 --> 09:45.560
server

216
09:45.560 --> 09:50.200
because that server is not passing the HTTP based health check that it's doing

217
09:50.200 --> 09:51.880
periodically with that server.

218
09:51.880 --> 09:55.910
So now if we go to applications and virtual services, notice now we have two

219
09:55.910 --> 09:56.760
services engines

220
09:56.760 --> 09:59.040
that are supporting our virtual service.

221
09:59.040 --> 10:00.880
And that's because we told it to.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
09:59.040 --> 10:00.880
And that's because we told it to.

222
10:00.880 --> 10:04.240
And if we click on this virtual service here, it's showing us some end to end

223
10:04.240 --> 10:05.240
timing by default.

224
10:05.240 --> 10:07.360
But the real magic is in the logs.

225
10:07.360 --> 10:11.280
So here with logs like that, and I opted in earlier to see the updated version

226
10:11.280 --> 10:12.520
of how they're presenting logs.

227
10:12.520 --> 10:16.320
I'm going to say I want to see the non-significant as well as the significant

228
10:16.320 --> 10:16.680
logs.

229
10:16.680 --> 10:18.520
And then here are all the entries.

230
10:18.520 --> 10:19.480
So let's go ahead and grab one of these.

231
10:19.480 --> 10:21.240
I'm going to collapse the right hand column.

232
10:21.240 --> 10:24.840
And let me go ahead and click on the eyeball next to this one right here.

233
10:24.840 --> 10:28.350
So here in the summary, if we just scroll down, it'll take us to the

234
10:28.350 --> 10:30.240
application and headers respectively.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

234
10:28.350 --> 10:30.240
application and headers respectively.

235
10:30.240 --> 10:32.360
So here it's showing us who the client was.

236
10:32.360 --> 10:33.920
The client was .151.

237
10:33.920 --> 10:35.080
That's my management computer.

238
10:35.080 --> 10:39.660
According to this virtual IP address, then the service engine did the proxying

239
10:39.660 --> 10:40.880
from its IP address

240
10:40.880 --> 10:41.880
over to the web server.

241
10:41.880 --> 10:43.600
In this case, use .51.

242
10:43.600 --> 10:47.080
And this is the specific service engine that did the work.

243
10:47.080 --> 10:50.730
And it also has the latency for the round trip time between the client and the

244
10:50.730 --> 10:51.200
load balance.

245
10:51.200 --> 10:53.760
So here's the answer between the load balancer and the server.

246
10:53.760 --> 10:54.760
And then we scroll down.

247
10:54.760 --> 10:56.680
It'll take us to the application and headers.

248
10:56.680 --> 10:59.960
It has a summary, including where the client came from.

249
10:59.960 --> 11:01.560
So as running Windows, that's true.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

249
10:59.960 --> 11:01.560
So as running Windows, that's true.

250
11:01.560 --> 11:02.720
I was using Chrome.

251
11:02.720 --> 11:03.720
That's true.

252
11:03.720 --> 11:05.400
Here's the user agent involved.

253
11:05.400 --> 11:08.120
And if I scroll down, here's the application information.

254
11:08.120 --> 11:09.960
It was a get request.

255
11:09.960 --> 11:10.960
We'll scroll down.

256
11:10.960 --> 11:11.960
Here's the header information.

257
11:11.960 --> 11:15.640
This is the header as it came in from the client to the load balancer.

258
11:15.640 --> 11:18.840
And this is from the load balancer over to the server.

259
11:18.840 --> 11:21.600
And as we continue to scroll down, here's the response.

260
11:21.600 --> 11:23.400
This came back from the server to the load balancer.

261
11:23.400 --> 11:26.120
And then from the load balancer back to the client.

262
11:26.120 --> 11:27.640
So we'll go ahead and close that.

263
11:27.640 --> 11:30.290
And for this virtual service, if we click here on help, it'll give us details
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

263
11:27.640 --> 11:30.290
And for this virtual service, if we click here on help, it'll give us details

264
11:30.290 --> 11:30.600
about

265
11:30.600 --> 11:32.680
its help score and why it got that.

266
11:32.680 --> 11:35.230
It can give us information based on the source of where those clients were

267
11:35.230 --> 11:36.200
coming in from.

268
11:36.200 --> 11:40.560
There's a tab for security and events and alerts.

269
11:40.560 --> 11:43.430
So if we click here on pools, that can also give us an indicator regarding how

270
11:43.430 --> 11:44.080
many servers

271
11:44.080 --> 11:45.080
are available.

272
11:45.080 --> 11:48.680
So this is showing two out of three on the back end are available.

273
11:48.680 --> 11:51.960
So if we were to bring back in the third web server, which I turned off here a

274
11:51.960 --> 11:53.160
moment ago,

275
11:53.160 --> 11:54.560
and I turned it back on.

276
11:54.560 --> 11:58.440
So now the web service is running the health check, which is verifying whether

277
11:58.440 --> 11:59.240
HTTP services

278
11:59.240 --> 12:01.240
are running or not on the system.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

278
11:59.240 --> 12:01.240
are running or not on the system.

279
12:01.240 --> 12:03.840
That health check should come back with two thumbs up saying, you know what,

280
12:03.840 --> 12:04.280
this server

281
12:04.280 --> 12:05.480
is back up and running.

282
12:05.480 --> 12:09.590
And this number, which it just did, should change back to three out of three

283
12:09.590 --> 12:10.000
now being

284
12:10.000 --> 12:11.000
available.

285
12:11.000 --> 12:15.000
So if we went back to the browser and now we did a control shift R a few times.

286
12:15.000 --> 12:19.480
Now it's including dot 53 in that mix because we set it up for round Robin.

287
12:19.480 --> 12:24.120
So there's 52 with a control shift R, there's 51 and there is 53.

288
12:24.120 --> 12:27.160
Also when you're working with a load balancer and you're testing it, just be

289
12:27.160 --> 12:27.760
critically

290
12:27.760 --> 12:32.160
aware that there's a lot of caching that can happen locally at the browser.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

290
12:27.760 --> 12:32.160
aware that there's a lot of caching that can happen locally at the browser.

291
12:32.160 --> 12:35.670
So one technique that you could also use is to use curl right here from the

292
12:35.670 --> 12:36.480
command line.

293
12:36.480 --> 12:41.420
So we could go ahead to the virtual IP address 10, 101, 0.5 press enter and we

294
12:41.420 --> 12:42.120
're going to

295
12:42.120 --> 12:45.840
get a response and although this test doesn't tell us exactly which back end

296
12:45.840 --> 12:46.560
server we're

297
12:46.560 --> 12:51.040
going to, it does verify that we're getting a response from one of the servers.

298
12:51.040 --> 12:53.440
So as a quick wrap up here in the controller, if we go back now to

299
12:53.440 --> 12:54.480
infrastructure here on

300
12:54.480 --> 12:57.640
the dashboard is showing us three service engines that are currently out there

301
12:57.640 --> 12:57.960
because

302
12:57.960 --> 13:01.120
it deployed to automatically and then we told to bring up another one.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

302
12:57.960 --> 13:01.120
it deployed to automatically and then we told to bring up another one.

303
13:01.120 --> 13:04.420
And as long as everything's working, including the servers on the back end are

304
13:04.420 --> 13:05.000
available,

305
13:05.000 --> 13:07.760
these health scores should continue to improve.

306
13:07.760 --> 13:11.930
So if we opened up cloud resources here and clicked on service engine and then

307
13:11.930 --> 13:12.520
we picked

308
13:12.520 --> 13:15.200
our cloud, which is our NSX cloud right here.

309
13:15.200 --> 13:17.600
There's our three service engines and then we want to see more details

310
13:17.600 --> 13:18.240
regarding that

311
13:18.240 --> 13:19.240
service engine.

312
13:19.240 --> 13:21.870
We could go ahead and simply click on its name right here and then regarding

313
13:21.870 --> 13:22.480
that specific

314
13:22.480 --> 13:26.840
service engine, we have a whole bunch of tabs, including help and BDP peering

315
13:26.840 --> 13:27.640
and events

316
13:27.640 --> 13:30.840
and alerts and an option for traffic capture.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

316
13:27.640 --> 13:30.840
and alerts and an option for traffic capture.

317
13:30.840 --> 13:34.320
And if we went back to applications and clicked on virtual services and then

318
13:34.320 --> 13:34.840
selected our

319
13:34.840 --> 13:35.840
virtual service.

320
13:35.840 --> 13:39.660
Again, tons of great detail here regarding how that virtual service is doing,

321
13:39.660 --> 13:39.920
including

322
13:39.920 --> 13:42.520
options for the log health clients, et cetera.

323
13:42.520 --> 13:45.240
And then regarding this graph right here, if you want to see details for

324
13:45.240 --> 13:45.600
throughput,

325
13:45.600 --> 13:48.700
you simply click there, it'll highlight that for us and in timing, it'll

326
13:48.700 --> 13:49.360
highlight that

327
13:49.360 --> 13:51.160
for us to give us that information.