Shulou(Shulou.com)06/02 Report--

In the past, when we created highly available Web applications, load balancers were an essential component. We all use the load balancer of traditional internal servers, where our application runs on N instances, with the load balancer in front of these servers, and distributes the load to the back-end servers according to some predefined algorithms and settings.

To move to the cloud, we need to understand how to use Azure components to achieve the same load balancing. Load balancing in cloud applications requires more consideration, that is, there is a simple load balancer in front of some servers, just as we can host services on PaaS, we can run services on different instances for different tenants, or applications can run on multiple servers distributed around the world.

For this reason, there are several components in Azure that can be used for load balancing. Each of these components has a different purpose, and we need to choose the right component for the solution to achieve the best application architecture.

Azure load balancing solution

There are three main load balancing components in Azure.

L Azure load balancer

L Azure Application Gateway

L Azure Traffic Manager

Let's look at each component one by one and try to understand when to use each component effectively.

Azure load balancer

Azure load balancer is a classic load balancer because it can be used to balance the load of VM, just as we use traditional load balancers with our on-premises servers. Now, because the Azure load balancer is designed for cloud applications, it can also be used to balance load with containers and PaaS applications as well as VM.

But this is similar to traditional load balancers in that Azure load balancers work at the transport layer (layer 4 of the OSI model). This means that it will distribute network traffic in the same Azure data center, but cannot use the characteristics of traditional load balancers provided by the session and application layers, as these are layer 7 constructs of the OSI model.

Load balancers are configured with load balancing rules that work at the port level. It accepts the source port and the destination port to map them together so that whenever it receives a request for the source port, the request is forwarded to the virtual machine from a set of virtual machines (or applications in VNET) connected to the load balancer on the destination port.

The Azure load balancer can be used in two configuration modes:

External-Public load balancing

Internal-internal load balancing

External-Public load balancing

In this mode, a public IP address is assigned to the load balancer to ensure that the load balancer can accept requests from the Internet. Client applications and services will invoke the load balancer from Internet, and then, according to the configured rules, it will distribute incoming traffic through VM, containers, or applications.

Internal-internal load balancin

The internal load balancer is basically the same as the external load balancer, but it uses a private IP address, so it can only be called from applications in the virtual network to which it is connected.

Azure load balancer helps us design high availability at the infrastructure level, but because there are situations that require our load balancing components to provide more advanced functions and services, such as connection relevance, security, SSL termination, etc., we cannot use Azure load balancer to implement these advanced functions we need a solution that can handle the layer 7 structure of the OSI model, that is, applications, sessions, etc. Let's see how we can achieve this in the next section.

Azure Application Gateway

The Azure application gateway is a 7-layer load balancer, so it can payload the sessions that access the application, so that the application gateway can provide more functions in addition to load balancing. Such as sticky conversation, bonding affinity and so on. Because application gateways have more features than Azure load balancers, more complex routing and load balancing can be configured. The application gateway acts as a reverse proxy service. It terminates the client connection and forwards the request to the back-end endpoint.

Personally, I think that if we run workloads at the application level where common load balancers should be used, then in more use cases, the use of application gateways makes more sense than load balancers.

Application gateways can be thought of as running on layer 7 and provide more functionality than load balancers. Application gateways can also be used to route traffic based on URL, which is useful for developing multi-tenant applications, where each tenant has a separate VM running instance and a tenant identifier in URL.

Azure Traffic Manager

So far, we have seen a load balancing solution that meets load balancing in the data center. Load balancers and application gateways are components used to achieve high availability in the data center. But through the cloud, we can also build our applications in a geographically distributed way. So how do we balance the load between geographical locations.

Azure Traffic Manager is used for this purpose only. The Azure traffic manager uses DNS to redirect requests to the appropriate geolocation endpoint. The traffic manager does not see the traffic passing between the client and the service. It simply redirects the request based on the most appropriate endpoint. Geolocation endpoints are Internet-oriented accessible public URL.

The Azure traffic manager works at the DNS level, that is, it uses rules configured at the DNS level to distribute load across multiple regions and data centers. The client issues a DNS request, and based on the location of the DNS, the Azure Traffic Manager will find the nearest area and send it back to the client through the DNS response.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.