Network Management
How to validate if RabbitMQ is in a cluster in Solarwinds HA setup
If you have implemented Solarwinds HA. This article provides steps on how to validate if your RabbitMQ is in a cluster.
First published date
9/14/2021 9:18 AM
Last published date
3/22/2022 3:47 AM
Overview
If you have implemented Solarwinds High Availability implemented in your environment for main pool, this article provides information on how to validate if RabbitMQ Cluster is correctly setup and working as expected. A healthy and correctly configured RabbitMQ cluster is one of a pre-requisite for a stable HA environment.
The RabbitMQ cluster is created automatically when we create HA Main pool, provided there were no issues with RabbitMQ on the Pool members.
The RabbitMQ cluster is created automatically when we create HA Main pool, provided there were no issues with RabbitMQ on the Pool members.
Product section
Orion Platform
Cause
NA
Resolution
RabbitMQ Cluster Verification via Web console:
Consider a scenario where we have Primary main poller (31A) and Standby main poller (31B), 31A is the Active one and 31B is standby.
In this case, when you login to Rabbitmq management web console via openrabbitmqconsole.exe on both Server we should expect to see the cluster name at top right should always be pointed to the Active Server. In this example 31A
And whenever a successfully fail over happens to standby node, the cluster name will change to the Standby node in our case 31B in screenshot above
And node status should be green, i.e the name column below will be red if there is has a problem with any RabbitMQ node and the node can't join the cluster or cluster is broken. If a node is not healthy then refer to Troubleshooting RabbitMQ to fix and continue the validation part.
Note, the above screenshots is taken from Orion Platform 2020.2.4 environment, so the version of RabbitMQ and Erlang may be different if you have different version of Orion.
RabbitMQ Cluster Verification via CLI:
We can verify the same info via the rabbitmqctl.bat command line utility. Sample output will look like this in a healthy cluster environment. Note the output may different if your ver of RabbitMQ is different.
Output from Active Main Poller (31A)
Output from Standby Main Poller (31B)
Consider a scenario where we have Primary main poller (31A) and Standby main poller (31B), 31A is the Active one and 31B is standby.
In this case, when you login to Rabbitmq management web console via openrabbitmqconsole.exe on both Server we should expect to see the cluster name at top right should always be pointed to the Active Server. In this example 31A
And whenever a successfully fail over happens to standby node, the cluster name will change to the Standby node in our case 31B in screenshot above
And node status should be green, i.e the name column below will be red if there is has a problem with any RabbitMQ node and the node can't join the cluster or cluster is broken. If a node is not healthy then refer to Troubleshooting RabbitMQ to fix and continue the validation part.
Note, the above screenshots is taken from Orion Platform 2020.2.4 environment, so the version of RabbitMQ and Erlang may be different if you have different version of Orion.
RabbitMQ Cluster Verification via CLI:
We can verify the same info via the rabbitmqctl.bat command line utility. Sample output will look like this in a healthy cluster environment. Note the output may different if your ver of RabbitMQ is different.
Output from Active Main Poller (31A)
C:\Program Files (x86)\SolarWinds\Orion\RabbitMQ\sbin>rabbitmqctl.bat cluster_status Cluster status of node rabbit@S-SW-31A ... Cluster name: rabbit@S-SW-31A.mydomain.com rabbit@S-SW-31A rabbit@S-SW-31B rabbit@S-SW-31A rabbit@S-SW-31B rabbit@S-SW-31A: RabbitMQ 3.8.16 on Erlang 23.3 rabbit@S-SW-31B: RabbitMQ 3.8.16 on Erlang 23.3
Output from Standby Main Poller (31B)
C:\Program Files (x86)\SolarWinds\Orion\RabbitMQ\sbin>rabbitmqctl.bat cluster_status Cluster status of node rabbit@S-SW-31B ... Cluster name: rabbit@S-SW-31A.mydomain.com rabbit@S-SW-31A rabbit@S-SW-31B rabbit@S-SW-31A rabbit@S-SW-31B rabbit@S-SW-31A: RabbitMQ 3.8.16 on Erlang 23.3 rabbit@S-SW-31B: RabbitMQ 3.8.16 on Erlang 23.3 ... ...Note Cluster name portion of output is same in both cases, which means the active server is the master node for cluster.