Cluster across two data centers

[ixoixo]

Hello,
I need your advice how to set up RMQ cluster.
Lets imagine you have two data center (DC) close enough. Ping under 10ms and less. The 'Management' idea is to have cluster across both data centers, but active only on one and second one will have always current data but no active exchanges and so on.
If first data center will have, let’s say network problem than second with data up to date will take over with ‘work’.
But how? Is it even possible? If I have 3 node ‘cluster’ in first one DC > 3 nodes on second one DC >> I’ll end up with 6 node big cluster, but 6 is even number!
Thx for the answers!

[mkuratczyk]

Rather than spreading a cluster across 2 data centres (which will mostly just increase the odds of a network partition), set up two independent clusters and a warm standby solution between them. This is one of a few commercial features we offer on top of RabbitMQ:
https://docs.vmware.com/en/VMware-Tanzu-RabbitMQ-for-Kubernetes/3.13/tanzu-rabbitmq-kubernetes/standby-replication.html

Your apps use only one of the clusters, warm standby replication makes sure the messages (and exchanges, queues, etc) are replicated to the other cluster and if you need to, you can promote the secondary cluster to be the new live cluster.

[ixoixo]

Thx, could be the way, but we use RMQ on Windows, no Linux or any docker solution. This is so far big limitation for us.
Any idea to get this working with Windows and VMWare setup/environment?

[michaelklishin]

There is no Windows build of Tanzu RabbitMQ at the moment. Use a Linux container or VM.

[ixoixo]

OK, Let's think about changing of consept how 'management' sees cluster to be done. I do not like the idea but I have no jokers in my pocket to give them solid answer how to do it. I do understant that combining DCs into one is cos saving some money and as well to use idle resources. But it has to be a way to do it on Windows as well.

[michaelklishin]

We cannot make any public promises on Tanzu RabbitMQ availability on Windows or its timelines. Our corporate sponsor explicitly prohibits such forward-looking statements.