历经十年：关于Ceph现状与未来的一些思考
|
1)数据双倍写入。Ceph本地存储接口(FileStore)为了支持事务，引入了日志(Journal)机制。所有的写入操作都需要先写入日志(XFS模式下)，然后再写入本地文件系统。简单来说就是一份数据需要写两遍，日志+本地文件系统。这就造成了在大规模连续IO的情况下，实际上磁盘输出的吞吐量只有其物理性能的一半。 2)IO路径过长。这个问题在Ceph的客户端和服务器端都存在。以osd为例，一个IO需要经过message、OSD、FileJournal、FileStore多个模块才能完成，每个模块之间都涉及到队列和线程切换，部分模块在对IO进行处理时还要进行内存拷贝，导致整体性能不高。 3)对高性能硬件的支持有待改进。Ceph最开始是为HDD设计的，没有充分考虑全SSD，甚至更先进的PCIe SSD和NVRAM的情况NVRAM。导致这些硬件的物理性能在Ceph中无法充分发挥出来，特别是延迟和IOPS，受比较大的影响。 3. CephFS CephFS现在在整个Ceph系统中处于一个较为尴尬的情况，因为POSIX这种借口似乎在云计算中没有用武之地，导致了社区对这个模块的关注不足，也就没有什么进展。 CephFS作为最初Ceph的设计目标，Sage投入了巨大的精力，几乎实现了所有需要的特性，并且进行了大量工程层面的优化。 正所谓成也萧何败萧何，Ceph想把CephFS模块做到足够强大，甚至是最强大，但强大的同时也意味着不菲的代价。元数据动态子树分区、目录分片、快照、权限控制、IOPS优化、故障恢复、分布式缓存、强弱一致性控制，这些高大上的名词背后都意味着复杂的工程性任务，更不要说将这些叠加在一起。很多时候，叠加不是想加，而是相乘的关系。最终的结果就是整个MDS的工程难度已经超过了可以掌控的程度，无法做出足够成熟、稳定的系统。 目前CephFS宣称其单MDS的模式是稳定的，MDS的集群的模式是不稳定的。而快照功能默认关闭，今后也够呛会有开启的可能了。 4. 业务连续性 Ceph中的RADOS采用强一致性设计，即Write-All-Read-One，这种模式的好处在于读取效率较高，而且工程难度较低，比较适合与读多写少的系统。 Write-All-Read-One的特点是必须等待所有的副本全部写入完毕才算是写入成功，这实际上对系统硬件的可靠性要求较高，因为如果在写入过程中存在任意硬件故障，则写入过程都要受影响。通常表现为卡顿，一般在数秒级别，时间长短和判断故障的机制以及故障恢复过程中IO的处理策略相关。 但是当集群非常非常大时，Write-All-Read-One对于硬件可靠性的要求几乎是无法满足的。想象一下一个10PB的系统，按照最大4TB每块盘的计算，就有2500块磁盘。按照我们以往的运维经验，每周存在一块磁盘故障是完全正常的。这种场景下，如果数据分布足够分散，实际上一块磁盘可能涉及到很多数据块，也就是说一块磁盘故障会影响很多IO，而这种情况每周发生一次。这对业务连续性的影响是已经是不可忽略的。 生产环境中的场景比这个更加复杂，因为磁盘或者硬件的故障可能不仅表现为不可写，还有可能是慢或者不稳定。这些情况对于业务连续性的影响也更加严重。 5. 社区 Ceph社区现在已经有很多厂商实际上或者号称参入进来，其中不乏Intel、Dreamhost、SanDisk这样的大厂，也不乏UnitedStack这样的Start-Up公司，还有电信、大学、研究所这类非存储领域的公司或单位。但实际上整个Ceph还是掌握在Inktank或者说RedHat的手中，绝大多数核心代码由他们贡献，也是他们Review和Merge。总的来说还是一个集权组织。 更加重要的是，Ceph相比OpenStack这种成熟完善的开源社区，缺乏足够的基础设施，例如成熟的单元测试、集成测试、测试环境、Reivew流程、贡献指引、代码规范等。导致整个社区仍然是人治、而非法制的过程，代码和系统的发展方向本质是由RedHat公司控制的。 对于以上这些问题，Ceph社区也非常清楚，并且正在或者将要改进。例如为了增加了对于SSD的支持，改进数据双倍写入问题以及更完善的社区建设和基础设施等。这些都增加了人们对Ceph的信心。 总的来说，Ceph瑕不掩瑜，仍然是一个优秀，甚至出色的开源存储系统。如果说分布式存储在云计算时代是风口上的猪，那么Ceph也是一直优秀的猪。 未来是什么样子，我们拭目以待。 关于作者 袁冬博士，UnitedStack产品副总裁、Ceph等开源存储项目的核心代码贡献者。 原文链接：https://www.ustack.com/blog/sikao/ （编辑：云计算网_宿迁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
