Preparing clusters for Ozone replication policies

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.

Complete the following checklist to ensure that the clusters are ready to be used in an Ozone replication policy:

Have you added the source and target clusters on the Management Console > Clusters page?
For more information, see Adding clusters to a Cloudera Private Cloud Data Services deployment.
important
Consider the following limitations before you add clusters:
- Only users with admin and poweruser roles can add clusters to use in Replication Manager.
- When Auto-TLS is enabled for a cluster, you must use the Cloudera Manager hostname to add a cluster.
- If a Cloudera Manager instance manages multiple clusters, you cannot include those clusters for replication in Cloudera Private Cloud Data Services Replication Manager.
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.
note
The OBS-to-OBS replication is successful only if the underlying buckets used in the Ozone replication policy have an OBS layout.
Do you need to replicate data securely? 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.

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.

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 following command to add the group name of the user (For example, the group name bdr) to the Ozone service configuration in target Cloudera Manager:
  sudo usermod -a -G om bdr
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, you must:
1. 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.
2. complete the following steps for the Ranger service in source Cloudera Manager:
  1. Go to the source Cloudera Manager > Clusters > Ranger service > Configuration tab.
  2. Locate the Ranger KMS Server with KTS Advanced Configuration Snippet (Safety Valve) for conf/kms-site.xml property.
  3. Add the following key-value pairs:
    - hadoop.kms.proxyuser.om.hosts=*
    - hadoop.kms.proxyuser.om.groups=*
    - hadoop.kms.proxyuser.om.users=*
  4. Save the changes.
  5. Restart the Ranger service for the changes to take effect.