开源存储这么香，为何我们还要坚持自研？

引言

近年来，开源软件的蓬勃发展，给软件产业、软件技术、软件生态的发展都带来了巨大的机会。同时在使用开源软件过程中也必须要去面临存在的众多风险和固有的技术限制带来的难题。在存储领域，以Ceph为例，作为云技术栈开源技术的一个重要组成部分，同样面临着开源项目固有的技术限制。通过自研以弥补开源架构的劣势，也揭开国内厂家坚持自研的面纱。

开源软件的发展分析

开源软件的发展得益于互联网技术的发展，随着云计算、移动互联网的发展，OpenStack、k8s、Ceph等开源技术纷至沓来。这些开源项目催生了ASF、OIF、CNCF等基金会，致力于开源项目的孵化和运营。随着开源软件托管平台的普及，开源全球化协作和共创的沟通成本急剧下降，开源项目数量持续提升，据测算，2026年全球开源项目数量将超过3亿。


近年来，我国开源项目爆发式增长态势。根据中国信通院发布的《开源生态白皮书(2021)》，中国在全球最大开源平台GitHub上的贡献者数量已经达到了全球第二。2020年，GitHub平台上中国贡献者的数量增加了37%。Gitee2020年度报告数据指出，我国在Gitee平台上开源项目增长率达192%，达到了1500万，是2013年至2018年Gitee平台开源项目的总和。


开源技术在本质事实上，可以加快存储初创公司的诞生，同时也加快了与存储相关的开源生态的发展。数据作为企业最为重要的资产，用户对于存储可靠性的要求往往会超过计算，不容有任何闪失，也因为如此，创新品牌不易被用户市场接受。诸如ceph这一类的开源项目，通过组织、公司或者基金会的运作，实现了商品的快速商业化包装和上市推广，却拉低了分布式存储的准入门槛。

开源软件面临的风险

随着国内互联网产业和软件产业蓬勃发展，对经济社会的繁荣发展起到了积极的推动作用，但在基础软件方面往往习惯于依赖开源，普遍对Linux、OpenStack、Ceph等开源软件有所依赖。过度依赖开源软件不仅会导致软件产品同质化，还会增加知识产权风险和安全风险，必须予以重视。

2021年底，国家信息中心公共技术服务部王晓冬在《我国开源软件产业面临的突出风险及对策研究》一文中分析指出，我国开源软件产业存在断供、代码安全、知识产权、自主创新等风险。

开源安全漏洞风险显著。 根据新思科技《2021 开源安全与风险分析报告》显示，84%的代码库至少含有一个漏洞，近三年漏洞比例逐年增高，60%的已审核代码库包含高风险漏洞。根据开源网安Source Check 工具对热门开源项目的扫描结果看，53.8%的项目存在超危风险。


开源需特别关注数据安全。 开源软件涉及源代码共享，很多配置信息中会涉及账号密码等敏感信息，如果不对代码进行审核检查，可能会造成大量敏感信息与数据随着代码的共享而泄露。同时开源软件公开的源代码，如果包含对企业数据库的访问代码，则可能导致整个数据库面临数据泄露的危险，同时也可能导致企业内部文件与用户信息的泄露。

开源可能面临商业产品组件协议冲突风险。开源软件涉及层层依赖关系，商业产品在使用开源过程中不断加入新的开源组件，可能导致不同协议的冲突。因此使用开源软件需要关注开源软件所依赖的其它开源软件/组件。以操作系统为例，其依赖的软件包上万，涉及源码、二进制包等多种形态，任何一个环节出现问题，都可能影响最终产品的使用。

运维成本高、统筹管理困难和安全漏洞威胁严重成为我国用户企业关注的三大挑战。根据中国信通院调研数据显示，2020 年我国企业用户认为技术更新迭代快、运维成本高为开源使用风险的比例最高，约为 60.8%，比 2019 年数据增加8%；开源软件数目庞大、统筹管理困难风险占比排名第二，达到 56.7%，与2019 年数据相比降低 6.7%；安全漏洞威胁严重风险占比排名第三，达到43.7%，与2019 年相比降低 6.5%。

开源存储固有的技术限制

开源存储软件要走向商业化所面临的挑战，可不是一朝一夕就能解决的。在国内坚持走自研路线的存储厂商如华为、中科曙光等经历了数年之久的磨练，才有了今天在存储软件的自研技术积累。由此不得不让大家联想到，开源存储这么香，为何我们还要下那么大的功夫自研呢？值得大家思考一下。

基于开源模式所发展的存储产品设计过程较为透明，因为有更多人贡献代码，产品功能迭代更快。由于其本身的庞杂性，很难有厂商将所有的代码都进行测试，在实际应用中，就存在着很大的安全隐患。

在众多开源存储软件中，Ceph作为软件定义存储开源项目的领头羊，在市场上的知名度和曝光度都很高，ceph作为是一个极其复杂的统一分布式存储系统，在生产部署和运维的技术门槛相对较高，对于小规模的ceph集群部署尚且可以用人工来应对。但对于具一定规模的ceph集群部署时人工的方法往往显得有些困难。首先在人工部署上时间成本就很高；其次是人工部署时难免会出现一些不可控的误操作。

Ceph实际产品化过程中的问题

Ceph运维中遇到的问题是真实存在的，甚至在实际的运维过程中还出现过其他更复杂的问题，盘点企业在Ceph运维中遇到的五大问题：

扩容复杂

Ceph中数据以PG为单位进行组织，因而当数据池中退出新的存储单元（OSD）时，通过调整OSDMAP会带来数据重均衡。正如提到的，如果波及到多个OSD的扩容是可能导致可用PG中OSD小于min_size，从而产生PG不可用、IO阻塞的状况。为了尽量避免这种状况的呈现，只能将扩容粒度变小，比方每次只扩容一个OSD或者一个机器、一个机柜（次要取决于存储隔离策略），然而这样注定会带来极大的运维工作量，甚至连扩容速度可能都赶不上数据增长速度。

运维复杂

Ceph本身是一个十分复杂的体系，要做到稳定运维，需要看团队对开源软件是否熟悉，是否有经验。同时，这还要看开源社区文档的质量。厂商技术实力强大，自然对于用户的服务质量就高，厂商技术实力弱一些，带给用户的服务质量就存在“折扣”。可见，每一次开源存储软件的交付，都是对开源存储厂商的技术考验。对于用户自身运维团队来讲，需要积累自己的运维文档。这对用户的技术积累管理、技术文档管理、核心人才流失管理，都产生了一些挑战。

集群利用率低

存储成本主要是看集群的可用率。即Ceph集群规模增大后，伪随机算法导致了存储资源分布不均衡，磁盘利用率方差过大的问题。

Ceph集群达到了80%后，经常有磁盘变满，需要管理员介入，调低过高磁盘的reweight。而在这台磁盘使用量没降下来之前，又有更多的磁盘被写满了，管理员就又要介入，调整reweight，Ceph至此就再也没有进入过稳定状态了，管理员还必须时时刻刻盯着集群。集群大了之后，如何清理垃圾数据、如何归档冷数据，也带来了不小的挑战。

数据迁移过程中的IO争用

在频繁数据迁移过程中带来的IO争用问题。当集群规模变大后，硬盘损坏、PG数量裁减可能会变得常态化。

死机等机器临时故障需要人工介入

出现机器死机等故障时，为了避免产生大量重算pg及数据迁移，通常需要手动禁止数据恢复和重平衡，等到机器故障恢复时再打开，来减少对业务的影响。如果不手动禁止，而是设置比较长的磁盘故障、节点故障之后的时间进行数据恢复，则在故障期间可能写入的数据将长时间得不到恢复。对运维人员的依赖较大。

osd震荡

集群压力大或者集群网络故障时，会导致osd工作线程超时或osd心跳检测超时，集群的某些osd状态一会为up一会为down，此时客户端写入数据卡顿或写入进程僵死。

为何我们还要坚持自研

站在性能、可靠性、稳定性、安全性等角度来考量，用户在面对核心业务应用场景的方案选择时，对开源存储一直都比较谨慎。特别是用户本身运维团队比较薄弱，在经验不够丰富的情况下，不得不面临后续软件维护、更新迭代等一系列技术挑战。因此用户在核心业务、生产系统和大规模部署情况下，首选依然是自研存储系统。

对用户而言，存储选择到底是开源还是自研产品，需要考虑到自身的综合成本，包括对数据安全性要求与运维成本，存储实际应用过程中解决问题的服务质量和响应时间等。当然，数据安全、运维成本与服务质量，对于任何一个开源存储厂商而言，也是值得重视的三大问题。

结合以上来看，存储软件自主研发的动机大概有以下几点：

1. 政策导向。国家要倡导关键技术的自主可控。这两年贸易战中美针锋相对，我们不仅仅是在芯片啊5G等关键方向在拼命挣扎，其实存储、数据库等领域又何尝不是呢？现在很多数据类产品国产化（势必要自研）过程中甚至需要用国内自研的加密算法，为的是响应国家级数据安全需要。
2. 市场需求导向。解决开源存储在企业级应用下的问题和痛点，比如稳定性、性能、运维、安全、多租户等方面。真正掌握核心技术，发展有竞争力、有辨识度、能满足客户需求的产品仍然是市场获胜的关键。
3. 技术支持和保障问题。开源的东西一般只解决一些地公共基础需求。 除此之外面对多重需求的企业，开源无法满足企业个性化按需定制。
4. 安全能力方面。即保证系统不受外来攻击干扰，又要保证用户的数据不被人窃取、业务不会被中断。

结语

最后想说的是开源虽然很香，平台也在享受开源的红利，但开源自身的发展方向一定有取舍，新功能优先级的设定就不一定能够满足当下客户需求，这时自研就展现出它很香的地方，越来越多的客户也在享受自研的红利，自研比开源更快的适配客户需求并实际落地。