来自 Juno 峰会的 Ceph 集成到 OpenStack

shan

距离香港峰会已经过去了六个月，能够看到社区的所有成员聚集在一个（有点寒冷）的会议中心，总是令人兴奋。就我所看到的提交和接受的演讲而言，Ceph 仍在通往顶峰的道路上。对 Ceph 的兴趣仍然巨大。
在 5 月 13 日星期二，Josh 和我主持了一个（持续 3 小时）的会议，讨论 Ceph 集成到 OpenStack 的下一步。说实话，当我们还在香港的时候，我认为我们的路线图过于乐观。所以这次我们决定更加现实，采取更循序渐进的方法，而不是“让我们添加所有我们可以添加的东西”。然而，这并不意味着 Icehouse 周期在功能方面受到限制，完全不是！事实上，Icehouse 周期已经取得了一些巨大的改进。我不知道你是否还记得我去年在 Icehouse 峰会后的文章，其中有一个我非常想要的功能：RADOS 作为 Swift 的后端。是的，我们做到了，所以如果你想了解更多细节，最好继续阅读 :)。

集成坏消息

为了给您提供一些背景信息，在 Havana 周期中，我们引入了一个新的后端来存储虚拟机磁盘。基本上，它允许您无缝地将虚拟机启动到 Ceph 中，所以是的，您的虚拟机磁盘将位于 Ceph 内部，而不是传统的文件系统路径 /var/lib/nova/instances//disk。管理此行为的标志称为‘libvirt_image_type’以及 rbd 选项。此功能非常有用，因为很多人希望简化虚拟机的管理/维护。由于 RBD 共享存储后端，实时迁移和恢复变得更加容易。
然而，即使有了这个后端，我们仍然在使用标准的方式来启动实例。这意味着我们必须从 Glance（已经位于 Ceph 内部）中提取镜像，将其流式传输到计算节点下的‘/var/lib/nova/instances/_base’目录，并最终将其导入到 Ceph（是的，再次！）。此操作效率低下且速度慢，因此我们想出了另一种方法。我们决定使用 Ceph RBD 的写时复制克隆功能。鉴于在导入到 Glance 期间，镜像被快照和保护，我们可以轻松地从它们创建克隆，我们已经在 Cinder 中创建卷时执行此操作。

在 Icehouse 中，我们有一个补丁来实现 COW 克隆。这段代码通过了功能冻结，但最终由于一个小的错误（Jay Pipes 顺便修复了）而被拒绝。鉴于我们拥有的时间框架，Nova 团队认为此补丁过于关键。有关完整讨论，请阅读此线程 http://lists.openstack.org/pipermail/openstack-dev/2014-March/029127.html。
幸运的是，Dmitry Borodaenko 为 Nova 创建了一个特殊分支，其中包含 COW 克隆代码。该分支可在他的 Github 上找到 https://github.com/angdraug/nova/commits/rbd-ephemeral-clone。eNovance 已经在 Sid 和 Jessie 的官方 Debian 镜像中提供了 Debian 和 Ubuntu 包。但是，对于 Debian Wheezy、Ubuntu Precise 和 Trusty，您应该查看： http://cloud.pkgs.enovance.com/{wheezy,precise,trusty}-icehouse。

Ceph 在 OpenStack 中？

unify-all-the-things-with-ceph

正如您所见，我们一直在努力将 Ceph 持续集成到 OpenStack 中。Ceph 从一开始就存在于 OpenStack 中，在每个版本中我们都集成了新功能。

Icehouse 有什么新功能？

Glance RBD 后端的非原始镜像克隆

在一些生产设置之后，我们发现 libvirt_image_type RBD 后端与 QCOW2 Glance 镜像不兼容。对于已经尝试从卷启动 Cinder 的人来说，这是一个众所周知的问题。本质上，Ceph 不支持 QCOW2 用于托管虚拟机磁盘。显然这是一个问题，因为用户倾向于上传 QCOW2 镜像，因为它们是稀疏的。这就是为什么我通常建议私有云用户始终导入 RAW 镜像。如果他们不能或上传镜像需要太长时间，他们仍然可以从 QCOW2 镜像启动虚拟机，该镜像将被转换为 RAW，然后虚拟机将可用。之后，您可以简单地快照此实例，并稍后将快照用作镜像模板。有了这个小技巧，您就不需要上传大型 RAW 镜像（谁说大型 Windows 镜像？）
最终说明，这段新代码适用于 Cinder 从卷启动和 Nova 临时 RBD 后端。

Nova 临时后端专用池和用户

在 Icehouse 之前，我们必须使用 libvirt 中的 client.admin 来进行身份验证并与 Ceph 集群交互。这是一个巨大的安全漏洞，因为该密钥具有访问和控制整个集群的权限。现在，我们能够使用一个专用且权限受限的用户来访问 Nova 池，而无需其他任何权限。

RADOS 作为 Swift 的后端

这是大消息 :D。

如您所知，Swift 不遵循 OpenStack 发布周期，因此此新功能可能不会直接被视为 Icehouse 的添加项。

Swift 具有多后端功能，允许您将对象存储为
文件系统上的文件
glusterfs 共享上的文件
Ceph RADOS 中的对象

我想强调的一点是，您不会在 Swift 的核心代码中找到这些后端。Swift 具有一项策略，即让所有存储后端位于核心代码之外。鉴于此，每个后端都有其独立的 Stackforge 存储库。

它是如何工作的？

好吧，实现起来相当容易理解。由于 Swift 具有内置的多引擎 DiskFile，我们只是依赖它。一切都在 swift-object-server 级别发生，因此您仍然可以利用 Swift API、Swift 中间件和所有 Swift 功能。在这种情况下，Ceph 处理复制，Swift 配置为单个副本。

现在您可能想知道实施状态如何？

我们通过了所有单元测试和功能测试覆盖率。我们获得了两者的 100%。我们在 eNovance 玩了几个星期。我们运行了大量的基准测试和功能测试，它从未崩溃。这太棒了，在 eNovance，我们认为它已准备好投入生产，我们甚至即将开始将其实施到一些客户那里。
唯一的问题在于帐户和数据库级别。实际上，目前没有用于此的多后端引擎，补丁已经在 https://review.openstack.org/#/c/47713/ 上进行处理。
然后，一旦此补丁合并，我们将实施一个 RADOS 后端来存储帐户和数据库。

我如何测试它？

我们有一个 Ansible 存储库： https://github.com/enovance/swiftceph-ansible 可用且已准备就绪。
代码很快将在 StackForge 上可用，与此同时，您可以使用我们的存储库： https://github.com/enovance/swift-ceph-backend

Juno 的路线图

对于即将到来的周期，我们将尝试比上一个发布周期更现实，基本上我们选择了需要实施的关键功能，按优先级排序

  • 将 COW 克隆纳入稳定版（Dmitry Borodaenko）：这里的关键点是验证实时迁移和实例撤离等功能。

  • 使用 RBD 快照而不是 qemu-img（Vladik Romanovsky）：高效，因为我们不需要快照，获取一个平面文件并将其上传到 Ceph

  • DevStack Ceph（Sébastien Han）：方便开发人员采用

  • 持续集成系统（Sébastien Han）：拥有一个用于测试 RBD 的基础设施将帮助我们更轻松地合并补丁

  • 支持卷迁移和卷重定型（Josh Durgin）：在 Ceph 和其他后端之间移动块

再次说明，我认为这个新周期将会很有趣。Inktank 最近被 Red Hat 收购是一件好事，肯定会加强 Ceph 与 OpenStack 的集成。我期待着这些事情的发生。
下次再见。