Creating a Replication Group

You can create a replication group by selecting desired replication clusters and configuring active/passive relationships and a backup policy between the replication clusters. The namespace bound to the replication group backs up data based on the configuration of the replication group.

Prerequisites

Procedure

  1. Choose Data Protection > Configuration > Cross-Site DR > Replication Group.
  2. Click Create.

    The Create Replication Group page is displayed on the right.

  3. Set a name for the replication group.

    • The name contains 1 to 255 characters.
    • The name contains letters, digits, hyphens (-), and underscores (_), and must start with a letter and cannot end with a hyphen (-) or underscore (_).

  4. Select a policy type for the replication group.

    • Replica: Complete data is replicated to all clusters.

      For example, if a replication group has three clusters, data of all buckets in the replication group is stored at these clusters.

    • EC: Data is divided into multiple data blocks and stored at the data fragment clusters. If you select this option, you need to specify the number of parity fragments. The number of parity fragments is the number of nodes that can be faulty in a replication group. If a cluster is faulty, data of the faulty cluster can be calculated by reading data of other clusters. EC reduces storage space occupation and saves costs.

      For example, three clusters are selected, including two data fragment clusters for storing data and one parity fragment cluster for storing parity data. If a cluster that stores data is faulty, the data of the faulty cluster can be calculated based on the data of the parity cluster and the data of the other data cluster.

  5. In the Available Replication Clusters list, select replication clusters. In the Selected Replication Clusters list, set Cluster Type and Replication Mode of the clusters. If only one active cluster is selected, you can specify a passive cluster among all selected passive clusters to automatically take over services in case of a fault of the active cluster. Select the synchronous or asynchronous replication mode for the clusters. The sequence of selecting replication clusters is used as the DNS scheduling sequence by default. The first healthy active cluster in the sequence receives services. In the Selected Replication Clusters list, you can click the up or down arrow to adjust the sequence of replication clusters to adjust the DNS scheduling sequence of the replication group.

    • If you select Replica for the policy type, select at least two clusters (containing at least one active cluster).
    • If you select EC for the policy type, select at least (2 + the number of parity fragments) clusters (containing at least one active cluster).
    • By default, the passive cluster (auto takeover) is in the read-only state, and the namespace associated with the replication group of the passive cluster (auto takeover) is also in the read-only state. If the active cluster is faulty, the cluster (auto takeover) automatically switches from the read-only state to the read/write state, so do the associated namespace.
    • For the same cluster type, replication type, and DNS scheduling sequence, only one replication group can be created, while for the same cluster type and replication type, and different DNS scheduling sequences, different replication groups can be created.
    • Synchronous replication is used between two synchronous replication clusters, and asynchronous replication is used between other clusters. If a replication group contains synchronous replication clusters, the number of synchronous replication clusters can only be 2 or 3, and the number of synchronous and asynchronous replication clusters must be less than or equal to 12.
    • If the policy type of a replication group is EC, clusters in the replication group do not support the synchronous replication mode.

  6. Click OK.
  7. If a replication group contains synchronous replication clusters, the system will verify the replication group configuration when you click OK. If the configuration is not as recommended, a high-risk warning message will be displayed. In this case, perform operations as prompted.

    • The synchronization link latency directly affects the front-end service performance. Therefore, you need to detect the synchronization link latency. If the synchronization link latency is greater than 10 ms, a high-risk warning message will be displayed. In this case, you are advised not to configure any synchronous replication cluster in the replication group.
    • It is recommended that synchronous replication clusters take precedence over asynchronous replication clusters in taking over services. Therefore, in the following scenarios, a high-risk warning message will be displayed on the configuration plane. In such scenarios, you are advised not to configure any synchronous replication cluster in the replication group.
      • The DNS priority of asynchronous replication clusters is higher than that of synchronous replication clusters when both synchronous and asynchronous replication clusters are active.
      • Synchronous replication clusters are passive when a passive asynchronous replication cluster exists and auto takeover is enabled.
      • Synchronous replication clusters are passive or passive (auto takeover) when an active asynchronous replication cluster exists.

Follow-up Procedure

For a replication group of the EC policy type, you can run the change rgm rg_bkts command on the CLI to change the retention period of a local copy. The default value is 0, indicating that the local copy of an object will be deleted immediately after cross-site EC is complete. If the retention period is too long, the amount of data written to the site increases excessively. Set this parameter based on the customer's service scenario. 
admin:/>change rgm rg_bkts fs_id=37 bkt_name=bkt1 retention_time=30
Command executed successfully.
Parent topic: Managing a Replication Group