openstack/kolla-ansible
Code Issues Proposed changes

Merge "Improve RabbitMQ performance by reducing ha replicas"

Browse Source
This commit is contained in:
Zuul 2023-03-20 12:17:42 +00:00 committed by Gerrit Code Review
commit 0d42110e01
2 changed files with 25 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
ansible/roles/rabbitmq/defaults/main.yml
View File

@ -89,10 +89,16 @@ rabbitmq_cluster_partition_handling: "pause_minority"
# More details see:
# https://www.rabbitmq.com/ha.html#promoting-unsynchronised-mirrors
rabbitmq_ha_promote_on_shutdown:
# The number of rabbitmq replicas should follow this advice:
# https://www.rabbitmq.com/ha.html#replication-factor
# This means, if you have three rabbit nodes, we request two
# replicas of all queues and exchanges.
# Note: this assumes an odd number of rabbitmq nodes.
# If no replica count is specified, replicates across all nodes with definition
# "ha-mode":"all". Otherwise, uses
# "ha-mode":"exactly","ha-params":{{ rabbitmq_ha_replica_count | int }}
rabbitmq_ha_replica_count:
rabbitmq_server_count: "{{ groups[role_rabbitmq_groups] | length }}"
rabbitmq_ha_replica_count: "{{ (rabbitmq_server_count | int // 2 + 1) }}"
rabbitmq_extra_config: {}
####################

18
releasenotes/notes/rabbitmq-ha-improve-performance-8f29c7657d2999dd.yaml Normal file
View File

@ -0,0 +1,18 @@
---
upgrade:
- |
RabbitMQ replica count has changed from n to (n//2+1) where n is the number
of RabbitMQ nodes. That is, for a 3 node clusters, we request exactly 2
replicas, for a 1 node cluster, we request 1 replica, and for a 5 node
cluster, we request 3 replicas. This only has an effect if
`om_enable_rabbitmq_high_availability` is set to `True`, otherwise queues
are not replicated. The number of mirrored queues is not changed
automatically, and instead requires the queues to be recreated (for
example, by restarting RabbitMQ).
This follows the good practice advice here:
https://www.rabbitmq.com/ha.html#replication-factor
A major motivation is to reduce the load on RabbitMQ in larger
deployments. It is hoped, the improved performance should also
help rabbitmq recover more quickly from cluster issues.
Note that the contents of the RabbitMQ definitions.json are now changed,
meaning RabbitMQ containers will be restarted on next deploy/upgrade.