You can deploy Redpanda for production with a default deployment, which uses recommended deployment tools, or with a custom deployment, which uses unsupported deployment tools.
|
Note
|
|
To start deploying Redpanda for production, choose your deployment type:
-
Default deployment: Use recommended deployment tools.
-
Custom deployment: Use unsupported deployment tools.
This section describes how to set up a production cluster of Redpanda.
deploy:partial$linux/install-redpanda.adoc
deploy:partial$linux/install-fips.adoc
deploy:partial$linux/install-console.adoc
To get the best performance from your hardware, set Redpanda to production mode on each node and run the autotuner tool. The autotuner identifies the hardware configuration of your node and optimizes the Linux kernel to give you the best performance.
By default, Redpanda is installed in development mode, which turns off hardware optimization.
-
Make sure that your current Linux user has root privileges. The autotuner requires privileged access to the Linux kernel settings.
-
Set Redpanda to run in production mode:
sudo rpk redpanda mode production
-
Tune the Linux kernel:
sudo rpk redpanda tune all
Changes to the Linux kernel are not persisted. If a node restarts, make sure to run the autotuner again.
To automatically tune the Linux kernel on a Redpanda broker after the node restarts, enable the redpanda-tuner service, which runs rpk redpanda tune all:
-
For RHEL, after installing the rpm package, run
systemctlto both start and enable theredpanda-tunerservice:sudo systemctl start redpanda-tuner sudo systemctl enable redpanda-tuner -
For Ubuntu, after installing the apt package, run
systemctlto start theredpanda-tunerservice (which is already enabled):sudo systemctl start redpanda-tuner
For more details, see the autotuner reference.
After tuning the Linux kernel, you can optimize Redpanda for the I/O capabilities of your worker node by using rpk to run benchmarks that capture its read/write IOPS and bandwidth capabilities. After running the benchmarks rpk saves the results to an I/O configuration file (io-config.yaml) that Redpanda reads upon startup to optimize itself for the node.
|
Note
|
Unlike the autotuner, it isn’t necessary to run rpk iotune each time Redpanda is started, as its I/O output configuration file can be reused for each node that runs on the same type of hardware.
|
Run rpk iotune:
sudo rpk iotune # takes 10minsFor reference, a local NVMe SSD should yield around 1 GB/s sustained writes.
rpk iotune captures SSD wear and tear and gives accurate measurements
of what your hardware is capable of delivering. Run this before benchmarking.
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.
deploy:partial$linux/bootstrap.adoc
deploy:partial$linux/start-redpanda.adoc
deploy:partial$linux/start-console.adoc
deploy:partial$linux/verify-redpanda.adoc
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, such as Ansible Playbook, Helm Chart, or Kubernetes Operator.
|
Tip
|
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
the 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 .bootstrap.yaml file
in the same directory as redpanda.yaml.
This file is only read on the first startup of the cluster. Any subsequent
changes to .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:
- aliceWith 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 RP_BOOTSTRAP_USER to alice:letmein.
|
Note
|
RP_BOOTSTRAP_USER only creates a user account. You must still
set up authentication using cluster configuration.
|
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
admin_api_require_auth,superusers, andRP_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 brokers join a cluster by directing requests from newly-started brokers to an existing cluster. The seed_servers broker configuration property controls how Redpanda finds its peers when initially forming a cluster. It is dependent on the empty_seed_starts_cluster broker configuration property.
Starting with Redpanda version 22.3, you should explicitly set empty_seed_starts_cluster to false on every broker, and every broker 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 broker 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 broker 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 servers when forming a cluster. Each seed server decreases the likelihood of unintentionally forming a split brain cluster. To ensure brokers can always discover the cluster, at least one seed server 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 broker starts with an empty
seed_serverslist, it creates a single broker cluster with itself as the only member. -
When a broker starts with a non-empty
seed_serverslist, it sends requests to the brokers in that list to join the cluster.
You should never have more than one broker with an empty seed_servers list, which would result in the creation of multiple clusters.
|
Important
|
Redpanda expects its storage to be persistent, and it’s an error
to erase a broker’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 brokers may find their data volumes erased. For such environments, Redpanda recommends setting empty_seed_starts_cluster to false and designating a set of seed servers such that they couldn’t lose their storage simultaneously.
|
Redpanda automatically generates unique broker IDs for each new broker and assigns it to the node_id field in the broker configuration. This ensures safe and consistent cluster operations without requiring manual configuration.
|
Warning
|
Do not set
node_id manually.Redpanda assigns unique IDs automatically to prevent issues such as:
Manually setting or reusing |
deploy:partial$self-test.adoc
Deployment automation should place each broker into maintenance mode and wait for it to drain leadership before restarting it with a newer version of Redpanda. For more information, see Upgrade.
If upgrading multiple feature release versions of Redpanda in succession, make sure to verify that each version upgrades to completion before proceeding to the next version. You can verify by reading the /v1/features Admin API endpoint and checking that cluster_version has increased.
Starting with Redpanda version 23.1, the /v1/features endpoint also includes a node_latest_version attribute, and installers can verify that the cluster has activated any new functionality from a previous upgrade by checking for cluster_version == node_latest_version.