jasper的技术小窝

关注DevOps、运维监控、Python、Golang、开源、大数据、web开发、互联网

graphite集群扩容方案探究

作者:jasper | 分类:graphite | 标签:       | 阅读 2186 次 | 发布:2015-06-06 2:36 p.m.

现在正在做一个监控平台,对于metric的存储调研了一下graphite,graphite算是很成熟的了,但是缺点也很明显,就是读的效率不是很好,而且集群比较挫,但是也不是不能搭出集群,结果扩容又是一件棘手的事情……

前提

虽然我一直认为graphite的集群算不上是真正的集群,因为没有控制节点,也没有类似于zookeeper这样的调度器,但是在influxdb还不靠谱的前提下,我们不得不先忍受一下graphite;为了减小机器的压力,我们使用了Booking公司开源的carbon-c-relay来做sharding(听说Booking的graphite集群的规模达到了上百台,不知道他们是怎么做扩容的)。carbon-c-relay使用一致性哈希来做metric的sharding,那么如果在改变了集群的节点数,就会导致sharding完全乱套;所以graphite集群的扩容不能简单的加节点,而且每新加节点后的数据迁移也是一个耗时耗力的行为,所以讨论出了几个方案。

方案

重现这个现象之后,我做了如下的笔记——采用不同的GC算法运行似乎也产生不同的结果:

序号 方案 描述 缺陷
1 采用rsync的方式 先暂停数据的发送,新加一个更多节点的集群,然后使用rsync的方式把老集群中的数据sync到新的集群中,之后再把数据补回,但是补的时候考虑到时间戳的问题,所以在暂停数据发送时,应该先开启一个进程消费数据,加上时间戳之后再写入新的队列中。 由于使用carbon-c-relay来做的数据分配,在做rsync的时候的目标节点如何获得?而且在同步的时间里,数据是不可用的。一次需要的新机器过多。
2 fetch老数据再发给新集群 新加一个更多节点的集群,然后同时向两个集群发送数据,再把历史数据从老集群里fetch出来,再发往新的集群中,在历史数据迁移完成后,将DNS切换成新的集群,把老集群下线即可。 数据的迁移耗时会很长,而且迁移的时候是否影响正常数据的读写?一次需要的新机器过多。
3 历史数据另外存一份,只对热数据集群扩容(一) 最热的数据单独存一个集群,历史数据另外存一个,历史数据根据估量确定容量大小(事先考虑到冗余,最好做到不需扩容),会有一个进程不断地把历史数据发送到那个集群。针对热数据的扩容的话,也是新加一个更多机器的集群,等到数据新集群的数据满足热数据的要求时,将DNS的切换,再把老集群的机器下线。(注:做数据的采集时,根据不同的时间来选择不同的集群。当往历史数据集群发送时,希望时间的间隔是符合历史数据要求的,所以这里可能需要稍微修改一下whisper中的fetch那一段,使之支持特定的间隔) 一次需要的新机器过多。
4 历史数据另外存一份,只对热数据集群扩容(二) 同方案3,但是在对热数据扩容的时候,在集群资源<50%的时候,在集群内的每个节点开一个instance放入新节点,再把新的机器也放入新的集群。 扩容时机的掌握。

结论

暂时想到的方案主要这几个,各有优缺,更倾向于3、4两种方案,仅仅提供文字描述,图太难了画不出来。。。
偶有所得:https://github.com/jssjr/carbonate 提供了一些graphite集群的管理工具,先在此Mark一下。


转载请注明出处:http://www.opscoder.info/graphite_cluster_scale.html

别人正在读
【上一篇】 代理模式
【下一篇】 常见的时间序列数据库概述
其他分类: