对于提供多媒体的服务来说，整体访问量上来之后，对存储需求依赖会越来越强，这就需要底层可以提供一个稳定的、可靠的和高性能的存储系统。下面是作者曾经根据业界主流的文件存储系统，结合业务需求进行的一次选型调研。

来源：大厂的中小型文件存储技术方案选型 - 掘金 (juejin.cn)

一、业务需求

业务侧存在的需求

• 存储量：千万级别
• 可承载下载并发数：10
• 下载qps：100
• 文件平均大小<15MB, 最大50MB
• 整体大小预估为800TB，10 并发下需要满足1GB/s的下载速度。

对于非结构化文件的存储，实际就是二进制文件的存储。数据的访问特征满足：大块的数据读写；单次写入后，多次读取，且几乎不会再有修改；要求较高的吞吐能力，对于延迟并不敏感；存储周期长；数据之间没有关系。如果追求更高的可用性和性能，某些存储系统可能就会有些捉襟见肘了。

二、结论

这里先上结论

1. 横向对比

选择了业内主流的几个分布式存储系统进行了调研，从几个维度上进行了简单的对比。

2. 结论

通过比较和分析，除了HDFS，剩下的几种存储技术都比较适合本次存储的技术选型，性能和功能上都满足需求。考虑到前后期的运维成本以及后续可能的二次开发，要求部署简单，运维成本低，可以便捷地对数据进行管理，在源代码的基础上修改成本也低，可以剔出FastDFS、Ceph、Cassandra和MongoDB Gridfs。同时，要求社区活跃度很高，后续使用中如果遇到问题，有较多资料可以参考借鉴，这一点上可以排除和go-fastdfs。这样就剩下Seaweedfs和MinIO。

MinIO支持k8s和docker方式部署，开箱即用。官方提供了主流语言如Java、Python等的SDK，同时提供了客户端mc，可以使用类似于UNIX系统的一些命令，如ls、rm和cp等，以方便管理存储于MinIO上的数据。客户端支持上，Seaweedfs只有第三方提供的客户端，这一点显然MinIO做得更好。

综上，选择MinIO和Ceph作为本次存储选型。考虑到Ceph的一些优势，如对K8s提供了更好的支持，在公司内也有基于Ceph并推向外部的成熟产品，故把Ceph列为备选方案。同时对MinIo和Ceph作了更多比较，见五、MinIO和Ceph的比较

对于大多数人而言，这里提供的建议是通用的。如果有上云的需求，并且可以组建专门的运维团队，由于Ceph对K8s的原生支持是最好的，优先选择的应该是Ceph，有必要地话可以进行二次研发；反之，因为MinIO的低运维成本，故障率也更低些，Mino反而会是更好的选择。

详细调研情况见下三、主流存储系统调研。

三、主流存储系统调研

1. HDFS

介绍

HDFS（Hadoop Distributed File System），作为Google File System（GFS）的实现，是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。

特点

• HDFS对大量小文件的存储开销比较大，适合大文件处理，如果有多个小文件，可以合并为大文件再处理
• HDFS适用于高吞吐量，而不适合低时间延迟的访问
• HDFS适用于流式读取的方式，不适合多用户写入一个文件、随机写以及文件的覆盖操作
• HDFS更加适合写入一次，读取多次的应用场景
• 开启webhdfs后，可以直接通过url下载文件。

缺点

• 不适合小文件的存储，HDFS现在默认的块大小64MB，过多的小文件会造成资源的浪费，如果合并，又会提升使用成本
• 小文件存储会带来过多的元数据信息，给Namenode带来压力

2.MongoDB

介绍

MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。主要解决的是海量数据的访问效率问题，为WEB应用提供可扩展的高性能数据存储解决方案。当数据量达到50GB以上的时候，mongodb的数据库访问速度是MySQL的10倍以上。MongoDB的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万~1.5万次读写请求。MongoDB还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储。

GridFS介绍

GridFS是MongoDB之上的分布式文件系统，用于存储和检索因超过16MB大小而无法使用BSON存储的文件，其利用了MongoDB的分布式存储机制并通过MongoDB来存储文件数据和文件元数据，兼具文档型数据库和文件系统的优势。GridFS是当前大数据潮流和复杂数据分析需求的产物。

简单地来说，GridFS通过将文件数据和文件元数据保存在MongoDB里来实现文件系统，通过复制(Replication)来应对故障切换、数据集成，还可以用来做读扩展、热备份或者作为离线批处理的数据源，通过分片来实现自动切分数据，实现大数据存储和负载均衡，通过数据库对集合中文档的管理和查询（包括MapReduce）实现轻量级文件系统接口和搜索与分析。

GridFS的一个基本思想就是可以将大文件分成很多块(chunk)，一般为256k/个。每一块作为一个单独的文档存储，这样就能存储大文件了。将文件存储在两个Document里，chunks用来存储二进制数据，Files用于存储基本文件信息。由于MongoDB支持在文档中存储二进制数据，可以最大限度减小块的存储开销。GridFS使用MongoDB的复制、分片等机制来实现分布式文件存储，使用MongoDB进行管理和复杂分析。

若文件大小没有超过16MB还是使用BinData存储比较好。

特点

• 拥有MongDB的全部优点：在线存储、高可用、可伸缩、跨机房备份。
• 支持Range Get,需要通过MongDB定期删除来释放磁盘空间

GridFS适用场景

• 对每个目录下文件的个数有限制（太多，将会影响文件的打开速度等）
• 文件数据有分数据中心镜像保存（大数据情况，可用性保证)
• 希望访问一个超大的文件，而不希望将它全部加入内存，而是有即分段读取的情况，那么GridFS天生就具备这种能力，你可以随意访问任意片段。

GridFS访问方式

• MongoDB Driver
• mongofiles command-line
• gridfs-fuse 使GridFS中存的数据可以通过标准磁盘IO方式进行访问
• nginx-gridfs, 利用Nginx直接读取gridfs中的数据进行发送，这个类似于Nginx的sendfile机制

GridFS性能

17年，一篇文章中看到有人利用两台机器组成的集群，利用ab测试nginx-gridfs的性能。详见：rdc.hundsun.com/portal/arti…。

测试结果：

缺点

• 并非专业的分布式存储系统，可能不适合高压力下读写，需要进一步调研。

• 可能发生RS102错误，在primary节点与secondary节点间出现同步差距过大的问题，最新稳定版本中不知道是不仍然存在这个问题，待验证。

参考：

• docs.mongodb.com/manual/core…
• www.mongodb.com/blog/post/s…
• 基于Flex、Red5和MongoDB的视频直播、录制及存储系统设计

3. FastDFS

介绍

FastDFS是为互联网应用量身定做的一套分布式文件存储系统，非常适合用来存储用户图片、视频、文档等文件。对于互联网应用，和其他分布式文件系统相比，优势非常明显。充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。

FastDFS按文件存储的，不会对文件进行分快（切分）存储,主要提供文件的上传下载服务应用于大中网站中。出于简洁考虑，FastDFS没有对文件做分块存储，因此不太适合分布式计算场景。

特点

• 文件不分块存储，上传的文件和OS文件系统中的文件一一对应
• 支持相同内容的文件只保存一份，节约磁盘空间
• 下载文件支持HTTP协议，可以使用内置Web Server，也可以和其他Web Server配合使用
• 支持在线扩容
• 支持主从文件
• 存储服务器上可以保存文件属性（meta-data）V2.0网络通信采用libevent，支持大并发访问，整体性能更好

缺点

• 写入一个副本即返回成功，一旦副本同步中发生问题，有数据丢失风险
• 缺乏自动化恢复机制
• 数据恢复效率低
• 存储空间利用率低，单机存储的文件数受限于inode的数量
• 社区活跃度低

参考

• FastDFS分布式文件存储原理
• HDFS和FastDFS的上传、下载效率对比测试
• FastDFS的一些缺点
• Docker 部署 FastDFS
• FastDFS FAQ

4.go-fastdfs

介绍

go-fastdfs是一个基于http协议的分布式文件系统，它基于大道至简的设计理念，一切从简设计，使得它的运维及扩展变得更加简单，它具有高性能、高可靠、无中心、免维护等优点。可以理解为FastDFS的go语言版本，虽然不是FastDFS开发维护开发的，但是go-fastdfs作者借鉴FastDFS的设计思想，在其基础上进行精简和优化。

特点

• 无依赖(单一文件）
• 自动同步,失败自动修复
• 文件自动去重
• 支持浏览器上传
• 支持小文件自动合并(减少inode占用)
• 支持断点续传(tus)
• 支持docker部署
• 支持一键迁移（从其他系统文件系统迁移过来）
• 支持异地备份（特别是小文件）
• 持token下载　token=md5(file_md5+timestamp)
• 运维简单，只有一个角色（不像fastdfs有三个角色Tracker Server,Storage Server,Client），配置自动生成
• 每个节点对等（简化运维）
• 所有节点都可以同时读写

缺点

• 开源时间较短，业界尚未有大公司应用，也没有看到成熟的存储方案可供参考。

参考

• go-fastdfs 分布式文件系统搭建

5.Seaweedfs

介绍

Seaweedfs是一个基于Go语言开发的分布式文件系统，是Facebook 发表的Finding a needle in Haystack: Facebook’s photo storage论文中提出的方案的优秀实现。

特点

• 支持数十亿级别的文件存储
• 快速响应
• 相比 FastDS,在具体存储小文件的时候，weedfs是通过将多个小文件的二级制存储到一个大文件中，然后通过索引进行具体的位置的定位。而fastdfs是通过文件夹散列的方式将文件直接存储在硬盘上面。在海量小文件的情况下，weedfs产生的文件的元数据是很少的，FastDFS会产生大量的元数据，其本身依赖的是操作系统的文件管理系统，对每一个文件的定位以及验证都是通过元数据来进行的。

性能

以项目作者的测试为例，单机测试性能可以达到15708.23 qps, 数据传输：16191.69 kb/s

缺点

• seaweedfs 采用的是同步式复写有以下几个问题：

  • 当在某个volume-server 下线又上线恢复的情况下，没有自动的同步机制
  • 同步复写需要等待每个节点都复写成功，效率相对较低
  • 虽然节点的上下线会快速通过心跳通知master节点，但是仍然存在一定的延迟，期间Volume-Server在复写的时候可能会出现因为复写已经下线的volume-server导致上传失败的情况

• seaweedfs目前在权限管理方面还相对比较弱，目前仅有一个白名单控制机制，来控制外部的读写权限/恶意删除。

• 中小型文件效率非常高，但是它的单卷最大容量被程序限制到30GB，超大文件（比如500MB以上）的存储可能效率会比较低下

参考

• github.com/chrislusf/s…

6.MinIO

介绍

MinIO 是一款高性能、分布式的对象存储系统。它与Amazon S3云存储服务兼容。它最适合存储非结构化数据，如照片，视频，日志文件，备份和容器/ VM映像。对象的大小可以从几KB到最大5TB.

特点

• 对象存储，兼容 Amazon S3 协议
• 安装运维相对简单，开箱即用
• 后端除了本地文件系统，还支持多种存储系统，目前已经包括 OSS
• 原生支持 bucket 事件通知机制 （参考2）
• 可通过多节点集群方式，支持一定的高可用和数据容灾。Minio使用纠删码erasure code和校验和checksum来保护数据免受硬件故障和无声数据损坏。 即便丢失一半数量（N/2）的硬盘，仍然可以恢复数据。
• 有 web 管理界面和 cli，可以用于测试或者管理
• 公开 bucket 中的数据可以直接通过 HTTP 获取

性能测试

官方文档上没看到物理机器上测试报告，只有aws集群的benchmark，集群拥有32个server。在3T带宽下，读的吞吐为1.46T/2，写吞吐为1.37T/s。

缺点

• 单集群不支持动态增加节点，集群搭建完成后只能通过多集群级联的方式进行扩容

参考

• MinIO用于AI和海量存储的高性能对象存储
• Performance at Scale: MinIO Pushes Past 1.4 terabits per second with 256 NVMe Drives

7. Ceph

介绍

Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。

Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

特性

• 高性能：

  • 摒弃了传统的集中式存储元数据寻址的方案，采用CRUSH算法，数据分布均衡并行度高。
  • 考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。
  • 能够支持上千个存储节点的规模，支持TB到PB级的数据。

• 高可用性：

  • 副本数可以灵活控制。
  • 支持故障域分隔，数据强一致性。
  • 多种故障场景自动进行修复自愈。
  • 没有单点故障，自动管理。

• 高可扩展性：

  • 去中心化。
  • 扩展灵活。
  • 随着节点增加而线性增长。
  • 特性丰富：
  • 支持三种存储接口：块存储、文件存储、对象存储。
  • 支持自定义接口，支持多种语言驱动

缺点

• 开发语言使用C++，二次开发成本较高
• 存储资源分配使用伪随机算法，导致实际上的数据分配可能不平均，机器资源利用率上会出现差异过大的情况
• 运维成本较高。一次扩容只能扩容一台机器，pg（placement group）迁移时间较长 ，会导致部分数据在迁移期间不可访问。

参考

• Ceph运维告诉你分布式存储的那些“坑”
• 八十亿级小文件写入测试

8. Cassandra

介绍

Cassandra 是一个来自 Apache 的分布式数据库，具有高度可扩展性，可用于管理大量的结构化数据。它提供了高可用性，没有单点故障。

特点

• 对大型表格和 Dynamo支持得最好
• 支持以某个范围的键值通过列查询
• 满足CAP中的CA，强调最终一致性，数据scan效率不如hbase,但是可以支持更高的并发写与读
• 支持类sql语言，不支持直接写入，需要预先定义好schema
• 写操作比读操作更快Cassandra写入性能是非常高的，Netflix曾经在一次测试中达到每秒超过100万次的写入
• 支持线性扩展，架构去中心化，不存在单点故障
• 不依赖于外部环境，部署简单
• 功能丰富，支持CQL(类似于SQL)。

适用场景

• 不需要辅助索引
• 同样不满足需要事务处理的业务

业内使用案例：

Cassandra甚至可以处理最庞大的数据集。Instagram每天平均处理8000万张照片，而Spotify则在其数据库中存储超过2000万首歌曲。360云盘也使用了Cassandra，高峰时期拥有超过10k+个物理节点的集群规模，差不多是国内互联网公司中Cassandra生产环境落地最大的公司。

缺点

• 需要根据业务场景高度定制调优
• 读性能不如写性能。

参考

• 为什么使用Cassandra
• Cassandra 在360的实践与改进

四、分析

1.对存储系统的要求

技术选型上主要要考虑以下几点

• 较高的高性能，主要是100M以内的文件，尤其是10M以内的文件的存储。
• 安全性/容错性高，包括单点故障，网络异常，不会因为单台机器下线造成部分数据长时间无法访问。
• 资源占用较小、运行稳定
• 高可用、支持集群、支持多活
• 支持平滑的扩容。集群可在线扩容，数据自动备份。
• 较高的并发。100并发时，文件的上传下载性能不得低于1GB/s

2.现状分析

HDFS 并不适合小文件的存储，对于存储的业务需求，不满足。webhdfs的方式容易对Namenode节点产生压力，持续的高负载读写，可能会地整体集群的稳定性造成影响。同时还存在安全问题。直接使用HDFS存储并不合适。如果配合Hbase用增加了运维成本，同时Hbase 本身也存在单点故障，对于稍微大一点的数据不断的compaction也非常影响I/O性能。

MongoDB本身对于文档处理的能力是无庸置疑的，但是没有找到海量数据存储选型使用GridFS的案例，有查到11年12年有人基于GridFS搭建集群存储图片的例子，但是最后都出这样或那样的问题。同时Github上也有很多人提出的问题没有得到解决，其本身的关注度也不如其它文件分布系统。使用GridFS风险较大。

FastDFS就其本身来说搭建分布式文件存储的集群是非常合适的，从官方的论坛上来看，也有一些大公司如京东、支付宝等在用，但是贴子是几年前贴出来的，不知道现状如何。整个FastDFS的社区活跃底较低，很多用户提出的问题没有人解答,Github上，之前存在的问题很久没有修复。相比借鉴者go-fastdfs，技术选型不如选择后者。

go-fastdfs，起步较晚，没有大公司使用的案例，对于海量数据的存储没有可以借鉴的方案，在百T级数据规模下，无法得知其稳定性和可用性如何，还有性能高低是否会受数据量的提升下降严重。

Seaweedfs 社区关注度较高，性能也可以，是Facebook Haystack小文件存储系统的开源实现。业内的一些公司，对Seaweedfs都有借鉴，像bilibi就就借鉴了SeaweedFs的设计开发了bfs。还有某东之前，曾被人指出抄袭Seaweedfs的源码。滴滴内部的对象存储系统也使用了Seaweedfs。

MinIO社区活跃度很高，本身也很成熟，业内有不少公司在应用。Mino在性能上足够优秀，运维成本较低，不足之处就是，搭建成功的集群不能再进行单机扩容，并且一个集群最多只有32个节点。如果集群的存储容量成为瓶颈，后续需要扩容，只能通过多个集群联合的方式，使用跨集群存储。

Ceph也是一个非常优秀的分布式存储文件系统。不过它的一些缺点需要在使用之前考虑清楚，比如资源利用率不高，数据迁移时的一些问题，会造成后期运维成本升高。

Cassandra严格的说是一款多模数据库，其写能力非常出众，也特别适合存储中小文件。国内热度较于国外稍有不如，但是近年来越来越多的国内公司也逐渐开始热衷于Cassandra。Cassandra适用于写多读少的情况，对于存储的选型可能不是特别合适。并且Cassandra是不支持restful api的，如果选择Cassandra需要进行二次开发或者选择一些第三方的组件来实现。

3. MinIO的深入调研

如果采用MinIO的话，需要对MinIO的功能和性能做更进一步的调研。

• 单机读写性能的测试

  • 测试不同文件大小、连接并发数等指标下的性能
  • 通过配置进行单机条件下的调优

• 集群条件下的读写性能测试

  • I/O能力是否可以线性扩展
  • 测出集群的瓶颈在哪儿
  • 通过配置进行调优

• 测试集群的容错能力

  • 通过配置不同级别的storage class, 验证MinIO纠删码对丢失数据的恢复能力。

• 多租户隔离条件下安全性

• 多集群扩容的可行性，及扩容成本

参考

• bfs:支撑Bilibili的小文件存储系统
• 滴滴对象存储系统的架构演进实践
• Compared to Other File Systems
• 基于 Go 开源项目 MIMIO 的对象存储方案在探探的实践

五、MinIO和Ceph的比较

技术选型一旦选择了某种分布式存储技术，存储方案设计时还需要进行更多的思考。除了要保证存储方案的可行性，还需要考虑后续的可扩展性，不能只在初期满足业务需求，一旦上层业务复杂性与日俱增，对底层存储系统提出了更多的要求时，存储方案需要重新设计，或者面临更大的问题需要再进行技术选型。

1. k8s支持程度

如今随着容器化技术大行其道，k8s作为容器编排系统受到越来越多用户的欢迎，一些主流的分布式技术系统也开始对k8s提供了支持。但是，支持的程度却不尽相同。有的只能以k8s的方式进行部署，有的还可以直接通过PV(PersistentVolumes)对分布式存储系统进行挂载，在pod内部可以直接访问集群上的数据，多个pod之间实现共享存储。k8s对这些分布式存储系统的支持有限，目前只支持了CephFS、Ceph RBD、GlusterFS等。 其中，CephFS和Ceph RBD都是Ceph的两种存储方式。相比GlusterFS，Ceph更适合中小文件的存储。

如果有k8s共享存储的需求，存储的又是中小文件，Ceph显然是更好的选择。Ceph的两种挂载方式也略有区别。

CephFs

• 优点：读取延迟低,I/O带宽表现良好,尤其是block size较大一些的文件；灵活度高,支持k8s的所有接入模式
• 缺点: 写入延迟相对较高且延迟时间不稳定
• 适用场景：要求灵活度高(支持k8s多节点挂载特性)，对I/O延迟不甚敏感的文件读写操作,以及非海量的小文件存储支持.例如作为常用的应用/中间件挂载存储后端.

Ceph RBD

• 优点：I/O带宽表现良好；读写延迟都很低；支持镜像快照,镜像转储
• 缺点：不支持多节点挂载
• 适用场景：对I/O带宽和延迟要求都较高,且无多个节点同时读写数据需求的应用

2. 兼容S3接口

Amazon S3是Amazon推出的一种持久安全可扩展的云存储产品，目前在业界S3已经成为对象存储系统的一种接口规范。基于这种规范开发的上层服务，可保证存储层与上层服务进行更好的分离，降低上层服务的后续迁移成本，也降低了对底层具体采用的分布式存储系统的依赖。MinIO和Ceph都对外提供了S3接口。

相比Ceph，MinIO支持存储桶通知，如果桶中的数据发生改变，比如上传了新的存储对象，可以通过这种通知机制将事件发布出去。MinIO支持Elasticsearch、Redis、Kafka和MySQL等。基于此可以更好地监控整个集群的数据变更。

3. 数据可靠性

分布式集群的数据可靠性至关重要，一旦发生节点下线，整体集群需要保证稳定可用，线上服务不受影响或影响尽可能的小。这就对分布式系统的数据持久化策略提出了很高的要求，传统的分布式存储系统大多采用多副本的方式，比如3个副本，至少要保证2个副本在线，才能确保数据不会丢失。多副本会造成很大的数据冗余，带来较高的数据存储成本，500G的数据，3副本的情况下就要求底层磁盘至少提供1.5P的存储空间。

MinIO和Ceph都支持一种纠删码的机制，当集群有节点下线时，通过这种机制 ，利用其它节点剩余的数据块以及校验块就可以对丢失的数据进行恢复。比如MinIO会通过纠删码将数据分成一半数据和一半奇偶校验块。对于12块盘，一个对象会被分成6个数据块、6个奇偶校验块，这种情况下即使丢失任意6块盘，也可以从剩下的盘中对数据进行恢复，同时只有一倍的数据冗余。

4. 集群升级

当存储系统的版本发生迭代时，带来了更多的特性，并可以更好地应用于生产环境，需要升级分布式存储系统集群。

MinIO支持滚动升级，通过客户端mc可以滚动升级整个集群中的各种节点。

Ceph有多个组件，集群升级要求各个组件按照一定的顺序进行。

• 监视器： 如果 ceph-mon 守护进程晚于 ceph-osd 守护进程启动，那么这些监视器就不能正确注册其能力，新功能也不可用，除非再次重启。
• OSD
• 元数据服务器： 如果 ceph-mds 守护进程先被重启了，它只能先等着，直到所有 OSD 都升级完，它才能完全启动
• 网关： 一起升级 radosgw 守护进程。多片上传功能有微小的行为变化，它会阻止由新版 radosgw 发起、却由旧版 radosgw 完成的多片上传请求。

5. 集群扩容

集群扩容时， 会触发所有节点之间的数据再平衡，这对线上服务的读写多多少少会有一些影响。

严格地说，MinIO并不支持集群扩容，集群初始化完成后，就不能再加入新的节点。官方建议的扩容方案时，底层可以通过添加多个集群的方式扩容，即以集群为单位进行扩容，上层通过loadbalancer 进行负载均衡，把请求分散到不同的集群中。这样可以保证集群内部数据，不会因为扩容受到影响。同时上层的服务需要保证，某个集群的存储空间的利用率达到一定阈值后，使这个集群进入“只读”模式，不再接受新的写请求。

Ceph的扩容，稍微麻烦一些，需要通过NTP保证每个节点之间的时间是同步的，并且新节点的信息，需要同步到当前集群所有节点的配置文件中。PG（Placement Group）是Ceph的逻辑存储单元，当加入新的OSD节点时，集群会调整OSD MAP重新分配数据，当PG中的OSD小于min_size时，会发生IO阻塞的情况。需要根据集群的情况适当进调整扩容策略

6. 横向对比

如果要求运维成本很低，不能保证后续的运维人力投入，同时整体的存储方案支持跨集群，可以选择MinIO。

如果线上服务对k8s的PV支持有强需求，扩容方案要求支持单节点的在线扩容，可以接受后续的运维成本，能够保持有一定的人力投入，可以选择Ceph。

参考

• Types of Persistent Volumes
• K8S 如何使用具有配额限制的 ceph 共享存储