《OpenStack CI/CD 原理与实践》

前言	2018年3月，全球 Cephers 的盛会——Cephalocon APAC 2018 在北京如期举行。来自RedHat、SUSE、Intel、中兴通讯、中国移动等 Ceph 生态联盟成员的 1000 多位 Ceph 开发者、使用者和爱好者共聚一堂，探讨 Ceph 的现状与未来，彰显了 Ceph 开源社区的蓬勃生机。时光荏苒，自 Sage A. Weil 的博士论文走来，十多年间 Ceph 已经从一个默默无闻的学生作品成长为分布式存储领域最具活力与领导力的开源项目。据 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 设计原理与实现》一书，但是基本上都进行了重新创作。重复录入这些章节不是简单的查漏补缺，而是进一步地提炼与升华，它们是本书不可或缺的组成部分。事实上，与新增内容相比，重新创作这些章节花费了我们更多的时间与精力。
第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 传统的三副本数据备份方式能够在取得高可靠性的前提下最小化客户端请求的响应时延，因而特别适合对可靠性和性能都有一定要求的存储应用。这种目前使用最广泛的备份方式缺点在于会大量占用额外的存储空间，因而导致集群的实际空间利用率不高。与之相反，纠删码以条带为单位，通过数学变换，将采用任意 k + m 备份策略所消耗的额外存储空间都成功控制在 1 倍以内，代价是计算资源消耗变大和客户端请求响应时延变长，因而适合于对时延不敏感的“冷数据”（例如备份数据）应用。

前言

2018年3月，全球 Cephers 的盛会——Cephalocon APAC 2018 在北京如期举行。来自RedHat、SUSE、Intel、中兴通讯、中国移动等 Ceph 生态联盟成员的 1000 多位 Ceph 开发者、使用者和爱好者共聚一堂，探讨 Ceph 的现状与未来，彰显了 Ceph 开源社区的蓬勃生机。时光荏苒，自 Sage A. Weil 的博士论文走来，十多年间 Ceph 已经从一个默默无闻的学生作品成长为分布式存储领域最具活力与领导力的开源项目。据 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 设计原理与实现》一书，但是基本上都进行了重新创作。重复录入这些章节不是简单的查漏补缺，而是进一步地提炼与升华，它们是本书不可或缺的组成部分。事实上，与新增内容相比，重新创作这些章节花费了我们更多的时间与精力。

第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 传统的三副本数据备份方式能够在取得高可靠性的前提下最小化客户端请求的响应时延，因而特别适合对可靠性和性能都有一定要求的存储应用。这种目前使用最广泛的备份方式缺点在于会大量占用额外的存储空间，因而导致集群的实际空间利用率不高。与之相反，纠删码以条带为单位，通过数学变换，将采用任意 k + m 备份策略所消耗的额外存储空间都成功控制在 1 倍以内，代价是计算资源消耗变大和客户端请求响应时延变长，因而适合于对时延不敏感的“冷数据”（例如备份数据）应用。

我们对Cookie的使用策略

我们对Cookie的使用策略

我们对Cookie的使用策略

中兴通讯技术丛书