迈向更完善的 Ceph-Deploy 之路

2013年9月26日 alfredo

Ceph-deploy 是 Ceph 的简易部署工具，但它曾一度带来不少麻烦：几乎没有日志记录，当出现问题时也没有清晰的错误消息。

为了解决这些（以及其他）问题，并使 ceph-deploy 变得更好，我们付出了*巨大*的努力。好到令人难以置信。这篇文章将介绍该工具所经历的一些重大变化，并展望未来的发展。

我的主机上发生了什么？ ¶

对于一个在远程主机上执行命令的工具来说，最重要的事情之一是能够准确显示正在执行什么以及输出是什么。然而，ceph-deploy 以前并非如此。当我们开始修复问题时，我们将此作为优先事项。

如果没有关于远程端发生情况的详细日志记录，几乎不可能知道如何修复问题，或者如何改进任何过程。

现在默认情况下，该工具的日志级别为 DEBUG，并且会实际输出它在远程端执行的每个命令，其调用方式完全相同。

下面是向测试机部署监视器时的部分输出摘录：

$ ceph-deploy mon create node1 [ceph_deploy.mon][DEBUG ] Deploying mon, cluster ceph hosts node1 [ceph_deploy.mon][DEBUG ] detecting platform for host node1 ... [ceph_deploy.sudo_pushy][DEBUG ] will use a remote connection with sudo [ceph_deploy.mon][INFO ] distro info: Ubuntu 12.04 precise [node1][DEBUG ] determining if provided host has same hostname in remote [node1][DEBUG ] deploying mon to node1 [node1][DEBUG ] remote hostname: node1 [node1][INFO ] write cluster configuration to /etc/ceph/{cluster}.conf [node1][DEBUG ] checking for done path: /var/lib/ceph/mon/ceph-node1/done [node1][INFO ] create a done file to avoid re-doing the mon deployment [node1][INFO ] create the init path if it does not exist [node1][INFO ] locating `service` executable... [node1][INFO ] found `service` executable: /usr/sbin/service [node1][INFO ] Running command: sudo initctl emit ceph-mon cluster=ceph id=node1 [node1][INFO ] Running command: sudo ceph daemon mon.node1 mon_status

我们不仅记录了命令和交互，而且还用实际的主机名来命名每个日志记录器，以指示操作发生的位置！如果您正在利用在多台主机上运行命令，这一点尤其重要。

在这种情况下，输出会发送到终端，但执行目录中始终会保留一份副本（通常命名为 ceph.log 的文件）。

如前所述，所有命令也会显示出来，它们通常以 Running command: 为前缀，后面跟着正在执行的确切命令。

只需查看日志，任何人都可以轻松地编写 Chef 配方、Puppet 清单或任何其他配置管理引擎。对我们来说，非常重要的是，当用户准备从 ceph-deploy 的默认配置过渡到更自定义的 Ceph 配置时，我们能够为他们赋能。

模糊不清的错误 ¶

没有什么比晦涩难懂的错误消息更令人沮丧了，它们既没有告诉你发生了什么（也可能没有暗示你如何修复）。

这是我们想要修复的另一个大问题。我们投入了大量工作来正确捕获错误并向日志输出返回有意义的消息。

以前不仅在发生错误时会出现长长的堆栈跟踪，而且远程错误还会被 ceph-deploy 用于远程连接的库所混淆。这尤其令人痛苦，因为要修复发生在远程端的问题，我们（至少）知道错误是什么是非常重要的。

现在，远程错误不仅得到了很好的处理和报告，而且如果由于某种原因 ceph-deploy 无法正确处理某个错误，它将以 ERROR 级别记录，以便清楚地表明出了问题。

这是一个由于变量未定义而无法创建文件的代码示例：

[vpm017][ERROR ] Traceback (most recent call last): [vpm017][ERROR ] File "/home/ubuntu/ceph-deploy/ceph_deploy/util/decorators.py", line 10, in inner [vpm017][ERROR ] File "/home/ubuntu/ceph-deploy/ceph_deploy/hosts/common.py", line 3, in write_monitor_keyring [vpm017][ERROR ] NameError: global name 'keyring' is not defined

请记住，这个输出来自远程执行的命令，因此我们（和用户）清楚地知道是否有问题（以及为什么）是非常重要的。

在工具的大部分内部异常处理中都进行了规范化，使得错误报告更加清晰，希望也更容易理解。
处理，使得错误报告更加清晰，希望也更容易理解。

稳定、稳定、稳定 ¶

除了改进日志记录和错误报告之外，我们的主要目标是提高工具的稳定性。这意味着要消除正在发现的 bug，也要消除那些似乎永远不会消失的旧 bug。

我相信我们正在使代码库达到一个阶段，即需要解决的大问题越来越少，并且有更好的机会开始处理一些期待已久的功能。

接下来我们要去哪里？ ¶

更好的监视器部署 ¶

在我们修复一些问题的过程中，有一些明显的痛点需要通过更好的输出来解决，其中之一就是部署监视器。

有时监视器会挂起，或者收集密钥会失败，几乎没有信息（即使有新的日志记录）可以告诉用户可能出了什么问题。

从版本 1.2.6 开始，ceph-deploy 会在部署监视器时报告其状态，确保主机短版本与远程版本匹配，并且监视器的排名处于可接受的值。

但还有更多功能即将推出！将有更多的检查来捕获常见的陷阱，以及一种更简单的方法（单个命令）来部署所有定义的监视器，等待它们形成仲裁，最后收集密钥。

这有望在事情没有按预期运行时提供更好的信息，并使部署少量监视器变得更容易。

使所有命令都更详细 ¶

尽管 install 标志（以及其他几个标志）对于告诉我们远程主机上发生的事情非常有用，但仍有一些需要更新才能使用较新的连接实用程序，将远程详细级别提升到标准水平。

这对 install、osd 和 mon 至关重要，我们确信对 ceph-deploy 的其余部分也会如此。

更简单的 Rados Gateway 部署 ¶

目前 ceph-deploy 尚不支持，但已列入待办事项。一旦我们有了所需所有组件的打包版本，它就会被添加到工具集中。

在这个问题上我们需要划清界限，决定工具应该做什么，我们决定先依赖一个包，然后让 ceph-deploy 使用它来进行部署。

最后… ¶

让这个小工具跟上速度并表现良好，同时保持其有用性，需要付出巨大的努力。还有很多工作要做，还有很多需要改进！请保持关注（并保持耐心！），常规版本将开始变得更好，比以前的版本有了突飞猛进的改进。

请务必更新。每个版本平均包含大约 5-10 个 bug 修复，这就是为什么我们尽量经常发布的原因。

希望 ceph-deploy 会变得更容易使用，并且更容易处理错误。