Updated on 2023-12-20 GMT+08:00

Load Balance Channels

Load balance channels expose your services through dedicated gateways. and are accessed through subnets in VPCs for lower latency. They balance the loads of backend services.

After creating a load balance channel, you can configure it for an API of an HTTP/HTTPS backend service.

For example, six ECSs have been deployed, and a load balance channel has been created to reach ECS 01 and ECS 04. In this situation, APIG can access these two ECSs through the channel.

Figure 1 Accessing ECSs in a load balance channel through APIG

Prerequisites

  • You have the VPC Administrator permission.

Creating a Load Balance Channel

  1. Go to the APIG console.
  2. Select a gateway at the top of the navigation pane.
  3. In the navigation pane, choose API Management > API Policies.
  1. Click the Load Balance Channels tab.
  2. Click Create Load Balance Channel and configure basic information.

    Table 1 Basic information

    Parameter

    Description

    Name

    Channel name.

    Port

    The host port of the channel, that is, the port of your backend services.

    Range: 1–65535

    Routing Algorithm

    The algorithm to be used to forward requests to cloud servers you select.

    The following routing algorithms are available:

    • WRR: weighted round robin
    • WLC: weighted least connection
    • SH: source hashing
    • URI hashing

  3. Configure servers.

    Load balance channels support private network load balancers. You can specify server addresses.

    • Select cloud servers
      1. Click Create Server Group.
        In the displayed dialog box, enter server group information and click OK.
        Table 2 Server group parameters

        Parameter

        Description

        Group Name

        Enter a server group name. Using naming rules facilitates future search.

        Weight

        Enter the weight of the server group. The larger the weight, the more requests can be forwarded to the servers in the group.

        Description

        Enter a brief description of the server group.

      2. Click Add Cloud Server.

        In the displayed dialog box, select a subnet, select the cloud servers to be added, and click OK.

      3. After the configuration is complete, configure health check.
    • Specify IP addresses
      1. Click Create Server Group.

        In the displayed dialog box, enter server group information and click OK. Configure parameters according to Table 2.

      2. Click Add Backend Server Address and enter a backend server address.
        Table 3 Backend server parameters

        Parameter

        Description

        Backend Server Address

        Backend server IP address.

        Standby Node

        If you enable this option, the backend server serves as a standby node. It works only when all non-standby nodes are faulty.

        Port

        Access port number of the backend server. If the port number is 0, the port of the load balance channel is used.

        Server Status

        Specify whether to enable the server. Requests are distributed to the server only if it is enabled.

      3. After the configuration is complete, configure health check.

  4. Configure health checks.

    Table 4 Basic information

    Parameter

    Description

    Protocol

    The protocol used to perform health checks on cloud servers associated with the channel. Options:

    • TCP
    • HTTP
    • HTTPS

    Default value: TCP.

    Two-Way Authentication

    Set this parameter only when Protocol is set to HTTPS.

    Determine whether to allow APIG to authenticate the API backend service. For details about how to configure the certificate for two-way authentication, see Procedure.

    Path

    Set this parameter only when Protocol is not set to TCP.

    The destination path for health checks.

    Method

    • GET
    • HEAD

    Check Port

    The destination port for health checks.

    If this parameter is not specified, the port of the load balance channel is used by default.

    Healthy Threshold

    The number of consecutive successful checks required for a cloud server to be considered healthy.

    Range: 2–10. Default value: 2

    Unhealthy Threshold

    The number of consecutive failed checks required for a cloud server to be considered unhealthy.

    Range: 2–10. Default value: 5.

    Timeout (s)

    The timeout used to determine whether a health check has failed. Unit: s.

    Range: 2–30. Default value: 5.

    Interval (s)

    The interval between consecutive checks. Unit: s.

    Range: 5–300. Default value: 10.

    Response Codes

    Set this parameter only when Protocol is not set to TCP.

    The HTTP codes used to check for a successful response from a target.

  5. Click Finish.

Follow-Up Operations

Create APIs to expose backend services deployed in the workload.