Pulsar 负载均衡设计

Posted StreamNative

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Pulsar 负载均衡设计相关的知识,希望对你有一定的参考价值。

作者 | 狂野

编辑 | Irene

导读:本文介绍了 Pulsar 负载均衡相关的概念,以及 Pulsar 负载的分配管理原理。

Pulsar 定位为云级别可伸缩的消息系统解决方案,其核心设计在于逻辑集群能够尽可能的把负载(traffic)均匀分布在各个可用的 Broker 上。

 

在大多数情况下,Pulsar 是开箱即用的,不必过多关注配置。 然而,即使这样,Pulsar 有多种参数设置和管理工具可以控制负载分配,下面我们一起来了解 Pulsar 中负载是怎么分配管理的。



 动态分配 Topic 到 Broker 上


基于 Broker 集群负载状况,Topic 将动态分配到 Broker 上。当客户端创建新的还没有分配到任何 Broker 的 Topic 时,会触发一个动作:在给定负载条件的情况下,它将选择最适合的 Broker 来作为新 Topic 的所有者。

 

当然,对于 Partition Topic,不同的 Partition 可能被分配到不同的 Broker 上。注意,这里谈论的 Topic 是无分区的 Topic 或者 Partition Topic 中的一个 Partition。

 

分配是“动态的”,因为变更非常快速。例如:如果拥有该 Topic 的 Broker 宕机了,或者拥有该 Topic 的 Broker 负载过大,则该 Topic 将立即重新分配给另一个 Broker 。 在这种情况下,该 Topic 也将重新分配给负载较低的 Broker 。Broker 的无状态特性使得动态分配成为可能, 这也确保根据实际使用情况可以快速扩容或缩容(可伸缩)。


分配粒度


对于要分配到 Broker 上的 Topic/Partition 来说,它不是在自身(Topic/Partition)的级别上进行分配的,而是在更高一层的级别 Bundle 上进行分配,这样做是为了减少元数据的信息。通过对系统 CPU、内存、网络负载等指标数据采集,然后根据指标数据把 Topic 动态分配到特定的 Broker 上(负载均衡)。


每个 Broker 都拥有 Namespace(命名空间)下 Topic 的子集,而不是单独的 Topic/Partition 分区分配。 这个子集称为“ Bundle ”(下文详解),实际上它是一个分片机制。Namespace 是“管理”单元:许多配置开关或操作在命名空间级别完成。


对于分配,Namespace 被分片为 Bundles 列表,每个 Bundle 包含 Namespace 的整个哈希范围的一部分。通过计算 Topic 的哈希码来确定把 Topic 分配给特定的 Bundle 。每个 Bundle 都是互相独立的,被分配到不同的 Broker 上。


创建 Namespace 和 Bundle


当创建新的 Namespace 时,需要在 conf/broker.conf 文件中设置 Bundle  的数量。


#创建命名空间时若没有设置 bundle 数量,这个值为 bundle 的默认数量

defaultNumberOfNamespaceBundles=4

当然,也能改变系统默认值,创建新 Namespace 时,可以用如下命令覆盖:

bin/pulsar-admin namespaces create my-tenant/my-namespace --clusters us-west --bundles 16

用这命令,可以创建有16个 Bundle 的 Namespace 。因此,此 Namespace 的 Topic 最多可以立即分布在16个 bundle 中。一般的,如果预先知道系统将要承载的负载和 Topic 数量,最佳实践是设置一个合理数量的 Bundle 而不是将来等待系统自动变更分片。


同样,系统投入使用时,Bundle 数量比 Broker 数量多通常是有益的。主要因为 Topic 分配到 Bundle 中的哈希散列特性。 例如,对于具有1000个 Topic 的 Namespace,使用64个 Bundle 在16个 Broker 中就能实现良好的负载分配。


卸载 Topic 和 Bundle 的关系


Pulsar 中有一个 卸载 Topic 的管理命令,卸载意味着关闭 Topic,释放所有者,然后基于当前负载,重新把 Topic 分配到新的 Broker 上。

 

发生卸载时,客户端将经历有极小的延迟抖动,通常耗时10ms左右,与此同时,Topic 将被重新分配到新的 Broker 上。卸载是负载管理器用于执行减载的机制,也可以手动触发,例如,即使在任何 Broker 超载之前,也要变更分配并重新分配负载。


卸载 Topic 对于分配来讲没有影响,仅仅是关闭和重新打开此 Topic:

pulsar-admin topics unload persistent://tenant/namespace/topic

卸载 Namespace 下所有的 Topic 触发重分配:

pulsar-admin namespaces unload tenant/namespace


Namespace Bundles 拆分


由于 Bundle 中 Topic 的负载可能随着时间的推移发生变化,也很难预先预测到,因此 Bundle 可以由 Broker 分成 2 个。 然后将新的较小的 Bundle 重新分配给不同的 Broker 。


拆分发生在可调节的阈值上。 超过阈值的 Bundle 会成为候选 Bundle 被拆分。 默认情况下,新拆分的 Bundle 也会立即卸载(分配到)到其他负载较低的 Broker,以促进负载均衡。


#启用/禁用自动拆分 Namespace Bundle

loadBalancerAutoBundleSplitEnabled=true

#启用/禁用自动卸载拆分 Bundle

loadBalancerAutoUnloadSplitBundlesEnabled=true

#Bundle 中 topic 最多为1000,超过会触发拆分 bundle

loadBalancerNamespaceBundleMaxTopics=1000 

#Bundle 中会话数最多(包括生产者和消费者)为1000,超过会触发拆分 Bundle

loadBalancerNamespaceBundleMaxSessions=1000

#Bundle 中消息数最多为 30000(包括输入和输出),超过会触发拆分 Bundle

loadBalancerNamespaceBundleMaxMsgRate=30000

#Bundle 中宽带最大为 100M(包括扇入和扇出),超过会触发拆分 Bundle

loadBalancerNamespaceBundleMaxBandwidthMbytes=100

#Namespace 中 Bundle 数量最大为128,超过则自动拆分

loadBalancerNamespaceMaximumBundles=128


(负载高)自动减少负载


Broker 超载时,Pulsar 负载均衡管理器支持自动降低负载。也就是说,当系统认为 broker 过载时,它将强制一部分负载分流到其他负载较低的 broker 上。


当负载管理器判断 broker 超载时,broker 会被强制卸载到具有较高负载的 bundle 子集,以降低其负载。


例如,默认阈值为85%,如果 broker 超过 CPU 使用率95%配额,将卸载这中间的差额并加上5%的余量:(95% - 85%) + 5% = 15%。


考虑到选择要卸载的 bundle 基于流量(作为 CPU,网络,内存计算代理),broker 将卸载 bundle 至少15%的负载。默认情况下,启用自动减少负载;如果要禁用,可以采用如下方式:


#启用/禁用自动 bundle 卸载

loadBalancerSheddingEnabled=true

还有2个 shedding 参数如下:

#负载 shedding 间隔。broker 会周期性的检查是否把负载从超载的 broker 分配到负载低的 broker 上去。

loadBalancerSheddingIntervalMinutes=1


#在此时间范围内,防止相同的 topic 被移除并转移到其他 broker 上。

loadBalancerSheddingGracePeriodMinutes=30


broker 超载阈值


决定 broker 何时负载超载是基于 CPU 、网络和内存指标阈值。无论什么时候这指标达到阈值时,将触发一个减负动作(如果启用)

决定 broker 是否负载超载是基于 CPU 、网络和内存指标阈值。无论这些指标中任意一个达到阈值时,都会触发减负动作(如果启用)。


负载阈值默认为 85%:

loadBalancerBrokerOverloadedThresholdPercentage=85

Pulsar 从系统指标收集使用情况统计信息。在某些情况下,Linux 报告的网络接口速度不正确,需要人工设置网络带宽值。 在具有1Gbps NIC 速度的 AWS EC2 实例中就是这种情况,OS 报告10 Gbps 的速度。

 

由于最大速度不正确,Pulsar 负载管理器可能认为代理尚未达到 NIC 容量,而实际上它已经在使用所有带宽并且流量正在减慢。

 

可以通过以下设置修正最大 NIC 速度:

loadBalancerOverrideBrokerNicSpeedGbps=

当这个值为空时,Pulsar 将用 OS 报告的值。


以上是关于Pulsar 负载均衡设计的主要内容,如果未能解决你的问题,请参考以下文章

架构设计:负载均衡层设计方案之负载均衡技术总结篇

服务负载均衡系统设计与实践

架构设计笔记_10_关键模式_负载均衡

架构设计笔记_10_关键模式_负载均衡

架构设计:负载均衡层设计方案——负载场景和解决方式

架构系列十(负载均衡组件设计实现思考)