ELB

ELB

Elastic Load Balance (ELB) automatically distributes incoming traffic across multiple backend servers based on the listening rules you configure. ELB expands the service capabilities of your applications and improves their availability by eliminating single points of failure (SPOFs).

Elastic Load Balance (ELB) automatically distributes incoming traffic across multiple backend servers based on the listening rules you configure. ELB expands the service capabilities of your applications and improves their availability by eliminating single points of failure (SPOFs).

Free Packages Free

Register now to take advantage of these incredible deals

Huawei Cloud Blossom Program

Help your business bloom with cloud resource discounts, free trainings, and so on

Functions

  • Multiple Protocols 

    Multiple protocols are supported at Layer 4 and Layer 7, facilitating diverse application scenarios.

    Multiple protocols are supported at Layer 4 and Layer 7, facilitating diverse application scenarios.

  • High Availability 

    A variety of measures ensure high service availability and quality.

    A variety of measures ensure high service availability and quality.

  • Layer 4
    Layer 4

    TCP and UDP are used to handle services with a large number of access requests, or those require high performance.

    TCP and UDP are used to handle services with a large number of access requests, or those require high performance.

  • Layer 7
    Layer 7

    Both HTTP and HTTPS are supported. Multiple encryption protocols and cipher suites are available for HTTPS to ensure service flexibility and security.

    Both HTTP and HTTPS are supported. Multiple encryption protocols and cipher suites are available for HTTPS to ensure service flexibility and security.

  • Health Check
    Health Check

    Server health status is regularly monitored and traffic is distributed only to healthy servers, ensuring service continuity.

    Server health status is regularly monitored and traffic is distributed only to healthy servers, ensuring service continuity.

  • Cross-AZ Load Balancing
    Cross-AZ Load Balancing

    ELB distributes traffic across availability zones and ensures service continuity even if an availability zone fails because of a disaster.

    ELB distributes traffic across availability zones and ensures service continuity even if an availability zone fails because of a disaster.

  • Sticky Sessions 

    Requests from a client for a particular session are forwarded to the same backend server to ensure that the client has continuous access.

    Requests from a client for a particular session are forwarded to the same backend server to ensure that the client has continuous access.

  • Elastic Scaling 

    ELB automatically scales its request handling capacity and combines with Auto Scaling to improve service flexibility and reliability.

    ELB automatically scales its request handling capacity and combines with Auto Scaling to improve service flexibility and reliability.

  • Layer 4
    Layer 4

    Source IP addresses are used to maintain sessions at Layer 4.

    Source IP addresses are used to maintain sessions at Layer 4.

  • Layer 7
    Layer 7

    Cookies are used to maintain sessions at Layer 7.

    Cookies are used to maintain sessions at Layer 7.

  • Seamless Integration
    Seamless Integration

    Auto Scaling automatically adjusts the number of servers as necessary to cope with varying levels of workload.

    Auto Scaling automatically adjusts the number of servers as necessary to cope with varying levels of workload.

  • Automatic Expansion
    Automatic Expansion

    ELB automatically scales to the incoming traffic to ensure a positive user experience.

    ELB automatically scales to the incoming traffic to ensure a positive user experience.

How ELB Works

Figure 1 How ELB works

The following describes how ELB works:

1. A client sends a request to your application.

2. The listeners added to your load balancer use the protocols and ports you have configured to receive the request.

3. The listener forwards the request to the associated backend server group based on your configuration. If you have configured a forwarding policy for the listener, the listener evaluates the request based on the forwarding policy. If the request matches the forwarding policy, the listener forwards the request to the backend server group configured for the forwarding policy.

4. Healthy backend servers in the backend server group receive the request based on the load balancing algorithm and the routing rules you specify in the forwarding policy, handle the request, and return a result to the client.

How requests are routed depends on the load balancing algorithms configured for each backend server group. If the listener uses HTTP or HTTPS, how requests are routed also depends on the forwarding policies configured for the listener.

Load Balancing Algorithms

Dedicated load balancers support four load balancing algorithms: weighted round robin, weighted least connections, source IP hash, and connection ID. Shared load balancers support three load balancing algorithms: weighted round robin, weighted least connections, and source IP hash.

Weighted round robin: Requests are routed to backend servers using the round robin algorithm. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests. This algorithm is often used for short connections, such as HTTP connections.

The following figure shows an example of how requests are distributed using the weighted round robin algorithm. Two backend servers are in the same AZ and have the same weight, and each server receives the same proportion of requests.

Figure 2 Traffic distribution using the weighted round robin algorithm

Weighted least connections: In addition to the weight assigned to each server, the number of connections being processed by each backend server is also considered. Requests are routed to the server with the lowest connections-to-weight ratio. In addition to the number of connections, each server is assigned a weight based on its capacity. Requests are routed to the server with the lowest connections-to-weight ratio. This algorithm is often used for persistent connections, such as connections to a database.

The following figure shows an example of how requests are distributed using the weighted least connections algorithm. Two backend servers are in the same AZ and have the same weight, 100 connections have been established with backend server 01, and 50 connections have been connected with backend server 02. New requests are preferentially routed to backend server 02.

Figure 3 Traffic distribution using the weighted least connections algorithm

Source IP hash: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hashing key, and all backend servers are numbered. The generated key is used to allocate the client to a particular server. This allows requests from different clients to be routed based on source IP addresses and ensures that a client is directed to the same server that it was using previously. This algorithm works well for TCP connections of load balancers that do not use cookies.

The following figure shows an example of how requests are distributed using the source IP hash algorithm. Two backend servers are in the same AZ and have the same weight. If backend server 01 has processed a request from IP address A, the load balancer will route new requests from IP address A to backend server 01.

Figure 4 Traffic distribution using the source IP hash algorithm

Connection ID: The connection ID in the packet is calculated using the consistent hash algorithm to obtain a specific value, and backend servers are numbered. The generated value determines to which backend server the requests are routed. This allows requests with different connection IDs to be routed to different backend servers and ensures that requests with the same connection ID are routed to the same backend server. This algorithm applies to QUIC requests.

NOTE: Currently, only dedicated load balancers support the Connection ID algorithm.

Figure 5 shows an example of how requests are distributed using the connection ID algorithm. Two backend servers are in the same AZ and have the same weight. If backend server 01 has processed a request from client A, the load balancer will route new requests from client A to backend server 01.

Figure 5 Traffic distribution using the connection ID algorithm

Factors Affecting Load Balancing

In addition to the load balancing algorithm, factors that affect load balancing generally include connection type, session stickiness, and server weights.

Assume that there are two backend servers with the same weight (not zero), the weighted least connections algorithm is selected, sticky sessions are not enabled, and 100 connections have been established with backend server 01, and 50 connections with backend server 02.

When client A wants to access backend server 01, the load balancer establishes a persistent connection with backend server 01 and continuously routes requests from client A to backend server 01 before the persistent connection is disconnected. When other clients access backend servers, the load balancer routes the requests to backend server 02 using the weighted least connects algorithm.

NOTE: If backend servers are declared unhealthy or their weights are set to 0, the load balancer will not route any request to the backend servers.

For details about the weighted least connections algorithm, see Load Balancing Algorithms.

If requests are not evenly routed, troubleshoot the issue by performing the operations described in How Do I Check Whether Traffic Is Evenly Distributed?

Product Advantages

Robust Performance

ELB can establish up to 100 million concurrent connections and meet your requirements for handling huge numbers of concurrent requests.

High Availability

ELB is deployed in cluster mode and ensures that your services are uninterrupted. If servers in an AZ are unhealthy, ELB automatically routes traffic to healthy servers in other AZs.

High Scalability

ELB makes sure that your applications always have enough capacity for varying levels of workloads. It works with Auto Scaling to flexibly adjust the number of servers and intelligently distribute incoming traffic across servers.

Easy to Use

A diverse set of protocols and algorithms enable you to configure traffic routing policies to suit your needs while keeping deployments simple.

Application Scenarios

High Traffic Websites

ELB intelligently distributes traffic to ensure smooth running of applications, making it a good choice for websites with an extremely large number of simultaneous requests.

Advantages

  • Flexible Expansion

    ELB allows you to monitor traffic and automatically scales as traffic changes.

  • High Performance

    ELB is capable of processing hundred millions of connections simultaneously.

Related Services
VPC
ECS
RDS for MySQL
Anti-DDoS

Disaster Recovery

ELB can distribute incoming traffic across availability zones, offering high service availability to enterprises like banks.

Advantages

  • Flexible Expansion

    ELB automatically scales its request handling capacity according to the incoming traffic.

  • Uninterrupted Service

    ELB distributes traffic to servers in multiple availability zones, and services will continue even if an availability zone becomes faulty.

Related Services
VPC
ECS
RDS for MySQL

Flash Sales

ELB works with Auto Scaling to balance the number of servers during promotion periods that feature sudden spikes.

Advantages

  • Elastic Scaling

    Servers are automatically added or removed according to changes in the amount of incoming traffic.

  • High Availability

    Server health status is regularly monitored and traffic is distributed only to healthy servers, ensuring service continuity.

  • High Performance

    ELB can process hundred millions of concurrent connections, making it the right choice for handling a large number of access requests.

Related Services
VPC
ECS
AS
OBS
CDN

Getting Started

Figure 1 shows how you can use basic functions of ELB to route requests when you are still new to ELB, and Figure 2 shows how you can use domain name or URL-based forwarding of ELB to route requests more efficiently.

Figure 1 Getting started - entry level

Figure 2 Getting started - advanced level

User Guide
Load Balancer
Overview

A load balancer distributes incoming traffic across multiple backend servers. Before using a load balancer, you need to add at least one listener to it and associate one backend server with it.
Creating a Dedicated Load Balancer

You have prepared everything required for creating a load balancer. For details, see Preparations for Creating a Load Balancer.
Modifying the Bandwidth

When changing bandwidth, you need to change the specifications of the dedicated load balancer to avoid speed limit due to insufficient bandwidth.
Creating a Shared Load Balancer

You have prepared everything required for creating a load balancer. For details, see Preparations for Creating a Load Balancer.
Changing an IP Address

You can change the private IPv4 IP address and IPv6 IP address bound to each load balancer. Only dedicated load balancers support this function.
Preparations for Creating a Load Balancer

Before creating a load balancer, you must plan its region, network, protocol, and backend servers.
Changing the Specifications of a Dedicated Load Balancer

This section guides you how you can change the specifications of a dedicated load balancer.
Changing the Billing Mode or Bandwidth Billing Option

For public network load balancers, you can change their billing options (billed by bandwidth or traffic) as required.
Listener
Overview

You need to add at least one listener after you have created a load balancer. This listener receives requests from clients and routes requests to backend servers using the protocol, port, and load balancing algorithm you select.
Protocols and Ports

Frontend protocols and ports are used by load balancers to receive requests from clients. Load balancers use TCP or UDP at Layer 4, and HTTP or HTTPS at Layer 7. Select a protocol and a port that best suit your requirements.
Load Balancing Algorithms

Load balancers receive requests from clients and forward them to backend servers in one or more AZs. Each load balancer has at least a listener and a backend server. The load balancing algorithm you select when you add the listener determines how requests are distributed.
Access Control

Access control allows you to add a whitelist or blacklist to specify IP addresses that are allowed or denied to access a listener. A whitelist allows specified IP addresses to access the listener, while a blacklist denies access from specified IP addresses.
Adding a TCP Listener

You can add a TCP listener, if high reliability and high accuracy are required but slow speed is acceptable, for example, during file transfer, email sending and receiving, and remote login.
Adding an HTTP Listener

HTTP listeners are suitable for applications that require identifying the data content, such as web applications and small mobile games.
Configuring Timeout Durations

You can configure timeout durations (idle timeout, request timeout, and response timeout) for your listeners to meet varied demands. 
Transfer Client IP Address

Generally, load balancers use IP addresses in the 100.125.0.0.16 IP address range to communicate with backend servers.

Health Check
Overview

ELB periodically sends requests to backend servers to check whether they can process requests. If a backend server is detected as unhealthy, the load balancer stops routing requests to it.

Disabling a Health Check

If you do not require health check, you can disable it when you add listeners. If you have already added listeners with health check enabled, you can also disable it when you modify the listeners.
Configuring a Health Check

You can configure a health check when you add a listener. If you have no special requirements, retain the default settings.
Certificate
Overview

ELB supports two types of certificates. If you need an HTTPS listener, you need to bind a server certificate to it. To enable mutual authentication, you also need to bind a CA certificate to the listener.
Replacing a Certificate

You need to bind a certificate when you add an HTTPS listener to a load balancer. If the certificate used by the load balancer has expired or needs to be replaced due to other reasons, you can replace the certificate.
Creating, Modifying, or Deleting a Certificate

To enable authentication for securing data transmission over HTTPS, you can create certificates for load balancers. You can also modify and delete certificates.
Certificate and Private Key Format

You can copy and paste the certificate body to create a certificate or directly upload the certificate.
Querying a Listener by Certificate

You need to quickly view details of the listener to which a certificate is bound.

Videos

Elastic Load Balance Brief Introduction

03:20

Elastic Load Balance Brief Introduction

Configuring ELB

04:46

Configuring ELB

Configuring Access Logging

03:49

Configuring Access Logging

What Can I Do If Backend Server Is Unhealthy?

06:03

What Can I Do If Backend Server Is Unhealthy?

Elastic Load Balance Brief Introduction

03:20

Elastic Load Balance Brief Introduction

Configuring ELB

04:46

Configuring ELB

Configuring Access Logging

03:49

Configuring Access Logging

What Can I Do If Backend Server Is Unhealthy?

06:03

What Can I Do If Backend Server Is Unhealthy?

Documentation

Best Practices

API Reference

SDK Reference

FAQ
查看更多 收起