Configure Kafka rack awareness
Learn how to configure rack awareness and multi-level rack awareness for Kafka brokers and clients.
Racks provide information about the physical location of a broker or a client. A Kafka deployment can be made rack aware by configuring rack awareness for the Kafka brokers and clients respectively. Enabling rack awareness can help in hardening your deployment, it provides durability guarantees for your Kafka service, and significantly decreases the chances of data loss.
The following tasks give step by step instructions on how you can configure and enable rack awareness and multi-level rack awareness for Kafka brokers and clients. The following covers configuration only. If you want to learn more about the rack awareness feature and how rack-aware Kafka deployments behave, see Kafka rack awareness.
Configuring rack awareness for Kafka brokers
Learn how to configure rack awareness for Kafka brokers.
Rack awareness can be enabled and configured by specifying rack IDs. This can be done in two ways.
You can set the rack IDs on the level of the host machine in Cloudera Manager and configure Kafka to use the rack IDs specified for the host machines. Rack IDs are specified with the Enable Rack Awareness property.
action in Cloudera Manager. Kafka can be configured to use these IDs by selecting theAlternatively, you can manually specify the rack ID for each broker role using the Broker Rack ID property. In this case, selecting Enable Rack Awareness is not required.
If IDs are specified in Broker Rack ID and Enable Rack Awareness is selected, the ID's specified in Broker Rack ID take precedence.
- In order for rack awareness to properly function, the brokers in your deployment must be spread across available racks. If all brokers are deployed on the same rack, enabling and configuring rack awareness will not provide you with any benefits.
- If you previously configured and enabled rack awareness by manually configuring the
broker.rack
property with Kafka Broker Advanced Configuration Snippet (Safety Valve), ensure that you remove allbroker.rack
entries from the advanced configuration snippet. The advanced configuration snippet takes precedence and overwrites the configuration set by both Enable Rack Awareness and Broker Rack ID. - If you want to specify the rack IDs on the level of the host, you must specify rack information for your hosts before you start the following procedure. Complete Specifying Racks for Hosts.
- If you are using Broker Rack ID to set rack IDs, ensure that you set the property for each broker instance separately. Do not specify this property on a Kafka service level.
Configuring multi-level rack awareness for brokers
Learn how to enable and configure multi-level rack awareness for brokers.
Multi-level rack awareness can be enabled and configured by specifying multi-level rack IDs and selecting the Enable multi-level rack awareness Kafka service property.
A multi-level rack ID has a different format than a standard rack ID. It is an absolute
path, it starts with a slash ( / ), but does not end in a slash. For example,
/uswest/R0
or /DC1/Rack1/HostA
. The ID can be specified
in two ways.
You can set the rack IDs on the level of the host machine in Cloudera Manager and configure Kafka to use the rack IDs specified for the host machines. Rack IDs are specified with the Enable Rack Awareness property.
action in Cloudera Manager. Kafka can be configured to use these IDs by selecting theAlternatively, you can manually specify the rack ID for each broker role using the Broker Rack ID property. In this case, selecting Enable Rack Awareness is not required.
If IDs are specified in Broker Rack ID and Enable Rack Awareness is selected, the ID's specified in Broker Rack ID take precedence.
- In order for multi-level rack awareness to properly function, the topology of your deployment must be compatible. That is, the brokers in your deployment must be spread across available physical infrastructure (for example DCs and racks). If your deployment topology is not compatible, enabling and configuring multi-level rack awareness will not provide you with any benefits.
- If you previously configured and enabled rack awareness by manually configuring the
broker.rack
property with Kafka Broker Advanced Configuration Snippet (Safety Valve), ensure that you remove allbroker.rack
entries from the advanced configuration snippet. The advanced configuration snippet takes precedence and overwrites the configuration set by both Enable Rack Awareness and Broker Rack ID. - If you want to specify the rack IDs on the level of the host, you must specify rack information for your hosts before you start the following procedure. Complete Specifying Racks for Hosts.
- If you are using Broker Rack ID to set rack IDs, ensure that you set the property for each broker instance separately. Do not specify this property on a Kafka service level.
Multi-level rack awareness is enabled for the broker. The brokers create replica assignments with multi-level rack awareness guarantees.
Configuring rack awareness for Kafka consumers
Learn how to make Kafka consumers rack aware by enabling and configuring follower fetching.
Kafka Consumers can be made rack aware enabling follower fetching for your Kafka
deployment. Follower fetching can be enabled by configuring the
replica.selector.class
property for the broker and configuring the
client.rack
property in the consumer’s configuration. The
replica.selector.class
property is not directly available for
configuration in Cloudera Manager and you must use an advanced security snippet to configure
it.
Configuring multi-level rack awareness for consumers
Learn how to configure consumer follower fetching in Kafka deployment that has multi-level rack awareness enabled.
client.rack
property in the consumer’s configuration.Configuring rack awareness for Kafka producers
Learn how to enable and configure rack awareness for Kafka producers.
Enabling rack awareness for Kafka producers involves configuring your Kafka deployment in a
way that ensures that producers commit messages to at least two separate brokers that are
deployed on different racks. This can be done by configuring your producers to provide the
highest available guarantee on message delivery and configuring
min.insync.replicas
for your topics.