CEPH存储介绍（理论）

前言：

• Linux持续不断进军可扩展计算空间，特别是可扩展存储空间。Ceph 最近加入到 Linux 中令人印象深刻的文件系统备选行列，它是一个分布式文件系统，能够在维护 POSIX 兼容性的同时加入了复制和容错功能。
• Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。
  

  文章目录

  • 一、概要
  • 二、历史与发展
  • 三、CEPH的优点和缺点
  • 1. 优势
  • 1）CRUSH算法
  • 2）统一存储架构
  • 3）丰富的特性
  • 2. 缺点
  • 1）代码质量
  • 2）性能
  • 3）CEPHFS
  • 4）业务连续性
  • 5）社区
  • 四、 架构
  • 1. 集中式存储架构
  • 2. 中间控制节点架构（HDFS）
  • 3. 完全无中心架构---一致性哈希（Swift）
  • 4. 完全无中心架构---计算模式（Ceph）

一、概要

• CEPH是一个开源的项目，它是软件定义的、同一的存储解决方案。CEPH是一个可大规模扩展、高性能并且无单点故障的分布式存储系统。从一开始它就运行在通用的商用的硬件上，具有高度的可伸缩性，容量可扩展至EB界别，甚至更大。
• CEPH因为开放、可扩展、分布式的本质在存储领域名声鹊起。如今公有云、私有云、乃至混合云是提供大规模基础设施的主流方案。
• CEPH发架构设计之初就包含如下特性：
  • 所有的组件必须可以扩展的
  • 不能存在单点故障点
  • 解决方案必须是软件定义的、开源的并且可以适配
  • CEPH软件应该运行在通用商用的硬件之上
  • 所有的组件必须可能自我管理
• CEPH为企业提供了基础的性能，无限的扩展性，强大的并且灵活的存储产品
• 产品官方网站：https://ceph.io
  
• 产品学习网站：http://docs.ceph.org.cn/start/intro/
  

二、历史与发展

• Ceph是圣克鲁兹加利福尼亚大学的Sage Weil在2003年开发的，也是他的博士学位项目的一部分。初始的项目原型是大约40000行C++代码的Ceph文件系统，并于2006年作为参考实现和研究平台遵循LGPL协议（Lesser GUN Public License）开源。美国劳伦斯利物莫国家实验室（Lawrence Livermore National Laboratory）资助了Sage的初始研究工作。2003～2007年是Ceph的研究开发时期。在这期间，它的核心组件逐步形成，并且社区对项目的贡献也已经开始逐渐变大
• 2007年年末，Ceph已经越来越成熟，并开始等待孵化。此时，DreamHost（洛杉矶的一个虚拟主机和域名注册公司）参与进来，从2007年到2011年对Ceph进行孵化。在这期间Ceph逐渐成型。已有的组件变得更加稳定、可靠；各种新特性也已经实现，未来的路线图也已设计好。至此，Ceph项目真正开始进入企业选择意向和路线图。在这期间，多个有名的开发者开始参与到Ceph项目中，他们中包括Yehuda Sadeh、 Weinraub、Gregory Farnum、Josh Durgin、 Samuel Just、Wido den Hollander和LoCeph这个词是宠物章鱼的一个常见绰号。Ceph可以看作Cephalopod的缩写，它属于海洋软体类动物家族。Ceph以章鱼作为自己的吉祥物，表达了Ceph跟章鱼一样的并行行为
  
• nktank这个词与章鱼有一定关系。渔民有时候也把章鱼称为墨鱼，因为它们可以喷射墨汁。这就解释了为什么章鱼（Ceph）跟墨鱼（Inktank）有一定关系。同样，Ceph和Inktank有很多共同点。你可以认为Inktank就是Ceph的智库
• Sage Weil是DreamHost的联合创始人之一
• 2007年年末Ceph项目启动时，它最先由DreamHost孵化。2008年5月7日，Sage发布了Ceph 0.2版本，之后开发进展逐渐加快。版本发布时间间隔缩短并且现在每隔一个月都会有新版本的更新。2012年7月3日，Sage宣布到目前为止最重要的一个版本Argonaut（0.48版本）发布。下表列出了Ceph发布的主要版本，包括Long Term Support (LTS)版本。更多的信息可以访问https://ceph.com/category/releases/
• 各个版本发布的时间如下：
  • Nautilus 2019年3月（v14.2.0 Nautilus released changelog）
    mimic 2018年5月
    Luminous 2017年10月
    Kraken 2017年10月（引入bluestore）
    Jewel 2016年4月
  • 历史版本：
    Infernalis Stable November 2015 - June 2016
    Hammer LTS April 2015 - November 2016
    Giant Stable October 2014 - April 2015
    Firefly 0.80版本(LTS) 2014年5月
    Emperor 0.72版本 2013年11月9日
    Dumpling 0.67版本(LTS) 2013年8月14日
    Cuttlefish 0.61版本 2013年5月7日
    Bobtail 0.56版本(LTS) 2013年1月1日
    Argonaut 0.48版本(LTS) 2012年6月3日

三、CEPH的优点和缺点

• Ceph从2004年提交了第一行代码，至今为止已经10年了。这个起源于Sage博士论文，最早致力于开发下一代高性能分布式文件系统的项目，现在也成为了开源社区众人皆知的明星项目。特别是随着云计算的发展，Ceph乘上了OpenStack的春风，受到各大厂商的待见，Intel、DreamHost、SanDisk、CISCO、Yahoo等公司都或多或少的参与其中。RedHat更是一掷千金，直接砸了1.75亿美金将Sage创建的Inktank公司及其Ceph团队收入囊中，将其作为IaaS三大组件计算、网络、存储之一
• 在这十年的发展过程中，Ceph似乎越来越向着云计算的方向靠拢，最先的CephFS文件系统已经不再是开发重点，甚至开发已经陷入了停滞状态。而与虚拟化相关的RBD、RGW则成了发展重点，成为发展最快的模块。但是从代码中仍然能够看到各种遗迹，似乎在告诉后来人这段饶了一个大弯的历史
• Ceph发展现在仍然快的眼花缭乱，让我们暂时停下脚步，看看经过十年发展后，现在Ceph的优势与缺点

1. 优势

1）CRUSH算法

• CRUSH算法是Ceph最初的两大创新之一（另一个是基于动态子树分区的元数据集群），也是整个RADOS的基石，是Ceph最引以为豪的地方
• CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。同时， CRUSH算法支持副本和EC两种数据冗余方式，还提供了四种不同类型的Bucket（Uniform, List, Tree, Straw），充分考虑了实际生产过程中硬件的迭代式部署方式，虽然实际生产中大多数情况下的都是只用了一种Straw
• 另外根据Sage的论文，CRUSH算法具有相当好的可扩展性，在数千OSD的情况下仍然能保证良好的负载平衡。但这更多是理论层面的，目前还没有人给出在数PB规模的生产环境中的测试结果
• 总的来看，CRUSH算法仍然是目前经过实践检验的最好的数据分布算法之一

2）统一存储架构

• Ceph最初设计的RADOS是为其实现一个高性能的文件系统服务的，并没有考虑对于块设备、对象存储的支持，也就没有什么RBD、RADOS GateWay，跟别提OpenStack和qemu之类的了。但谁想无心插柳柳成荫，由于 RADOS 出色的设计和独立简洁的访问接口，再加上Sage敏锐的眼光，Ceph社区果断推出了用于支持云计算的分布式块存储RBD和分布式对象存储RADOS GateWay，并将开发中心全面转向云计算领域
• 不得不说，RADOS的设计还是非常的优秀。从架构上来看，RBD和RADOSGateWay实际上都只是RADOS的客户端而已，但得益于RADOS的优秀设计，RBD和RADOSGateWay的设计和实现都很简单，不需要考虑横向扩展、冗余、容灾、负载平衡的等复杂的分布式系统问题，同时能够提供足够多的特性和足够优秀的性能，因此迅速得到了社区的认可。另一方面，Ceph为OpenStack提供了良好的支持，成为了目前最火的OpenStack底层存储系统。乘着云计算和OpenStack的东风，Ceph作为一个统一存储系统，似乎大有舍我取谁之势

3）丰富的特性

• Ceph的特性不可谓不多，从分布式系统最基本的横向扩展、动态伸缩、冗余容灾、负载平衡等，到生产环境环境中非常实用的滚动升级、多存储池、延迟删除等，再到高大上的CephFS集群、快照、纠删码、跨存储池缓存等，不可谓不强大
• 但是就像大多数开源系统一样，Ceph的基本特性，或者说真正在生产环境中用的上的特性还是非常靠谱的，但其他“高级”特性就只能打一个问号了。特别是在CephFS模块，由于Ceph社区目前的开发重点主要还是与云计算相关的部分，即RBD和RADOSGateWay，导致CephFS的开发停滞了很久，相关的特性，例如元数据集群、快照等，目前都不满足生产环境的要求

2. 缺点

1）代码质量

• 代码质量的问题，实际上是个仁者见仁智者见智的问题
• Ceph主要使用C/C++语言编写，同时外围的很多脚本和工具用了Python。之所以要说明Ceph的语言构成，是因为代码质量实际上是和语言具有密切的关系。不否认用C++也能写出优雅的代码，但相比于更加“现代”的语言，要想写出具备同样可读性、结构良好、调理清晰代码，C++要困难很多。但是，由于存储作为底层系统，对效率的追求是无止境的，因此不太可能舍弃对于内存等底层系统资源的控制，而使用Java/Python这类的语言。而作为一个开源项目，期望所有的贡献者都是C++的高手，未免有些强人所难，这似乎成了一个死结。其他类似的开源项目怎么办呢？貌似他们都用的纯c……
• 另一方面，Ceph广泛使用了STL，在部分核心代码中还是用了BOOST，这两者在底层核心系统代码中的可用性也一直存在争议。这更加加剧了代码质量的挑战性
• 最关键的是，Ceph似乎已经被太多已经背负了太多的历史包袱，比如最核心的osd模块，最初的设计包含OSD和PG类，其中PG类负责PG的通用逻辑，OSD负责管理所有的PG。然后PG的子类ReplicatedPG实现了以副本作为冗余模式的PG。这里就存在了两个半类：OSD、PG及其子类ReplicatedPG，这两个半类实现了osd模块99%的逻辑，可以想象这两个半类会有多大
• 在目前的master分支上，相关文件的大小分别是：
  • OSD.h+OSD.cc = 2383行+8604行 = 10987行
    PG.h+PG.cc = 2256行+7611行 = 9867行
    ReplicatedPG.h+ReplicatedPG.cc = 1487行+12665行 = 14152行
• 需要特别注意的是，从C++继承的角度上，理解一个类，必须理解他的父类，也就是说，如果你想理解ReplicatedPG，理论上你必须同时理解PG，也就是说，要同时理解20000+行代码！
• 更加丧心病狂的是，这两个半类之间存在密切而复杂的调用关系，相互之间直接使用整个类，而没有什么实际上的接口隔离。严重加剧了理解代码的难度
• 在EC功能以一种奇葩的方式加入到osd中之后，整个场面更加混乱。按照最初的设计，实现EC应该增加PG的一个子类，类似ErasureCodePG。但是由于ReplicatedPG包含了太多通用的代码，实际上已经和PG合二为一了，所以EC只能在ReplicatedPG的基础上改造。于是又出现了PGBackend的概念和相关的实现，这只能说是挑战人脑的极限了
• Ceph社区也曾试着梳理代码，比如添加OSDService类，作为PG与OSD通讯的接口。这样所有的PG全部调用OSDService而非OSD，相当于做了OSD与PG之间的隔离。但是似乎并没有起到足够的效果，现在已经名存实亡了
• Ceph在这样的代码质量下，还能向前走多久，委实是一件令人担忧的事情

2）性能

• 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也是一直优秀的猪。未来是什么样子，我们拭目以待

四、 架构

1. 集中式存储架构

• 分布式存储是相对于集中式存储来说的，在介绍分布式存储之前，我们先看看什么是集中式存储。不久之前，企业级的存储设备都是集中式存储。所谓集中式存储，从概念上可以看出来是具有集中性的，也就是整个存储是集中在一个系统中的。但集中式存储并不是一个单独的设备，是集中在一套系统当中的多个设备

• 以EMX公司的存储为例，整个存储系统可能需要几个机柜来存放
  

• 在这个存储系统中包含很多组件，除了核心的机头（控制器）、磁盘阵列（JBOD）和交换机等设备外，还有管理设备等辅助设备。如图2是一个集中式存储的基本逻辑示意图
  

• 在集中式存储中通常包含一个机头，这个是存储系统中最为核心的部件。通常在机头中有包含两个控制器，这两个控制器实现互备的作用，避免硬件故障导致整个存储系统的不可用。在该机头中通常包含前端端口和后端端口，前端端口用户为服务器提供存储服务，而后端端口用于扩充存储系统的容量。通过后端端口机头可以连接更多的存储设备，从而形成一个非常大的存储资源池

• 机头中是整个存储系统的核心部件，整个存储系统的高级功能都在其中实现。控制器中的软件实现对磁盘的管理，将磁盘抽象化为存储资源池，然后划分为LUN提供给服务器使用

• 这里的LUN其实就是在服务器上看到的磁盘。当然，一些集中式存储本身也是文件服务器，可以为服务器提供共享文件服务。无论如何，从上面我们可以看出集中式存储最大的特点是有一个统一的入口，所有数据都要经过这个入口，这个入口就是存储系统的机头

• 分布式存储是一个大的概念，其包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等

2. 中间控制节点架构（HDFS）

• 分布式存储最早是由谷歌提出的，其目的是通过廉价的服务器来提供使用与大规模，高并发场景下的Web访问问题。如图3是谷歌分布式存储（HDFS）的简化的模型。在该系统的整个架构中将服务器分为两种类型，一种名为namenode，这种类型的节点负责管理管理数据（元数据），另外一种名为datanode，这种类型的服务器负责实际数据的管理
  

• 上图分布式存储中，如果客户端需要从某个文件读取数据，首先从namenode获取该文件的位置（具体在哪个datanode），然后从该位置获取具体的数据。在该架构中namenode通常是主备部署，而datanode则是由大量节点构成一个集群。由于元数据的访问频度和访问量相对数据都要小很多，因此namenode通常不会成为性能瓶颈，而datanode集群可以分散客户端的请求。因此，通过这种分布式存储架构可以通过横向扩展datanode的数量来增加承载能力，也即实现了动态横向扩展的能力

3. 完全无中心架构—一致性哈希（Swift）

• 与Ceph的通过计算方式获得数据位置的方式不同，另外一种方式是通过一致性哈希方式获得数据位置。一致性哈希的方式就是将设备做成一个哈希环，然后根据数据名称计算出的哈希值映射到哈希环的某个位置，从而实现数据定位
  
• 上图一致性哈希的基本原理，为了绘制简单，本文以一个服务器上的一个磁盘为例进行介绍。为了保证数据分配的均匀性及出现设备故障时数据迁移的均匀性，一致性哈希将磁盘划分为比较多的虚拟分区，每个虚拟分区是哈希环上的一个节点。整个环是一个从0到32位最大值的一个区间，并且首尾相接。当计算出数据（或者数据名称）的哈希值后，必然落到哈希环的某个区间，然后以顺时针，必然能够找到一个节点。那么，这个节点就是存储数据的位置
• Swift存储的整个数据定位算法就是基于上述一致性哈希实现。在Swift对象存储中，通过账户名/容器名/对象名三个名称组成一个位置的标识，通过该唯一标识可以计算出一个整型数来。而在存储设备方面，Swift构建一个虚拟分区表，表的大小在创建集群是确定（通常为几十万），这个表其实就是一个数组。这样，根据上面计算的整数值，以及这个数组，通过一致性哈希算法就可以确定该整数在数组的位置。而数组中的每项内容是数据3个副本（也可以是其它副本数量）的设备信息（包含服务器和磁盘等信息）。也就是经过上述计算，可以确定一个数据存储的具体位置。这样，Swift可以将请求重新定向到该设备进行处理
  
• 上述计算过程是在一个名为Proxy的服务中进行的，该服务可以集群化部署。因此可以分摊请求的负载，不会成为性能瓶颈

4. 完全无中心架构—计算模式（Ceph）

• 下图是Ceph存储系统的架构，在该架构中与HDFS不同的地方在于该架构中没有中心节点。客户端是通过一个设备映射关系计算出来其写入数据的位置，这样客户端可以直接与存储节点通信，从而避免中心节点的性能瓶颈
  
• 在Ceph存储系统架构中核心组件有Mon服务、OSD服务和MDS服务等。对于块存储类型只需要Mon服务、OSD服务和客户端的软件即可。其中Mon服务用于维护存储系统的硬件逻辑关系，主要是服务器和硬盘等在线信息。Mon服务通过集群的方式保证其服务的可用性。OSD服务用于实现对磁盘的管理，实现真正的数据读写，通常一个磁盘对应一个OSD服务
• 客户端访问存储的大致流程是，客户端在启动后会首先从Mon服务拉取存储资源布局信息，然后根据该布局信息和写入数据的名称等信息计算出期望数据的位置（包含具体的物理服务器信息和磁盘信息），然后该位置信息直接通信，读取或者写入数据