Unbalanced cluster

Bug #1890759 reported by Roy Zuo
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack RabbitMQ Server Charm
Fix Released
Medium
Unassigned

Bug Description

Charmed rabbitmq does not configure queue_master_locator and this results in the majority of queue masters being put on the node where the queues are declared. A lot of the times the node where the queues are defined is simply the first node listed in rabbit client configurations such as nova.conf.

This leads to often unbalanced clusters with queue masters concentrated on one node. That node would have to handle most of the connections and have high load in cpu and memory, and at the time when that node is down, a majority of queue masters would have to be moved, putting even more pressure on the cluster.

Configuring queue_master_locator to something like "min-master" can relieviate the problem. Otherwise, load balancer is another option.

The rabbitmqctl_report file is attached for reference.

# Queue masters are mostly on 11-lxd-8
> cat rabbitmqctl_report | awk -F'\t' '/^Queues on openstack/ {a=1}; a && /rabbit/ {split($1,s,"."); b[s[1]]++}; NF==0 {a=0}; END {for(i in b) {print i, b[i]}}'
<rabbit@juju-0aa49a-9-lxd-9 15
<rabbit@juju-0aa49a-11-lxd-8 15426
<rabbit@juju-0aa49a-10-lxd-8 309

# Most connections are made to 11-lxd-8
> cat rabbitmqctl_report| awk -F'\t' '/^Connections/ {a=1}; a && /rabbit/ {split($1,s,"."); b[s[1]]++}; NF==0 {a=0}; END {for(i in b) {print i, b[i]}}'
<rabbit@juju-0aa49a-9-lxd-9 8763
<rabbit@juju-0aa49a-11-lxd-8 14843
<rabbit@juju-0aa49a-10-lxd-8 6413

# 11-lxd-8 uses the most memory
> cat rabbitmqctl_report| awk '/^Status/ {a=1; print}; a && /total,/; !NF {a=0}'
Status of node 'rabbit@juju-0aa49a-10-lxd-8'
     [{total,3536412448},
Status of node 'rabbit@juju-0aa49a-11-lxd-8'
     [{total,7030459176},
Status of node 'rabbit@juju-0aa49a-9-lxd-9'
     [{total,4256377400},

Tags: sts
Revision history for this message
Roy Zuo (roylez) wrote :
Roy Zuo (roylez)
tags: added: sts
Changed in charm-rabbitmq-server:
status: New → Triaged
importance: Undecided → Wishlist
Felipe Reyes (freyes)
Changed in charm-rabbitmq-server:
assignee: nobody → Felipe Reyes (freyes)
Revision history for this message
Edward Hope-Morley (hopem) wrote :
Revision history for this message
Billy Olsen (billy-olsen) wrote :

The severely unbalanced cluster has real implications to cloud availability and can lead to a loss of cloud functionality for a period of time. Updating bug importance accordingly

Changed in charm-rabbitmq-server:
importance: Wishlist → Medium
Felipe Reyes (freyes)
Changed in charm-rabbitmq-server:
assignee: Felipe Reyes (freyes) → nobody
Revision history for this message
Nicolas Bock (nicolasbock) wrote :

Policies are only applied on queue creation and policy updates. This means that a balanced cluster can become and stay unbalanced if the cluster loses one or more brokers. I still think that adding Felipe's proposed change is important, it is not a full solution to this problem here.

Revision history for this message
Nobuto Murata (nobuto) wrote :

It might be totally unrelated but in the field we are seeing more deployment race condition in terms of RabbitMQ with 21.01 charm release than 20.10 somehow.

I think the biggest change in charm-rabbitmq-server is this one to introduce "queue-master-locator" and set "min-masters" as the default value which is not the default in upstream:
https://opendev.org/openstack/charm-rabbitmq-server/commit/07ec03b5d7a13aa40a2d6e2751c39ba4e5d7dedd

Some services gave up to start something like:

2021-02-19 13:42:43.254 49489 ERROR oslo_service.service oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 10.217.143.106:5672 after inf tries: Server unexpectedly closed connection
22:53

root@juju-d778c7-0-lxd-2:~# systemctl status cinder-scheduler.service
● cinder-scheduler.service - OpenStack Cinder Scheduler
   Loaded: loaded (/lib/systemd/system/cinder-scheduler.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2021-02-19 13:42:43 UTC; 10min ago
  Process: 49489 ExecStart=/etc/init.d/cinder-scheduler systemd-start (code=exited, status=0/SUCCESS)
 Main PID: 49489 (code=exited, status=0/SUCCESS)

Feb 19 13:37:02 juju-d778c7-0-lxd-2 systemd[1]: Started OpenStack Cinder Scheduler.

We will look into more, but there seems some known issues with "min-masters":
* deployment race condition - https://bugs.launchpad.net/tripleo/+bug/1789373
* failover scenario - https://github.com/rabbitmq/rabbitmq-server/issues/1405

Revision history for this message
Nobuto Murata (nobuto) wrote :

Just as a follow-up on my previous comment:
https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1890759/comments/5

We found out the underlying bcache device for control plane including RabbitMQ wasn't set as writeback accidentally. So the whole race condition might have been caused by IO contention and starvation. So the new config and the new default value may not be the culprit here.

Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :

As it has no one assigned to it, I'm dropping this back to triaged. if there is some assigned, plus update assigned and status as appropriate. Thanks.

Changed in charm-rabbitmq-server:
status: In Progress → Triaged
Revision history for this message
Nobuto Murata (nobuto) wrote :

Just for the record again,

> We found out the underlying bcache device for control plane including RabbitMQ wasn't set as writeback accidentally. So the whole race condition might have been caused by IO contention and starvation. So the new config and the new default value may not be the culprit here.

Even after setting writeback to bcache, the deployment wasn't reliable. With bionic's rabbitmq at least, other services had error status sometimes. And the following change in charm config made it reliable in the end.

known-wait: 180
queue-master-locator: client-local

I'm not saying queue-master-locator is the one, but we just need to keep an eye on it especially with large scale deployments.

Revision history for this message
Edward Hope-Morley (hopem) wrote :
Changed in charm-rabbitmq-server:
milestone: none → 21.01
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.