在本章中，我们将介绍以下秘籍：
在本章中，我们将学习一些关于 Ceph 的非常有趣的主题。这些将包括硬件/软件建议、Ceph 组件（即 Ceph MON 和 OSD）和客户端的性能调整，包括操作系统调整。最后，我们将了解 Ceph 擦除编码和缓存分层，涵盖两者的不同技术。
Ceph 是一种软件定义的存储解决方案，旨在在商用硬件上运行。这种能力使其成为一种灵活且经济的解决方案，可根据您的需求量身定制。由于 Ceph 的所有智能都存在于其软件中，因此它需要一套良好的硬件才能使其成为一个出色的存储解决方案的整体软件包。
Ceph 硬件选择需要根据您的存储需求和您拥有的用例进行细致的规划。组织需要优化的硬件配置，使他们能够从小规模起步并扩展到数 PB。下图展示了用于确定 Ceph 集群的最佳配置的几个因素：
不同的组织有不同的存储工作负载，通常需要性能、容量和 TCO 共享的中间地带。 Ceph是统一存储，即可以在同一个集群中提供文件、块、对象存储。 Ceph 还能够在同一个集群中提供针对不同工作负载的不同类型的存储池。这种能力允许组织根据需要定制其存储基础架构。有多种方法可以定义您的存储需求；下图显示了这样做的一种方法：
其他方法如下：
如前所述，Ceph 硬件选择需要根据您的环境和存储需求进行细致的规划。硬件组件的类型、网络基础设施和集群设计是您在 Ceph 存储规划的初始阶段应考虑的一些关键因素。 Ceph 硬件选择没有黄金法则，因为它取决于各种因素，例如预算、性能与容量（或两者）、容错级别和用例。
Ceph 与硬件无关；组织可以根据预算、性能或容量要求或用例自由选择他们选择的任何硬件。他们可以完全控制他们的存储集群和底层基础设施。此外，Ceph 的优点之一是它支持异构硬件。您可以在创建 Ceph 集群基础架构时混合使用硬件品牌。例如，在构建 Ceph 集群时，您可以混合使用来自不同制造商（例如 HP、Dell、Supermicro 等）的硬件，甚至是现成的硬件，从而显着节省成本。跨度>
您应该记住，Ceph 的硬件选择取决于您计划在存储集群上放置的工作负载、环境以及您将使用的功能。在这个秘籍中，我们将学习为 Ceph 集群选择硬件的一些一般做法。
Ceph 监控守护进程维护集群映射，不向客户端提供任何数据，因此它是轻量级的，没有非常严格的 < span>处理器要求。在大多数情况下，一个普通的单核服务器处理器将为 Ceph 监视器完成这项工作。另一方面，Ceph MDS 更需要资源。它需要四核或更好的 CPU 处理能力显着提高。对于小型 Ceph 集群或概念验证环境，您可以将 Ceph 监视器与其他 Ceph 组件（例如 OSD、RADOS 网关，甚至 Ceph MDS）放在一起。对于大中型环境，Ceph 监视器不应被共享，而应托管在专用机器上。
Ceph OSD 守护进程需要相当多的处理能力，因为它为客户端提供数据。要估计 Ceph OSD 的 CPU 需求，了解服务器将托管多少个 OSD 很重要。通常建议每个 OSD 守护程序至少应具有一个 CPU 核心 GHz。您可以使用以下公式来估算 OSD CPU 需求：
例如，具有单插槽、六核、2.5 GHz CPU 的服务器应该足以支持 12 个 Ceph OSD，每个 OSD 将获得大约 1.25 GHz 的计算能力：
以下是 Ceph OSD 节点的更多处理器示例：
英特尔® 至强® 处理器 E5-2620 v4（2.10 GHz，8 核）：
1*8*2.10 = 16.8意味着这对于具有多达 16 个 OSD 的 Ceph 节点是有益的
英特尔® 至强® 处理器 E5-2680 v4（2.40 GHz，14 核）：
1*14*2.40 = 33.6意味着这对于具有多达 33 个 OSD 的 Ceph 节点是有益的
如果您打算使用 Ceph 纠删码功能，那么获得更强大的 CPU 会更有利，因为纠删码操作需要更多的处理能力。在使用 Ceph 纠删码时确定 CPU 时，最好高估所需的处理能力，而不是低估它。
Monitor 和 MDS 守护进程需要快速提供数据，因此它们应该有足够的内存来加快处理速度。经验法则是每个守护程序实例有 2 GB 或更多内存——这对 Ceph MDS 和较小 Ceph 集群中的监视器应该是有益的。较大的 Ceph 集群应该增加这个数量。 Ceph MDS 很大程度上依赖于数据缓存；由于他们需要快速提供数据，因此需要大量 RAM。 Ceph MDS 的 RAM 越高，Ceph FS 的性能就越好。
OSD 通常需要大量的物理内存。对于平均工作负载，每个 OSD 守护程序实例 1 GB 内存就足够了。但是，从性能的角度来看，每个 OSD 守护进程 2 GB 是一个不错的选择，并且拥有更多内存也有助于恢复和改进缓存。此建议假设您为一个物理磁盘使用一个 OSD 守护程序。如果每个 OSD 使用多个物理磁盘，内存需求也会增加。一般来说，物理内存越多越好，因为在集群恢复期间，内存消耗会显着增加。值得知道的是，如果考虑底层物理磁盘的 RAW 容量，OSD 内存消耗会增加。因此，6 TB 磁盘的 OSD 要求将高于 4 TB 磁盘。您应该明智地做出此决定，以免内存成为集群性能的瓶颈。
Ceph 是一个分布式存储系统，它严重依赖于底层网络基础设施。如果您希望您的 Ceph 集群可靠且高性能，请确保您的网络专为它设计。建议所有集群节点都有两个冗余的独立网络用于集群和客户端流量。
对于小型概念验证，或测试几个节点的 Ceph 集群，1 GBps 的网络 速度应该可以正常工作。如果您有一个中大型集群（几十个节点），您应该考虑使用 10 GBps 或更多的网络带宽。在恢复/重新平衡时，网络起着至关重要的作用。如果您的带宽网络连接有 10 GBps 或更多，您的集群将快速恢复，否则可能需要一些时间。因此，从性能的角度来看，10 GBps 或更高的双网络将是一个不错的选择。精心设计的 Ceph 集群使用两个物理上分离的网络：一个用于集群网络（内部网络），另一个用于客户端网络（外部网络）。这两个网络都应该从服务器到网络交换机以及介于两者之间的所有内容在物理上分开，如下图所示：
关于网络，另一个争论的话题是是使用以太网还是 InfiniBand 网络，或者更准确地说是 10 G 网络还是 40 G 或更高带宽的网络。它取决于几个因素，例如工作负载、Ceph 集群的大小、Ceph OSD 节点的密度和数量等等。在几次部署中，我看到客户使用 Ceph 的 10 G 和 40 G 网络。在这种情况下，Ceph 集群范围为几个 PB 和几百个节点，它们使用客户端网络为 10 G，内部集群网络为高带宽、低延迟 40 G。然而，以太网的价格网络出现故障；根据您的用例，您可以决定您想要的网络类型。
对于网络优化，您可以选择使用巨型帧以获得更好的 CP/带宽比。如果要使用巨型帧，请记住验证所有互连网络设备都配置为处理巨型帧。启用巨型帧将在本章后面的秘籍中讨论。
Ceph 集群的性能和经济性都在很大程度上取决于存储介质的有效选择。在为 Ceph 集群选择存储介质之前，您应该了解您的工作负载和可能的性能要求。 Ceph 以两种方式使用存储介质：OSD 日志部分和 OSD 数据部分。正如前面章节中所解释的，Ceph 中的每个 write 操作目前都是一个两步过程。当 OSD 收到写入对象的请求时，它首先将该对象写入代理集中 OSD 的日志部分，并发送一个 write 向客户致谢。不久之后，日志数据同步到数据分区。值得知道的是，复制也是 write 性能的重要因素。复制因子通常是可靠性、性能和 TCO 之间的权衡。这样，所有的集群性能都围绕着 OSD 日志和数据分区。
如果您的工作负载以性能为中心，那么建议您使用 SSD。通过使用 SSD，您可以通过减少访问时间和 write 延迟来显着提高吞吐量。为了将 SSD 用作日志，我们在每个物理 SSD 上创建多个逻辑分区，这样每个 SSD 逻辑分区（日志）都映射到一个 OSD 数据分区。在这种情况下，OSD 数据分区位于旋转磁盘上，并且其 日志位于更快的 SSD 分区上。< /span> 下图说明了这种配置：
在这种类型的设置中，您应该记住不要通过存储超出其限制的多个日志来使 SSD 过载。通常，10 GB 到 20 GB 的日志大小对于大多数情况应该足够了，但是，如果您有更大的 SSD，您可以创建更大的日志设备；在这种情况下，不要忘记增加 OSD 的文件存储最大和最小同步时间间隔。
与 Ceph 一起使用的两种最常见的非易失性快速存储类型是 SATA 或 SAS SSD，以及 PCIe 或 NVMe SSD。为了让您的 SATA/SAS SSD 获得良好的性能，您的 SSD 与 OSD 的比例应该是 1:4，即一个 SSD 与四个 OSD 数据磁盘共享。对于 PCIe 或 NVMe 闪存设备，根据设备性能，SSD 与 OSD 的比率可以在 1:12 到 1:18 之间变化，即一个闪存设备与 12 到 18 个 OSD 数据磁盘共享。< /span>
将单个 SSD 用于多个日志的不利之处在于，如果您丢失了 SSD，托管多个日志，则与该 SSD 关联的所有 OSD 都将失败，您可能会丢失数据。但是，您可以通过对日志使用 RAID one 来克服这种情况，但这会增加您的存储成本。此外，与 HDD 相比，每 GB 的 SSD 成本几乎高出十倍。因此，如果您使用 SSD 构建集群，则会增加 Ceph 集群的每 GB 成本。但是，如果您希望从 Ceph 集群中获得显着的性能改进，那么值得为期刊投资 SSD。
我们了解了很多关于 SSD 日志的知识，并且了解它们可以有助于提高 write 性能。但是，如果您不关心极限性能，并且每 TB 的成本是您的决定因素，那么您应该考虑将日志和数据分区配置在同一个硬盘驱动器上。这意味着，在您的大型旋转磁盘中，您将为 OSD 日志分配几 GB，并将同一驱动器的剩余容量用于 OSD 数据。这种设置的性能可能不如基于 SSD 日志的设置，但每 TB 存储价格的 TCO 会相当低。
一般来说，OSD 与日志的比率的既定公式是：
前面的公式通常为 SSD 日志磁盘产生大约四到五个旋转驱动器。这意味着根据前面的公式，单个 SSD 磁盘可用于承载大约四到五个 OSD 的日志。
OSD 是存储所有数据的真正主力。在生产环境中，您应该在 Ceph 集群中使用企业、云或归档类硬盘驱动器。通常，桌面级 HDD 不太适合生产 Ceph 集群。原因在于，在 Ceph 集群中，数百个旋转 HDD 安装得很近，组合的旋转振动可能成为桌面级 HDD 的挑战。这会增加磁盘故障率并可能影响整体性能。企业级 HDD 专门用于处理振动，它们本身产生的旋转振动非常小。此外，它们的中位故障间隔时间 (MTBF) 明显高于桌面级 HDD。
Ceph OSD数据盘的另外一个需要考虑的就是它的接口，也就是SATA或者SAS。 NL-SAS 硬盘具有双 SAS 12 GBps 端口，它们通常比单端口 6 GBps SATA 接口 硬盘具有更高的性能。此外，双 SAS 端口提供冗余，还可以允许同时读取和写入。 SAS 设备的另一个方面是，与 SATA 驱动器相比，它们的不可恢复的读取错误 (URE) 较低。 URE 越低，清理错误和归置组修复操作就越少。
Ceph OSD 节点的密度也是集群性能、可用容量和 TCO 的重要因素。一般来说，拥有更多的小节点比拥有几个大容量节点要好，但这总是有争议的。您应该选择 Ceph OSD 节点的密度，使得一个节点应小于集群总大小的 10%。
例如，在 1 PB Ceph 集群中，您应该避免使用 4 x 250 TB OSD 节点，其中每个节点构成集群容量的 25%。相反，您可以拥有 13 个 80 TB OSD 节点，其中每个节点的大小小于集群容量的 10%。但是，这可能会增加您的 TCO，并可能影响集群规划方面的其他几个因素。
Ceph 是在基于 Linux 的操作系统之上运行的软件定义系统。 Ceph 支持大多数主要的 Linux 发行版。截至目前，运行 Ceph 集群的有效操作系统选择是 RHEL、CentOS、Fedora、Debian、Ubuntu、openSUSE 和 SLES。对于 Linux 内核版本，建议您在较新版本的 Linux 内核上部署 Ceph。我们还建议在具有长期支持（LTS< /span>）。 在编写本书时，推荐使用 Linux 内核 v3.16.3 或更高版本，这是一个很好的起点。留意 http:// 是个好主意docs.ceph.com/docs/master/start/os-recommendations。根据文档，CentOS 7 和 Ubuntu 14.04 是 tier-1 发行版，其全面的功能、回归和压力测试套件连续运行，毫无疑问，如果您使用的是企业 Red，RHEL 7 是最佳选择帽子 Ceph 存储产品。
Ceph OSD 守护进程运行在可以是 XFS、EXT 甚至 Btrfs 的文件系统之上。然而，为 Ceph OSD 选择正确的文件系统是一个关键因素，因为 OSD 守护进程严重依赖底层文件系统的稳定性和性能。除了稳定性和性能，文件系统还提供扩展属性（XATTR) Ceph OSD 守护进程利用的。 XATTR 向 Ceph OSD 守护进程提供有关对象状态、快照、元数据和 ACL 的内部信息，这有助于数据管理。
这就是为什么底层文件系统应该为 XATTR 提供足够的容量。 Btrfs 提供了更大的 XATTR 元数据，它存储在一个文件中。 XFS 有一个相对较大的限制（64 KB），大多数部署不会遇到，但是 ext4 太小而无法使用。如果您在 Ceph OSD 中使用 ext4 文件系统，则应始终将 filestore xattr use omap = true 添加到 [OSD] 部分的以下设置中>ceph.conf 文件。文件系统的选择对于生产工作负载来说非常重要，而对于 Ceph，这些文件系统在很多方面彼此不同，如下所示：
在这个秘籍中，我们将学习 Ceph 集群的一些性能调优参数。这些集群范围的配置参数是在 Ceph 配置文件中定义的，因此每次 Ceph 守护程序启动时，它都会遵守定义的设置。默认情况下，配置文件名为ceph.conf，位于/etc/ceph目录下。这个配置文件有一个全局部分以及每个服务类型的几个部分。每当 Ceph 服务类型启动时，它都会应用 [global] 部分以及 下定义的配置 守护进程特定部分。一个 Ceph 配置文件有多个部分，如下图所示：
我们现在将讨论配置文件的每个部分的作用：
在下一个秘籍中，我们将学习一些调整 Ceph 集群性能的技巧。性能调优是一个庞大的话题，需要了解 Ceph 以及存储堆栈的其他组件。性能调整没有灵丹妙药。这在很大程度上取决于底层基础架构和您的环境。
全局参数应在 Ceph 集群配置文件的 [global] 部分定义，如如下：
如前所述，PG和PGP编号应保持相同。 PG 和 PGP 值根据集群大小变化很大。前面提到的配置不应损害您的集群，但您可能需要在应用这些值之前考虑一下。您应该知道，这些参数不会更改现有池的 PG 和 PGP 编号；它们在您创建新池而不指定 PG 和 PGP 值时应用。
默认日志级别对您的集群来说已经足够好了，除非您发现内存级别日志正在影响您的性能或内存消耗。在这种情况下，您可以尝试禁用内存日志记录。要禁用内存中日志的默认值，请添加以下参数：
监视器调优参数应在 Ceph 集群配置文件的 [mon] 部分定义为如下：
在这个秘籍中，我们将了解应该在 [osd] Ceph 集群配置文件的部分。
以下设置允许 Ceph OSD 守护进程确定文件系统类型、挂载选项以及其他一些有用的设置：
Ceph OSD 守护进程支持以下日志配置：
journal_max_write_bytes：日志一次可以写入的最大字节数：
以下是一些可以为 Ceph OSD 守护进程配置的文件存储设置：
当你想要性能过度恢复时，应该使用这些设置，反之亦然。如果您的 Ceph 集群运行状况不佳并且正在恢复，您可能无法获得正常的性能，因为 OSD 将忙于恢复。如果您仍然更喜欢性能而不是恢复，您可以降低恢复优先级以减少 OSD 被恢复占用的情况。如果您想快速恢复集群，也可以设置这些值，帮助 OSD 更快地执行恢复：
OSD 回填设置允许 Ceph 将回填操作设置为低于 read 和 write :
OSD 清理对于维护数据完整性很重要，但它会降低性能。您可以调整以下设置以增加或减少擦洗操作：
客户端调优参数应在 [client] 部分下定义你的 Ceph 配置文件。通常，这个 [client] 部分也应该出现在客户端节点上托管的 Ceph 配置文件中。参数如下：
在上一个秘籍中，我们介绍了 Ceph MON、OSD 和客户端的调优参数。在这个秘籍中，我们将介绍一些可以应用于操作系统的通用调优参数，如下所示：
假设磁盘 vda 是一个安装在客户端节点上的 RBD。使用以下命令检查它的 read_ahead值，这是大多数情况下的默认值：
设置 read_ahead为更高的v值，即8 MB 对于 vda RBD，执行以下命令：
read_ahead 设置用于使用挂载 RBD 的 Ceph 客户端。要获得 read 性能提升，您可以将其设置为数 MB，具体取决于您的硬件和所有 RBD 设备。
虚拟内存：D由于高度关注 I/O 的配置文件，使用交换会导致整个服务器变得无响应。对于高 I/O 工作负载，建议使用较低的 swappiness 值。设置 vm.swappiness 到0 in / etc/sysctl.conf 为了防止这种情况：
执行以下命令检查磁盘设备的默认I/O调度程序sda（默认调度程序应出现在方括号内）：
将 sda 磁盘的默认 I/O 调度程序更改为 deadline：
将磁盘的默认 I/O 调度程序更改为 noop：
要检查 sda 块设备的调度程序深度，请使用以下命令：
要将调度器深度增加到 1024，请使用以下命令：
负载 MTU 超过 1,500 字节的以太网帧称为巨型帧。在 Ceph 用于集群和客户端网络的所有网络接口上启用巨型帧应该可以提高网络吞吐量和整体网络性能。
应该在主机和网络交换机端启用巨型帧，否则，MTU 大小不匹配会导致丢包。要在接口 eth0 上启用巨型帧，请执行以下命令：
同样，您应该对参与 Ceph 网络的其他接口执行此操作。要使此更改永久生效，您应该在接口配置文件中添加此配置。
在日常 I/O 工作负载和恢复/重新平衡场景中，适当的调优可以极大地提高集群的性能。让我们看看为您的 OSD 节点设置推荐的调优配置文件：
以下屏幕截图中显示了一个示例：
以下屏幕截图显示了一个示例：
有关这些值的更多信息，请参阅：https://www.kernel.org/doc/文档/sysctl/。
Ceph 中的默认数据保护机制是复制。它已被证明是最流行的数据保护方法之一。然而，复制的缺点是它需要双倍的存储空间来提供冗余。例如，如果您计划构建一个具有 1 PB 可用容量且复制因子为 3 的存储解决方案，则您需要 3 PB 的原始存储容量才能获得 1 PB 的可用容量，即 200% 或更多。这样，通过复制机制，存储系统的每GB成本显着增加。对于小型集群，您可能会忽略复制开销，但对于大型环境，它变得很重要。
Ceph 的 Firefly 版本引入了另一种称为擦除编码的数据保护方法。这种数据保护方法与复制方法完全不同。它通过将每个对象划分为称为数据块的更小块、使用编码块对它们进行编码、最后将所有这些块存储在 Ceph 集群的不同故障区域中来保证数据保护。纠删码的概念围绕着方程n = k + m。这在以下列表中进行了解释：
根据前面的等式，纠删码 Ceph 池中的每个对象都将存储为 k+m 个块，每个块存储在一个唯一的 OSD 中一套表演。这样，一个对象的所有块都分布在整个 Ceph 集群中，提供了更高程度的可靠性。现在，让我们讨论一些有关擦除编码的有用术语：
可靠性级别：借助纠删码，Ceph 可以容忍多达 m 个块的故障。
编码率 (r)： 这可以使用公式 r = k / n 计算，其中 r 小于 1 需要存储.这是使用公式 1/r.
为了更好地理解这些术语，我们来看一个例子。根据纠删码(3, 2) 规则，创建了一个带有五个 OSD 的 Ceph 池。存储在此池中的每个对象都将按照以下公式划分为数据集和编码块：n = k + m.
考虑 5 = 3 + 2，然后 n = 5、k = 3 和 m = 2。每个对象将被划分为三个数据块，并在其中添加两个额外的纠删码块，总共五个块将存储和分布在 Ceph 集群中纠删码池的五个 OSD 上。在失败的情况下，要 构造我们需要的原始文件（ k 个块）， 中的三个块（n 个块），和五个块来恢复它。因此，我们可以维持一个y（m）两个OSD的故障，因为数据可以使用恢复三个 OSD：
假设有一个大小为 1 GB 的数据文件。要将此文件存储在纠删码 (3, 5) 池上的 Ceph 集群中，您将需要 1.6 GB 的存储空间，这将为您提供具有两个 OSD 可持续性的文件存储失败。
与复制方式相比，如果同一个文件存储在一个复制池中，那么为了维持两个 OSD 的故障，Ceph 需要一个副本大小为 3 的池，最终需要 3 GB 的存储空间才能可靠地存储 1 GB 的文件。这样一来，您可以通过使用 Ceph 的纠删码功能将存储成本降低约 40%，并获得与复制相同的可靠性。
与复制池相比，纠删码池需要更少的存储空间，但是，此存储节省元素是以性能为代价的，因为纠删码过程将每个对象分成多个较小的数据块，并且一些较新的编码块与这些数据块混合在一起。最后，所有这些块都存储在 Ceph 集群的不同故障区域中。这整个机制需要来自 OSD 节点的更多计算能力。而且，在恢复的时候，解码数据块也需要大量的计算。因此，您可能会发现用于存储数据的纠删码机制比复制机制要慢一些。纠删码主要取决于用例，您可以根据您的数据存储要求充分利用纠删码。
Ceph 为我们提供了在创建纠删码配置文件时选择纠删码插件的选项。每次可以使用不同的插件创建多个纠删码配置文件。选择正确的配置文件很重要，因为它在创建池后无法修改。为了更改配置文件，需要创建一个具有不同配置文件的新池，并将前一个池中的所有对象移至新池。 Ceph 支持以下用于擦除编码的插件：
LRC 旨在从丢失单个 OSD 中恢复时降低带宽。如前所述，每四个数据块 (K) 生成一个本地奇偶校验块 (L)。当 K3 是lost，而不是从所有[(K+M)-K3] 个块中恢复，即11个块，用LRC，从 K1、K2、K4、L1 chun<跨度>ks.
带状纠删码插件：本地代表适用于单个 OSD 故障。对于多个 OSD 故障，LRC 的恢复开销很大，因为它必须使用全局奇偶校验 (M) 进行恢复。让我们重新考虑前面的场景，假设丢失了多个数据块 K3 和 K4。要使用 LRC 恢复丢失的块，需要从 K1、K2、L1（本地奇偶校验块）和 恢复M1（全局奇偶校验块）。因此，LRC 涉及多磁盘故障的开销。
为了解决这个问题，Shingle Erasure Code (SHEC) <跨度><跨度>已被引入。 SHEC 插件封装了多个 SHEC 库，让 Ceph 能够比 Jerasure 和 LRC 更高效地恢复数据。 SHEC 方法的目标是有效地处理多个磁盘故障。在这种方法下，局部奇偶校验的计算范围已经改变，并且将对它们之间的重叠（如屋顶上的瓦片）进行奇偶校验以保持耐久性。
让我们通过示例SHEC (10,6,5)来理解这一点，其中K=10（数据块），m =6（奇偶校验块）和 l=5（计算范围）。在这种情况下，SHEC 的图示如下：
回收效率是 SHEC 的最大特点之一。它最大限度地减少了恢复期间从磁盘读取的数据量。如果块 K6 和 K9 丢失，SHEC 将使用 M3 和 M4 奇偶校验块，并且 K5、K7、K8 和 K10 数据块用于恢复。下图中也说明了这一点：
对于多磁盘故障，SHEC 有望比其他方法更有效地恢复。在双盘故障的情况下，SHEC 的恢复时间比 Solomon 代码快 18.6%。
擦除代码是通过创建擦除类型的 Ceph 池来实现的。该池基于定义纠删码特征的纠删码配置文件。我们将首先创建纠删码配置文件，然后我们将基于此配置文件创建纠删码池。
以下步骤将向您展示如何创建 EC 配置文件，然后将该配置文件应用到 EC 池。
本节中提到的命令将创建一个名为 EC-profile 的纠删码配置文件，该配置文件将具有 k=3 和 m=2 的特征，分别是数据和编码块的数量。因此，每个存储在纠删码池中的对象将被划分为 3 个（k）个数据块，并在其中添加 2 个（m）个额外的编码块，总共制作了 5 (k + m) 个块。最后，这 5 (k + m) 个块分布在不同的 OSD 故障区域：
这显示在以下屏幕截图中：
检查新创建的池的状态；你应该发现池的大小是5 (k + m)，也就是擦除大小。因此，数据将被写入五个不同的 OSD，如下图所示：
如果你观察输出，你会注意到object1存放在placement group中 2.c，依次存储在 EC 池。你还会注意到归置组存储在五个OSD上，即osd.2、osd.8 、osd.0、osd.7 和 osd.6。如果您返回第 1 步，您将看到我们创建了 (3,2) 的纠删码配置文件。这就是为什么 object1 存储在五个 OSD 上的原因。
在这个阶段，我们已经完成了在 Ceph 集群中建立一个纠删池。现在，我们将刻意尝试破坏 OSD，以查看当 OSD 不可用时擦除池的行为。
关闭 osd.2 并检查 EC-pool 和object1的OSD映射。您应该注意到 osd.2 被替换为单词 NONE, w这意味着 osd.2 不再可用于此池：
如下截图所示：
现在，EC-pool 运行在三个 OSD 上，这是设置的最低要求擦除池。如前所述， EC-pool 将需要五个块中的任意三个块才能读取数据.现在，我们只剩下三个块了，分别是 on osd.0、osd.7 和 osd.6，我们仍然可以访问数据。让我们验证读取的数据：
Ceph 强大的架构极大地受益于纠删码功能。当 Ceph 检测到任何故障区域不可用时，它就会开始其基本的恢复操作。在恢复操作期间，擦除池通过将失败的块解码到新的 OSD 上来重建自己，然后，它们会自动使所有块可用。
在上面提到的最后两个步骤中，我们打算最终破解了osd.2和osd.8< /kbd>。一段时间后，Ceph 将启动t 恢复并将丢失的块重新生成到不同的 OSD 上。恢复操作完成后，您应该检查 EC-pool 和 object1 的 OSD 映射。您会惊讶地看到新的 OSD ID 为 osd.1 和 osd.3。因此，an 擦除池在没有管理输入的情况下变得健康，如以下屏幕截图所示：
<span>与纠删码一样，Ceph Firefly 版本中也引入了缓存分层功能。对于存储在缓存层中的数据子集，缓存层为 Ceph 客户端提供了更好的 I/O 性能。缓存分层会在速度更快的磁盘（通常是 SSD）之上创建一个 Ceph 池。这个缓存池应该放在一个常规的、复制的擦除池之前，这样所有的客户端 I/O 操作都由缓存池首先处理；稍后，数据被刷新到现有的数据池中。客户端享受高速缓存池的高性能，而他们的数据透明地写入常规池。下图说明了 Ceph 缓存分层：
缓存层构建在昂贵、速度更快的 SSD/NVMe 之上，从而为客户端提供更好的 I/O 性能。缓存层由存储层备份，该存储层由具有复制或擦除类型的 HDD 组成。整个客户端 I/O 请求进入缓存层并获得更快的响应，无论是 read 还是 write;更快的缓存层服务于客户端请求。根据我们为缓存层创建的策略，它会将其所有数据刷新到后备存储层，以便它可以缓存新请求来自客户。缓存层和存储层之间的所有数据迁移都是自动发生的，并且对客户端是透明的。缓存分层代理处理缓存层和存储层之间的数据迁移。 管理员可以配置迁移的发生方式.有两种主要场景，我们将在以下部分讨论。
当 Ceph 缓存分层配置为 writeback 模式时，Ceph 客户端将数据写入缓存层池，即更快的池，因此会立即收到确认。根据您为缓存层设置的刷新/驱逐策略，数据从缓存层迁移到存储层，并最终由缓存分层代理从缓存层中删除。在客户端的 read 操作期间，缓存分层代理首先将数据从存储层传输到缓存层，然后将其提供给客户端。数据将保留在缓存层中，直到它变为非活动或冷态。 writeback 模式的缓存层非常适合可变数据，例如照片或视频编辑、事务数据等。 writeback 模式非常适合可变数据。
当 Ceph 缓存分层配置为 只读 模式时，它仅适用于客户端的 读取 操作。 write 操作在此模式下不处理，它们存储在存储层中。当任何客户端执行 read 操作时，缓存分层代理将请求的数据从存储层复制到缓存层。根据您为缓存层配置的策略，从缓存层中删除过时的对象。当多个客户端需要读取大量类似数据（例如社交媒体内容）时，这种方法非常理想。不可变数据非常适合只读缓存层。
为了充分利用 Ceph 的缓存分层功能，您应该使用更快的磁盘（例如 SSD），并在由 HDD 组成的较慢/常规池之上创建一个快速缓存池。在 章节9, Ceph Under the Hood, 我们介绍了 p 通过修改 CRUSH 图在特定 OSD 上创建 Ceph 池的过程。要在您的环境中设置缓存层，您需要首先修改您的粉碎图并为 SSD 磁盘创建一个规则集。因为我们已经在 第 9 章< /a>，引擎盖下的 Ceph，< span>在特定 OSD 上创建 Ceph 池 配方我们将使用基于 osd.0、osd.3 和 osd.6 。由于这是一个测试设置，我们没有真正的 SSD，我们假设 OSD 0、3 和 6 是 SSD，并将在它们之上创建一个缓存池，如下图所示：< /span>
让我们使用命令 ceph osd crush rule ls 检查 CRUSH 布局，如以下屏幕截图所示。我们已经有了在 第 9 章，引擎盖下的 Ceph，在特定 OSD 上创建 Ceph 池配方。您可以通过运行 ceph osd crush rule dump ssd-pool 命令获取有关此 CRUSH 规则的更多信息：
我们现在将创建一个用于缓存分层的池：
如下截图所示：
在上一个秘籍中，我们创建了一个基于 SSD 的池 cache-pool。我们现在将使用这个池作为我们在本章前面创建的纠删码池 EC-pool 的缓存层：
接下来的说明将指导您使用写回模式创建缓存层以及如何使用 EC 池设置覆盖层。
按照这组步骤，我们将为我们的纠删码池创建一个缓存层：
一个缓存层有几个定义缓存层策略的配置选项。在发生回写的情况下，需要此缓存层策略将数据从缓存层刷新到存储层。在只读缓存层的 e 情况下，它将数据从存储层移动到缓存层。在这个秘籍中，我尝试使用写回模式来演示缓存层。这些是您应该为您的生产环境配置的一些设置，根据您的要求使用不同的值。
现在我们已经配置了缓存层，我们需要为缓存池设置一些推荐的配置选项：
如下截图所示：
如下截图所示：
如下截图所示：
完成这些步骤后，Ceph 缓存分层设置应该完成，您可以开始向其中添加工作负载。
如下截图所示：
因为我们的缓存层已经准备好了，在write操作期间，客户端会看到正在写入他们的常规池的内容，但实际上，它正在被写入缓存-< /span>先存储池，然后根据缓存层策略数据，将其刷新到存储层。这种数据迁移对客户端是透明的。
这显示在以下屏幕截图中：
这显示在以下屏幕截图中：
如果您仔细查看步骤 3 和 4，您会注意到数据已从 cache-pool 迁移在一定时间后发送到EC-pool，对用户完全透明。< /span>
在任何类型的生产用例中部署缓存分层之前，应进行适当的全面测试，以验证缓存分层功能不会导致异常性能问题。众所周知，缓存分层会降低大多数客户端工作负载中的读/写性能，应仅谨慎使用：
缓存分层在使用 RGW 时很有用，并且 RGW 工作负载包含针对最近写入或经常访问的对象的大部分读取操作。此用例中的缓存分层（在可配置的时间段内将对象保存在更快的层中）实际上可能会提高性能。
以下是已知的不良工作负载：
具有复制缓存和纠删码基础的 RBD：适当倾斜的工作负载仍会一次又一次地向冷对象发送写入。由于缓存层仍然不支持小写入，因此必须将整个 4 MB 对象提升到缓存层以满足较小的写入。极少数用户部署了这种配置，它之所以成功，是因为他们的用例是备份数据，这些数据保持冷态并且对性能不敏感。
带有复制缓存和基础的 RBD：当使用带有复制基础的 RBD 时，当基础是纠删码时，层可以更好地执行，但这仍然很大程度上取决于工作负载中存在的偏斜和很难确定。此用例需要对工作负载有非常好的了解，并且必须正确仔细地调整和配置缓存分层。