我对 CephFS 在 OpenStack 中的看法

shan

我最近收到了一些非常有趣的问题，并引发了一些很好的讨论。由于我收到了两次相同的问题，我认为与社区分享这个问题会很好。

这个问题很简单，而且显然背景是关于 OpenStack

我可以使用 CephFS 存储我的虚拟机磁盘吗？

这个问题很公平，因为 Ceph 充当 OpenStack 的绝佳存储后端，并且在 Nova、Glance 和 Cinder 中得到了很好的实现。并且在每个稳定版本之后，它变得越来越好。对我来说，Ceph 绝对是 OpenStack 的事实上的存储。使用 CephFS 的主要目标是完全抽象 /var/lib/nova/instances，方法是将 CephFS 挂载到它上面。这对最终用户来说是透明的，这是一个操作员的选择。最终，你获得了 VM 磁盘的共享存储。听起来很棒，但每个人都知道 CephFS 还没有准备好。

在回答这个问题之前，我总是喜欢从文件系统的一点历史和遗留问题开始。我不会处理对共享集中化数据的需求。在这里，我只是想解释为什么人们在传统的计算环境中（面向 ISP）认为他们需要 DFS。分布式文件系统试图回答传统应用程序（通常是 Web 服务器，但也为底层存储带来高可用性）的主要问题。通常，你的前端有很多 Web 服务器访问相同的存储后端（这个古老的 NFS），其中包含网站的文件。由于应用程序的设计，Web 服务器需要能够同时访问所有文件（因为它使应用程序易于扩展），而 DFS 是一个很好的答案。这只是一个常见的用例，还有其他用例，例如将所有 VM 磁盘存储在共享存储上。这种方法带来了无可辩驳的好处，例如客户的 VM 高可用性和操作员的平滑维护（即使 DFS 有时对操作员来说可能是一个真正的难题）。

但是，如何在不使用 DFS 的情况下让每个人都满意呢？嗯？这真的可能吗？是的，是的！但是现在，让我们尝试专注于 CephFS 的用例。

粗略地说，当提出这个问题时，我总是建议不要使用 CephFS，而是使用 RBD，原因有很多，这使得它更适合这个云用例。RBD 依赖于 RADOS（对象存储），这是整个 Ceph 堆栈的底层。这个抽象级别简单地提供了一个在集群周围条带化的图像。RBD 可以以两种不同的形式向客户端呈现图像

  • 一个内核模块，自 2010 年以来一直是主线的一部分，它将块设备暴露给系统（就像 iSCSI 一样）
  • 一个 QEMU 驱动程序，用于在 RBD 之上构建虚拟机磁盘（连接设备并从设备启动）

此外，RBD 本身是稳定的并且性能良好，因为 Ceph 开发人员花费了大量时间使其变得健壮，这使得它成为 Ceph 中第二可靠的部分。

所以你是在说这可以通过 RBD 来解决？

每个人都希望 VM 具有高可用性，OpenStack 的卷启动功能在一定程度上解决了这个问题，但它不是启动 VM 时的默认选项。卷启动是一个将虚拟机的磁盘存储在存储集群中的过程，这使得数据高度可用。在 OpenStack 中，这表现为 Cinder 控制和管理的块设备，存储在存储后端，在这种情况下后端是 RBD。所以是的，使用 Cinder / RBD 的卷启动是提供 VM 高可用性的解决方案。顺便说一下，像 nova evacuate 和 nova live migration 真的很快，因为在此过程中只迁移工作负载 ;-)

但是你刚刚说部分解决？我来解释一下。

好的，正如你已经猜到的，问题是半个解决了，因为我们想要一种透明的卷启动方式。在 OpenStack 中，卷启动是启动 VM 的可选方式，而不是默认方式。最终用户必须选择正确的参数。强制卷启动是不可能的，虽然它可以实现，但这意味着需要在代码库和 API 中进行一些重大的修改。显然，你仍然有 丑陋的选项可以使用修改后的 Nova API 版本，该版本调用 Cinder 并发出隐藏的 RBD 卷启动。我必须说，如果你不运行公共云，这可能很好……我看到 2 种用例

  1. ISP（公共提供商），忘记这个想法，除非你想提供一个非常接近的服务。
  2. 企业云（私有云），你独自管理平台，并且你知道平台上发生的一切。你必须 100% 确定你完全控制你的基础设施。你可以随时入侵仪表板，但这不仅仅是这样：你必须自动化从镜像创建卷的过程。这将延长该过程。

在两种情况下，我甚至不建议这样做，你可以想象

  • 兼容性问题，你被困住了！
  • 维护问题，我如何在任何更新版本上更新我的系统？你不能！

到那时，由你决定 :-)。

然后，解决这个问题的方法是在 libvirt_image_type 标志上实现一个新的后端。主要目标是为临时磁盘镜像提供替代存储后端。这通常由 libvirt_images_type 标志在你的 nova.conf 文件中管理。目前，仅支持文件（raw、qcow2）和 LVM。在 RBD 的上下文中，该机制与卷启动功能非常相似，其中 nova 需要能够从 ceph 集群连接设备。该方法的优点是，从客户端的角度来看，它是完全透明的。如果 VM 已经存储在 Ceph 中（卷启动），这也使得实时迁移更容易。基本上，操作员将指定一个 Ceph 池来构建 RBD 镜像。然后，每次启动 VM 时，根据请求的 flavor，RBD 镜像将以这种方式调整大小并用作 VM 的根驱动器。

以下蓝图解决了这个问题：https://blueprints.launchpad.net/nova/+spec/bring-rbd-support-libvirt-images-type，我真诚地希望这能在 Havana 中可用。

更多改进的空间

OpenStack 没有利用带有缓存选项的 QEMU 驱动程序。以任何方式都无法使用特殊的标志来使用 rbd_cache，例如。

以下蓝图解决了这个问题：https://blueprints.launchpad.net/nova/+spec/enable-rbd-tuning-options，我希望这能在 Havana 中及时可用。

好吧，一年后你会怎么说？

嗯，可能还是同样的话，因为我正在推动这项举措，并且我希望看到人们参与到这些新的存储考虑中来。我们正处于一个过渡时期，因此采用速度较慢，但是事情正在发生变化。我认为总会有分布式文件系统的用例，例如 HPC 平台。因此，在 DFS 变得更加成熟时，重新考虑这个问题会很好。虽然我认为这是一个可靠的解决方案，但我们不需要文件系统来存储我们的 VM 磁盘（更少的开销和复杂性）。

我想你们都明白了！让我们将所有这些临时空间整合到一个分布式、快速可访问、开源存储上！显然，并且一如既往地，请随时与这篇博文互动。