Creating a Backend Server Group

If you want to use ELB to balance traffic, you must associate at least one backend server group with a listener and add at least one backend server to the backend server group.

A backend server group can be associated with listeners of different load balancers.

Table 1 describes the scenarios for creating a backend server group.

The backend protocol of the new backend server group must match the frontend protocol of the listener, as described in Table 2.

1. Log in to the management console.
2. Click in the upper left corner of the console and select a desired region and project.
3. Click in the upper left corner to display Service List and choose Network > Elastic Load Balance.
4. In the navigation pane on the left, choose Elastic Load Balance > Backend Server Groups.
5. Click Create Backend Server Group in the upper right corner.
6. Configure the routing policy based on Table 3.

   Table 3 Parameters required for configuring a routing policy

   Parameter	Description
   Backend Server Group Name	Specifies the name of the backend server group.
   Type	Specifies the type of load balancer that can use the backend server group. Select Dedicated.
   Load Balancer	Specifies whether to associate a load balancer. You can associate an existing dedicated load balancer when you create a backend server group or associate one later. A backend server group can be associated with multiple load balancers or listeners. After the group is created, associate it with listeners to complete service configuration. Associate later Associate existing
   Backend Server Group Type	Specifies the type of the backend server group. Hybrid: You can add cloud servers and supplementary network interfaces as backend servers, and add IP addresses as backend servers when IP as a Backend is enabled. When you create a hybrid backend server group, you must specify a VPC and associate the backend server group with a load balancer in this VPC. IP as a backend server: You can add IP addresses as backend servers. This function is available only when IP as a Backend is enabled.
   Forwarding Mode	Specifies the forwarding mode to distribute traffic. There are two options: Load balancing and Active/Standby. Load balancing: You can add one or more backend servers to the backend server group. Active/Standby: You must add two backend servers to the backend server group, one acting as the active server and the other as the standby server. If the active server is faulty, traffic is forwarded to the standby server, improving service reliability. Active/standby backend server groups can only be associated with TCP, TLS and UDP listeners.
   VPC	Specifies the VPC where the backend server group works. You can associate the backend server group with a load balancer in this VPC. This parameter is mandatory if you select Hybrid for Backend Server Group Type. You can select an existing VPC or create a new one. For more information about VPC, see the Virtual Private Cloud User Guide.
   Backend Protocol	Specifies the protocol that backend servers in the backend server group use to receive requests from the listeners. The protocol varies depending on the forwarding mode: Load balancing: HTTP, HTTPS, TCP, UDP, TLS, or QUIC Active/Standby: TCP, UDP, TLS, or QUIC
   IP Address Version	Specifies the IP address version of backend servers that can be added to the backend server group. By default, IPv4 backend servers are supported. There are two options when the backend protocol is TCP or UDP: IPv4: Only IPv4 addresses can be added as backend servers. Dual stack: Both IPv4 and IPv6 addresses can be added as backend servers.
   Forward to Same Port	If this option is enabled, you do not need to specify a backend port when you add a backend server. The listener routes the requests to the backend server over the same port as the frontend port. This option cannot be disabled after being enabled. NOTE: This option is available only for TCP and UDP backend server groups associated with a dedicated load balancer.
   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. 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 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. Source IP hash: Requests from different clients are routed based on source IP addresses and requests from the same client are forwarded to the same server. Connection ID: This algorithm is available when you have selected QUIC for Backend Protocol. This algorithm allows requests with the same connection ID to be routed to the same backend server. For more information about load balancing algorithms, see Configuring Load Balancing Algorithms to Distribute Traffic.
   Sticky Session	Specifies whether to enable sticky sessions if you have selected Weighted round robin, Connection ID, or Weighted least connections for Load Balancing Algorithm. If you enable sticky sessions, all requests from the same client during one session are sent to the same backend server. For more information about sticky sessions, see Enabling Sticky Session to Accelerate Access. NOTE: TLS backend server groups do not support sticky session. Sticky session is enabled by default and is not shown for QUIC backend server groups.
   Sticky Session Type	Specifies the sticky session type. This parameter is mandatory if Sticky Session is enabled. You can select one of the following types: Source IP address: 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 system allocates the client to a particular server based on the generated key. This ensures requests from the same IP address are forwarded to the same backend server. 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. Application cookie: The application deployed on the backend server generates a cookie after receiving the first request from the client. All subsequent requests with the cookie are routed to the same backend server. NOTE: Source IP address is available when you have selected TCP, QUIC, or UDP for Backend Protocol. Load balancer cookie and Application cookie are available when you have selected HTTP, GRPC, or HTTPS for Backend Protocol.
   Stickiness Duration (min)	Specifies how long the sticky session is maintained, in minutes. This parameter is mandatory if Sticky Session is enabled. Sticky sessions at Layer 4: 1 to 60 Sticky sessions at Layer 7: 1 to 1440
   Slow Start	Specifies whether to enable slow start. This parameter is optional if you have selected Weighted round robin for Load Balancing Algorithm. After you enable this option, the load balancer linearly increases the proportion of requests to backend servers in this mode. When the slow start duration elapses, the load balancer sends full share of requests to backend servers and exits the slow start mode. NOTE: Slow start is only available for HTTP, and HTTPS backend server groups of dedicated load balancers. For more information about the slow start, see Configuring Slow Start for a Backend Server Group.
   Slow Start Duration (s)	Specifies how long the slow start will last, in seconds. This parameter is mandatory if Slow Start is enabled.
   Description (Optional)	Provides supplementary information about the backend server group.

7. Click Next to add backend servers and configure health check.

   Add cloud servers, supplementary network interfaces, and IP as backend servers to this backend server group. For details, see Backend Server Overview.

   Configure health check for the backend server group based on Table 4. For more information about health checks, see Health Check.

   Table 4 Parameters required for configuring a health check

   Parameter	Description
   Health Check	Specifies whether to enable the health check option. If health check is enabled, click to set health check parameters.
   Health Check Protocol	Specifies the protocol that will be used by the load balancer to check the health of backend servers. The value can be TCP, HTTP, TLS, or HTTPS. If the protocol of the backend server group is UDP or QUIC, the health check protocol is UDP by default and cannot be changed.
   Domain Name	Specifies the domain name that will be used for the health check. This parameter is mandatory if the health check protocol is HTTP or HTTPS. By default, the private IP address of each backend server is used. You can also specify a domain name that consists of at least two labels separated by periods (.). Use only letters, digits, and hyphens (-). Do not start or end strings with a hyphen. Max total: 100 characters. Max label length: 63 characters.
   Health Check Port	Specifies the port that will be used by the load balancer to check the health of backend servers. The port number ranges from 1 to 65535. NOTE: By default, the service port on each backend server is used. You can also specify a port for health checks.
   Path	Specifies the health check path, which is the destination on backend servers for health checks. This parameter is mandatory if the health check protocol is HTTP or HTTPS. The path can contain 1 to 80 characters and must start with a slash (/). The path can contain letters, digits, hyphens (-), slashes (/), periods (.), question marks (?), number signs (#), percent signs (%), ampersands (&), and extended character sets _;~!. () *[]@$^:',+
   Interval (s)	Specifies the maximum time between two consecutive health checks, in seconds. The interval ranges from 1 to 50.
   Timeout (s)	Specifies the maximum time required for waiting for a response from the health check, in seconds. The value ranges from 1 to 50.
   Healthy Threshold	Specifies the number of consecutive successful health checks required for declaring a backend server healthy. The value ranges from 1 to 10.
   Unhealthy Threshold	Specifies the number of consecutive failed health checks required for declaring a backend server unhealthy. The value ranges from 1 to 10.
   Status Code	Specifies the status codes that will be returned to the load balancer to indicate the health of backend servers. This parameter is available only when you set the health check protocol to HTTP or HTTPS. You can enter any unique number from 200 to 599, or a number range, for example, 200-300. The default value is 200. A maximum of five HTTP status codes and number ranges are supported. If there is more than one status code or number range, press Enter to separate them.

8. Click Next.
9. Confirm the specifications and click Create Now.

You can associate the backend server group with the listener of a dedicated load balancer in the ways listed in Table 1.