作者：谢型果,严军
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Ceph之RADOS设计原理与实现试读：
前言
2018年3月，全球Cephers的盛会——Cephalocon APAC 2018在北京举行。来自RedHat、SUSE、Intel、中兴通讯、中国移动等Ceph生态联盟成员的1000多位Ceph开发者、使用者和爱好者共聚一堂，探讨Ceph的现状与未来，彰显了Ceph开源社区的蓬勃生机。
时光荏苒，自Ceph由Sage A.Weil在博士论文提出以来，十多年间，已经从一个默默无闻的学生作品成长为分布式存储领域最具活力与领导力的开源项目。据Ceph官方不完全统计，在世界范围内，目前已有超过100家公司（机构）研究与使用Ceph，其中不乏欧洲原子能研究组织（CERN）这样知名的全球性科研机构和Yahoo、阿里巴巴等著名的互联网公司。可见，作为分布式软件定义存储的标杆，Ceph领先的架构和设计理念已经深入人心。
Ceph的魅力源于其架构的前瞻性、可塑性和长期演进能力。事实上，在设计之初，Ceph被定位成一个纯粹的分布式文件系统，主要用于解决大型超级计算机之间如何通过联网的方式提供可扩展的文件存储服务。随着云计算、大数据和人工智能逐渐成为信息时代的主旋律，Ceph正不断拓展自身的触角，从取代Swift成为OpenStack首选存储后端进入公众视野，到完美适配以Amazon S3为代表的公有云接口，再到征战下一个没有硝烟的虚拟化（技术）高地——容器。时至今日，Ceph已然成为一个兼容块、文件、对象等各类经典/新兴存储协议的超级统一存储平台。随着Ceph的加速进化，可以预见，我们将会看到越来越多的基于Ceph构建的自定义存储应用。为什么写这本书
开源软件诞生的土壤决定了大部分开源软件从来就不是面向普通大众的，典型的如Linux，其无可视化界面的命令行操作方式和海量命令足以让90%的用户望而却步。Ceph作为一个出身于学院的开源作品也存在类似的缺点。此外，随着自身的不断演进和完善，Ceph已经从最初的分布式文件系统逐渐成长为一个全能的分布式统一存储平台，因此其复杂程度远远超过功能相对单一的传统存储系统。更糟的是，虽然社区有建议的编码规范，但是为了不挫伤贡献者的积极性，这些规范并未作为强制要求，因此随着贡献者数量的快速增长，Ceph代码本身也不可避免地趋于异构化。上述种种因素使得无论是使用还是开发Ceph都难度巨大，再加上语言和文化背景的差异，足以造成大量国内Ceph初级玩家难以逾越的鸿沟。
距我们创作《Ceph设计原理与实现》一书已经过去了两年。一方面，Ceph代码发生了巨大变化；另一方面，我们对Ceph的认知也有了较大提升。因此，我们两位负责研究RADOS组件的同事基于前作中的相关章节重新创作了本书。
与前作相比，本书更加专注于RADOS这个基础组件，而剥离了RBD、RGW、CephFS等具体存储应用和案例实战部分。这主要是基于以下考虑：
首先，RBD、RGW和CephFS与其承载的具体业务耦合度较高，例如RBD后续的重点工作是兼容iSCSI/FC传统块存储接口，而要彻底掌握RGW则必然要对以S3、Swift为代表的新兴对象存储协议簇有比较透彻的了解等，限于篇幅，很难单纯从Ceph的角度对这些组件做出比较完整和透彻的解读。
其次，由于时间仓促，加之不少章节均由不同的作者独立创作，因此前作中章节之间难免重复或者脱节，而本书则更加注重章节之间衔接与编排的合理性。此外，由于作者数量大幅减少，本书风格更加统一，相对而言读者可以获得更好的阅读体验。
再次，藉本次重新创作，我们进一步削弱了前作中相关章节与代码之间的耦合性，更加侧重于阐述设计理念。由于Ceph社区十分活跃，贡献者数量众多，每个版本代码都会发生翻天覆地的变化，因此，理解设计原理，以不变应万变，无疑比掌握某个特定版本的代码更为重要。
最后，需要再次强调的是，虽然本书部分章节源自《Ceph设计原理与实现》一书，但是基本上都进行了重新创作。重复录入这些章节不是简单的查漏补缺，而是进一步提炼与升华，它们是本书不可或缺的组成部分。事实上，与新增内容相比，重新创作这些章节花费了我们更多的时间与精力。本书的读者对象
本书适合于对Ceph有一定了解，想更进一步参与到Ceph开源项目中来，并致力于后续为Ceph，特别是RADOS组件添砖加瓦的开发者或者高级开发者阅读。
此外，高级运维人员通过阅读本书也能够了解和掌握Ceph的核心设计理念及高级应用技巧，从而在日常运维工作中更加得心应手。
与《Ceph设计原理与实现》力求如实反映源码的实现细节不同，本书是Ceph（特别是RADOS组件）设计思想与基本理念的高度浓缩。有条件的读者可以将两本书对照阅读，相信可以有更大收获。本书的主要内容
本书主要介绍Ceph的核心——RADOS。具体编排如下：
第1章 一生万物——RADOS导论
Ceph是集传统块、文件存储以及新兴对象存储于一身的超级分布式统一存储平台。
Ceph在架构上采用存储应用与存储服务完全分离的模式，并基于RADOS对外提供高性能和可轻松扩展的存储服务。理论上，基于RADOS及其派生的librados标准库可以开发任意类型的存储应用，典型的如Ceph当前的三大核心应用：RBD、RGW和CephFS。
作为全书的开始，本章旨在为读者建立一个RADOS的初步印象，主要介绍包括OSD、Monitor、存储池、PG、对象等在内的一众基本概念。
第2章 计算寻址之美与数据平衡之殇——CRUSH
CRUSH是Ceph两大核心设计之一。CRUSH良好的设计理念使其具有计算寻址、高并发和动态数据均衡、可定制的副本策略等基本特性，进而能够非常方便地实现诸如去中心化、有效抵御物理结构变化并保证性能随集群规模呈线性扩展、高可靠等高级特性，因而非常适合Ceph这类对可扩展性、性能和可靠性都有严苛要求的大型分布式存储系统。
CRUSH最大的痛点在于，在实际应用中，很容易出现由于CRUSH的先天缺陷导致PG分布不均，进而导致集群出现OSD之间数据分布失衡、集群整体空间利用率不高的问题，为此社区引入了包括reweight、weight-set、upmap、balancer在内的一系列手段加以改进。
第3章 集群的大脑——Monitor
Monitor是基于Paxos兼职议会算法构建的、具有分布式强一致性的小型集群，主要负责维护和传播集群表的权威副本。Monitor采用负荷分担的方式工作，因此，任何时刻、任意类型的客户端或者OSD都可以通过和集群中任意一个Monitor进行交互，以索取或者请求更新集群表。基于Paxos的分布式一致性算法可以保证所有Monitor的行为自始至终都是正确和自洽的。
第4章 存储的基石——OSD
对象存储起源于传统的NAS（例如NFS）和SAN存储，其基本思想是赋予底层物理存储设备（例如磁盘）一些CPU、内存资源等，使之成为一个抽象的对象存储设备（即OSD），能够独立完成一些低级别的文件系统操作（例如空间分配、磁盘I/O调度等），以实现客户端I/O操作（例如读、写）与系统调用（例如打开文件、关闭文件）之间的解耦。
与传统对象存储仅仅赋予OSD一些初级的“智能”不同，Ceph开创性地认为，这种“智能”可以被更进一步地用于执行故障恢复与数据自动平衡、提供完备的高性能本地对象存储服务等复杂任务上，从而使得基于OSD构建高可靠、高可扩展和高并发性能的大型分布式对象存储系统成为可能。
第5章 高性能本地对象存储引擎——BlueStore
BlueStore是默认的新一代高性能本地对象存储引擎。BlueStore在设计中充分考虑了对下一代全SSD以及全NVMe SSD闪存阵列的适配，增加了数据自校验、数据压缩等热点增值功能，面向PG提供高效、无差异和符合事务语义的本地对象存储服务。
第6章 移动的对象载体——PG
面向分布式的设计使得Ceph可以轻易管理拥有成百上千个节点、PB级以上存储容量的大规模集群。
通常情况下，对象大小是固定的。考虑到Ceph随机分布数据（对象）的特性，为了最大程度地实现负载均衡，不会将对象粒度设计得很大，因此即便一个普通规模的Ceph集群，也可以存储数以百万计的对象，这使得直接以对象为粒度进行资源和任务管理的代价过于昂贵。
简言之，PG是一些对象的集合。引入PG的优点在于：首先，集群中PG数量经过人工规划因而严格可控（反之，集群中对象的数量则时刻处于变化之中），这使得基于PG精确控制单个OSD乃至整个节点的资源消耗成为可能；其次，由于集群中PG数量远远小于对象数量，并且PG的数量和生命周期都相对稳定，因此以PG为单位进行数据同步或者迁移等，相较于直接以对象为单位而言，难度更小。
PG最引人注目之处在于其可以在OSD之间（根据CRUSH的实时计算结果）自由迁移，这是Ceph赖以实现自动数据恢复、自动数据平衡等高级特性的基础。
第7章 在线数据恢复——Recovery与Backfill
在线数据恢复是存储系统的重要研究课题之一。
与离线恢复不同，在线数据恢复的难点在于数据本身一直处于变化之中，同时在生产环境中一般都有兼顾数据可靠性和系统平稳运行的要求，因此如何合理地处理各种业务之间的冲突，恰当地分配各种业务之间的资源（例如CPU、内存、磁盘和网络带宽等），在尽可能提升数据恢复速度的同时，降低甚至完全避免数据恢复对正常业务造成干扰则显得至关重要。
按照能否依据日志进行恢复，Ceph将在线数据恢复细分为Recovery和Backfill两种方式。通常意义上，两者分别用于应对临时故障和永久故障，当然后者也常用于解决由于集群拓扑结构变化导致的数据和负载不均衡问题。
第8章 数据正确性与一致性的守护者——Scrub
Scrub是一种重要的辅助机制，用于守护集群数据的正确性与一致性。
实现上，Scrub主要依赖对象的有序性与信息摘要技术，前者使其可以不重复（从而高效）地遍历集群中的所有对象，后者则提供了一种快速检测数据正确性和一致性的手段。
与数据恢复类似，Scrub也分在线和离线两种方式。同样，由于数据本身一直处于变化之中，为了捕获数据错误和一致性问题，要求Scrub周期性地执行，同时为了能够完整地完成一次深度扫描，则要求Scrub基于合适的粒度、以合理的规则执行。
第9章 基于dmClock的分布式流控策略
dmClock是一种基于时间标签的分布式I/O调度算法。Ceph采用dmClock主要希望解决客户端业务与集群内部操作的I/O资源合理分配问题，但由于种种原因，这一部分研究进展比较缓慢。通过深入研究dmClock算法，我们在社区的基础上对其进行了改进和应用实践，增加了块设备卷粒度QoS与OSD粒度的数据恢复流量自适应控制的支持，并基于此进一步优化了整个集群的流控策略。
第10章 纠删码原理与实践
Ceph传统的3副本数据备份方式能够在取得高可靠性的前提下最小化客户端请求的响应时延，因而特别适合对可靠性和性能都有一定要求的存储应用。这种目前使用最广泛的备份方式的缺点在于会大量占用额外的存储空间，因而导致集群的实际空间利用率不高。与之相反，纠删码以条带为单位，通过数学变换，将采用任意k+m备份策略所消耗的额外存储空间都成功控制在1倍以内，而代价是计算资源消耗变大和客户端请求响应时延变长，因而适合对时延不敏感的“冷数据”（例如备份数据）应用。勘误与支持《Ceph设计原理与实现》一书出版之后，我们收到了不少读者朋友的来信，指出了书中的错误和疏漏，在此对这些热心的读者朋友们一并表示感谢。
本书在前作的基础上，对相关章节进一步做了大幅修订，同时增加了大量新的章节。由于写作和认知水平有限，问题仍然在所难免，欢迎新老读者们通过以下电子邮箱对本书进行指正：
xie.xingguo@zte.com.cn
yan.jun8@zte.com.cn致谢
Ceph官方社区的源代码是创作本书的原始素材，因此我们首先感谢Ceph官方社区和创始人Sage A.Weil先生。
其次，我们要感谢所在部门的主管领导谭芳，感谢他在日常工作中给予我们的关照，以及对于出版《Ceph设计原理与实现》与本书不遗余力的支持。
再次，感谢Clove团队，本书很大程度上是整个团队的智慧结晶。此外，我们要特别感谢宋维斌、韦巧苗、罗慕尧、朱尚忠、朱凯波等几位同事，他（她）们通读了本书的初稿，提出了大量宝贵的修改意见，极大地增强了本书的专业性与可读性。
最后，感谢IT学院的闫林老师对于出版《Ceph设计原理与实现》及本书给予的鼓励和巨大帮助。谢型果 严军2018年8月第1章一生万物——RADOS导论
Ceph诞生于10年前，本来的意图是为大型超级计算机打造一个高可靠、高可扩展和高性能的分布式文件系统。在漫长的演进过程中，Ceph基于计算分布数据、完全去中心化的设计理念，经受住了时间考验，逐渐成长为大数据时代最具生命力与参考价值的开源统一存储系统。
Ceph的特点亦即其优点如下：
1）Ceph是软件定义存储。Ceph可以运行在几乎所有主流Linux发行版（例如CentOS和Ubuntu）和其他类UNIX操作系统（例如FreeBSD）之上。2016年，社区成功地将Ceph从x86架构移植到ARM架构，表明Ceph开始进军移动通信、低功耗等前沿领域。因此，Ceph的应用场景覆盖当前主流的软硬件平台。
2）Ceph是分布式存储。分布式基因使其可以轻易管理成百上千个节点、PB级及以上存储容量的大规模集群，基于计算寻址则让Ceph客户端可以直接与服务端的任意节点通信，从而避免因为存在访问热点而产生性能瓶颈。实际上，在没有网络传输限制的前提下，Ceph可以实现我们梦寐以求的、性能与集群规模呈线性扩展的优秀特性。
3）Ceph是统一存储。Ceph既支持传统的块、文件存储协议，例如SAN和NAS，也支持新兴的对象存储协议，例如S3和Swift，这使得Ceph在理论上可以满足当前一切主流的存储需求。此外，良好的架构设计使得Ceph可以轻易地拓展至需要存储的任何领域。
上述特点使得只要存在存储需求，Ceph就能找到用武之地。因此，诚如Ceph社区所言：Ceph是存储的未来！
为了尽可能地拓展“触角”，Ceph在架构上采用存储应用与存储服务完全分离的模式（即Client/Server模式），并基于RADOS（Reliable Autonomic Distributed Object Store）——一种可靠、高度自治的分布式对象存储系统，对外提供高性能和可轻松扩展的存储服务。
毋庸置疑，RADOS是Ceph的核心组件。理论上，基于RADOS及其派生的librados标准库可以开发任意类型的存储应用，典型的如Ceph的三大核心应用——RBD（Rados Block Device）、RGW（Rados GateWay）和CephFS，如图1-1所示。图1-1 Ceph的三大核心应用
作为全书的开始，本章简要介绍包括OSD、Monitor、存储池、PG、对象在内的基本概念，旨在为读者建立一个对RADOS的初步印象。但是作为一个分布式存储系统的核心组件，RADOS的庞大和复杂在所难免，因此本章的介绍不免存在挂一漏万之嫌。好在序幕刚刚开启，如果存在某些当前无法理解的细节，读者大可不必灰心，我们将在后续章节逐一解答。1.1 RADOS概述
当存储容量达到PB级别或者更高规模时，对应的存储系统必然一直处于变化之中：随着存储需求的增长，会不断有新设备被加入进来；老设备因为故障而不断地被淘汰；任何时候都有大量数据写入、更新或者删除；持续不断的数据恢复，或者出于负载均衡而自动触发的数据迁移行为等。如果再考虑用户不断提升的数据可靠性和近乎无止境的性能诉求，那么任何基于中心控制器和查表法设计的传统存储都难免力不从心。
Ceph基于RADOS，可提供可靠、高性能和全分布式的存储服务。基于计算实时分布数据，允许自定义故障域，再加上任意类型的应用程序数据都被抽象为对象这个同时具备安全和强一致性语义的抽象数据类型，从而，RADOS可轻松地在大规模异构存储集群中实现动态数据与负载均衡。
简言之，一个RADOS集群由大量OSD（Object Store Device，对象存储设备）和少数几个Monitor组成。
OSD是个抽象概念，一般对应一个本地块设备（如一块磁盘或者一个RAID组等），在其工作周期内会占用一些CPU、内存、网络等物理资源，并依赖某个具体的本地对象存储引擎，来访问位于块设备上的数据。
基于高可靠设计的Monitor团体（quorum，本质上也是一个集群）则负责维护和分发集群的关键元数据，同时也是客户端与RADOS集群建立连接的桥梁——客户端通过咨询Monitor获得集群的关键元数据之后，就可以通过约定的方式（例如RBD、RGW、CephFS等）来访问RADOS集群，如图1-2所示。
为了去中心化、免除单点故障，RADOS使用一张紧凑的集群表对集群拓扑结构和数据映射规则进行描述。任何时刻，任何持有该表的合法客户端都可以独立地与位于任意位置的OSD直接通信。当集群拓扑结构发生变化时，RADOS确保这些变化能够及时地被Monitor捕获，并通过集群表高效传递至所有受影响的OSD和客户端，以保证对外提供不中断的业务访问。由于数据复制、故障检测和数据恢复都由每个OSD自动进行，因此即便存储容量上升至PB级别或者以上，系统也不会存在明显的调度和处理瓶颈。图1-2 一个典型的RADOS集群
RADOS取得高可扩展性的关键在于彻底抛弃了传统存储系统中诸如中心控制器、网关等概念，另辟蹊径地以基于可扩展哈希的受控副本分布算法——CRUSH（Controlled Replication Under Scalable Hashing）取而代之，作为衔接客户端和OSD的桥梁，使得客户端可以直接与OSD通信，从而得以彻底免除需要查表的烦琐操作。进一步地，由于CRUSH包含了获取集群当前数据分布形态所需的全部信息，所以OSD之间通过交互即可智能地完成诸如故障、扩容等引起的数据重新分布，而无须中心控制器进行指导和干预。集群表屏蔽了实际集群可能呈现的纷繁芜杂的细节，使得客户端可以将整个RADOS集群当作一个单一的“对象”来处理。
当然，在生产环境中，由于集群本身可能具有复杂的拓扑结构，以及随着时间的推移，不可避免地趋于异构化，为了最大化资源利用率，我们还必须对集群资源合理地分割和重组。1.2 存储池与PG
为了实现存储资源按需配置，RADOS对集群中的OSD进行池化管理。资源池（对存储系统而言，具体则是存储池）实际上是个虚拟概念，表示一组约束条件，例如可以针对存储池设计一组CRUSH规则，限制其只能使用某些规格相同的OSD，或者尽量将所有数据副本分布在物理上隔离的、不同的故障域；也可以针对不同用途的存储池指定不同的副本策略，例如若存储池承载的存储应用对时延敏感，则采用多副本备份策略；反之，如果存储的是一些对时延不敏感的数据（例如备份数据），为提升空间利用率则采用纠删码备份策略；甚至可以为每个存储池分别指定独立的Scrub、压缩、校验策略等。
为了实现不同存储池之间的策略隔离，RADOS并不是将任何应用程序数据一步到位地写入OSD的本地存储设备，而是引入了一个中间结构，称为PG（Placement Group），执行两次映射，如图1-3所示。图1-3 应用程序数据通过两次映射到达OSD的本地存储设备
第一次映射是静态的，负责将任意类型的客户端数据按照固定大小进行切割、编号后，作为伪随机哈希函数输入，均匀映射至每个PG，以实现负载均衡策略；第二次映射实现PG到OSD的映射，仍然采用伪随机哈希函数（以保证PG在OSD之间分布的均匀性），但是其输入除了全局唯一的PG身份标识之外，还引入了集群拓扑，并且使用CRUSH规则对映射过程进行调整，以帮助PG在不同OSD之间灵活迁移，进而实现数据可靠性、自动平衡等高级特性。最终，存储池以PG作为基本单位进行管理。
为了维持扁平寻址空间，实际上要求PG拥有一个全集群唯一的身份标识——PGID。由于集群所有存储池都由Monitor统一管理，所以Monitor可以为每个存储池分配一个集群内唯一的存储池标识。基于此，我们只需要为存储池中的每个PG再分配一个存储池内唯一的编号即可。假定某个存储池的标识为1，创建此存储池时指定了256个PG，那么容易理解对应的PGID可以写成1.0，1.1，…，1.255这样的形式。1.3 对象演进与排序
与Linux“一切皆文件”的设计理念类似，Ceph将任意类型的客户端数据都抽象为对象这个小巧而精致的概念。
文件伴随文件系统一同诞生，是计算机科学中最基本和最经典的概念之一。为了增强（人机之间的）可交互性，一般而言文件对外支持使用基于UTF-8编码方式的字符串进行命名，作为其唯一身份标志。这意味着在最初的文件系统设计中，所有文件都共享一个扁平的全局命名空间（namespace）。
信息技术的飞速发展使得数据（信息）呈井喷式增长，因此，与传统文件系统不同，现代文件系统普遍采用面向管理海量数据（文件）的设计——例如XFS，这是一个64位文件系统，64位意味着XFS64理论上可以存储和管理多达2个文件。而被誉为最后一个文件系统的ZFS则更进一步地采用面向128位寻址空间的设计（注：这表明单128个ZFS文件系统可以管理的存储空间为2，但是因为ZFS仍然采用64位的inode设计，所以单个ZFS文件系统能够存储的最大文件数量仍然与XFS相同。）。正如ZFS的创造者所言：理论上，单个ZFS所能管理的存储容量“即便穷尽这个地球上的每粒沙子来制造存储设备也无法企及”。
出于查找效率考虑，面向管理海量文件而生的现代文件系统不可能继续采取全局唯一的扁平命名空间，而必须采用更高效的组织方式。参考人类社会族谱、各类社会组织机构等，一个自然的想法是转而使用树这种非线性数据结构对文件系统中所有文件进行描述：树中每个叶子节点表示一个文件，每个中间节点则起到了隔离和保护其辖下所有文件、特别是每个文件名作用域的作用，因此这些中间节点又被形象地称为文件夹（或者目录）。这样，即便使用数据结构中最常见的平衡二叉树来管理单个64位文件系统中的所有文件（注：指64理论上限，即2。），树的高度（或者层级）也不超过64，也就是查找任何文件都可以经过至多64次比较得到。
与文件类似，Ceph也使用字符串对对象进行标识，使用命名空间对每个对象归属的作用域进行限制和隔离。除此之外，因为对象（必须通过PG间接地）归属于某个存储池，因此对象还必须记忆其归属的存储池标识。
作为文件系统中最经典的数据备份机制，快照和克隆对所有存储系统而言几乎都是必备功能。在将一切客户端数据对象化之后，很容易理解Ceph的快照和克隆功能，其实现粒度也应当是对象级的。因此，为了区分原始对象和由其产生的一众克隆对象，必须通过向对象中添加全局唯一的快照标识（snap-id）加以解决。进一步，在宣布支持纠删码这种数据备份机制后，Ceph的数据强一致性设计必然要求其支持对象粒度的数据回滚功能，为此还必须能够区分某个纠删码对象的当前版本和由其衍生的一众历史版本。类似地，这通过向对象中添加分片标识（shard-id）和对象版本号（generation）加以解决。
至此，我们已经得到了基于对象名、命名空间、对象归属的存储池标识、快照标识、分片标识和版本号区分集群中各种对象的方法，基于这些特征值构造的数据结构也被称为对象标识（object-id），其在集群内唯一定义一个Ceph对象。
事实上，无论是Ceph引以为傲的自动数据恢复和平衡功能，还是用于守护数据正确性与一致性的Scrub机制，都无不隐式地依赖于“可以通过某种手段不重复地遍历PG中所有对象”这个前提，这实际上要求能够对PG中的每个对象进行严格排序。一个比较直观的方法是简单地将对象标识中所有特征值按照一定顺序拼接起来，形成一个囊括对象所有特征信息的字符串。这样，直接通过字符串比较（容易理解，每个这种类型的字符串都唯一对应一个对象），我们即可实现对象排序。然而不幸的是，一些典型应用，例如RBD，为了保证对象的唯一性，一般都会倾向于使用较长的对象名（例如rbd_data.75b86e238e1f29.0000000000000050），因此如果直接采用上面这种方式，其效率实际上是十分低下的。
一个改进的方向是与存储池标识类似，要求每个对象也直接采用集群内唯一的数字标识。考虑到Ceph本身是个分布式存储系统，这个数字标识只能由客户端在创建每个对象时统一向Monitor申请。显然，这样做效率只会更低。那么，是否还有其他代价较小的方法能产生这个数字标识呢？答案是哈希。
哈希是一种在密码学中被广泛使用的非对称数学变换手段。大部分情况下，针对不同输入，哈希都能够得到不同输出，而使用不同输入得到相同输出的现象称为哈希冲突。产生哈希冲突的概率一是取决于算法本身，二是取决于输出长度。考虑到目前广泛使用的几种哈希算法都经过大量工程实践验证，其算法本身的质量毋庸置疑，因此采用典型哈希算法（例如MD5、SHA）产生冲突的概率主要受输出长度影响。举例来说，如果输出长度为16位，则原始输入经过哈希后至多产生65536种不同的结果（输出）；如果输出长度增加到32位，则将产生超过40亿种不同的结果。显然，在保证算法不变的前提下，增加输出长度可以不同程度地降低产生冲突的概率。当然，随着输出长度的增加，所需的存储空间也将相应增加，加之冲突的发生理论上不可避免，因此一般而言输出长度也不是越大越好。
考虑到Ceph当前的实现中，我们总是以PG为单位进行数据迁移、Scrub等，因此实际上仅需要能够针对单个PG中的全部对象进行排序即可。以标称容量为1TB的磁盘为例，按照每个OSD承载100个PG并且每个对象大小固定为4MB进行估算，平均每个PG存储的对象数量约为2621个。因此，在相当长的一段时间内（注：参考摩尔定律，9假定磁盘容量每年翻一番，按照前面的估算，2621×2=1341952，即要到9年之后，单个PG能够存储的对象数量才能达到百万级别。），我们认为每个PG能够存储的最大对象数量大约在百万至千万级别。进一步地，综合考虑内存消耗（这个哈希结果需要作为对象标识的一部分常驻内存）和比较效率（我们引入这个数值的初衷就是为了对对象排序进行加速），采用32位的哈希输出是一个比较合理的选择。
确定了哈希输出长度后，反过来我们需要决策哪些对象特征值适合充当哈希输入。最差的做法当然是直接使用对象的全部特征值。考虑到快照、纠删码数据回滚并不是常见操作，因此与之相关的快照标识、分片标识、版本号这类特征值在大部分情况下都是无效值，可以排除在外。进一步地，由于PG不能在存储池之间共享，即某个PG中的所有对象都只能归属于同一个存储池，所以在计算哈希时，存储池标识也是无效输入，同样需要予以剔除。
综上，我们认为使用命名空间加上对象名作为哈希输入是合适的。包含此32位哈希值之后的对象标识如表1-1所示。表1-1 对象标识
注：http://burtleburtle.net/bob/hash/evahash.html
基于对象的特征值可以定义对象排序所依赖的比较算法如下：
·比较两个对象的分片标识
·比较两个对象的存储池标识
·比较两个对象的32位哈希值
·比较两个对象的命名空间
·比较两个对象的键
·比较两个对象的对象名
·比较两个对象的快照标识
·比较两个对象的版本号
·判定两个对象相等
进一步地，基于上述排序算法可以对PG中的所有对象执行快速排序，这是实现Backfill、Scrub等复杂功能的理论基础。1.4 stable_mod与客户端寻址
Ceph通过C/S模式实现外部应用程序与RADOS集群之间的交互。任何时候，应用程序通过客户端访问集群时，首先由其客户端负责生成一个字符串形式的对象名，然后基于对象名计算得出一个32位哈希值。针对此哈希值，通过简单的数学运算，例如对存储池的PG数（pg_num）取模，可以得到一个PG在存储池内部的编号，加上对象本身已经记录了其归属存储池的唯一标识，最终可以找到负责承载该对象的PG。
假定标识为1的存储池中的某个对象，经过计算后32位哈希值为0x4979FA12，并且该存储池的pg_num为256，则由：0x4979FA12 mod 256 = 18
我们知道此对象由存储池内编号为18的PG负责承载，并且其完
试读结束[说明：试读内容隐藏了图片]