Optimize the availability of your clusters by configuring and tuning Redpanda cluster properties.
Limit Client Connections
A malicious Kafka client application may create many network connections to execute its attacks. A poorly configured application may also create an excessive number of connections. To mitigate the risk of a client creating too many connections and using too many system resources, you can configure a Redpanda cluster to impose limits on the number of created client connections for its Kafka protocol server nodes.
The following cluster properties limit the number of connections:
- kafka_connections_max: Similar to Kafka's
max.connections, this property sets the maximum number of connections created by a node.
- kafka_connections_max_per_ip: Similar to Kafka's
max.connections.per.ip, this property sets the maximum number of connections created per IP address by a node.
- kafka_connections_max_overrides: A list of IP addresses for which kafka_connections_max_per_ip is overridden and doesn't apply.
Redpanda also provides properties to manage the rate of connection creation:
- kafka_connection_rate_limit: This property limits the maximum rate of connections created per second. It applies per CPU core.
- kafka_connection_rate_limit_overrides: A list of IP addresses for which kafka_connection_rate_limit is overridden and doesn't apply.
- These connection limit properties are disabled by default. You must manually enable them.
- Typically, a client opens two or three connections, so the total number of connections is not equal to the number of clients. For example, to support 100 clients, you might set your connection limit to 300.
Prevent crash loops
A Redpanda node may create a non-insignificant amount of log segments at startup. If a node were to crash after startup, and if it were to get stuck in a crash loop, it would produce progressively more stored state that uses more disk space and takes more time for each restart to process.
To prevent infinite crash loops, the node property crash_loop_limit sets an upper limit on the number of consecutive crashes that can happen within one hour of each other. Once it reaches the limit, a node cannot restart until its internal consecutive crash counter is reset to zero by one of the following conditions:
- The node configuration file,
redpanda.yaml, is updated.
startup_logfile in the node's data_directory is manually deleted.
- One hour elapses since the last crash.
- The node is cleanly shut down. (This is not possible after
crash_loop_limithas been reached and the node cannot be restarted.)
- The limit property is disabled by default. You must manually enable it by setting it to a non-zero value.
- If the limit is less than two, the node will be blocked from restarting after every single crash, until one of the reset conditions is met.