*

Leverage Ceph For SDS in

China MobileLIU Yuan & GUI Hecheng

2

自我介绍

LIU Yuan:中国移动苏州研发中心高级架构师兼基础架构组经理

热爱开源，是分布式存储Sheepdog维护者和主要贡献者之一，也是多个开源项目代码贡献者。目前负责苏研虚拟化，存储，内核，NFV等底层系统开发。曾就职于英特尔上海开源技术中心(kvm/xen)，阿里云（vhost-blk/Sheepdog/盘古），青云(SDS），从事内核，虚拟化，存储系统等底层软件研发。

GUI Hecheng:中国移动苏州研发中心软件开发工程师

2016开始参与开发ceph，目前主要参与RGW-NFS接口开发，为librgw和nfs-ganesha贡献补丁；另外也参与librbd的开发，为librbd添加了writesame命令

支持。之前任职于南京富士通南大软件技术有限公司，主要从事内核文件系统Btrfs及其工具btrfs-progs的开发。

3

苏研Ceph概况

RBD iSCSI

目录

RGW NFS

线上问题

4

苏研Ceph概况

1. 背景a. 16年6月，对象存储从自研oNest转向Ceph RGWb. 16年10月，块存储从Sheepdog转向Ceph RBD

2. 生产部署情况1. 块存储，私有云，公有云，传统SAN等 500+节点， 30PB+数据2. 对象存储，公有云，备份，归档，视频图片等600+节点，30PB+数据3. 完成大小数十个项目，最大单集群200+节点

3. 社区开发情况1. 16年12月开始第一个补丁2. 截止到6月10日，Ceph 100+补丁，行数6000+，近半年国内最活跃的

代码贡献者3. Ceph相关项目(TCMU, NFS-Ganesha, Kernel)补丁80+，行数5000+4. RBD iSCSI和RGW NFS 主要贡献者之一

5

块服务

虚机块设备 iSCSI LUN服务

基于Ceph，提供块存储服务 1 虚机块设备 2 iSCSI LUN

6

对象服务

基于Ceph，提供对象服务

主要是S3协议 多数据中心项目

7

Why RBD iSCSI？

• 目标：RBD iSCSI协议支持

• 应用：对标IP-SAN，支持数据库，HyperV，VMware等传统应用服务

Target

生产系统 SCSI Target

存储服务

librbdiscsi

RBD iSCSI

• 需求：

VMware存储服务

IP-SAN存储服务

数据库共享卷服务

• 解决方案：

TCMU – LIO用户态Target 后端

支持VMware VAAI高级特性

8

Why RGW-NFS?

• 目标：对象存储支持NFS接口

• 应用：支持混合云存储及数据中心云化需求，提供数据迁移工具

存储网关

生产系统 网关前端 存储服务

httpnfs

存储网关

• 需求：

私有云数据迁移

混合云数据中心

私有云数据容灾

• 解决方案：

文件存储网关

支持NFS接口

9

苏研Ceph概况

RBD iSCSI

目录

RGW NFS

线上问题

10

RBD iSCSI

• VMware VAAI

– Block和NAS存储都有扩展

– Block Primitives:

• Atomic Test & Set: 细粒度锁机制. Reservation Lock锁住整个LUN.

• Extended Copy: 克隆和热迁移负载offload到存储

• WriteSame: 清零操作offload到存储，加速块分配、克隆、数据初始化操作。

• Unmap: 回收不用的空间，提高存储空间使用率。

• TCMU

– In-kernel LIO + User-space TCMU

– Ceph RBD adoption: 添加writesame, compare_and_write接口

• Roadmap

– 目前：ceph patches ready to merge, TCMU VAAI merged

– 9月底完成开发工作开始测试，补丁全部合入上游社区，年底可上线

*

LIO & TCMU

*

UIO -- 框架图

*

TCMU -- ring buffer 架构与现状

从代码可以看出，当前，ring buffer size固定为（256+16）* 4096 = 1M + 64 K。

其中，sizeof(Mailbox + Command Ring) = 64K，sizeof( Data Area) = 1M。

Command Ring 是通过伪数组的形式进行管理，每个元素具有 length 属性。

Data Area 是通过 bitmap 架构进行管理。

*

TCMU -- Ring 之 Data Area 优化

结合 TCMU & UIO 的框架实现，增加 Ring 的 Data Area 的动态调整特性。

针对于单个 Target Ring：• Data Area 区域最大 size 限制为256 * 1024 Pages，4K page size 下为 1G。• Data Area 区域初始 size 为 128 Pages，4K page size 下为 1M。• Data Area 根据实际需求进行动态的 grow 或者 shrink。

介于系统本身内存的限制，如果不对 TCMU 下所有 Targets 的 Ring 的 Data Area 进行限制，则会造成系统内存的耗尽，解决方案：• 对 TCMU 下所有 Ring 的 Data Area 区域大小总和进行限制，比如当前的2G，

然后建立一个缓冲池 GDAP（Global Data Area Pool）。• 任何一个 Target Ring 的 Data Area 进行动态 grow 时候，会从GDAP中申请和

释放。

优化后效果：读写 IOPS 分别提升约 100 ~700%，应用压力越大，提升越明显。

以上方案的相关补丁目前已经进入内核主线。

*

TCMU -- Ring 之 Cmd Area 优化

Cmd Area 存放的相关 SCSI 命令头控制信息，相对于 SCSI 传输的 Data 数据大小，所占空间是很小的，所以在设定最大 1G Data Area 情况下，根据估算Cmd Area 不超过 8M（Cmd Area：Data Area ~= 8：1024），所以目前设定单个 Target Cmd Area 大小为 8M。

8M Cmd Area 相对于大多数情况下，能够配合 1G Data Area 工作的很好，但是针对于 SCSI 大量的小数据量的传输情况下，8M还是会造成性能瓶颈。

根据 SCSI 命令下 DMA Segments Scatter/Gatter <--> iovec 区域转换合并的特点，对 Cmd Area 下各个SCSI entry 进行瘦身优化，优化后能够使得每个 SCSI entry 节省约一半以上的内存空间，使得 8M 大小的 Cmd Area 显得绰绰有余。

优化后效果：节省 Cmd Area 约一半的内存。

以上瘦身优化补丁目前已经进入内核主线。

*

TCMU-runner

• 添加Ceph支持• 添加对 ESXI 硬件加速（VAAI）的支持• 添加配置文件支持• 添加日志机制的支持• 大量代码重构…• Ceph rbd, rados改造

17

苏研Ceph概况

RBD iSCSI

目录

RGW NFS

线上问题

18

目的：让对象存储兼容传统NFS接口应用

概念:

普通文件 : S3 object

目录 : 空的S3 object（顶层目录是S3 bucket）

文件属性 : RADOS object xattr (unix-key1, unix1)

根目录（/） : 可以显示所有的S3 bucket的目录

RGW-NFS简介

*

内容

架构

测试

主要开发点

正在开发

*

架构

Ceph + Librgw + Nfs-ganesha

*

架构

Ceph + Librgw + Nfs-ganesha

Nfs-ganesha

- 用户态NFS服务器，支持V3,V4协议

- 采用类似VFS的架构，可支持多种后端（glusterfs、cephfs、rgw）

- 支持类似dcache的元数据缓存(MDCACHE)

Librgw

- S3的bucket/object操作封装

*

测试

文件系统接口测试

Sigmund – 测试框架，驱动其他测试，筛选用例

Pjdfstest – POSIX语意测试

Cthon04 – FS通用测试

Xfstests – FS通用测试

RGW-NFS对比S3FS

S3FS：基于FUSE的文件系统，数据写入Rados-Gateway

*

测试

文件系统接口测试

*

主要开发点

更灵活的IO

目前只支持全文件覆盖写，不支持局部写

- S3的语意本身是object级别的写入，不支持局部写

不支持文件并发访问

- 将来可支持并发读取，但无并发写入

Nfs-ganesha服务高可用

Nfs-ganesha服务主备切换

- 使用Pacemaker和各种Resource Agent支持

- 需要将client信息写入ceph集群，支持NFSv4故障恢复

更丰富的文件接口

Symlink：暂无用户场景（或者你有？）

File Lock：暂无用户场景（或者你有？）

*

正在开发

文件随机访问

将S3 object变为可局部写入，需要修改现有语意

主要开发者：Matt Benjamin @Redhat

*

正在开发

Nfs-ganesha高可用

基于Pacemaker的解决方案 -- Storhaug Project （from Redhat）

支持Nfs-ganesha双活

主要组件:

- Pacemaker的Resource Agent:

（VIP, portblock, ganesha, ganesha_grace）

- 将client信息存入ceph提供的OMAP

- Cache Invalidation：发生故障切换时保持缓存一致性

*

正在开发

Nfs-ganesha高可用：搭建

*

正在开发

Nfs-ganesha高可用：故障切换

29

Writesame命令介绍

一种SCSI命令

将小块数据在一段范围内复制N份，

复制过程对客户端透明，性能高

于客户端直接写N份

用于快速初始化块设备

Librbd::Writesame处理流程

小块数据全0则执行Discard

RADOS对象上写入区间跟小块数

据不对齐则退化为普通写

Librbd API: Writesame

30

Compare And Write命令介绍

一种SCSI命令

对小块数据进行先读再比、后写，

过程原子化，比客户端直接做一次

读、一次写更安全、高效。

用于支持VMWare ATS锁

Librbd::CompareAndWrite处理流程

先读再比，只有数据一致时才执行

写

整个操作不跨RADOS对象

Librbd API: Compare And Write

31

苏研Ceph概况

RBD iSCSI

目录

RGW NFS

线上问题

32

线上问题1：数据不均衡

问题：压测时集群压力过大，出现慢IO是正常现象，但是很大一部分慢IO的原因并

不是磁盘故障导致，而是由于CEPH的CRUSH算法数据分布不均衡，导致局部OSD

数据分布量远超过其他OSD的平均值，发送到这几个OSD的IO请求远超其他节点，

所以就会成为整个集群的热点，IO延时也大，再加上IO延时具有累积效应，局部

OSD的慢IO请求越来越多。

产生原因： CRUSH算法本身是伪随机算法，当数据量小的情况下无法做到完全均

衡。

解决办法：当前可以通过ceph osd reweight-by-utilization以及ceph osd

reweight-by-pg的方式在集群刚部署完成时进行pg再均衡，当集群在运行过程中

时，通过ceph osd reweight微调。同时社区在4月底合入了Sage的pg_remap

tool （13984），能够支持在线pg再均衡

33

线上问题2：元数据占用空间大

问题：线上2700个OSD的ceph集群环境，在测试中我们发现，集群的元数据就占

用了整个空间的2.8T。

产生原因：OSD缓存了集群某一段epoch的osdmap，当集群规模很大时，

osdmap占用的空间也会随之增加。

解决办法：该问题在K版ceph中通过更高效的encoding来降低空间占用率，但是在

现有的H或者J版中，只能通过修改mon_min_osdmap_epochs为200或者更低的

值来减少缓存的osdmap数量来降低空间占用，具体可以修改ceph配置

mon_min_osdmap_epochs = 500。

34

线上问题3：osd数据不一致

问题：我们在进行节点故障测试的时候发现，当副本配置为size 3/min_size 1时，

如果集群在大压力下不停地启/停不同osd节点，整个集群将会处于不稳定状态，即

使后续无任何操作，也有个别osd将无法正常运行，会不停地down掉。

产生原因：该问题与pg恢复对象的版本有关系，min_size为1的时候，极端场景下，

会产生所恢复对象的版本与副本所需的版本不一致，或者恢复得到的版本与本地

need的版本不一致的情况发生，这将导致不同副本恢复need的版本不一致，以及

恢复的版本与实际need版本不一致的问题。

解决办法：除了修改pglog，强制将各副本的版本设置为一致外，min_size需要至

少配置为2，这样就能保证至少有一个最新的pglog存在，而不会出现数据不一致现

象。