Streaming

Requirements and Recommendations

This topic provides the requirements and recommendations for provisioning servers to run Redpanda in production.

Operating system

  • Minimum version required of RHEL/CentOS: 8. Recommended: 9+

  • Minimum version required of Ubuntu: 20.04 LTS. Recommended: 22.04+

Recommendation: Linux kernel 4.19 or later for better performance.

Number of nodes

Provision one physical node or virtual machine (VM) for each Redpanda broker that you plan to deploy in your Redpanda cluster. Each Redpanda broker requires its own dedicated node for the following reasons:

  • Resource isolation: Redpanda brokers are designed to make full use of available system resources, including CPU and memory. By dedicating a node to each broker, you ensure that these resources aren’t shared with other applications or processes, avoiding potential performance bottlenecks or contention.

  • External networking: External clients should connect directly to the broker that owns the partition they’re interested in. This means that each broker must be individually addressable. As clients must connect to the specific broker that is the leader of the partition, they need a mechanism to directly address each broker in the cluster. Assigning each broker to its own dedicated node makes this direct addressing feasible, since each node will have a unique address. See External networking.

  • Fault tolerance: Ensuring each broker operates on a separate node enhances fault tolerance. If one node experiences issues, it won’t directly impact the other brokers.

Recommendations: Deploy at least three Redpanda brokers.

Prevent automatic node upgrades

Ensure that node and operating system (OS) upgrades are manually managed when running Redpanda in production. Manual control avoids unplanned reboots or replacements that disrupt Redpanda brokers, causing service downtime, data loss, or quorum instability.

Common issues with automatic node upgrades include:

  • Hard timeouts for graceful shutdowns that do not allow Redpanda brokers enough time to complete decommissioning or leadership transitions.

  • Replacements or reboots without ensuring data has been safely migrated or replicated, risking data loss.

  • Parallel upgrades across multiple nodes, which can disrupt quorum or reduce cluster availability.

Requirements:

  • Disable automatic node maintenance or upgrades.

CPU and memory

Requirements:

  • Each production node must have at least two physical CPU cores.

  • x86_64 (Westmere or newer) and Arm (AArch64) processors are supported.

  • Each Redpanda broker must have at least 2 GB of memory per core.

  • Each Redpanda broker must have at least 2 MB of memory for each topic partition replica.

    The total memory available for partition replicas is determined as a percentage of the cluster’s total memory, which is controlled by the topic_partitions_memory_allocation_percent setting. Each partition replica consumes topic_memory_per_partition bytes from this pool. If insufficient memory is available, topic operations will fail. You can adjust the allocation ratio using topic_partitions_memory_allocation_percent, but doing so is not recommended, as lowering it may lead to instability or degraded performance.

Recommendations:

  • Four physical cores for each node are strongly recommended.

Storage

Requirements:

  • An XFS or ext4 file system.

    The Redpanda data directory (/var/lib/redpanda/data) and the Tiered Storage cache must be mounted on an XFS or ext4 file system.

    The Network File System (NFS) is unsupported for use as the storage mechanism for the Redpanda data directory or for the Tiered Storage cache.

Recommendations:

  • Locally attached SSDs, typically NVMe (Non-Volatile Memory Express) devices, are strongly recommended for production deployments. They provide the high throughput and low latency needed for optimal Redpanda performance.

    See also: Disk and network self-test benchmarks.

  • Use an XFS file system for its enhanced performance with Redpanda workloads.

  • For setups with multiple disks, use a RAID-0 (striped) array. It boosts speed but lacks redundancy. A disk failure can lead to data loss.

Security

Recommendations:

  • If you’re using a cloud platform, use IAM roles to restrict access to resources in your cluster.

  • Secure your Redpanda cluster with TLS encryption and SASL authentication.

External networking

  • For external access, each node in your cluster must have a static, externally accessible IP address.

  • Minimum 10 GigE (10 Gigabit Ethernet) connection to ensure:

    • High data throughput

    • Reduced data transfer latency

    • Scalability for increased network traffic

Tuning

Before deploying Redpanda to production, each node that runs Redpanda must be tuned to optimize the Linux kernel for Redpanda processes.

See Deploy for Production: Manual.

Object storage providers for Tiered Storage

Redpanda supports the following storage providers for Tiered Storage:

  • Amazon Simple Storage Service (S3)

  • Google Cloud Storage (GCS), using the Google Cloud Platform S3 API

  • Azure Blob Storage (ABS)

Cloud instance types

Recommendations:

  • Use a cloud instance type that supports locally attached SSDs with an XFS file system. Local SSDs, typically NVMe devices, offer high I/O operations per second (IOPS) and minimal latency, while XFS offers enhanced performance with Redpanda workloads.

  • For most workloads, use a general-purpose instance type that has 4 GB of memory per vCPU. Choose a storage-optimized instance type when you need large local disks, such as for longer retention on local storage, or when storage IOPS limits the workload.

  • You can replace a recommended instance type with one that has strictly better capabilities, although the replacement is usually less cost-efficient. For example, R6id instances can replace M6id instances because they have the same capabilities and twice as much memory.

  • Newer instance generations generally provide better performance per dollar, but they may not be available in all regions. If an instance type isn’t available in your target region, consider an older generation.

Amazon

  • General purpose: General-purpose instances provide a balance of compute, memory, and networking resources, and they generally have better availability than storage-optimized and other special-purpose instance types.

  • Storage optimized (high-performance disks): These instances deliver very high volumes of low-latency, random IOPS. Choose them when storage IOPS limits the workload.

  • Storage optimized (large disks): These instances provide dense local storage at a lower cost per GB. Choose them when you need large local disks, such as for longer retention on local storage.

AWS instance family names indicate their capabilities:

  • A d after the generation number indicates locally attached SSDs. Storage-optimized families, whose names start with i, always have locally attached SSDs.

  • A g after the generation number indicates AWS Graviton (Arm) processors, which often provide slightly better value per dollar.

  • An i or a after the generation number indicates Intel or AMD x86 processors, respectively. Both are supported.

Azure

  • General purpose: General-purpose VM sizes provide a balanced CPU-to-memory ratio. The D family has 4 GB of memory per vCPU. Later versions are better: v6 introduced larger and faster NVMe disks than v4 and v5, and v7 pairs those disks with newer CPUs but may have less availability.

  • Storage optimized: The L family provides large, fast local disks. These VM sizes are suitable when you need more local storage, or more storage performance, than the general-purpose sizes offer, but they are more expensive.

Azure VM size names use modifiers that indicate their capabilities:

  • The d modifier indicates locally attached disks. Choose sizes that include d.

  • The a modifier indicates AMD processors, which are supported.

  • The s modifier indicates Premium Storage support, which does not affect Redpanda. Sizes with and without s are interchangeable.

  • The l modifier indicates a reduced memory-to-vCPU ratio. For example, Dlds_v5 has 2 GB of memory per vCPU. Avoid these sizes unless you intend to use less memory.

  • The p modifier indicates Arm processors, which are supported.

Google

On Google Cloud, prefer general-purpose machine types with locally attached SSDs. Machine types that end in -lssd include a fixed number of local SSDs. For older machine types, you choose the number of disks to attach.

Next steps

Suggested reading

Suggested labs

See more
Search all labs