Ceph社区跟踪(2021-01-04 ~ 2021-01-17)

本文作者: 徐 桑 迪

Youtube Channel

最近视频停止了更新,可能跟圣诞元旦假期有关。

邮件列表

Develop

  • P(pacific)版本特性基本确定,准备从master分支剥离
  • 搭建了新的平台(https://sentry.ceph.com)来跟踪teuthology的失败用例
  • BlueStore大量删除对象(比如清理Pool时)导致时延大幅度上升:
    • https://tracker.ceph.com/issues/45765
    • https://tracker.ceph.com/issues/47044

User

  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/B7K6B5VXM3I7TODM4GRF3N7S254O5ETY/
    用户发现大量元数据操作时,减小mds mds_max_caps_per_client配置有效提升了ops性能

代码合入

  • 最近的PR有一大部分是crimson osd相关,看来新的存储程序正在紧锣密鼓地开发中。其他值得关注地PR有:
    • https://github.com/ceph/ceph/pull/38708 多MDS scrub特性被标记为stable

C计划

前言

网易高性能分布式存储系统Curve已在github开源,开源以来受到了业界的广泛关注,现招募在校学生贡献者加入我们的开发。

Who?任何对分布式存储系统,Curve感兴趣的在校生,不限年级不限专业。

Why? Curve是新一代开源高性能分布式存储系统,通过参与Curve的开发,你可以收获:大型分布式系统开发经验,和业界大牛协作学习的机会,表现优异者可以获得在网易实习的机会(人数不限),特别优异者有机会直接获得校招offer。

How?添加opencurve微信号联系我们,加微信号记得注明[报名C计划]。我们会提供分布式系统学习的Roadmap供大家参考,基于分布式存储系统的理论基础之上进行选题。另外我们会有定期线上会议,了解大家的想法并为为大家答疑解惑。近期12.25左右会有C计划启动会,具体时间我们会在微信群中公布。

Roadmap

因为缺乏专业背景知识,很多小伙伴看到Curve是一头雾水,看完Curve的简介后也许还是一头雾水,那我们该如何打怪升级呢?在开始C计划的选题之前,我们给参加C计划的小伙伴们一个分布式系统的学习的Roadmap,该Roadmap是Curve团队的新人培养实践沉淀,大家可以根据自身需要自行学习。

选题

难易级别:选题共有三个级别:easy,medium,hard

发放规则:这三个级别的选题我们会分三个阶段发布,第一阶段发布easy,第二阶段发布medium,第三阶段发布hard,每个阶段持续两个月,具体的时间会在微信群里通知。对选题的任何疑问或者需要帮助的都可以在群里咨询我们。

任务提交:

  • 代码开发环境推荐使用docker镜像,参照:https://github.com/opencurve/curve/blob/master/docs/cn/build_and_run.md
  • 对于所有的任务,开始之前请大家先提交issue,地址:https://github.com/opencurve/curve/issues
    • issue的标题格式【C计划-选题*】描述清楚选做哪部分
    • 在提issue之前可以浏览下其他已有的issue,是否有一样的任务,尽量选择不同任务,如果非常感兴趣,也可以重复选择
  • 对于完成的任务,请大家将代码/文档以pr的形式提交至Curve的仓库,我们会定期查收并进行review给大家提出相应建议。对于优秀的提交,我们会合入代码仓库。

必选题:curve项目部署与编译

任务说明

  • 每个参与者必须要实际部署和编译
  • 所需技能:docker、读懂curve部署/编译文档

任务描述

部署和编译是参与开发前必须要掌握的。编译是代码开发、调试与测试过程中必要步骤,部署是学会使用curve、理解curve使用场景的途径。所以希望每个人都按照下列参考文档实际动手操作一下。任务提交:编译/部署成功的截图,通过issue的方式进行提交。如果在编译/部署过程中有对文档的改进建议,也可以一并添加进来。

参考资料

单机部署:https://github.com/opencurve/curve/blob/master/docs/cn/deploy.md#单机部署

编译:https://github.com/opencurve/curve/blob/master/docs/cn/build_and_run.md

选题一:代码解读

任务说明

  • 单人参与,这是一个系列任务
  • 所需技能:熟悉Curve代码

任务描述

在阅读Curve代码的过程中写一些源码解读或者自己的心得体会,一方面作为自己学习的沉淀,另一方面可以供他人参考

参考资料

建议在了解Curve的整体架构基础上去看代码

(B站直播视频:https://space.bilibili.com/700847536/channel/detail?cid=153949

(ppt下载:https://github.com/opencurve/curve-meetup-slides/tree/main/2020

选题二:代码翻译

任务说明

  • 单人参与,这是一个系列任务
  • 所需技能:了解Curve代码框架和书写规范,github使用

任务描述

针对curve github仓库中的Curve各模块的代码注释进行中文到英文的翻译,注意翻译的完整性和准确性。Curve代码中的mds模块已经都是英文注释,剩下的为 curve/src/chunkserver 、curvesrc/client、curve/nebd/part1、curve/nebd/part2。大家可以按照一个头文件和cpp对应实现为单位进行翻译,比如common.h、common.cpp。

选题三:清理代码中的TODO

任务说明

  • 单人参与,这是一个系列,每个TODO可以作为一个任务
  • 所需技能github的使用,google c++编程规范,curve文档,编译工具bazel的使用,测试工具gtest的使用

任务描述

curve的代码在开发的过程中遗留了一些TODO,可以对这些TODO进行一些清理。清理范围,include,src,test目录下,排除thirdparties目录下的第三方组件的TODO。用“// TODO”作为关键字,搜索代码中的TODO。这些TODO有些比较简单,有些难度比较大。建议先从简单的开始修复,熟悉代码的修复合入流程,再慢慢挑战比较复杂的TODO。

参考资料

github的使用,google c++编程规范,curve文档,编译工具bazel的使用,测试工具gtest的使用

这里举例几个简单的TODO任务,也可以自己搜索代码中的TODO。

  1. curve/include/chunkserver/chunkserver_common.h,把kOpRequestAlignSize放到配置文件中。
    // TODO(wudmeiao): 是否需要考虑可配置
    const uint32_t kOpRequestAlignSize = 4096;
    
  2. curve/src/chunkserver/copyset_node.cpp,Init copyset对应的raft node options放到nodeOptions的init中。
    /**
    
    * Init copyset对应的raft node options
    
    */
    
    nodeOptions_.initial_conf = conf_;
    
    nodeOptions_.election_timeout_ms = options.electionTimeoutMs;
    
    nodeOptions_.fsm = this;
    
    nodeOptions_.node_owns_fsm = false;
    
    nodeOptions_.snapshot_interval_s = options.snapshotIntervalS;
    
    nodeOptions_.log_uri = options.logUri;
    
    nodeOptions_.log_uri.append("/").append(groupId)
    
    .append("/").append(RAFT_LOG_DIR);
    
  3. curve/src/client/libcbd_libcurve.cpp,cbd_libcurve_filesize调用StatFile4Qemu接口时,判断StatFile4Qemu的返回值。
    int64_t cbd_libcurve_filesize(const char* filename) {
    struct FileStatInfo info;
    memset(&info, 0, sizeof(info));
    
        // TODO(wuhanqing): 判断返回值
    StatFile4Qemu(filename, &info);
    return info.length;
    }
    
  4. curve/src/mds/nameserver2/curvefs.cpp,RenameFile接口,把oldFileName改成sourceFileName,newFileName改成destFileName。
    // TODO(hzchenwei3): change oldFileName to sourceFileName
    //                   and newFileName to destFileName)
    StatusCode CurveFS::RenameFile(const std::string & oldFileName,
    const std::string & newFileName,
    uint64_t oldFileId, uint64_t newFileId)
    

选题四:单元测试

任务说明

  • 单人参与,这是一个系列任务
  • 所需技能:c++基础,gtest使用

任务描述

目前Curve很多代码的单元测试覆盖率不够,(具体情况见59.111.93.165:8080/job/curve_untest_job/HTML_20Report/),希望大家在现有单元测试代码(位于Curve代码的test目录)基础上,添加测试用例,使其覆盖率达到CI标准,代码行覆盖85%及以上,代码分支覆盖75%及以上。

参考资料

RoadMap中「掌握代码开发/测试工具」所列出的资料

选题五:捉虫计划

任务说明

  • 单人参与,这是一个列任务,每找到1个bug,相当于完成了一个任务
  • 所需技能:github使用,熟悉curve部署、使用、代码

任务描述

金无足赤,人无完人,代码也没有不存在bug的代码。在代码开发过程中,虽然工程师们采用了各种方式来减少bug,但是总有一些漏网之鱼。各位小伙伴,一起撸起袖子来捉虫吧。在curve部署、使用、阅读代码过程中,如果发现了bug,请通过issue的方式记录下来,如果有解决方案,欢迎向我们提交代码。

参考资料

RoadMap中「了解Curve」所列出的资料

奖励

表现优异者可以获得在网易实习的机会(人数不限),特别优异者有机会获得校招offer。我们会根据整个计划过程中提交任务的质量、参与度、提交任务的数量等为依据进行评估。

Ceph社区跟踪(2020-10-16 ~ 2020-11-25)

本文作者:本人

youtube channel

Ceph Orchestrator Meeting 2020-10-26

  • 主要讨论alpha版本发布流程(分支、pr相关)和完善文档事宜

Ceph Docubetter Meeting 2020-10-29

  • ceph df输出格式修改对应的文档也要更新:https://github.com/ceph/ceph/pull/37539
  • digitalocean的一个人分享了一个ppt,主要是探讨如何把rados message protocol相关的文档写的更清晰易懂(un-black box rados),看起来更多的是librados相关的client封装比如go或其他语言,可以方便的通过message protocol(类似网络协议)跟rados打交道而不是通过封装调用C/C++的librados api,并且让其他开发人员可以分担核心开发的文档相关工作量
  • 安装部署文档跟不上安装工具的发布节奏(ceph-deploy、cephadm、ceph-ansible、docker、rook。。。),并且各个发行版的文档适配也是个大问题
  • 有些文档的url链接失效了,需要修复,但是老版本的文档要不要处理还在讨论
  • 主要还是围绕如何让开发人员更加高效快速高质量的贡献文档方面进行讨论,但看起来并没有实际的结论

Ceph Code Walkthrough 2020-10-27

  • LibRBD I/O Flow Pt. 1 (屏幕录制效果较差,HD模式勉强可以看。。。)
  • 全部分享记录:https://tracker.ceph.com/projects/ceph/wiki/Code_Walkthroughs

Ceph Crimson/SeaStor OSD 2020-10-28

  • review pr:https://github.com/ceph/ceph/pull/37870
  • extend mapping在添加大量kv之后删除(超过一千,问题必现),会导致内存暴涨,怀疑是编码问题导致,还在分析
  • seastore性能测试工具准备,发现nbd server方案是最简单的,已经实现,可以直接对接seastor后端发送transaction:https://github.com/ceph/ceph/pull/38290 (https://github.com/ceph/ceph/pull/38290/commits/82013fa0160fa08db9d3221ec9d40de055ea02e0)
  • 智能网卡场景下,osd和client的交互模式可能要完全修改,不需要唤醒cpu就可以写盘,没有线程队列之类的东西了,每个osd有很多port,pg按port分组(shared),还讨论了nvme over fabric的好处(采用cpu模式处理io,cpu占有率方面永远达不到nvme over fabric的效果,因为它是0),nvme oF还要考虑厂商兼容性问题,不能只支持特定厂商
  • 讨论client和pg通信模型(一个client/tcp连接对应后端一个cpu core,之后转发到对应的pg进行处理,把pg映射到core,方案有点ugly,但是在修改message protocol之前只能这么做)
  • 测试覆盖率提升讨论

Ceph Performance Meeting 2020-10-29

  • new pr讨论:https://github.com/ceph/ceph/pull/37762 、 https://github.com/ceph/ceph/pull/37636
  • 删除pg速度优化:(看起来是在大量omap场景下)可以提升10倍(https://github.com/ceph/ceph/pull/37314、https://github.com/ceph/ceph/pull/37496),性能数据 https://docs.google.com/spreadsheets/d/17V2mXUDEMAFVmSC67o1rQtrWNnAm_itBgzdxh1vRJMY/edit#gid=0
  • pg log容量占用问题:要么减少pool的pg数量,要么减少pg的log长度,pg太少并发性能受影响,只能创建更多的pool,冷数据池的pg log是否需要缓存到内存中?
  • 问题讨论:一个初始集群很小的时候,应该分配多少pg、多少pool才合适?并且后续扩容要尽量减少数据迁移。
  • rocksdb kv onode缓存不释放问题:很老的kv还保存在内存中,其实只有新的热数据会被使用,比较浪费内存空间(data cache也会被挤占掉,但是data cache却不能挤占metadata cache,即使他们中很多都是老的没有用的数据)

Ceph Crimson/SeaStor OSD Weekly 2020-11-04

  • 在seastor架构下object context lock如何实现问题(BlueStore、FileStore都有这个lock)
  • EIO处理逻辑开发,发现之前的方案有问题,需要修改(其他人希望功能开发者可以把新方案整理成文档再讨论下,但是他还没写):https://github.com/AmnonHanuhov/ceph/tree/wip-ObjectStore_EIO_Handling
  • 讨论pr:https://github.com/ceph/ceph/pull/37925、https://github.com/ceph/ceph/pull/37907

Ceph Developer Monthly 2020-11-04

  • 讨论3个议题:
    • manager scalability:MGR性能问题(是否要考虑增加metric来辅助定位),以及module调试问题,太长了没全部听完
    • 讨论replicated writeback cache in librbd(有ppt展示):Intel基于PMEMs/SSDs的rbd client writeback cache方案进展介绍,librbd cache也能副本化(master、replica),master client挂了,也能通过replica节点把数据刷到osd上,replica挂了会找新的replica:https://github.com/pmem/rpma
    • 建议搞一个面板来管理开发计划和进度,否则有些人由于时差问题不好同步参加周会

Ceph User Survey Working Group 2020-11-05/2020-11-12/2020-11-25

  • 讨论2020年度问卷设计问题,有人吐槽问卷有点复杂,无关问题有点多,当前的问卷:https://tracker.ceph.com/attachments/download/5260/Ceph%20User%20Survey%202020.pdf
  • https://tracker.ceph.com/projects/ceph/wiki/User_Survey_Working_Group
  • 这个就不关注了,等调查结果出来再看

Ceph Crimson/SeaStor OSD 2020-11-11

  • 任务交流,主要是提交和review pr

Ceph Performance Meeting 2020-11-12

  • cbt的数据库支持讨论,要能把测试结果保存起来,并且可以支持后续的自动化分析
  • 讨论给osd加socket command或日志,来获取benchmark测试过程中的性能统计数据,当前已经有了一些了,新的要怎么加?
  • 新增pr讨论(performance label的那些)https://github.com/ceph/ceph/pull/38025、https://github.com/ceph/ceph/pull/38477,。。。
  • wpq、dmclock scheduler对比,osd_op_num_shards=2,osd_op_num_threads_per_shard=8场景下的性能测试数据结果review、讨论,看起来dmclock效果比较好,时延和吞吐都有提升,恢复场景也能控制速度,等最终pr出来了再深入分析吧
  • 讨论这个benchmark工具:https://www.vi4io.org/tools/benchmarks/md-workbench
  • rocksdb compaction问题讨论

Ceph Science Working Group 2020-11-25

  • 主要讨论ceph在科研相关应用场景下遇到的各种问题,如可扩展性、可升级性等等

邮件列表

https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/

  • Module ‘cephadm’ has failed: cephadm exited with an error code: 2, stderr:usage: rm-daemon [-h] –name NAME –fsid FSID [–force] [–force-delete-data]:无人回复
  • RGW with HAProxy:报错invalid response,无人回复
  • Recommended settings for PostgreSQL(rbd场景跑数据库调优问题):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/PLYPZOTPWEPEH5BPKTIFVRSSMU3TDLFH/
  • OSD host count affecting available pool size?(属于初级用户问题)
  • Mon DB compaction MON_DISK_BIG(mon db占用了超过15G空间导致warning,我们也经常遇到,他的是12.2.8版本;在线压缩效果不明显,离线压缩也可以试试,但是主要是因为他集群中有一个osd down了好久没踢掉导致的):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/6EHBAIJG3BBYQ7XCMDQAVJKDVQGYXUKV/
  • Problems with ceph command – Octupus – Ubuntu 16.04(初级问题,mon集群没启动好,导致ceph命令超时,重启就好了):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/IO6FCOS3ZIZFQ5HRJN64LPNEEJAYKLJZ/
  • pool pgp_num not updated(调整完pgp_num之后没变化,应该是集群空间不足导致backfill不能正常完成导致的):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/KWUUXNCHUR5E5MURKHEY3LECJCNFTINT/
  • Difference between node exporter and ceph exporter data:无人回复,应该是关于prometheus插件的问题,也是初级问题
  • 有人反馈了一个15.2.3版本内存泄露问题,会导致osd无法完成recover,问题还没有解决:https://tracker.ceph.com/issues/47929
  • 6 PG’s stuck not-active, remapped(应该是CRUSH经过最大尝试次数还找不到足够的osd来满足min_size要求,同时down掉的盘太多了):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/F34WC6YSFBMDCT5S7YNXLRKEFTROSYXO/
  • Need help integrating radosgw with keystone for openstack swift:暂时没有人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/RI3J5UCRGE6ELNZYX2UISEPCXDE3MQY5/
  • RFC: Seeking your input on some design documents related to cephadm / Dashboard:https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/3BN2UCD3N7XGIXJSTWWOL3MMCMNLYGRX/
  • ceph octopus centos7, containers, cephadm:(问centos7上跑O版本应该怎么部署,答可以用cephadm,用这个就会用到container,或者手工包安装就不会了)https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/AIB72SZFS53E6SWZKBKGJJ7I4QPLZA4P/
  • TOO_FEW_PGS warning and pg_autoscale:(缩容pool导致pg数太少导致的warning告警该怎么处理,暂无人回复)https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/PRHZLOJWCDO7NLRWAQ4HAQM5C3YX73AU/
  • Ceph Octopus:cephadm部署问题,刚开始的时候就一块网卡,后面加了一块,怎么修改配置? https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QL5UUZ3LKLLA3L6U3TOBKDVHHQIIR5IF/
  • OSD Failures after pg_num increase on one of the pools:(14.2.7版本扩容pg_num之后崩了。。。只要不设置norecover osd就会assert挂掉,估计是个bug,有一个人回复但还没有进一步结论)https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/EPAA6MZW3HVG66F3DR2N3OGTTET5VST7/
  • desaster recovery Ceph Storage , urgent help needed:(又一个把自己集群玩崩了的。。。这个是因为改了机器的ip地址导致的,mon集群想办法恢复后ceph -s里面都没有osd了,暂时还没有结论) https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/EEHQ4WLJOBTNXBQBLTDQH6UK5KSYLIJ4/
  • Large map object found:(rgw问题,omap太大导致了warning,有人建议对桶进行reshard,之后就好了):https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/PVP6F5FTEJNDUDHQEAUXIC5V2BFSQUG5/
  • Ceph and ram limits:osd和mon占用内存太多导致oom问题,暂时没有结论 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/MMC22TPSP6VKXI6RNX4O224UBV5IHCCA/
  • Urgent help needed please – MDS offline:这个问题是12.2.10版本的,对我们有参考或者警示价值,主要问题是集群突然写满,mds重启后replay journal阶段有个dentry太大占用了太多内存,然后mds节点内存只有128G就OOM了,最后这个人根据其他人建议加了一块800G的ssd做swap,跑了3~4个小时恢复了集群: https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FZE4RGXJMKMWVIBEQDDVVGBMTOWYE7KE/
  • Ceph cluster recovering status:又一个集群崩了的,暂无人回复
  • The feasibility of mixed SSD and HDD replicated pool:有个人提了一个比较“奇葩”或者思路清奇的问题,是否可以把ssd和hdd放到一个副本pool里面,ssd做primary,hdd做replica,用来保存只写一次的数据(写的时候慢点没关系),之后就是只读取了,读取的话ceph默认从primary读,就可以发挥ssd的性能优势了,可以通过设置primary affinity把主都放到ssd上,我觉得这个思路确实有点意思,感觉理论上是可行的, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/UZG3OKIEBH5VHP3U2B7R42NJP6MVG6Y6/
  • Ceph docker containers all stopped:这个人描述问题不太清晰,有人猜测是cephadm部署的集群,还没有进一步结论,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TUUYDRO47FZJ6COWKHQMY4JXWZDFKGIU/
  • Question about expansion existing Ceph cluster – adding OSDs:集群扩容速度没跟上使用量增长速度导致的问题,也讨论了添加osd的常规步骤, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FGOODUAH6XVXXKF73SGCY6ECD77L33RE/
  • Hardware for new OSD nodes.:讨论nvme+sas盘的场景下,该如何配置,对我们有参考价值 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/KYHLBPYYPFSW2E6W7TNYKSW3UF5QXWIC/
  • Ceph not showing full capacity:数据不均衡导致的集群可用空间不符合预期, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FGC3AV6J7DYPOQR5TTIKL45ARFBQXY44/
  • Cephadm: module not found:cephadm问题,新版本已修复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/B3EE45F5TKA6VQCHZOP7RQ7IDJUVPSPZ/
  • Switching to a private repository:cephadm问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/OM6PIRHRB6Y7EYXX6LJPBDWA2HL3XEC5/
  • OSD disk usage:N版本集群可用容量问题,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ZWSXKCEUVUS6JVQV5O5U2KA3IJV3T6XT/
  • Ceph Octopus and Snapshot Schedules:https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FX3AFHYQXRRU3636WTQWI66PQL2KLKB7/
    • 他提到的是这个功能:Mirroring now supports a new snapshot-based mode that no longer requires the journaling feature and its related impacts in exchange for the loss of point-in-time consistency (it remains crash consistent). https://docs.ceph.com/en/latest/releases/octopus/#rbd-block-storage
    • 还有人回复提到了cephfs这个快照调度功能(定时快照之类的),backport还没合入O版本:https://github.com/ceph/ceph/pull/37142
  • Strange USED size:对USED的值有疑惑,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FYCXRYJKWRCWAARK4MZEEFQWISVRLSMG/
  • Fix PGs states:一堆down、incomplete、stale、unknown状态的pg,不知道咋处理, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/Y4QLZPMCBCL6FV6NPI3XZRQWZ2NSN3OJ/
  • pgs stuck backfill_toofull:rgw集群osd满了,有人回复帮忙解决, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ZRVWWECTFQNWUURG7PDGHIWHZ2LTDAIE/
  • RGW seems to not clean up after some requests:rgw 503错误问题,暂未解决 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/I7DBUXTMUA5ONO7IXLWKKMZD6VFLG3QS/
  • cephfs cannot write: 15.2.5版本集群状态OK,pg状态active+clean,但是集群无法写入,有人回复怀疑是挂载目录的权限问题 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/CMBICTKTMJZQ4BBXJLYNVKIHEP2OGR44/
  • read latency:讨论如何降低读时延,以及小io顺序读和随机读的区别(预读机制) https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/LA5BKFZTLCWJE4ZKKFIYYLJ7RQSTTQDD/
  • Monitor persistently out-of-quorum:mon集群无法选举成功,原因是网络问题(多个交换机的MTU不匹配导致) https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QEMRZJWKQ4R6CGOFEF62UVM3BRI7ZJ6S/
  • How to recover from active+clean+inconsistent+failed_repair?:pg不一致之后没办法repair,出现的场景是全部osd掉电,有人猜测可能是某个盘有坏道导致3个副本都不一致,建议先用smartctl 找出来有问题的盘,试着用ddrescure/badblocks命令把原来盘上的数据恢复出来,在重新启动osd,最终这个问题也没有解决,也不能标记为lost https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TI6RM5GUAX5PGERCQVZZ6JMZXQQ3O7OZ/
  • Does it make sense to have separate HDD based DB/WAL partition:纯HDD的osd是否要把db/wal放到独立的分区,有人回复没必要,不能提升性能, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/Q7M425C7TBBQKWJGVHGPOAB3USGD5LFP/
  • Updating client caps online:怎么在线更新auth caps,有人给了操作步骤,可以成功执行 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/MVMHMAWMLENMOJRJAP7X235AWXTDAAPX/
  • Restart Error: osd.47 already exists in network host:cephadm部署后重启osd报错,暂未解决, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/LRMMYVQQMWDU3BZJ7MXZ3PO2FDPOEXRM/
  • Inconsistent Space Usage reporting:nbd盘的df结果显示的使用量和ceph集群使用量不一致,有人建议他用fstrim回收下空间, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TV3DY2OB3ENL2PPOMIN3OA6RSKXPJLEQ/
  • How to reset Log Levels:日志文件太大调了日志级别到0,怎么找回默认值?有人回复用 ceph config dump命令, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/YMEJR3I4I52LHHH7R5TYHG2YS24GGDP6/
  • Ceph 14.2 – stuck peering. :pg卡在peering状态,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/KW7B5B42AYPNA63W5LVNIXMYKREPYD5D/
  • bluefs_buffered_io:问这个配置项的用途,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/HBGRMUUUHWBZ3VMHGUM5EZFM4XDQ63AI/
  • RBD image stuck and no erros on logs:集群状态OK,rbd卷无法读写,不知道该怎么处理,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TAAGMSVVJ2V7UICT5WVA2IMRSLMENVHL/
  • Ceph flash deployment:全闪存集群部署调优, https://tracker.ceph.com/projects/ceph/wiki/Tuning_for_All_Flash_Deployments 这个文档有点老了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/3Y6DEJCF7ZMXJL2NRLXUUEX76W7PPYXK/
  • File read are not completing and IO shows in bytes able to not reading from cephfs:cephfs集群做异常测试,kernel client挂载模式,设置nodown、noout、norecover、nobackfill之后停掉整个集群,重启恢复healthy之后client端无法读写已有的文件,新写入正常, 暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/GY6ZGNIRGJQVWZCSWG3VKISACYVP2QYM/
  • cephadm POC deployment with two networks, can’t mount cephfs:如题,有人回复建议他重新看下指导文档步骤, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/3UBRRNYV52SO5OGTWKV6DPRSZLEGBZ6E/
  • RGW pubsub deprecation:如下两种bucket变动的通知机制哪个更好?
    • [1] https://docs.ceph.com/en/latest/radosgw/notifications/ 主动推送模式,是否应该优先选这个
    • [2] https://docs.ceph.com/en/latest/radosgw/pubsub-module/ 被动拉取模式
    • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/YQEW7DE4SOWERD7KH64MCRIVHSXWMUCZ/
  • high latency after maintenance:一个机柜停机维护2小时(上面5个node),停机前noout、noreblance已设置,开机后集群时延升高到20多秒,20分钟后恢复正常,不知道为啥。猜测应该是在做recover导致的hdd拉满
    • We’re running nautilus 14.2.11. The storage nodes run bluestore and have 9x 8T HDD’s and 3 x SSD for rocksdb. Each with 3 x 123G LV
    • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/R2OEG6RE4EKKGOAVG2H4LQ5MNYABKX7X/
  • Problem with checking mon for new map after upgrade:N版本升级到O之后,osd启动后卡在1234 tick checking mon for new map阶段
    • 已知问题(执行ceph osd require-osd-release mimic可以解决):https://www.mail-archive.com/search?l=ubuntu-bugs%40lists.ubuntu.com&q=subject%3A%22%5C%5BBug+1874939%5C%5D+Re%5C%3A+ceph%5C-osd+can%27t+connect+after+upgrade+to+focal%22&o=newest&f=1
    • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/EABVI566VYJ4NA4UMPCOLE2SGNGA5MCB/
  • msgr-v2 log flooding on OSD proceses:日志太多,不知道怎么调整配置 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/VYEIS6MPIQR4FG5HIRLAUFEL6YIH2J5G/
  • NoSuchKey on key that is visible in s3 list/radosgw bk:15.2.3版本(L版本正常),s3cmd ls和radosgw-admin bi list都可以查询到对象,但是curl下载的时候报404,https://tracker.ceph.com/issues/47866,https://tracker.ceph.com/issues/48331,https://github.com/ceph/ceph/pull/38249, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/WQ2F2GWI2WRDAGLVRDA7PAAGBJTNN4PI/
  • Low Memory Nodes:osd节点内存不够怎么解决?(有人建议修改配置:ceph config set osd osd_memory_target 1500000000) https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ERK3OCTPE4AR7HXM254M4D3PURALGNC5/
  • ceph command on cephadm install stuck:cephadm问题,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/CDIWUO2T2VFBOU4P5SZMKU56CX6VXTO4/
  • Dovecot and fnctl locks:Dovecot这个应用跑在cephfs上的问题,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/WBU2BEWUA3HEQPP62SZ44VNADGQM6U4D/
  • pg xyz is stuck undersized for long time:加盘之后又挂了一个osd之后pg一直没有clean,看着应该是backfill tofull导致的, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/POIYKF4DP4H7L2ROTBK3OD2DYFULFOPL/
  • Multisite sync not working – permission denied:rgw这个功能之前的版本还可以用,升级到15.2.4版本之后不好用了,暂未解决, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/RXRF54FFJIUTQDQXLZ3YIJZTYXOPLEML/
  • Mon went down and won’t come back:问题解决了,但是不知道根本原因, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/4V5X6M26VUNXAUDHDEMVN6P3YIHXUA2D/
  • Ceph 15.2.3 on Ubuntu 20.04 with odroid xu4 / python thread Problem:ceph命令超时,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/7RLG5KJ5FAOIIFIJNUOVUBMQVDFBSIBE/
  • move rgw bucket to different pool:想把rgw的bucket迁移到其他pool,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/AZGFB32O4HWLTDK2GTPIQXZJSMEVMQYV/
  • cephfs forward scrubbing docs:吐槽文档写的不清晰,
    • ceph tell mds.cephflax-mds-xxx scrub start /volumes/_nogroup/xxx recursive repair,与多mds有冲突,文档没写,另外这个功能本身看起来还不完善
    • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ME6NOEIM4UXC5F5RX3EMNQ23ICL5H3Q6/
  • The feasibility of mixed SSD and HDD replicated pool:还是那个ssd做primary、hdd做replica的问题,在读多写少的场景下提升读性能(通过crush rule来实现primary落在ssd上,而不是通过修改affinity),有人回复已经这么玩很久了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/IGLHDCD2EFS3CHIFWFZ4NZM5IAHXWPFX/
  • disable / remove multisite sync RGW (Ceph Nautilus):原来用的是multisite sync,后面改用rclone了,想保证数据安全的前提下去掉multisite sync,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/BTLWEMDR3AAC2QT4EGLWRNGCUV7I7ZWU/
  • cephfs – blacklisted client coming back?:14.2版本evict之后reconnect问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ROYV6RUUT5VHQFNL2MPABL36EN4GZ3FZ/
  • Slow ops and “stuck peering”:pg卡在peering状态无法恢复正常,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/4VHI4LJOF7B5LHVEVL4BVI6H5EXH5PEJ/
  • RGW multisite sync and latencies problem:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/UDG5VC5VV3W7LJZF546UU3LNBHSCPXKB/
  • Ceph RBD – High IOWait during the Writes:用ec pool跑rbd,有人回复EC pools + small random writes + performance: pick two of the three.,还有人建议用cephfs, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/25CCEUNNUXTRCGGKM4H7LYU6GTEF6RRG/
  • safest way to re-crush a pool:怎么配置crush规则问题,初级问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/MSMBLWB4KICHNP5K6SR474MZEM6FKHBG/
  • Is there a way to make Cephfs kernel client to write data to ceph osd smoothly with buffer io:page cache满了之后大量数据同时flush对osd造成压力,有人回复可以调整这两个参数vm.dirty_bytes、vm.dirty_background_bytes, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ROFF5IK7MCHM6BVHT2UVZKPJKMCSDIJX/
  • _get_class not permitted to load rgw_gc:版本混用导致的,O版本降级之后恢复了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TDDH6YRK2M6EFKDH4TYMB4ZEFJ2XEE5R/
  • Nautilus – osdmap not trimming:osdmap不会trim问题,有人回复有个bug,如果集群有osd down的话就会这样,v14.2.13 has an important fix in this area: https://tracker.ceph.com/issues/47290 , https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ROINIUNPI36Z24YWGAYF6ZZB7LMQ6EZE/
  • newbie question: direct objects of different sizes to different pools?:这个人想把不同大小的对象放到不同的pool,比如小对象放副本pool,大对象放ec pool,想问s3 client或者rgw能不能做到根据对象大小自动分配pool, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FN4NF2M35MYCLPDULBVGPSS622UWPLOC/
  • How to use ceph-volume to create multiple OSDs per NVMe disk, and with fixed WAL/DB partition on another device?:有人回复用这个命令 ceph-volume lvm batch –osds-per-device 4 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 –db-devices /dev/nvme0n1, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/SVHR3XAPAIPSXDKIWEIFYVGX2EZAHQAB/
  • How to run ceph_osd_dump:N版本报OSD_SLOW_PING_TIME_BACK,想通过dump_osd_network 命令查看网络状态,官方文档写的mgr可以,其实应该是osd,文档有误 https://docs.ceph.com/en/latest/rados/operations/monitoring/#network-performance-checks , https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/IGEXQLDAMLIZQBBA6DYBQTK4EWQBBRAL/
  • Rados Crashing:N版本删除对象的时候rgw服务挂了4个,有人回复可能是这个bug导致的,https://tracker.ceph.com/issues/22951, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QVIMMFKQ7GA3POXUX5QLLSFQVHTHOEKR/
  • Autoscale – enable or not on main pool?:如题,暂无人回复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/PDQILIX6RCGOSPFNAKD2NSSBH3SFUMWQ/
  • Cephfs Kernel client not working properly without ceph cluster IP:IP配置问题,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/3XSSJ745CPCM2L25TOLN2DPX4KYTVBYL/
  • question about rgw delete speed:没有明确结论,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/HAFHHL5VL2KZBVU7WQRL2TOB7XD4Y6AM/
  • OverlayFS with Cephfs to mount a snapshot read/write:这个没太看明白,应该是想用cephfs做overlayfs的只读layer,本地目录做读写layer,然后内核版本有问题,升级后解决了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/BIOBKO67OFYMZ245RIH4XG6BANW7HCAY/
  • How to Improve RGW Bucket Stats Performance:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/WTO2K5FP77DKA2DV4HBCYATACDWCYXOZ/
  • monitor sst files continue growing:加盘之后mon db问件越来越大,compact也没效果,有人回复建议先把集群搞成healthy状态,然后把mon db的盘换成ssd的(compact速度太慢了),之后就好了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/GTV6YD7V2GLWKFX4ROPRMS52YJOOP6AA/
  • which of cpu frequency and number of threads servers osd better?:如题,这类问题本身就不好回答, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/EXWC2YJYFC6RUVSAUYLQWN2DHH4A2GG3/
  • Problem in MGR deamon:O版本MGR挂掉问题,暂无人回复 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/H3UKEJAXATLF5GPIF5ALC5D2R3NBFD4D/
  • Beginner’s installation questions about network:https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/2U23VVLSN653CZ6JH3C2NTUGSGKYR3XP/
  • build nautilus 14.2.13 packages and container:打包问题,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QSSPPXBOP3AZFIUGGSYQWZGZLASU6XWD/
  • Mimic updated to Nautilus – pg’s ‘update_creating_pgs’ in log, but they exist and cluster is healthy.:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/OZRAFZ7KSOYWB6RO6S77KVD4T52YHTNP/
  • OSD memory leak?:怀疑M版本内存泄漏,osd内存会缓慢增长,暂无结论, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TPIFMPQ6YHEK4GYH5LA6NWGRFXVW44MB/
  • How to configure restful cert/key under nautilus:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/WQZE23MHTVZ6GPXPA36XU7UCTWTHRWL5/
  • CephFS: Recovering from broken Mount:14版本client连接15版本集群,网络故障后,无法恢复,只能重启物理机,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/NBGPVFYDA3MBEQF4DEA4FUYMGPAVOSYC/
  • Bucket notification is working strange:O版本问题, https://tracker.ceph.com/issues/47904, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/XNEMWNL7ZKW6Y5MWZ5FQWO7JCOWGADKB/
  • Reclassify crush map:暂无人回复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/46HQ375OQDQJ4AZ4CIT7MKCVJSONYUXK/
  • Ceph RBD – High IOWait during the Writes:这种问题本身就没有什么可以明确答复的, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/57IQ5HWXTOK77BYI6DS5VY5EETSEKCPY/
  • (Ceph Octopus) Repairing a neglected Ceph cluster – Degraded Data Reduncancy, all PGs degraded, undersized, not scrubbed in time:4个osd做了一个2+1的ec pool,然后大量pg进入degrade状态, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/WDT475WDZXU4VTYAG6BZDSYDA6TTHABU/
  • Ceph EC PG calculation:EC pool的pg数量怎么计算的, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/XHYKS7KK7SJNQWTHLHPFZDGWWUZQNG7M/
  • Unable to clarify error using vfs_ceph (Samba gateway for CephFS):Samba gateway for CephFS问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/MM7DPKL6IKIZEDWQNIREMPCHFHO5SHOH/
  • Module ‘dashboard’ has failed: ‘_cffi_backend.CDataGCP’ object has no attribute ‘type’:与ceph无关的问题,是pyOpenSSL 版本问题,已解决, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/53ZKGBQLNOX2N4RQAXHUDXKT4VO2ZXAT/
  • Not all OSDs in rack marked as down when the rack fails:猜测应该是没有足够多的osd把关掉的rack上的osd上报为down状态, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/HZXM2DQTNKE55CS35IJMJKYVEO7237VQ/
  • MONs unresponsive for excessive amount of time:一个mon停服45分钟之后再启动,加入集群后导致mon集群无响应达10分钟,MDS也无法连接mon集群,IO hang了10分钟才恢复,不知道原因,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/RLZUWD4JNWUJY77U6SYOKU25VOZHITEK/
  • Using rbd-nbd tool in Ceph development cluster:rbd-nbd命令怎么在vstart开发环境使用, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/AN3WQOBHWHUWZQOHA4GYELCYHSWBDEVY/
  • CentOS 8, Ceph Octopus, ssh private key:cephadm安装问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/BEEYGGDDY6LXJNZKM5WONUO5APUNLU6H/
  • MGR restart loop:M版本停服一个mon节点导致MGR反复重启,1天后才恢复,怀疑是跟心跳超时时间有关, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/P6K4MNSGXHNLCXOEP2U4MO2YS4EYVQRZ/
  • Weird ceph use case, is there any unknown bucket limitation?:ceph能否支持5万个bucket?有人回复说可以,但是要用nvme做metadata pool, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/CJFJ2XFAPCWQ3GBJ7GAAKIXTZT7K7JZ5/
  • EC overwrite:问这个功能是否可用?会不会有问题?有人回复这个可以用但是没啥用,https://docs.ceph.com/en/latest/rados/operations/erasure-code/#erasure-coding-with-overwrites, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QRK2D73TNWPHPXSITHLIAS5WBDJA4ZUQ/
  • Slow OSDs:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/MUO3WPXQZNYMEKORIGHJIJ2DVWGJVC4U/
  • BLUEFS_SPILLOVER BlueFS spillover detected:14.2.8版本报这个warn,手工compact可以修复,但是得反复做,有人回复这个问题已经讨论过多次了,后面14.2.12修复了,https://github.com/ceph/ceph/pull/33889、https://github.com/ceph/ceph/pull/37091,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/Q4QP3SFHGZUTPGNWVJ4YI4DCJESKTW5H/
  • newbie Cephfs auth permissions issues:有人回复要先enable application cephfs, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QLYDHKWPAYZAQHPMJX4CS3J45LZEFHXR/
  • Mon’s falling out of quorum, require rebuilding. Rebuilt with only V2 address.:暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/5X4HXXKHHVLFAQCCEZWX4BZJVRWZ455R/
  • EC cluster cascade failures and performance problems:14.2.11版本spillover问题、osd down一个导致其他也会跟着down,性能也比14.2.8版本差,只能回退,有人回复问他是否删除特别频繁,他说是400T数据每1~2周就循环删除一遍,暂无结论 https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/YZRC3SUXGW3GSHDCQEN5BDCOAEBD74X7/
  • one osd down / rgw damoen wont start: 14.2.13版本,down一个osd导致rgw卡在启动阶段,暂无结论, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/BPESDVBVRYNJLFPJM7XAUM2CETNIKOOR/
  • CephFS error: currently failed to rdlock, waiting. clients crashing and evicted:smaba+cephfs问题,暂无结论,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/D2RTMXELQT2RX66ALTUCNGTKEQAK3YFZ/
  • The serious side-effect of rbd cache setting:开启rbd cache之后,rbd bench测试抖得很厉害,关掉之后就平稳了,之前我们也遇到过, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/VI4ZOXQN4UADOWZK6MQXUEZLHSD6DOXW/
  • Multisite design details:找相关资料,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/EJQTR3ZV74LDHDEGRYJTPL7XWW2CA7HU/
  • Problems with mon:mon集群无法选举,重建有问题的mon后恢复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/3UOD4U46YS5GVEUGGFJI4YOJ5W4H66V3/
  • Manual bucket resharding problem:bucket reshard过程中Ctrl-C停掉了,之后没办法再次reshard,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/C2JSWSZOZO42GM22K3NUKJMA4IAPJP7G/
  • question about rgw index pool:index pool的硬件配置问题,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/POJATK2SLJYDWR2VG6LJKBSXNWB6XQ4S/
  • using fio tool in ceph development cluster (vstart.sh):初级问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/2S7T2XCYLDJY6QZIBB4P3KOLILOQA5WT/
  • multiple OSD crash, unfound objects:15.2.4版本,讨论了好久,看起来也没啥结论, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/QHFOGEKXK7VDNNSKR74BA6IIMGGIXBXA/
  • Sizing radosgw and monitor:rgw和osd的数量比例多少合适?暂无人回复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/KBZCLLQL72RSI5SVZSTFHVMM66YIRIPR/
  • HA_proxy setup:暂无人回复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/HGELLTZZCRSTFSZWHRVGHW3PX7JOVWO7/
  • PGs undersized for no reason?:小版本升级之后的问题,原因是osd跑到了其他root下, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/VN5B5LUL37YZSQZNY4O6FXWFMO4XQFBL/
  • ssd suggestion:QLC的ssd注意事项,有人回复主要注意下生命周期,容易坏, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/33AR2JWCVMOGPZUYI7XIZAI6ANAEQKZY/
  • Prometheus monitoring:对字段有疑惑,暂无人回复, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/NWZ23WESBA4J4NEUE4VQX6F4WJ6XIAYY/
  • Cephfs snapshots and previous version:问samba的cephfs snapshot插件在centos8的包里没有,是否稳定了?有人回复这个插件稳定的,重新自己打包就好了, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/AWGAV7YSM7EMYSQZHBXZU2OJMCA4Z4PO/
  • Documentation of older Ceph version not accessible anymore on docs.ceph.com:老版本文档地址问题, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/FZYE2BEDU5Y4EVJB6RY4X7Z2WDG4O5VG/
  • Unable to find further optimization, or distribution is already perfect:8T和16T盘混用问题,利用率不均衡,暂无结论, https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/Q6GUF5UIXHY5D4SAP5RAYVYJURS6LU7Z/
  • Certificate for Dashboard / Grafana:暂无人回复,https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/AGCDM46OXOU4RMW7JVZKXJWU4GP6I4SF/

https://lists.ceph.io/hyperkitty/list/dev@ceph.io/

  • can we remove the fmt submodule in master?:chai kefu回复不行,seastar依赖libfmt,xenial发行版的包不够新,https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/YLFSJNRDVH327DEYCHYLRMBHRERZPMZB/
  • Bucket chown:问为何不backport这个pr到N版本 https://github.com/ceph/ceph/pull/28813,答复是依赖太多,commit也多,需求不强烈,建议升级到O版本, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/GJMVENAQLJ4AK3ORKZXFZ7XUYBQX6HMT/
  • Bug #47586 – Able to circumvent S3 Object Lock using deleteobjects command:这个人提了个bug,对自己服务影响比较大,想自己修掉,先问问看有没有人已经在解决了。 https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3JKGTQOBXTJFXM4YU2X4RZRPORKZGEN5/
  • RGW vstart.sh failed to start:MGR数量没有设置为0,导致一直等待mgr启动,由于编译选项没有加mgr的,导致启动失败, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/HIOSNVN3KKPKQHZNDBU7OLR7NHUQJH37/
  • RGW starting issue:开发环境启动rgw失败,暂无结论, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/TKLNMGCTOQII3MSVVAK3FTN3BAB5KR3A/
  • RFC: Seeking your input on some design documents related to cephadm / Dashboard:征集意见讨论如何完善cephadm、dashboard相关文档, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3BN2UCD3N7XGIXJSTWWOL3MMCMNLYGRX/
  • Testing Roles S3 APIs:(提交了一个PR for syncing roles in a multisite env with https://github.com/ceph/ceph/pull/37679)怎么补充测试用例,暂无人回复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/TBNOABDBRN6QQTCW7WWLTWGIFJ5MWGK4/
  • make-dist hangs:暂无结论, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/7TGWYZ6XB4BY6QK5VKYSGVMUVOQUZOT7/
  • ceph_crc32 null buffer:问null buffer为啥还要计算crc?暂无人回复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/BQZGM5BH67MCTOQO6F53A5WI7W72BGLL/
  • nautilus cluster one osd start up failed when osd superblock crc fail:如题,暂无人回复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/YXRMHFJGYL6AERX7GWYU7I7DN7IIEE6B/
  • error executing ./do_cmake.sh:编译问题,原因是Python3依赖问题,you could either use -DWITH_PYTHON3=3.6 or just ignore this option.,https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/PTQXEFXPZJOCS23PKZICYSBKRXBNJKK6/
  • v14.2.12 broken due to mon_host parsing. .13 release?:https://tracker.ceph.com/issues/47951,https://github.com/ceph/ceph/pull/37816,建议把这个pr backport到14.2.13版本,回复是已经加入了。 https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/PR77FQUGQZXWZWDE4BYOAE5JPPJIXDZZ/
  • cephfs inode size handling and inode_drop field in struct MetaRequest:没看懂,关于kcephfs的,Yan, Zheng回复了, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/JJUFZHDWY3KASGAOJNGWHIBFBGD7HVTF/
  • “ceph osd crush set|reweight-subtree” behavior:命令不生效,提交了bug, https://tracker.ceph.com/issues/48065, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/UMXYYCHEQZUHB5IFUBE6QDFSCPPQLJO6/
  • radosgw keyring configuration parameter:提交了一个ceph config generate-minimal-conf命令的bug, https://tracker.ceph.com/issues/48122, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/NVPSANZHCRXNCVABQCAH7Q3UC6SYFYF2/
  • building RPMs locally:打包问题, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/YWLPAAPQVMTHEV4LOCGSJNY4TTCQYVU7/
  • make check failure:测试用例失败,已提交修复代码, https://github.com/ceph/ceph/pull/38021, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/BF36L2SPYVDGSCFACWRDIWICQMZQI55A/
  • Pull Request Auto-labeling:给pr自动添加label, 应该是根据改动的代码路径来判断的,https://github.com/ceph/ceph/pull/38049 and
    https://github.com/ceph/ceph/pull/38060, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/RCCK7XLAHV6EP46MPY3K2KXP6EBX2POF/
  • Design discussion about replicated persistent write-back cache in librbd.:如题,写的比较细,可以看下, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/C6BC3SPPDIZJAJ45RHAGKUQK43BIV2EL/
  • RGW Lua Compilation error:有人回复新的提交已经修复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/PI6LOPVQIOVZXL65CE3HYHVVCWEPLE47/
  • Do rados objects have a version or epoch?:暂无人回复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3Z27XMVFXSVDK65WA3C2RXJFXE3Q4WUQ/
  • using fio tool in ceph development cluster (vstart.sh):问fio能不能用在vstart环境下,有人给的参考,https://github.com/ceph/ceph/pull/34622#issuecomment-625893545, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/2S7T2XCYLDJY6QZIBB4P3KOLILOQA5WT/
  • Ceph containers images:docker镜像维护问题,不够全, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/W4APLWWM6GDMZXNDJZUVQR7A7NXZWJR2/
  • PR test failure: https://github.com/ceph/ceph/pull/37933 这个pr的test失败了,但不知道为啥,本地是好的, 暂无人回复, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/T632DRI5USSVGQRPBJ4GX2I3HDTXLZYS/
  • Best way to contribute bunch of miscellaneous fixes?:移植15.2.4版本到arm平台,遇到很多bug,怎么提交pr比较合适?一波全提交还是一个一个来(会很多)? chaikefu给出的回复是ceph没支持过arm,还在讨论要不要测测看, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/4IRKQIIZO4XKGQTVI5LCIHX3FRPIYDA6/
  • run run-cli-tests in development environment:这个命令不会玩,chaikefu给的回复是参考这个https://github.com/ceph/ceph#running-unit-tests, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/24AJ4UIVCSMHBASXLL3DMTMH3YHFJE3F/
  • Compiling master with Clang….:如题,暂无结论, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3DFVJN7CVKC7L4VH7RYSZR75GKA42HM7/
  • A Query about rados read op API behavior:can we feed the same “rados_read_op_t” instance to “rados_read_op_operate()” multiple times with different oid?” i think the the answer is “no”, https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/77SKXKCYR2GGA2D7HAZYKCCEWG4BKIB2/

社区博客

  • Welcoming Ernesto Puerta as the new Ceph Dashboard Component Lead:https://ceph.io/community/welcoming-ernesto-puerta/
  • https://ceph.io/releases/v14-2-14-nautilus-released/
  • https://ceph.io/community/v15-2-6-octopus-released/
  • https://ceph.io/releases/v14-2-15-nautilus-released/
  • https://ceph.io/community/v15-2-7-octopus-released/

master近期合入代码

  • 有点多,不一一分析了:https://github.com/ceph/ceph/pulls?q=is%3Apr++is%3Amerged

Ceph社区跟踪(2020-10-01 ~ 2020-10-15)

本文作者: 吴 宏 松 https://zhuanlan.zhihu.com/c_1267088333848641536

youtube channel

https://www.youtube.com/c/Cephstorage/videos

  • Ceph Tech Talk: Karan Singh – Scale Testing Ceph with 10Billion+ Objects
    介绍了10Billion+级对象下对象存储的测试

Ceph Performance Meeting 2020-10-01

  • 讨论新pr:
    • https://github.com/ceph/ceph/pull/37274 (ceph-volume: retrieve device data concurrently)
    • https://github.com/ceph/ceph/pull/37496 (osd: optimize PG removal (part1&2 of 2))
    • 由于rocksdb的wal以及compaction的影响,所以考虑用myrock替代rocksdb(目前对myrock的理解应该是有限的,准备接下来好好研究下myrock)

Ceph Docubetter Meeting 2020-10-14

  • 新pr:
    https://github.com/ceph/ceph/pull/37451/(make cephadm faster and more scalable )
  • 改变了guthub的习惯,以后提doc相关的pr signed off by可以不再需要了
  • ceph文档的链接出问题了,不过他已经修复好了
  • 提到cephfs文档的问题,想parick donney检查并更新一下

Ceph Orchestrator Meeting 2020-10-05

  • 当前rook module(https://docs.ceph.com/en/latest/mgr/rook/)默认还没有enable,原因是还有一些bug没有解决。
  • redhat的人说他们那边只有3个人工作在编排这块,所以没有足够的人力同时进行cephadm以及rook的工作,他们会把工作重心几乎都放在cephadm
  • 目前在进行nfs ganesha在rook上工作的测试
  • 一些编排的指令不能工作(比如不能list host和进程),已经修复了这些bug

邮件列表

https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/

  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/ ceph大规模(10Billion+ Objects)下的测试情况
  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/7IMIWCKIHXNULEBHVUIXQQGYUDJAO2SF/ osd_pglog导致的osd内存增大,所以考虑要不要增加一个配置项osd_pg_log_memory_limit,使得当pg_log对应的内存空间较大时,可以主动减少
  • https://www.mail-archive.com/ceph-users@ceph.io/msg06745.html 发现集群有slow request,进一步测试发现当把读和写分开放到两个pool则不会出现这种问题(我觉得可能是对象读写锁的问题)
  • https://www.spinics.net/lists/ceph-users/msg62766.html 有人询问cephfs多文件系统是否成熟, Patrick Donnelly说期望在P版本落实这个事情
  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/PRSXG7THZXRO3UE45S6NC6Y5PU2JMLZF/ go-ceph v0.6.0发布

社区博客

https://ceph.io/community/blog/

  • https://ceph.io/releases/v14-2-13-nautilus-released/ v14.2.13 Nautilus发布了

master近期合入代码

  • bug修复相关:
    • https://github.com/ceph/ceph/pull/37594 (librbd: fix race on watcher unregister)
    • https://github.com/ceph/ceph/pull/37581 (librbd: avoid failing IO with -ESHUTDOWN when disabling exclusive-lock)
    • https://github.com/ceph/ceph/pull/37580(os/bluestore: fix memory accounting in TwoQBufferCacheShard)
    • https://tracker.ceph.com/issues/47751 的修复代码,Normal级别bug,影响M/N/O (os/bluestore: fix segfault on out-of-bound offset provided)
    • https://tracker.ceph.com/issues/47734 的修复bug,Urgent级别,影响N/O (client: hang after statfs)
    • https://tracker.ceph.com/issues/47605 的修复bug,nornam级别,影响N/O (mds: purge_queue’s _calculate_ops is inaccurate)
    • https://tracker.ceph.com/issues/46024 的修复bug,影响N,master(larger osd_scrub_max_preemptions values cause Floating point exception)
    • https://tracker.ceph.com/issues/47608的修复bug,normal级别,影响N/O (mds: OpenFileTable::prefetch_inodes during rejoin can cause out-of-memory)
  • 其他:
    • https://github.com/ceph/ceph/pull/37504 (octopus: erasure-code: enable isa-l EC for aarch64 platform)

Curve vs Ceph

本文属于入门科普类型,适合对分布式存储系统(ceph、curve等)感兴趣的运维、测试、开发人员,或者对底层存储系统感兴趣的云计算平台开发人员,可添加微信号opencurve邀请您加入curve用户群进行沟通交流。

curve新版本介绍

9月下旬我们发布了curve的最新版本v1.1,这个版本重点是性能优化,不论是单client还是10 client场景下,相比v1.0版本,都有至少30%以上的提升,其中提升尤其明显的是4k随机读写场景下的性能(具体可参考releasenote),大部分场景下的提升都达到70%以上,部分场景性能几乎提升一倍,可谓是飞跃性的进步。这一个版本兑现了7月份curve发布时许下的提升30%的承诺,并带来了一点惊喜。

当然我们不会满足于当前的性能,我们可以清晰的看到,在大IO场景下curve还有很大的提升空间,这也是curve团队小伙伴们正在努力优化的,另外小IO场景下我们观察到也有较大的提升空间,期待curve下一个版本也能给大家带来惊喜。

下面的性能对比数据中curve部分如无特殊说明都是基于v1.1版本测试的。

参考:https://github.com/opencurve/curve/blob/master/CHANGELOG-1.1.md

架构

Ceph

架构图参考官网:https://docs.ceph.com/en/latest/architecture/

ceph是基于crush算法的去中心化分布式存储架构,最大的优势是不需要元数据服务器,client每次下发IO请求可以自己通过crush算法(输入osdmap、对象名等)计算存储节点和存储设备(osd)以及数据存储的大概位置(pg),不需要元数据服务器的好处是不会引起性能瓶颈和可用性、可扩展性之类的问题,没有元数据分区、失效等问题,但无中心化的设计也会带来容量不均衡等问题。

但ceph也有一个mon集群,用来管理基本的存储集群拓扑结构(monmap、osdmap、pgmap等)、容量、存储集群各组件状态等信息,并通过Paxos协议保持多mon节点的可用性、可靠性和一致性,在集群稳定运行过程中,正常IO请求是不需要与mon集群交互的,但是在集群有异常,比如节点、磁盘上下线等场景下,还是要mon介入以便确认副本状态等信息,否则client和osd之间无法达成一致,或者说没办法确认应该跟谁通信。对应到存储节点,每个节点上一般都有多个磁盘(osd)来提供物理存储空间,每个osd上面又承载多个pg(管理数据副本一致性的最小单位),每个pg管理多个对象(rbd、fs、rgw等存储类型的数据存储对应到osd上都是已对象的形式来存储的,因此不考虑前面的3种具体形态,只有osd和mon的存储系统又叫rados)。

pg里的对象在磁盘上的管理形式当前主要是直接存储在裸盘上(老版本是文件系统如xfs),为了能找到对象数据的位置(逻辑位置到物理位置映射关系),每个osd还要维护一份自己的元数据信息(当然还可以保存对象的其他信息如omap,以及osd自身的空间使用情况等,还有pg的log信息),通常使用rocksdb(老版本是leveldb)。由于rocksdb本身属于LSM类型的存储引擎,因此需要经常性的进行compaction操作,这一操作过程中就会导致性能波动(磁盘压力或rocksdb本身性能影响)。

在集群中存储节点或存储设备上下线过程中,pg为了保证数据的一致性,需要经由mon来确认各个副本的状态,如果有副本下线,需要补充新的副本,如果副本上线则要同步落后的数据给他,在数据同步之前pg需要经历一个叫peering的阶段(osdmap可能会变化),用来找到权威的副本并且告知mon当前pg可以对外提供IO读写服务了,peering阶段完成前不能对外服务,这一阶段如果花费的时间稍长就会导致client端IO时延变长(俗称IO抖动,表现一般为util升高)。

节点下线的时候如果没有及时通知mon进行peering(osdmap还是旧的),client端和主osd就会认为下线的osd还处于在线状态,继续等待其返回或直到超时,新版本优化了下线流程不是死等超时,可以主动发现osd网络故障进而推断出其已下线,加速进入peering阶段,减少IO抖动时长。

ceph另一个问题是由于其要求3副本写入强一致,必须等待所有副本写入(至少是wal写入完毕)才能返回给client成功消息,所以一旦有一个副本(含主)磁盘响应慢或者存储机异常,就会导致IO请求时延飙高导致IO抖动,但是这个机制带来的好处是,ceph可以支持任意副本数的存储池(比如常用的1~3)。另外在副本增量恢复过程中(recovery),有读(主副本)写(任意副本)请求的时候也要等恢复完毕之后才能提供服务,也是会在一定程度上影响IO时延。

在集群规模达到几百台的场景下,ceph的抖动问题非常突出,因此针对H版本我们定制开发及优化了很多功能,比如数据均衡工具、backport下线主动发现机制、优化peering耗时,恢复速度控制、实现异步恢复等,另外我们也配置了数量众多的监控告警,以便及时发现问题节点、osd进行故障处理。

参考资料:
1. https://docs.ceph.com/en/latest/
2. http://aspirer.wang/?cat=1

Curve

架构图参考官网:https://opencurve.github.io/

curve是网易完全自主研发的新一代分布式存储系统,其架构中包含一个中心化的元数据管理服务MDS(通过ectd选出主从实现高可用),配合etcd存储引擎来保存集群的元数据信息,包括系统的拓扑信息(类似ceph的osdmap);文件系统的Namespace ( 树形目录结构,文件和目录,目录元信息等 ),类似ceph的crush ;Copyset ( Raft 复制组) 位置信息,copyset类似ceph的pg。MDS在一定程度上与ceph的mon集群相似。MDS还感知集群状态并进行合理调度,包括感知Chunkserver上下线、收集Chunkserver负载信息、集群负载均衡与故障修复,中心化架构的优势在于数据均衡比较容易实现,劣势在于容易带来扩展性的瓶颈,curve通过避免核心IO路径上与MDS交互的方案来规避这一问题(只有管控操作如创建删除卷等需要MDS),我们模拟过上百近千台存储机场景下,MDS都不是瓶颈,更大规模的场景还需要进一步验证。

curve的chunkserver类似ceph的osd,都是通过管理物理磁盘并存储用户数据的,当前1.0版本的chunkserver更接近于FileStore实现,通过ext4文件系统来管理chunk元数据,不需要依赖rocksdb等嵌入式数据库(因此每个chunk扩展属性还不支持,但针对块存储场景目前还没有此类需求)。curve数据存储的最小单元是 chunk(类似ceph的对象),管理chunk的基本单位是Copyset(类似ceph的pg),每个copyset搭配一个raft复制组来保证数据多副本的一致性和容灾能力。raft是多数一致性协议,好处是不需要等所有副本写入(至少是wal),大多数写入即可返回client端,极大的减少了长尾效应带来的影响,同时也避免了单个节点或磁盘异常(慢盘坏盘、节点超载等)场景下的IO抖动问题,不足是不能支持单副本场景(3副本中有2副本损坏的紧急场景),也即3副本至多容忍损坏一个,否则就不能提供服务(ceph配置min_size为1可以支持但不太建议,单副本长期运行一旦坏盘会导致数据丢失)。curve可以在节点、chunkserver上下线时主动进行数据的再均衡,并且支持恢复带宽控制(这一点ceph也做的不太好,尤其是L及之前的版本,都是通过控制并发及强制sleep来控制,很难精确控制带宽)。chunkserver的wal写入和一致性保证都是由braft来管理的,因此其业务逻辑非常简单,代码量也较少,开发者很容易上手(当然要深入理解brpc、braft也会有一些挑战)。

curve client端实现了一些卷读写接口如AioWrite、AioRead、Open、Close、StatFile、Extend等,用来给qemu虚拟机、curve-nbd等应用提供卷的IO操作接口,client还要跟MDS交互实现对元数据的增删改查(如卷的增删改查等,接口不列出来了)。client还会对io进行切分,能对inflight io数量进行控制。Client还支持热升级,可以在上层应用(qemu、curve-nbd等)无感知的情况下进行client sdk版本变更。

curve的快照系统与ceph相比也不太一样,ceph快照是保存在ceph自身存储系统里面(rados层)的,支持以对象或者存储池为粒度进行快照,curve则是要导出到S3接口兼容的存储系统。两种架构各有优劣,保存本系统好处是不需要导出导入,节省时间,但会带来性能开销,可靠性也会有一定影响(如果丢数据则快照也不能幸免),保存到外部系统,则可以做更多的事情,比如快照压缩等,性能也更优(多级快照场景更加明显,不需要逐层查找对象进行IO读写)。

curve常用链接汇总(含设计文档、分享PPT、FAQ、Roadmap等):https://github.com/opencurve/curve/wiki

参考:
1. https://opencurve.github.io/
2. https://github.com/opencurve/curve/blob/master/README.md
3. https://docs.ceph.com/en/latest/architecture/

功能

从功能方面来对比Curve和Ceph肯定是不公平的,毕竟ceph已经发展了10年了,curve才刚刚开源出来,不过可以简单看下二者在块存储方面的功能对比,让大家对curve有个更直观的了解。

常用功能方面,curve和ceph都支持卷创建、删除,支持挂载到qemu、物理机(nbd)使用,支持扩容,支持快照及恢复。

ceph提供了一些高级功能(L版本),比如rbd-mirror、layering support、striping、exclusive lock、object map等,大部分一般用户是用不到的,或者是针对快照等场景进行的优化。更高版本的ceph提供了QoS功能。

curve提供的高级功能包括client QoS(通过限制inflight io实现)、client sdk热升级等,都是非常实用的功能。ceph的client端qos老版本还不太支持(比如L版本),当前我们H版本都是在应用层做的(比如qemu、nbd设备的cgroup等)。

ceph支持EC pool,但块存储场景下一般不太会使用到。

ceph的控制台功能比较简单不能满足产品化需求,当然curve还没有开发控制台,但是监控告警由于是基于bvar来做的,因此配合grafana和prometheus可以方便的实现可视化监控,并且展示的信息量非常丰富。ceph的监控更多的是通过ceph-mgr配合prometheus来做但可展示的监控项不是很丰富,或者基于perf counter功能自己封装,总体来说不够便利。

其他有些功能方面的差异已经在架构部分做了说明,这里不再复述。

参考:http://aspirer.wang/?p=1456

性能

性能方面,小IO场景下curve具有比较大的优势,尤其是最近发布的v1.1版本,性能更是提升了一大截。大IO情况下,curve还有较大的提升空间,尤其是时延方面还比较高,这也是curve团队当前的重点工作方向。我相信有了小IO场景优化经验,大IO场景优化起来也会比较得心应手。

项目 配置
存储机 Dell R730xd * 6台
CPU Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz * 2
MEM 256G
NIC Intel Corporation 82599EB 10-Gigabit SFI/SFP+ * 2
OS Debian GNU/Linux 9
Kernel 4.9.65-netease #1 SMP Thu Aug 2 03:02:48
curve版本 v1.1-0beta
ceph版本 Luminous 12.2.13
client host Dell R730xd * 2台
fio版本 3.13

我们内部测试对比数据如下(由于集群软硬件配置和ceph调优手段不尽相同,数据仅供参考):

单卷:

项目 Ceph Curve
4k randwrite (128 iodepth) iops: 39700, latency-avg: 3.2ms, latency-99: 4ms iops:109000, latency-avg: 1.1ms, latency-99: 2ms
4k randread (128 iodepth) iops: 41700, latency-avg: 3.1ms, latency-99: 3.4ms iops:128000, latency-avg: 1.0ms, latency-99: 1.5ms
512k write (128 iodepth) bps: 2076MB/s(单节点带宽已打满), latency-avg: 31ms, latency-99: 116ms bps: 204MB/s, latency-avg: 314ms, latency-99: 393ms
512k read (128 iodepth) bps: 2056MB/(单节点带宽已打满)s, latency-avg: 31ms, latency-99: 144ms bps: 995MB/s, latency-avg: 64ms, latency-99: 92ms

10卷:

项目 Ceph Curve
4k randwrite (128 iodepth) iops: 185000, latency-avg: 7ms, latency-99: 24ms iops:262000, latency-avg: 4.9ms, latency-99: 32ms
4k randread (128 iodepth) iops: 330000, latency-avg: 3.7ms, latency-99: 6ms iops:497000, latency-avg: 2.7ms, latency-99: 6ms
512k write (128 iodepth) bps: 3172MB/s(单节点带宽已打满), latency-avg: 44ms, latency-99: 182ms bps: 1122MB/s, latency-avg: 569ms, latency-99: 1100ms
512k read (128 iodepth) bps: 4440MB/(单节点带宽已打满)s, latency-avg: 28ms, latency-99: 129ms bps: 3241MB/s, latency-avg: 200ms, latency-99: 361ms

注:Ceph版本为L,N版本经测试与L相差不大,相关配置项为默认值。

参考:https://github.com/opencurve/curve/blob/master/CHANGELOG-1.1.md

运维

运维这方面,主要讨论部署和日常维护两块:

项目 ceph curve
部署 ceph-deploy,新版本是ceph-adm ansible
维护 命令集(ceph/rbd/rados/…) curve_ops_tool

两个项目把集群部署起来都还算简单,ceph-deploy有个问题,部署比较慢,要串行操作,为此我们还优化了一下ceph-deploy工具。ceph部署完服务才算第一步,后面还要创建crush rule(这个如果没有经过深入研究,还是有比较高的门槛的),配置pool的各项参数等操作。

curve应该只需要修改几个比较简单的配置文件(playbook的yaml),就可以一键部署搞定了,相对比较简单。

维护的话,ceph一大问题是经常遇到慢盘、坏盘,影响client的IO,用户经常抱怨(会收到一堆util超过90%告警),长时间抖动要帮用户手工解决(停掉慢盘osd),或者短时间的抖动要帮用户确认是否ceph导致的util飙高。为此我们也做了大量的工作来搞定这一场景(如增加各种监控,进行巡检等及时发现问题,甚至发现慢盘自动停止osd等等),但总归是治标不治本,只能尽量规避。

除了抖动,还有容量均衡问题(没有中心化的调度节点,只能根据使用情况进行osd的pg数量调整),集群缩容问题等比较难处理,老版本的pg数量不支持减少,是个比较大的问题(L版本也只能增加pg,更新的版本才支持减少pg),以及缩容后,即使只剩下少量的卷,也很难迁移到其他存储池(qemu用到了存储池,可以迁移到其他root rule,但是pg数量无法减少也是个问题),导致存储池使用的存储节点很难下线。

扩容场景下,除非新建root rule和存储池,否则ceph需要对已有数据进行迁移均衡到新增加的节点上,这方面curve也是类似的(物理池逻辑与ceph的root rule类似),curve的好处是可以做到精确的带宽控制,减少对正常业务的影响。

日常的坏盘替换场景下,ceph可以做到只迁移一次数据(L版本,H版本还不太行),也即坏盘下线的时候不做数据迁出,新盘上线时进行数据恢复即可(当然也可以做到自动迁出和迁入)。curve的话当前是下线自动迁出,上线自动迁入。二者区别不大,curve好处依然是精确带宽控制。

压力检测是一个比较困难的场景(如何找出压力比较大的client,并及时对其进行限制防止雪崩效应?),也是一个强需求(虽然client有qos,但集群一般都有性能超售,部分client压力飙升可能影响整个集群),ceph场景下,由于只能看到集群压力情况,很难做到所有client的汇集(当前是qemu端做的监控)和分析(当然可能跟我们使用的自研监控服务不支持这种场景有一定关系),导致很难找出那个或者那些影响了整个集群的client。一般我们都是用土方法,查看压力大的osd,打开message日志,找出消息比较多client ip,然后再根据client的监控情况判断是否跑满,同时找出同样业务的其他虚拟机,然后逐个进行限速处理。这一过程肯定比较耗时耗力,还不一定准确(可能新版本已经支持了单个rbd卷的性能统计)。curve场景下就比较简单了,看下grafana的client监控,找到压力大的client对其进行限速即可。

监控告警也是一大运维重点,ceph的话可以基于perf counter机制来做一部分,做不了的可以自己定制化扩展。也可以基于ceph-mgr+prometheus+grafana来做,一般还要配合存储节点的NODE_EXPORTER来做会比较全面。我们内部没有用这套机制,是基于自研的监控系统来做的,主要是用到了perf counter+监控脚本模式。

相比ceph的模式,curve基于bvar+prometheus+grafana,监控指标拉取更及时,都是秒级的,可以实时显示性能、时延曲线。bvar另外一个好处是它对外提供的是http api,不是perf counter那种命令行,也就是说不需要在本地部署agent或者脚本即可拉取数据,管理起来比较方便。

参考:
1. https://github.com/opencurve/curve/blob/master/docs/cn/monitor.md
2. https://github.com/opencurve/curve/blob/master/docs/cn/deploy.md#%E5%A4%9A%E6%9C%BA%E9%83%A8%E7%BD%B2
3. https://docs.ceph.com/en/latest/mgr/prometheus/

学习曲线

纯使用

如果是运维人员想使用ceph或curve,或者对比2者进行选型,那我这篇文章基本上可以做为参考了。

ceph运维上手还是比较复杂的,要对各种概念、配置参数(L版本单单osd配置项我粗略看了下就有400多个,大部分配置项都要通过阅读源码来真正理解其意义和用途)、各种监控指标有比较清晰的理解,还要对各种pg状态有深入理解,各种异常要能找到对应的解决方案,当然网上各种调优文档也有很多可以拿来参考,如果没有深入的使用经验和测试比较,这些调优文档也有可能与你的使用场景不符,甚至可能带来副作用。

curve的代码注释(含配置项)非常完善,配置项也比较少(粗略看了下client、chunkserver、mds等全部加起来跟osd的配置项数量差不多),每个配置都有详细的解释,即使不明白也可以随时咨询我们的开发人员。集群状态也比较容易理解,没有那么多的incomplete、peering、degraded、undersize、recoverying、remapped、stale…

运维相关的部署维护监控告警方面,也是curve更容易上手一些,上面已有对比说明。

开发者

上面的架构对比已经说明了问题,curve架构非常简洁易懂(raft也比Paxos简单多了),不需要花费太多时间就能理解代码逻辑,上手进行开发测试。

更重要的是,不论对纯使用的运维人员还是开发者来说,curve的资料原文都是中文版本的,对国内用户来说都特别友好(另外还有微信群可以即时沟通)。

可扩展性/可塑性

功能

ceph的功能已经足够多了,号称统一存储平台。因此功能这块扩展性或者可塑性已经不大。

curve的话还非常年轻,它从架构设计之初就考虑到后续支持扩展各种存储场景的(块、对象、EC、其他引擎等等),当前的发展方向也还在逐步摸索,我们会根据公司内部和存储业界最新动向来及时调整规划,紧跟IT架构演进趋势。我们也欢迎各路同仁加入讨论和开发,一起发展curve。

我们近期的roadmap主要集中在如下几个方向:
1. 云原生数据库支持:为MySQL提供分布式存储后端
2. 云原生容器平台支持:容器云、中间件的存算分离(curve-nbd替换本地data盘、支持类似cephfs的文件存储)
3. 作为ceph的前端缓存集群:类似ceph的cache tier
4. 发展开源社区:吸引个人、企业开发者,加入TOP开源基金会

各个方向都能拆分出非常多的功能、性能、稳定性等方面的需求。中长期的规划可能会发生比较大的变化,这里就不列出来了。

性能

性能一直是curve重点关注的方向,除了上面已经给出的数据,后续curve还会花费大量资源在性能优化上,近两年的目标是支持云原生数据库和给k8s集群提供存储服务(前期可能考虑用nbd盘替换k8s节点本地盘,后期可能考虑开发类似cephfs的文件系统功能),虽然v1.1版本相比v1.0有了很大提升,当前离目标还是有一定差距的。io_uring、QUIC、spdk、rdma、25G网卡等新技术都在考虑当中,nvme/傲腾、40G网络等新硬件也在调研。curve近几年没有商业化或者盈利的打算,因此不会把各种优化手段和方案保留自用,都会毫无保留的开源出来。

ceph的性能也一直在改进,但由于其架构和功能比较复杂,牵一发而动全身,所以只能用全新的版本和架构来做(基于spdk/seastor等的SEASTORE),因为要保持功能的兼容性,当前看起来还需要较长时间才能正式发布。大部分sds厂商都是基于现有的架构进行优化改进,具体优化到什么程度,要看各家的实力和人力投入如何,但是一般来说他们的优化都是作为竞争力保留的,不太会开放给外部。

参考:https://docs.ceph.com/en/latest/dev/seastore/

社区

ceph的社区活跃度肯定是很高的,curve刚刚开源,很多人还不了解。

ceph是一个成熟的国际化的开源社区,新人想参与进去提交pr还是有较高的难度的(一般是从编写测试用例、简单的bug修复入手),功能性的pr一般都是比较核心的开发人员才容易被接受(这一点跟Linux内核社区很相似)。

而curve刚刚起步,目前重点还是吸引国内开发者,一是便于沟通交流(可以微信添加opencurve拉你进交流群),二是鉴于当前国际形式也更倾向于为国内用户服务。刚刚起步的好处是,我们对所有的pr都非常欢迎,并且要求会相对比较低(可能你提交的pr不太符合规范,我们可以帮忙修改完善,可能你的pr没有考虑全面,我们可以给你提供修改建议和设计思路),有任何想法都可以在群里或者issue上提出来,目的是鼓励大家积极参与进来。企业用户如果有交流的想法,也可以与我们联系面谈,如果roadmap或需求有匹配的地方可以合作开发,提高研发效率、节约人力成本。

后续curve也会考虑加入某个开源组织(基金会),但目前主要还是关注自身的功能和性能问题,待条件成熟会有进一步的动作。

curve的Roadmap可参考:https://github.com/opencurve/curve/wiki/Roadmap

应用规模

当前来说二者也没有可比性,毕竟ceph已经发展了10年,而curve才刚刚开源3个多月(内部开发2年多)。单就网易内部使用情况来说,ceph上线将近5年了,节点最多时数千台(随着业务从OpenStack转向k8s,集群规模有所减少),curve上线1年多,卷数量数千,并且一直稳定运行无任何SLA损失,这一点据我了解ceph当初上线时也没有做到的,curve的开发质量可见一斑。业务方经过这一年多时间测试观察,已经逐步建立起了对curve的信心,这一点从近期curve卷的使用量大幅增加可以明显感觉出来(我们给业务方提供了ceph、curve两种卷类型,他们可以自行选择创建哪种类型的卷),近2个月以来curve卷数量已翻了一番,我们预估明年集团内部使用量会有爆发式增长。

Ceph社区跟踪(2020-09-19 ~ 2020-09-30)

本文作者: 胡 遥 ( https://my.oschina.net/u/2257799 )

youtube channel

  • Ceph Crimson/SeaStor OSD 09-23
    • 修复测试用例发现的bug,bug的场景是:一个request因为拿不到object context而被pengding,再次重新执行的时候可能乱序。
    • 完善cstore垃圾回收方面的基础开发,目前已经可以在一个随机的工作负载下一直
    • 集成了hobject的读写流程,以及对应的单元测试
  • Ceph Science Working Group 09-23
    • 讨论了ceph的一个线上问题,某一次大停电,3个数据中心,其中2个中心完全掉电。最后没有丢数据,并且通过均衡恢复了。
    • 报告了一个osd pg迁移走之后,使用率还是很高的问题。没找到问题的原因,最后通过重建解决
    • 计划将第二个s3的环境从L版本升级到N版本,并且都进行了测试,之前已经升级成功一个。比较担心region的设置从前一个版本的设置无法在下一个版本中生效
    • 讨论了s3 单bucket文件数量过大的问题,目前已经把aoto reshard功能给关闭了。问题原因是做list file操作的时候,如果shard达到512个,而每次如果list 1000条记录,则需要512个shard同时返回1000条记录,则有几十万条记录进行排序,耗时非常严重,对此进行了优化。
  • Ceph Performance Meeting 09-24
    • 讨论了2个新的pr
      • https://github.com/ceph/ceph/pull/37156
      • https://github.com/ceph/ceph/pull/36266
      • https://github.com/ceph/ceph/pull/37314
    • 分析rocksdb社区做的rocksdb基准测试,用不同工作负载的模式进行测试。有人提出rbd下的rockdb工作负载和rgw下的rocksdb工作负载差别很大,要把工作负载模型都测试到,工作量很大
    • 分析rocksdb的文档,代码以及案例。目前只熟悉了文档,还没进行代码的深入分析,并且觉得这很耗时,如果有人可以提供rocksdb代码速成的方法,会很高兴
    • 讨论了bluestore是否有更好的并行处理能力,kv-sync线程一直是瓶颈,导致当初的bluestore非常慢,现在已经大大改善了,如果想要进一步改善,需要比单线程使用更多的并行化
    • 提到删除调用pglog的相关的代码,来测试pglog的开销
  • Ceph Code Walkthrough: Patrick Donnelly – Metadata Servers 2020-09-29
    • 这个主要是代码讲解,自己看就好了
  • 邮件列表
    • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/M67UHRHBOBO64FGG5U3OTLH2MOR43PEX/ (报告一些代码backport到了N版本导致FreeBSD环境编译不通过)
    • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/JBMAEEMXZWTHF5XA4MBFJDWLDCOFH5DH/ (ceph社区实习报名)
    • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/DIQTY4AYHRE3RSOCA7WHEG2TE2M6C7WW/ (有人说他开发了一个性能更好的块存储,并且可以对接qemu,https://vitastor.io)
    • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/UJTZE3JRQ56M2CM7C3TU25Y6P2VA2OY5/ (ceph-mgr升级到15.2.4,总是需要很长时间才能得到ceph pg结果)
    • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/DXM3Z2BE3PBDPIZHE7XJKQOVMTJ322XM/ (ceph-fuse 多client之间存在不一致的问题)
  • master近期合入代码(0919~0930)
    • bug修复相关:
      • https://github.com/ceph/ceph/pull/37331 修复 https://tracker.ceph.com/issues/47461
      • https://github.com/ceph/ceph/pull/37334 修复mds在session连接关闭后不恢复文件caps的问题
      • https://github.com/ceph/ceph/pull/37382 降低了mds的open file table的内存使用

Ceph社区跟踪(2020-08-27 ~ 2020-09-09)

本文作者:本人

youtube channel

  • Ceph Crimson/SeaStor OSD 08-26
    • 在osd层屏蔽不支持的特性,补充测试用例
    • 每个主要开发人员开发进度同步:extent/onode tree、omap、dirty extent/segment管理方案pr讨论
    • 解决EC相关bug及messenger层导致的心跳相关bug
    • 讨论美光新开源的存储引擎(https://www.micron.com/about/blog/2020/june/what-is-a-heterogeneous-storage-engine ),tiger、rocksdb等LSM存储引擎的性能问题,吐槽rocksdb非常slow,用它是因为它流行 【这块可以关注下新开源的存储引擎】
    • 讨论使用io_uring实现异步IO
    • 讨论的相关pr:https://github.com/ceph/ceph/pull/36779、https://github.com/ceph/ceph/pull/35865
  • Ceph Performance Meeting 08-27
    • 跟踪rocksdb社区进展,每2周的论文阅读情况(连摘要都没时间看。。。),有些论文作者还不想把最新进展同步给他们(因为论文还没发表。。。)
    • onode、rocksdb等相关的议题讨论:rbd使用更简单的内存数据结构,其他的如cephfs可以复杂点,以及精简其他内存数据结构(如blob、extent等)以减少内存占用?把一个key拆分成多个,以减少提交到rocksdb的数据量?
      • 另外一个人评论:这个改动要先做好POC,改动会比较大,想法是好的,不知道收益如何
      • 另外讨论了这些优化是否会影响crimson/seastor架构
    • 64k的blob size是否合适,是否要调小到16k或者调大到512k?还需要继续调研,不同场景下的性能表现(单client、多client、db场景等),只靠benchmark场景来测试得到合适的blob size是不合理的。
  • Ceph tech talk 08-27
    • 主题:Secure Token Service(STS) in Ceph Rados Gateway
      • 主要参考了AWS STS APIs以及AWS IAM APIs,N版本已经实现了一部分
  • Ceph Orchestrator Meeting 08-31
    • nfs兼容性问题:N版本实现的dashboard的nfs管理功能与O版本不兼容,要想办法解决(也不是完全不兼容,只是两个不能同时用)
    • 想办法支持从N版本迁移用户到O版本
    • rook问题
      • ceph daemon僵尸进程没有处理好
      • ceph daemon进程的core dump文件没办法生成
    • 配置文件模板问题:grafana、告警服务,使用jinja管理模板文件,比较灵活但用户体验较差(相比UI方式)
    • 不需要编译ceph或者部署一个ceph集群就可以体验cephadm,跑测试用例
    • cephadm的安装方式(包管理?集群升级问题?要尽快确定一个cephadm本身的最小命令行集合,以便保持兼容性)
  • Ceph Crimson/SeaStor OSD 09-02
    • 测试用例失败问题讨论及分工;interruption问题修复方案讨论(应该是指osd正常退出过程中的停止pg服务和snapshot终止问题)
    • rgw omap offload代码开发及review
    • seastor onode tree功能联调完毕,准备提PR
    • lambda函数使用问题(主要是讨论其性能问题)
  • Ceph Performance Meeting 09-02
    • 讨论新PR
      • https://github.com/ceph/ceph/pull/36961(mon/AuthMonitor: speed up caps updates)
      • https://github.com/ceph/ceph/pull/36914 (change the default value of option osd_async_recovery_min_cost from 100 to 10,经过测试rgw+EC pool场景下10比较合适)
    • onode等数据结构重构问题
      • 讨论怎么减少内存占用以及提升rocksdb性能
      • 基于column family来分离onode、omap、extent等BlueStore的metadata到不同的block cache?
    • 降低osd的cpu占用方案讨论:目标是占用1~2cores,现实是nvme场景下BlueStore引擎osd占用10~14cores,节省下的cores可以给其他进程使用
      • BlueStore+rocksdb在nvme场景下比FileStore性能好,但也遇到了cpu性能瓶颈问题,要想办法降低cpu开销
      • seastor会在一两年内搞定,会解决这个问题?潜在的意思是说我们还要不要花费时间在BlueStore上做优化?
      • 降低cpu利用率需要先确定硬件类型,nvme、optane。。。
    • rocksdb性能问题:
      • Intel的人提出了一个原型,把pg log写入bluefs,绕过rocksdb,还讨论了一坨优化pg log在rocksdb的性能问题的方案
      • 有人提出ceph的rocksdb里的key string用的太多(前缀、后缀、比较等等)影响性能,考虑用binary方式替换?
      • 参考zfs的元数据管理方式改进ceph这边使用rocksdb的姿势?
      • nvme和Intel ssd对比benchmark性能,没有提升多少,需要继续研究
    • pg lock/log(pg lock还是pg log,没听太清。。。根据上下文应该是log)性能问题,禁用pg lock可以提升20~30%的性能(fio测试BlueStore engine)
  • Ceph Developer Monthly 09-02
    • 讨论teuthology等CI问题(出现一批失败用例,以及job排队问题,需要机器?),有些问题比较难复现,出现了要尽快上去看,比较难解决的问题可以先尝试用bisect找到问题
    • teuthology每天晚上可以跑300个用例,这样才可以快速发现新引入的问题(意思是近期teuthology不太稳定,要尽快修复)
    • debug level可以配置高点,方便定位问题?

邮件列表

  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/TPIFMPQ6YHEK4GYH5LA6NWGRFXVW44MB/ (13.2.8版本有用户反馈osd可能有内存泄露,还在讨论)
  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/OLFOSYULOTC4HFVF37YSASSAFYFE372A/ (ceph tell osd.0 bench之后怎么删除测试数据?)
  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/XJICICKXGMGUSH2KDP4TSVRYR2SELHYH/ (cephfs怎么跨集群同步数据,提到了2个工具,我们有空可以研究下)
    • https://docs.ceph.com/docs/master/dev/cephfs-mirroring/【推荐】
    • https://github.com/oliveiradan/cephfs-sync
  • https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/6TW27ZYQ3PRW6QEWGT5EZXADOVRYYT77/ (怎么解决”inconsistent+failed_repair”这个pg状态,cephfs的pool,暂无人回复)
    https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/thread/ZOPBOY6XQOYOV6CQMY27XM37OC6DKWZ7/ (14.2.8升级到14.2.10之后db/wal性能下降明显,貌似还没有结论,没仔细看)
  • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/QWZHT4MQBVSHVYXUEFJMBDO2MA65PZLF/ (ceph-deploy还可以继续用吗?答复是ceph-ansible和cephadm不一定能满足所有用户需求,deploy还会继续支持,比如python3支持还会发版本)

社区博客

  • https://ceph.io/community/blog/

没有新增文章

master近期合入代码(08-27~09-09)

大部分都是crimson/seastor相关的,也有少量rpm打包、文档、dashboard相关的。

bug修复相关:
– https://tracker.ceph.com/issues/47302 的修复代码,minor级别bug,影响N/O版本(include/encoding: Fix encode/decode of float types on big-endian systems)
– https://tracker.ceph.com/issues/47290 的修复代码,major级别bug,影响N/O版本(osdmaps aren’t being cleaned up automatically on healthy cluster)
– https://tracker.ceph.com/issues/47293 的修复代码,minor级别,影响master版本(client: osdmap wait not protected by mounted mutex)
– https://tracker.ceph.com/issues/47201 的修复代码,minor级别bug,影响N/O版本(mds: CDir::_omap_commit(int): Assertion `committed_version == 0′ failed.)
– https://tracker.ceph.com/issues/46842 的修复代码,影响N/O版本(librados: add LIBRBD_SUPPORTS_GETADDRS support)

其他:
– https://github.com/ceph/ceph/pull/36955 (os/bluestore: Switch from libzbc library to libzbd library,libzbd是libzbc的升级版。。。)
– https://github.com/ceph/ceph/pull/36850 (mds: add performance counter for cap messages)

Ceph社区跟踪(2020-08-10 ~ 2020-08-23)

本文作者: 徐 桑 迪

Youtube Channel

https://www.youtube.com/c/Cephstorage/videos

  • Ceph Orchestrator Meeting 08-10
    • Rook 1.4发布
    • 更新了删除OSD的设计文档
  • Ceph DocuBetter Meeting 08-12
    • 优先编写Installation guide和development guild
    • 后续考虑录制短视频(~5mins)演示如何安装Ceph
  • Ceph Crimson/SeaStor OSD 08-12
    • 编写新的OSD实现crimson-osd,讨论功能设计和开发进度
    • 关键词:NVMe,SeaStore,Multi-cores,Cache,LBA tree
  • Ceph Performance Meeting 08-13
    • 开发中:根据buffer原大小动态调整append buffer的大小
    • Need QA:(ma jianpeng)RocksDB Env中避免一次性下刷过多的数据
    • Need Review:d3m caching
    • 开发中:(ma jianpeng)优化BlueFS中BufferList重建流程,正在考虑将其应用到通用BufferList中
    • 研究中:有人提出了一个CRUSH算法的优化版本,用来降低集群扩容时的数据迁移影响
    • Paper中仅测试了HDDs,可能是因为在这个硬件上效果更好
    • Sam提出他更关注减少数据迁移,从而可以提升NVMe设备的使用寿命
    • https://www.usenix.org/system/files/fast20-wang_li.pdf
  • Ceph Orchestrator Meeting 08-17
    • 考虑重构Cephadm工具
    • 从原有的Ceph-ansible中拷贝部分代码过来,应该是想后续完全替代掉ceph-ansible
    • 编写使用Cephadm工具部署Ceph集群的指导文档
  • Ceph Crimson/SeaStor OSD 08-19
    • OSD EIO处理
    • 使用crimson关键字跟踪相关BUG
  • Ceph Performance Meeting 08-20
    • 讨论之前提出的CRUSH扩展算法论文;其对新PG使用了新的rule,可能不是很好
      • 要么最终仍然需要迁移数据以达到集群平衡,这样带来了额外的PG合并开销
      • 要么得一直保留PG映射的特殊信息,而且这会随着集群的扩容不断增大
    • 正在积极开发QoS功能,初步验证效果显著
    • PG priming?(可能是高版本特性,暂不了解)
    • 持续关注研究领域的Ceph/CRUSH相关论文,定期一起阅读讨论

邮件列表

IRC

  • https://tracker.ceph.com/projects/ceph/wiki/Code_Walkthroughs
    • 2020-08-25 @ 7am PDT: KRBD I/O Flow – Ilya Dryomov
    • 2020-10-27 @ 7am PDT: Librbd I/O Flow – Jason Dillaman
  • Proposal: Encrypted Namespaces
  • CEPH dmclock per-client QoS control
    • not implemented, still need a lot of work
  • https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/IMYRL55PURREJXFLVX3FKHJ4QQX57JA7/
    • 33% possible performance regression between 15.2.4 and HEAD?
    • checking bluestore disk allocator work
  • https://github.com/ceph/go-ceph/releases/tag/v0.5.0
    • go-ceph v0.5.0 released

社区博客

https://ceph.io/community/blog/

  • https://ceph.io/releases/v14-2-11-nautilus-released/
    • abort scrub/deep-scrub by setting certain osd flag
    • implement Hybrid allocator for bluestore
    • do not raise “client failing to respond to cap release” when client working set is reasonable

代码合入

主要通过新版本的Release Notes看合入的commits:https://docs.ceph.com/docs/master/releases/general/#release-timeline

V14.2.11 NAUTILUS
标签 Commits数 值得关注的修复/特性
bluestore 2
build/ops 1
ceph-volume 1
cephfs 27
core:mon 1
core:mgr 2
core:osd 6
mgr modules 10 nautilus: New msgr2 crc and secure modes (msgr2.1)
msgr 1
rbd 3
rgw 15
tools 1

其它

  • https://github.com/ceph/cbt
    • Ceph benchmarking tool(CBT)
  • https://docs.ceph.com/docs/master/dev/crimson/
  • https://docs.ceph.com/docs/master/dev/seastore/

ceph rgw vs minio vs swift

个人观点,能力有限,仅供参考

结论

  1. Ceph显然是云原生标准存储组件,其他两个都有很多功能缺失,比如不支持块和文件存储,这会导致一套云环境要部署多套存储系统
  2. MinIO只支持EC纠删码,不支持副本存储模式,性能和可靠性会有损耗
  3. MinIO扩容不方便,不适合规模多变的生产环境
  4. 从非功能方面比较,Ceph也是最佳选择
  5. 从我们内部使用情况来看,Ceph已经使用多年,有成熟的运维经验,也有很强的二次开发能力,其他两个都没有使用经验,更没有开发经验

功能对比

功能 ceph minio swift 备注
S3接口 Y Y Y 都是常用接口,高级接口一般都不支持
私有接口 Y N Y ceph同时支持swift接口
多语言SDK Y Y Y S3 SDK支持多种语言
bucket name跨账号同名 N N Y  
命令行工具 Y Y Y  
支持的操作系统 超多 minio支持windows、mac,其他两个基本都是Linux发行版
硬件绑定情况 不需要特定硬件
数据加密 Y Y Y  
多副本 Y N Y  
EC Y Y Y  
快照 Y? N N ceph支持pool级别快照
故障域 Y Y Y 副本域或EC分片域
多租户支持 Y Y? Y minio多用户ok,多租户需要单独部署server
LDAP Y Y Y  
bucket ACL Y Y Y  
multisite Y Y Y 跨区灾备
数据压缩 Y Y N swift官方不支持,但可以自己开发插件
NFS导出/NAS Y Y N? swift官方不支持,猜测可以通过NFS-Ganesha配合S3 api实现?
配额 Y N Y minio支持限制租户使用的磁盘数量
块存储 Y N N  
文件存储 Y N N  
dashboard Y Y Y? swift需要使用OpenStack horizon作为dashboard
监控告警 Y Y Y ceph、minio支持prometheus,swift支持statsd,也有第三方的prometheus exporter
分块上传 Y Y Y  
最大对象大小 单次上传5G(可配置),分片上传最多10000个 单次5TB,分片最多10000,每片最大5G 单次上传5G(可配置),分片上传最多1000个(可配置)  
最大元数据大小 512KB 8KB 4KB(可配置)  
静态站点托管 Y Y Y ceph需要通过代理服务实现(比如nginx、haproxy)
bucket lifecycle Y Y Y  
bucket policy Y Y Y  
临时url Y Y Y  
object versioning Y N? Y minio看起来还在开发这个功能
Bitrot Protection Y Y Y  
WORM

(一写多读)

N Y N  
bucket notification N Y N  
object tags Y Y Y  
第三方备份 N Y N  
元数据搜索 Y N Y  

 

非功能对比

  ceph minio swift 备注
稳定性  
数据一致性 强一致 强一致 最终一致 minio数据落盘不是direct?
集群可扩展性 minio不支持存储池级别扩容
数据可靠性 中高  
性能 未实际测试,但估计相差不大
运维便利性 后2者未实际使用,网上查询比较简单
可维护性 后2者没有使用经验
可订制化 极高 后2者没有二次开发经验
云原生适配能力 极高 ceph已经是云原生标配开源存储组件,OpenStack也推荐使用,swift在OpenStack的IaaS平台上只能用来保存镜像,minio几乎没有在云环境的使用案例
企业使用情况 普遍 极少 一般 国内几乎所有SDS存储厂商都是基于Ceph在做,几乎没有基于swift的,minio更没有听说过;另外国内大厂也都有ceph使用场景(中国移动、腾讯、阿里、网易、乐视、携程、今日头条、中国电信、中兴、恒丰银行、平安科技、YY、B站、360等),使用OpenStack的企业很多,相信其中也有部分公司用到swift,minio几乎没听说过
商业版本 Y Y Y 同上
开源社区活跃度 极高 minio几乎就几个人在做
软件业内顶级公司参与度 普遍 极少 一般 同上
文档完善度  
开发运维人员招聘难度 适中 稍高  
开源协议 LGPL-2.1 or LGPL-3 Apache License 2.0 Apache License 2.0  
项目发起时间 2008.01 2015.06 2010.07 以第一个版本发布时间为准
版本发布频率 每年1个大版本,小版本比较频繁 7天 6个月一个大版本,小版本比较频繁  
CI自动化程度及覆盖率 非常完善 未知 非常完善  
项目贡献参与难度(学习曲线) 中? ceph整体代码量及复杂度都很高

 

 

 

peering耗时优化方案:跳过wait_up_thru阶段

需求

减少日常运维操作导致的peering的耗时,如停止osd、启动osd、调整osd权重、迁移pool等,从而减少对客户端IO造成的影响。

现状

当前waitupthru阶段耗时是整个peering阶段最长的,该阶段的耗时与monitor的Paxos决议间隔时间强相关(当前配置是间隔1s),也跟monitor服务的繁忙程度有关,之前通过更换monitor所用的存储盘为ssd盘之后,已经大幅降低了waitupthru阶段的耗时,从而也很大程度上降低了peering耗时,对客户端IO的影响也大大降低。

但通过分析多次线上日常运维对打桩卷IO的影响情况,仍然发现有部分osd的peering耗时达到5s甚至8s,其中最耗时的阶段仍然是waitupthru,可达7s左右。另外观察影响打桩卷IO较小的场景,其peering阶段耗时均较低,一般为1s多(绝大部分仍然为waitupthru占据),因此仍然需要进一步优化waitupthru耗时。

方案

本方案的总体流程变动

相关名词解释

peering相关流程请参考:Ceph peering相关问题

WaitUpThru是peering的最后一个阶段,其作用是等待osd通知monitor把他的up_thru字段更新到osdmap中,up_thru字段用来表明该osd何时(哪个epoch)完成了peering,一旦更新完成,就表示该osd上的pg已经可以接受客户的IO请求,后续生成past_intervals时该interval就不能被跳过(可能有IO写入,如果跳过则可能导致数据丢失)。

如果没有这个字段,则无法区分特定场景下的interval是否有IO写入,官方举例如下:

在上述场景下,epoch 3这个阶段,B所处的状态可能有2个,1)B正常运行并且可以处理IO;2)B已经down,只是mon还没发现或者没有更新到osdmap;如果是情况1,那么在peering阶段就不能跳过2这个interval,如果是情况2,则可以安全跳过,osd的up_thru就是用来区分情况2的,即:

如果这种情况下,B在epoch 3这个interval其实是没有完成peering的,因此肯定没有IO写入,可以在后面的peering阶段跳过。

而如果B在epoch 3这个interval的up_thru成功更新成了3,则表示它正常运行并且完成了peering,有IO写入,后续peering不能跳过。

past_intervals在发生变化后(新加入或老的interval被清理),都会把pg的dirty_big_info字段设置为true,然后把更新后的past_intervals存盘(leveldb),在osd启动时会重新加载past_intervals信息。因此我们只需要考虑的是配置项修改后新生成的interval的maybe_went_rw的值是否符合预期即可。

因此如果要跳过WaitUpThru阶段,就必须要做到将每个interval都看作接收过客户端IO请求(写请求),而不能跳过。

方案设计

计划实现一个开关osd_wait_up_thru,来控制OSD在peering过程中是否需要等待up_thru字段更新到osdmap并返回给osd,并且该开关可以随时打开关闭而不影响OSD的运行和数据可靠性、一致性。false表示不等待up_thru字段更新到osdmap,true表示等待。

在peering跳转到WaitUpThru阶段的位置(通过发送NeedUpThru事件给pg状态机实现跳转),加上这个配置项条件的判断,如果为false则不进入waitupthru阶段。

在GetInfo阶段,会首先生成一系列的interval也即past_intervals,然后把这些interval中的osd列表都放入一个set中(prior_set),之后给他们发送pg info查询请求,找出哪个或者哪些osd的pg信息比较全,然后用来在GetLog阶段获取pg log,生成权威日志,供数据恢复使用。

生成interval过程中会根据up_thru字段检查该interval是否曾经接收过客户端写IO,如果没有则可以不考虑这个interval(这个interval的osd不放入pg info查询的os集合),而如果我们之前跳过了WaitUpThru阶段,则可能无法区分该interval是否有写IO,因此只能将其加入pg info查询的osd集合,带来的影响就是多查询了一些osd,并且这个osd可能已经无法启动。但更多的情况下,3副本存储池,一般都有至少2个副本运行,因此每个interval一般都是会有写IO,很少能跳过,并且3副本对应的osd一般都不会发生变化,如pg 1.0从创建后一般都是在固定的3个osd上(如osd.1,2,3),除非我们对其做过运维操作如调整权重或者踢osd。因此并不会导致pg info或pg log需要多发送给很多的无效osd造成耗时增加。

需要考虑的异常场景如下:

  • 开关临界场景:即配置项开关从开到关或者从关到开,不能造成数据丢失或其他问题
  • OSD频繁up、down场景(正常或误报):不能导致数据丢失或其他问题
  • 某个interval单副本运行,但坏盘导致其无法启动,如何把pg恢复正常,尤其是当该interval实际上可能没有接收客户端IO请求的场景,跳过WaitUpThru阶段是否会引入新的问题?

针对配置项开关临界场景的设计如下:

  • 在线修改配置项(从true到false):根据上面的整体流程图可以看出,这一过程实际上是把interval的maybe_went_rw=true的场景变得更加宽泛,也即只会把原本为false的变为true,让pg在peering时给更多的osd发送查询pg info+log请求,在我们场景下都是ok的,唯一需要考虑的是异常场景3的情况下(单副本运行期间坏盘),如果单副本所在的osd故障无法启动,如何让pg完成peering恢复业务?这个问题在下面的异常场景3的设计讨论时进行解释。
  • 在线修改配置项(从false到true):这个场景与从关到开相反,因此interval的maybe_went_rw=false的场景变得更加宽泛,也即把原来为true的场景变成了false,带来的问题是可能这个interval是有IO写入的,但peering过程中却跳过了,就可能导致数据丢失风险。导致这一问题的根本原因是我们跳过了WaitUpThru阶段,也即判断maybe_went_rw=true的条件是不准确的(根据主osd的up_thru或者pg的info.history.last_epoch_clean版本判断,但由于peering转到active之前没有等待新的osdmap到来,所以这两个值有可能是不准确的),因此我们需要在修改配置项之前,检查osd的up_thru值是否更新完毕,并且pg的状态是否为active,只有满足这两个条件才可以进行配置项更改。为了统一配置项修改条件以简化代码逻辑,我们把在线修改配置项从关到开的修改条件也限制为与从开到关同样的条件。补充:修改配置项与peering触发流程不能并发,加锁控制
  • 针对离线配置文件中配置项的修改:可参考下面的非功能性设计相关内容

针对频繁的OSD up、down场景设计如下:

  • 首先,在配置项为false场景,由于基本上每个interval都被我们认为是有IO写入的,因此会导致某些没有IO写入的interval的osd也需要被查询(pg的info和log),因此某些单副本运行的interval虽然没有IO写入,也需要被查询,导致无法跳过,pg状态可能变成down+peering,但此时只要把该osd启动起来即可恢复,如果无法启动,则需要进行手工的恢复,恢复流程见:pg down+peering状态处理方案,由于实际上这个interval并没有IO写入,因此手工恢复也不会导致数据丢失。如果单副本运行的interval有IO写入,那这种场景跟官方场景是一样的,都可能导致数据丢失,这种场景下的数据丢失并不是本次改动引入的。

针对单副本运行过程中坏盘场景设计如下:

  • 如果只是一个副本坏盘,其他一个或两个副本正常运行(min_size=1),那么这个场景是可以正常完成peering的。如果是单副本运行过程中坏盘,这个场景又分为单副本运行的interval有无IO写入,这个问题与上面的osd频繁up、down中的类似,可以参考上面的说明。

非功能性设计

升级

升级过程比较简单,只要把代码打包,然后安装、启动即可(代码中osd_wait_up_thru配置项默认为false,也即让interval的maybe_went_rw=true的条件变宽泛,让更少的interval被跳过,以保证数据可靠性)。ceph.conf配置文件中的osd_wait_up_thru,也配置为false即可。

配置项修改

配置项修改分为在线和离线两种,在线修改已经在代码中进行相应的设计和处理,只有在条件满足时才能修改成功。

离线的配置项修改,需要先完成在线修改,然后再修改离线的ceph.conf配置文件,这么做的原因是,一旦离线的ceph.conf修改完毕,尤其是从false改为true的场景,此时如果在线配置项没有修改而osd异常down掉并重启(当然我们当前的运维场景下不会发生),那么有些interval可能被错误的标记为没有IO写入而跳过,导致数据丢失。如果我们先修改了进程内存中的配置,并且判断已经成功,那么之后无论是在ceph.conf是否修改时发生osd重启,均不会导致interval错误的标记为没有IO写入。

补充:生成prior_set过程中会首先把当前的acting和up的osd列表加入进去,在我们的场景下,这两个列表里的osd已经有所有需要的pg info和log,因此即使错误的跳过一些interval(不给这个interval里的osd列表发生查询pg info和log请求),也不会导致pg信息获取不足(导致数据丢失)。

if (lastmap->get_up_thru(i.primary) >= i.first && // 不等up_thru,意味着本地的osdmap可能是旧的,所以这个判断条件可能是不正确的
    lastmap->get_up_from(i.primary) <= i.first) { // interval可能与自己无关,这里主要关心主是否可写
        i.maybe_went_rw = true;
} else if (last_epoch_clean >= i.first && // 不等up_thru,意味着本地的osdmap可能是旧的,所以这个判断条件可能是不正确的
           last_epoch_clean <= i.last) {  // 因为last_epoch_clean也是在mark_clean的时候用本地最新的osdmap的epoch设置的
        // If the last_epoch_clean is included in this interval, then
        // the pg must have been rw (for recovery to have completed).
        // This is important because we won't know the _real_
        // first_epoch because we stop at last_epoch_clean, and we
        // don't want the oldest interval to randomly have
        // maybe_went_rw false depending on the relative up_thru vs
        // last_epoch_clean timing.
        i.maybe_went_rw = true;
} else {
        i.maybe_went_rw = false;
}

回退

  • 通过配置项回退,把osd_wait_up_thru配置项的值从false改为true即可(包括在线和离线)
  • 通过重装到老版本回退,在active状态下修改osd_wait_up_thru配置项为true,成功后停掉osd,重装版本,之后启动即可,按副本域顺序对osd操作。

风险

  • 单副本运行interval坏盘场景下,如果该interval并没有IO写入,但在osd_wait_up_thru=false的情况下,这个interval无法被跳过,可能导致pg错误的变成down+peering,需要手工修复。