Adding a Listener
Scenarios
After creating a load balancer, you need to add at least one listener to the load balancer. A 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.
A 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.
Add a Listener
- Log in to the management console.
- In the upper left corner of the page, click and select the desired region and project.
- Click Service List. Under Network, click Elastic Load Balance.
- Locate the target load balancer and click its name.
- Under Listeners, click Add Listener. Set the parameters by referring to 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 numbers range from 1 to 65535, and the following protocols are supported:
- HTTP
- TCP
- HTTPS
- UDP
HTTP/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 feature to redirect the requests from the HTTP listener to the HTTPS listener to ensure security.
After an HTTP listener is redirected, backend servers 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
Advanced Settings
HTTP/2
Specifies whether HTTP/2 is supported when you select HTTPS for Frontend Protocol.
N/A
Mutual Authentication
Specifies whether to enable mutual authentication between the server and client. To enable mutual authentication, both a server certificate and CA certificate are required. This feature can be enabled when Frontend Protocol is set 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 when Frontend Protocol is set to HTTPS and mutual authentication is enabled.
N/A
Description
Provides supplementary information about the listener.
N/A
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 that receive requests from the load balancer. Select Create new or Use existing.
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.
- 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 business needs for better traffic distribution.
Weighted round robin
Sticky Session
Specifies whether to enable sticky sessions. After this feature is enabled, 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
Specifies the sticky session type. The following options are available:
- Source IP address: The hash of the source IP address of the request is used to identify a server in the static fragment table.
- Load balancer cookie: The load balancer generates a cookie after receiving a request from the client. All subsequent requests with the cookie are routed to the same backend server for processing.
- Application cookie: The application deployed on the backend server generates a cookie after receiving the first request from the client. All requests with the cookie are routed to this backend server.
NOTE:- Source IP address is the only choice available when TCP is used as the frontend protocol. If HTTP or HTTPS is selected as the frontend protocol, the sticky session type can be Load balancer cookie or Application cookie. Choose an appropriate sticky session type to better distribute requests and improve load balancing.
- Sticky sessions at Layer 4 are maintained for one minute, while sticky sessions at Layer 7 are maintained for 24 hours.
Source IP address
Cookie Name
Specifies the cookie name. When Application cookie is selected, you need to enter a cookie name.
cookieName-qsps
Stickiness Duration (min)
Specifies the duration that sticky sessions are maintained in minutes. The value ranges from 1 to 60.
20
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 the health check function.
N/A
Protocol
- Specifies the protocol used by the load balancer to perform health checks on backend servers. You can use either TCP or HTTP. A selected protocol cannot be changed.
- If the frontend protocol is UDP, the health check protocol is UDP by default.
HTTP
Domain Name
Specifies the domain name in the health check request. The domain name consists of digits, letters, hyphens (-), and periods (.), and must start with a digit or letter. This parameter is left blank by default and needs to be set only when the health check protocol is HTTP.
www.elb.com
Port
Specifies the port used by the load balancer to perform health checks on backend servers. The port numbers range from 1 to 65535.
NOTE:This parameter is optional. If no health check port is specified, the port of each backend server is used for health checks by default.
80
Advanced Settings
Provides some advanced features. Two options are available, Default and Custom.
Default
Interval (s)
Specifies the maximum time between health checks in the unit of second.
The value ranges from 1 to 50.
5
Timeout (s)
Specifies the maximum time required for waiting for a response from the health check in the unit of second. The value ranges from 1 to 50.
10
Check Path
Specifies the health check URL, which is the destination on backend servers for health checks. This parameter is available only when Protocol is set to HTTP. The value 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot