We recommend the following setup for deploying Longhorn in production.

  • 3 nodes
  • 4 vCPUs per node
  • 4 GiB per node
  • SSD/NVMe or similar performance block device on the node for storage (recommended)
  • HDD/Spinning Disk or similar performance block device on the node for storage (verified)
    • 500/250 max IOPS per volume (1 MiB I/O)
    • 500/250 max throughput per volume (MiB/s)

Architecture

Longhorn supports the following architectures:

  1. AMD64
  2. ARM64 (experimental)
  3. s390x (experimental)

Software

It’s recommended to run an OS from the following list for every node of your Kubernetes cluster:

  1. RancherOS

We recommend the following setup for nodes and disks.

Use a Dedicated Disk

It’s recommended to dedicate a disk for Longhorn storage for production, instead of using the root disk.

If you need to use the root disk, use the default setup which is 25%, and set overprovisioning percentage to 200% to minimize the chance of DiskPressure.

If you’re using a dedicated disk for Longhorn, you can lower the setting minimal available storage percentage to 10%.

For the Over-provisioning percentage, it depends on how much space your volume uses on average. For example, if your workload only uses half of the available volume size, you can set the Over-provisioning percentage to 200, which means Longhorn will consider the disk to have twice the schedulable size as its full size minus the reserved space.

Disk Space Management

Any extra disks must be written in the /etc/fstab file to allow automatic mounting after the machine reboots.

Don’t use a symbolic link for the extra disks. Use mount --bind instead of ln -s and make sure it’s in the file. For details, see the section about multiple disk support.

Configuring Default Disks Before and After Installation

To use a directory other than the default /var/lib/longhorn for storage, the Default Data Path setting can be changed before installing the system. For details on changing pre-installation settings, refer to this section.

The feature can be used to customize the default disk after installation. Customizing the default configurations for disks and nodes is useful for scaling the cluster because it eliminates the need to configure Longhorn manually for each new node if the node contains more than one disk, or if the disk configuration is different for new nodes. Remember to enable Create default disk only on labeled node if applicable.

Deploying Workloads

If you’re using ext4 as the filesystem of the volume, we recommend adding a liveness check to workloads to help automatically recover from a network-caused interruption, a node reboot, or a Docker restart. See for details.

We highly recommend using the built-in backup feature of Longhorn.

For each volume, schedule at least one recurring backup. If you must run Longhorn in production without a backupstore, then schedule at least one recurring snapshot for each volume.

Longhorn system will create snapshots automatically when rebuilding a replica. Recurring snapshots or backups can also automatically clean up the system-generated snapshot.

Guaranteed Instance Manager CPU

To be precise, you can set the percentage of a node total allocatable CPU reserved for all engine/replica manager pods by modifying settings Guaranteed Engine Manager CPU and Guaranteed Replica Manager CPU.

If you want to set a concrete value (milli CPU amount) for engine/replica manager pods on a specific node, you can update the fields or Replica Manager CPU Request of the node. Notice that these 2 fields will overwrite the above settings for the specific node.

The setting Guarantee Engine CPU is deprecated. For the system upgraded from old versions, Longhorn v1.1.1 will set the node fields mentioned above automatically to the same value as the deprecated setting then clean up the setting.

For details, refer to the settings references and Guaranteed Replica Manager CPU.

StorageClass

We don’t recommend modifying the default StorageClass named longhorn, since the change of parameters might cause issues during an upgrade later. If you want to change the parameters set in the StorageClass, you can create a new StorageClass by referring to the StorageClass examples.

Replica Node Level Soft Anti-Affinity

This setting should be set to false in production environment to ensure the best availability of the volume. Otherwise, one node down event may bring down more than one replicas of a volume.

Recommend: false