100. 相同的树

题目链接:https://leetcode.cn/problems/same-tree/

自己写了一个,用递归遍历,同步记录遍历的节点到vector,空节点用比较大的负数表示,但是会重复遍历一些子节点(虽然也能正确判断两棵树是否相同)。下面这个是官方答案。另外我也尝试用循环遍历,但是记错了,用了stack,而不是queue。空了试下queue。

 

98. 验证二叉搜索树

题目链接:https://leetcode.cn/problems/validate-binary-search-tree/

没能把中序遍历和搜索二叉树联系起来,看的评论区题解。

 

谁是最亲近的人?

记不清从啥时候开始,只有我老婆记得我的生日。农历生日,真是记不住,连我自己也都不知道农历是什么日子。

犹记得18周岁生日那天在大学宿舍听收音机(是的,收音机,暴露年龄了),广播里的主播说今天是光棍节(11.11,也就是现在的双11),那是我第一次知道还有光棍节这个说法,本来以为4个1,好兆头啊。当时也正被感情困扰(不过单相思罢了),以为这辈子就是光棍命了。

幸好老天眷顾,在研究生快毕业的时候遇到了现在的老婆,还算顺利的过了11年。这几年聚少离多,但感情还算不错,日子也能过得下去(除了俩儿子有点气人)。

希望以后的日子全家人也平平安安,健健康康,顺顺利利。

我老婆常说,孩子长大了就不是自己的了,是他们自己一家子的,只有夫妻才是同路人。

95. 不同的二叉搜索树 II

题目链接:https://leetcode.cn/problems/unique-binary-search-trees-ii/

这题不会,直接看的题解。

 

立个flag

感觉不把flag立起来就一直不能静下心来动手写代码,先立起来,看看啥时候能搞定:

  • 先写一个brpc的服务,学一学brpc怎么玩的,最简单的实现一个http服务(get、post)
  • 再写一个braft应用,在多个节点上实现一个分布式的id查询和自增服务

 

2022-11-09

下载brpc代码库,v1.3版本分支,Ubuntu 22.04上完成编译,完成echo_c++ example代码编译和运行。下一步适当修改,改造成一个http的服务。

2022-11-11

简单改了下Echo示例代码,加了个rpc参数,表示消息长度,改成了http协议:

运行结果:

curl请求:

 

HTTP service,读文件内容:

运行结果:

 

 

 

236. 二叉树的最近公共祖先

题目链接:https://leetcode.cn/problems/lowest-common-ancestor-of-a-binary-tree/

不会做,看的答案。

原理是先遍历二叉树,用hash map记录所有节点的父节点,然后分别遍历p、q节点的父节点并染色(用hash map记录节点是否染色过),遇到重复染色的节点即为二者的共同祖先节点。

 

 

网易对象存储NOS十周年纪念文章

上上周花了几个晚上,整理了下对象存储服务NOS的历史,想了些后续规划,总结了一些经验教训,形成了一篇上线10周年的纪念文章,发表在网易杭研的公众号上,文章内容就不贴了,放个链接省事儿了。

网易对象存储NOS十周年

目录:

NOS介绍

1.1 NOS能干什么?

1.2 为什么要做NOS?

1.3 NOS凭什么10年不被取代?

NOS历史

2.1 这10年NOS都做了什么? 

2.2 架构变化

2.3 怎么保持10年稳定运营?

2.4 NOS功臣访谈

NOS现状

NOS未来

 

我这4年都做了什么

为什么要写这篇文章

昨天收到提名通过的邮件之后,就开始着手准备答辩PPT,但是思来想去,感觉要写的东西比较多,想要在20分钟讲完讲透,一时半会儿还挑不出重点,写PPT确实不是我的强项,干脆先都先用文字写出来,再从里面挑选重点内容放到PPT里面,也算是一种对这几年工作的全面回顾和反思,以后万一哪天不得不更新简历的时候,也能有点素材。
晋级可以不提名,可以不通过,但是不能不反思不正视自己的不足。权且把答辩当作一次面试。
刚毕业在华为工作,有一句话我印象非常深刻:“板凳要坐十年冷”。要成为大佬,就要耐得住寂寞,顶得住压力,眼光放长远,切莫急功近利。我比较鄙视的一种行为:挖个坑,晋个升,跑个路,循环往复。这么玩儿几次就把自己的技术声誉败光了,我对自己的技术声誉和职业道德还是有信心的,做项目的第一原则:尽量不给后人挖坑,除非真的到了我能力上限。
需要声明的是,如下项目除了前两年我自己做开发的时候自己动手做了不少事情,后面两年其实都是团队小伙伴们实际动手做的,我只能提出想法和规划,毕竟一个人的能力非常有限,项目的成功都是小伙伴们的功劳,项目做得不好,负责人的问题最大。

我理解的P5大佬应该具备的能力

公司要求和我的理解

【关键词】面:方法论,事业部内
  • 作为事业部内公认的某方面的专家,能够解决较复杂的问题或领导大中型项目;
    • 前面半句比较抽象,也不好自我证明
    • 后面半句更具体一些,我理解要么就是解决某一个专业方向的业界技术难题,以我略懂的云计算领域来举例,你要可以解决底层虚拟化性能问题,优化之后能达到业界领先水平,或者在提升计算资源利用率方面做到业界领先,或者在网络方面性能水平达到业界领先(而不是仅仅用开源跑起来),存储领域你就要对标业界主流开源项目的性能和可靠性(最好可以超越),或者你可以成为某个大型开源社区的core developer,甚至某个子模块的maintainer,或者中小型但比较流行的开源社区的maintainer
    • 就是要领导过大中型项目,这个我理解你要带领团队开发过一个完整的项目,我理解中型项目标准应该是5w行以上业务代码,核心功能模块3个或以上,大型项目则要超过10w行。这个标准可能实际还会更高一些。
  • 在本专业某主要领域具有精通、全面的知识和技能,是集团内公认这一领域的专家,在多个子领域的技术能力在集团内领先,在集团内作出显著创新;
    • 还是后半句更具体,我理解多个子领域的技术能力在集团内领先,这一点就要做到你主导的项目在集团内没有比你更好的解决方案,如果有,则表示你的技术能力不够领先;有一些公司有内部赛马机制(也有叫红军蓝军的),这种情况下就很容易体现出你的项目是否在集团内领先了
    • 在集团内作出显著创新,这方面参考创新奖申报条件,如果是集团外部或者业界已经用了比较长的时间或者成熟的方案,你只是在集团内部最先引入或者稍加改进,这不能算创新,创新要引领业界趋势,而不是简单的跟随
  • 技术成果对所在事业部的成功是重要的依赖因素;
    • 这个也容易理解,你负责的项目是否对事业部OKR有很好的支撑效果,项目的成功对事业部OKR会产生较大的正面影响,项目不成功会导致严重的负面影响。如果这个项目对事业部的OKR来说可有可无,那就要考虑项目存在的必要性和价值了,这方面做维护性的项目肯定是吃亏的
  • 能够解决复杂的问题或领导大中型项目;
    • 与第一条重复
  • 能够把握本专业的发展趋势,并是与本专业发展规划与业内发展趋势相吻合;
    • 这一点比较抽象,比较难自证,但是可以参考第二点,技术能力在集团内领先,并作出显著创新,如果不能把握本专业的发展趋势,就很难做到显著创新
  • 可以指导本专业内的一个子系统有效运行。
    • 参考第一点,能领导大中型项目应该就满足这条

我的不足

  • 在多个子领域的技术能力在集团内领先,在集团内作出显著创新;
    • 创新这块应该有些子领域做的还不错,还有个别领域正在做,但是落地成果还没有很好的体现,目前还处于推广初期
  • 能够把握本专业的发展趋势,并是与本专业发展规划与业内发展趋势相吻合;
    • 这方面跟上面一条有点关联,推广顺利的话就能证明趋势把握的是正确的,否则就比较难说
除了上面公司要求的不足之处外,我理解自己的不足还有如下几点:
  • 绩效不算好,近几年一直都是B+,原因我理解主要包括:
    • 前两年做开发,产出和落地不明显,抖动问题解决了之后,由于规模比较大,升级本身也会造成IO抖动,因此需要非常长的升级上线时间,当时效果还没有体现,并且Ceph项目是维护项目,确实也比较难出高绩效
    • 项目带的不好,主要是Curve这块,近两年一直都在开发新的文件存储功能,近期才刚刚开始落地,项目价值还没有很好的体现出来;另外块存储的性能优势也没有达成质的飞跃
    • NOS项目我认为做的还算不错,虽然也是维护项目,线上故障也有几次,但是近两年一直在进行微创新
  • Curve项目发展不达预期,尤其是开源社区建设方面,外部用户数量还不太多,这个原因有很多,最根本的还是我们内功没练好,功能也比较欠缺,用户想用也用不起来
所以这也是前面几次晋升提名我都没有积极参与的主要原因,这次也是感觉希望渺茫。

怎么弥补

  • 尽快把不足的子领域的推广落地效果拿出来,展示出来项目在集团内或者业界的创新成果和给事业部带来的收益。
  • 某些子领域项目的研发进度有些略低于预期,这与项目的复杂度和团队成员的构成有一定关系,也与个人的项目管理能力有一定关系,这2个方面要继续加强,提升团队战斗力和个人项目管理能力
  • 复盘,思考改进方向

基本信息

工作经历

2018.08-至今  网易/杭州研究院/技术工程事业部   资深服务端开发工程师
2017.07-2018.08  杭州云容科技有限公司   技术总监
2012.06-2017.07   网易/杭州研究院   高级/资深服务端开发工程师
下面是废话:
我这边情况比较特殊,属于“二进宫”,之前因为一些原因出去跟前同事一起搞了一段时间私有云平台,搞了几个项目之后发现有点搞不动(小公司的认可度、长期维护能力等客户都存疑),在外面一年后就又回到现在的部门。
17年出走那次是主管给我报名了P5的晋升提名的,不过我最终还是想出去闯一次,结果其实当时就知道90%是会失败的,不过不试试看总是不甘心的。所以现在的状况我也能欣然接受,都是出走之前考虑到的。
17年之前一直在做云计算平台相关工作,出走的原因之一也是因为平台已经稳定能做的事情不多,还是想在技术上有更多发展;原因之二是当时组里一位基友做线上升级的时候,搞出来一个大锅,我们几个小伙伴花了几个小时紧急修复之后,又折腾了几天几夜才算完成收尾,这让我倍受打击,当时也没啥心情参与晋升答辩了(感觉搞出来这么大的锅哪还有脸晋升),现在想想还是心态不够稳,没有历练出来,这几年明显感觉有进步,遇到线上问题至少手不抖了。
18年回来之后改做云存储,也是云计算的一部分。换一种方向也挺好,我跟之前的同事互相吹捧的时候,就提到过,云计算的3大底层模块,计算&存储我都能玩的转,何愁没有出路(年龄问题不考虑的话。。。)。上一篇文章我写过,工作就是为了赚钱,要么现在赚钱,要么以后赚钱,其实软件行业还可以加一条,要么可以延长职业生涯,做底层存储应该会有这方面的好处。
回来的时候前领导跟我交流,提到一点,就是这次回来能不能做的长远一点,我12年进公司,到17年正好5年,其实在这边工作真的挺好的(发自肺腑),有需求,有落地,有价值,还有好基友,否则也不会考虑“二进宫”了,去别的公司也可以混口饭吃。所以我“二进宫”之前就答应领导只要我还能干的动,部门还需要我,我还有价值,就能一直做下去,18年到现在也4年了,这一点我认为我做到了,不过我的工作还有很多要改进的地方,后续还会继续尽力改进。
近4年来,前面2年其实还是主要做ceph开发和维护工作,后面会有介绍。后面2年主要带存储团队,包括ceph在内一共3个项目,有的做的还可以,有的还需要继续努力,后面也会有介绍。做开发的时候,Ceph已经处于维护状态,而近2年Curve项目新开发的文件存储系统效果还没体现出来,所以我的绩效一直是B+,这个结果我是非常理解的,也清楚做到什么程度才能拿到更高的绩效,并且一直在努力推动落地。

申请理由

申请理由有点“自吹自擂”的感觉,但是还是要把重点工作产出实事求是的讲出来,否则其他人怎么了解你的工作价值?这一部分有很大的难度,因为内容很短,要求很精练,并且突出重点核心工作,我这方面做的不好,容易陷入技术视角,描述很多技术细节;另外还有就是不善于包装,我了解到商业化项目有很多架构师可以把一件不那么有技术含量的东西包装的很高大上来“忽悠”客户买单,这种能力在打单的时候真的是必不可少,在晋升答辩的时候肯定也有一定的效果,但不能过头要把握好尺度(反正我也不会)。
原始理由特别长,肯定不适合放在一个小文本框里:
  1. Ceph项目(2020年开始主导):
    1. 参与Ceph成本优化项目,2020年成本下降到2018年的1/6
    2. 参与Ceph块存储优化项目,通过规范运维标准化及配套工具,优化集群监控报警,块存储近4年未出现较大故障,基本没有SLA损失,云盘抖动情况显著改善,同时节省SA半个人力
    3. 参与并主导cephfs容器场景产品化项目,填补了k8s RWX PVC存储的空白,解决了传媒,严选,云音乐等部门共享文件存储的痛点,集群数量达到10+,业务数据达到xxPB+
  2. Curve项目(2020年开始主导):
    1. 推动Curve块存储业务规模发展,2年内集团内部存储数据容量从不到xxxTB增加到超xxPB,同时发展外部用户数家;近2年未发生集群级故障,性能和稳定性相比Ceph云盘有了极大提升了
    2. 带领团队完成了Curve文件存储的规划、设计及开发,数据和元数据相关性能均达到开源存储项目的领先水平,目前正在推广落地中
    3. Curve开源社区建设方面,推动Curve加入CNCF基金会sandbox项目、信创认证、PG数据库社区共建等社区建设工作,目前已有数位外部贡献者,以及数家外部用户,测试中用户10+
  3. NOS项目(2020年开始主导):
    1. 通过技术架构升级推动NOS内部降本,相比xx云OSS 9折甚至更低;开发上线1.2副本低频存储(xxPB)及冷归档存储(xxPB),为业务方节省大量成本
    2. 持续进行业务拓展(xx、xx、xx等),年营收增长达30%以上
    3. 通过主动为业务降本及共建等手段,持续提升业务方满意度,上半年更创新高;近2年SLA均超过99.5%
精简后的理由,总感觉没有抓住重点(也有可能是项目本身也没有什么特别的亮点):
  1. 带领Ceph团队支撑近千台规模Ceph块存储和文件存储产品,对Ceph进行较多定制化开发和性能优化,快速响应解决多次开源社区bug导致的故障
  2. 带领Curve团队持续优化性能并相比开源竞品保持领先优势;在Curve文件存储架构设计和开发落地、开源社区建设等方面成果显著
  3. 带领NOS项目通过内部降本、主动的为业务优化成本,项目的满意度提升显著,年存储数据增量30%以上,容量翻番达xxPB,为基础平台实现收支平衡贡献了较多的营收和利润,同时也获得了xx、xx内部新增大客户,以及外部商业化项目xx

业务贡献

Ceph优化

ceph团队规模,最多的时候有超过x个人,目前有x个人不到在做维护工作。我是18年中加入的,20年开始带团队。
这个标题一直想不好怎么写,因为是一个半维护项目,涉及到的组件或者服务也比较多,怎么才能在标题里把这个项目做的全部或者至少主要工作表达出来,非常有挑战,现在只能简单的写 Ceph优化。
上面申请理由里面提到了一些重点工作,这里再罗列一下(项目产出在成果那一节里面再写):
  • 成本优化:机柜整合,存储池整合,容量均衡,空间清理(社区bug导致集群topo信息额外占用了大量存储空间)
  • IO抖动优化:ceph的io抖动问题对业务影响非常大,而且很频繁,一直是业务抱怨最多的痛点问题,18~19年花了很大力气去优化,这几年已经有了极大改善(当然也有一部分原因是个别业务方做了一些日志异步打印等方面的改造)
  • 运维优化:ceph的运维工作,经历了3个阶段,首先是ceph开发团队自己运维,之后是sre/sa运维,最后又回归到了ceph开发团队,切换给sre/sa的原因是研发团队想专注做开发工作,运维毕竟不是研发团队的强项,后来又切到ceph开发团队的原因,也是ceph运维具有极高的复杂性和问题紧急分析处理能力,如果对ceph不够熟悉,定位分析时间长还只是一方面,严重的话会导致把问题放大进一步恶化,又扯远了。。。总之这块就是把之前要人肉凌晨2点操作的日常运维工作,全部实现了自动化无人值守(之前sre也做过类似工具,但是因为对ceph技术细节了解不够深入,导致了线上事故就没有继续使用),并且做到了不会造成IO抖动,这一点我认为是非常值得ceph团队骄傲的
  • cephfs共享文件存储产品化:ceph团队最开始只有块存储(rbd)项目在做,但共享文件存储需求在k8s集群的部分业务场景下是强需求(RMX的PVC),比如AI训练、机器学习、web服务端共享存储、分布式视频处理等,但是公司内部没有团队提供相关的存储系统,19年的时候ceph团队就把cephfs这个存储系统给产品化了,解决了多个业务团队的需求,后面还跟云音乐机器学习平台共建了几个高级特性,目前有10多个业务方生产集群在跑
  • ceph性能优化:通过改造ceph底层引擎以及增加扩展接口,提升ceph性能
  • ceph生产环境故障处理:面对几十个集群,这几年我们遇到过多次线上生产环境的故障,基本都是社区bug导致的(我们ceph团队开发的功能和运维操作,可以说没有引入过线上事故),从发现事故到业务快速恢复,即考验对ceph的掌控程度,也考验紧急情况下的团队合作能力,这一点我对ceph团队的小伙伴非常满意
  • ceph商业化项目支撑:ceph团队给轻舟、低代码、easyAI等业务也提供了很多poc甚至生产环境的L2支持(主要形态是共享文件存储和对象存储),帮助相关团队解决了不少技术问题;甚至还做了rgw对象存储的商业化尝试,另外也有一些集团内部业务自己部署的ceph集群遇到问题也会找我们解决

背景和必要性

Ceph这个项目最大的问题在于前两年处于半维护状态(近一年多已经是完全的维护状态了),那么项目的必要性就比较难描述,ceph是一个重运维的项目,但是如果没有人做这些事情甚至运维不及时,线上环境肯定早就出大问题了(我们做商业化项目的L2支持的时候,经常遇到poc环境甚至生产环境已经搞得一团乱了才来找我们解决),cephfs集群也不会扩展到10来个。
必要性我这里就按我的理解挑重点写几点吧:
  • 成本优化:这方面的必要性不用细述,都能理解,集团这几年的重点考核要求之一
  • IO抖动优化:这个涉及到业务方满意度甚至基础设施部的SLA,也是基础设施团队的重点考核要求之一
  • 运维优化:节省人力(否则每周2次的日常运维,都是人肉在凌晨2点做,通常耗时半小时以上,ceph团队一共就3个人肯定吃不消),另外可以减少人为操作导致的故障和IO抖动(运维流程标准化、工具化、可回溯),这也是团队经过长期运维实践总结出经验固化到工具里,工具刚开始用的时候也是人肉观察调整了一个多月才敢无人值守,就怕造成抖动或事故
  • cephfs产品化:这个也不用多解释,从0到1,解决了共享文件存储的业务需求
其实上面列出来的重点工作,每一条都有其必要性,毕竟维护项目谁也不愿意做无意义的事情,直白点说就是维护工作难出好绩效。另外很多事情都是业务方主动找我们做的,比如cephfs的产品化和云音乐goblin共建项目,没有cephfs他们就只能自己搭nfs或者自己折腾其他存储系统,并且要承受不可控的SLA水平。

项目挑战

挑战1:IO抖动问题优化

IO抖动的定义:云主机的云盘IO时延超过3s,会导致云盘的util 100%,业务会收到大量磁盘util告警,并且如果IO时延达到几十秒甚至分钟级,就会导致业务集群出现严重问题,甚至引发雪崩效应。
这里面其实包含了多个场景下的IO抖动问题,比如坏盘、慢盘、扩容、容量均衡、宕机恢复、网络丢包或者时延飙高、集群负载飙高等等,以及实施成本优化、运维优化的过程中也有很大可能造成IO抖动,为了解决这个老大难问题。
经过长时间深入分析,Ceph IO抖动问题的根源主要包括:
  • 部署问题:ceph monitor服务是整个集群唯一的中心化服务,正常情况下他不会对IO时延产生影响,但是由于最开始选型的同事没考虑到在异常场景下会导致恢复时间过长带来IO抖动
  • ceph本身架构问题:多副本强一致导致任何一个节点或磁盘的响应时间超过3s就会造成IO抖动,如果是彻底挂掉还好(配置的心跳超时时间在7s左右,IO抖动时间也基本如此),就怕心跳还偶尔半死不活,这种情况就会一直抖动,我们也尝试从代码逻辑层面做了一些优化(遇到半死不活就自杀),不过发现其他策略效果还不错,并且这种问题发生的概率比较低(也有规避手段),就没有打开相关配置(主要怕大面积误杀)
  • ceph代码实现问题:pg锁问题,peering流程问题,monitor负载问题等等
  • 运维操作流程问题:如果不能自动化运维,为了不造成抖动就要进行各种微调,导致运维耗时非常长,自动化才能解决此类问题
  • ceph底层性能问题:filestore存储引擎在大量删除文件和写入大量小文件之后的性能问题等等,因此后续我们上线的cephfs和nos ceph-ec集群全部都切换到了bluestore,也取得了良好的效果(当然也顶住了数据可靠性的风险,其实是偷偷上的,当时的团队负责人担心bluestore数据可靠性有问题不同意使用,在这一点上我们ceph团队的小伙伴还是非常给力的,做到了不给后来人挖坑)。

解决方案:
  • 部署优化:把monitor节点使用的hdd盘换成更高性能的ssd,并把大规模集群的混部的monitor服务独立到单独的服务器上,提升monitor单点性能,减少心跳上报、多副本之间peering过程中的排队现象,缩短异常场景或者运维操作过程中IO中断时间
  • 代码优化:peering流程优化,减少不必要的流程,极大降低了流程耗时
  • 日志和命令行工具优化:新增日志和命令行查询工具,精确定位抖动原因和所在磁盘,便于快速恢复和事后分析
  • 工具迭代优化:自动化运维工具迭代式优化,根据日志发现抖动问题是运维工具不完善造成的之后,持续微调工具操作流程细节(有人可能会问为啥不线下测试好再上线,如果线下小规模环境能复现,问题也就不那么难解决了),直到趋于完美
  • 引擎性能优化:我们基于filestore也做了很多的性能改进尝试,配置调优都已经上线,也取得了一些效果,但代码修改和缓存盘方案受限于文件系统性能限制,以及线上集群升级困难(数据已经在那里了,动不了),最终并没有落地
  • 监控告警完善:这个比较容易理解,我们基于日志和命令行工具,配合专用打桩机,对每个存储池、每台服务器、每块盘,都在哨兵上做了很多新的监控项,这些监控项配合哨兵告警能帮助我们第一时间发现抖动问题,及时进行处理,从此以后,再也没有出现抖动超过几分钟还没找到问题原因的情况,基本做到了抖动发生的几秒钟内就能发现原因
有了上述优化并上线之后,我们会通过日志和监控告警分析每次抖动的根本原因(我们有专门的wiki页面记录了数十次各类场景下抖动问题发生的时间点、影响时间、影响范围,这里就不展示了),这是做IO抖动优化专项攻坚之前从来没有深入细致做的事情,之前只知道做了什么操作或者发生了什么硬件故障导致的抖动,但是没有从底层ceph代码流程层面分析过造成抖动的根本原因并加以优化,如果经过分析发现是ceph架构造成的抖动无法优化(比如慢盘、raid卡故障、网络丢包等),我们也会补齐对应场景下的监控告警,可以做到第一时间发现抖动的根源,并及时上线进行处理。
优化前:
优化后:

挑战2:超百万行ceph代码的掌控问题

ceph最新的代码量已经达到180w行,即使是之前的版本,肯定也有几十上百万行,团队一共最多的时候就5个人,每个人20w行代码,做到深入全面的掌控肯定是不现实的。这一点不得不提华为,我当年在的时候,libvirt/qemu这种规模的项目,仍然是每个人负责一块,把所有代码都吃透(要有代码分析文档、要有内部代码走读分享),并且有KPI考核,他们最大的优势是人多,每个开源项目甚至十几个人在做,甚至一个驱动模块就有几个人负责,每个人就是一颗螺丝钉,会有半年时间全部给你分析代码流程,完全掌控之后再做版本开发。我们显然做不到这种程度,但是又不能不掌控,只能挑重点。另外还有一个方面的问题比较难解决,单纯的代码分析是没有绩效的,或者至少不会有高绩效,大家动力不足,更多的是凭个人的兴趣和主动性在做。
解决方案:
  • 从遇到的问题入手,把问题涉及到的代码流程吃透,并尽可能扩散覆盖到更多的流程
  • 从核心流程入手,把核心IO流程的代码吃透,遇到相关问题时可以快速深入问题细节,找到解决方案或者规避手段
  • 从版本社区已知bug入手,定期去社区bug tracker平台分析我们使用的版本新报告的bug,并深入分析bug产生的场景和相关代码流程,合入补丁时做到心中有数、举一反三
  • 代码责任田,每个人负责一块,比如monitor、mds、mgr、osd等
  • 团队内知识分享,每次解决的问题或bug都有详细的分析报告,并组织团队内部讨论分享,并通过学习分享这块考核进行牵引
在这方面,我们团队吴宏松做的很不错,他是我们团队最能静下心来研读代码的同学,也总结了非常多的流程分析文档,还有自己的知乎专栏,给Curve也做了不少引流。大部分时候你问他某某功能或特性的具体实现逻辑是什么样的?他都会回答,等我翻一下我的云笔记,我问他你怎么有这么多的总结文档,他说因为热爱,一有空就看代码。其实我知道,他是想成为业界大佬,好赚大钱(因为我也一样,你看我把curve代码流程大部分都理了一遍,虽然一知半解,但是也算能帮助外面的人入门)。

项目成果

  • 参与Ceph成本优化项目,2020年成本下降到2018年的1/6
  • 参与Ceph块存储优化项目,通过规范运维标准化及配套工具,优化集群监控报警,保障了近xx个块存储集群x百台服务器xPB业务数据,近4年未出现较大故障,基本没有SLA损失,云盘抖动情况显著改善,同时节省SA半个人力
  • 参与并主导cephfs容器场景产品化项目,填补了k8s RWX PVC存储的空白,解决了传媒,严选,云音乐等部门共享文件存储的痛点,集群数量达到xx,存储机x百台,业务数据达到xxPB+
在ceph现有集群的维护方面,团队里马杰同学真的是劳苦功高,基本上一个人扛下来了所有集群的问题处理(相信使用ceph的团队应该都跟他打过交道),知识面也非常宽,还乐于学习新技术,开发了不少运维自动化工具、监控脚本、部署流程文档,也做了不少功能增强,比如回收站功能,也受到非常多的外部同行关注。curvefs的CSI工具也是他快速“糊”出来的,他就是我上一篇怎么管理团队的文章里写的效率高但质量意识稍差的代表,但他可以快速迭代,发现问题及时改掉,人的性格有差别,只要用对地方,每个人都有自己的优势。

总结复盘

做的好的:
我们针对IO抖动问题攻坚,总结出来的核心方法论就是:对症下药!先找出来准确的问题根因,再讨论解决方案并验证效果,反复迭代优化,才有了Ceph集群近两年的平稳运行。
这一块工作我认为做的还算比较到位,即使复盘重来一次,唯一需要改进的就是应该更早的开始攻坚解决这个问题,但我18年刚来就开始做了,也没办法做的更早。
需要改进的:
如何用较少的人力掌控超大型开源项目,并落地到大规模的生产环境?这不仅仅是技术问题,还涉及到团队管理问题。这一挑战我们做的也有不太好的地方,主要是绩效牵引不到位,也没有这么多的人力、时间精力去做(半年时间不做业务只分析代码,这在我司有点不现实,但是华为就可以)。

Curve项目

背景和必要性

Curve团队我是20年中接手的,Curve块存储当时已经上线了,并且有了一定的量,这方面我做的工作主要是把容量从xxxTB扩展到xPB,并且保证服务可用性SLA超出预期,数据可靠性100%,另外一大块工作是性能优化相关,继续保持curve的性能优势。
这里重点讲一下Curve文件存储的背景和必要性。
内部需求情况:
自19年开始cephfs部署的xx个集群,几乎全部是用在AI训练场景的(广义上的AI,包括机器学习,深度学习,文本语音视频分析等),也有少量场景是web服务端共享存储和分布式并行视频编解码等。而openstack场景下的云盘需求基本没有增量,已经基本都被k8s取代,部分老业务在往k8s上迁移,新业务基本都在3.0云平台k8s上,存储需求一般是两种,对共享存储没有强需求的使用hostpath本地存储,有需求的则使用cephfs共享文件存储。
业务的第二个诉求是性能,提升存储性能对训练加速,从而提升GPU资源利用效率,也是为业务降本的一种手段。根据云音乐goblin机器学习团队反馈,现在cephfs的性能问题会导致部分训练场景下GPU利用率只有30%只有,亟待提升。
第三个诉求是降本,对象存储已经从3副本降低到1.2甚至更低副本冗余度,文件存储使用cephfs仍然以3副本为主,有很大的降本空间。常规手段是冷热数据分离存储,冷数据使用1.2副本甚至更低冗余度,热数据使用3副本,配合高性能热数据缓存层,按冷热数据8:2比例计算,可以节省50%左右的存储空间。另外集团在海外的业务拓展也在加速进行,海外没有专门的数据中心,也涉及到数据合规性问题,因此都是在云上部署,一旦要使用文件存储就涉及到比较高的费用问题,以aws的efs文件存储为例,其费用相比对象存储是非常高昂的(标准存储类型为例:$0.3/GB/月 vs $0.023/GB/月),因此如果可以在云上使用对象存储作为数据存储空间,可以为业务节省大量存储费用。
外部需求情况:
Ceph 2021用户调查报告显示,61.95%在ceph集群中使用了cephfs,cubefs则在今年进入了CNCF的孵化项目,juicefs的用户star数达到了6k+,curve用户群新增了数百个用户,其中大部分都有共享存储需求。minio是对象存储,但其在云上的发展策略也是值得curve学习借鉴的,他们在重点拓展公有云和混合云架构,这也是未来的存储发展趋势。
功能类别
功能项
juicefs
cephfs
cubefs
curvefs
备注
基础功能(主要对标)
POSIX 兼容
CSI插件
否*
curvefs csi插件开发中
元数据管理
第三方组件
数据一致性
close-to-open
强一致
close-to-open
close-to-open*
JuiceFS 确保了数据的高可靠性,在文件关闭时会将其同步上传到对象存储。curve一致性目标处在规划中
S3兼容引擎
自有S3组件
自有S3组件
juicefs为各家对象存储厂商提供了独立的驱动层(用的是各家的专有SDK,curve用的是aws s3的sdk对接所有厂商)
客户端缓存
内存、硬盘
无客户端缓存
3.0版本支持内存、硬盘缓存、3副本引擎
内存、硬盘、3副本引擎
juicefs商业版本支持单副本的读缓存
自有存储引擎
多挂载
目录配额
是*
是*
否*
juicefs、cubefs支持volume级配额,curvefs规划支持配额功能
多文件系统
是*
cephfs多文件系统支持不完善,目前以单文件系统用法为主
开发语言
Go
C++
Go
C++
认证、权限管理、多租户
否*
否*
curvefs规划支持,juicefs没有看到相关文档(操作过程中也没有看到类似参数)
扩展功能
内置stat工具
否?
文件锁
否?
否*
curvefs规划支持
HDFS兼容引擎
curvefs是否要支持待定
NFS协议
插件支持
curvefs规划支持
S3协议
curvefs规划支持,优先级低
HDFS协议
curvefs是否要支持待定
CIFS协议
插件支持
curvefs是否要支持待定
ceph rados引擎
curvefs规划支持,优先级低
fsck数据校验
否?
curvefs规划支持
对象分片合并
同一个文件反复随机写入的碎片整理
垃圾对象清理
需要调研与分片合并的区别(目前看是游离分片数据的清理功能)
内置benchmark工具
否?
多桶写入
/
/
否*
curvefs规划支持同一集群配置多个后端存储桶
元数据备份恢复
是?
否*
curvefs规划支持
高级特性
主动目录缓存
否*
juicefs为warmup命令,curvefs规划支持
数据加密(传输、静态)
是?
curvefs是否要支持待定
数据压缩
否?
curvefs是否要支持待定
跨集群数据同步
是指将阿里云oss(或其他对象存储厂商)某个桶中的数据同步到aws s3(或其他对象存储厂商)的某个桶,与文件系统本身的关系不大,类似rclone等第三方数据同步工具
快照
否?
否*
curvefs规划支持快照功能
回收站
否?
否*
curvefs规划支持回收站功能,https://juicefs.com/docs/zh/community/security/trash
内核态客户端
否*
curvefs是否要支持待定,https://juicefs.com/docs/zh/community/metadata_dump_load , juicefs支持自动定期备份
冷热数据分层
否*
curvefs规划支持,ceph cache tire更适合对象存储场景,cubefs 3.0版本支持了3副本和ec的分层存储
数据生命周期管理
否*
curvefs规划支持

项目挑战

挑战1:技术架构和应用场景

文件存储方向上怎么做出curve的特色?怎么从业界众多项目中脱颖而出?
存储系统尤其是文件存储已经有几十年的历史了,最早的NFS、到专用NAS设备,再到分布式存储系统(GlusterFS、LustreFS、CephFS、FastCFS、CubeFS、JuiceFS等等),每个都支持POSIX接口,这些文件系统有什么差异?在哪方面做了演进?文件存储后续5年甚至10年的技术架构和重点应用场景是什么?这些都是Curve需要回答的问题,否则怎么做到技术架构的前瞻性和创新性,怎么让未来最广泛的业务应用场景选择curve?
我们的答案:
我一直在跟团队小伙伴们强调一点,我们做CurveFS,一定不能做成第二个xxxFS,如果做成xxxFS,谁会来用,社区用户会对curve感兴趣吗,用户为什么要选一个完全没有特色的新项目而不是一个完全一样的成熟稳定的老项目?重复造轮子,就算大家以后出去面试,也没有什么值得吹嘘的东西可以给面试官讲。我想让大家做一些用户真正需要的东西,或者同类项目里面有优势的东西,让大家觉得这几年没白忙活,脸上有光,即使出去也能多赚钱。
Curve文件存储研发目标:
  • 高性能
  • 高性价比
  • 支持公有云部署
  • 支持混合云部署
  • 支持冷热数据分层存储及数据生命周期管理
  • 支持多级缓存
  • 完整的POSIX兼容性
这些目标也是我们经过反复讨论,调研,与社区用户交流,分析内部业务需求总结出来的,业界已有的存储系统,目前都没有做到具备上述全部的能力。
有了这些目标,还要匹配到业务场景,才能更好的落地,外面用户的情况我们可以了解也可以进行宣传推广,但没有内部业务的打磨,怎么保证你的项目是好用的、高质量的、能解决用户痛点的?一个好的产品必然要自己对上层业务有深入接触深入理解才能真正抓住业务痛点。内部业务场景在前面项目背景部分已经有了描述,CephFS已经有了比较多的使用,具体场景来看,主要就是AI训练,其他场景大部分都还是本地盘hostpath模式,既然网易互联网业务都是如此,应该可以推而广之,外面的互联网业务也不会有特别大的差异(非互联网业务我们接触的很少,不敢妄下结论),因此我们打算首先主推AI训练场景,有一定用户基础之后再推广到其他业务场景。
目前内部已经有AI业务上线使用curvefs,最吸引他们的就是成本,3台服务器共3块ssd盘(可以混部到其他业务机器上)就可以跑起来,后端用nos低频存储(1.2副本,比cephfs的3副本成本低很多很多,cephfs用的是8T盘,nos是18T,密度也高很多)。另外多媒体AI团队也在于我们共建,已经测试出来一些性能数据,更多的场景还在测试中。
团队里李小翠,在架构设计调研方面做得最到位,报告写得最详细,能把各个场景都考虑的非常细致全面,写代码一定是谋定而后动。

挑战2:如何保证Curve具备高性能优势

Curve块存储最大的优势之一就是高性能,与主流开源项目Ceph RBD相比,小文件随机IO性能远超RBD(时延也是有很大优势),大文件顺序IO场景与其持平。但是只做到这些肯定是不够的,在云原生数据库场景下,数据库对底层存储的性能尤其是时延要求是极高的(时延越低越好,就看我们能做到什么程度),如何保证Curve的高性能优势持续领先?这也是我们面临的一大挑战。
我们的行动:
Curve块存储:
  • 全链路瓶颈梳理
  • 大文件顺序读写性能优化
  • raft相关优化
  • 高性能硬件适配
Curve文件存储:
  • 元数据性能优化
  • 数据面性能优化
  • FUSE优化
  • 多级缓存
高性能硬件适配这方面的工作,还是得靠大佬出手,我们团队高级专家徐逸锋,绝对的实力派资深码神,与阿里多隆不相伯仲,相关适配已经在开发扫尾阶段,近期将会有测试结论。文件存储的元数据和数据面性能优化方面,团队里新秀王海和吴宏松也有不错表现。
上面每一项展开来写,都是一篇技术文章,感兴趣的可以看一下curve公众号文章,或者更早之前的文章在网易杭州研究院的公众号里。
CurveBS对大文件顺序IO的优化:
CurveFS元数据性能对比: