Deploy for Production
This section describes how to set up a production cluster of Redpanda.
Provision hardware according to these requirements:
XFS for the data directory of Redpanda (
/var/lib/redpanda/data). NFS is not supported.
A kernel that is at least 3.10.0-514, 4.18 or newer
Local NVMe, RAID-0 when using multiple disks
2GB of memory per core
33145- internal RPC
9092- Kafka API
8082- HTTP Proxy
8081- Schema Registry
9644- Prometheus and Admin API
|You can use Terraform to deploy Redpanda.|
Install Redpanda on each system you want to be part of your cluster. There are binaries available for Fedora/RedHat or Debian systems.
You can also install Redpanda using an Ansible playbook.
curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.rpm.sh' | \ sudo -E bash && sudo yum install redpanda -y
curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | \ sudo -E bash && sudo apt install redpanda -y
Redpanda Console is a developer-friendly web UI for managing and debugging your Redpanda cluster and your applications.
For each new release, Redpanda compiles the Redpanda Console to a single binary for Linux, macOS, and Windows. You can find the binaries in the attachments of each release on GitHub.
curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.rpm.sh' | \ sudo -E bash && sudo yum install redpanda-console -y
curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | \ sudo -E bash && sudo apt-get install redpanda-console -y
By default, Redpanda is installed in development mode, which turns off hardware optimization.
To enable hardware optimization, set Redpanda to run in production mode:
sudo rpk redpanda mode production
To tune the hardware, on each node, run:
sudo rpk redpanda tune all
For more details, see the autotuner reference.
Optional: Benchmark your SSD
On taller machines, Redpanda recommends benchmarking your SSD. This can be done with rpk iotune. You only need to run this once.
For reference, a local NVMe SSD should yield around 1GB/s sustained writes.
If you’re on AWS, GCP, or Azure, creating a new instance and upgrading to an image with a recent Linux kernel version is often the easiest way to work around bad devices.
Configure Redpanda using the
rpk redpanda config bootstrap command, then start Redpanda:
sudo rpk redpanda config bootstrap --self <private-ip> --ips <seed-node-ips> && \ sudo rpk redpanda config set redpanda.empty_seed_starts_cluster false && \ sudo systemctl start redpanda-tuner redpanda
--selfflag tells Redpanda the interface address to bind to. Usually this is its private IP.
--ipsflag lists all the seed nodes in the cluster, including the one being started. Seed nodes correspond to the
--ipsflag must be set identically (with nodes listed in identical order) on each node.
When a Redpanda cluster starts, it instantiates a controller Raft group with all the seed nodes that are specified in the
--ips flag. After all seed nodes complete their startup procedure and become accessible, the cluster is then available. After that, non-seed nodes start up and are added to the cluster.
Start Redpanda Console:
sudo systemctl start redpanda-console
Make sure that Redpanda Console is active and running:
sudo systemctl status redpanda-console
To verify that the Redpanda cluster is up and running, check the logs:
journalctl -u redpanda
If topics were initially created in a test environment with a replication factor of
rpk topic alter-config to change the topic replication factor:
rpk topic alter-config [TOPICS...] --set replication.factor=3
To create a topic:
rpk topic create panda
This section provides information for creating your own automation for deploying Redpanda clusters without using any of the tools that Redpanda supports for setting up a cluster:
|Redpanda strongly recommends using one of these supported deployment tools. See Automate Deploying for Production.|
Redpanda cluster configuration is written with the Admin API and
rpk cluster config CLIs.
In the special case where you want to provide configuration to Redpanda
before it starts for the first time, you can write a
in the same directory as
This file is only read on the first startup of the cluster. Any subsequent
.bootstrap.yaml are ignored, so changes to
cluster configuration must be done with the Admin API.
The content format is a YAML dictionary of cluster configuration properties. For example, to initialize a cluster with Admin API authentication enabled
and a single superuser, the
.bootstrap.yaml file would contain the following:
admin_api_require_auth: true superusers: - alice
With this configuration, the Admin API is not accessible until you bootstrap a user account.
When using username/password authentication, it’s helpful to be able to create one user before the cluster starts for the first time.
Do this by setting the
RP_BOOTSTRAP_USER environment variable
when starting Redpanda for the first time. The value has the format
<username>:<password>. For example, you could set
The Admin API is used to create SASL user accounts and ACLs, so it’s important to think about how you secure it when creating a cluster.
No authentication, but listening only on 127.0.0.1: This may be appropriate if your Redpanda processes are running in an environment where only administrators can access the host.
mTLS authentication: You can generate client and server x509 certificates before starting Redpanda for the first time, refer to them in
redpanda.yaml, and use the client certificate when accessing the Admin API.
Username/password authentication: Use the combination of
RP_BOOTSTRAP_USERto access the Admin API username/password authentication. You probably still want to enable TLS on the Admin API endpoint to protect credentials in flight.
Seed servers help new nodes join a cluster by directing requests from newly-started nodes to an existing cluster. The seed_servers node configuration property controls how Redpanda finds its peers when initially forming a cluster. It is dependent on the empty_seed_starts_cluster node configuration property.
Starting in Redpanda version 22.3, you should explicitly set
false on every node, and every node in the cluster should have the same value set for
seed_servers. With this set of configurations, Redpanda clusters form with these guidelines:
When a node starts and it is a seed server (its address is in the
seed_serverslist), it waits for all other seed servers to start up, and it forms a cluster with all seed servers as members.
When a node starts and it is not a seed server, it sends requests to the seed servers to join the cluster.
It is essential that all seed servers have identical values for the
seed_servers list. Redpanda strongly recommends at least three seed nodes when forming a cluster. Each seed server decreases the likelihood of unintentionally forming a split brain cluster. To ensure nodes can always discover the cluster, at least one seed node should be available at all times.
By default, for backward compatibility,
empty_seed_starts_cluster is set to
true, and Redpanda clusters form with the guidelines used prior to version 22.3:
When a node starts with an empty
seed_serverslist, it creates a single node cluster with itself as the only member.
When a node starts with a non-empty
seed_serverslist, it sends requests to the nodes in that list to join the cluster.
You should never have more than one node with an empty
seed_servers list, which would result in the creation of multiple clusters.
Redpanda expects its storage to be persistent, and it’s an error to erase a node’s drive and restart it. However, in some environments (like when migrating to a different node pool on Kubernetes), truly persistent storage is unavailable, and nodes may find their data volumes erased. For such environments, Redpanda recommends setting
Redpanda automatically generates unique node IDs for each new node. This means that you don’t need to include node IDs in configuration files or worry about policies on
If you choose to assign node IDs, make sure to use a fresh
node_id each time you add a node to the cluster.
|Never reuse node IDs, even for nodes that have been decommissioned and restarted empty. Doing so can result in an inconsistent state.|
Deployment automation should place each node into maintenance mode and wait for it to drain leaderships before restarting it with a newer version of Redpanda. For information about how to drive a rolling upgrade of a Redpanda cluster, see Node Maintenance Mode.
Rolling restarts preserve high availability and reduce risk during upgrades. Check the cluster’s health after upgrading each node. Rolling back an upgrade to an earlier feature release is only supported until the last node has been updated, so it’s important to identify any issues before that point.
If clients will connect from a different subnet, see Configuring Listeners.