前言: 在kafka的集群运维操作过程中,我们需要通过一些工具来实现集群的高可用以及负载的平均操作,而对于kafka集群的SRE来说,需要掌握好如下几点,才能更好的维护和保证kafka集群服务的稳定性,可靠性和整体性能。
要想kafka跑的好,如下几点要知晓。
Graceful shutdown
建议开启如下参数:
|
|
注意:
只有在broker上承载的分区都具有副本时(副本大于1,且副本存活),controller节点才会成功关闭
Balancing leadership
每当Broker停止或崩溃时,该broker的分区的领导权就转移到其他副本。
这意味着,默认情况下,当broker重新启动时,它将只是所有分区的关注者,这意味着它不会用于客户端读写,这对于整个集群来说吞吐会受到1/N的降低(N表示集群节点数)
为了避免这种不平衡,kafka提供了一种优先副本的概念preferred replicas
.
如果一个分区的副本列表是1、5、9,那么节点1比节点5或节点9更适合作为leader,因为它位于副本列表的前面。
可以使用如下命令来恢复已恢复副本的领导权:
|
|
当然每次在服务器启动后执行该操作,可能很无聊,因此可以设置如下参数来自动执行:
|
|
Balancing Replicas Across Racks
机架层面的副本均衡。
机架感知特性将相同分区的副本分散到不同的机架上,这扩展了Kafka为broker失败提供的覆盖机架失败的保证,如果机架上的所有broker同时失败,就限制了数据丢失的风险。
该特性还可以应用于其他broker分组,如EC2中的可用性区域。
您可以通过向broker配置添加属性来指定broker属于特定的机架:
|
|
当创建、修改或重新分发一个主题时,将遵循机架约束,确保副本尽可能多地跨越多个机架(一个分区将跨越最小(#机架,复制因子)不同的机架)。
用于将副本副本分配给broker的算法,会确保每个broker的leader数量是恒定的,而不管broker是如何分布在机架上的。这确保了平衡的吞吐量。
注意:
明智的做法是为每个机架配置相同数量的broker
Mirroring data between clusters
我们将在Kafka集群之间复制数据的过程称为“镜像”,以避免与单个集群中节点之间的复制混淆。
Kafka附带一个用于在Kafka集群之间镜像数据的工具,即MirrorMaker
,该工具可以从源集群进行消费,并生产到目标集群。
常用的场景就是在另外一个数据中心提供副本。
您可以运行许多这样的镜像进程来提高吞吐量和容错能力。
使用mirrormaker进行迁移topic到另外的集群:
|
|
需要注意,我们必须使用--whitelist
参数指定topic,该参数支持java的正则表达式结构,比如--whitelist 'A|B'
,或者--whitelist '*'
.
通常在使用kafka-mirror-maker时,建议配合auto.create.topics.enable=true
使用,可以大批量的进行topic迁移。
Checking consumer position
检查消费者的位移,有时候了解消费者当前的位置时很有必要的。
kafka有一个工具,它将显示所有消费者在一个消费者组中的位置,以及他们与日志结束的距离
|
|
Managing Consumer Groups
ConsumerGroupCommand工具可以list, describe, or delete
一个消费组,消费者组可以手动删除,也可以在该组最后提交的偏移量过期时自动删除。
只有在组中没有任何活动成员时,手动删除才有效。
如下命令可以列出所有主题的所有消费者组:
|
|
查看指定消费者组
|
|
当然可用试用一些额外的参数来查看更多的消费者信息:
- –members: 查看消费者组中活跃的消费者
- –members –verbose: 该参数还可以查看分配给每个成员的分区
- –offsets: 该参数实际上可以被
--describe
参数中的内容覆盖掉 - –state: 该参数可以提供组级别的信息
- –delete: 该参数可以手动删除一个或多个消费者组
- -reset-offsets: 该参数用于重置消费者组的偏移量,此选项在同一时间支持一个消费者组,同时需要使用
--all-topics或--topic
指定范围
|
|
注意:
--reset-offsets
选项支持如下三个执行选项:
- 显示要重置的偏移量
- –execute: 执行
--reset-offsets
进程 - –export: 以csv格式导出执行结果
--reset-offsets
参数还有如下方案可供选择:
- –to-datetime: 重置offset到另外一个offset (format:YYYY-MM-DDTHH:mm:SS.sss)
- –to-earliest: 重置offset到最早的offset
- –to-latest: 重置为最新的offset
- –shift-by: 重置offset为n
- –from-file: 重置到csv中定义的offset
- –to-current: 重置offset到当前
- –by-duration: 重置offset为当前时间( Format: ‘PnDTnHnMnS’)
- –to-offset: 重置offset为指定的值
|
|
如果你还是使用老的high-level
消费者,并且将组的元数据存储在zk中(offsets.storage=zookeeper
),可以使用--zookeeper
来代替bootstrap-server
参数:
|
|
Expanding your cluster
集群的扩展.
将服务器添加到Kafka集群很容易,只需为它们分配一个惟一的brokerid,并在新服务器上启动Kafka.
然而,这些新服务器不会自动分配任何数据分区,因此,除非将分区移动到它们,否则在创建新主题之前,它们不会做任何工作。
因此,通常在向集群中添加机器时,您会希望将一些现有数据迁移到这些机器上。
迁移数据的过程是手动启动的,但是完全自动化。
实际上,Kafka将添加新服务器作为它正在迁移的分区的追随者,并允许它完全复制该分区中的现有数据。
当新服务器完全复制了该分区的内容并加入同步副本时,现有副本中的一个将删除其分区的数据。
可以使用分区重新分配工具在broker之间移动分区。
理想的分区分布应该确保所有broker之间的数据负载和分区大小是一致的。
分区重新分配工具不具备自动研究Kafka集群中的数据分布并移动分区以获得均匀的负载分布的能力,因此,管理员必须确定应该移动哪些主题或分区。
分区迁移工具可以运行在三种互斥模式下:
--generate
: 给定主题列表和broker列表,该工具生成一个候选重新分配,将指定主题的所有分区移动到新的broker,该参数仅帮助管理员方便的来生成给定主题和目标broker列表的分区重新分配计划--execute
: 该工具根据用户提供的重新分配计划开始重新分配分区(使用--reassignment-json-file
指定生成的迁移配置),---verify
: 该工具将验证列出的所有分区的重新分配状态,可以是成功完成、失败或正在进行
1.自动迁移数据到新的服务器
分区重新分配工具可用于将某些主题从当前broker集移到新添加的broker。 这在扩展现有集群时通常很有用,因为与一次移动一个分区相比,将整个主题移至新的broker集更容易。 用于执行此操作时,用户应提供应移至新的一组broker的主题列表和新broker的目标列表。 然后,该工具将给定主题列表中的所有分区平均分配到新的一组broker中。 在此过程中,主题的复制因子保持不变。 有效地,将输入主题列表的所有分区的副本从旧的broker集移至新添加的broker。
如下示例(topic:foo1和foo2的全部分区移动到broker 5和6上,迁移完成后,该topic的全部分区将在Broker5和6上):
|
|
2.自定义分区分配和迁移
分区重分配工具还可以用于有选择地将分区的副本移动到一组特定的broker。
当我们以这种方式使用时,假设用户知道重新分配计划,并且不需要该工具来生成候选的重新分配,即直接使用用户的分配策略进行数据迁移。
示例: 迁移topicfoo1
的partition-0到broker5和6,partition-1到broker2和3
|
|
Decommissioning brokers
分区重新分配工具还不能自动生成用于退役broker的重新分配计划,因此,管理员必须制定一个重新分配计划,将托管在代理上的所有分区的副本迁移到代理的其余部分。
这可能比较繁琐,因为重新分配需要确保所有副本不会从已退役的代理移动到另一个代理。为了简化这个过程,我们计划在将来为退役代理添加工具支持。
Increasing replication factor
增加现有分区的复制因子很容易,只需在定制的重新分配json文件中指定额外的副本,并使用—execute选项来增加指定分区的复制因子。
示例: 将主题foo的partition-0的副本从1增加到3。在增加复制因子之前,代理5上只存在分区的副本,作为增加复制因子的一部分,我们将在代理6和代理7上添加更多的副本。
|
|
Limiting Bandwidth Usage during Data Migration
Kafka允许您对复制流量施加限制,设置用于将副本从一台机器移动到另一台机器的带宽上限。
这在重新平衡集群、引导新代理或添加或删除代理时非常有用,因为它限制了这些数据密集型操作对用户的影响
最简单的方式就是在使用kafka-reassign-partitions.sh
脚本时,使用限流功能,不过kafka-configs.sh
脚本也具有该功能。
|
|
查看broker的限流配置:
|
|
这显示了应用于复制协议的leader和follower端上的节流。默认情况下,两边分配相同的节流吞吐量值。
查看限流的副本:
|
|
Setting quotas
配额设置。
|
|
注意
: 在broker的配置中增加如下配置,会默认为全部的生产者和消费者进行配额限制.
|
|