Enabling Replication Between Clusters in Different Kerberos Realms

Minimum Required Role: Cluster Administrator (also provided by Full Administrator)

If you want to enable replication between clusters that reside in different Kerberos Realms, there are some additional setup steps you need to perform to ensure that the source and target clusters can communicate.

For HDFS replication:

  1. On the hosts in the target cluster, ensure that the krb5.conf file on each host has the following information:
    • The kdc information for the source cluster's Kerberos realm.
    • Domain/host to realm mapping for the source cluster NameNode hosts.
  2. On the target cluster, through Cloudera Manager, add the realm of the source cluster to the Trusted Kerberos Realms configuration property.
    1. Go to the HDFS service.
    2. Click the Configuration tab.
    3. In the search field type "Trusted Kerberos" to find the Trusted Kerberos Realms property.
    4. Enter the source cluster realm.
    5. Click Save Changes to commit the changes.
  3. If your Cloudera Manager is less than 5.0.1, you must restart the JobTracker to enable it to pick up the new Trusted Kerberos Realm settings. Failure to restart the JobTracker prior to the first replication attempt may cause the JobTracker to fail.

For Hive replication:

  1. Perform the steps described above on the target cluster, including restarting the JobTracker.
  2. On the hosts in the source cluster, ensure that the krb5.conf file on each host has the following information:
    • The kdc information for the target cluster's Kerberos realm.
    • Domain/host to realm mapping for the target cluster NameNode hosts.
  3. On the source cluster, through Cloudera Manager, add the realm of the target cluster to the Trusted Kerberos Realms configuration property.
    1. Go to the HDFS service.
    2. Click the Configuration tab.
    3. In the search field type "Trusted Kerberos" to find the Trusted Kerberos Realms property.
    4. Enter the target cluster realm.
    5. Click Save Changes to commit the changes.
  4. It is not necessary to restart any services on the source cluster.