利⽤ mutex 和 condition_variable 实现读写锁

用vscode+copilot生成的代码:

这个读写锁允许多个读者同时访问,但是在写者访问时,其他所有读者和写者都会被阻塞。当写者释放锁后,所有等待的读者和写者都会被通知。

注意,这个实现并没有处理读者和写者的优先级,所以可能会导致写者饥饿。如果你需要处理这种情况,你可能需要使用更复杂的策略,例如引入一个等待队列来公平地处理读者和写者。

 

 

 

集团业务需要的是什么样的存储系统?

一、调研基本信息

调研目的:

了解集团内各类业务对存储系统的现状和需求,为公技存储团队提供优化和改进的方向和建议。

调研主题:集团业务需要的是什么样的存储系统?

调研方法/形式:

通过日常popo交流、面对面需求沟通、数据分析等方式,收集和整理各业务线的存储系统类型、规模、性能、成本、问题、期望等信息。

调研用户情况:

调研对象包括集团内各大业务线的研发、运维人员等,基本涵盖了互联网业务线、游戏基础设施、数帆商业化团队等多个领域。

前言

近两年公技存储团队对接的集团各类业务线越来越多,沟通的频次和深度也逐步加强,也让我们有机会能了解到各类业务的存储系统现状和需求,目前各大业务线的存储系统现状可以说是五花八门、类型繁多,因此不得不考虑一个问题,集团内各业务到底需要的是什么样的存储系统?

本文主要探讨以下几个方面的问题:

  • 集团内各类业务对存储的需求到底是什么样的?
  • 能不能用一套存储搞定所有业务场景?
  • 各个业务线自己维护甚至自己开发存储系统是否真的有必要?
  • 公技存储团队存在的价值是什么?

为了不暴露业务细节,文中所有业务均用业务A、B、C等替代。

二、用户洞察与业务思考

基于用户调研的核心发现:

集团内各类业务对存储的需求到底是什么样的?

业界选型存储系统的关注点通常包括性能、成本、稳定性、易用性、可靠性、可扩展性等几个方面。集团内部一般都是托管运维或者半托管运维,所以易用性的关注不太强烈。

业务对存储系统的性能、成本、稳定性/可靠性 3个指标如何排序?

经过我的调研了解,不同的业务诉求是不一样的,块存储场景下,只有极个别的业务如业务H,因为涉及到用户体验才对性能有较高需求,但对数据可靠性和成本关注稍低;而数据库业务B则不但要有极高的iops性能,还需要极低的时延、极高的数据可靠性。普通的云主机云盘块存储场景下,则以成本和稳定性诉求为主(价格便宜稳定不抖动)。

对象存储场景下,几乎所有业务都是以成本优先,稳定性次之,对性能几乎没有太多诉求,因为大部分业务前端都是CDN加速服务,而没有CDN加速的业务则通常都是内网访问为主。

对于共享文件存储,业务使用场景通常是AI训练和少量其他存储,通常是稳定性和成本优先,在这两个前提下性能尽量好即可。

对于使用本地盘存储的业务,如本地盘、ES/CK等,主要考虑的也是稳定性和成本,对性能的需求只要能达到或接近本地盘的性能即可。尤其是当前使用本地盘的业务,他们最担心的是替换成分布式存储之后,一旦故障会导致业务集群不可用,影响范围太广不能接受,另外分布式存储也可能会带来多副本的成本增加问题。

目前为止,尚未了解到集团内有业务使用硬件存储阵列的,可见互联网公司通常仍然会选择软件定义存储或者分布式存储方案。

业务对当前使用的存储系统满意吗?

  • 业务H:性能不满意,受限于软硬件限制,吞吐总是有瓶颈,影响用户体验。满意度:中
  • 业务B:数据库对iops的需求是越高越好,因此希望继续提升;另外数据库有主从高可用、高可靠,底层存储的副本数应该尽量低,以便降低成本。满意度:中
  • 业务D:AI业务,训练时长要尽量短,存储数据的成本要尽量低,因此要提升性能降低成本,并且要保证存储服务稳定性。满意度:中高
  • 业务F:同样是AI业务,除了对训练时长(也就是存储性能)有需求之外,最大的痛点是现有开源存储服务不稳定,经常出故障,用户抱怨很大。满意度:低
  • 业务E:冷数据存储要方便易用,成本足够低,性能需求不高,因为是周期性转存冷数据,所以对服务的稳定性要求也不太高(偶尔停服问题不大),但不能导致数据丢失或错误。满意度:中高
  • 业务C:对象存储只要求存储成本越低越好,不要丢数据,期望用成本更低的对象存储替换HDFS存储。满意度:高
  • 业务Y:合规要求高,不能使用公共存储服务,要独立部署集群,对性能和稳定性有一定的要求,数据可靠性要求高。满意度:高
  • 业务S:商业化项目对底层存储服务有依赖,要简单易运维,并且相比业界存储系统有对标优势(控标项需求强烈),当前是使用开源存储项目,优势不足。满意度:中低

从上面的业务情况可以看出,影响业务满意度的几个方面按严重程度通常是:

  1. 稳定性:这是对存储系统的最基础要求,不稳定的系统几乎大部分业务都不能接受
  2. 成本:这是进阶诉求,成本要尽量低,越低越好,降本诉求在还有增量的存储系统上尤其明显
  3. 性能:这是高阶诉求,成本和稳定性保证之后,性能要尽量能提升上去,但通常受限于成本,很难达到二者兼得

业务如果对现有存储系统不满意,会怎么做?

通常是选择调研新的存储项目(开源项目为主),并在内部尝试部署落地,如有短板则有部分业务会动手定制开发进行增强。

选择自研存储系统的业务几乎没有,因为投入产出比太低,不合算,本身存储的数据量就不太大,而开发一套稳定可靠、成本低、性能优的存储系统的人力投入和时间成本都极高。

为什么不愿意用内部开发的存储项目?而是去调研开源的存储?

这方面的问题有很多:

  • 首先,内部开发的存储项目也不一定符合业务需求,从上面的调研来看,业务的需求也是各有不同的,一套系统很难满足全部业务。
  • 其次,也有少量业务考虑到自身团队的人员工作产出,占地盘的思想还是存在的,部门墙很难打破。
  • 最后,历史包袱问题,部分业务的存储系统很难切换,甚至业务的开发人员都已经更换了好几批,当前维护人已经对这些系统完全不熟悉了,这类情况是连调研新的存储项目一般都不会做。

基于用户调研的业务思考:

大一统的存储系统能不能解决所有业务场景的存储需求?

大一统的存储系统,开源的有Ceph,包括了块存储、文件存储、对象存储 3大存储形态,从功能层面基本上覆盖了所有业务的存储场景。Ceph的应用场景和用户群体规模都是首屈一指的,但Ceph能解决所有存储需求吗?显然不能,否则就没有其他分布式存储项目的立足之地了。

看业界情况的话,一般的互联网大厂都是有自研的存储系统的,通常也都是大一统的。以阿里为例,盘古是国内最知名的存储系统了,阿里基于它构建了ebs、nas、oss等存储形态,但是盘古+上层这几个存储形态解决了他们所有的业务需求吗?据我了解也没有,比如边缘计算场景,就不适合用盘古搞定,他们也是用ceph来搞定的。另外还有类似polardb开源生态,也没办法用盘古搞定,因为盘古太重了,一般的中小型业务规模都没办法部署。

我们公技存储团队目前还没有自研大一统的存储系统,我们有Curve块存储和文件存储,以及NOS对象存储,当然目前还维护一批存量的Ceph rbd/fs 集群。既然大一统的存储系统并不能解决所有业务的存储需求,那也就没有必要费时费力去做一个出来。即使要做一个自研存储,能解决内部大部分业务诉求即可。

各个业务线自己维护甚至自己开发存储系统是否真的有必要?

首先,我是不赞同业务线自己开发存储系统的,这不是业务线的主业,除非主业已经发展到足够大的量级,对存储的依赖已经到了阻碍主业发展的程度,才适合考虑自研。

其次,对于各业务线自行维护开源存储系统是否合适,我认为要分为几种情况详细讨论:

  1. 对于内部业务,存储系统对主业的重要性一般,比如只是存储一些周边数据,即使故障也不影响核心业务,并且存储系统的运维工作量不大兼职即可,数据量不大,能用就行。对于这种情况自己维护问题不大,毕竟投入少,对核心系统影响小。
  2. 对于内部业务,存储了重要业务数据,一旦故障会造成业务停顿,并且数据量比较大(PB级),这种业务就不建议自己维护了,还是交给专业的团队来做更合适,毕竟术业有专攻
  3. 对于有商业化交付需求的业务,底层存储是否要作为交付组件,甚至是否要作为控标项来体现到标书里,也需要综合考量,如果存储的数据量较小且存储系统的优势对主干业务影响不大(说白了就是够用就行,不影响用户体验),那完全没必要自己维护甚至开发存储系统,因为投入产出比太低(存储容量低收不到钱,底层存储对用户感知度低价值体验不到)。如果是严重依赖底层存储的业务(目前还没有发现集团内有类似业务),并且存储容量大,用户体验敏感,倒是可以考虑投入人力维护开发。

简单总结下:非核心业务依赖且数据量太少没必要折腾,开源项目部署凑合用或者所在业务线有基础设施部门提供服务直接用。重要且是核心依赖的业务可以自研或与专业的存储团队共建。商业化看能不能帮团队赚到更多利润,能就做不能就拉倒。

公技存储团队存在的价值是什么?

  1. 提供存储基础设施服务,减少各业务线的存储维护成本,提升服务稳定性和可靠性
  2. 统一资源池,通过软硬件优化提升存储密度降低单位存储成本
  3. 提供能满足大多数业务存储需求,且相比外部服务商更有性价比的存储服务

根据上面调研,存储服务的需求多样性和业务定制化需求较多,数据规模、存储形态、接口格式、性能要求、可靠性要求、成本诉求等等,不同业务之间有差异,一个存储项目很难同时满足,公技存储团队同时维护多种存储产品的代价太高,受限人力就无法做到专精深,因此应该寻求开发维护相对普适的存储系统,对多数业务有价值即可,以做到投入产出比最优。对于有特殊需求的业务,可以根据业务规模和需求特点选择开源或定制甚至商业存储产品来满足。

NOS对象存储服务是这方面的代表,我们的目标是做到成本最优,稳定可靠,而不是追求极致性能,相比公有云或其他对象存储商业软件产品,NOS具备极高的性价比优势,因此能在集团内各大业务线广泛使用,也实实在在并且持续的为业务降本,业务满意度近几年持续超过4分。

另外我们当前主推的CurveFS,也是基于上述考量而投入研发的,重点解决的是业务冷数据的低成本存储问题,通过多级的缓存架构支持冷热分离、AI训练加速,当前也在探索小规模、中低负载数据量场景下HDFS替换,由于数据存储在成本较低且非常通用的对象存储上,因此公有云上使用也非常适合。

基于ChatGPT的code review机器人试用体验 – 20230303

经组内同学孙中夏 推荐,今天在Curve代码库试用了一个基于ChatGPT的代码review机器人,github地址:https://github.com/anc95/ChatGPT-CodeReview

具体的执行流程和算法原理我没研究,应该也研究不明白,这里就讲讲怎么在GitHub仓库上配置这个bot,以及实际的review效果如何。

部署配置

参考https://github.com/anc95/ChatGPT-CodeReview#usage这里的描述即可:

  1. 安装这个bot的GitHub APP
  2. 安装好之后,在这个APP页面点“Configure”
  3. 选择你要应用到的账号及代码仓库,注意你要有代码库的管理员权限
  4. 之后进入到代码库的主页,进入“Settings”标签
  5. 进入“Secrets and variables” — “Actions”
  6. 注意切换到“variables” tab项,再点“New repository variable”
  7. 填入name和value,name是“OPENAI_API_KEY”,value就是openai的key了

ps. 我用的是GitHub app方案,不是GitHub action,试了action方案没跑起来,有懂行的可以给点指导。

试用效果

尝试创建一个pull request,比如:

PR创建完成后,稍等片刻,就可以看到cr-bot开始review代码了。

单就review效率来说,比人工评审代码要快太多倍了,我上面两个提交都是直接从一个分支合并到另外一个,代码改动量很大,但是cr-bot还是几分钟就搞定了,人工的话估计得好几天还不一定review的很细致。

review效果感受

大家可以自行去查看上面两个测试PR的review效果,我这里截图几个我觉得有代表意义的代码review结果。

上面这个pr,是我去年提交的(golang我只看过基本语法,第一次写实际代码,所以请忽略我粗鄙的编码),这次重新提交一下看看ChatGPT code review bot的效果,可以看出,他指出了我代码里很多问题,其中第3条,是有一个外部curve用户实际遇到过的偶发问题(执行命令卡很久才返回),我自己怎么测都跑不出来,用户那边几乎必现,后来还是组内golang高手小伙伴重构了这段代码才解决。其他几点问题也都是非常有参考价值的。

这个评审意见不需要解释,还是比较有效的。

  • 配置项也能review:

增加简单功能的commit可以理解代码意图,这一点还是很不错的。

总体来说,还是有不少帮助作用的,至少可以让人工评审节省不少时间,比如bot可以辅助解释新提交代码的作用,指出常见错误,给出改进建议等。

如果配合ChatGPT的交流窗口,把有问题的代码片段再次单独交给他评审,可能会有更多的收获:

更多细节可以翻阅上面给到的两个测试PR的review记录。

不足之处

  1. 多次提交同样的代码,每次给出的review结果是不相同的,可能某次的评审建议是相对更合理且全面的,其他的几次不一定,或许需要多给他review几次,然后再综合几次的评审意见进行代码评估
  2. 无法完整的理解某个大的功能特性的设计方案和实现思路,打个形象的比方,就是组内A同学从来没有参加过功能点X的方案设计和评审工作(主要由B同学负责),然后让A同学直接去review B同学提交的代码,就有类似的效果,只能理解函数或代码片段,没有全局意识
  3. 个别review建议可能不一定正确,需要再进行人工判断,这一点也类似人工review,代码评审人提的建议也不一定是正确的
  4. 太长的新增的源文件,好像会无法评审
  5. 如果没有别的建议,bot会给出一堆通用建议,比如增加UT用例、lint检查、注释、log等等,这一点其实也不能说是不足吧

降本效果显著,助推对象存储成为温冷数据首选 – 20230726

一、引言

1.1 对象存储介绍

1.1.1 什么是对象存储?

对象存储(Object Storage)是一种用于存储和访问非结构化数据(如文档、图片、视频等)的存储技术,具有以下主要特点:
  1. 对象存储将数据以对象的形式进行存储,每个对象包含数据、元数据和一个全局唯一的标识符。
  2. 对象存储通过RESTful API来读取、写入和删除对象,提供简单的对象访问接口。
  3. 对象存储设计为大规模、高扩展性和高可用性,可横向扩展到数十亿个对象。
  4. 对象存储数据具有冗余性和高持久性,确保数据不易丢失。
  5. 对象存储使用基于软件的缩放,方便根据需求弹性调整存储空间。
此外,对象存储服务提供商通常还会基于存储的数据类型提供更多的增值服务,以集团内部的NOS对象存储为例,它对存储的图片提供了裁剪、缩略、格式转换、水印等服务,对存储的视频提供了转码、格式转换、水印等服务,使得对象存储更加方便易用。

1.1.2 对象存储的发展历程

  • 20世纪90年代:理念产生。
  • 21世纪初:Amazon S3推出,业界开始认识对象存储优势。
  • 2007年:OpenStack Swift面世,开源对象存储方案问世。
  • 2011年:阿里云OSS对象存储服务上线。
  • 2012年:网易杭研对象存储服务NOS正式上线,NOS的发展里程可以参考这篇文章:网易对象存储NOS十周年纪念文章
  • 当前:对象存储已成为云存储主流,大量互联网、移动应用使用对象存储。
未来对象存储会向更大规模、更低成本方向发展,并支持更多的API,会应用在更多场景中。

1.1.3 对象存储市场规模和前景

全球对象存储市场:
  • 2020年规模约为150亿美元
  • 2025年预计达到290亿美元,复合年增长率达14%
中国对象存储市场:
  • 2020年规模超过10亿美元
  • 2025年预计达到22亿美元,复合年增长率超过17%
对象存储占整个存储市场的比重也在稳步提升,由于其成本优势和云计算的驱动,未来几年对象存储市场仍将保持较快增长。
主要对象存储服务供应商包括:
  • 国际:Amazon S3、Oracle Cloud、Microsoft Azure、Google Cloud
  • 国内:阿里云OSS、腾讯云COS、华为云OBS、百度云BOS
随着数据量爆炸式增长,对象存储已经成为云计算时代主流的非结构化数据存储方式之一。其市场前景广阔,预计未来将继续维持高速增长态势。

1.2 什么是温冷数据?

热冷数据通常符合2:8比例分布,其中80%的数据都是温冷数据,我对他们的定义分别是:
  • 温数据:访问时延在100ms以上到秒级,可以在线同步访问的数据
  • 冷数据:数据已经归档(比如多份数据合并压缩),存储在需要一定时间(通常分钟或小时级)才能解冻取回的存储系统(包括磁带库、分布式冷存储等离线存储系统),不可在线访问的数据
  • 热数据:本地磁盘上的数据访问时延通常在us级,集中式或分布式存储上的数据访问时延通常在ms级左右,可以低时延、大带宽实时访问的数据
为什么会有温冷数据?数据的访问频率是随着存储时间拉长而逐渐降低的,也就是数据通常具有时间尺度上的热点效应,因此大量需要(相对)长期保留的数据都会逐渐变成温冷数据,数据从热转温通常需要1周到1个月,从温转冷需要1个月到半年。
  • 在网络流量行为分析系统中,通常将最近一个月的数据作为热数据,其他的作为温数据或冷数据
  • 在电商交易订单系统中,通常将最近三个月的订单作为热数据,其他的作为温数据或冷数据
  • 在大数据存储服务中,通常将最近一周或一个月的数据作为热数据,其他的作为温数据或冷数据

二、对象存储在温冷数据场景应用突破

2.1 业界应用情况

目前比较流行的数据类开源项目基本都已支持将数据存储到兼容S3的对象存储上,主要有:
  • 数据库类:
    • MySQL – 通过一些插件可以将冷数据存到S3,如 MyDumper、Spider、LiunxServer
    • ClickHouse – 支持使用S3作为冷数据存储
    • Elasticsearch – 支持使用S3作为snapshot备份存储
    • Cassandra – 支持将S3用作外部存储
    • MongoDB Atlas – 提供与S3的集成方案
  • 数据处理类:
    • Spark – 支持读取和写入S3数据
    • Hive – 可以将对象存储服务作为外部表(External Table)来使用,实现对对象存储服务中数据的查询
    • HBase – 以将对象存储服务作为后端存储(Backend Storage)来使用,实现对HBase表中数据的持久化
    • Kafka – 支持将topic日志备份到S3
    • Flink – 可以将checkpoint数据保存到S3
    • Pulsar – 可以与S3集成作为tiered storage
    • Hadoop – 支持在HDFS之外使用S3作为数据存储
    • Presto – 支持使用S3作为存储层
  • 监控类:
    • Prometheus – 支持使用S3作为长期存储介质
    • Grafana – 支持使用S3作为备份存储
    • ELK – Filebeat/Logstash支持发送日志到S3
  • CI/CD类:
    • Jenkins – 支持将作业日志、构建artifacts等存入S3
    • Drone – 支持以S3作为离线缓存
  • 机器学习框架:
    • PyTorch – 支持从S3加载数据
    • TensorFlow – 可以直接读取S3上的数据集
    • SageMaker – 支持把模型保存到S3
  • 代码托管平台:
    • GitLab – 可以使用S3兼容的对象存储做备份
    • Gitea – 支持把仓库备份到S3
  • 容器编排工具:
    • Kubernetes – 支持使用S3作为数据卷
    • Docker – 可以把镜像上传到S3仓库
    • Docker Registry – 支持使用S3作为镜像存储后端
  • 文件存储类:
    • CurveFS:网易自研开源的共享文件存储服务(兼容POSIX协议、SMB/CIFS、NFS、S3协议,HDFS协议正在开发即将发布),支持将数据存储到S3兼容的对象存储服务,支持存储到自研的CurveBS块存储服务,规划支持单副本kv存储
    • JuiceFS:与CurveFS类似,提供开源和商业版,但开源版本有较多的功能缺失,并且在元数据的性能、可靠性、可用性方面也不如CurveFS
    • Alluxio:是一个缓存加速框架,不兼容POSIX,元数据性能差,数据可靠性低
    • JindoFS(OSS-HDFS):阿里云基于OSS提供的HDFS协议适配插件
    • EMRFS:AWS基于S3提供的HDFS协议适配插件

2.2 集团内应用情况

我了解到的部分应用场景(应该不全面):
  • AI训练:
    • 将经过特殊的格式转换后的训练数据集存储到NOS,通过range读的方式读取其中的部分数据;训练完得到的模型数据也可以存到NOS
    • 通过CurveFS将数据集、模型数据直接存储到NOS,不需要格式转换,并且可以通过多级缓存进行访问加速
  • ES冷数据:
    • 使用ES专用的S3冷数据转存插件讲数据保存到NOS或其他对象存储服务
    • 使用CurveFS挂载本地目录,配合ES的冷数据转存规则自动转存到NOS
  • gitlab冷数据:杭研gitlab历史代码仓库,通过CurveFS挂载本地目录方式直接存储到NOS,节约存储成本,并且支持在线访问
  • 互娱游戏出海场景下的公有云上Hadoop业务(内部知识分享平台文章链接已隐去)
  • harbor镜像仓库:https://harbor.cloud.netease.com 的后端存储也是NOS
  • 伏羲游戏出海场景下的存算分离架构(内部知识分享平台文章链接已隐去)
CurveFS+NOS正在探索的业务方向:
  • IDC内部基于CurveFS+hdfs sdk+NOS替代hdfs
如有类似业务,欢迎与我们联系交流。

三、推动因素分析

3.1 对象存储价格优势显著

阿里云各类型存储的官网列表价对比:
存储类型
按量付费单价
普通云盘
0.3 元/GiB/月
容量型文件存储NAS
0.35 元/GiB/月
标准型本地冗余OSS对象存储
0.12 元/GiB/月
从内部的NOS对象存储来看,随着存储密度提升以及磁盘价格下降(当前NOS对象存储采用的存储型服务器至少配置36块20TB硬盘,60盘的机型也在逐步落地使用),对象存储成本持续下降,NOS的低频存储价格已经低至 0.03XX 元/GiB/月。而我们维护的文件存储服务,则通常选择10块8TB硬盘的机型来部署,单从存储密度上就已经有了数倍差距。

3.2 存算分离架构驱动

存算分离架构(Compute and Storage Separation Architecture)是一种云计算架构设计模式,其主要思想是将计算资源和存储资源进行分离,实现各自独立弹性扩展。
该架构的主要特征包括:
  1. 计算资源和存储资源物理上分离,可以独立扩展。
  2. 计算资源可以是无状态的,数据存储在分布式存储系统中。
  3. 通过高速网络连接计算资源和存储资源。
  4. Applications直接面向存储资源开发,计算资源可以根据需求弹性调度。
  5. 存储资源提供标准数据访问接口,屏蔽实际存储实现的细节。
  6. 计算资源无状态、存储状态化,易于水平扩展。
  7. 高容错性,计算资源的故障不会影响存储数据。
存算分离架构的优点包括:
  • 计算和存储弹性扩展更加灵活
  • 资源利用率更高
  • 可根据需求调度计算资源
  • 高可用性和容错性
总体来说,存算分离架构适合需要频繁水平扩展和业务波动较大的云计算场景,可以有效提升资源利用率和系统可靠性。
大数据业务场景下的存算分离相关介绍,网上有很多相关案例可以搜索查看。(内部知识分享平台文章链接已隐去)

3.3 业务上云的必然选择

上面给出了各类云存储的成本对比,业务上云之后如果基于成本考量,很容易可以推导出对象存储是最优选择。另外如果要基于云盘部署各类存储服务(比如hdfs),通常至少要2副本才能保证服务可用性,因此价格相比对象存储要高出更多。
另外databricks在2017年就在其博客上给出了5条使用S3替代hdfs的理由,第一条就是成本低:https://www.databricks.com/blog/2017/05/31/top-5-reasons-for-choosing-s3-over-hdfs.html
当然各大公有云厂商,也都顺应时代潮流,推出了各类大数据的对象存储插件,比如阿里云的JindoFS(OSS-HDFS)、AWS的EMRFS,都是为了让大数据业务能把数据直接存储到对象存储。
除了公有云厂商推出的专属插件,也有许多开源软件基于对象存储提供各类文件存储服务,比如前面提到的几个CurveFS、JuiceFS、Alluxio等。
这些开源软件的推出,其中立和开放性更容易获得用户的认可和信赖,也让基于对象存储的各类文件存储生态更加繁荣活跃,性能优异、功能全面并且避免厂商锁定是他们的最大优势。

3.4 其他因素

  • 简单易用、接口统一:对象存储提供的Restful API和丰富的SDK,以及协议的高度标准化(通常都兼容S3协议),使得各类上层业务接入对象存储非常容易,适配门槛极低
  • 生态工具完善:各种数据相关的知名开源软件(上面列出了部分)都已经提供了完善的对象存储插件,基本做到了开箱即用
  • 访问性能提升:随着技术架构的演进和硬件能力的提升,对象存储已经不再是当年的上百ms的时延,随机和吞吐性能都有了大幅提升,而且可以水平扩展,已经可以很好的支持各类数据存储业务(非极端性能敏感型)

四、未来展望

4.1 各类项目提供对象存储插件的弊端

  • 各自为战,无法互相兼容,重复造轮子
  • 不兼容标准Posix协议,做了比较多的折中处理
例如ElasticSearch、Hadoop在直接使用S3插件的情况下,就存在诸多不便之处,详情可参考网络文章。(这里的公司内部知识分享平台的文章地址隐去了)

4.2 对象存储天然的短板

  • 元数据访问效率低,时延高,例如列出所有对象就非常困难
  • 数据访问时延高,随机访问性能差,无法支持热数据读写
  • 不兼容Posix协议,需要应用开发专门的适配插件才能使用对象存储

4.3 解决方案

CurveFS产生的背景,其中一个重要的目标就是解决的对象存储的短板,相比传统的分布式文件系统,基于对象存储的CurveFS具备如下几个特色:
  1. 支持标准的Posix协议,支持共享文件存储(类似NFS的一写多读模式和多节点数据写入的一致性能力),业务可无缝从本地文件系统迁移到CurveFS
  2. 针对AI训练/机器学习场景、elasticsearch/hdfs等大数据场景做了专门优化,支持内存缓存、本地磁盘缓存、分布式内存缓存(基于memcached或其他kv存储)等多级缓存,可对文件读写进行缓存加速并保持数据写入可靠性,支持数据预热到缓存中加速读取过程,大数据场景下使用curvefs+对象存储相比本地副本存储方案具备更高的性价比优势以及易用性优势
  3. 基于multi-raft支持元数据的分区存储,具备无限扩展性,性能可随节点数线性扩展,不存在性能热点问题
  4. 支持将文件数据存储到对象存储和CurveBS块存储上(适用于shuffle盘的单副本存储引擎也在规划中),可以做到冷热数据分层存储和生命周期管理(roadmap),数据容量可无限扩展
0
更多架构细节可以参考这些文章:

五、总结

简单总结两点:
  • 对象存储性价比优势明显,在温冷数据存储场景的份额将持续扩大
  • 企业应充分利用对象存储降本增效,配合CurveFS等存储中间件提升存算分离的便利性,调优存储架构

六、参考资料

  1. NOS这10年暨上线10周年纪念:http://aspirer.wang/?p=1716
  2. 聊聊大数据下的存算分离:(内部知识分享平台文章链接已隐去)
  3. Curve开源项目代码仓库:https://github.com/opencurve/curve
  4. 使用Curve云上部署Hadoop,轻松节约50%存储成本:(内部知识分享平台文章链接已隐去)
  5. 游戏出海大数据架构升级研究与实践:(内部知识分享平台文章链接已隐去)
  6. CurveFS在Elasticsearch冷热数据存储中的应用:(内部知识分享平台文章链接已隐去)
  7. https://www.databricks.com/blog/2017/05/31/top-5-reasons-for-choosing-s3-over-hdfs.html
  8. Curve Roadmap 2023:https://github.com/opencurve/curve/issues/2207
  9. CurveFS架构设计介绍:https://github.com/opencurve/curve/blob/master/docs/cn/curvefs_architecture.md
  10. New Bing AI、Claude AI

大数据存储演进方向汇报 – 202311

1. 大数据存储技术架构演进趋势

1.1 趋势一:湖仓一体

数据仓库

数据仓库 = 结构化数据存储系统 + 内置计算引擎 + SQL 接口
相关项目开源项目:

数据湖

数据湖 = 原始数据存储系统 + 多种计算引擎 + 包含 SQL 在内的多种接口
支持的存储系统多种多样,需要进行数据ETL处理。
存储类型:存算一体和存算分离两类数据湖。存算一体主要是Hadoop生态体系,存算分离主要基于对象存储+缓存加速层,或者HDFS的替代产品OZone。

湖仓一体

湖仓一体 = 配备元数据层和加速层的对象存储 + 数据仓库、大数据、AI、HPC 等各个领域的计算引擎 + 包含SQL 在内的多种接口
相关项目:
  • 公有云大数据平台:各类EMR平台+加速层+对象存储
    • 使用对象存储做为存储底座,提供HDFS接口适配
    • 配备数据加速层,大部分配备元数据层
  • Alluxio/JuiceFS/CurveFS:开源中立对象存储加速中间件
参考资料

1.2 趋势二:冷热分离

冷热一体

低版本的各类数据平台基本都是存算一体的。
如ES、CK、SR、Spark/Hive/Flink+HDFS等等。

冷热分离

基于成本优化考虑,以及热冷数据的28分布原则,基本所有的数仓产品都提供冷热分离存储方案,热数据在HDFS、冷数据存储到S3兼容的对象存储中。
冷热分离是存算分离的前奏,大部分项目是直接使用S3接口,没有缓存加速层。
  • 数据库类:
    • MySQL – 通过一些插件可以将冷数据存到S3,如 MyDumper、Spider、LiunxServer
    • ClickHouse – 支持使用S3作为冷数据存储
    • ElasticSearch – 支持使用S3作为snapshot备份存储
    • Cassandra – 支持将S3用作外部存储
    • MongoDB Atlas – 提供与S3的集成方案
  • 数据处理类:
    • Spark – 支持读取和写入S3数据
    • Hive – 可以将对象存储服务作为外部表(External Table)来使用,实现对对象存储服务中数据的查询
    • HBase – 以将对象存储服务作为后端存储(Backend Storage)来使用,实现对HBase表中数据的持久化
    • Kafka – 支持将topic日志备份到S3
    • Flink – 可以将checkpoint数据保存到S3
    • Pulsar – 可以与S3集成作为tiered storage
    • Hadoop – 支持在HDFS之外使用S3作为数据存储
    • Presto – 支持使用S3作为存储层
    • Apache Doris 2.0 – 支持冷数据存储到对象存储

1.3 趋势三:云原生

存算一体

传统部署方案下,计算引擎不需要弹性调度,固定运行在一组存算一体的节点上。与冷热一体类似,低版本的数据平台也都是存算一体的。

存算分离

云原生化部署的大数据平台驱动了大数据存储从冷热分离到彻底的存算分离。云原生大数据平台主要基于K8S算力平台进行计算引擎的弹性调度,存算分离是基础条件,要实现计算引擎的弹性云原生部署,天然需要做到存算分离。私有化的云原生大数据平台可以使用HDFS或是S3作为底层存储。
而基于公有云部署的大数据平台则只能依赖公有云提供的大数据存储服务,传统IDC部署HDFS方案不适合云上部署,公有云上的大数据存储基本都是基于对象存储提供的。
存算分离的驱动因素主要包括:
  • 降本增效:计算、存储资源利用率,运维成本
  • 硬件发展:高速网络、高密专用存储服务器
  • 云原生化:云原生场景下的必然选择
  • 对象存储:生态繁荣、低成本、免运维、灵活弹性
相关项目:
  • 2016 – The Snowflake Elastic Data Warehouse:首次实现存算分离,本地缓存+S3
  • databricks、TiDB serverless等:本地缓存+S3
  • fluid+alluxio/juicefs+hdfs/S3:数据+缓存调度系统
  • 各类Remote Shuffle Service(RSS)项目
  • Starrocks 3.0、Doris 3.0:支持HDFS、S3
  • Ozone:兼容HDFS、S3
  • 网易:内部基于HDFS,18、19年开始探索;数帆大数据项目已经有较多项目落地(Hadoop+对象存储)
为了适配云上部署,S3对象存储是必选项,但是S3直接转成HDFS接口不够完美存在兼容性问题,性能也不能与本地数据PK,因此搭配元数据层和缓存加速层效果更佳。
趋势总结:
  1. 存储底座高内聚(基本均支持S3存储或HDFS存储),计算引擎和存储底座之间低耦合(无状态服务由K8S平台调度)。
  2. 基于对象存储服务的HDFS兼容层加速中间件发展迅猛(公有云产品为主、开源项目为辅)

2. CurveFS+对象存储方案介绍

2.1 CurveFS介绍

CurveFS支持通用Posix以及HDFS等接口,故而可以支持如下业务:
  • TensorFlow以及PyTorch等机器学习训练业务的数据集存储
  • Spark,MapReduce等大数据计算业务的数据湖存储
  • ElasticSearch,Clickouse等大数据查询分析业务的数据存储
另外,CurveFS支持把数据存储在性价比高的对象存储上,同时还支持把数据存储在性能优先的Curve块存储上,用户可以按需选择。基本框架如下:
CurveFS架构如下,其由三个部分组成:
  1. 客户端 curve-fuse,和元数据集群交互处理文件元数据增删改查请求,和数据集群交互处理文件数据的增删改查请求。
  2. 元数据集群
    • metaserver cluster:用于接收和处理元数据(inode 和 dentry)的增删改查请求。metaserver  cluster 基于 raft实现3副本存储,具有高可靠、高可用、高可扩的特点:
    • MDS: 用于管理集群拓扑结构,资源调度。
  1. 数据集群 data  cluster,用于接收和处理文件数据的增删改查。data  cluster 目前支持两存储类型:支持 S3 接口的对象存储以及 CurveBS(开发中)等存储后端。
接下来简单介绍下CurveFS的一些亮点:
  1. CurveFS支持S3和Curve块存储两种数据后端

  1. 文件系统的元数据独立存存储
解决元数据增长带来的扩展性和性能要求。文件系统的元数据存储在独立的集群中,随着文件数量的增加,元数据集群可以不断扩容,保证元数据可线性扩展。
  1. 文件系统数据和元数据都支持多级缓存

在工程实践过程中,由于S3、元数据集群都需要通过网络进行访问,每次读写都走网络对于业务性能是不可用的。在分析了业务特点后,Curve共享文件系统在保证多挂载点一致性的情况下进行了数据和元数据的性能优化,主要的思路是增加缓存。
  • 数据支持多级缓存。包括内存缓存(用于加速当前节点上的读写速度),本地缓存(用于加速当前节点上的读写速度),全局缓存集群(用于加速当前节点以及多节点数据共享时的速度)。
  • 元数据支持kernel缓存、本地缓存。缓存何时加载或者失效,是元数据缓存的难点。我们没有采用分布式锁来做这样的保证,一方面是实现很复杂,另一方面从业务的分析不需要完全强一致。Curve共享文件系统为每种类型的缓存数据制定了一些规则,在满足业务一致性的前提下,提供了比较好的性能。
  1. 文件系统支持数据预读 & 预热
  • 支持预读,即当数据访问的时候,可以把文件超过访问长度外的数据提前读到缓存中;
  • 支持预热,用户可以提前把云端的数据按需拷贝到指定的任一缓存层,这样当后续需要访问时,可以提供更好的性能。

2.2 与 JuiceFS / Alluxio 对比

Alluxio
JuiceFS
CurveFS
定位
缓存系统
存储中间件
通用文件系统
主要优势
强大的聚合层,来为不同的存储系统(比如 HDFS、NFS)提供统一接入和缓存服务
不错的性能和易用性,元数据以插件形式接入,可完全上云,商业化很成熟
通用文件系统,拥有双存储引擎(S3 + CurveBS),性能优势明显,并且拥有很强的易用性和极低的维护成本,开源版本拥有全部特性
主要场景
作为后端存储的缓存层,加速访问
ES、大数据、AI 训练等
ES、大数据、AI 训练、热数据、高性能存储场景等
元数据引擎
开源版本无元数据引擎,需要使用第三方组件,Redis(扩展性差)、TiKV(性能差)
自研的 raft+rocksdb 元数据引擎,兼具性能和扩展性
存储后端
无(只做缓存)
S3 后端、ceph rados 后端
拥有双存储引擎:
1. 高性价比存储引擎(S3)
2. 高性能存储引擎(CurveBS)
可根据实际业务进行选择
使用方式对比
完全兼容 POSIX
不支持
支持
支持
Hadoop 兼容
支持
支持
支持
S3 兼容
支持
支持
支持
Kubernetes CSI 驱动
支持
支持
支持
特性对比
元数据缓存
单节点加载全部元数据
缓存在客户端
缓存在客户端(多类缓存,性能较好)
数据缓存
多级缓存:内存、HDD、SSD
多级缓存: 内存、SSD、分布式缓存(企业版)
多级缓存:内存、SSD、分布式缓存
元数据一致性
不一定
强一致
强一致
数据一致性
取决于用户配置(性能较差)
close-to-open(依赖缓存时长)
完善的 close-to-open
易用性、运维成本对比
客户端
一键挂载
一键挂载
一键挂载
服务端
运维复杂
取决于所使用的组件(一般较复杂)
CurveAdm 一键部署,所有运维都一键完成
运维成本
有一定的学习、运维成本
需要引入新组件(如 Redis、TiKV)增加运维成本和组件学习门槛
极其简单上手,所有运维操作都傻瓜化
改造成本
开源版本存在一些性能问题和特性的缺失,往往需要用户进行一些改造优化才能较好在生产环境上运行,增加了用户的开发成本
由于JuiceFS 开源版本的限制,很多用户需要进行改造适配才能接入业务,改造工作量较大,周期长
开源版本特性完善,性能较好,用户往往只要接入即可使用
其他对比
开发语言
Java
Go
C++
开源时间
2014
2021.1
2021.6(开发 FS)
CurveFS VS JuiceFS
优势:
  • 开源包含所有特性:CurveFS对标的是JuiceFS商业版,其社区开源版本由于各种功能缺失导致用户需要进行改造优化才能较好在生产环境上运行,这无疑增加了用户的成本
  • 性能优势明显:在AI训练、通用存储等场景下元数据等标测性能比 JuiceFS 开源版(TiKV)要好出不少,另外CurveFS还有 BS 后端,可作为高性能存储后端支持热数据存储,这是 JuiceFS 不具备的
  • 运维成本和学习成本极低:CurveAdm 部署运维所有操作都是一键完成、傻瓜化操作,而 JuiceFS 需要额外引入第三方组件作为元数据存储引擎,第三方组件也有一定的学习门槛和维护成本
CurveFS VS Alluxio
优势:
  • 完善的 POSIX 接口,可对接更多场景
  • 拥有更强的数据和元数据一致性
  • 易用性方面,特别是服务端运维,CurveFS 拥有更好的易用性
  • 开源版本存在一些性能问题和特性的缺失,往往需要用户进行一些改造优化才能较好在生产环境上运行,增加了用户的开发成本

2.3 与公有云产品对比

JindoFS(适配阿里oss)/ RapidFS(适配百度bos)/ GooseFS(适配腾讯cos)/ EMRFS(适配aws s3)等公有云产品一般提供2种模式:block、cache,而CurveFS/JuiceFS只支持block模式。
cache模式只缓存对象存储的对象,不提供单独元数据服务,提供的是HDFS或对象存储接口,通常为只读缓存不支持数据写入,无法对元数据加速。优点是可以做到HDFS和S3接口的统一命名空间(同一个对象可以被两种接口协议访问)。
block模式,将数据切片存储到对象存储上,并提供元数据管理服务(相比S3的元数据性能有巨大提升),兼容HDFS接口并且接口性能优异,可以做到Hadoop体系计算引擎的无缝切换。不足在于无法做到HDFS和S3接口统一访问(业务文件数据会切片存储到对象存储里,对象存储中保存的不是完整的业务文件)。
JindoFS的block模式只提供云服务,JindoFSx(cache模式)可以私有部署,也兼容第三方云存储,但性能不如block模式。JindoFS可下载二进制和SDK,但源码不开源。
RapidFS不开源,且不提供下载,只随BMR产品提供。
GooseFS可下载SDK,不提供二进制下载,源码不开源。
AWS的EMRFS则是基于DynamoDB来增强S3的一致性视图,从而避免将S3接口直接转换为HDFS接口带来的不一致性问题。
公有云通常还提供EMR平台来方便用户,做到大数据平台的开箱即用,EMR通过上述fs加速组件来实现高性价比。
最大的区别有2点:
  • 中立性:CurveFS/JuiceFS是中立开源的存储中间件,通常支持所有S3兼容的对象存储(包括公有云、私有化部署等),而公有云的相关加速中间件通常都是为自家的公有云对象存储和EMR服务提供支持,不开源且一般存在定制化和厂商锁定问题。
  • 兼容性:CurveFS/JuicFS通常提供POSIX、HDFS、S3接口,并且可以扩展到NFS、SMB等协议,厂商加速中间件通常提供的是HDFS接口。
参考资料:

3. CurveFS+NOS方案落地挑战

3.1 CurveFS面临的挑战

基于CurveFS+HDFS SDK+对象存储(不限于NOS)替换HDFS集群主要有以下几个方面的挑战。
技术相关:
  • 对Hadoop体系各类计算引擎的理解程度不够深入细致,对大数据存储的需求理解比较肤浅,目前是完成了HDFS兼容性接口适配
  • 对热数据场景的支持还没有补齐(roadmap)
  • 对rename等操作的性能优化还没有完成(doing)
  • 多级缓存的架构改进(如写缓存的高可用及持久化、读缓存的命中率等)和性能优化(doing)
  • 在公有云上的部署还没有进一步优化
竞品相关:
  • JuiceFS/Alluxio占据先发优势,周边生态、落地场景和案例的丰富度,以及功能的完善度比CurveFS高出不少
  • Alluxio主打大数据场景,对用户需求的理解程度更深入
  • JuiceFS/Alluxio有商业版本,在付费用户群体中的认可度更高
  • 人力投入与其他竞品有一定差距

3.2 NOS面临的挑战

  • 性能成本均衡问题:NOS当前的软件架构和存储硬件选型都是面向成本优先规划设计的,大数据场景尤其是热数据场景下的性能需求比普通的对象存储要高很多,而公有云会综合考虑性能和成本,并且实测公有云性能比NOS优秀很多。在现有的架构和成本下,NOS性能提升空间不大。
  • 收费模式:目前NOS的收费模式仍然是参照公有云模式,与大数据的收费模式可能有比较大的差异,存在是否能真正为业务降本的风险。
  • 冷热分层:当前NOS的冷热分层主要是以NOS自身数据的上传时间为参照,大数据存储场景下的冷热分离更多的是业务层的指标为主(如数据生成时间、数据库表转冷等方面),存在上下层割裂问题,后续要考虑如何做到更好的协调适配。

晋升PPT及讲稿 – 202209

这是我之前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的总体架构和应用场景:
  1. 作为openstack的云盘
  2. 作为k8s的pvc卷
  3. 作为云原生数据库的存储底座
  4. 基于对象存储在公有云或混合云场景提供高性价比的文件存储服务
今年重点发展内部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
致谢

2023年工作总结

近期团队和部门调整转到新部门,应新部门负责人要求,需要向他做一次2023年的工作情况汇报,也就是述职,因此整理了一下去年的个人和团队的主要工作。注意事项:
1)隐去了部分隐私、敏感内容
2)有些复盘总结是给领导看的,并不代表本人/团队真实想法

个人及团队介绍

个人简介

2010年杭电硕士毕业,10~12年在华为云计算虚拟化团队从事虚拟机控制面组件开发,12~17年在网易杭研云计算团队从事OpenStack云主机服务开发,17~18年在创业公司负责OpenStack私有云产品研发,18~23年在网易杭研云存储团队从事ceph/curve/nos等存储项目的维护开发(其中Ceph是开源引入、Curve是自研开源、NOS是自研项目)。当前职级P5-1。
优势:
  • 超13年云计算领域从业经验,技术面较宽
  • 对技术产品化有一定的经验,注重用户体验,能深挖用户需求深层次的背景并牵引用户找到更合适的解决方案
  • 5年以上中小团队管理经验
不足:
  • 存储领域技术深度不够
  • 团队管理风格偏宽松

团队介绍

当前团队剩余4人(含本人,原有18人):
  • **(P4-3):熟悉Curve块和文件存储两个项目,负责Curve项目开发及线上集群维护工作,并参与维护NOS底层NEFS存储引擎
  • **(P4-2):熟悉Ceph块和文件存储项目,负责维护Ceph项目的线上维护工作,与**互为备份;并参与了Curve文件系统项目的开发
  • **(P4-1):熟悉Curve文件存储项目,负责Curve项目开发及线上集群维护工作,与**互为备份
团队目前共负责开发维护Ceph和Curve两个核心项目(近xx个集群,文件存储xxx+台节点,块存储xxx台左右,xxPB+业务数据),以及云平台相关的存储组件(如OpenStack云盘插件、k8s csi插件等)。23年活跃的项目主要是Curve存储项目和Ceph贵州IDC新版本升级项目。
优势:
  • 技术实力强,主动性高,业务满意度较好
不足:
  • 对业务需求的挖掘还不够深入,更多的是在底层存储项目内部做工作,缺少与业务的深度拉通对齐

23年工作复盘及总结

业务(不含NOS项目)

1. Curve块存储(云硬盘)

主要完成了混闪引擎功能开发、某游戏业务云盘本地快照及性能需求开发、云原生数据库高性能存储引擎落地等工作,另外还调研并POC了raft双写导致的大IO性能优化问题解决方案。
主要成果为:
  • 达成混闪功能性能指标并上线小集群,可通过混闪云盘(NVME+3.5寸8T大盘)替换掉HDD云盘(2.5寸1.8T小盘),提升单机存储密度,降低HDD云盘成本,并预估可替换本地盘raid1方案节约成本(可达50%),目前推广阻力主要是分布式存储的爆炸半径问题以及部分极端IO性能需求无法满足。目前由于人员变动,项目已取消。
  • 某游戏团队云盘服务已完成功能开发、联调,以及达成性能指标要求,可替换当前使用的ceph块存储,优化性能提升用户体验(随机读提升2倍、随机写提升40%)。目前由于人员变动,项目已取消。
  • 大IO性能优化方案调研了多种ROI预期较高备选方案,包括接入开源存储引擎(bluestore、vitastor等)、专有存储硬件(xdp、nvdimm等)、ext4替换为xfs文件系统并使用relink特性,均未能取得全面改善,需要全新研发新的存储引擎ROI较低,项目取消。

2. Curve文件存储

Curve文件存储主要完成了AI、ES、HDFS等业务场景下的存储替换需求开发,通过将数据存储到低成本的NOS对象存储上来帮助业务降低存储、运维成本。
主要成果为:
  • 性能相比竞品有显著优势:
    • 多线程mdtest测试场景下,CurveFS元数据性能远超某FS、CephFS(含kernel客户端),并且还有进一步的优化空间
    • 在IO密集型AI训练场景的各阶段代码编译、特征提取、训练阶段效率有30%以上的提升,IO耗时占比较少的提升不明显(依赖数据集预热、缓存盘性能等因素)
  • 23年Curve文件存储已落地业务包括:
    • 生产:某ai业务a、某ai业务b、某ES业务a、某ai业务c、某tob商业化项目a、gitlab冷数据、某业务HDFS存储替换、某业务替换nas存储
    • 测试:某ai业务d、某时序数据库业务冷数据
    • 外部用户:江苏农信、清华MadSys实验室(深度共建)等
目前项目仍处于推广初期,线上集群容量仍然较少(xPB+),降本效果不显著。当前项目由于人力变动,预计后续仅投入部分重点业务场景(如HDFS替换等)。

3. 贵州机房搬迁

贵州机房搬迁相关工作主要包括Curve块存储全面替换SSD系统盘和云盘,以及Ceph新版本升级工作(含云盘及文件存储)。
主要成果为:
  • Curve系统盘及SSD云盘已上线贵州私有云,并优化了杭州机房存在的部分功能及性能问题,当前已使用xxxTB容量
  • 完成Ceph新版本升级方案及功能开发,并落地贵州机房部署了HDD云盘集群,以及完成某机器学习平台底层文件存储集群xxxTB数据迁移
后续将继续协助更多业务完成贵州机房搬迁工作。

4. 开源社区运营

23年Curve开源社区组织了2场开发者活动,共吸引了47位外部contributor(含5位committer),以及江苏农信、北京外国语、同程旅行、天翼云边缘计算团队等外部用户,同时还有zstack、清华大学madsys实验室等参与深度共建开发。
由于人力变动,后续Curve开源社区将停止运营。

团队

主要工作内容

团队管理方面23年的重点工作主要包括:
  • 团队目标管理:主要包括目标的讨论制定、目标拆分及团队人力调配、过程跟进、风险管理、验收卡点等方面
  • 业务满意度维护:主要包括存储服务的可用性及稳定性、数据可靠性、业务需求承接、存储服务降本等方面
  • 业务拓展:了解业务痛点并探索解决方案、完成开发后推进业务落地应用
  • 人才梯队建设:促进开发技能、项目经验在团队内部的共享和传递,做好人力备份和后备人力储备
  • 绩效管理:优秀员工的识别、培养,不合格员工的清退等
管理思路主要是:
  • 确立团队项目正确方向并且配合团队全力达成
  • 给每个人找到合适的工作目标,团队和个人共同发展
  • 业务满意度始终放在首位,始终把业务需求、线上问题、服务稳定性等放在个人和团队工作最高优先级

思考和复盘

个人认为团队做得好的有如下几个方面:
  • 业务方满意度较好
待改进的有:
  • Curve内外部应用落地成效不大

个人

主要工作内容

23年个人共完成40+工作任务,主要包括如下几个任务类型:
  • 业务沟通及拓展
  • 目标规划及修正
  • 业界及竞品调研
  • 需求分析及poc
  • 重点架构方案评审及实现效果review
  • Curve开源社区运营维护

思考和复盘

在23年及近两三年,我在存储团队中的角色可以通俗的描述为:架构师+产品经理+项目经理+团队leader+Curve开源社区PMC,同时承担这几个角色的工作内容。也即对外负责与业务方满意度维护、需求沟通和解决方案输出;对内负责产品设计和架构选型,给团队解释需求背景、制定设计目标;对上负责团队目标的达成;对下负责团队搭建、人力调配、激励、梯队培养等。
在这几个角色当中,我个人认为自己做得好的有如下几个方面:
  • 作为项目经理,交付时间点和组织绩效目标完成度良好
  • 作为团队leader,人力调配和梯队培养方面完成较好,通过深入了解个人发展规划和能力现状,在分配任务目标时能兼顾个人能力长处和兴趣点,更好的达成目标
  • 作为架构师,项目的架构优势、服务稳定性和降本效果显著
  • 作为产品经理,业务方对存储服务的满意度较高
待改进的有如下几个方面:
  • 作为产品经理,存储项目的商业化落地效果较差
  • 作为架构师,Curve块存储的大IO性能优化改进不达预期
  • 作为开源社区PMC,外部用户的落地应用情况较差

重点工作规划

curve & braft

是根据业务类型的不同有不同的存储实现,比如curvebs,管理的是文件系统里的chunkfile文件,curvefs是rocksdb,快照的实现也完全不同,但都是在raft状态机的

on_snapshot_save方法里执行的raft snapshot流程。bs存储的是状态机元数据+chunfile文件列表,fs存储的则是状态机元数据+rocksdb的checkpoint数据。
2. 一个新加入的follower,比如换盘,怎么恢复出来全部数据的?
参考问题1
3. 配置变更的流程是?以add/remove peer为例进行说明。为啥Leader启动的时候要发送NO_OP请求?
4. 节点视图(类似osdmap)配置(论文中应该是叫configuration)是如何持久化的?
5. 为了支持follower读,Client的读取中带上CommittedId,怎么获取的?

在Raft协议中,为了支持Follower节点的读取,Client在读请求中携带CommittedId。这个CommittedId表示已经提交的日志条目的索引。

具体获取CommittedId的过程如下:

  1. Leader节点确认CommittedId:Client首先向Leader节点发送一个读请求。Leader会检查自己的已提交日志条目,并确定一个CommittedId,表示已经提交的最新日志条目的索引。
  2. Leader将CommittedId返回给Client:Leader将确定的CommittedId作为响应返回给Client。这个CommittedId可以用于后续的读请求。
  3. Client使用CommittedId进行读取:Client在后续的读请求中携带这个CommittedId。Follower节点会根据这个CommittedId来判断是否可以读取数据。只有当Follower节点的已提交日志条目的索引大于等于CommittedId时,才能返回数据给Client。

需要注意的是,如果网络分区或其他异常情况导致Follower节点的已提交日志条目滞后,读取可能会受到影响。因此,一些实际场景中可能需要考虑过期读取等机制来处理这种情况。

6. installsnapshot是否意味着全量恢复?本地如果还有chunkfile但是数据比较老,是否会从leader上拉取覆盖本地的?
installsnapshot并不能完全恢复之前的数据状态,还有一部分snapshot做完之后变更的数据要通过logentry的重放进行恢复。对bs来说,因为是支持原地改写(覆盖写),而且logentry也是保序的,所以可以认为对chunkfile的修改是幂等的,通过installsnapshot拿到所有的chunkfile列表之后,从leader节点同步chunkfile数据过来(如果本地的chunkfile的checksum和leader的不一致就拉过来,一致就不需要),重放之后的logentry,就能保证跟leader上的chunkfile最终达成一致的结果。
fs则是通过rocksdb的mvcc来保证数据的一致性。

ceph mon组件 & paxos

monitor组件的关键作用就是管理集群topo及配置(monmap、osdmap、pgmap、mgrmap、configmap、auth、log等,可以通过源文件名称看出来XXMonitor.cc/.h,这些都是PaxosService类的具体实现),包括配置在多台monitor节点上的一致性和持久化,这也是paxos共识协议要解决的问题。如果只有一台monitor,那就不需要用到paxos协议了,如果只有2台,也可以通过数据的主从复制来搞定,也不一定要用到paxos,只有节点数量不确定,并且需要多副本一致的高可用高可靠服务,才需要用到共识协议。多副本也可以起到负载均衡的作用,集群规模很大的时候,各种map的访问频次也会极大增长,少量monitor节点是服务不了这么多节点的。
paxos的原理相对简单,但是论文里推导过程和工程实现却是业界公认的难点。我们通常更喜欢raft,就是因为它更简单易于实现(更主要的是开源实现有很多,抄起来也方便)。这里不分析paxos的推导过程(可以从bing copilot ai那里问到很多相关的文章),只看paxos的原理,我简单理解如下:
  • 目的:达成分布式系统多个节点之间数据的一致性(数据可以是某个具体的值,也可以是某个操作,或者某个事务,总之就是一件事情或者叫提案),在ceph monitor里是一个事务(通过bufferlist编码,accept之后持久化到rocksdb)
  • 角色:有proposer、accepter、learner几个,在ceph中这几个角色是每个monitor服务都存在的,不同的是multi-paxos(multi是针对一组paxos角色可以反复连续决议多组数据而言,basic paxos只能决议一次,然后要重置状态才能进行下一次,效率太低)增加了leader和peon角色,leader负责发起提案,其他peon负责共同参与决议,超过半数就可以accept。ceph的monitor集群只会有一个leader,其余都是peon。启动的时候会选举leader,或者leader心跳超时之类的情况也会,租约机制来保证选举不会过于频繁。
  • 流程:src/ceph_mon.cc里main函数是入口,PaxosService负责paxos相关组件的初始化(之前还有一次选举leader过程,在src/mon/Elector.cc),之后所有的paxos操作都是在src/mon/Paxos.h/.cc里完成的,每个函数都有良好的注释,并区分了leader和peon谁会执行这些函数,执行顺序跟函数在源文件中的顺序差不多。决议完成后(所有Monitor节点)会进行数据的持久化,也就是commit到rocksdb。成员函数也有详细注释,有疑问也可以问AI。另外ceph里所有操作基本都是在dispatch函数中触发的(ceph自己实现的messenger就类似于其他rpc框架,比如grpc或者brpc等等),Monitor服务也不例外,相当于接收到其他节点的rpc请求或叫携带了操作类型的消息,就要触发相应的操作流程,跟其他rpc实现有差异,但是原理类似。
  • 异常:心跳超时通常会重新发起选举,然后再次对之前的提案进行决议(不是leader超时,并且满足quorum则不需要),还有一些租约续期之类的常规操作。uncommitted_v, uncommitted_pn,uncommitted_value这几个参数是记录当前异常挂掉之前的决议提案的,用来新leader当选后恢复上一次中断的paxos决议。
问题:
1. mon节点故障或者新增一个mon节点后的数据恢复流程是怎么样的?

在Ceph Monitor的启动过程中,probing阶段是一个关键的步骤。在这个阶段,Monitor会与集群中的其他Monitors进行通信并同步信息。具体来说,probing阶段主要做了以下几件事:

  1. 连接其他Monitors:Monitor会根据monmap(Monitor map,记录了集群中所有Monitor的信息)尝试与其他Monitors建立连接。
  2. 同步信息:Monitor会与其他Monitors交换信息,包括各自的状态、已知的最新的Paxos版本等。
  3. 决定角色:在完成信息同步后,集群会开始选举,决定每个Monitor的角色(Leader或Peon)。

这个阶段的目标是确保新启动的Monitor能够获取到集群中的最新状态,并且能够正确地加入到集群的运行中。这个阶段Monitor集群是不能提供服务的。

ceph-mon paxos实现

参考资料:
  1. 知乎专栏:理解 Paxos 协议——浅谈分布式一致性协议
  1. 知乎专栏:共识协议优质资料汇总(paxos,raft)
    • 这篇专栏整理了关于 Paxos、Multi-Paxos 和 Raft 的学习资料,包括论文、博客等。
    • 如果你想系统地学习共识协议,这里有很多有用的资源。
    • 链接在这里:共识协议优质资料汇总(paxos,raft)
  1. 知乎专栏:理解这两点,也就理解了 Paxos 协议的精髓
当涉及到 Ceph 使用 Paxos 时,它的 Monitor 组件是关键。让我为你介绍一下 Ceph 中如何使用 Paxos 以及一些学习资源:
  1. Ceph Monitor 和 Paxos:
    • 背景:Ceph 是一个分布式存储系统,它使用 Paxos 算法来实现 Monitor 的一致性。
    • Monitor:Monitors 负责维护集群状态、配置信息和映射(如 MonMap、OSDMap、PGMap 等)。
    • Paxos 作用:Paxos 用于确保所有 Monitor 之间的数据一致性,包括上述映射和其他信息。
    • 单一 Paxos 实例:Ceph 使用单一的 Paxos 实例来处理多个映射的变更。
  1. 学习资源:
    • Ceph.io 文章:Monitors and Paxos, a chat with Joao
      • 这篇对话记录了 Ceph 核心开发者 Joao Luis 和 Loïc Dachary 的交流,深入探讨了 Monitor 和 Paxos 的关系。
      • Joao 解释了 Ceph Monitor 中 Paxos 的实现细节,以及如何确保数据一致性。
      • 链接在这里:Monitors and Paxos, a chat with Joao
  1. CSDN 博客:Ceph的Paxos源码注释
    • 这篇博客详细解释了 Ceph Monitor 中 Paxos 的源码实现,适合深入研究。
    • 链接在这里:Ceph的Paxos源码注释