Ceph研究教程.pptx

Ceph 研究分析;简介;开发文件系统是一种复杂的投入，但是如果能准确的解决问题的话，则拥有着不可估量的价值。Ceph 的目标可以简单的定义为： 容易扩展到 PB 量级 不同负荷下的高性能 （每秒输入输出操作数 [IPOS]、带宽） 可靠性高 不幸的，这些目标彼此间矛盾（例如，可扩展性会减少或阻碍性能，或影响可靠性）。Ceph 开发了一些有趣的概念（例如动态元数据分区、数据分布、复制），本文会简单探讨。Ceph 的设计也集成了容错特性来防止单点故障，并假定，大规模（PB 级的存贮）的存储故障是一种常态，而非异常。最后，它的设计没有假定特定的工作负荷，而是包含了可变的分布式工作负荷的适应能力，从而提供最佳的性能。它以 POSIX 兼容为目标完成这些工作，允许它透明的部署于那些依赖于 POSIX 语义的现存应用（通过 Ceph 增强功能）。最后，Ceph 是开源分布式存储和 Linux 主流内核的一部分。;现在，让我们先在上层探讨 Ceph 架构及其核心元素。之后深入到其它层次，来辨析 Ceph 的一些主要方面，从而进行更详细的分析。 Ceph 生态系统可以大致划分为四部分（见图1）：客户端（数据使用者）、元数据服务器（缓冲及同步分布的元数据）、对象存储集群（以对象方式存储数据与元数据，实现其它主要职责），及集群监控（实现监控功能）。;图2 提供了架构的另一视角图。一组服务器通过客户端接口访问 Ceph 生态系统，接口理解元数据服务器和对象级存储的关系。这种分布式存储系统可被看作为几层，包括存储设备的格式（扩展的和基于 B-树 的对象文件系统[ebofs]，或者其它备选），为管理数据复制、故障检测、恢复、后续数据迁移（称之为可靠的自发分布式对象存储，RADOS）等所设计的至关重要的管理层。最后，监控用于鉴定组件故障，包括后续通知。;了解了 Ceph 的概念构图之后，你可以继续深入了解 Ceph 生态系统内实现的主要组件。Ceph 和传统文件系统一个关键的不同是，智能并非集中于文件系统本身，而是分布在生态系统各处。 图 3 展示了一个简单的 Ceph 生态系统。Ceph 客户端是 Ceph 文件系统的使用者。Ceph 元数据后台服务程序提供了元数据服务，?? Ceph 对象存储后台服务程序提供了实际的存储（数据及元数据）。最后， Ceph 监控提供了集群的管理。注意可以存在多个 Ceph 客户端，多个对象存储端点，许多元数据服务器（取决于文件系统的能力），和至少一对冗余监控。这样的话，这个文件系统是怎样实现分布的呢？;Ceph 组件;因为 Linux 为文件系统提供了一个通用接口（通过虚拟文件系统交换器 [VFS]），Ceph 的用户视角是透明的。考虑到多个服务器组成存储系统的可能性（详见关于创建 Ceph 集群的?资源?一节），管理员视角当然会不同。从使用者的视角看，他们可以使用海量存储系统，并不知晓下层的元数据服务器、监控、聚合成大规模存储池的各个对象存储设备。使用者仅仅看到一个挂载点，从那里执行标准的文件 I/O 操作。 Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。注意绝大多数文件系统，所有的控制和智能都实现在内核的文件系统源代码本身中。但对 Ceph 而言，文件系统的智能分布在各节点上，它简化了客户端接口，但也同时提供给 Ceph 应对大规模（甚至动态的）数据的能力。;并非是依赖于分配链（用来映射磁盘块到指定文件的元数据），Ceph 使用了一个有趣的选择。一个文件从 Linux 的角度看，被赋予了一个来自元数据服务器的 inode 号（INO），它是文件的唯一识别符。之后这个文件被刻进到多个对象中（基于文件大小）。使用 INO 和 对象号 （ONO），每个对象被赋予了一个对象 ID（OID）。通过使用 OID 上的一个简单哈希，每个对象被分配到 一个放置组中。这个放置组（通过 PGID 来识别）是对象的概念上的容器。最后，放置组到对象存储设备的映射是一种使用了称为可扩展哈希受控复制（CRUSH）算法的伪随机映射。以这种方式，放置组（及副本）映射到存储设备不依赖于任何元数据，而是依赖于伪随机映射函数。这种行为是理想的，因为它最小化了存储的负荷，以及简化了数据的分布和查询。 最后一个分配组件是集群映射。集群映射是代表着存储集群的设备的有效表示。通过 PGID 和 集群映射，你可以定位任何对象。;元数据服务器的任务 (命令) 是管理文件系统的命名空间。尽管不管是数据还是元数据都存储在对象存储集群中，它们都被分别管理，以支持可扩展性。事实上，元数据在元数据服务器的集群间进一步的分割，这些元数据服务器能够自适应的复制和散布命名空间，从而避免热点。如图 4所示，元数据服务器管理部分命名空间，并能部分重叠