分布式存储如何尽量避免增减节点带来的性能影响?

我们处于分布式存储产品选型阶段,做了一些POC测试,在压测阶段发现增减节点对I/O的性能影响都比较大。请问社区大神们如何尽量的降低这种影响?是否有好的处理模式。显示全部

我们处于分布式存储产品选型阶段,做了一些POC测试,在压测阶段发现增减节点对I/O的性能影响都比较大。请问社区大神们如何尽量的降低这种影响?是否有好的处理模式。

收起
参与13

查看其它 2 个回答Garyy的回答

GaryyGaryy  系统工程师 , 某保险

这个问题涉及到了存储节点的QoS的问题。QoS应该是存储系统设计之初就要仔细考虑的架构问题。分析了一众主流存储大厂后还是觉得ceph在这方面做得最细致最全面。同时也有些厂商做得比较简陋,只提供了带宽或者IOPS的限速功能。这或许在某些场景中已经够用,但我认为一个完整的QoS方案至少要包括对带宽、IOPS的预留、上限和优先级控制,如果再精细点还可以考虑IO的粒度、延迟、突发、空间局部性、系统内部IO、用户IO、缓存、磁盘等要素。
分布式存储都有很长的IO路径,简单的IOPS限速功能通常在路径的最前端实现。例如OpenStack Cinder默认使用QEMU完成存储块的限速功能,QEMU对存储来说已经属于客户端的角色了。
QoS的本质总结起来就四个字:消此长彼,它并不会提高系统整体处理能力,只是负责资源的合理分配。
对Ceph来说,OSD的ShardedOpWq队列是个不错的选择,因为几乎所有重量级的IO都会经过该队列。这些IO可以划分为两大类,一类是客户端过来的IO,包括文件、对象和块存储;另一类是系统内部活动产生的IO,包括副本复制、Scrub、Recovery和SnapTrim等。
目前Ceph QoS最新提交了两个有关QoS的PR,具体如下:
1)dmClock Update
dmClock算法分为客户端和服务器端,服务器端一般驻留在OSD上,不会有太大变化,主要是客户端的设计,目前社区有三种初步方案:
1,使用mclock作为一种资源调度策略,控制客户端I/O请求和Ceph内部I/O之间的优先次序
2,使用卷或者存储池作为粒度,为其设置一套QOS模板
3,为每个真实的客户端提供一套QOS模板.

2)rbd: implement image qos in tokenbucket algorithm
这个是国内团队提交的一个关于rbd块设备读写镜像时候采用令牌桶算法的一直QOS方式

保险 · 2019-04-26
浏览3297

回答者

Garyy
Garyy0410
系统工程师某保险
擅长领域: 云计算存储容器

Garyy 最近回答过的问题

回答状态

  • 发布时间:2019-04-26
  • 关注会员:4 人
  • 回答浏览:3297
  • X社区推广