RabbitMQ

RabbitMQ 是用 Erlang 编写的消息代理。它目前是 Kolla Ansible 部署中消息队列的默认提供者。

TLS 加密

在保护 RabbitMQ 通信时，需要考虑多个通道。Kolla Ansible 目前支持以下内容的 TLS 加密

  • 客户端-服务器流量，通常是使用 oslo.messaging 库和 RabbitMQ 的 OpenStack 服务之间的流量

  • RabbitMQ 管理 API 和 UI（仅限 HAProxy 的前端连接）

目前不支持以下通道的加密

  • RabbitMQ 服务器节点之间的 RabbitMQ 集群流量

  • RabbitMQ CLI 与 RabbitMQ 服务器节点之间的通信

  • RabbitMQ 管理 API 和 UI（HAProxy 到 RabbitMQ 的后端连接）

客户端-服务器

通过将 rabbitmq_enable_tls 设置为 true 来启用客户端-服务器流量的加密。 此外，证书和密钥必须在以下路径中可用（优先级顺序）

证书

  • "{{ kolla_certificates_dir }}/{{ inventory_hostname }}/rabbitmq-cert.pem"

  • "{{ kolla_certificates_dir }}/{{ inventory_hostname }}-cert.pem"

  • "{{ kolla_certificates_dir }}/rabbitmq-cert.pem"

密钥

  • "{{ kolla_certificates_dir }}/{{ inventory_hostname }}/rabbitmq-key.pem"

  • "{{ kolla_certificates_dir }}/{{ inventory_hostname }}-key.pem"

  • "{{ kolla_certificates_dir }}/rabbitmq-key.pem"

kolla_certificates_dir 的默认值为 /etc/kolla/certificates。

证书必须对运行 RabbitMQ 的 API 网络上的主机的 IP 地址有效。

可以通过 rabbitmq_tls_options 将其他 TLS 配置选项传递给 RabbitMQ。 这应该是一个字典，键将以 ssl_options. 为前缀。 例如

rabbitmq_tls_options:
  ciphers.1: ECDHE-ECDSA-AES256-GCM-SHA384
  ciphers.2: ECDHE-RSA-AES256-GCM-SHA384
  ciphers.3: ECDHE-ECDSA-AES256-SHA384
  honor_cipher_order: true
  honor_ecc_order: true

有关 RabbitMQ TLS 配置的详细信息，请参阅 RabbitMQ 文档。

当 om_rabbitmq_enable_tls 为 true 时（它默认为 rabbitmq_enable_tls 的值），适用的 OpenStack 服务将被配置为使用启用 TLS 的 oslo.messaging。 CA 证书通过 om_rabbitmq_cacert 配置（它默认为 rabbitmq_cacert，指向用于 TLS 的系统的受信任 CA 证书包）。 请注意，目前不支持使用客户端证书。

为了测试目的，Kolla Ansible 提供了 kolla-ansible certificates 命令，如果 rabbitmq_enable_tls 为 true，它将为 RabbitMQ 生成自签名证书。

管理 API 和 UI

管理 API 和 UI 通过 HAProxy 访问，仅在内部 VIP 上公开。 因此，当 kolla_enable_tls_internal 为 true 时，到此端点的流量将被加密。 请参阅 TLS 配置。

将参数传递给 RabbitMQ 服务器的 Erlang VM

Erlang 程序在 Erlang VM（虚拟机）中运行并使用 Erlang 运行时。 可以配置 Erlang VM。

Kolla Ansible 可以通过使用 rabbitmq_server_additional_erl_args 变量将参数传递给 Erlang VM。 其内容将附加到传递给 RabbitMQ 服务器启动脚本的环境变量 RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS。 Kolla Ansible 已经为 RabbitMQ 服务器配置了 IPv6（如果需要）。 可以根据 https://rabbitmq.cn/runtime.html 中记录的任何参数传递到那里。

rabbitmq_server_additional_erl_args 的默认值为 +S 2:2 +sbwt none +sbwtdcpu none +sbwtdio none。

默认情况下，RabbitMQ 会启动 N 个调度器，其中 N 是 CPU 核心数，包括超线程核心。 当您假设所有 CPU 都专用于 RabbitMQ 时，这很好。 在典型的 Kolla Ansible 设置中，这不是一个好主意。 我们选择两个调度器线程 (+S 2:2)。 更多详细信息请参见：https://rabbitmq.cn/runtime.html#scheduling 和这里：https://erlang.org.cn/doc/man/erl.html#emulator-flags

参数 +sbwt none +sbwtdcpu none +sbwtdio none 可防止调度器的繁忙等待，有关更多详细信息，请参见：https://rabbitmq.cn/runtime.html#busy-waiting。

高可用性

随着 RabbitMQ 4.0 的发布，所有队列都高度可用，因为它们被配置为默认的 quorum 队列。 RabbitMQ 还提供称为 streams 的队列，可用于用更高效的替代方案替换“fanout”队列。 默认情况下启用此功能，但可以通过设置 om_enable_rabbitmq_stream_fanout: false 来禁用。 更改队列类型时，需要执行以下步骤。

警告

由于默认值已更改为在 Epoxy 版本中使所有队列都为持久类型，因此在升级到 Epoxy 之前需要执行以下步骤。

  1. 为所有服务生成新的配置。 之后，请确保不要在重置 RabbitMQ 状态之前重新启动任何容器。

    kolla-ansible genconfig

  2. 停止所有使用 RabbitMQ 的 OpenStack 服务，以便它们不会尝试重新创建任何队列。

    kolla-ansible stop --tags <service-tags>

  3. 如果您之前使用过 om_enable_rabbitmq_high_availability，请重新配置 RabbitMQ。

    kolla-ansible reconfigure --tags rabbitmq

  4. 重置每个 RabbitMQ 上的状态，以删除旧的瞬态队列和交换机。

    kolla-ansible rabbitmq-reset-state

  5. 再次启动 OpenStack 服务，此时它们将重新创建适当的持久队列。

    kolla-ansible deploy --tags <service-tags>