This guide covers how to use Standby Offsite Replication Operator to configure the Standby Offsite Replication plugin. If you haven't installed Standby Offsite Replication Operator, please see: installation guide. For a general guide on how to set up Active Passive topology for Tanzu RabbitMQ, please see: Active Passive dedicated guide.

This guide is structured in the following sections:

  • Upstream Configurations
  • Downstream Configurations
  • Update Configurations
  • Delete Configurations

Upstream Configurations

You can use Standby Offsite Replication Operator to configure which quorum queues that the plugin should collect messages for. The following example let the plugin know it should collect messages for all quorum queues in vhost test:

---
apiVersion: rabbitmq.tanzu.vmware.com/v1beta1
kind: StandbyReplication
metadata:
  name: upstream-configuration
spec:
  operatingMode: "upstream" # has to be "upstream" to configure an upstream RabbitMQ cluster; required value
  upstreamModeConfiguration: # list of policies that Operator will create
    replicationPolicies:
      - name: test-policy # policy name; required value
        pattern: "^.*" # any regex expression that will be used to match quorum queues name; required value
        vhost: "test" # vhost name; must be an existing vhost; required value
  rabbitmqClusterReference:
    name: upstream # the upstream RabbitMQ cluster name; must be in the same namespace; required value

Note that field spec.operatingMode has to be set to upstream in order to provide upstream related configurations.

spec.upstreamModeConfiguration.replicationPolicies is a list, and name, pattern, vhost are all required values for an operator policies.

Downstream Configurations

You can use Standby Offsite Replication Operator to configure a downstream (passive) RabbiMQ cluster to connect to a certain RabbitMQ. Operator takes the provided endpoints and credentials to set standby_replication_upstream global parameter in the downstream RabbitMQ.

The following example connects RabbitMQ cluster downstream to RabbitMQ cluster at endpoint 34.75.255.555:5552:

---
apiVersion: rabbitmq.tanzu.vmware.com/v1beta1
kind: StandbyReplication
metadata:
  name: downstream-configuration
spec:
  operatingMode: "downstream" # has to be "downstream" to configure an downstream RabbitMQ cluster
  downstreamModeConfiguration:
    endpoints: "34.75.255.555:5552" # comma separated list of endpoints to the upstream RabbitMQ
    upstreamSecret:
      name: upstream-secret # an existing Kubernetes secret; required value
  rabbitmqClusterReference:
    name: downstream # RabbitMQ cluster name; must be in the same namespace; required value

Note that field spec.operatingMode has to be set to downstream to provide downstream related configurations.

spec.downstreamModeConfiguration.endpoints is a comma separated list containing endpoints to connect to the upstream RabbitMQ. Endpoints have to be reachable from this downstream cluster with the stream protocol port.

spec.downstreamModeConfiguration.upstreamSecret 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

Update Configurations

You can update both upstream and downstream configurations. Be aware that once a StandbyReplication custom resource is created, you won't be able to update its spec.operatingMode and spec.rabbitmqClusterReference. To change these two immutable fields, you will need to delete and re-create the resource.

Operator does not watch updates for the Kubernetes secret object which is set in spec.downstreamModeConfiguration.upstreamSecret. If credentials have been updated in the secret, you can force the Operator to update by adding a temporary label or annotation to the custom resource.

Note that updates to spec.upstreamModeConfiguration.replicationPolicies is not fully supported. Operator won't clean up removed policies from the list. Other update operations such as updating policy name, vhost, and patterns, and adding a new policy are supported.

Delete Configurations

You can remove upstream and downstream configurations by deleting the StandbyReplication custom resource. To delete an upstream configuration, Operator removes all replication policies set in spec.upstreamModeConfiguration.replicationPolicies from the RabbitMQ.

To delete a downstream configuration, Operator removes the standby_replication_upstream global parameter.

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