Adding a Listener¶
Scenarios¶
After you create a load balancer, add at least one listener to the load balancer. This listener is a process that checks for requests using the protocol and port you configure for connections from clients to the load balancer, and the protocol and port from the load balancer to backend servers.
The listener also defines the health check configuration, based on which the load balancer continually checks the running statuses of backend servers. If a backend server is detected unhealthy, the load balancer routes traffic to these healthy ones. Traffic forwarding to this server resumes once it recovers.
When you add an HTTP listener, ensure that the subnet of the load balancer has sufficient IP addresses. If the IP addresses are insufficient, add multiple subnets on the Basic Information page of the load balancer. After you select a subnet, ensure that ACL rules are not configured for this subnet. If rules are configured, request packets may not be allowed.
Adding a Listener to a Load Balancer¶
Log in to the management console.
In the upper left corner of the page, click
and select the desired region and project.Hover on
in the upper left corner to display Service List and choose Network > Elastic Load Balancing.Locate the load balancer and click its name.
Under Listeners, click Add Listener. Configure the parameters based on Table 1, Table 2, and Table 3.
Table 1 Parameters for configuring a listener¶ Parameter
Description
Example Value
Name
Specifies the listener name.
listener-pnqy
Frontend Protocol/Port
Specifies the protocol and port used by the load balancer to receive requests from clients and forward the requests to backend servers.
The port number ranges from 1 to 65535, and the following protocols are supported:
HTTP
TCP
HTTPS
UDP
TCP/80
Redirect
Redirects requests to an HTTPS listener when HTTP is used as the frontend protocol. If you have both HTTPS and HTTP listeners, you can use this function to redirect the requests from the HTTP listener to the HTTPS listener to ensure security.
If you create a redirect for an HTTP listener, the backend server will return HTTP 301 Move Permanently to the clients.
N/A
Redirected To
Specifies the HTTPS listener to which requests are redirected.
N/A
Server Certificate
Specifies the certificate used by the server to authenticate the client when HTTPS is used as the frontend protocol.
N/A
Enable SNI
Specifies whether to enable SNI when HTTPS is used as the frontend protocol.
SNI is an extension to TLS and is used when a server uses multiple domain names and certificates. This allows the client to submit the domain name information while sending an SSL handshake request. After the load balancer receives the request, the load balancer queries the corresponding certificate based on the domain name and returns it to the client. If no certificate is found, the load balancer will return the default certificate.
N/A
SNI Certificate
Specifies the certificate associated with the domain name when the frontend protocol is HTTPS and SNI is enabled.
N/A
Advanced Settings
HTTP/2
Specifies whether you want to use HTTP/2 if you select HTTPS for Frontend Protocol.
N/A
Security Policy
Specifies the security policy you can use if you select HTTPS as the frontend protocol. The following options are available (for details, see TLS Security Policy):
TLS-1-0
Mutual Authentication
Specifies whether to enable mutual authentication between the server and client. Both a server certificate and CA certificate are required for mutual authentication. You can enable this option if you have set Frontend Protocol to HTTPS.
N/A
CA Certificate
Specifies the certificate used by the server to authenticate the client when HTTPS is used as the frontend protocol. This parameter is mandatory if you have set Frontend Protocol to HTTPS and enabled mutual authentication.
N/A
Obtain Load Balancer EIP
Specifies whether to pass the load balancer EIP to backend servers if you select HTTPS or HTTP for Frontend Protocol.
N/A
Description
Provides supplementary information about the listener.
N/A
Tag
Adds tags to the listener. Each tag is a key-value pair, and the tag key is unique.
11/11
Table 2 Parameters for adding a backend server group¶ Parameter
Description
Example Value
Backend Server Group
Specifies a group of servers with the same features to receive requests from the load balancer. Two options are available:
Create new
Use existing
Note
To associate an existing backend server group, ensure that it is not in use. Select the backend server group with the correct protocol. For example, if the frontend protocol is TCP, the backend protocol can only be TCP.
Create new
Name
Specifies the name of the backend server group.
server_group-sq4v
Backend Protocol
Specifies the protocol used by backend servers to receive requests.
HTTP
Load Balancing Algorithm
Specifies the algorithm used by the load balancer to distribute traffic. The following options are available:
Weighted round robin: Requests are routed to different servers based on their weights, which indicate server processing performance. Backend servers with higher weights receive proportionately more requests, whereas equal-weighted servers receive the same number of requests.
Weighted least connections: In addition to the weight assigned to each server, the number of connections processed by each backend server is also considered. Requests are routed to the server with the lowest connections-to-weight ratio.
Source IP hash: The source IP address of the request is input into a hash algorithm, and the resulting hash is used to identify a server in the static fragment table.
Note
Choose an appropriate algorithm based on your requirements for better traffic distribution.
Weighted round robin
Sticky Session
You have selected Weighted round robin for Load Balancing Algorithm.
Specifies whether to enable sticky sessions. If you enable sticky sessions, all requests from a client during one session are sent to the same backend server.
Note
For HTTP and HTTPS listeners, enabling or disabling sticky sessions may cause few seconds of service interruption.
N/A
Sticky Session Type
After you enable the sticky session feature, select a sticky session type:
Source IP address: The source IP address of each request is calculated using the consistent hashing algorithm to obtain a unique hash key, and all backend servers are numbered. The system allocates the client to a particular server based on the generated key. This enables requests from different clients to be routed and ensures that a client is directed to the same server that it was using previously.
Load balancer cookie: The load balancer generates a cookie after receiving a request from the client. All subsequent requests with the same cookie are then routed to the same backend server.
Note
Sticky sessions at Layer 4 (for TCP or UDP listeners): only Source IP address
Sticky sessions at Layer 7 (for HTTP or HTTPS listeners): Load balancer cookie. Choose an appropriate sticky session type to better distribute requests and improve load balancing.
Source IP address
Cookie Name
Specifies the cookie name. If you select Application cookie, enter a cookie name.
cookieName-qsps
Description
Provides supplementary information about the backend server group.
N/A
Table 3 Parameters for configuring a health check¶ Parameter
Description
Example Value
Enable Health Check
Specifies whether to enable health checks.
N/A
Protocol
Specifies the protocol used by the load balancer to perform health checks on backend servers. You can select either TCP or HTTP. The health check protocol cannot be changed once it is set.
If the frontend protocol is UDP, the health check protocol is UDP by default.
HTTP
Port
Specifies the port used by the load balancer to perform health checks on backend servers. The port number ranges from 1 to 65535.
Note
This parameter is optional. If you do not specify a health check port, a port of the backend server will be used for health checks by default. If you specify a port, it will be used for health checks.
80
Advanced Settings
Provides some advanced features.
N/A
Interval (s)
Specifies the maximum time between two consecutive health checks, in seconds.
The interval ranges from 1 to 50.
5
Timeout (s)
Specifies the maximum time required for waiting for a response from the health check, in seconds. The timeout ranges from 1 to 50.
3
Check Path
Specifies the destination path for health checks. Configure this parameter only if you have set Protocol to HTTP. The path can contain 1 to 80 characters and must start with a slash (/).
/index.html
Maximum Retries
Specifies the maximum number of health check retries. The value ranges from 1 to 10.
3
Click Finish.
Click OK.