在本章中，我们将介绍以下秘籍：
在前面的章节中，我们介绍了部署、配置和管理 Ceph 的不同方法。在本章中，我们将介绍对 Ceph 集群进行基准测试，这是在投入生产之前必须做的事情。我们还将介绍使用管理套接字、REST API 和 ceph-objectstore-tool 进行 Ceph 管理和故障排除的高级方法。最后，我们将学习 Ceph 内存分析。
在将 Ceph 集群用于生产工作负载之前对其进行基准测试应该是一个优先事项。基准测试可为您提供集群在读取、写入、延迟和其他工作负载期间的性能的大致结果。
在进行真正的基准测试之前，最好通过测量连接到集群节点的硬件（例如磁盘和网络）的性能来建立预期最大性能的基线。
磁盘性能基线测试将分两步完成。首先，我们将测量单个磁盘的性能，然后，我们将同时测量连接到一个 Ceph OSD 节点的所有磁盘的性能。
为了获得磁盘的读写性能，我们将使用 dd 命令与 oflag 设置为 direct 为了绕过磁盘缓存以获得真实的结果。
让我们对单磁盘写入性能进行基准测试：
理想情况下，您应该重复步骤 1 和步骤 2 几次并取平均值。在我们的例子中，写入操作的平均值为 121 MB/s，如下图所示：
下一步，我们将在节点上 Ceph 使用的所有 OSD 磁盘上运行 dd , ceph-node1, 获取单个节点的汇总磁盘写入性能。
让我们对多磁盘写入性能进行基准测试：
要获得汇总的磁盘写入性能，请取所有写入速度的平均值。就我而言，平均值为 127 MB/s：
为了获得单盘读取性能，我们再次使用 dd 命令。
让我们对单磁盘读取性能进行基准测试：
理想情况下，您应该重复步骤 1 和步骤 2 几次并取平均值。在我们的例子中，读取操作的平均值为 133 MB/s，如下图所示：
类似于单盘读取性能，我们将使用dd得到聚合的多盘读取性能.
让我们对多磁盘读取性能进行基准测试：
获取 Ceph OSD 使用的磁盘总数；就我而言，它是三个磁盘：
要获得聚合的磁盘读取性能，请取所有读取速度的平均值。就我而言，平均值为 137 MB/s：
根据我们执行的测试，结果将如下所示。这些结果因环境而异；您正在使用的硬件和 OSD 节点上的磁盘数量可以发挥很大作用：
| 操作 |
每磁盘 |
聚合 |
| 阅读 |
133 MB/s |
137 MB/s |
| 写 |
121 MB/s |
127 MB/s |
在这个秘籍中，我们将执行测试以发现 Ceph OSD 节点之间网络的基线性能。为此，我们将使用 iperf 实用程序。确保在 Ceph 节点上安装了 iperf 包。 iperf 是一个简单的点对点网络带宽测试器，适用于客户端-服务器模型。
要开始网络基准测试，请在第一个 Ceph 节点和客户端上使用服务器选项执行 iperf第二个 Ceph 节点上的选项。
使用 iperf，让我们获得集群网络性能的基准：
安装 iperf 在ceph-node1 和 ceph-node2:
这表明 Ceph 节点之间的网络连通性约为 2.15 Gbits/s。同样，您可以对 Ceph 集群的其他节点执行网络带宽检查。网络带宽实际上取决于您在 Ceph 节点之间使用的网络基础设施。
第 10 章，生产Ceph 的规划和性能调优，您可以在其中找到与 Ceph 网络相关的更多信息。
Ceph 附带一个称为 rados bench 的内置基准测试工具，可用于在池级别测量 Ceph 集群的性能。 rados bench 工具支持写入、顺序读取和随机读取基准测试，还可以清理临时基准数据，非常整洁。
让我们尝试使用 the rados bench 运行一些测试：
要对池 RDB 运行 10 秒的写入测试而不进行清理，请使用以下命令：
执行命令后我们得到如下截图：
您会注意到我的测试实际上运行了 17 秒的总时间，这是由于在 VM 上运行测试以及完成测试的写入 OPS 所需的时间延长。
rados bench 的语法如下：
语法可以解释如下：
rados bench 是一个非常方便的工具，可以快速测量 Ceph 集群的原始性能，您可以根据写入、读取和随机读取配置文件。
有点类似于rados bench，RADOS load-gen是Ceph 提供的另一个有趣的工具，开箱即用。顾名思义，RADOS load-gen 工具可用于在 Ceph 集群上生成负载，并可用于模拟高负载场景。
RADOS load-gen 的语法如下：跨度>
下面是前面命令的详细解释：
此命令将通过将 50 个对象写入 RBD 池来在 Ceph 集群上产生负载。这些对象和操作长度中的每一个都是 4 MB 大小，5% 的读取，测试运行时间为 60 秒：
为简洁起见，输出已被修剪。一旦 load-gen 命令完成，它会清理它在测试期间创建的所有对象并显示操作吞吐量：
您还可以使用 watch ceph -s 命令或 ceph -w;同时，RADOS load-gen 将运行，只是看看它是如何进行的。
工具，rados bench、和RADOS load-gen ，我们在上一个秘籍中讨论过，用于对 Ceph 集群池进行基准测试。在这个秘籍中，我们将专注于使用 rbd bench-write 工具对 Ceph 块设备进行基准测试。 ceph rbd 命令行界面提供了一个名为 < span>bench-write，这是一个在 Ceph Rados 块设备上执行写入基准测试操作的工具。
为了对 Ceph 块设备进行基准测试，我们需要创建一个块设备并将其映射到 Ceph 客户端节点：
如您所见，rbd bench-write 输出格式良好的结果。< /span>
rbd bench-write 的语法如下所示：
以下是前面语法的详细解释：
灵活 I/O（FIO）；它是最流行的生成 I/O 工作负载和基准测试的工具之一。 FIO 最近添加了对 RBD 的原生支持。 FIO 是高度可定制的，可用于模拟和基准测试几乎所有类型的工作负载。在这个秘籍中，我们将学习如何使用 FIO 对 Ceph RBD 进行基准测试。
要对 Ceph 块设备进行基准测试，我们需要创建一个块设备并将其映射到 Ceph 客户端节点：
由于 FIO 支持 RBD ioengine，我们不需要将 RBD 映像挂载为文件系统。要对 RBD 进行基准测试，我们只需提供将用于连接到 Ceph 集群的 RBD 映像名称、池和 Ceph 用户。创建具有以下内容的 FIO 配置文件：
完成后，FIO 会生成许多有用的信息，应仔细观察。但是，乍一看，您可能主要对 IOPS 和聚合带宽感兴趣，这两者都在上一个屏幕截图中突出显示。
第二章, < em>使用 Ceph 块设备，我们详细介绍了 Ceph 块设备的创建。
有关 FIO 的更多信息，请访问 https://github .com/axboe/fio.
Ceph 组件是守护进程和 Unix 域套接字。 Ceph 允许我们使用这些套接字来查询它的守护进程。 Ceph 管理套接字是在运行时获取和设置 Ceph 守护进程配置的强大工具。使用此工具，更改守护程序配置值变得容易得多，而不是更改需要重新启动守护程序的 Ceph 配置文件。
为此，您应该登录到运行 Ceph 守护进程的节点并执行 ceph 守护进程命令。
有两种方法可以访问管理套接字：
我们现在将尝试使用管理套接字访问 Ceph 守护进程：
另一种无需登录到该节点的开销即可更改 Ceph 守护程序的运行时配置的有效方法是使用 ceph tell< /span> 命令。
ceph tell 命令可以节省您登录到运行守护程序的节点的工作量。此命令通过监控节点，因此您可以从集群中的任何节点执行它：
Ceph 具有强大的 REST API 接口访问权限，可让您以编程方式管理集群。它可以作为 WSGI 应用程序或独立服务器运行，侦听默认端口 5000。它通过 HTTP 可访问的界面提供与 Ceph 命令行工具类似的功能。命令以 HTTP GET 和 PUT 请求的形式提交，结果可以 JSON、XML 和文本格式返回。在这个秘籍中，我将快速向你展示如何设置 Ceph REST API 并与之交互。
让我们配置并使用 Ceph REST API 来检查一些集群状态：
这是 ceph-rest-api 的基本实现。要在生产环境中使用它，最好将它部署在多个实例中，并使用 Web 服务器封装的 WSGI 应用程序，并且前端由负载平衡器完成。 ceph-rest-api 是一项可扩展的轻量级服务，可让您像专业人士一样管理 Ceph 集群。< /span>
内存分析是动态程序分析的过程，使用TCMalloc 确定程序的内存消耗并确定优化它的方法。在这个秘籍中，我们将讨论如何在 Ceph 守护进程上使用内存分析器进行内存调查。
让我们看看如何分析节点上运行的 Ceph 守护进程的内存使用情况：
Ceph 守护进程已经非常成熟，除非遇到导致内存泄漏的错误，否则您可能并不真的需要内存分析器进行分析。您可以使用前面讨论的过程来找出 Ceph 守护程序的内存问题。
Ceph 的关键特性之一是它的自我修复和自我修复特性。 Ceph 通过在不同的 OSD 保留多个归置组副本来做到这一点，并确保您不会丢失您的数据。在极少数情况下，您可能会看到多个 OSD 故障，其中一个或多个 PG 副本位于故障 OSD 上，并且 PG 状态变得不完整，从而导致集群运行状况中的错误。对于粒度恢复，Ceph 提供了一个低级 PG 和对象数据恢复工具，称为 ceph-objectstore-tool.
让我们来看看 ceph-objectstore-tool 的一些使用示例：
以下部分描述了您可以与 ceph-objectstore-tool:
移除一个归置组是一个有风险的操作，可能会导致数据丢失；请谨慎使用此功能。如果您在 OSD 上有一个损坏的归置组，阻止了 OSD 服务的对等或启动，那么在删除该归置组之前，请确保您在另一个 OSD 上拥有该归置组的有效副本。作为预防措施，在删除 PG 之前，您还可以通过将 PG 导出到文件来对其进行备份：
ceph-objectstore-tool 的语法是：
<options> 的值可以如下：< /span>
为了更好的理解这个工具，我们举个例子：一个pool对一个对象做了两份拷贝，PG位于osd.1 和 osd.2。此时如果发生故障，会出现如下顺序：
排查后发现可以从文件系统中读取osd.2数据，但是它的 osd 服务没有启动。在这种情况下，应该使用 ceph-objectstore-tool 从失败的 <跨度>osd。 ceph-objectstore-tool 为您提供足够的能力来检查、修改和检索对象数据和元数据。
从一开始，Ceph 就缺乏一个整体的健康检查工具，该工具很容易突出 Ceph 集群内部的问题。 ceph status 和 ceph health detail 命令存在，它们可以很好地提供整体集群运行状况详细信息，但如果存在更复杂的问题，则不会为用户指明任何具体方向。 ceph-medic 项目的创建允许运行单个命令来轮询 Ceph 集群上的多个预定义检查。这些检查范围从最佳实践建议到密钥环和目录所有权的验证。 ceph-medic 项目继续快速发展，并经常添加新的检查。
我们将使用以下步骤来安装和使用 ceph-medic：
ceph-medic 会将完整的日志文件输出到发出命令的当前工作目录。此日志比命令发送到终端的输出详细得多。可以使用 ~/.cephmedic.conf 中的 --log-path 选项修改此日志位置。
由于 ceph-medic 对整个集群执行检查，因此它需要知道集群中存在的节点以及对集群中节点的无密码 SSH 访问。如果你的集群是通过 ceph-ansible 部署的，那么你的节点已经配置好了，这不是必需的，如果没有，那么你需要将 ceph-medic 指向一个清单文件和 SSH 配置文件。
ceph-medic 命令的语法如下：
inventory 文件是一个典型的 Ansible inventory 文件，可以在运行 ceph-medic check 的当前工作目录中创建。该文件必须名为 hosts 并且支持以下标准主机组：mons、osds、rgws、< kbd>mdss、mgrs 和客户端。示例主机文件如下所示：
SSH 配置文件允许对特定帐户进行非交互式 SSH 访问，这些帐户可以在没有密码提示的情况下使用 sudo。该文件可以在运行 ceph-medic check 的工作目录中创建。 Vagrant VM 集群上的示例 SSH 配置文件如下所示：
BlueStore 是 Ceph OSD 守护进程的新后端。它的亮点是更好的性能（写入大约是 2 倍）、完整的数据校验和和内置压缩。与目前使用的 FileStore 后端相比，BlueStore 允许将对象直接存储在 Ceph 块设备上，而不需要任何文件系统接口。 BlueStore 是 Luminous (12.2.z) 版本的新默认存储后端，将在配置新 OSD 时默认使用。 BlueStore 在Jewel 中不被认为是生产就绪的，因此不建议以BlueStore 作为后端运行任何生产Jewel 集群。
BlueStore 的一些功能和增强功能包括：
OSD 可以通过 ceph-ansible 与 BlueStore 后端一起部署，我鼓励您在现有集群中使用 BlueStore 后端部署第二个 Ceph 集群或 OSD 节点，并比较本文前面描述的基准测试关于由 BlueStore 支持的 Ceph 集群或 OSD 节点的章节，您将看到 rados bench 测试的显着改进！
将 ceph-node4 安装为通过 ceph-ansible 带有 BlueStore 后端的 OSD 节点，您可以执行以下操作：
BlueStore 的输出如下：
Ceph-node4 现在已经成功部署了三个带有 BlueStore 后端的 OSD。集群中的其余 OSD 保留在 Jewel 默认的 FileStore 后端。随意使用本章提供的工具测试 BlueStore 后端和 FileStore 后端之间的性能比较！