部署openstack 组件rabbitmq 之最佳实践

Posted 2021-04-24 UMCloud优云数智

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

在专用节点上部署RabbitMQ

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

此隔离选项在版本8.0开始可用于Mirantis OpenStack。有关详细信息，请在验证的插件页面上搜索“Detach RabbitMQ”。

用HiPE运行RabbitMQ

HiPE代表高性能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

但是用 HiPE 编译也有缺点，编译后的应用启动时间变长很多。使用 HiPE 编译的 RabbitMQ 初次启动需要 2 分钟左右。

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

HiPE在Mirantis OpenStack中从9.0版开始启用。

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

我们的研究表明，在3节点集群上启用队列镜像会使消息吞吐量下降两倍。您可以在Mirantis Scale团队测试报告生成的公开数据中看到此效果。

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

在Mirantis，通常只对Ceilometer队列启用队列镜像，其中必须保留消息。您可以在这里(https://github.com/openstack/fuel-library/blob/master/files/fuel-ha-utils/policy/set_rabbitmq_policy#L28)看到我们如何定义这样的RabbitMQ策略。关闭队列镜像的选项在从Mirantis OpenStack 8.0开始的MOS中可用，对于从版本9.0开始的RPC队列默认启用。

对Ceilometer使用单独的RabbitMQ集群

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

使用单独的RabbitMQ集群进行通知的能力可从OpenStack Mitaka（MOS 9.0）开始提供，并且在开箱即用的MOS中不支持。该功能尚未记录，但您可以在这里找到实现。

降低Ceilometer采集频率

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

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

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

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

可以从版本8.0开始在Mirantis OpenStack中禁用Ceilometer队列的镜像功能，但默认情况下禁用。

此篇为Mirantis原创。如有转载，烦请联系UMCloud，转载第三方请保留原创信息。

UMCloud（上海优铭云计算有限公司）成立于2016年，由中国顶尖的中立公有云服务商UCloud和全球排名第一的OpenStack云计算服务商Mirantis在华成立的中方控股合资云计算公司，专注于提供私有云产品方案与服务、存储产品、Mirantis OpenStack培训等业务。 

  了解更多资讯  关注官方微信