Creating a Backend Server Group (Shared Load Balancers)

Scenario

To route requests, you need to associate a backend server group to each listener.

Note

This section describes how you can create a backend server group for shared load balancer.

You can create a backend server group in the ways listed in Table 1.

Table 1 Creating a backend server group

Scenario

Procedure

Creating a backend server group and associating it with a load balancer

Procedure

Creating a backend server group when adding a listener

You can add listeners using different protocols as required. For details, see Overview.

References are as follows:

Changing the backend server group associated with the listener

Changing a Backend Server Group

Constraints

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

  • The backend server group of a shared load balancer can be associated with only one listener.

Procedure

  1. Log in to the management console.

  2. In the upper left corner of the page, click image1 and select the desired region and project.

  3. Click image2 in the upper left corner to display Service List and choose Network > Elastic Load Balancing.

  4. In the navigation pane on the left, choose Elastic Load Balancing > Backend Server Groups.

  5. Click Create Backend Server Group in the upper right corner.

  6. Configure the routing policy based on Table 2.

    Table 2 Parameters required for configuring a routing policy

    Parameter

    Description

    Example Value

    Load Balancing Type

    Specifies the type of load balancers that can use the backend server group.

    Shared

    Load Balancer

    Specifies whether to associate a load balancer.

    N/A

    Backend Server Group Name

    Specifies the name of the backend server group.

    server_group

    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:

    The options are HTTP, TCP, and UDP.

    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. 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: Allows requests from different clients to be routed based on source IP addresses and ensures that requests from the same client are forwarded to the same server.

    For more information about load balancing algorithms, see Load Balancing Algorithms.

    Weighted round robin

    Sticky Sessions

    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 Sticky Session.

    N/A

    Sticky Session Type

    Specifies the type of sticky sessions. After the sticky session is enabled, you need to 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 hashing 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.

    • 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 same cookie are routed to the same backend server.

    Note

    • Source IP address is available when you have selected TCP or UDP for Backend Protocol.

    • Load balancer cookie is available when you have selected HTTP or HTTPS for Backend Protocol.

    Source IP address

    Stickiness Duration (min)

    Specifies the time that sticky sessions are maintained, in minutes.

    • Sticky sessions at Layer 4: 1 to 60

    • Sticky sessions at Layer 7: 1 to 1440

    20

    Description

    Provides supplementary information about the backend server group.

    N/A

  7. Click Next to add backend servers and configure health check based on Table 3. For more information about health checks, see Health Check.

    Table 3 Parameters required for configuring a health check

    Parameter

    Description

    Example Value

    Health Check

    Specifies whether to enable health checks.

    If the health check is enabled, click image3 next to Advanced Settings to set health check parameters.

    N/A

    Health Check Protocol

    • The health check protocol can be TCP or HTTP.

    • If the protocol of the backend server group is UDP, the health check protocol is UDP by default.

    HTTP

    Domain Name

    Specifies the domain name that will be used for health checks. By default, the private IP address of each backend server is used.

    A domain name consists of at least two character strings separated by periods (.). The total length of a domain name cannot exceed 100 characters with each character string not exceeding 63 characters. Only letters, digits, and hyphens (-) are allowed. Strings cannot start or end with a hyphen.

    www.elb.com

    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.

    80

    Path

    Specifies the health check URL, which is the destination on backend servers for health checks. 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 (&).

    /index.html

    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 interval ranges from 1 to 50.

    3

    Maximum Retries

    Specifies the maximum number of health check retries. The value ranges from 1 to 10.

    3

  8. Click Next.

  9. Confirm the specifications and click Create Now.