Ceph：一个 Linux PB 级分布式文件系统

Ceph 最初是一项关于存储系统的 PhD 研究项目，由 Sage Weil 在 University of California, Santa Cruz（UCSC）实施。但是到了 2010 年 3 月底，您可以在主线 Linux 内核（从 2.6.34 版开始）中找到 Ceph 的身影。虽然 Ceph 可能还不适用于生产环境，但它对测试目的还是非常有用的。本文探讨了 Ceph 文件系统及其独有的功能，这些功能让它成为可扩展分布式存储的最有吸引力的备选。

“Ceph” 对一个文件系统来说是个奇怪的名字，它打破了大多数人遵循的典型缩写趋势。这个名字和 UCSC（Ceph 的诞生地）的吉祥物有关，这个吉祥物是 “Sammy”，一个香蕉色的蛞蝓，就是头足类中无壳的软体动物。这些有多触角的头足类动物，提供了一个分布式文件系统的最形象比喻。

开发一个分布式文件系统需要多方努力，但是如果能准确地解决问题，它就是无价的。Ceph 的目标简单地定义为：

不幸的是，这些目标之间会互相竞争（例如，可扩展性会降低或者抑制性能或者影响可靠性）。Ceph 开发了一些非常有趣的概念（例如，动态元数据分区，数据分布和复制），这些概念在本文中只进行简短地探讨。Ceph 的设计还包括保护单一点故障的容错功能，它假设大规模（PB 级存储）存储故障是常见现象而不是例外情况。最后，它的设计并没有假设某种特殊工作负载，但是包括适应变化的工作负载，提供最佳性能的能力。它利用 POSIX 的兼容性完成所有这些任务，允许它对当前依赖 POSIX 语义（通过以 Ceph 为目标的改进）的应用进行透明的部署。最后，Ceph 是开源分布式存储，也是主线 Linux 内核（2.6.34）的一部分。

现在，让我们探讨一下 Ceph 的架构以及高端的核心要素。然后我会拓展到另一层次，说明 Ceph 中一些关键的方面，提供更详细的探讨。

Ceph 生态系统可以大致划分为四部分（见图 1）：客户端（数据用户），元数据服务器（缓存和同步分布式元数据），一个对象存储集群（将数据和元数据作为对象存储，执行其他关键职能），以及最后的集群监视器（执行监视功能）。

如图 1 所示，客户使用元数据服务器，执行元数据 *** 作（来确定数据位置）。元数据服务器管理数据位置，以及在何处存储新数据。值得注意的是，元数据存储在一个存储集群（标为 “元数据 I/O”）。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来，更高层次的 POSIX 功能（例如，打开、关闭、重命名）就由元数据服务器管理，不过 POSIX 功能（例如读和写）则直接由对象存储集群管理。

另一个架构视图由图 2 提供。一系列服务器通过一个客户界面访问 Ceph 生态系统，这就明白了元数据服务器和对象级存储器之间的关系。分布式存储系统可以在一些层中查看，包括一个存储设备的格式（Extent and B-tree-based Object File System [EBOFS] 或者一个备选），还有一个设计用于管理数据复制，故障检测，恢复，以及随后的数据迁移的覆盖管理层，叫做 Reliable Autonomic Distributed Object Storage （RADOS）。最后，监视器用于识别组件故障，包括随后的通知。

了解了 Ceph 的概念架构之后，您可以挖掘到另一个层次，了解在 Ceph 中实现的主要组件。Ceph 和传统的文件系统之间的重要差异之一就是，它将智能都用在了生态环境而不是文件系统本身。

图 3 显示了一个简单的 Ceph 生态系统。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器，而 Ceph Object Storage Daemon 提供了实际存储（对数据和元数据两者）。最后，Ceph Monitor 提供了集群管理。要注意的是，Ceph 客户，对象存储端点，元数据服务器（根据文件系统的容量）可以有许多，而且至少有一对冗余的监视器。那么，这个文件系统是如何分布的呢？

早期版本的 Ceph 利用在 User SpacE（FUSE）的 Filesystems，它把文件系统推入到用户空间，还可以很大程度上简化其开发。但是今天，Ceph 已经被集成到主线内核，使其更快速，因为用户空间上下文交换机对文件系统 I/O 已经不再需要。

因为 Linux 显示文件系统的一个公共界面（通过虚拟文件系统交换机 [VFS]），Ceph 的用户透视图就是透明的。管理员的透视图肯定是不同的，考虑到很多服务器会包含存储系统这一潜在因素（要查看更多创建 Ceph 集群的信息，见 参考资料 部分）。从用户的角度看，他们访问大容量的存储系统，却不知道下面聚合成一个大容量的存储池的元数据服务器，监视器，还有独立的对象存储设备。用户只是简单地看到一个安装点，在这点上可以执行标准文件 I/O。

Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。值得注意的是，在大多数文件系统中，所有的控制和智能在内核的文件系统源本身中执行。但是，在 Ceph 中，文件系统的智能分布在节点上，这简化了客户端接口，并为 Ceph 提供了大规模（甚至动态）扩展能力。

Ceph 使用一个有趣的备选，而不是依赖分配列表（将磁盘上的块映射到指定文件的元数据）。Linux 透视图中的一个文件会分配到一个来自元数据服务器的 inode number（INO），对于文件这是一个唯一的标识符。然后文件被推入一些对象中（根据文件的大小）。使用 INO 和 object number（ONO），每个对象都分配到一个对象 ID（OID）。在 OID 上使用一个简单的哈希，每个对象都被分配到一个放置组。 放置组 （标识为 PGID）是一个对象的概念容器。最后，放置组到对象存储设备的映射是一个伪随机映射，使用一个叫做 Controlled Replication Under Scalable Hashing （CRUSH）的算法。这样一来，放置组（以及副本）到存储设备的映射就不用依赖任何元数据，而是依赖一个伪随机的映射函数。这种 *** 作是理想的，因为它把存储的开销最小化，简化了分配和数据查询。

分配的最后组件是集群映射。 集群映射 是设备的有效表示，显示了存储集群。有了 PGID 和集群映射，您就可以定位任何对象。

元数据服务器（cmds）的工作就是管理文件系统的名称空间。虽然元数据和数据两者都存储在对象存储集群，但两者分别管理，支持可扩展性。事实上，元数据在一个元数据服务器集群上被进一步拆分，元数据服务器能够自适应地复制和分配名称空间，避免出现热点。如图 4 所示，元数据服务器管理名称空间部分，可以（为冗余和性能）进行重叠。元数据服务器到名称空间的映射在 Ceph 中使用动态子树逻辑分区执行，它允许 Ceph 对变化的工作负载进行调整（在元数据服务器之间迁移名称空间）同时保留性能的位置。

但是因为每个元数据服务器只是简单地管理客户端人口的名称空间，它的主要应用就是一个智能元数据缓存（因为实际的元数据最终存储在对象存储集群中）。进行写 *** 作的元数据被缓存在一个短期的日志中，它最终还是被推入物理存储器中。这个动作允许元数据服务器将最近的元数据回馈给客户（这在元数据 *** 作中很常见）。这个日志对故障恢复也很有用：如果元数据服务器发生故障，它的日志就会被重放，保证元数据安全存储在磁盘上。

元数据服务器管理 inode 空间，将文件名转变为元数据。元数据服务器将文件名转变为索引节点，文件大小，和 Ceph 客户端用于文件 I/O 的分段数据（布局）。

Ceph 包含实施集群映射管理的监视器，但是故障管理的一些要素是在对象存储本身中执行的。当对象存储设备发生故障或者新设备添加时，监视器就检测和维护一个有效的集群映射。这个功能按一种分布的方式执行，这种方式中映射升级可以和当前的流量通信。Ceph 使用 Paxos，它是一系列分布式共识算法。

和传统的对象存储类似，Ceph 存储节点不仅包括存储，还包括智能。传统的驱动是只响应来自启动者的命令的简单目标。但是对象存储设备是智能设备，它能作为目标和启动者，支持与其他对象存储设备的通信和合作。

从存储角度来看，Ceph 对象存储设备执行从对象到块的映射（在客户端的文件系统层中常常执行的任务）。这个动作允许本地实体以最佳方式决定怎样存储一个对象。Ceph 的早期版本在一个名为 EBOFS 的本地存储器上实现一个自定义低级文件系统。这个系统实现一个到底层存储的非标准接口，这个底层存储已针对对象语义和其他特性（例如对磁盘提交的异步通知）调优。今天，B-tree 文件系统（BTRFS）可以被用于存储节点，它已经实现了部分必要功能（例如嵌入式完整性）。

因为 Ceph 客户实现 CRUSH，而且对磁盘上的文件映射块一无所知，下面的存储设备就能安全地管理对象到块的映射。这允许存储节点复制数据（当发现一个设备出现故障时）。分配故障恢复也允许存储系统扩展，因为故障检测和恢复跨生态系统分配。Ceph 称其为 RADOS（见 图 3 ）。

如果文件系统的动态和自适应特性不够，Ceph 还执行一些用户可视的有趣功能。用户可以创建快照，例如，在 Ceph 的任何子目录上（包括所有内容）。文件和容量计算可以在子目录级别上执行，它报告一个给定子目录（以及其包含的内容）的存储大小和文件数量。

虽然 Ceph 现在被集成在主线 Linux 内核中，但只是标识为实验性的。在这种状态下的文件系统对测试是有用的，但是对生产环境没有做好准备。但是考虑到 Ceph 加入到 Linux 内核的行列，还有其创建人想继续研发的动机，不久之后它应该就能用于解决您的海量存储需要了。

Ceph 在分布式文件系统空间中并不是唯一的，但它在管理大容量存储生态环境的方法上是独一无二的。分布式文件系统的其他例子包括 Google File System（GFS），General Parallel File System（GPFS），还有 Lustre，这只提到了一部分。Ceph 背后的想法为分布式文件系统提供了一个有趣的未来，因为海量级别存储导致了海量存储问题的唯一挑战。

随着OpenStack日渐成为开源云计算的标准软件栈，Ceph也已经成为OpenStack的首选后端存储。Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。

Ceph是一个开源的分布式文件系统。因为它还支持块存储、对象存储，所以很自然的被用做云计算框架openstack或cloudstack整个存储后端。当然也可以单独作为存储，例如部署一套集群作为对象存储、SAN存储、NAS存储等。

前三台服务器增加一块硬盘/dev/sdb实验, 创建目录并挂载到/var/local/osd{1,2,3}

规范系统主机名添加hosts文件实现集群主机名与主机名之间相互能够解析（host 文件添加主机名不要使用fqdn方式）可用 hostnamectl set-hostname [name] 设置分别打开各节点的 /etc/hosts 文件，加入这四个节点ip与名称的对应关系:

在管理节点使用ssh-keygen 生成ssh keys 发布到各节点

第一步：增加 yum配置文件(各个节点都需要增加yum源) vim /etc/yum.repos.d/ceph.repo

或阿里的ceph源

复制配置文件到其它节点和客户端

在ceph1更新软件源并安装ceph-deploy 管理工具

配置文件的默认副本数从3改成2，这样只有两个osd也能达到 active+clean 状态，添加行 osd_pool_default_size = 2

(如果网络源安装失败，手工安装epel-release 然后安装yum –yinstall cep-release再yum –y install ceph ceph-radosgw)

错误参考： https://blog.csdn.net/yenai2008/article/details/72457463

添加osd节点 (所有osd节点执行)

我们实验准备时已经创建目录/var/local/osd{id}

（用ceph-deploy把配置文件和admin密钥拷贝到所有节点，这样每次执行Ceph命令行时就无需指定monitor地址和ceph.client.admin.keyring了）

以上基本上完成了ceph存储集群的搭建。

其中： <pg_num>= 128 ,

关于创建存储池

确定 pg_num 取值是强制性的，因为不能自动计算。下面是几个常用的值：

随着 OSD 数量的增加，正确的 pg_num 取值变得更加重要，因为它显著地影响着集群的行为、以及出错时的数据持久性（即灾难性事件导致数据丢失的概率）。

创建好存储池后，你就可以用 fs new 命令创建文件系统了

ceph fs new <fs_name>cephfs_metadata cephfs_data

其中： <fs_name>= cephfs 可自定义

在这里想起没在/etc/fstab配置ceph1、ceph2、ceph3的sdb自动挂载。

ceph在开源社区还是比较热门的，但是更多的是应用于云计算的后端存储。所以大多数在生产环境中使用ceph的公司都会有专门的团队对ceph进行二次开发，ceph的运维难度也比较大。但是经过合理的优化之后，ceph的性能和稳定性都是值得期待的。

清理机器上的ceph相关配置

可以参考内容： http://blog.51cto.com/12270625/1887648

---