基于Ceph打造高性能高可靠的分布式块存储系统

 

存储是云计算的基石。 — Jack Ma

 

块存储系统

分布式存储有出色的性能,可以扛很多故障,能够轻松扩展,所以我们使用Ceph构建了高性能、高可靠的块存储系统,并使用它支撑公有云和托管云的云主机、云硬盘服务。

由于使用分布式块存储系统,避免了复制镜像的过程,所以云主机的创建时间可以缩短到10秒以内,而且云主机还能快速热迁移,方便了运维人员对物理服务器上硬件和软件的维护。

用户对于块存储系统最直观的感受来源于云硬盘服务,现在我们的云硬盘的特点是:

  • 每个云硬盘最大支持 6000 IOPS和170 MB/s的吞吐率,95%的4K随机写操作的延迟小于2ms 。
  • 所有数据都是三副本,强一致性,持久性高达10个9。
  • 创建、删除、挂载、卸载都是秒级操作。
  • 实时快照。
  • 提供两种云硬盘类型,性能型和容量型。

软硬件配置

经过多轮的选型和测试,并踩过无数的坑之后,我们选择了合适我们的软件和硬件。

软件

ss-software-used

硬件

  • 从SATA磁盘到SSD,为了提高IOPS和降低Latency。
  • 从消费级SSD到企业级SSD,为了提高可靠性。
  • 从RAID卡到HBA卡,为了提高IOPS和降低Latency。

 

最小部署架构

随着软硬件的升级,需求的调整, 我们的部署架构也不断在演进,力求在成本、性能、可靠性上达到最佳平衡点。

ss-minimum-deployment

最小规模部署中有12个节点,每个节点上有3块SSD。节点上有2个万兆口和1个千兆口,虚拟机网络和存储网络使用万兆口,管理网络使用千兆口。每个集群中都有3个Ceph Monitor节点。

轻松扩展

云计算的好处是极强的扩展性,作为云计算的底层架构,也需要有快速的Scale-out能力。在块存储系统的部署架构中,可以以12台节点为单位进行扩展。

ss-144-nodes

 

改造OpenStack

原生的OpenStack并不支持统一存储,云主机服务Nova、镜像服务Glance、云硬盘服务Cinder的后端存储各不相同,造成了严重的内耗。我们把这三大服务的后端统一起来,进行高效管理,解决了虚拟机创建时间长和镜像风暴等问题,还能让虚拟机随便漂移。

原生的OpenStack

ss-openstack-old

改造后的OpenStack

ss-openstack-new

 使用原生的OpenStack创建虚拟机需要1~3分钟,而使用改造后的OpenStack仅需要不到10秒钟时间。这是因为nova-compute不再需要通过HTTP下载整个镜像,虚拟机可以通过直接读取Ceph中的镜像数据进行启动。

我们还增加两个OpenStack没有的功能: QoS 和 共享云硬盘。云计算的另外一个好处是租户资源隔离,所以必备QoS。共享云硬盘可以挂载给多台云主机,适用于数据处理的场景。

我们还使用了OpenStack的multi-backend功能,支持多种云硬盘类型,现在我们的云硬盘类型有性能型、容量型,可以满足数据库和大文件应用。

 

高性能

存储系统主要的性能指标是IOPS和Latency。我们对于IOPS的优化已经达到了硬件的瓶颈,除非更换更快的固态硬盘或者闪存卡,或者是改变整个架构。我们对于Latency的优化也快接近完成,可以达到企业级存储的水平。

 

复杂的I/O栈

整个块存储系统有着长长的I/O栈,每个I/O请求要穿过很多线程和队列。

ss-io-stack

 

优化操作系统

优化操作系统的参数可以充分利用硬件的性能。

  • CPU
    • 关闭CPU节能模式
    • 使用Cgroup绑定Ceph OSD进程到固定的CPU Cores上
  • Memory
    • 关闭NUMA
    • 设置vm.swappiness=0
  • Block
    • 设置SSD的调度算法为deadline
  • FileSystem
    • 设置挂载参数”noatime nobarrier”

优化Qemu

Qemu作为块存储系统的直接消费者,也有很多值得优化的地方。

  • Throttle: 平滑的I/O QoS算法
  • RBD: 支持discard和flush
  • Burst: 支持突发请求
  • Virt-scsi: 支持多队列

优化Ceph

我们对于Ceph的优化是重头戏,有很多问题也是时间长、规模上去之后才暴露出来的。

ss-rule-1 ss-rule-2 ss-rule-3 ss-rule-4 ss-rule-5 ss-rule-6 ss-rule-7

 

ss-result-iops ss-result-latency

高可靠性

存储需要高可靠性,保证数据可用并且数据不丢失。因为我们的架构中没有使用UPS和NVRAM,所以写请求的数据都是落到三块硬盘之后才返回,这样最大限度地保证了用户的数据安全。

如何计算持久性

持久性是数据丢失的概率,可以用于度量一个存储系统的可靠性,俗称 “多少个9”。数据的放置(DataPlacement)决定了数据持久性,而Ceph的CRUSH MAP又决定了数据的放置,因此CRUSH MAP的设置决定了数据持久性。但是,即时我们知道需要修改CRUSH MAP的设置,但是我们应该怎么修改CRUSH MAP的设置呢,我们该如何计算数据持久性呢?

我们需要一个计算模型和计算公式,通过以下资料,我们可以构建一个计算模型和计算公式。

最终的计算公式是: P = func(N, R, S, AFR)

  • P: 丢失所有副本的概率
  • N: 整个Ceph Pool中OSD的数量
  • R: 副本数
  • S: 在一个Bucket中OSD的个数
  • AFR: 磁盘的年平均故障率

这个计算模型是怎么样得到计算公式的呢?下面是4个步骤。

  1. 先计算硬盘发生故障的概率。
  2. 定义哪种情况下丢失数据不能恢复。
  3. 计算任意R个OSD发生故障的概率。
  4. 计算Ceph丢失PG的概率。

硬盘发生故障的概率是符合泊松分布的:

  • fit =   failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365)
  • 事件概率 Pn(λ,t) = (λt)n e-λt / n!

Ceph的每个PG是有R份副本的,存放在R个OSD上,当存有这个PG的R个OSD都发生故障时,数据是不可访问的,当这R个OSD都损坏时,数据是不可恢复的。

计算一年内任意R个OSD发生相关故障概率的方法是:

  1. 计算一年内有OSD发生故障的概率。
  2. 在Recovery时间内,(R-1)个OSD发生故障的概率。
  3. 以上概率相乘,就是一年内任意R个OSD发生相关故障概率,假设是 Pr。
  4. N个OSD中,任意R个OSD的组合数是C(R, N)。

因为这任意R个OSD不一定存有同一个PG的副本,所以这任意R个OSD发生故障并不会导致数据不可恢复,也就是不一定会导致数据丢失。

假设每个PG对应一组OSD(有R个OSD, 称之为Copy Set),有可能多个PG对应同一组OSD。假设有M个不同的Copy Set, M是一个非常重要的数字。

我们再来对Copy Set进行精确的定义:Copy Set上至少有一个PG的所有副本,当这个Copy Set损坏时,这个PG的所有副本也会丢失,这个PG上的所有数据就不可恢复。所以Ceph丢失数据的事件就是Ceph丢失PG, Ceph丢失PG就是有一个Copy Set发生损坏,一个Copy Set丢失的概率就是 P = Pr * M / C(R, N) 。

持久性公式就是个量化工具,它可以指明努力的方向。我们先小试牛刀,算一下默认情况下的持久性是多少?

假设我们有3个机架,每个机架上有8台节点,每个几点上有3块硬盘,每个硬盘做一个OSD,则一共有72个OSD。

ss-default-map

默认的crush map设置如下所示

ss-default-crush

通过持久性公式,我们得到下面的数据。

ss-default-durability

默认情况下,持久性有8个9,已经比一般的RAID5、RAID10要高,和RAID6差不多,但是还不能满足公有云的要求,因为公有云的规模很大,故障事件的数学期望也会很大,这就逼着我们尽量提高持久性。

提高持久性的方法有很多,比如增加副本数,使用Erase Code等。不过这些方法都有弊端,增加副本数势必会扩大成本;使用Erase Code会导致Latency提高,不适合于块存储服务。在成本和Latency的制约下,还有什么办法可以提高持久性呢?

前面我们已经得到一个量化公式 P = Pr * M / C(R, N), 我们从量化公式入手,去提高持久性(也就是降低P)。要想降低P, 就得降低Pr、M,或者是提高C(R, N)。因为C(R, N)已经确定,我们只能降低Pr和M。

 

降低恢复时间

从Pr的定义可以知道Pr与恢复时间有关,恢复时间越短,Pr的值越低。那么恢复时间跟什么有关系呢?

ss-host-bucket-disadvantage ss-osd-domain

我们需要增加更多的OSD用于数据恢复,以便减少恢复时间。目前host bucket不能增加更多的OSD,这是因为主机的网络带宽限制和硬盘插槽限制。解决办法是从CRUSH MAP入手,增加一种虚拟的Bucket: osd-domain, 不再使用host bucket。

ss-osd-domain-map ss-osd-domain-crush ss-osd-domain-durability

通过使用osd-domain bucket,我们把持久性提高了10倍,现在持久性有9个9。

 

减少Coepy Set个数

如何减少Copy Set的个数呢?Copy Sets是和PG的映射有关的,我们从CRUSH MAP的规则和条件入手,减少Copy Set的个数。解决办法增加虚拟的Bucket: replica-domain, 不再使用rack bucket。每个PG必须在一个replica-domain上,PG不能跨replica-domain,这样可以显著减少Copy Set的个数。

ss-replica-domain-map ss-replica-domain-crush ss-replica-domain-durability

通过使用replica-domain,现在的持久性有10个9,持久性比默认的crush map设置提高了100倍。

 

自动化运维

Ceph的运维比较费心,稍有差池,整个云平台都会受到影响,因此我们觉得运维的目标是可用性:

减少不必要的数据迁移,进而减少slow requests,保证SLA。

部署

我们整个云平台都是使用Puppet部署的,因此我们使用了Puppet去部署Ceph。一般Ceph的安装是分阶段的:

  1. 安装好Ceph Monitor集群。
  2. 格式化Disk,使用文件系统的UUID去注册OSD, 得到OSD ID。
  3. 根据OSD ID去创建数据目录,挂载Disk到数据目录上。
  4. 初始化CRUSH MAP。

Puppet只需要完成前三步,第四步一般根据具体情况用脚本去执行。因为OSD ID是在执行过程中得到的,而Puppet是编译后执行,这是一个悲伤的故事,所以puppet-ceph模块必须设计成retry的。

相比eNovance和Stackforge的puppet-ceph模块,我们的puppet-ceph模块的优点是:

  • 更短的部署时间
  • 支持Ceph所有的参数
  • 支持多种硬盘类型
  • 使用WWN-ID替代盘符。

 

维护

升级Ceph的过程很简单,三条命令就可以搞定:

  1. ceph osd set noout    #避免在异常情况下不可控
  2. ceph osd down x        #提前mark down, 减少slow request
  3. service ceph restart osd.x

更换硬件或者升级内核时需要对机器进行重启,步骤也很简单:

  1. 把这台机器上的虚拟机迁移到其他机器上
  2. ceph osd set noout
  3. ceph osd down x    #把这个机器上的OSD都设置为down状态
  4. service ceph stop osd.x
  5. 重启机器

扩展集群的时候需要非常小心,因为它会触发数据迁移:

  1. 设置crush map
  2. 设置recovery options
  3. 在凌晨12点触发数据迁移
  4. 观察数据迁移的速度,观察每个机器上网口的带宽,避免跑满
  5. 观察slow requests的数量

你总会碰到硬盘损坏的时候,替换硬盘时需要非常小心,你要小心的设置crush map,你要保证要替换硬盘过程中replica-domain的weight的值是不变的,这样才能保证不必须要的数据迁移。

 

监控

Ceph自家的Calamari长得不错,但是不够实用,而且它的部署、打包还不完善,在CentOS上还有一些BUG,我们只能继续使用原有的工具。

  • 收集:使用diamond,增加新的colloctor,用于收集更详细的数据。
  • 保存:使用graphite,设置好采集精度和保存精度。
  • 展示:使用grafana,挑了十几个工具,发现还是grafana好看好用。
  • 报警:zabbix agent && ceph health

我们根据Ceph软件架构对每个OSD分成了很多个throttle层,下面是throttle模型:

ss-throttle

有了throttle model,我们可以对每个throttle进行监控,我们在diamond上增加了新的collector用于对这些throttle进行监控,并重新定义了metric name。

ss-graphite-metric-name

最后,我们可以得到每个OSD每层throttle的监控数据。但平时只会关注IOPS、吞吐率、OSD Journal延迟、读请求延迟、容量使用率等。

ss-ceph-status

事故

在云平台上线已经快一年了,我们遇到的大小事故有:

  • SSD GC问题,会导致读写请求的Latency非常大,飙到几百毫秒。
  • 网络故障,会导致Monitor把OSD设置为down状态。
  • Ceph Bug, 会导致OSD进程直接崩掉。
  • XFS Bug, 会导致集群所有OSD进程直接崩掉。
  • SSD 损坏。
  • Ceph PG inconsistent。
  • Ceph数据恢复时把网络带宽跑满。

总体来说,Ceph是非常稳定和可靠的。

 

 

 

 

12 comments

    • dong lei Reply

      好文章!

      有个问题,没看懂如何能够通过用virtual-domain这种bucket替换host这个bucket来减少recovery时间。

      看你的图里面,“如果1个osd out了,只有2个osd可以recovery”
      就我的理解,recovery是以pg为单位,out的这个osd上所有pg的peers都可以做recovery,不限定于同一个server(看你的图上是server8)上的其他两个osd。而这些peers可以是其他host上的很多osd。

      • 朱 荣泽 Post authorReply

        recoverying是分数据导出和数据导入的。当一个osd失效后,是有很多osd同时参与recoverying,但是只有2个osd会接替死去osd的工作(只有同一个host下的osd才能接替死去osd的工作),只有这2个osd是被导入数据,其他osd是导出数据。因此这2个osd就是瓶颈了。
        使用virtual-domain的做法是为了提高recoverying的数据导入速度。

        • soranokaze Reply

          “只有同一个host下的osd才能接替死去osd的工作”是因为当一个OSD退出后对应 host bucket 的总weight不变才成立的吧?
          一般情况下如果无人工干预,一个OSD退出后,该OSD在crush中的weight就会被ceph自动置为0,然后对应的 host bucket 的weight也会随之减少,从而退出的OSD的PG会重新分布于所有现有的OSD上(而不仅仅是同一个host下的OSD),也就是对应着“多个读出”、“多个写入”。所以如果不是在OSD退出后人工手动调整host bucket的weight使之保持原值,而是由ceph自动调整的话,是不存在“只有同一个host下的osd才能接替死去osd的工作”的瓶颈的吧?
          而且貌似博主说的是backfill过程,而不是recovery过程。
          不知道我的理解正不正确,有错的话请指正

          • soranokaze

            不了,估计博主在北上广,我在无锡的小城市,交通不便
            只是看到博主的文章后对ceph的调优有了一些启发,于是搞了4台服务器测试了一下,发现在默认安装配置下,一个osd down了之后数据迁移的现象与博主原先描述的有些出入,于是作了如上猜测,但并不是很确定。
            我目前还没有足够的能力研究ceph源码及实现细节,所以只能 猜测 这里是怎么一回事。如果博主了解的话,还请不吝在博文中再细讲解一下~谢谢~~毕竟一旦投入生产,crushmap就不太好做这么大的改动了,这种调优只能尽可能在一开始设计好并保证正确。

          • 朱 荣泽 Post author

            Ceph OSD分为up、down、out状态。

            当osd为down状态时,它的weight不变,处于降级状态。过了N秒之后(这个值可以设置),Ceph Monitor会自动把这个osd状态设置为out状态,则它的weight变成0,这会触发数据迁移。

          • 朱 荣泽 Post author

            一篇博文不足以详细解析Ceph的源码和实现细节,只能说明Ceph的大致行为。

            要想利用Ceph的扩展性并提供可用性和维护性,是要一开始就做好Ceph的架构设计和CRUSHMAP的设计。

          • soranokaze

            所以结论就是:
            1、如果在实际生产中决定由人工触发数据迁移(ceph osd set noout),并在迁移中会保持要替换或去掉的osd的上层bucket weight不变,那么就可以使用博主博文里的osd-domain来减少恢复时间,从而提高可靠性(当然,会牺牲一点分布的平衡性)。
            2、如果在实际生产中决定依靠ceph自动触发数据迁移(ceph osd unset noout),那么要达到减少恢复时间的目的,(osd-domain在此时没有效果)就只能适当减小mon osd down out interval,使之尽可能小但又不会过于灵敏而频繁触发数据迁移,从而提高可靠性了。
            是这样吗?

        • xww Reply

          recoverying是分数据导出和数据导入的。当一个osd失效后,是有很多osd同时参与recoverying,但是只有2个osd会接替死去osd的工作(只有同一个host下的osd才能接替死去osd的工作),只有这2个osd是被导入数据,其他osd是导出数据。因此这2个osd就是瓶颈了。

          楼主的这段话实在不敢苟同,估计ceph原理都没懂

  1. luoqingchao Reply

    关于Durability的计算,可直接参考MTTDL模型,描述的更加简明扼要!

Leave a Reply

Your email address will not be published. Required fields are marked *