Ceph的示例分析

这篇文章主要介绍了Ceph的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

   Ceph起源于2003年，2003年~2007年是Ceph的研究开发时期，2012年7月3日，Sage宣布版本Argonaut（0.48版本）发布，这是Ceph版本发布的一个非常重要的里程碑。Ceph在国内的应用从2014年开始走强，从此Ceph的架构设计理念在国内倍受追捧。

  Ceph为云平台提供后端存储，我觉得这个目标和定位非常清晰。Ceph一开始作为OpenStack的一个后端存储，我认为这是非常好的切入方式。摘录自Cephalocon APAC 2018前夕的社区访谈内容：“虽然Ceph的市场规模尚无官方结论，但据Ceph中国社区联合创始人孙琦粗略统计，市场上70%～80%的云平台都在采用Ceph作为底层的存储平台。”

  Ceph采用Crush算法的去中心化设计，底层基于对象存储。Ceph开始的时候以业界流行的对象存储为切入点，后来提供了块和文件存储功能。Ceph在一个统一的系统中同时提供了对象、块和文件存储功能。

  设计巧妙、功能齐全是Ceph引以为傲的亮点，但我们要看到其中潜在的隐患。作为同行，我最近对大名鼎鼎的Ceph进行了一些学习和了解，发现了解得越多，对Ceph在特定领域（如数据库）的应用就越没有信心。

  Ceph官方宣传Ceph具有高可靠、高性能和易扩容三大特性。Ceph高可靠我没有做过太多了解，姑且认为在非数据库这样严苛的场景下可以达到。易扩容是分布式系统必备特性，我相信Ceph做得还不错。对于高性能这点我持保留意见。为什么这么说呢，Ceph作为后端存储可以跑数据库吗？有在Ceph上跑过数据库的朋友，我们可以好好交流一下。接下来着重分析Ceph在性能方面做得不尽人意的地方。

  Ceph底层基于对象存储，刚开始用于对象存储功能，无可厚非。但后来增加了块和文件存储功能，底层存储还是基于对象存储，这个做法的局限性就非常明显了。

  我举个例子大家可能就明白了。FastDFS目前是类似于Kev-Value的分布式文件存储系统，没有对大文件进行分片存储，只能使用专有API访问，简洁高效。如果FastDFS要提供通用文件接口（客户端可以mount到本地的标准文件系统），并且对大文件进行分片存储，server端最省事的实现方式就是 FastDFS + 文件目录服务（文件元数据管理）。这种搭积木的实现方式性能会很好吗？请大家自行评估。

  去中心化的Crush算法或一致性hash算法在存储业界倍受推崇，我觉得还是辩证地看待这个问题比较好。去中心化的分布式算法必然带来更大的系统复杂度，这点从Ceph发布第一个版本到推出稳定可用版本的时间跨度就可以得到印证。另外，去中心化的算法针对对象存储方式比较有效，但对于其他存储方式，可能就非常鸡肋甚至不合时宜了。比如文件存储方式，因为这种方式必然要引入中心节点管理文件元数据，此时通过算法实现去中心化的做法已经丧失了其原本意义。

  最后说一下Ceph的写放大问题。“3副本情况下，当数据写入量较大时，WAF（写放大系数）逐渐收敛于6，符合我们上文WAF=2*N的推理（N为副本数）；但是当写入对象很小时，WAF则会很大。”

感谢你能够认真阅读完这篇文章，希望小编分享的“Ceph的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!