晋升PPT及讲稿 – 202209

更详细的工作内容可以参考这2篇文章：

各位评委下午好，我是基础平台存储部的xx，本次申请级别是P5-1

这是我的基本信息，入职时间是18年8月，近几年的绩效都是B+。申请理由是：xxxxxx

这是我近几年的工作经历。

因为我汇报的工作内容比较多，后面的业务贡献部分讲的会比较快比较简略，如果有细节问题可以后面我讲完后再深入交流。

这是我本次汇报的第一项业务贡献，开源ceph存储增强，这个项目的背景主要是，ceph作为云盘服务抖动频繁业务抱怨很大、运维成本高且容易导致线上故障，另外集团互联网业务也缺少稳定可靠的共享文件存储服务，我的工作就是解决这3个比较大的短板。IO抖动这方面，主要问题包括：（讲述PPT内容）；运维方面的问题主要包括：（PPT内容）；共享文件存储这方的工作主要是将CephFS产品化，解决相关业务的痛点需求，也为nos ec引擎升级打下了基础，解决了旧版本引擎读写性能和删除性能方面的不足。

首先解释下什么是IO抖动：IO时延超过3s就会导致磁盘util 100%，业务方磁盘监控就会告警。

经过深入分析，我找到了多个导致抖动的问题点，其中核心问题有3个，这是第一个。

cpeh云盘是3副本，这张图是3副本之间进行数据恢复的状态机转换图，而peering则是3副本达成一致的一个关键阶段，可以简单理解为选主，这一阶段无法提供IO服务。peering阶段流程比较复杂，简化来看主要包括4个阶段：

GetInfo：

GetLog：

GetMissing：

WaitUpThru：

经过分析，最耗时的阶段就是这个WaitUpThru。为了优化这个阶段耗时，我深入分析了4个问题：

这一阶段做了什么？是否可以降低其耗时？是否可以跳过这一阶段？怎么保证跳过后数据的一致性？

问题：优化peering耗时这个工作的挑战是什么？

为了搞清楚这些问题，我对代码做了反复调试，也买了几本书专门研究peering流程，并跟组里同事反复交流，最终确认可以跳过，但是后果是非常极端的场景下会有一点问题，但可以规避，而且我们运维非常及时不会导致进入极端场景。代码修改比较简单，但是为了保证数据一致性，我用ceph社区的集成测试套件反复跑了一个多月的故障测试，确认没有引发新的问题才最终上线，上线后，节省了peering阶段的大量耗时。

这是引发抖动的第二个核心问题，问题发生在主osd协调副本osd恢复数据的阶段，这一阶段是可以提供IO服务的，但是如果客户端读的数据是主OSD上还没有完成恢复的，就需要先等待数据从副本OSD上先拉取回来之后才能正常读，如果是写请求，则要保证3副本都全部恢复同步才能继续写入，这一过程如果需要恢复的数据太多，就会导致排队时间过长，最终导致IO抖动。红框部分就是这一阶段所做的工作。

我所做的工作就是把这一阶段从同步改成异步，保证客户端IO请求可以正常读写，对于读请求，直接发到临时的主osd读取，对于写请求，在缺失数据的副本上只写入log，后续的恢复流程会填充数据解决这一问题。

这个方案解决了恢复数据阶段造成的IO抖动。

ceph 是重运维系统，我们每周2次运维窗口，凌晨2点操作。人力\时间窗口受限，集群数量也多，手工运维容易忙中出错，也容易造成io抖动。

之前18年sre自动化运维工具效果不太好。我们开发团队基于ceph技术架构和抖动监控数据反复迭代优化，最终实现了基本无抖动的全自动运维。

另外ceph本身架构导致的抖动问题，主要是完善了监控告警，及时人工介入处理。

————

这是第3个核心问题，ceph是重运维系统，遇到坏盘、容量满、宕机等各种异常必须要及时处理，否则就会导致更严重的问题，比如丢数据或者无法写入数据等。一般我们是每周2次日常运维窗口期，凌晨2点开始，也偶尔会有紧急操作（比如3副本变成了1副本）。如果运维操作也会导致IO抖动，那每周都要至少影响2次业务，肯定是不能接受的，而且如果纯手工运维，所需时间太长，多个集群并发操作特别容易出错，窗口期要拉长很多，业务肯定也不能接受。之前sre同学也有做过自动化运维工具，但是由于对ceph底层代码逻辑不熟，工具无人值守的效果不好，还是会造成抖动，并且有一次还造成了线上事故，最终交给ceph团队运维。我们为了避免发生同样的问题，开发好之后人工值守执行了一个多月才敢无人值守，并且每次执行完都会根据监控到的抖动情况，对工具进行迭代优化，最终把运维时间窗口调整到半小时左右，并且对业务的影响降到最低。

另外还有一些抖动问题，是ceph的架构决定的，无法彻底解决，只能通过补全监控项，优化运维工具来规避，一旦出现抖动，及时发现问题根因进行上线处理（比如网络丢包严重、慢盘或raid卡故障等osd心跳正常无法自动下线的问题）。另外也有一部分是性能问题导致的，比如大量的删除数据或者写入数据，这方面的问题我们反复分析性能瓶颈并调整了配置项，但都只能缓解，最终还是要通过升级存储引擎解决。

这是优化后的效果对比，可以看到（PPT内容）

接下来介绍Ceph项目的第二个比较有挑战的工作项，CephFS产品化。主要有几十万行代码的掌控问题，以及与开源版本的对比优势问题，和可靠性可用性如何保障的问题。

我们采用了与云音乐机器学习平台共建的方式来解决这3个方面的问题，这里以回收站功能为例进行介绍。

回收站在ceph开源版本和业界也没有很好的解决方案，主要是回收难和还原难两大挑战。我们想到3种可能的方案解决回收难问题，第一个是在客户端做，把删除操作转换为mv到回收站，问题是多种客户端类型的兼容性不行。

第二种是在元数据服务端MDS上做，基于ceph本身已有异步删除机制改造，但是改动的逻辑非常复杂，容易引入问题，后期维护也很困难。

第三种是把第一种方案的实现移动到了MDS服务端，保证了兼容性，改动也不多，回收难的问题解决了。

还原难，主要是恢复时怎么保持删除前的目录结构？业界其他文件系统很多都是平铺放到回收站里，用户自己挑选要恢复的文件并自己想办法还原目录结构，实际的用户体验非常差，我们对此做了优化，可以做到又快又好的恢复。

这是共建项目的效果，（PPT内容），产品化这块有了这些优势，其他业务也愿意用我们的产品了（之前有很多业务是自己搭共享存储服务）。

我们自己维护了10个以上的cephfs集群，有xxPB多 的业务数据，并且我们还为多个商业化项目提供了L2支持，其他也有一些自己部署cephfs的部门也会找我们协助解决遇到的问题，有几个业务集群本来是自己维护的，最终都托管给我们运维了。SLA这方面，目前只有传媒专属集群有损失，2年17分钟，都是社区bug引入，其他集群都没有，全部集群都没有数据丢失问题。

这是我要讲的第二个业务贡献，Curve分布式存储，我是20年7、8月份接手的curve项目，面临的问题主要包括：1）块存储的未来如何发展？2）云原生存储是什么样的？3）云原生文件存储是什么样的？我们的技术架构上要做出什么优势？

我们对curve的定位：云原生、高性能、易运维。下面的挑战项也主要是针对高性能、易运维来描述的。

经过调研和思考总结，我定义了curve的总体架构和应用场景：

1. 作为openstack的云盘
2. 作为k8s的pvc卷
3. 作为云原生数据库的存储底座
4. 基于对象存储在公有云或混合云场景提供高性价比的文件存储服务

今年重点发展内部cephfs集群使用非常多的AI训练场景和云原生数据库场景。

以及结合内外部业务使用cephfs的情况，我们发现在AI训练场景下对共享存储有强烈需求，并且大部分业务也是在k8s平台上使用，与云原生存储的趋势相符。另外21年以来，国内比较流行的juicefs和cubefs的发展趋势也证明了我们的判断。

对于块存储，我们高性能优势，主要用作文件存储的高性能引擎，以及对接了polardb for pg，后来又对接了内部数据库团队开发的bosondb。

Curve项目的第二个挑战：如何保证Curve具备高性能优势

块存储的困难主要包括：1、2、3、4

文件存储的困难主要是：1、2、3、4、5

后续的目标：

curve块存储的性能主要是时延这方面与公有云上的云盘服务比如阿里云的essd盘等我们还有比较大的优化空间，我们也在进一步优化，所以这里的性能优势目前还是与开源的ceph对标的。

文件存储的性能方面，我们主要对标开源的cephfs、juicefs和cubefs，在元数据和数据方面也取得了一些优势，但是目前仍然有一些优化空间需要我们继续努力。