Active Passive Guide

This is a dedicated guide about how to configure Tanzu RabbitMQ to have both topology objects, such as vhosts, queues, and policies, and quorum queue messages replicated to a different Tanzu RabbitMQ cluster.

This guide is structured in the following sections:

  • RabbitmqCluster Configurations
  • Schema Sync Configurations
  • Standby Replication Configurations

RabbitmqCluster Configurations

To set up active passive topology, we need to enable all required plugins and provide specific RabbitMQ server configurations.

Following manifest is an example for an upstream (active) RabbitmqCluster with required configurations:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: upstream-rabbit
spec:
...
  rabbitmq:
    additionalPlugins:
      - rabbitmq_stream # required for plugin rabbitmq_standby_replication
      - rabbitmq_schema_definition_sync # plugin that replicates topology objects
      - rabbitmq_schema_definition_sync_prometheus
      - rabbitmq_standby_replication # plugin that replicates quorum queue messages
    additionalConfig: |
      schema_definition_sync.operating_mode = upstream # required
      standby.replication.operating_mode = upstream # required

Below is a manifest for a downstream (passive) RabbitmqCluster configurations:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: downstream-rabbit
spec:
...
  rabbitmq:
    additionalPlugins:
      - rabbitmq_stream # required for plugin rabbitmq_standby_replication
      - rabbitmq_schema_definition_sync # plugin that replicates topology objects
      - rabbitmq_schema_definition_sync_prometheus
      - rabbitmq_standby_replication # plugin that replicates quorum queue messages
    additionalConfig: |
      schema_definition_sync.operating_mode = downstream # required
      standby.replication.operating_mode = downstream  # required
      schema_definition_sync.downstream.locals.users = ^default_user_ # configure the schema sync plugin not to overwrite the exsiting default user; required
      schema_definition_sync.downstream.locals.global_parameters = ^standby # configure the schema sync plugin not to overwrite plugin specific global param; required

Schema Sync Configurations

RabbitMQ Schema Sync Plugin is configured using Messaging Topology Operator by create custom resources schemareplications.rabbitmq.com. You need to provide upstream RabbitMQ endpoints for both the upstream (active) and downstream (passive) RabbitMQ clusters. For example:

---
apiVersion: rabbitmq.com/v1beta1
kind: SchemaReplication
metadata:
  name: upstream
spec:
  endpoints: "upstream-server-0.upstream-nodes.rabbitmq-system.svc.cluster.local:5672,upstream-server-1.upstream-nodes.rabbitmq-system.svc.cluster.local:5672,upstream-server-2.upstream-nodes.rabbitmq-system.svc.cluster.local:5672"
  upstreamSecret:
    name: upstream-rabbit-default-user # an existing Kubernetes secret; required value
  rabbitmqClusterReference:
    name: upstream-rabbit # RabbitMQ cluster name; must be in the same namespace; required value
---
apiVersion: rabbitmq.com/v1beta1
kind: SchemaReplication
metadata:
  name: downstream
spec:
  endpoints: "upstream-server-0.upstream-nodes.rabbitmq-system.svc.cluster.local:5672,upstream-server-1.upstream-nodes.rabbitmq-system.svc.cluster.local:5672,upstream-server-2.upstream-nodes.rabbitmq-system.svc.cluster.local:5672"
  upstreamSecret:
    name: upstream-secret # an existing Kubernetes secret; required value
  rabbitmqClusterReference:
    name: downstream-rabbit # RabbitMQ cluster name; must be in the same namespace; required value

Custom resource SchemaReplication needs to be created in the same namespace as the RabbitMQ it refers to in spec.rabbitmqClusterReference.

spec.endpoints is a comma separated list containing endpoints to connect to the upstream RabbitMQ. Endpoints should be set with the amqp port.

spec.upstreamSecret.name is the name of an exising Kubernetes secret in the same namespace. This secret must contain keys: username and password. It's used as credentials to connect to the upstream RabbitMQ. For example:

---
apiVersion: v1
kind: Secret
metadata:
  name: upstream-secret
type: Opaque
stringData:
  username: test-user # upstream cluster username
  password: test-password # upstream cluster password

For convenience, you can use the default user secret that's created by the Cluster Operator for the upstream RabbitmqCluster when configuring the upstream, since the default user secret contains keys username and password. If you would like to use a different user, you can set spec.upstreamSecret.name to a different Kubernetes secret.

Standby Replication Configurations

RabbitMQ Standby Replication Plugin is configured by its dedicated Operator, Standby Replication Operator. Upstream (active) RabbitMQ are configured by creating policies which tells the plugin which quorum queues it will collect messages for. Downstream (passive) RabbitMQ are configured by setting global parameter standby_replication_upstream. To see how to use Standby Replication Operator, check out:

check-circle-line exclamation-circle-line close-line
Scroll to top icon