Configuring srm-control

Cloudera Manager automatically generates a configuration file for the srm-control tool. If both the co-located and external Kafka clusters are unsecured, the default configuration can be used, without making any changes. If however, any of the clusters taking part in the replication process use any type of security, additional configuration is required.

The srm-control tool functions similarly to any Kafka client. It reads data from and writes data to Kafka topics. More specifically, it manipulates Streams Replication Manager's (SRM) internal configuration topic (stored within Kafka) that contains the replication allow and deny lists.

The srm-control tool requires a properties file which specifies information about all clusters taking part in the replication process. That is, the properties file contains the cluster names (aliases), the bootstrap servers, and security related properties of each cluster.

This information, however, is not unique to the tool, as the SRM service (Driver and Service roles) also requires these properties to be set. Therefore, the configuration of the tool can be viewed as a subset of the SRM service's configuration. Because of this and because the SRM service is configured with Cloudera Manager, Cloudera Manager is capable of automatically creating a configuration file for the tool based on the configuration of the SRM service.

The configuration file is located at /etc/streams_replication_manager/conf/ By default the tool uses this configuration file.

The default configuration generated by Cloudera Manager is dynamic. It is updated any time you deploy the client configuration for SRM. For example, if you add a new cluster for replication or change an existing one, the changes you made are automatically added to the default tool configuration once client configuration is deployed.

This automation simplifies the process of configuring the tool. If the Kafka clusters that SRM is connecting to are not secured, then no additional configuration is needed. The default will contain all necessary properties. In cases like this you only need to ensure that the SRM service is correctly configured.

However, if any of the Kafka clusters use any type of encryption or authentication, additional configuration is required. This is because the generated configuration by default does not contain any sensitive TLS/SSL or SASL properties required to access the Kafka clusters. Providing this information to the tool requires additional configuration by the user.

There are five configuration tasks related to setting up sensitive properties for the tool. These are as follows:
  • Configuring the SRM client’s secure storage
  • Configuring TLS/SSL properties
  • Configuring Kerberos properties
  • Configuring properties for non-Kerberos authentication mechanisms
  • Setting the secure storage password as an environment variable
Which of these tasks you need to complete depends on the security configuration of the clusters that SRM connects to and the method used to define the co-located clusters. Review the following flowchart to see which of the tasks you need to complete and in what order.