LinkedIn开源Cruise Control：一个Kafka集群自动化运维新利器

 

http://www.infoq.com/cn/news/2017/09/LinkedIn-open-Cruise-Control-Kaf

Kafka近年来日渐流行，LinkedIn的1800台Kafka服务器天天处理2万亿个消息。虽然说Kafka运行得十分稳定，但要大规模运行Kafka，在运维方面仍然面临巨大的挑战。天天都会有broker崩溃，致使集群工做负载不均衡。SRE团队须要花费大量的时间和精力来重分配分区，以便让集群从新恢复均衡。

自动化所以变得十分重要，这也就是为何咱们要开发Cruise Control：持续监控Kafka集群，自动调整分配给服务器的资源，达到预期的性能目标。用户设定目标，Cruise Control对集群的工做负载进行分析，并自动执行一些操做来达成目标。

Cruise Control即日起在GitHub上开源。在这篇文章里，咱们将介绍Cruise Control的使用场景、它的架构以及咱们在开发Cruise Control过程当中面临的挑战。

设计目标

• 可靠的自动化： Cruise Control要准确地分析集群的工做负载，生成无需人工介入的执行计划。
• 资源有效性： Cruise Control要智能地执行操做，不会影响集群处理正常的工做负载。
• 可扩展性： Kafka用户对可用性和性能会有不一样的需求，还可能使用各类不一样的部署工具、管理端点和度量指标收集机制。Cruise Control必须可以知足用户定义的各类目标，并执行用户定义的操做。
• 通用性：尽管不少现有的产品能够用于均衡集群的资源，但它们大部分都与应用程序毫无关联，须要经过迁移整个应用进程来恢复均衡。这类产品对于无状态的系统来讲是没有问题的，但对于有状态的系统来讲就会显得有点力不从心，由于这类系统的不少状态与应用进程相关联。所以，咱们但愿Cruise Control会是一个可以了解应用程序的通用性框架，在恢复均衡时只须要进行一小部分状态迁移。

Cruise Control在LinkedIn的应用

Cruise Control在LinkedIn主要解决如下几个问题。

1. 保证Kafka集群资源的均衡：磁盘、网络和CPU。
2. 若是有broker崩溃，自动将副本从新分配给其余broker，并重置复制系数。
3. 识别出消耗资源最多的主题分区。
4. 在扩展集群或broker退役时只须要少许的人工介入。
5. 支持异构的Kafka集群以及单台主机部署多个broker实例。

Cruise Control的工做原理

Cruise Control遵循的是“监控——分析——行动”这样的工做流程。下图是Cruise Control的架构图。大部分组件都是可插拔的，如度量指标取样器（metric sampler）、分析器（analyzer）等。

REST API

Cruise Control为用户提供了一组REST API，能够用于查询Kafka集群的工做负载状况或触发管理操做。

负载监控器

负载监控器从集群收集Kafka的度量指标和每一个分区的资源度量指标，并生成集群工做负载模型，包括磁盘使用状况、CPU使用状况、流量流入速率、流量流出速率等，而后把模型发送给探测器和分析器。

分析器

分析器是Cruise Control的“大脑”，它根据用户提供的优化目标和来自负载监控器的工做负载模型来生成优化计划。用户能够配置优化计划的优先级，还能够分别设定硬性目标和软性目标。硬性目标是指必须达成的目标（例如必须根据机架来分配副本的位置），软性目标是指在优先知足硬性目标的前提下有可能得不到知足的目标。

硬性目标

1. 根据机架来安排副本的位置，即同一个分区的副本必须被放在不一样的机架上，这样能够减小硬件崩溃给Kafka集群带来不利的影响。
2. broker的资源使用必须处在预约义的阈值内。
3. 网络使用不能超过预约义的容量。若是一个broker的全部副本都成为首领，那么全部的消费者流量都会被重定向到这个broker上，致使网络流量膨胀。

软性目标

1. 让集群全部的broker使用相同的资源。
2. 让全部broker的首领分区达到相同的流量流入速率。
3. 让主题的分区均匀地分布在全部broker上。
4. 在全部broker上均匀地分布分区副本。

探测器

探测器主要用于探测两种类型的异常。

1. broker失效：好比一个非空闲的broker离开集群，致使分区不一样步。由于这种状况在集群正常重置时也会发生，因此探测器在触发告警以前会预留一段时间，若是不是正常重置，就会触发告警并进行修复。
2. 偏离目标：若是启用了自愈功能，Cruise Control会尝试经过分析工做负载并执行优化计划解决问题。

执行器

执行器负责执行由分析器生成的优化计划。Kafka集群的再均衡一般会涉及从新分配分区，执行器要对资源保持感知，避免拖垮broker。分区重分配可能须要很长时间，一个大型的集群可能须要几天时间才能完成一次分区重分配。有时候，用户但愿可以中止正在进行的分区重分配，因此执行器须要确保可以安全地中断执行计划。

有趣的挑战

在开发和使用Cruise Control时，咱们遇到了不少有意思的挑战。

为Kafka构建可靠的集群工做负载模型

这个比看上去的要可贵多，须要考虑到不少细节。例如，从broker上收集CPU度量指标是很容易的，但咱们该如何量化每一个分区的CPU使用状况？这个Wiki页对这个问题进行了解释。

大家愿意花多少时间在一个优化计划上？

分析器组件经历了一个漫长的演化过程。咱们最开始使用了一个具备复杂配置功能的通用优化器，它须要几周的时间才能获得一个中型Kafka集群的优化计划。后来，咱们改用如今的优化器，能够在几分钟以内获得一个较好的结果。

内存与速度的权衡

Cruise Control是一个内存密集型的应用，由于它须要在内存里保存度量指标一段时间，以便分析流量模式。同时，它也是一个CPU密集型的应用，由于它须要大量的计算来生成优化计划。这二者之间存在冲突关系。为了加快生成优化计划，咱们须要缓存更多的数据，进行更多的并行计算，但这样会使用更多的内存。咱们须要在这二者之间作出权衡。例如，咱们会预计算优化计划并缓存起来，当用户发起查询时就不须要等待那么长时间。另外，咱们会交错执行内存密集型的任务，避免同时消耗大量内存。

将来的工做

更多的集群优化目标

Cruise Control的优化组件是可插拔的，用户有可能会根据实际须要提出各类复杂的优化目标。做为一个开源项目，咱们鼓励用户建立本身的优化目标，并把它们贡献给社区。

与云管理系统集成

目前，Cruise Control经过移动失效broker的分区让集群保持正常运行。咱们但愿后续可以与云管理系统集成起来，实现自动集群扩展，或者使用空闲实例替换失效的broker实例。

加强运维洞见

Cruise Control分析从Kafka收集而来的度量指标，帮助SRE团队量化各类资源度量指标的影响程度，提高容量规划和性能调优的能力。

通用性

咱们在开发Cruise Control时就意识到动态负载均衡器对于分布式系统来讲是很是重要的。用于聚合度量指标、分析资源使用状况、生成优化计划的Cruise Control组件一样适用于其余分布式系统。从长远来看，咱们想把这些核心组件抽象出来，用在其余的项目上。