Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Creating a Backend Server Group

Updated on 2025-02-19 GMT+08:00

Scenario

To route requests, you need to associate at least one backend server group to each listener.

A backend server group can be associated with more than one listener.

You can create a backend server group for a load balancer in any of the ways described in Table 1.

Table 1 Scenarios

Scenario

Reference

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 by referring to Listener Overview.

Changing the backend server group associated with the listener

Changing a Backend Server Group

Notes and Constraints

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

Table 2 The frontend and backend protocol

Load Balancer Specification

Frontend Protocol

Backend Protocol

Network load balancing

TCP

TCP

Network load balancing

UDP

  • UDP
  • QUIC

Network load balancing

TLS

  • TLS
  • TCP

Application load balancing

HTTP

HTTP

Application load balancing

HTTPS

  • HTTP
  • HTTPS
  • gRPC

Application load balancing

QUIC

  • HTTP
  • HTTPS
  • gRPC

Procedure

  1. Go to the backend server group list page.
  2. Click Create Backend Server Group in the upper right corner.
  3. Configure the routing policy based on Table 3.
    Table 3 Parameters required for configuring a routing policy

    Parameter

    Description

    Load Balancer Type

    Specifies the type of load balancers 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.

    • Associate later
    • Associate existing

    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, UDP, and TLS listeners.

    Backend Server Group Type

    Specifies the type of the backend server group.

    • Hybrid: You can add ECSs and supplementary network interfaces as backend servers, or add IP addresses as 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 only when you enable IP as a Backend.
    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Backend Server Group Name

    Specifies the name of the backend server group.

    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, gRPC, TCP, UDP, TLS, or QUIC
    • Active/Standby: TCP, UDP, TLS, or QUIC

    IP Address Type

    Specifies the IP address type of backend servers that can be added to a backend server group. By default, IPv4 addresses can be added as backend servers.

    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.
    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    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 in certain regions. You can see which regions support this option on the console.

    NOTE:

    This option is available only for TCP, UDP, or QUIC 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: 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.
    • Connection ID: This algorithm is available when you have selected QUIC for Backend Protocol. This algorithm 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.

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

    Forwarding Even Unhealthy

    Specifies whether to forward traffic across all the backend servers even if all of them have been identified as unhealthy. This option is only available if Forwarding Mode is set to Load balancing.

    This option is disabled by default, preventing requests from being sent to the backend server group, in which all backend servers are identified as unhealthy.

    If this option is enabled, ELB forwards traffic across all the backend servers even if all of them have been identified as unhealthy.

    The function improves service availability by preventing disruptions from faulty health checks resulting from misconfigurations.

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

    NOTE:

    TLS backend server groups do not support sticky sessions.

    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 allows 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.
    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 the minutes that sticky sessions are maintained. 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, gRPC, and HTTPS backend server groups of dedicated load balancers.

    For more information about the slow start, see Slow Start.

    Slow Start Duration (s)

    Specifies how long the slow start will last, in seconds.

    This parameter is mandatory if Slow Start is enabled.

    Deregistration Delay

    This parameter is enabled by default if the backend protocol is TCP, UDP, or QUIC.

    If a backend server is removed or the health check fails, ELB continues to route in-flight requests to this server until the deregistration delay timeout expires.

    NOTE:

    This option is available in certain regions. You can see which regions support this option on the console.

    Deregistration Delay Timeout (s)

    This parameter is mandatory if Deregistration Delay is enabled.

    ELB continues to route in-flight requests to the backend server until the deregistration delay timeout expires.

    The value ranges from 10 to 4000, in seconds. The default value is 300.

    Description

    Provides supplementary information about the backend server group.

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

    Add cloud servers, supplementary network interfaces, or IP addresses 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 health checks.

    If the health check is enabled, click next to Advanced Settings 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.

    • TCP, HTTP, TLS, gRPC, and HTTPS are supported.
    • If the protocol of the backend server group is UDP and QUIC, the health check protocol is UDP by default and cannot be changed.
    NOTE:

    TLS and gRPC are available in certain regions. You can see which regions support them on the console.

    Domain Name

    Specifies the domain name that will be used for health checks.

    This parameter is mandatory if the health check protocol is HTTP, gRPC, 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: 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 URL, which is the destination on backend servers for health checks. This parameter is mandatory if the health check protocol is HTTP, gRPC, 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 a unique number or a positive number range within the status code range, for example, 0-10 and 200-300. A maximum of five HTTP status codes are supported. If there is more than one status code, press Enter to separate them.

    • If the health check protocol is HTTP or HTTPS, the status code ranges from 200 to 599.
    • When the gRPC protocol is used, the status code ranges from 0 to 99.
    NOTE:

    This feature will be available in more regions. See details on the management console.

  5. Click Next.
  6. Confirm the specifications and click Create Now.

Related Operations

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

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback