Let's now take a look at the Azure load balancing services you're expected to know about for the exam
and first of all we have as you load balancer This is the most common one this works at the transport
last I think layer four in the OS sign network reference stack it provides network level distribution
of traffic across instances of an application running in the same as a data center.
Now in contrast to load balance so we have application Gateway this works at least seven the application
layer.
It also acts as a reverse proxy service terminates in the client connection and forward and requests
to back end end points.
And finally we have traffic manage I think global scale globally distributed endpoints.
This works at the DNS level so we might have applications running in multiple regions and users coming
in from multiple locations.
That's where we would utilize traffic manager.
Now in more detail let's look at Azure load balance.
First of all.
So as I mentioned it's Layer 4.
It's important to know that there's basic and standard skews now available now the standard skews are
in preview they're not required for the exams.
You're only expected to know about the basic one but just know that's coming out and we'll certainly
update the material when that actually happens.
You have something called service monitoring as a feature this allows Azure load balancer to probe the
health of various server instances behind the load balancer when a probe fails to respond the load balancer
can stop sending new connections to the unhealthy let's say virtual machines that are behind the load
balancer we have something called automatic reconfiguration as well.
So this can reconfigure itself automatically when you scale instances up or down perhaps when you add
new web server instances as an example.
Next we have some called hash based distribution.
And this is how Azure load balancer distributes its traffic and by default it uses a five tuple hash
composed of a source IP a source port destination IP and destination port and protocol type to map traffic
to the available servers.
It also provides stickiness only within a transport session.
So this means that if a client comes back has the same session they will continue to connect to their
same say Web server behind the load balancer as well.
And finally there's internal and public options and you'll see some of the examples in a minute but
just know you can configure an internal load balancer for traffic to hit it and then disperse for internal
applications or it could be people coming over the Internet and you want expose the a public IP and
then you know once they hit that load balancer then we pass traffic to the servers behind the load balancer.
So let's look at some of those examples.
First of all look at a internal example.
And in this case we have our internal load balancer at the top there which has a private IP associated
with it that can be dynamic or static as well you can decide how how you configure that and then we
could have say to database servers behind the load balancer traffic or hit the private IP and then be
sent over to one of either dp 1 or DP 2.
Now let's look at a public example where if you look at the low balance which is in the center of the
screen traffic would come through the cloud at the top there of a TGP port 80 and then we would pass
the traffic down to one of the three available Web servers that are behind the load balance of that.
Now you're also going to get multi tier examples as well.
So in this case you might see traffic come in and hit one of the two load balances first of all traffic
from the public cloud would come in and hit that web load balancer at the top and then that would pass
the traffic down to the Web and all those virtual machines that perhaps the Web sites would then pass
traffic to another load balancer when they want to query the database.
So in this case the second load balance of that goes in front of the database servers and the web servers
just query the database server.
Now it's also possible then that people in total could just hit that database server if they wanted
to from other applications as well could be coming from the Web site.
You know it opens up a host of options for you that so let's shift our attention now to the apt Gateway
the other load balance that's available to us from Asia.
And first of all it's Layer 7 app load balancing as I mentioned before.
So just keep that in mind the whole time when we want to application load balancing we need app Gateway
when one just lay a full load balance and we can get away with just as you load balancer.
But a couple of unique features as well are important.
So cookie based session affinity you know this is a common requirement for many web applications and
this is required so that a user can maintain the same use a session on a backend server.
It also supports SSL offload to all those decryption tasks et cetera.
That web service would normally have to deal with.
They don't have to deal with that now they can offload that to app Gateway and it can take care of it
for them.
We also have end to end SSL.
So app Gateway supports end end encryption of traffic.
It does this by terminates an SSL connection at the app Gateway and then applies routing rules to all
of the traffic and then re encrypts the packet and forwards it to the appropriate back end based on
the routing rules that you've defined.
In addition one of the most popular new features that they added recently was around Web Application
Firewall and this has become a key feature you know when you enabled us it provides protection for web
applications from a lot of common web vulnerabilities and exploits you know this can include like Eskew
or injection cross site scripting things like that.
And you also have you URL based content routing.
And this allows us for direct and traffic to different back and servers based on the content that the
users actually request and you know different server can serve that content up.
Finally one very important thing is app Gateway does require its own subnet and you need to create that
subnet before you can create your app Gateway and you'll see this in the upcoming demonstration.
In addition there's a few things you need to know around app gateway.
Size as you know in the following table this shows you an average performance throughput for each application
Gateway instance and this is shown with SSL offload enabled.
And Microsoft does make a caveat on their web for this you know these values are approximate values
for an application Gateway throughput the actual throughput depends on various environment details such
as your page size the location of the backend instances in the processing time to serve up a page.
So just keep that in mind as well.
Finally if we just take a look at a comparison overall you know we covered Azure load balance so we've
come at app Gateway and we've covered traffic managers just very briefly there.
So just think at the top level technology you know what am I trying to do so if I need layer for as
a load balancer if I need layer 7 app Gateway and if it's something more geographically dispersed think
DNS level think I think traffic manager in that context as far as endpoint monitoring and it's worth
noting at the bottom you know it's all supported via probes for Azure load balance and application gateway
but traffic manages supported by TTP and H TTP s get requests as far as endpoints go that's the other
different feature that Azure load balancer supports Azure VM arms and cloud services roll instances
application Gateway supports any Azure internal IP address public Internet IP address as a VM or Azure
cloud service and traffic manager supports Azure v VMS cloud services again as your web apps and external
endpoints as well.
So that's just a brief summary there of all the different load balancing technologies for you but that's
it for this tutorial section I encourage you to check out the subsequent demos.