Edge Acceleration
  • Site Acceleration
    • Overview
    • Quickly Import and Export Site Configuration
    • Access Control
      • Token Authentication
    • Smart Acceleration
    • File Optimization
      • Smart Compression
    • Network Optimization
      • HTTP/2
      • HTTP/3(QUIC)
        • Overview
        • Enable HTTP/3
        • QUIC SDK
          • SDK Overview
          • SDK Download and Integration
          • Sample Code
            • Android
            • iOS
          • API Documentation
            • Android
            • iOS
      • IPv6 Access
      • Maximum Upload Size
      • WebSocket
      • Client IP Geolocation Header
      • Client IP Geographical Location
      • gRPC
    • URL Rewrite
      • Access URL Redirection
      • Origin-Pull URL Rewrite
    • Modifying Header
      • Modifying HTTP Response Headers
      • Modifying HTTP Request Headers
    • Custom Error Page
    • Request and Response Actions
      • Processing order
      • Default HTTP Headers of Origin-Pull Requests
      • Default HTTP Response Headers
    • Media Services
      • Audio and Video Pre-pulling
      • Just-in-Time Image Processing
      • Just-in-Time Media Processing
      • VOD Media Origin
  • L4 Proxy
    • Overview
    • Creating an L4 Proxy Instance
    • Modifying an L4 Proxy Instance
    • Disabling or Deleting an L4 Proxy Instance
    • Batch Configuring Forwarding Rules
    • Obtaining Real Client IPs
      • Obtaining Real TCP Client IPs via TOA
      • Obtaining Real Client IPs Through Protocol V1/V2
        • Overview
        • Method 1: Obtaining Real Client IPs Through Nginx
        • Method 2: Parsing Real Client IPs on Application Server
        • Format of Real Client IPs Obtained Through Proxy Protocol V1/V2
      • Transmitting Client Real IP via SPP Protocol
  • Edge DNS
    • Hosting DNS Records
      • Modifying DNS Servers
      • Configuring DNS Records
      • Advanced DNS Configuration
    • Domain Connection
      • Adding A Domain Name for Acceleration
      • Ownership Verification
      • Modifying CNAME Records
    • Domain alias
      • Overview
      • Configuration Guide
      • Batch Connecting SaaS Domain Names
      • Configuring Alias Domain Names for Disaster Recovery
    • Traffic Scheduling
      • Traffic Scheduling Management
    • Origin Configuration
      • Origin-pull configuration
        • Configuring Origin-Pull HTTPS
        • Host Header Rewrite
        • Controlling Origin-pull Requests
        • Redirect Following During Origin-Pull
        • HTTP/2 Origin-Pull
        • Range GETs
      • Load Balancing
        • Overview
        • Quickly Create Load Balancers
        • Health Check Policies
        • Viewing the Health Status of Origin Server
        • Related References
          • Load Balancing-Related Concepts
          • Introduction to Request Retry Strategy
      • Origin Group Configuration
      • Related References
        • ld Version Origin Group Compatible Related Issues
      • Collect EdgeOne origin-pull node IP
  • Edge Cache
    • Overview
    • EdgeOne Cache Rules
      • Content Cache Rules
      • Cache Key Introduction
      • Vary Feature
    • Cache Configuration
      • Custom Cache Key
      • Node Cache TTL
      • Status Code Cache TTL
      • Browser Cache TTL
      • Offline Caching
      • Cache Prefresh
    • Clear and Preheat Cach
      • Cache Purge
      • URL Pre-Warming
    • How to improve the Cache Hit Rate of EdgeOne
  • Rules Engine
    • Overview
    • Supported Matching Types and Actions
    • Rule Management
    • variables
Docs Overview/
Edge Acceleration/
Edge DNS/
Origin Configuration/
Load Balancing/
Quickly Create Load Balancers/

Quickly Create Load Balancers

This document guides you on how to create a Cloud Load Balancer instance.
Note:
EdgeOne Load Balancing feature is in beta testing. If you want to use it, you can Contact Us.

Sample Scenario

For example, you currently have an acceleration domain www.example.com, with three origins 1.2.3.4, 2.3.4.5, and 3.4.5.6. Under normal circumstances, both 1.2.3.4 and 2.3.4.5 are used as primary origins. You have already configured them as the origin group named primary_origins following the Origin Group Operation Guide. The server 3.4.5.6 is used as a standby origin in a group called backup_origins, which is only used when the primary origins fail. In cases where a real business request fails, retries are attempted with other healthy servers within the same group. Additionally, there is a requirement for proactive probing to actively identify and disable unhealthy origins.

Directions

1. Log in to the Tencent Cloud EdgeOne console. In the left menu bar, click the Site List. Within this list, click the Site that need to be configured to go to the details page.
2. On the site details page, click Origin Settings > Load Balancing.
3. On the Load Balancing page, click Create Instance.

4. Proceed to step 1 of choosing the origin. You need to fill in the instance name, choose the instance type, and add an origin group.
Taking this scenario as an example, add the origin group primary_origins as a priority 1 origin group, add the origin group backup_origins as a priority 2 origin group, and click Next.

Parameter
Description
Instance name
Limit to 1-200 characters in length. Allowed characters are a-z, A-Z, 0-9, _, -.
Instance type
HTTP-specific Type: Supports adding both HTTP-specific and general origin groups. It is only applicable for reference by site acceleration-related services, such as domain services and rule engines.
General Type: Only supports adding general origin groups. It is applicable for site acceleration services including domain services and rule engines, and reference by L4 proxy service.
Add origin group
In the CLB instance, the smallest configuration dimension for an origin is the origin group. You need to configure the origin into an origin group and add it here. For more details, see Origin Group Configuration.
You can set priorities for the added origin groups. Traffic will not be directed to origins in lower-priority origin groups if there are healthy origins in higher-priority origin groups. Up to 10 origin groups can be configured, with lower numbers indicating higher priorities.
5. Proceed to step 2 of health check policy. It supports four types of probes: ICMP Ping, HTTPS/HTTP, TCP, and UDP. Tencent Cloud EdgeOne will actively send probe requests to your origin to check its latency and health status. You can choose the appropriate probe frequency based on the load condition of your origin. Here, choose ICMP Ping as the probe policy. For a detailed introduction to probe policy configuration, see Introduction to Health Check Policy. After configuration is completed, click Next.

Note:
If you do not want EdgeOne's nodes to initiate any probe requests to origins, you can choose Not Enabled. In this case, the Load Balancing instance will default to traffic scheduling based on the priority order of the origin groups from step 1. If a request to a particular origin fails 5 times within 60 seconds, the corresponding origin will be disabled for 10 minutes according to the default policy.
Using this policy will not be able to disable the origin of the failure in advance, and it will not be able to automatically and quickly recover the traffic scheduling after the origin returns to normal. Compared with enabling active probe, using this policy may cause you to encounter more failed requests during the origin failure period. Therefore, if you want your business to have higher availability, it is recommended that you enable active probe.
6. Proceed to step 3 of traffic scheduling policy. The current traffic scheduling policy defaults to failover based on the priority order according to the results of active probes. When real business requests fail to retrieve content from the origin during the backsource process, support for request retry is available. There are two request retry policies available. For details, see Introduction to Request Retry Policy.
Policy 1: When a real business request fails to access a certain origin, it directly retries with another origin within the next lower priority origin group. This is suitable for scenarios where the performance of both origin group 1 and origin group 2 is similar.
Policy 2: When a real business request fails to access a certain origin, it directly retries with another origin within the same priority origin group. This is suitable for scenarios where the performance of origin group 1 is significantly better than that of origin group 2.

7. Taking this sample scenario as an example, policy 2 can be chosen. Click Complete to finish creating the instance.