Skip to content

Latest commit

 

History

History
94 lines (60 loc) · 3.66 KB

balance.md

File metadata and controls

94 lines (60 loc) · 3.66 KB

Traffic balancing

Sub cluster level load balance

Overview

  • Usually one cluster has more than one sub clusters. In BFE, it is supported to define weights for distributing traffic to each sub cluster.

  • Also there is a special virtual sub cluster "BLACKHOLE" for each cluster.

    • Traffic allocated to "BLACKHOLE" will be discarded.
    • "BLACKHOLE" is used to prevent traffic overloading to the whole cluster.

  • Load balance between sub clusters, it is a very important feature for BFE. This feature is very useful in multi-IDCs scenario.

Example

  • Consider the following scenario：

    • Two IDCs：IDC_1, IDC_2
    • Two BFE clusters：BFE_1, BFE_2
    • Two backend sub clusters：SubCluster_1, SubCluster_2

  • In BFE clusters, weights for distributing traffic to each sub cluster can be configured as follows:

    • BFE_1：{SubCluster_1: W11，SubCluster_2: W12, Blackhole: W1B}
    • BFE_2：{SubCluster_1: W21，SubCluster_2: W22, Blackhole: W2B}

  • Based on the above configuration, BFE clusters distribute traffic to backend sub clusters.

    • For example，if configuration of BFE_1 is {W11，W12, W1B} ={45，45，10}, traffic percentage to SubCluster_1, SubCluster_2 and Blackhole is 45%, 45% and 10%.

Forwarding Table

Instance level load balance

  • Usually, a sub cluster is composed of multiple instances.
  • Within sub cluster, several policies is provided for distributing traffic among instances. e.g.,
    • WRR(Weighted Round Robin)
    • WLC(Weighted Least Connection)
  • Instances can be assigned with different weights based on their capacity。

Health check

BFE supports health check for each backend instance.

BFE maintains a state machine for each instance, with two states:

  • NORMAL：the instance acts normally in processing request.
  • CHECKING：the instance fails to process request and response to BFE. BFE starts health check for this instance, until it acts normally again.

The condition for switching between states:

  • NORMAL to CHECKING, when：

    • Number of consecutive failures, in connecting or sending request to the instance, exceeds a threshhod.

  • CHECKING to NORMAL, when：

    • BFE receives correct response for health check request from the instance.

Automatic retries

If request forwarding fails, BFE supports retry in two ways：

  • In-Sub-Cluster Retry: Re-forward request within the same sub cluster.
  • Cross-Sub-Cluster Rery: Re-forward request to other sub cluster.

Connection pool

Two ways are supported for TCP connection between BFE and backend instance：

  • Short-Lived Connection：BFE forwards each request to backend instance with a new established TCP connection.

  • Connection Pool：

    • BFE maintains a connection pool for each backend instance.

    • For a request forwarded to given backend instance:

      • If there is an available idle connection in the connection pool, take it from the pool and reuse it.
      • Otherwise, establish a new TCP connection.

    • After processing for a request is finished, for the connection used for this request:

      • If number of idle connections in the pool is less than configured capacity, the connection is added into the pool.
      • Otherwise, close the connection directly.

Session stickiness

BFE supports session stickiness.

Session could be defined based on following infos of the request:

  • Source IP
  • Field in request header, cookie etc.

Session stickiness is supported for the following two levels:

  • Sub cluster level: requests of the same session are forwarded to the same sub cluster (may be different instances in this sub cluster).
  • Instance level: requests of the same session are forwarded to the same instance.