Ceph Day Beijing - Leverage Ceph for SDS in China Mobile
•
0 likes•61 views
Gui Hecheng, Software Engineer, China Mobile Lui Yuan, Senior Architect/Team Lead, China Mobile Li Xiubo, Senior Software Engineer, China Mobile
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Ceph Day Beijing - Leverage Ceph for SDS in China Mobile
Similar to Ceph Day Beijing - Leverage Ceph for SDS in China Mobile (20)
Ceph Day Beijing - Leverage Ceph for SDS in China Mobile
- 1. * Leverage Ceph For SDS in China Mobile LIU Yuan & GUI Hecheng
- 2. 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的开发。
- 4. 4 苏研Ceph概况 1. 背景 a. 16年6月，对象存储从自研oNest转向Ceph RGW b. 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. 5 块服务 虚机块设备 iSCSI LUN服务 基于Ceph，提供块存储服务 1 虚机块设备 2 iSCSI LUN
- 7. 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. 8 Why RGW-NFS? • 目标：对象存储支持NFS接口 • 应用：支持混合云存储及数据中心云化需求，提供数据迁移工具 存储 网关 生产系统 网关前端 存储服务 httpnfs 存储网关 • 需求： 私有云数据迁移 混合云数据中心 私有云数据容灾 • 解决方案： 文件存储网关 支持NFS接口
- 10. 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月底完成开发工作开始测试，补丁全部合入上游社区，年底可上线
- 11. * LIO & TCMU
- 12. * UIO -- 框架图
- 13. * 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 架构进行管理。
- 14. * 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 的 D ata Area 进行限制，则会造成系统内存的耗尽，解决方案： • 对 TCMU 下所有 Ring 的 Data Area 区域大小总和进行限制，比如当前的2G， 然后建立一个缓冲池 GDAP（Global Data Area Pool）。 • 任何一个 Target Ring 的 Data Area 进行动态 grow 时候，会从GDAP中申请和 释放。 优化后效果：读写 IOPS 分别提升约 100 ~700%，应用压力越大，提升越明显。 以上方案的相关补丁目前已经进入内核主线。
- 15. * 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 约一半的内存。 以上瘦身优化补丁目前已经进入内核主线。
- 16. * TCMU-runner • 添加Ceph支持 • 添加对 ESXI 硬件加速（VAAI）的支持 • 添加 配置文件支持 • 添加日志机制的支持 • 大量代码重构… • Ceph rbd, rados改造
- 18. 18 目的：让对象存储兼容传统NFS接口应用 概念: 普通文件 : S3 object 目录 : 空的S3 object（顶层目录是S3 bucket） 文件属性 : RADOS object xattr (unix-key1, unix1) 根目录（/） : 可以显示所有的S3 bucket的目录 RGW-NFS简介
- 19. * 内容 架构 测试 主要开发点 正在开发
- 20. * 架构 Ceph + Librgw + Nfs-ganesha
- 21. * 架构 Ceph + Librgw + Nfs-ganesha Nfs-ganesha - 用户态NFS服务器，支持V3,V4协议 - 采用类似VFS的架构，可支持多种后端（glusterfs、cephfs、rgw） - 支持类似dcache的元数据缓存(MDCACHE) Librgw - S3的bucket/object操作封装
- 22. * 测试 文件系统接口测试 Sigmund – 测试框架，驱动其他测试，筛选用例 Pjdfstest – POSIX语意测试 Cthon04 – FS通用测试 Xfstests – FS通用测试 RGW-NFS对比S3FS S3FS：基于FUSE的文件系统，数据写入Rados-Gateway
- 23. * 测试 文件系统接口测试
- 24. * 主要开发点 更灵活的IO 目前只支持全文件覆盖写，不支持局部写 - S3的语意本身是object级别的写入，不支持局部写 不支持文件并发访问 - 将来可支持并发读取，但无并发写入 Nfs-ganesha服务高可用 Nfs-ganesha服务主备切换 - 使用Pacemaker和各种Resource Agent支持 - 需要将client信息写入ceph集群，支持NFSv4故障恢复 更丰富的文件接口 Symlink：暂无用户场景（或者你有？） File Lock：暂无用户场景（或者你有？）
- 25. * 正在开发 文件随机访问 将S3 object变为可局部写入，需要修改现有语意 主要开发者：Matt Benjamin @Redhat
- 26. * 正在开发 Nfs-ganesha高可用 基于Pacemaker的解决方案 -- Storhaug Project （from Redhat） 支持Nfs-ganesha双活 主要组件: - Pacemaker的Resource Agent: （VIP, portblock, ganesha, ganesha_grace） - 将client信息存入ceph提供的OMAP - Cache Invalidation：发生故障切换时保持缓存一致性
- 29. 2 Writesame命令介绍 一种SCSI命令 将小块数据在一段范围内复制N份， 复制过程对客户端透明，性能高 于客户端直接写N份 用于快速初始化块设备 Librbd::Writesame处理流程 小块数据全0则执行Discard RADOS对象上写入区间跟小块数 据不对齐则退化为普通写 Librbd API: Writesame
- 30. 3 Compare And Write命令介绍 一种SCSI命令 对小块数据进行先读再比、后写， 过程原子化，比客户端直接做一次 读、一次写更安全、高效。 用于支持VMWare ATS锁 Librbd::CompareAndWrite处理流 程 先读再比，只有数据一致时才执行 写 整个操作不跨RADOS对象 Librbd API: Compare And Write
- 32. 3 线上问题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. 3 线上问题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 线上问题3：osd数据不一致 问题：我们在进行节点故障测试的时候发现，当副本配置为size 3/min_size 1时， 如果集群在大压力下不停地启/停不同osd节点，整个集群将会处于不稳定状态，即 使后续无任何操作，也有个别osd将无法正常运行，会不停地down掉。 产生原因：该问题与pg恢复对象的版本有关系，min_size为1的时候，极端场景下， 会产生所恢复对象的版本与副本所需的版本不一致，或者恢复得到的版本与本地 need的版本不一致的情况发生，这将导致不同副本恢复need的版本不一致，以及 恢复的版本与实际need版本不一致的问题。 解决办法：除了修改pglog，强制将各副本的版本设置为一致外，min_size需要至 少配置为2，这样就能保证至少有一个最新的pglog存在，而不会出现数据不一致现 象。