Preparing clusters to replicate Ozone data

You must prepare the clusters, create buckets in the target cluster, and configure additional configurations for OBS bucket replication before you create Ozone replication policies in Cloudera Private Cloud Base Replication Manager.

Before you create Ozone replication policies, you must ensure that you do not use the following source and target Cloudera Manager combinations as these combinations are incompatible for Ozone replication:


Source Cloudera Manager version	Target Cloudera Manager version
7.7.1 through 7.7.1 CHF3	7.7.1 CHF4 through 7.7.1 CHF23
7.7.1 through 7.71 CHF3	7.11.3 through 7.11.3 CHF9
7.7.1 CHF4 through 7.7.1 CHF21	7.7.1 CHF22 through 7.7.1 CHF23
7.7.1 CHF4 through 7.7.1 CHF21	7.11.3 CHF8 through 7.11.3 CHF9
7.11.3 through 7.11.3 CHF7	7.7.1 CHF22 through 7.7.1 CHF23
7.11.3 through 7.11.3 CHF7	7.11.3 CHF8 through 7.11.3 CHF9

Complete the following prerequisites to create Ozone replication policies:

Have you added the source cluster as a peer to the target cluster?
For information about adding a source cluster as a peer, see Adding cluster as a peer.
Have you created the bucket on the target cluster of the same type as the bucket on the source cluster from which the replication policy replicates data?
tip
Create a volume and then the bucket. For more information, see Managing storage elements using CLI..
The following sample commands create a volume and an FSO bucket:
```
ozone sh volume create o3://ozone1/vol1
ozone sh bucket create o3://ozone1/vol1/buck1 --layout FILE_SYSTEM_OPTIMIZED
```
The following sample command creates a volume and an OBS bucket:
```
ozone sh bucket create /s3v/buck2 --layout OBJECT_STORE
```
Are the additional configurations required for OBS bucket replication configured when the source bucket is an OBS bucket?
For more information, see Configuring properties for OBS bucket replication using Ozone replication policies.
note
The OBS-to-OBS replication is successful only if the underlying buckets used in the Ozone replication policy have an OBS layout.
Are the source and target clusters SSL-enabled? If so, ensure that the SSL/TLS certificate exchange between two Cloudera Manager instances that manage source and target clusters respectively is configured.
For more information, see Configuring SSL/TLS certificate exchange between two Cloudera Manager instances.
Is Kerberos enabled on both the clusters? If so, perform the following steps:
1. Configure a user with permissions to access HDFS and Ozone.
2. Run the sudo usermod -a -G om bdr command to add the group name of the user (For example, the group name bdr) to the Ozone service configuration in target Cloudera Manager:
important
If Kerberos is enabled on both the clusters, you must run the kinit -kt /[***PATH***]/[***TO***]/ozone.keytab command (the absolute path to the Ozone service's keytab) before you run any Ozone commands. For example, kinit -kt /.../ozone.keytab om/[***PRINCIPAL***]@[***REALM.SAMPLE***].
Is Ranger enabled on the source cluster? If so, complete the following steps on the Ranger UI from source Cloudera Manager:
1. Log into Ranger UI from source Cloudera Manager.
2. Click cm_ozone on the Service Manager page.
3. Add the user (that you configured in the previous step) to the all - volume, bucket, key, all - volume, and all - volume, bucket policy names, and then set the groups for this policy as public.
Is Ranger KMS enabled on the source and target clusters? If so, complete the following steps for the kms-site.xml file for the Ranger_KMS service on the source and target clusters:
1. Locate and open the kms-site.xml file on the source Cloudera Manager.
2. Add the following key-value pairs:
  - hadoop.kms.proxyuser.om.hosts=*
  - hadoop.kms.proxyuser.om.groups=*
  - hadoop.kms.proxyuser.om.users=*
3. Save the file.
4. Restart the Ranger_KMS service for the changes to take effect.
5. Locate and open the kms-site.xml file on the target Cloudera Manager.
6. Add the following key-value pairs:
  - hadoop.kms.proxyuser.om.hosts=*
  - hadoop.kms.proxyuser.om.groups=*
  - hadoop.kms.proxyuser.om.users=*
7. Save the file.
8. Restart the Ranger_KMS service for the changes to take effect.

Are the following permissions enabled if the source and target clusters are secure, and Ranger is enabled for Ozone?

note

In 7.11.3 CHF10 and lower versions, the Ozone service uses hive or om usernames to run the Ozone commands during the Ozone replication policy runs. The service ignores the user specified in the Run as Username and Run on Peer as Username fields during Ozone replication policy creation to run the Ozone commands.

Starting from 7.11.3 CHF11, the Ozone commands are run impersonating the users that you specify in the Run as Username and Run on Peer as Username fields in the Create Ozone replication policy wizard when the Ozone replication is run. The user accessing the buckets for the OBS-to-OBS replication is determined by the access key specified in the fs.s3a.access.key property. For information about the property, see Configuring properties for OBS bucket replication using Ozone replication policies.


Resource	User permissions
On the source cluster:
srcVolume srcVolume/srcBucket srcVolume/srcBucket/* The bucket srcVolume/srcBucket must be owned by srcUser^, or the srcUser^ must be an Ozone administrator (in order to create snapshots in this bucket). /user /user/`[*srcUser*]`	Must be readable by srcUser^*
/user/`[*srcUser]`/ The bucket /user/`[*srcUser]` must already exist, or must be createable by srcUser^. The Ozone service must allow the users om and hive to impersonate srcUser^*.	Must be readable/writable by srcUser^*
On the destination cluster:
dstVolume dstVolume/dstBucket The bucket dstVolume/dstBucket is owned by dstUser^, or dstUser^ is an Ozone administrator (to create snapshots in this bucket). /user /user/`[*dstUser*]`	Must be readable dstUser^*
dstVolume/dstBucket/* /user/`[*dstUser]`/ The bucket /user/`[*dstUser]` must already exist, or must be createable by dstUser^. The Ozone service must allow the users om and hive to impersonate dstUser^*.	Must be readable/writable by dstUser^*
/user/`[*dstUser]`/	Must be readable by yarn user for YARN to pick up the container configuration for the MapReduce job.
*The srcUser is the user that you specify in Run on Peer as Username field, and the dstUser is the user that you specify in the Run as Username field in the Create Ozone replication policy wizard.