open-falcon graph扩容、缩容

方案原理

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

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

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

扩容流程

1. 修改修改新增加的graph的cfg.json如下：

"migrate": {
      "enabled": true,  //true 表示graph是否处于数据迁移状态
      "concurrency": 2,
      "replicas": 500,
      "cluster": { //未扩容前老的graph实例列表
         "graph-00" : "192.168.1.1:6070",
         "graph-01" : "192.168.1.2:6070"
      }
}

2. 启动新增加的graph（作者文档说是重启所有的graph）

3. 修改所有transfer的cfg.json如下：

"graph": {
    "enabled": true,
     ...,
    "replicas": 500,
    "cluster": {
        "graph-00" : "192.168.1.1:6070",
        "graph-01" : "192.168.1.2:6070",
        "graph-02" : "192.168.1.3:6070", # 新增的graph
        "graph-03" : "192.168.1.4:6070" # 新增的graph
    }
},

4. 重启所有的transfer

这时候，transfer就会将接收到的数据，发送给扩容后的graph实例；同时graph实例，会自动进行数据的rebalance，rebalance的过程持续时间长短，与待迁移的counter数量以及graph机器的负载、性能有关系。

5. 修改api的配置，并重启所有的api进程。

"graph": {
     ...,
    "replicas": 500,
    "cluster": {
        "graph-00" : "192.168.1.1:6070",
        "graph-01" : "192.168.1.2:6070",
        "graph-02" : "192.168.1.3:6070", # 新增的graph
        "graph-03" : "192.168.1.4:6070"  # 新增的graph
    }
},

6. 如何确认数据rebalance已经完成？

目前只能通过观察graph内部的计数器，来判断整个数据迁移工作是否完成；观察方法如下：对所有新扩容的graph实例，访问其统计接口http://127.0.0.1:6071/counter/migrate 观察到所有的计数器都不再变化，那么就意味着迁移工作完成啦。

迁移完成后关闭migrate后服务重启。

总结

1. 扩容失败对导致迁移期间数据丢失，建议分批扩容。

2. 根据原理可以知道在打开migrate开关后会对写入的数据进行rrd文件同步，达到数据迁移的效果。根据这一特性来思考下如何进行缩容操作。本人实际测试了下没走通（由于我先进行扩容操作，又进行缩容操作，导致数据没有进行同步）。如果是单纯的缩容操作应该可行。

参考文档：https://book.open-falcon.org/zh_0_2/practice/graph-scaling.html