• 前言
• 本文面向对象
• 方案原理
• 方案缺陷
• 扩容前，我们做了哪些准备
• 扩容过程
• 总结
• 附：扩容中的指标变化情况

1.1.1. 前言

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

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

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

1.1.2. 本文面向对象

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

1.1.3. 方案原理

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

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

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

1.1.4. 方案缺陷

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

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

1.1.5. 扩容前，我们做了哪些准备

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

补全自监控

【写】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的情况下，可以完美热扩容。

1.1.6. 扩容过程

分批扩容

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台，直至最终完全上线。
  实际证明，分批次扩容是完全可行、安全、可以降低风险的。
  

1.1.7. 总结

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

1.1.8. 附：扩容中的指标变化情况

RRD文件迁移量变化:

老集群IO.util:

老集群IO.read.MB:

新集群IO.write.MB:

作者：高家升 聂安 钱威

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

参考资料：

• graph扩容历史数据自动迁移 - laiwei