前言

监控系统是整个运维环节,乃至整个产品生命周期中最重要的一环。而Open-Falcon是目前业界做的最开放、最好用的互联网企业级监控产品。

Open-Falcon的底层存储,使用RRDTool时间序列数据库。在Transfer & Query模块,使用一致性哈希来对数据做均匀的分片。完美的满足了海量数据的存储以及高效、快速的查询。

然而当存储、IO、或者某一方面资源到达瓶颈的时候,我们的存储组件就需要通过扩容来继续满足使用的压力及需求。 本篇文章就将我们扩容的经验及过程分享给大家。

本文面向对象

1、Open-Falcon老鸟,但是没有经历过存储扩容,准备扩容的人。
2、眼一闭、一睁,啥也没管,就扩容完成了,心里仍然有一点懵逼的人。

方案原理

本篇文章不讨论代码细节,这里对应扩容步骤简单给大家讲下原理。 从修改Transfer开始,流量会按新的哈希规则进入到原始集群和扩容集群;此时扩容集群发现,migrate开关是打开状态;于是,扩容集群接收到流量之后,并没有很着急的去落盘,而是先按照旧的哈希规则从原始集群拉取历史数据(本质上就是一个rrd文件),拉取成功则将整个rrd文件写入本地,若拉取超时(默认1s),则将此次接收到的数据发送给旧的集群,下一个周期会再次重复此过程。

同样的,Query的查询,也是按照新的哈希规则。当查询的流量到达扩容集群,如果Graph发现,本地已有RRD文件,则直接查询返回;如果本地无RRD文件,则Graph会通过旧的哈希规则,去原始集群中拉取到旧数据;然后跟自己cache中的数据做一个聚合,再返回给查询者。

整个过程从技术上来说,可以说是:无损的、可以热迁移。

方案缺陷

整个方案,经过我们测试,比较稳定。但仍有如下缺点:

1、无回滚方案。开弓没有回头箭。一旦扩容失败,会导致扩容期间部分数据丢失。
2、自监控不够完善。官方提供给我们的统计数据,只有迁移的成功、失败的数量等较少几个指标,在扩容过程中,很可能会导致操作者不能完全掌控扩容的详细情况。

扩容前,我们做了哪些准备

在扩容之前,由于此方案容错率较低,可以提前做一些准备,保证第一时间可以发现问题的所在:

补全自监控

【写】Transfer接收点数(实际扩容并不会影响这个数值,主要用于比较)
【写】Transfer转发点数
【写】Graph接收点数
【写】扩容集群Trans数据到老集群点数
【读】Query到Graph查询总次数
【读】Graph转发查询的次数、耗时、错误率
【迁移】迁移的成功个数/成功率,失败个数/失败率,迁移延迟

功能测试

很多公司都对开源版本的Graph进行了一些修改和定制。很可能会对这个过程有影响。 之前笔者公司,对内存进行过优化,存储在内存中的数据格式有所变化。但是migrate时,哈希规则的计算正好依赖此数据。Graph扩容时计算出来的的哈希值,与Transfer不一致,最终导致丢掉了一部分数据。

因此,在真正的扩容前,针对自己的公司Graph版本,进行一个准确性测试,是很有必要的。

压力测试

不同的公司,监控系统会有不同的量级和瓶颈。 一般来讲,监控系统都是写入量大,查询量少。但是笔者所在的公司,由于重构了Judge,改原有的Transfer推送方式为Judge自行拉取。导致查询的量非常大,基本可以达到读写比 1:1的量级。 因此,在真正的扩容之前,进行一个与自己线上环境相符的压力测试,也是很有必要的。

跟大家分享下我们的压测结果:

测试环境:CentOS 7.2
内存:8 * 16G
硬盘:3.2TB Nvme SSD
扩容台数:2台 => 4台
压测过程中:单机持续写入130万点/秒,持续查询100W点/秒

压测结论

压测结论,各项指标正常,各项资源使用并没有明显增加。 concurrency的提高,并没有对扩容效率带来明显的提升。也从侧面说明,此方案,在读写比1:1的情况下,可以完美热扩容。

扩容过程

分批扩容

30台 => 31台 (灰度1台)
31台 => 33台 (再小流量2台)
33台 => 38台 (再中流量5台)
38台 => 50台 (全量)

扩容过程观察的指标

【基础指标】老集群和扩容集群的内存和IO情况
【写入链路】Transfer接收点数、Transfer转发点数、Graph接收点数
【查询链路】Query到Graph查询的次数、错误率、延迟。Graph转发查询的次数。
【迁移效果】RRD文件的迁移量、成功率、迁移时间。

扩容过程中指标变化

每次扩容,都严格遵守扩容步骤,观察所有性能指标及数据的稳定性,并没有出现严重的断层及数据异常。下面将我们多次扩容的性能及指标数据分享给大家:(所有concurrency配置为:5)

扩容细节

  • 说明1:此处主要说明性能上限,IO及内存的值,均为峰值
  • 说明2:由于笔者公司的监控系统持续有新指标的写入,因此迁移指标稳定时间这个值,对开源版Graph无太大参考意义

如何确保扩容完成

1、Graph接受指标总量稳定,且与Transfer转发指标数持平
2、所有查询量没有跌,且所有查询错误率稳定
3、迁移RRD文件数及迁移效率,逐渐稳定。趋于0或一个固定的值。(若无新指标,会趋于0)
4、找N个确定会落在扩容集群上的指标,确定这N条线的数据,连续且并没有断开。

需注意的点

  • 重启有害

    扩容过程中,没有完成RRD文件迁移之前,扩容集群重启就意味着扩容失败:
    重启时,内存中的数据会被强制落盘,导致未迁移完成的RRD文件无法再次迁移。
    
  • 建议分批扩容

    由于此方案无法回滚,对于数据敏感的场景,建议考虑分批次扩容。
    此次扩容过程中,我们就采用了分批次扩容的方案。先灰度一台,再小流量2台、5台,直至最终完全上线。
    实际证明,分批次扩容是完全可行、安全、可以降低风险的。
    

总结

总而言之,这个方案是可行、稳定、可操作的。 只要做好事前准备,对扩容过程了解到位,可以很容易扩容成功。

附:扩容中的指标变化情况

RRD文件迁移量变化:

老集群IO.util:

老集群IO.read.MB:

新集群IO.write.MB:

作者:高家升 聂安 钱威

链接:http://www.jianshu.com/p/a87ab10e09c7
來源:简书

参考资料:

Copyright 2015 - 2018 Xiaomi Inc. all right reserved,powered by Gitbook该文件修订时间: 2018-12-19 05:30:02