在OpenStack中运行RabbitMQ的最佳实践

Posted 2021-04-24 开源云中文社区

OpenStack依赖于消息队列，所以关键是有最好的设置。大多数部署包括RabbitMQ，所以让我们花几分钟时间查看一些最佳实践，使其尽可能高效地运行。

在专用节点上部署RabbitMQ

使用专用节点，RabbitMQ与其他CPU占用高的进程隔离，因此可以承受更多的压力。

用HiPE运行RabbitMQ

HiPE代表High Performance Erlang。当HiPE被启用时，Erlang应用程序在被执行之前被预编译为机器码。我们的基准显示，这使RabbitMQ的性能提升高达30％（如果你有这样的事情要处理，你可以在https://github.com/binarin/rabbit-simple-benchmark/blob/master/README.md找到基准的细节，在https://github.com/binarin/rabbit-simple-benchmark/blob/master/report.md看到结果）。

这样做的缺点是，当Erlang应用程序被编译的时候，应用程序启动时间大大增加。使用HiPE，第一个RabbitMQ启动大约需要2分钟。

我们发现的另一个微妙的缺点是，如果启用HiPE，调试RabbitMQ可能很难，因为HiPE可以破坏错误回溯，使它们不可读。

不要对RPC队列使用队列镜像

我们的研究表明，在3节点集群上启用队列镜像会使消息吞吐量下降两倍。你可以在Mirantis Scale团队生成的公开数据中看到此效果（http://docs.openstack.org/developer/performance-docs/test_results/mq_ha/index.html）。

另一方面，RPC消息变得很快就过时（1分钟），如果消息丢失，它只导致当前正在进行的操作失败，因此整体来看没有镜像的RPC队列似乎是一个很好的权衡。

在Mirantis，通常只对Ceilometer队列启用队列镜像，其中必须保留消息。你可以在https://github.com/openstack/fuel-library/blob/master/files/fuel-ha-utils/policy/set_rabbitmq_policy#L28看到我们如何定义这样的RabbitMQ策略。

对Ceilometer使用单独的RabbitMQ集群

一般来说，Ceilometer不通过RabbitMQ发送很多消息。但如果Ceilometer卡住，它的队列会溢出。这导致RabbitMQ崩溃，反过来又导致其他OpenStack服务的中断。

使用单独的RabbitMQ集群进行通知的能力从OpenStack Mitaka（MOS 9.0）开始提供，并且在开箱即用的MOS中不支持。该功能尚未记录，但可以在https://review.openstack.org/#/c/249508找到实现。

降低Ceilometer指标数量

在OpenStack下运行RabbitMQ的另一个最佳实践是减少发送的指标数量和/或其频率。显然，这不仅减少了对RabbitMQ，Ceilometer和MongoDB的压力，也减少了如果Ceilometer / MongoDB无法应付太多的消息时，消息在RabbitMQ堆积的机会。反过来，在队列中堆积的消息降低了整体RabbitMQ性能。

你也可以通过使用RabbitMQ的延迟队列功能（从RabbitMQ 3.6.0开始可用）来缓解堆积消息的影响，但是在写这篇文章时，MOS不使用延迟队列。

（仔细）考虑禁用Ceilometer队列的队列镜像

在Mirantis OpenStack架构中，队列镜像是唯一使用的“持久性”度量。我们不使用持久队列，因此如果丢失Ceilometer通知会带来伤害，请不要禁用队列镜像。例如，如果通知数据用于结算，就绝不能丢失这些通知。

编译：Jonathan Zhang

来源：https://www.mirantis.com/blog/best-practices-rabbitmq-openstack/

投稿邮箱：[e-mail]