这是我之前P5-1晋升答辩的PPT及演讲稿内容，答辩PPT讲解时间20分钟，评委提问环节不限时，通常30分钟左右。其实我第一次被主管提名P5-1是在2017年，我那一年6月份离职去了创业公司，二进宫之后之前的工作产出都清零了因此也就耽搁了几年。
更详细的工作内容可以参考这2篇文章：
page1 – 10s
各位评委下午好，我是基础平台存储部的xx，本次申请级别是P5-1
page2 – 60s
申请理由：18年入职主导解决Ceph云盘IO抖动问题，分析出3个根本原因并全部解决，极大提升了云盘稳定性和业务满意度，也提升了我分析问题、解决问题的能力，以及对分布式存储系统的理解。 20年开始带领存储团队，负责Ceph、NOS和Curve 3个项目的架构演进规划。主导了CephFS共享存储产品化，从0到1填补了集团互联网业务k8s RWX PVC存储方案的空白；主导了NOS内部降本和业务拓展，取得了良好收效，2年内存储量翻番；也规划了Curve共享文件存储的架构和应用场景及核心优势，并完成了项目的开发落地。这一阶段锻炼并提升了我的团队管理、项目管理、架构设计和业务沟通能力。希望能在更高的职级上为公司、部门、团队作出更大贡献。
这是我的基本信息，入职时间是18年8月，近几年的绩效都是B+。申请理由是：xxxxxx
page3 – 10s
这是我近几年的工作经历。
因为我汇报的工作内容比较多，后面的业务贡献部分讲的会比较快比较简略，如果有细节问题可以后面我讲完后再深入交流。
page4 – 30s — 2min **
这是我本次汇报的第一项业务贡献，开源ceph存储增强，这个项目的背景主要是，ceph作为云盘服务抖动频繁业务抱怨很大、运维成本高且容易导致线上故障，另外集团互联网业务也缺少稳定可靠的共享文件存储服务，我的工作就是解决这3个比较大的短板。IO抖动这方面，主要问题包括：（讲述PPT内容）；运维方面的问题主要包括：（PPT内容）；共享文件存储这方的工作主要是将CephFS产品化，解决相关业务的痛点需求，也为nos ec引擎升级打下了基础，解决了旧版本引擎读写性能和删除性能方面的不足。
page5 – 70s
首先解释下什么是IO抖动：IO时延超过3s就会导致磁盘util 100%，业务方磁盘监控就会告警。
经过深入分析，我找到了多个导致抖动的问题点，其中核心问题有3个，这是第一个。
cpeh云盘是3副本，这张图是3副本之间进行数据恢复的状态机转换图，而peering则是3副本达成一致的一个关键阶段，可以简单理解为选主，这一阶段无法提供IO服务。peering阶段流程比较复杂，简化来看主要包括4个阶段：
GetInfo：
GetLog：
GetMissing：
WaitUpThru：
经过分析，最耗时的阶段就是这个WaitUpThru。为了优化这个阶段耗时，我深入分析了4个问题：
这一阶段做了什么？是否可以降低其耗时？是否可以跳过这一阶段？怎么保证跳过后数据的一致性？
问题：优化peering耗时这个工作的挑战是什么？
为了搞清楚这些问题，我对代码做了反复调试，也买了几本书专门研究peering流程，并跟组里同事反复交流，最终确认可以跳过，但是后果是非常极端的场景下会有一点问题，但可以规避，而且我们运维非常及时不会导致进入极端场景。代码修改比较简单，但是为了保证数据一致性，我用ceph社区的集成测试套件反复跑了一个多月的故障测试，确认没有引发新的问题才最终上线，上线后，节省了peering阶段的大量耗时。
page6 – 60s — 4min **
这是引发抖动的第二个核心问题，问题发生在主osd协调副本osd恢复数据的阶段，这一阶段是可以提供IO服务的，但是如果客户端读的数据是主OSD上还没有完成恢复的，就需要先等待数据从副本OSD上先拉取回来之后才能正常读，如果是写请求，则要保证3副本都全部恢复同步才能继续写入，这一过程如果需要恢复的数据太多，就会导致排队时间过长，最终导致IO抖动。红框部分就是这一阶段所做的工作。
我所做的工作就是把这一阶段从同步改成异步，保证客户端IO请求可以正常读写，对于读请求，直接发到临时的主osd读取，对于写请求，在缺失数据的副本上只写入log，后续的恢复流程会填充数据解决这一问题。
这个方案解决了恢复数据阶段造成的IO抖动。
page7 – 50s **
ceph 是重运维系统，我们每周2次运维窗口，凌晨2点操作。人力\时间窗口受限，集群数量也多，手工运维容易忙中出错，也容易造成io抖动。
之前18年sre自动化运维工具效果不太好。我们开发团队基于ceph技术架构和抖动监控数据反复迭代优化，最终实现了基本无抖动的全自动运维。
另外ceph本身架构导致的抖动问题，主要是完善了监控告警，及时人工介入处理。
————
这是第3个核心问题，ceph是重运维系统，遇到坏盘、容量满、宕机等各种异常必须要及时处理，否则就会导致更严重的问题，比如丢数据或者无法写入数据等。一般我们是每周2次日常运维窗口期，凌晨2点开始，也偶尔会有紧急操作（比如3副本变成了1副本）。如果运维操作也会导致IO抖动，那每周都要至少影响2次业务，肯定是不能接受的，而且如果纯手工运维，所需时间太长，多个集群并发操作特别容易出错，窗口期要拉长很多，业务肯定也不能接受。之前sre同学也有做过自动化运维工具，但是由于对ceph底层代码逻辑不熟，工具无人值守的效果不好，还是会造成抖动，并且有一次还造成了线上事故，最终交给ceph团队运维。我们为了避免发生同样的问题，开发好之后人工值守执行了一个多月才敢无人值守，并且每次执行完都会根据监控到的抖动情况，对工具进行迭代优化，最终把运维时间窗口调整到半小时左右，并且对业务的影响降到最低。
另外还有一些抖动问题，是ceph的架构决定的，无法彻底解决，只能通过补全监控项，优化运维工具来规避，一旦出现抖动，及时发现问题根因进行上线处理（比如网络丢包严重、慢盘或raid卡故障等osd心跳正常无法自动下线的问题）。另外也有一部分是性能问题导致的，比如大量的删除数据或者写入数据，这方面的问题我们反复分析性能瓶颈并调整了配置项，但都只能缓解，最终还是要通过升级存储引擎解决。
page8 – 30s — 5min
这是优化后的效果对比，可以看到（PPT内容）
page9 – 30s
接下来介绍Ceph项目的第二个比较有挑战的工作项，CephFS产品化。主要有几十万行代码的掌控问题，以及与开源版本的对比优势问题，和可靠性可用性如何保障的问题。
page10 – 70s **
我们采用了与云音乐机器学习平台共建的方式来解决这3个方面的问题，这里以回收站功能为例进行介绍。
回收站在ceph开源版本和业界也没有很好的解决方案，主要是回收难和还原难两大挑战。我们想到3种可能的方案解决回收难问题，第一个是在客户端做，把删除操作转换为mv到回收站，问题是多种客户端类型的兼容性不行。
第二种是在元数据服务端MDS上做，基于ceph本身已有异步删除机制改造，但是改动的逻辑非常复杂，容易引入问题，后期维护也很困难。
第三种是把第一种方案的实现移动到了MDS服务端，保证了兼容性，改动也不多，回收难的问题解决了。
还原难，主要是恢复时怎么保持删除前的目录结构？业界其他文件系统很多都是平铺放到回收站里，用户自己挑选要恢复的文件并自己想办法还原目录结构，实际的用户体验非常差，我们对此做了优化，可以做到又快又好的恢复。
page11 – 30s — 7min
这是共建项目的效果，（PPT内容），产品化这块有了这些优势，其他业务也愿意用我们的产品了（之前有很多业务是自己搭共享存储服务）。
page12 – 30s
我们自己维护了10个以上的cephfs集群，有xxPB多 的业务数据，并且我们还为多个商业化项目提供了L2支持，其他也有一些自己部署cephfs的部门也会找我们协助解决遇到的问题，有几个业务集群本来是自己维护的，最终都托管给我们运维了。SLA这方面，目前只有传媒专属集群有损失，2年17分钟，都是社区bug引入，其他集群都没有，全部集群都没有数据丢失问题。
page13 – 60s
这是我要讲的第二个业务贡献，Curve分布式存储，我是20年7、8月份接手的curve项目，面临的问题主要包括：1）块存储的未来如何发展？2）云原生存储是什么样的？3）云原生文件存储是什么样的？我们的技术架构上要做出什么优势？
我们对curve的定位：云原生、高性能、易运维。下面的挑战项也主要是针对高性能、易运维来描述的。
page14 – 30s — 9min
经过调研和思考总结，我定义了curve的总体架构和应用场景：
- 作为openstack的云盘
- 作为k8s的pvc卷
- 作为云原生数据库的存储底座
- 基于对象存储在公有云或混合云场景提供高性价比的文件存储服务
今年重点发展内部cephfs集群使用非常多的AI训练场景和云原生数据库场景。
以及结合内外部业务使用cephfs的情况，我们发现在AI训练场景下对共享存储有强烈需求，并且大部分业务也是在k8s平台上使用，与云原生存储的趋势相符。另外21年以来，国内比较流行的juicefs和cubefs的发展趋势也证明了我们的判断。
对于块存储，我们高性能优势，主要用作文件存储的高性能引擎，以及对接了polardb for pg，后来又对接了内部数据库团队开发的bosondb。
page15 – 60s
Curve项目的第二个挑战：如何保证Curve具备高性能优势
块存储的困难主要包括：1、2、3、4
文件存储的困难主要是：1、2、3、4、5
后续的目标：
curve块存储的性能主要是时延这方面与公有云上的云盘服务比如阿里云的essd盘等我们还有比较大的优化空间，我们也在进一步优化，所以这里的性能优势目前还是与开源的ceph对标的。
文件存储的性能方面，我们主要对标开源的cephfs、juicefs和cubefs，在元数据和数据方面也取得了一些优势，但是目前仍然有一些优化空间需要我们继续努力。
page16 – 60s — 11min
这是文件存储的元数据性能对比效果，juicefs的元数据引擎是tikv，我们性能优势非常明显。
cubefs的元数据架构跟我们非常类似，都是raft一致性（我们把数据持久化到rocksdb，他们是内存+snapshot持久化），因此与他们性能比较接近，有一个场景我们优化，提升缓存数量。
这是数据面的对比数据，块存储经过条带化改造之后，在较低的io深度场景下也能达到很好的性能，可以做到与ceph接近。
文件存储方面，我们与juicefs类似都是用对象存储作为数据引擎，对比来看，有缓存盘并且缓存盘空间没有满的时候性能接近，我们的优势在于缓存盘满了之后的性能优势比较明显
page17 – 60s
第三个易用性的问题，也是curve主打的特色之一，我们参考TiDB项目的TiUP部署运维工具，也调研对比了cephadm，开发了curveadm，相比cephadm具备了不少易用性优势，也在tiup的基础上进行了一些小的创新。得到了社区用户的认可，根据运营同学统计，目前社区用户部署的错误率已经极大降低。
page18 – 60s — 13min
这是我要介绍的第三个业务贡献，NOS对象存储，NOS大家都比较熟悉，已经上线10年整。最大的困难是什么？10年的老项目如何运营？如何创新？如何进行架构演进？我们遇到了很多方面的问题，根据第一性原理，我认为最终还是业务发展缓慢数据增量太少导致的。经过分析团队还面临一个恶性循环，我要做的就是想方设法打破这个恶性循环。
page19 – 30s
打破恶性循环的关键就是要做到nos内部降本，然后再给业务降价。
我们在nos核心存储服务和周边服务这两个方面通过技术演进发力降本，实现了降价不降利润的效果，每PB的利润不变。因为降价业务就可以用同样的成本存储更多的数据，我们的利润自然也就增长上来了。
page20 – 60s
挑一个EC引擎场景下的小文件空间利用率的问题来细讲一下相关挑战。
首先NOS存储的文件分布情况，可以看到我们小文件的比例和大小都比业界64k的小文件标准低很多，业界通常在收费标准上做文章，不足64k按64k收费，我们则想要通过技术创新来解决这个问题。
我们这方面做了3次技术演进，首先是不做合并，解决低频存储从无到有的问题（当时优先转存的是大文件），其次是小条带，横向排列方式的合并，解决小文件场景下条带利用率低的问题。之后我们演进到纵向排列，配合我们做的smartclient能力，解决了IOPS放大问题。
这里包含了2项专利，都已经在专利局网站上公布了。
page21 – 60s
条带利用率统计数据可以看到，都在80%以上（原来平均在60%多不到65%），绝大部分都在90%以上，效果非常显著。
今年上半年与去年同期相比，营收和利润提升明显，利润接近40%的提升，成本下降了近40%。
最终实现了成本比公有云厂商更低的价格，内部大客户报价连续2年打7、8折，是阿里云oss价格的X折左右。
另外我们在2年内实现了存储容量翻一番，增量非常迅猛。业务满意度在今年上半年也取得了历史最高值。
page22 – 30s — 16min **
这个也不多介绍，我们冷归档由于idc硬件条件限制和业务规模限制，只能采取与公有云联合共建方式，在折扣方面也取得了不少效果，从原来的X折拿到了X折。
并且我们自研了归档存储，相比X折后的公有云厂商报价仍然有价格优势，目前都已经上线，尤其是冷归档已经转存了XPB数据，给业务节省了不少成本，这些省下来的成本都用来存储更多的数据了，也是我们增量的主要来源。
page23 – 20s
page24 – 20s
这篇文章荣获网易集团内部知识分享平台《2022年度十佳作者》及《2022年度十大人气文章》。
page25 – 30s **
与公司的要求差距，主要是curve文件存储的创新方面虽然有几个项目落地，但还处于推广初期，另外块存储的性能优势提升还没有质的飞跃。另外就是绩效一般，curve社区的用户和开发者还不够多。
后续将尽快推动curve文件存储的落地，把创新的效果展现出来，把curve开源社区发展起来。nos主要是要继续保持盈利，在成本方面要比竞品厂商（已经不只是公有云）有比较优势，并且做好长期的技术演进规划和技术储备，确保长期的稳定发展。
page26 – 10s — 18min
致谢
