Ceph 和 Mirantis OpenStack

scuttlemonkey

上周 Dmitry Borodaenko 在首届 硅谷 Ceph 用户组会议 上发表了关于 Ceph 和 OpenStack 的演讲。会议出席人数众多，Mellanox 的 Eli Karpilovski 和 Inktank 的 Kyle Bader 也发表了演讲。但是，如果您无法参加，以下 Dmitry 演讲的记录可以很好地回顾一下，并及时为 Mirantis / Inktank 联合举办的 Ceph 和 OpenStack 网络研讨会 做准备。

[转载自 Mirantis.com]

要了解 Ceph 如何作为 Mirantis OpenStack 的一部分工作，我们需要首先从 20,000 英尺的高度进行概览。您需要了解 Ceph 是什么，OpenStack 是什么，以及它们可以做什么。然后，我们将深入研究使这种组合真正发挥作用的细节。首先，我们将解释 Ceph 的由来以及它最终成为什么。

Ceph 是什么？

定义 Ceph 比你想象的要复杂。当我第一次听说它时，它被称为文件系统，但实际上它还没有完全达到那个水平。另一方面，它远不止于此。Ceph 是一个免费的集群存储平台，提供统一的对象、块和文件存储。

不知何处，它增加了一个对象存储后端，而事实证明这比它存储文件的能力更重要。此外，Ceph 还添加了一个块存储层，它也使用对象作为后端来提供 RBD 块设备，这对于 OpenStack 来说是最有趣的。

重申一下，Ceph 由以下部分组成

  • 对象存储。RADOS 对象支持快照、复制和一致性。
  • 块存储。RBD 块设备在 RADOS 对象之上进行稀疏配置，可以通过 librbd 库通过 QEMU 访问，如图所示。

图 1 Ceph 块存储

  • 文件存储。CephFS 元数据服务器 (MDS) 在 RADOS 上提供符合 POSIX 标准的覆盖。

现在，我们来谈谈 OpenStack。图 2 概述了几个核心组件，仅限于与 Ceph 可以为 OpenStack 提供的讨论相关的组件。

Mirantis OpenStack 是什么？

OpenStack 是一个开源云计算平台。

图 2 OpenStack 组件与 Ceph 相关

Nova 计算提供虚拟机，Cinder 为块设备或这些虚拟机提供卷。这些虚拟机基于从 Glance 获取的镜像。它们可以将对象存储在 Swift 对象存储系统中，Swift 也可以用作 Glance 的存储后端。

Mirantis OpenStack 基本上是一组经过加固的 OpenStack 包，包含在一个不错的工具中，可以开箱即用地进行简化安装，并具有各种不同的、相当复杂的配置，包括使用 Ceph 代替所有其他存储的配置。

Mirantis 提供 Fuel 实用程序来简化 OpenStack 和 Ceph 的部署。Fuel 使用 Cobbler、MCollective 和 Puppet 来发现节点、配置操作系统以及设置 OpenStack 服务，如图所示。

图 3 Fuel 正在运行

如您所见，我们使用 Cobbler 配置节点，然后使用 MCollective 和 Puppet 来发现它们并分发 Puppet 清单，并使用这些 Puppet 清单设置 OpenStack。

Ceph 如何融入 OpenStack？

RBD 驱动程序用于 OpenStack，使 libvirt 配置 QEMU 接口到 librbd。

那么 Ceph 如何融入 OpenStack？很简单，RADOS 块设备，或者简称 RBD，Ceph 对象存储之上的块设备层，具有用于 QEMU 的驱动程序。OpenStack 具有用于 RBD 的驱动程序，这些驱动程序使 libvirt 告诉 QEMU 使用 RBD 后端来满足其所有存储需求。下一个图显示了此过程。

图 4 Ceph 如何融入 OpenStack

因此，您获得了很多。首先，与基本的 Cinder、基于 LVM 的后端不同，Ceph 提供了多节点冗余，因此，如果您丢失一个存储节点，存储在该节点上的卷不会消失，因为它们在其他地方具有副本。

另一个好处是，它允许您复制镜像和卷和实例。因此，一旦您获得了系统镜像，就可以在不进行任何不必要的数据复制操作的情况下，在不同的虚拟机上移动它并启动不同的虚拟机，从而加快速度并提高存储利用率。

还有一点是，由于 Ceph 允许您执行各种存储，例如块存储和对象存储，并且可以用作 Cinder、Nova 和 Glance 的后端，这意味着您的 OpenStack 云的所有存储需求都可以基于相同的存储池。因此，相同的硬盘驱动器可以根据需要分发到您的需求中，因此您不必拥有专用的对象存储和块存储节点——所有这些都只是云或通用存储的一部分。

这就是我难以将 Ceph 称为文件系统的一个原因。它更像是一个平台，因为它只是提供存储，仅此而已。

最后，由于我们最近 Fuel 版本中完成的工作，您可以获得使用所有 Ceph 支持的实例进行实时迁移的功能。

总而言之，Ceph 的好处包括

  • 块存储（Cinder 卷和 Nova 临时驱动器）的多节点条带化和冗余

  • 镜像到卷和实例的复制写入克隆

  • 所有类型存储（对象、块和 POSIX）的统一存储池

  • Ceph 支持的实例的实时迁移

但是，Ceph 并不是解决所有问题的万能药。它仍然存在一些需要克服的问题。这些问题是

  • Ceph 对时钟漂移非常敏感。如果您想使用 Ceph，最好确保您的基础设施坚如磐石。如果您不这样做，您的服务器会失去同步，并且您的集群会崩溃。

  • 多站点支持。与 Swift 长期以来就具有多站点支持不同，Ceph 只有在最新版本名为 Emperor 的版本中才具有异步复制功能。在此之前，Ceph 仅支持同步复制，而同步分类意味着您无法在长距离链路上传播复制，这意味着您无法在多个站点之间复制，这限制了 Ceph 的可用性。我们尚未尝试在 Emperor 中引入的异步复制，因此我无法告诉您它的工作效果如何，以及它是否适合不同的需求，但我们对此感到非常兴奋。

  • 块存储密度。与 Cinder 不同，Cinder 仅提供数据的单个副本，因此我们基本上可以 100% 利用所有硬盘驱动器，而使用 Ceph 您必须具有数据复制，这意味着您至少需要数据的两个副本。这意味着您的实际原始存储容量必须是数据集的两倍或三倍。一种解决这个问题的方法是在下一个迭代版本中，一个名为 Firefly 的工具中承诺使用擦除编码，这意味着您不必完全复制数据，而是可以使用擦除编码条带化，这将大大降低 Ceph 的数据乘数要求。与其是数据的两倍或三倍，您可以拥有 1.5 倍的数据，甚至 1.2 倍的数据。

  • Swift API 差距。如果您想将 Ceph 作为您的主要对象存储，那么一些 Swift API 将不会得到 100% 的支持，因为目前使用 Ceph 的 Swift API 的唯一方法是使用 RADOS Gateway，它是一个 Swift API 的实现。它不是 Swift 本身，因此必然存在一些差距。

这些都很好，但是 Fuel 与之有什么关系？

Fuel 曾经为 Ceph 做过什么？除了让 OpenStack 像魅力一样工作，并拥有所有这些加固的软件包并使其全部部署之外，Fuel 曾经为 Ceph 做过什么？Fuel 实际上包含 Puppet 清单和其他一些零零碎碎的东西，因此整个配置、配置、使用 Ceph 启用的 Mirantis OpenStack 的部署过程确保您最终获得部署为 OpenStack 环境一部分的 Ceph 集群，以及配置为使用 Ceph 作为存储后端的 OpenStack 组件。因此，它会为 OSD 节点创建分区。它也可以创建通用分区。它设置不同 OpenStack 组件的身份验证，这些组件具有自己的存储池。它配置这些组件以使用正确的池和正确的凭据。它设置 RADOS Gateway，甚至可以将其置于 HAProxy 后面，以便它们实际上是高可用的。

因此

  1. Fuel 在专用节点或与 OpenStack 组件组合中部署 Ceph 监视器和 OSD。

  1. 在配置节点时创建 OSD 的分区。

  2. 为 Cinder、Glance 和 Nova 创建单独的 RADOS 池并设置 Cephx 身份验证。

  3. 配置 Cinder、Glance 和 Nova 以使用正确的池和凭据的 RBD 后端。

  4. 在控制器节点上部署 RADOS Gateway（S3 和 Swift API 前端到 Ceph）。

它看起来怎么样？

这里有一些关于在 Fuel 中配置 Ceph 的屏幕截图。

图 5 在 Fuel 中配置 Ceph：选择存储选项 ⇒ 将角色分配给节点 ⇒ 分配磁盘

您从设置存储设置开始，因此您单击一些复选框，将 Ceph 粘合到 Cinder、Glance、Nova、对象存储（如果您愿意）。您发现一些节点。您将一些角色分配给这些节点。其中一个角色是 Ceph OSD。正如我提到的——或者实际上没有提到，无论如何，我们还没有一个单独的 Ceph 监视器角色，所以——但是默认情况下只是将 Ceph 监视器放在控制器上。因此，无论您拥有哪些控制器节点，它们不仅具有 OpenStack 控制器组件；它们还将监视和管理 Ceph 集群。

而且，最终一步实际上你不需要做，但如果你想微调性能或者你还没有分配磁盘布局，你可能想配置你的磁盘存储。屏幕上最上面的截图显示了如果没有进行任何调整，只是让 Fuel 自动完成，具有多个磁盘的系统默认布局。默认情况下，我们会将所有分区放在第一个驱动器中，除了 Ceph，它会获得所有剩余的驱动器仅用于 OSD 存储。你可以做的是——实际上你可能想使用几个 SSD 驱动器，具体取决于你的存储节点有多少个硬盘驱动器，并将这些 SSD 驱动器、服务器专门用于通用设备。正如你所看到的，有一个存储角色或分区角色列表，你可以分配给不同的驱动器。你可以简单地更改它们的分配，从 Ceph 到 Ceph General，例如，“好的，该设备将是通用的”。

接下来，我们将讨论我们为使其工作所做的一些小事情。

我们所做的事情

表面上看，一切都非常简单：分区驱动器，告诉 Ceph 你的驱动器在哪里，构建 Ceph 集群，配置 OpenStack 使用该集群——完成。正如我们发现的，事情并不完全如此简单。有很多小事情需要做，这些事情记录在不同的地方或者根本没有记录，所以我只是想把它们放在一个地方供所有听众参考。

  1. 为 udev 自动挂载规则设置 OSD 和日志分区正确的 GPT 类型 GUID

但我们发现的第一件事之一——不是第一件事，但你必须做的第一件事之一是确保你的 OSD 分区具有正确的分区类型，否则你的 OSD 在重新启动时将无法自动启动。问题是，除非你真的想将所有 OSD 设备都添加到 FS 选项卡中，否则它们不会在重新启动时自动启动。但是 Ceph 提供了 udev 自动挂载规则，这些规则查找特定的 GPT 分区 GUID 并将它们自动挂载为 OSD 设备和日志。不幸的是，目前唯一记录这些内容的地方是源代码或 Ceph 磁盘。

  1. ceph-deploy：设置 Ceph 节点之间的 root SSH

我们做的另一件事是，为了使 Ceph deploy 正常工作，我们显然必须在所有节点之间配置 SSH，所以我们——Fuel 为你做的事情之一是生成 SSH 密钥并在节点之间分发这些密钥，以便节点可以相互通信。

  1. 基本的 Ceph 设置：cephx、池大小、网络

显而易见的是，你必须有一个基本的 Ceph 配置。你必须有 Cephx 身份验证密钥，配置你的复制因子，告诉 Ceph 使用哪些网络，等等。

  1. Cephx：ceph auth 命令行不能拆分

我们发现的另一个小问题是，当你使用 Cephx 命令行在脚本中使用时，永远不要将它们拆开，因为 Ceph auth 中存在一个错误，它无法处理意外的空格类型。这样说吧。

  1. Rados Gateway：必须使用 Inktank 的 FastCGI 分支，为 UUID 身份验证令牌工作设置无限的撤销间隔

RADOS Gateway 也有些挑剔。它使用 FastCGI，但不是任何 FastCGI。它必须是——它是 Inktank 分支的 CGI，因为它具有一些从未合并到上游的错误修复。另一件事是，虽然它可以将 PPI 作为自签名证书进行身份验证，但默认设置加起来比你希望自动化工具所做的事情要多。你想要你自己的 PPI 管理基础设施。你想要你的证书颁发机构或至少是适当的证书代理签名。因此，Fuel 不会尝试为你做所有这些。因此，默认情况下，它使用 UUID 身份验证令牌进行设置，这些令牌易于管理且易于自动设置。但是 RADOS Gateway 不知道的是，如果你有 UUID 身份验证令牌，Keystone 中没有令牌验证，因此你必须将验证间隔设置为无限大的值，以免它妨碍。

  1. 修补 Cinder 以在从 Glance 创建基于 RBD 的卷时转换非原始图像

我们还必须对 Cinder 和 Nova 进行大量的修补，特别是 Nova，才能使 Ceph 作为所有事物的存储后端正常工作。例如，Cinder 不够聪明，无法知道如果你有一个除原始格式以外的任何格式的图像，你不能只是从该图像创建一个卷并期望该卷可用，因为 Ceph 只能使用原始卷。因此，我们为 Cinder 添加了一个补丁来检查图像的实际格式，以及如果它正在请求从非原始卷创建图像，如何转换它。

  1. 修补 Nova：将基于 RBD 的 Glance 图像克隆到基于 RBD 的临时卷，将 RBD 用户传递给 qemu-img

我们还做了很多工作来调整临时 RBD，以便我们可以获得诸如从 Glance 图像直接启动实例时的写时复制之类的美好事物，而不仅仅是从 Cinder 卷启动，以便我们可以进行实时迁移。

  1. 临时 RBD：禁用 SSH 密钥注入，设置 Nova、libvirt 和 QEMU 以进行实时迁移

现在我们将重点放在 Ceph 的磁盘分区上。

Ceph OSD 的磁盘分区

正如我所说，Fuel 会自动完成 Ceph 的磁盘分区。它的工作方式如下（参见图 6）。

图 6 发现、配置、配置和部署期间磁盘分区信息的流程

首先，我们发现节点。节点启动到引导镜像，然后代理将有关节点的所有信息报告给 Fuel，包括其磁盘配置。因此，Fuel 能够将这些信息显示在 UI 中，以便用户可以将驱动器分配给特定角色所需的卷类型。如果你有一个 Ceph OSD 角色，那显然意味着 Ceph 有一个日志。它被归档到 Cobbler 通过 ks_spaces 变量中。这被一个脚本消耗，该脚本在 Cobbler 在配置期间运行，需要创建这些分区，并要求你的磁盘实用程序设置分区类型，实际设置这些身份验证模块。所以，作为参考，如果你想了解更多关于 Ceph 的期望，请参考 Ceph 磁盘源代码，因为我们是在那里找到它们的。

ceph-disk 的 GPT 分区类型 GUID 为

JOURNAL_UUID = ’45b0969e-9b03-4f30-b4c6-b4b80ceff106 ’ OSD_UUID = ’4fbd7e29-9d25-41b8-afd0-062c0ceff05d ’

如果你有多个日志设备并且你有多个 OSD 驱动器，它将日志设备均匀地分配到 OSD 之间，以便你的 SSD 日志设备之间的负载均匀分布，并且你可以从集群中获得最大的收益。

Cephx 身份验证设置

我们为 Cephx 所做的身份验证比你在典型教程中找到的更高级，因为我们决定在身份验证安全性方面落实事情。因此，不是像 OpenStack 组件的 Ceph 驱动程序通常期望的那样，只有一个名为 RBD 的池，我们有三个单独的池，每个池对应于每个具有 Ceph 驱动程序的组件。我们有一个用于图像、卷和实例的池。然后，你还需要权限。这是这些 Ceph 驱动器正常工作的绝对最低要求。

接下来，查看每个组件的脚本。

Monitor ACL 与所有 Cephx 用户相同

allow r

OSD ACL 因 OpenStack 组件而异

Glance：allow class -read object_prefix rbd_children ，

allow rwx pool=images

Cinder：allow class -read object_prefix rbd_children ，

allow rwx pool=volumes allow rx pool=images

Nova：allow class -read object_prefix rbd_children ，

allow rwx pool=volumes allow rx pool=images allow rwx pool=compute

注意：Cephx 很容易被 ceph auth 命令行参数中的意外空格所困扰，因此我们必须将它们全部放在同一行上。

现在我们来谈谈实时迁移。

使用 Ceph 进行实时 VM 迁移

我们发现的一件事有点令人困惑的是术语。像 OpenStack 特别是 libvirt 支持的迁移类型有很多种，这就是所有这些词的含义，这样你就可以理解我说的使用 Ceph 支持的实时迁移是实时的、基于卷的、原生的、对等互连的、管理的。

表 1 VM 迁移类型

OpenStack

实时与离线：VM 在迁移期间是否停止？

块存储与共享存储与基于卷的存储：VM 数据是否在节点之间共享？VM 元数据（例如 libvirt 域 XML）是否共享？

Libvirt

原生与隧道：VM 状态是直接在超visor 之间传输还是通过 libvirtd 隧道传输？

直接与对等互连：迁移是由 libvirt 客户端控制还是由源 libvirtd 控制？

管理与未管理：迁移是由 libvirt 控制还是由超visor 本身控制？

我们的类型

实时、基于卷*、原生、对等互连、管理。

* Nova 实际上认为它被称为共享存储，但它对共享存储的定义感到困惑，直到我们修补了这种困惑。

实时迁移意味着 VM 不需要停止。它是基于卷的——VM 的临时卷在计算节点之间共享。显然是共享的，因为它在 Ceph 集群中。它是原生的——我们使用 QEMU 使用 QEMU 到 QEMU 连接来传输 ZVM 状态在计算节点之间。它是对等互连的——我们没有让 libvirt 客户端与两个计算节点通信。我们在一个计算节点上启动它，并且该源计算节点负责管理迁移。并且它是管理的——libvirt 监督迁移过程，而不是将其交给 VM 并且不关心接下来会发生什么。

因此，你有 VM，Nova 告诉 libvirt 开始迁移，libvirt 告诉 QEMU，“好的，这里是一个连接到远程节点的 URL。转让状态，这里是硬盘——这里是 VM 配置以供使用。”该 VM 配置被传输到节点，到目标节点，它拾取了通过 QEMU 连接迁移的 VM。我们还设置了标志以在目标节点上持久化 VM，并在源节点上归档它，以便如果任何一个节点达到其迁移状态，迁移状态仍然迁移，以便 VM 不会重定向回源节点。

因此，我们更改了一些不太明显的事情。其中一件事情是，Nova 倾向于假设如果它不是基于 Cinder 卷的 VM 正在迁移，它必须与共享卷一起共享实例元数据。所以我们不得不解耦它并说，“好的，对于具有共享临时卷的 VM 迁移是合法的，该卷不是 Cinder 支持的。它只是一个临时驱动器，Ceph 支持的。”但是——libvirt 元数据，libvirt XML 不在 NFS 中。它不是共享的。它必须从一个节点传输到另一个节点。

Nova 的另一个烦人的事情是，它不会在迁移 VM 时更新 VNC 侦听地址。因此，广泛记录的解决方法是必须将 VNC 地址设置为全零，这意味着任何人都可以连接到任何计算节点上的 VNC。所以我们不得不添加一个空表行来限制从公共网络对该计算节点的管理，整个世界都无法与你的 VNC 通话。

最后，你必须打开临时端口 49152。实际上，你必须打开 QEMU 迁移的端口范围。单个端口是不够的，因为对于正在进行的每个迁移，QEMU 都会在范围内打开一个不同的端口。你拥有的节点越多，你期望迁移的 VM 越多，你需要的开放端口就越多。

总而言之，你

启用原生对等互连实时迁移

图 7 启用原生对等互连实时迁移

libvirt VIR_MIGRATE_* 标志：LIVE、PEER2PEER、UNDEFINE_SOURCE、PERSIST_DEST

  • 修补 Nova 以在实时迁移期间解耦共享卷与共享 libvirt 元数据逻辑

  • 将 VNC 侦听地址设置为 0.0.0.0 并通过 iptables 阻止 VNC 从管理网络外部访问

  • 为 QEMU 迁移在计算节点之间打开端口 49152+

我们未完成的事情

还有很多事情我们没有时间去做，比如在所有节点之间设置 root SSH。从技术上讲，你不需要 root SSH。你可以连接一个非 root 用户并使用 sudo，但是，如果你想要，你可以相对容易地输入它。

我们也不做的是——现在我们只是硬编码 PG 数字，这是池条带的尺寸信息，从技术上讲，应该基于 OSD 的数量。但是由于 Fuel 以开放式方式安装 OpenStack，它允许你在部署完成后任意地扩展或缩小规模，我们不想做出错误的假设。所以你实际上必须根据你的集群大小和工作负载来调整它。

我们实际上计划尽快修复的一个问题是，目前 Fuel 对不同流量类型具有某种硬编码的网络角色，并且我们只有一个存储网络。这意味着 Ceph，它有两个用于流量的网络，一个用于 Glance 服务器流量，一个用于应用程序流量，必须将两种类型的流量都放在存储网络上，或者将一种类型的流量放在存储网络上，将另一种类型的流量放在管理网络上。因此，根据你的网络配置部署，这意味着你必须做出一些妥协，直到 Fuel 支持不同类型的任意数量的网络。

我们没有开箱即用的一件事，我们可能也应该在下一个版本中这样做，就是确保所有 Ceph 监视器都列在每个 Ceph 节点的 Ceph.conf 中。现在我们所做的是只获取主监视器。这使得扩展到更多监视器变得更加简单——好吧，基本上与 PG 数字相同的妥协。一旦你完成了部署，将这些监视器列出就必须是过程的一部分。

还有一件事，如果你云非常大，你可能还需要专门的监控。实际上，我们的 Puppet 清单已经准备好执行此操作。它期望 Ceph 1 作为它自己的节点角色，但 Fuel 的其余部分没有定义这样的角色，因此你必须对 Puppet 清单进行一些手动部署和调整才能使其工作。但这可以做到。拥有像 Fuel 的其余部分一样漂亮的 GUI 会更好。

我们开始做但没有集成到 Fuel 中的一件事是 Cinder 的多后端配置。因此，Cinder 实际上支持在并行拥有多个存储后端。所以你可以拥有——在同一个 OpenStack 环境中，你有一些 Cinder LVM 节点和 Ceph 集群，并且你可以选择对于任何给定的卷，你想要使用 LVM 还是 Ceph。好吧，我们 Fuel 清单现在只有——支持一个选项。你使用 LVM 或你使用 Ceph，对于大多数情况来说应该足够了，但对于某些情况，你必须再次对 Cinder 配置进行一些调整才能使其为你工作。无论如何，这不应该太难。

还有一件事是——有点难看，虽然我想——好吧，它有效，但为了让任何支持 Ceph 的 OpenStack 组件都知道要转到哪个池，你必须通过 init 脚本传递一个环境变量，这实际上不是正确的方法。你确实在 RBD 驱动程序中有一个配置变量，它告诉你应该使用哪个池。但事实证明它不够。希望这将在即将发布的 OpenStack 版本中得到解决。

我之前提到过的一点是，Nova 不会更新 VNC 监听地址。所以实际上这不应该太难，一旦我们有时间处理，或者如果其他人来处理，自动将其更新为目标节点管理地址，而不是依赖于那个难看的 000 补丁，那将真的很好。

最后，我发现仍然存在一个用例，Ceph 驱动程序仍然在使用数据克隆。这是为了尝试仅克隆一个镜像。这个用例是快照一个 Ceph 备份的虚拟机。所以，如果您有一个从 Ceph 启动的虚拟机，它在 Ceph 中有其内部参数，并且您想要创建一个快照，而不是克隆该镜像，Nova 会调用 QEMU IMG，它会将镜像下载到本地存储，将其转换——即使它不需要从 raw 转换为 raw，然后将其上传回 Ceph。当然，如果不需要这样做就很好。

这是我们的待办事项的总结

  1. 用于 ceph-deploy 的非 root 用户和 sudo

  2. 根据 OSD 的数量计算 PG 数量

  3. Ceph 公共网络应该连接到第二个存储网络，而不是管理网络

  4. 专用监控节点，在每个 Ceph 节点上的 ceph.conf 中列出所有监控节点

  5. Cinder 的多后端配置

  6. 比 init 脚本中的 CEPH_ARGS 更好的配置 OpenStack 服务池的方式

  7. 在迁移后，使 Nova 更新 VM 的 VNC 监听地址为目标计算节点的 vncserver_listen

  8. 在 Nova 的 LibvirtDriver.snapshot() 中，将 ’qemu-img convert’ 替换为 clone_image()

诊断和故障排除

如何检查您的 Ceph 是否正常？如果出现问题，您该怎么办？哦，这里有一个非常、非常快速的烟雾测试，您可以在部署完成后进行，查看您的 Ceph + 是否正常，所有 OSD 设备是否在 OSD 树中，尝试创建一个卷，查看该卷是否创建成功，查看是否为您创建了所有其他池，以及当您创建卷实例时，数据是否显示在其中。检查您的其他池是否在那里，当您创建实例和卷时，数据是否显示在这些池中，最后尝试创建一个镜像并从该镜像启动一个实例，并将该实例迁移到另一个节点。如果所有这些都有效，那么您的环境基本上就可以投入压力测试了。

ceph -s ceph osd tree cinder create 1 rados df qemu - img convert -O raw cirros . qcow2 cirros .raw glance image - create --name cirros -raw --is - public yes \ --container - format bare --disk - format raw < cirros .raw nova boot -- flavor 1 --image cirros - raw vm0 nova live - migration vm0 node -3

您该怎么办

  • 在配置期间，磁盘分区失败。检查任何驱动器上是否留有先前分区表的痕迹

  • ’ceph-deploy config pull’ 失败。检查节点是否可以通过管理网络通过 ssh 连接到主控制器

  • HEALTH_WARN：检测到时钟偏差。检查您的 ntpd 设置，确保您的 NTP 服务器可以从所有节点访问

  • 在 RGW 中存储小对象时出现 ENOSPC。尝试设置较小的 rgw 对象条带大小

现在，以下是我们偶尔会看到发生的一些常见情况。首先，从配置到使用。首先可能发生的情况是您的 OSD 无法配置一些驱动器。我们添加了一些磁盘清理，所以不应该再发生这种情况了，但如果发生，如果您无法格式化驱动器，这意味着驱动器上留有一些 LVM 组或分区表的痕迹，您需要清理它们并重试部署。

另一个常见的错误是与 Ceph 相关的“ceph-deploy config pull 失败”，这实际上意味着您的网络很可能已损坏。如果您的节点无法通过 SSH 与主控制器通信，那么它将无法拉取 Ceph 配置，其余的部署将失败。

我之前警告过的一点是，您的 NTP 必须非常稳定。如果不是，您最终会收到时钟偏差检测到的健康警告，这意味着您的集群在最好的情况下会进入降级状态，甚至可能崩溃。好吧，在某些糟糕的情况下，我们已经看到它崩溃了。

最后，我们看到 Ceph 邮件列表中讨论了一个 ENOSPC 错误，如果使用 RADOS Gateway 在 Ceph 中存储大量小对象，则可能会发生这种情况。所以最终发生的情况是它使用了比所有对象组合大小更多的空间。解决此问题的一种方法是设置较小的条带大小，因为默认条带大小为四兆字节。所以，如果您的对象是 64K，您将为每个 64K 尝试存储而使用 4 兆字节。

资源

阅读文档

https://ceph.net.cn/docs/next/rbd/rbd-openstack/

[http://docs.mirantis.com/fuel/fuel-4.0/ http://libvirt.org/migration.html](http://docs.mirantis.com/fuel/fuel-4.0/ http://libvirt.org/migration.html)

https://docs.openstack.net.cn/admin-guide-cloud/contentch_introduction-to-openstack-compute.html

获取代码

Mirantis OpenStack ISO 镜像和 VirtualBox 脚本，

ceph Fuel 的 Puppet 模块，

Josh Durgin 的 havana-ephemeral-rbd 分支用于 Nova。

对 Nova 错误进行投票

#1226351, #1261675, #1262450, #1262914.

注册参加 Mirantis 和 Inktank 关于 Ceph 和 OpenStack 的网络研讨会。