Moving from single to multiple clusters

Use the multicluster support in Sterling Intelligent Promising containers to configure primary and secondary clusters. This feature ensures business continuity in the event of a disaster or outage affecting the primary environment.

This capability enables your organization to meet high availability and disaster recovery objectives. With a standby secondary cluster in sync helps you to take over when the primary cluster is not available.
Note: This feature is applicable only to users with a fully functional primary cluster deployment of Sterling Intelligent Promising containers and those planning to include secondary cluster for high availability and disaster recovery.

About this task

Sterling Intelligent Promising primarily relies on two databases, Cassandra and Elasticsearch. Depending on the type of data, the data might go into either or both of the databases. When moving from a single cluster to a multicluster setup, the existing data in the first cluster must be migrated to the new cluster to ensure that both data centers operate independently. The following procedure demonstrates how to move from a single cluster to multicluster.

Procedure

  1. Deploy middleware components in the new cluster that is the secondary cluster.
    1. Set up the required middleware components, including Cassandra, Elasticsearch, Kafka and others.
    2. Ensure that you create the Kafka topics that are required by Sterling Intelligent Promising in the secondary cluster. For more information, see Kafka topic list for the services.
  2. Enable Cassandra multidata center replication to maintain data consistency and high availability across clusters.
    Cassandra natively supports multidata center clustering, allowing seamless cross-datacenter data replication.
  3. Set up Kafka mirroring.
    1. Deploy MirrorMaker to replicate Kafka topics from primary cluster to secondary cluster. For more information, see List of Kafka topics to be mirrored.
    2. Ensure that you replicate the Kafka topics that are mentioned in step 3a from secondary to primary cluster.
  4. Perform a backup of the Elasticsearch cluster in the primary cluster and restore it to the secondary cluster.
    • If you are using Elasticsearch provided by a cloud provider such as AWS, Azure or Google Cloud Provider, you can use the native snapshot and restore capabilities offered by those platforms. Using built-in tools of a cloud provider allows management of backups and recovery independently.
    • If you are running a stand-alone Elasticsearch instance that you manage independently, follow the instructions to create snapshots and restore data. For more information, see Creating Elasticsearch snapshot to backup and restore data.
    When all the middleware components are ready, deploy Sterling Intelligent Promising services in the secondary cluster. However, to enable data replication between primary and secondary cluster, configure the mirrored Kafka topics and update required custom resources definitions to replicate Elasticsearch data. For more information, see Setting up a multicluster environment.

    With the primary and secondary clusters successfully configured, you can ensure business continuity and minimize downtime in a disaster or outage.

    To validate the configuration, simulate failover scenarios by redirecting traffic or workloads from the primary to the secondary cluster. This helps ensure that the failover mechanism functions as expected and that the system can continue operating smoothly during real-world disruptions.