Ceph在云英的实践

Posted on | In | |

以下是在云英工作时候做的一个Ceph实践的分享，原文链接为：http://www.sdnlab.com/17584.html

概述

大家好，我是云英负责存储的研发工程师，杨冠军，很高兴今天能在这里跟大家一起讨论分享下Ceph和Ceph在云英的实践。
首先我先介绍下，Ceph是什么，我们为什么选择Ceph？

Ceph是最近开源系统中很火的一个项目，基于Sage Weil的一片博士论文发展而来的一个分布式文件系统，可提供PB级，动态可扩展，数据安全可靠的存储服务。Ceph提供分布式存储服务包括：块存储RBD，对象存储RADOSGW和CephFS三种，基本覆盖了绝大部分企业对存储的需求，所以越来越多企业加入到使用Ceph的行列。在国内也有越来越多的个人和企业参与到Ceph的研发中，贡献自己的力量。

Ceph架构

下面我们来看下Ceph系统的整体架构：
arch

如上图所示，有如下几部分：

  1. RADOS: Ceph的核心模块，提供固定大小的Object存储
  2. LIBRADOS: RADOS的library，提供C, C++, Java, Python, Ruby, PHP的API访问RADOS
  3. RADOSGW: Rados GateWay，基于bucket策略，提供一个兼容S3和Swift的的REST gateway
  4. RBD: 提供可靠的分布式块存储服务，结合Openstack，应用非常之广
  5. CEPH FS：提供POSIX协议的文件系统服务

从上面可以看出，RADOS是Ceph的核心，它主要由MDS + OSD组成，下图描述的即是一个个笑脸(object)如何存储到OSDs中：
arch

Client端会跟Monitors通信，获取Cluster Maps信息，然后通过固定的算法算出每个Object存储的OSD位置，直接与OSD通信，写入Object数据。

这里Ceph的一大优势很好的体现出来：无需元数据服务器节点，所有都是“无需查表，算算就好”！

Ceph主要特性

前面我们提到了Ceph是一个动态可扩展，数据安全可靠的存储服务，现在我们逐一来讨论下Ceph作为一个分布式系统必须的三种特性：

高扩展性

针对集群的扩容需求，Ceph支持OSD和Monitor集群的动态可扩容，并通过两层Map机制[(pool, object) -> (pool, PG) -> OSD set)来有效的隔离了集群扩容对上层client的影响，提供了很好的扩展性。这样我们可以利用大量的低配置设备轻松的搭建出PB甚至EB级的存储系统。
arch

上图描述了Client段的一个File如何经过多层的映射，写入到OSDs中的，也正是这多层映射和CRUSH算法，保证了Ceph的高扩展性。在PG数不变的情况下，底层OSD的扩展对Client端是完全透明的。

高可靠性

针对数据的安全可靠，Ceph会在集群中存储同一数据的多个副本（或者其他类型的冗余，例如erasure code），来保证在某些设备故障后，用户存入的数据还可用，针对用户不同的高可用需求，Ceph可以很方便的设置Pool的数据冗余规则，另外通过Ceph Crushmap，用户也可以方便的设置各个备份之间存储位置的逻辑关系，比如达到多个副本跨机房、跨机架、跨机器等目的，提高集群的数据可靠性。

另外Ceph能自动探测到OSD/Monitor/MDS的故障，并自行恢复，有效减少了单设备节点的稳定性对集群的影响。

下图是Ceph中一个写IO的流程，保证数据的强一致性：
arch

从图中可以明显的看出，Ceph的写会由Client发给Primary OSD，由Primary OSD发送副本给Replica OSD上，而只有所有的副本都写完成后，写IO才算完成，保证了数据的一致性和高可靠性。

高性能

Ceph中通过文件切分和CRUSH算法，保证数据chunk分布基本均衡，同时Ceph的无元数据信息的设计(CephFS除外)，保证了Client可以根据cluster map，通过固定算法确定数据的位置信息，避免了单个元数据节点的性能瓶颈，可以提供非常高的并行化IO性能。
arch

如上图所示，Client端数据经过切分为Objects后，可以同时与多个OSDs交互，写入数据。

Ceph在云英的实践

前面大致介绍了Ceph系统的原理和架构，那我们为什么选择Ceph呢？
对比现有的一些其他的分布式存储系统，Ceph有如下优点：

  1. 完全的开源系统
  2. 能提供块存储，对象存储和文件系统存储的统一架构
  3. 设计理念先进，是个高扩展，高可用，高性能的分布式文件系统
  4. 与Openstack完美结合，社区支持好
  5. Ceph社区活跃度很大

总之，作为一个比较完善的分布式存储系统，Ceph能满足绝大多数企业的存储需求，同时它也提供了足够多的配置选项，给用户根据需求定制化自己的存储系统。

上面大致介绍了Ceph的原理架构和设计理念，下面我们来介绍下Ceph在云英的具体实践，给大家一个真实的感受。

首先说一下云英，云英的全称是北京云英传奇技术有限公司。我们是一家专注于为创客和行业客户提供云计算服务的公司，我们提供的有公有云和私有云服务，包括IAAS和PAAS层产品，网址为 www.cloudin.cn

在云计算的技术上我们选择了openstack + ceph的架构，基于之上实现了我们自己的逻辑和特色功能，包括云监控，自动化运维，RDS等服务。针对这么多应用，绝大部分服务的数据都依靠Ceph系统提供可靠的存储服务，在应用实践中，针对我们自己的系统架构和机房部署，我们对Ceph也进行了部分调优和优化，达到了我们的应用需求。

下面我们来介绍下Ceph存储在云英的应用，大致可以分为如下几种：

  1. RBD块存储服务
  2. CephFS提供服务器间数据共享
  3. RADOSGW提供对象存储服务
  4. Ceph的性能测试
  5. Ceph的优化
  6. Ceph的监控

首先我们先介绍下第一项:

RBD块存储服务

我们的块存储服务主要给Openstack组件使用，分为如下几类：

  1. Glance镜像存储
  2. Nova instance数据存储
  3. Cinder volume存储
  4. Backup服务

应用中，把Openstack的Glance组件image和Nova instance数据一起存储到Ceph集群中，可以很好的避免Openstack创建虚拟机时的image复制，并且利用Ceph RBD的snapshot功能，基本可以实现秒级创建Nova instance。

同样利用RBD的snapshot功能，可以有效的减少Cinder Volume，Nova instance的备份创建时间和空间占用。

另外因为Ceph底层是一个共享存储，所以基于此可以便利的实现Nova instance的热迁移功能，缩短了虚拟机热迁移导致的服务停顿时间。

整个应用场景如下图所示，Ceph作为了一个统一存储，对Openstack各个组件提供服务：

arch

CephFS提供服务器间数据共享

CephFS是基于Rados实现的PB级分布式文件系统，这里引入了一个新的组件MDS(Meta Data Server)，它主要为兼容POSIX文件系统提供元数据，如目录和文件元数据。同时，MDS会将元数据也存在RADOS(Ceph Cluster)中。元数据存储在RADOS中后，元数据本身也达到了并行化，大大加强了文件操作的速度。需要注意的是MDS并不会直接为Client提供文件数据，而只是为Client提供元数据的操作。

arch

在我们的生产环境中，遇到过服务器间共享数据的需求。之前的思路可以通过NFS来实现，现在基于CephFS，可以轻松的满足需求。虽说我们用的版本Hammer中，Ceph官方没说CephFS完善到可用于生产环境，但也是经过大规模测试后的版本，据说在雅虎也有大规模使用的集群，另外我们共享的数据对可靠性没那么大要求，IO量也不是很大，所以CephFS已经能很好的满足我们的需求了。

最近Ceph发布的JEWEL版本是官方声称的第一个CephFS稳定版本，如果对CephFS有强烈需求的话，可以部署最新的JEWEL版本。
另外部署中最好使用单MDS的方式，虽说Ceph支持MDS集群和很多很酷的特性，比如负载均衡，动态子树迁移，故障恢复等，但MDS集群还不是Ceph官方的推荐。

RADOSGW提供对象存储服务

RadosGW是基于Librados之上实现的，它主要提供兼容S3、Swfit的RESTful接口。同时RadosGW提供了Bucket的命名空间(类似于文件夹)和账户支持，并且具备用于账单目的使用记录。相对的，它增加了Http协议的负载。
RadosGW使得Ceph Cluster有了分布式对象存储的能力，如上面提到的Amazon S3和Swift等。企业也可以直接使用其作为数据存储或备份等用途。

arch

RADOSGW在云英主要应用于以下两方面

1. RDS的数据备份存储

RDS服务是云英提供的一项的MySQL服务，我们保证了MySQL的高可用和性能，用户只需创建自己的RDS服务即可使用，而不用麻烦的自己搭建MySQL服务并配置其高可用等特性。
在RDS服务中，用户会有创建MySQL备份的需求，而这种备份是最适合对象存储的，我们自己实现了RDS的S3备份接口，把RDS的备份数据上传到兼容S3的RADOSGW中。这样使用统一的Ceph系统，我们就不需要再搭建一套Swift对象存储系统了，简化了公司的运维成本。

2. 对象存储服务

Object Storage Service是很重要的一项存储服务，越来越多的应用都开始使用便利的对象存储来存储数据。Openstack源生的对象存储服务系统是Swift，对比Ceph，Swift可以便利的搭建部署，但它也有自己的劣势，我们也不想同时维护两套存储系统，所以我们就选择RADOSGW提供兼容S3和Swift的对象存储服务。

Ceph的性能测试

为了做到心中有数，我们需要在现有硬件配置条件下，测试Ceph的性能，看是否满足我们的期望。
结合网上的参考，Ceph性能测试可分为如下几类：

  1. RADOS性能测试
    rados bench 命令
    rados load-gen 命令
  2. rbd块设备性能测试
    rbd bench-write 命令
  3. fio工具测试
    fio + rbd ioengine 测试
    fio + libaio 测试

在云英的应用中，Ceph主要提供的是rbd块设备，所以经过评估，我们选择了比较贴合实际应用的方式，使用fio + libaio的测试方法来测试虚拟机中云硬盘的性能。
为此我们写了一系列的测试脚本来自动化测试和分析测试结果，结合Ceph的参数优化，给出实际的性能参考。

测试统计结果样本如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
device: /dev/rbd1
ioengine: libaio size: 1000 runtime: 300
models: randread randwrite
mixread: 50
blocks: 4
iodepth: 2
numjobs: 1
processes: 1 2 4
rate: , ratemin:
rate_iops: 100, rate_iops_min:
host: 10.10.0.12 10.10.0.13 10.10.0.14 10.10.0.15
hosts,model,mixread,bs,iodepth,numjobs,r-bw(KB/s),r-iops,r-avglat(msec),w-bw(KB/s),w-iops,w-avglat(msec)
1,randread,/,4,2,1,1329.03,331,24.13,0,0,0
1,randwrite,/,4,2,1,0,0,0,1437.01,356,15.14
2,randread,/,4,2,1,3187.00,792,2.41,0,0,0
2,randwrite,/,4,2,1,0,0,0,3175.73,792,13.54
4,randread,/,4,2,1,6399.24,1591,1.72,0,0,0
4,randwrite,/,4,2,1,0,0,0,6344.70,1582,15.95

上述测试结果可以方便的导出到excel，制作成表格进行分析对比：
arch

当然，测试并不是一帆风顺的，测试中的我们也会遇到一些问题，也会做一些调整，这里分享下常见的几个注意事项：

  1. 云硬盘需要先dd一遍后再测试
  2. 每轮测试前清空虚拟机的缓存数据
  3. 每轮测试前清空物理服务器的缓存数据
  4. 每轮测试中通过iostat命令搜集磁盘负载数据
  5. 测试获取顺序读写的bandwidth和随机读写的iops
  6. 独占系统，防止产生干扰
  7. 每轮测试后分析测试数据，找到系统评价和优化可能性

Ceph的优化

我们前面说过，Ceph提供了很多的配置参数来允许用户订制自己的分布式存储系统，在赋予用户这个便利性的同时，也意味着如果用户想获取自己系统的最大性能时，必须自己进行分析调优。

Ceph是一个复杂的系统，官方的默认配置能保证系统基本运行，但是不能贴合用户实际需求，达到最大化用户物理系统性能的要求。虽说现在也已经有了一些朋友分享Ceph的配置参考和调优，但对每个用户来说都不是拿来主义。他们只是提供了一种优化的参考，具体的效果如何还需要用户贴合自己的实际测试结果来调整。

对于云英来说，我们的物理机配置是相当前卫的，用于Ceph系统的物理机硬件配置大致如下：

  1. 200G+内存
  2. 32核Intel Xeon处理器
  3. 1:3的SSD和SATA配比，SSD分区做Journal，SATA盘做OSD
  4. PCIE的存储卡提供超高性能存储Pool
  5. 万兆网卡提供Ceph的Cluster Network通信
  6. 千兆网卡提供Ceph的Public Network通信

参考网上朋友的Ceph配置和调优参数后，结合我们的经验和测试分析，我们做了适合自己的独特优化，对比各种调优项前后，很好的达到我们的要求。

依据我们的经验，可以在以下几个方面做Ceph的性能调优：

  1. BIOS设置：

    • 开启CPU的Hyper-Threading
    • 关闭CPU节能
    • 关闭NUMA

  2. Linux参数调优

    • CPU设置为performance模式
    • 调整内核的pid_max限制
    • 调整SATA/SSD IO Scheduler
    • 调整磁盘的read_ahead_kb大小

  3. XFS相关

    • xfs mkfs options
    • xfs mount options

  4. filestore调整

    • filestore fd cache size
    • filestore omap header cache size
    • filestore queue相关参数
    • filestore wbthrottle相关参数
    • object size

  5. journal

    • 性能高的SSD分区做journal
    • journal size > 5G
    • journal queue

  6. osd相关

    • osd上PG总数限制
    • osd op threads
    • osd recovery threads

  7. crushmap优化

    • 给osd划分合理的pools
    • 故障域切分，降低数据丢失概率

Ceph的监控

对于一个大型系统来说，完善的监控很重要，我们不可能时刻靠人工来发现系统的问题。
针对Ceph系统，我们调研了很多种方案，主要有如下几种：

  1. Ceph官方的Calamari（已一年多没有提交）
  2. Intel的VSM
  3. Ceph-Dash
  4. Inkscope
  5. 定制化的Diamond + Grafana
  6. Ceph Collectd + Grafana

最后选择了适合我们的，方便我们扩展的一种。即：Diamond + Graphite + Grafana，下面介绍一下这些组件：

  1. Diamond是一个客户端性能收集工具，Python编写，易与扩展。
  2. Graphite是一个Python编写的企业级开源监控工具，采用django框架。
  3. Grafana是功能齐全的度量仪表盘和图形编辑器，支持Graphite，InfluxDB和OpenTSDB。

部署后，我们可以在Grafana的前端订制我们自己的监控项，类似下图：
arch
arch

另外，Ceph进程的监控，集群状态的监控，我们通过自己写的脚本，完美的集成到Zabbix系统，实现了Ceph系统有问题的实时通知。

我们的脚本监控主要有如下几个方面：

  1. Ceph状态和空间使用率的监控
  2. OSD状态的监控和自动拉起
  3. Monitor状态的监控和自动拉起
  4. PG状态的监控和报警
  5. Slow Requests的监控和报警

总结

总之，Ceph是一个大型的完善的分布式系统，对它的研究和优化是一个持续的过程，在后续我们会继续深入研究Ceph系统，学习其精髓，优化其应用，也会继续分享我们的心得。

Q&A

Q1:有多大存储规模？

A1:我们有两个机房，每个机房是一个独立的Ceph集群。每个集群里有200多个OSD，裸容量约为1PB。

Q2：主要还是块服务？对象用于备份？

A2：我们的应用方式主要是结合Openstack提供云硬盘服务，所以主要是块存储服务。
现在用于对象存储的有RDS的数据备份，还有马上准备推出的兼容S3的对象存储服务。

Q3：2个集群之间啥关系？互备？

A3：现在两个集群是独立的，没有打通作为互备。后续对于对象存储，我们有这个计划。

Q4：分享中提到调整磁盘read ahead大小和线程pid个数，只是告诉我们，去调整，但是我们不知道，调整多大？有什么参照关系？？比如是osd，两倍？

A4：应用中我们会调整SATA磁盘的read_ahead_kb到8K-16K，提高OSD的性能。
PID的个数是linux 内核最大线程的个数，应用中我们会根据物理服务器上OSD的个数去调大这个值，避免因为PID个数的限制，导致服务OSD的线程数不够。当然如果每个服务器上的OSD个数较少，这个值可以不用调整的。

Q5：200个osd，也就是200块盘？

A5：200个OSD对应200多块盘，Ceph推荐的也是一块SATA盘对应一个OSD，SSD盘就不一定是这个对应关系了，这取决于SSD盘的性能。

Q6：i/o能达到多少M连续的文件实测完？最多支持多少块硬盘 支持混插不？支持异地双活不？

A6：Ceph系统IO的吞吐量跟系统的规模有关系，我们最后得到的性能约为所有OSD磁盘性能/备份个数后的40% — 60%左右。
Ceph对磁盘个数没有限制，越多的磁盘就对应越大的Ceph集群，在提升系统容量的同时，也会带来一系列问题。现在据说最大的一个Ceph集群有3000多个OSDs。
另外Ceph对OSD的磁盘没特殊要求，支持不同配置、不同容量的磁盘。但是针对商业使用，还是推荐相同的配置硬盘，方便做crushmap的划分。
异地双活的方式，是需要上层技术支持的。Ceph本身没有异地双活。。但Ceph的对象存储功能 - RADOSGW，可以配置不同Region的备份，支持异地备份。

Q7：ceph稳定吗，云英有没有遇到过比较大的ceph故障？

A7：我们使用的是Ceph官方支持的Hammer版本，还是比较稳定的。相对的CephFS，推荐使用最新的Jewel版本，这个是第一个官方声明的CephFS稳定版本。
在云英的使用中，我们会遇到一些小故障，但Ceph都能很好的处理这些小故障，因为它是自修复的，不会影响上层应用的访问。我们也通过一些监控及时发现这些故障，人为查看修复它们。
Ceph是个分布式文件系统，每份数据都有多个备份，Monitors也是个主备的集群，正常不会出现大的故障，触发是维护人员的误操作等等。所以迄今为止我们还没有遇到过大的故障。

Q8：性能优化从哪着手？

A8：性能优化的问题，这个网上有些推荐，我们也是基于这些和自己对Ceph的理解，结合测试的结果和遇到的问题，进行分析后再做的具体优化调整。通过一些对比测试，可以分析出是SSD上的journal性能瓶颈？还是SATA盘的IO瓶颈？还是CPU处理能力的瓶颈？
总之，Ceph的优化可以从client端发起IO到OSD写下数据这个path上分析后进行优化。

Q9：pid个数和osd有什么样关系？比如说我有两块osd，那么建议将pid设置成4。类似这样关系，是什么样规则？

A9：我们用的是ubuntu系统，内核默认的pid_max应该是32768。而每个OSD会占用很多线程来处理数据，为了防止这个值影响OSD的启动和性能，我们调整为一个很大的值。

Q10：分享中提到写完所有副本才算完成，假如中间有一个副本写入失败了，需要回退之前的吗？之前写入成功的吗？

A10：写的操作是client发送Primary OSD的，它再发送给Replica OSDs，如果有IO写失败，写操作会hang住。Ceph的写机制没有超时设置，Ceph也不会回退写，所以在对应IO写失败的OSD被mark为down状态前，写操作是不会返回给客户端的。而在OSD被mark为down以后，Ceph会启动恢复机制，数据副本会写入新的OSD里。同时Ceph也有scrub机制，能保证PG sets里的数据一致性。

Q11：有个问题，cephfs 本身有服务器共享功能，那openstack 的Manila 项目是不是感觉就多余了？你们现在有做cephfs与Manila 的对接嘛

A11：Manila提供的是云上的文件共享，通过driver的方式连接多种存储后端，而Cephfs是实现POSIX语义的分布式文件系统，它通过native driver给Manila对接使用，所以这两个项目是不重复的。
我们还没做Manila与CephFS的对接，回头我们会考虑把这个提上日程。

支持原创