Configuring geo-redundancy using the Kafka MirrorMaker feature (OCP)

Edit online

You configure geo-redundancy to replicate data between two geographically distant sites so that Application Service Manager can switch from one site to another should a failure occur.

Before you begin

Prerequisites

Discover the IP addresses of worker nodes.

You can see these using the following command:

oc get nodes -o wide

In the examples used here, the following worker node IP addresses are used:

10.22.41.144
10.22.41.173
10.22.42.144
10.22.42.173
10.22.43.144
10.22.44.144

About this task

MirrorMaker provides bi-directional replication support, which means a single instance of MirrorMaker can be deployed to copy data from the primary cluster to the secondary (backup) cluster, as well as from the secondary cluster to the primary cluster.

MirrorMaker is configured on the backup cluster only. You set up a new backup deployment (ClusterB) and join it to the primary cluster (Cluster A). To do so, you expose Kafka in ClusterA, and then set up NOI and MirrorMaker in ClusterB (backup). MirrorMaker connects to both the Kafka brokers in clusterA and clusterB. If topicA is replicated, a new topic called primary.topicA becomes available in clusterB, while backup.topicA is available in clusterA, which reads the messages generated in the backup clusterB.

Assumption: The steps and examples in the following topics assume that the Kafka clusters are configured to allow unsecured connections within OCP, and that secured communications are only from the backup to the primary cluster (via Mirror Maker).