Skip to main content
Version: 4.0.x

Broker load balancer

If you want to develop a broker load balancer, check out the following docs.

Pulsar has the following types of load managers:

  • Simple load manager, implemented in SimpleLoadManagerImpl, which attempts to simplify how the load is managed while also providing abstractions so that complex load management strategies may be implemented.

  • Modular load manager, implemented in ModularLoadManagerImpl, which is a flexible alternative to the SimpleLoadManagerImpl.

  • Extensible load manager, implemented in ExtensibleLoadManagerImpl, which is dependent on system topics and table views for load balance metadata store and replication.

Concepts​

Before starting the impelemtation, make sure you understand the following basics.

note

The following concepts are only availabe for the modular load manager.

Data​

The data monitored by the modular load manager is contained in the LoadData class. Here, the available data is subdivided into the bundle data and the broker data.

Broker​

The broker data is contained in the BrokerData class. It is further subdivided into two parts, one being the local data that every broker individually writes to ZooKeeper, and the other being the historical broker data that is written to ZooKeeper by the leader broker.

Lead broker​

The module load manager is centralized, meaning that all requests to assign a bundle---whether it's been seen before or whether this is the first time---only get handled by the lead broker (which can change over time). To determine the current lead broker, examine the /loadbalance/leader node in ZooKeeper.

Local broker data​

The local broker data is contained in the class LocalBrokerData and provides information about the following resources:

  • CPU usage
  • JVM heap memory usage
  • Direct memory usage
  • Bandwidth in/out usage
  • Most recent total message rate in/out across all bundles
  • Total number of topics, bundles, producers, and consumers
  • Names of all bundles assigned to this broker
  • Most recent changes in bundle assignments for this broker

The local broker data is updated periodically according to the service configuration "loadBalancerReportUpdateMaxIntervalMinutes". After any broker updates their local broker data, the leader broker will receive the update immediately via a ZooKeeper watch, where the local data is read from the ZooKeeper node /loadbalance/brokers/<broker host/port>

Historical broker data​

The historical broker data is contained in the TimeAverageBrokerData class.

To reconcile the need to make good decisions in a steady-state scenario and make reactive decisions in a critical scenario, the historical data is split into two parts: the short-term data for reactive decisions, and the long-term data for steady-state decisions. Both time frames maintain the following information:

  • Message rate in/out for the entire broker
  • Message throughput in/out for the entire broker

Unlike the bundle data, the broker data does not maintain samples for the global broker message rates and throughputs, which is not expected to remain steady as new bundles are removed or added. Instead, this data is aggregated over the short-term and long-term data for the bundles. See the section on bundle data to understand how that data is collected and maintained.

The historical broker data is updated for each broker in memory by the leader broker whenever any broker writes their local data to ZooKeeper. Then, the historical data is written to ZooKeeper by the leader broker periodically according to the configuration loadBalancerResourceQuotaUpdateIntervalMinutes.

Bundle data​

The bundle data is contained in the BundleData. Like the historical broker data, the bundle data is split into a short-term and long-term time frame. The information maintained in each time frame:

  • Message rate in/out for this bundle
  • Message Throughput In/Out for this bundle
  • Current number of samples for this bundle

The time frames are implemented by maintaining the average of these values over a set, a limited number of samples, where the samples are obtained through the message rate and throughput values in the local data. Thus, if the update interval for the local data is 2 minutes, the number of short samples is 10 and the number of long samples is 1000, the short-term data is maintained over a period of 10 samples * 2 minutes / sample = 20 minutes, while the long-term data is similarly over a period of 2000 minutes. Whenever there are not enough samples to satisfy a given time frame, the average is taken only over the existing samples. When no samples are available, default values are assumed until they are overwritten by the first sample. Currently, the default values are

  • Message rate in/out: 50 messages per second both ways
  • Message throughput in/out: 50KB per second both ways

The bundle data is updated in memory on the leader broker whenever any broker writes their local data to ZooKeeper. Then, the bundle data is written to ZooKeeper by the leader broker periodically at the same time as the historical broker data, according to the configuration loadBalancerResourceQuotaUpdateIntervalMinutes.

Traffic distribution​

The modular load manager uses the abstraction provided by ModularLoadManagerStrategy to make decisions about bundle assignments. The strategy makes a decision by considering the service configuration, the entire load data, and the bundle data for the bundle to be assigned. Currently, the only supported strategy is LeastLongTermMessageRate, though soon users will have the ability to inject their own strategies if desired.

Least long term message rate strategy​

As its name suggests, the least long-term message rate strategy attempts to distribute bundles across brokers so that the message rate in the long-term time window for each broker is roughly the same. However, simply balancing load based on message rate does not handle the issue of asymmetric resource burden per message on each broker. Thus, the system resource usages, which are CPU, memory, direct memory, bandwidth in, and bandwidth out, are also considered in the assignment process. This is done by weighting the final message rate according to 1 / (overload_threshold - max_usage), where overload_threshold corresponds to the configuration loadBalancerBrokerOverloadedThresholdPercentage and max_usage is the maximum proportion among the system resources that are being utilized by the candidate broker. This multiplier ensures that machines with are being more heavily taxed by the same message rates will receive less load. In particular, it tries to ensure that if one machine is overloaded, then all machines are approximately overloaded. In the case in which a broker's max usage exceeds the overload threshold, that broker is not considered for bundle assignment. If all brokers are overloaded, the bundle is randomly assigned.

Enablement​

You can enable a simple, modular, or extensible load manager by following the steps below.

note

For simple and modular load managers:

  • Any mistakes in specifying the load manager will cause Pulsar to default to SimpleLoadManagerImpl.

  • If you do not specify load manager, the default load manager (ModularLoadManagerImpl) is used.

Enable simple load manager​

You can enable the simple load manager using one of the following methods:

  • Method 1

    Update the value of loadManagerClassName to org.apache.pulsar.broker.loadbalance.impl.SimpleLoadManagerImpl in conf/broker.conf.

  • Method 2

    Use the pulsar-admin tool.

    pulsar-admin brokers update-dynamic-config \
    --config loadManagerClassName \
    --value org.apache.pulsar.broker.loadbalance.impl.SimpleLoadManagerImpl

Enable modular load manager​

You can enable the modular load manager using one of the following methods:

  • Method 1

    Update the value of loadManagerClassName to org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl in conf/broker.conf.

  • Method 2

    Use the pulsar-admin tool.

    pulsar-admin brokers update-dynamic-config \
    --config loadManagerClassName \
    --value org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl

Enable extensible load manager​

You can enable the extensible load manager by updating the value of loadManagerClassName to org.apache.pulsar.broker.loadbalance.extensions.ExtensibleLoadManagerImpl in conf/broker.conf.

note

The pulsar-admin tool is not supported for enabling the extensible load manager.

Verification​

If you want to verify which load manager is used, follow the steps below.

Step 1: check loadManagerClassName​

You can use the pulsar-admin tool to examine the loadManagerClassName element.

Input

bin/pulsar-admin brokers get-all-dynamic-config

Output

{
"loadManagerClassName" : "org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl"
}

If there is no loadManagerClassName element, then the value of loadManagerClassName in the conf/broker.conf file is used.

Step 2: verify load manager (optional)​

To double-check which load manager is used, you can check the ZooKeeper load report or check monitor-brokers output.

Method 1: check load report​

Different load managers have different load reports. You can verify which load manager is used based on the output.

You can check ZooKeeper load reports.

  1. Connect to ZooKeeper.

    Input

    bin/pulsar zookeeper-shell -server zookeeper:2181

    Output

    Connecting to zookeeper:2181
    2023-08-02T12:48:58,655+0000 [main] INFO  org.apache.zookeeper.ZooKeeper - Client environment:zookeeper.version=3.8.1-74db005175a4ec545697012f9069cb9dcc8cdda7, built on 2023-01-25 16:31 UTC
    2023-08-02T12:48:58,662+0000 [main] INFO  org.apache.zookeeper.ZooKeeper - Client environment:host.name=broker-1
    2023-08-02T12:48:58,662+0000 [main] INFO  org.apache.zookeeper.ZooKeeper - Client environment:java.version=17.0.7
    2023-08-02T12:48:58,662+0000 [main] INFO  org.apache.zookeeper.ZooKeeper - Client environment:java.vendor=Eclipse Adoptium
    2023-08-02T12:48:58,662+0000 [main] INFO  org.apache.zookeeper.ZooKeeper - Client environment:java.home=/usr/lib/jvm/temurin-17-jdk-amd64

  2. List all brokers.

    Input

    ls /loadbalance/brokers

    Output

    This output shows that there are 2 brokers.

    [broker-1:8080, broker-2:8080]

  3. Check ZooKeeper load report for broker 1. The load report in /loadbalance/brokers/....

    Input

    get /loadbalance/brokers/broker-1:8080

    Output

    {"name":"broker-1:8080","brokerVersionString":"3.1.0-SNAPSHOT","webServiceUrl":"http://broker-1:8080","pulsarServiceUrl":"pulsar://broker-1:6650","persistentTopicsEnabled":true,"nonPersistentTopicsEnabled":true,"timestamp":1691042931108,"msgRateIn":0.0,"msgRateOut":0.0,"numTopics":0,"numConsumers":0,"numProducers":0,"numBundles":0,"protocols":{},"loadManagerClassName":"org.apache.pulsar.broker.loadbalance.impl.SimpleLoadManagerImpl","startTimestamp":1691042931108,"systemResourceUsage":{"bandwidthIn":{"usage":0.595387281695773,"limit":1.0E7},"bandwidthOut":{"usage":0.5799226769764033,"limit":1.0E7},"cpu":{"usage":6.224803359552059,"limit":800.0},"memory":{"usage":152.0,"limit":2096.0},"directMemory":{"usage":0.0,"limit":256.0}},"bundleStats":{},"bundleGains":[],"bundleLosses":[],"allocatedCPU":0.0,"allocatedMemory":0.0,"allocatedBandwidthIn":0.0,"allocatedBandwidthOut":0.0,"allocatedMsgRateIn":0.0,"allocatedMsgRateOut":0.0,"preAllocatedCPU":0.0,"preAllocatedMemory":0.0,"preAllocatedBandwidthIn":0.0,"preAllocatedBandwidthOut":0.0,"preAllocatedMsgRateIn":0.0,"preAllocatedMsgRateOut":0.0,"underLoaded":true,"overLoaded":false,"loadReportType":"LoadReport","msgThroughputIn":0.0,"msgThroughputOut":0.0,"bandwidthIn":{"usage":0.595387281695773,"limit":1.0E7},"bandwidthOut":{"usage":0.5799226769764033,"limit":1.0E7},"memory":{"usage":152.0,"limit":2096.0},"cpu":{"usage":6.224803359552059,"limit":800.0},"directMemory":{"usage":0.0,"limit":256.0},"lastUpdate":1691042931108}

Method 2: check monitor-brokers output​

You can use the pulsar-perf tool to start a broker monitor.

Different load managers have different outputs. This output is the same as the output of the Method 1: check ZooKeeper load report, but it is well formatted for better readability.

Input

pulsar-perf monitor-brokers --connect-string <zookeeper host:port>

**Output**

```bash
===================================================================================================================
||COUNT          |TOPIC          |BUNDLE         |PRODUCER       |CONSUMER       |BUNDLE +       |BUNDLE -       ||
||               |4              |4              |0              |2              |0              |0              ||
||RAW SYSTEM     |CPU %          |MEMORY %       |DIRECT %       |BW IN %        |BW OUT %       |MAX %          ||
||               |0.25           |47.94          |0.01           |0.00           |0.00           |47.94          ||
||ALLOC SYSTEM   |CPU %          |MEMORY %       |DIRECT %       |BW IN %        |BW OUT %       |MAX %          ||
||               |0.20           |1.89           |               |1.27           |3.21           |3.21           ||
||RAW MSG        |MSG/S IN       |MSG/S OUT      |TOTAL          |KB/S IN        |KB/S OUT       |TOTAL          ||
||               |0.00           |0.00           |0.00           |0.01           |0.01           |0.01           ||
||ALLOC MSG      |MSG/S IN       |MSG/S OUT      |TOTAL          |KB/S IN        |KB/S OUT       |TOTAL          ||
||               |54.84          |134.48         |189.31         |126.54         |320.96         |447.50         ||
===================================================================================================================
Was this helpful?
💡 Suggest changes🛟 Get support