|
This is unreleased documentation for SUSE® Storage 1.12 (Dev). |
Multiple Disks
SUSE Storage supports using more than one disk on the nodes to store the volume data.
Disk Types
SUSE Storage supports two types of disks:
-
Filesystem-type disk (
diskType: filesystem): It is used by the V1 Data Engine. The disk must be formatted with an extent-based file system (for example, Ext4 or xfs) and mounted to a directory on the host. -
Block-type disk (
diskType: block): It is used by the V2 Data Engine. The disk is used as a raw block device without a file system.
Each disk type is tied to its corresponding data engine:
-
V1 volumes are scheduled only to file system-type disks.
-
V2 volumes are scheduled only to block-type disks.
Default Disk Behavior
When a node is first added to SUSE Storage, the system creates a default file system-type disk at /var/lib/longhorn. This default disk is used for V1 volumes unless you disable scheduling for it or add other file system-type disks.
Add a Disk
Add a File System-Type Disk
File system-type disks are used for V1 volumes. Before adding one to SUSE Storage, you must prepare and mount it on the host.
-
Choose a Disk: Select the physical or virtual disk for SUSE Storage storage and format it with an extent-based file system (for example, Ext4 or XFS).
-
Mount the Disk: Mount the disk to a directory on the host, such as
/mnt/example-disk. Ensure the directory is accessible and correctly configured.
After the disk is mounted, you can add it to SUSE Storage by using either the UI or the kubectl command-line tool.
Using the SUSE Storage UI
-
Go to the Nodes tab, select a node, and choose Edit Disks from the dropdown menu.
-
Add the disk’s mount path to the disk list.
Using kubectl
-
Run
kubectl edit node.longhorn.io <node-name>to modify the Longhorn node resource. -
Add the disk path to
spec.disks. For example:... spec: ... disks: ... example-disk: allowScheduling: true diskDriver: "" diskType: filesystem evictionRequested: false path: /mnt/example-disk storageReserved: 0 tags: [] ... -
Save and exit the editor.
Once a disk is added:
-
SUSE Storage automatically detects the disk’s storage details, such as maximum and available capacity.
-
If the disk is suitable for storing volume data, SUSE Storage begins scheduling volumes to it.
|
Use an Alternative Path for a File System-Type Disk on the Node
If you prefer to use a different path for a file system-type disk (rather than the original mount point), you can use mount --bind to create an alternative path. Do not use symbolic link (lh -s), as these are not properly resolved inside Longhorn pods.
Make sure the alternative path is remounted after a node reboot, for example, by adding it to /etc/fstab.
Add a Block-Type Disk
Block-type disks are used for V2 volumes. The V2 Data Engine requires raw block devices for direct access.
SUSE Storage supports several ways to manage block-type disks on a node:
-
NVMe disks: It is managed with the
nvmedriver. -
VirtIO disks: It is managed with the
virtio-blkdriver. -
Other block devices: It is managed with the
aiodriver.
Prerequisites
-
The V2 Data Engine must be enabled. See V2 Data Engine Quick Start.
-
SUSE Storage prevents adding block disks that contain an existing file system or partition table. Clean the disk first:
wipefs -a /path/to/block/device
Steps
You can add a block-type disk using the SUSE Storage UI or kubectl.
-
Using the SUSE Storage UI:
-
Go to the Nodes tab, select a node, and choose Edit Disks from the dropdown menu.
-
Add the block device path and set the disk type to Block.
-
-
Using
kubectlCommand:-
Run
kubectl edit node.longhorn.io <node-name>to edit the Longhorn node resource. -
Add the block disk to
spec.disks. For example:... spec: ... disks: ... block-disk: allowScheduling: true diskDriver: auto diskType: block evictionRequested: false path: /dev/sdb storageReserved: 0 tags: [] ... -
Save and exit the editor.
-
Disk Driver
The diskDriver field controls how SUSE Storage accesses the block device. Setting it to auto allows SUSE Storage to detect the appropriate driver automatically:
-
NVMe disks: It uses the
nvmedriver. Thepathcan be a BDF (Bus Device Function) notation (for example,0000:05:00.0). -
VirtIO disks: It uses the
virtio-blkdriver. Thepathcan also be a BDF notation. -
Other disks: It falls back to the
aio(Linux AIO) driver. Thepathshould be a standard device path (for example,/dev/sdb).
After the disk is added, check node.status.diskStatus to confirm that SUSE Storage detected the disk without errors and assigned the expected diskDriver.
|
When a disk is managed by the |
Using AIO Disks
When a block device is neither NVMe nor VirtIO, or when you want to force Linux AIO, configure it with diskDriver: aio and use a standard device path.
aio-disk:
allowScheduling: true
diskDriver: aio
diskType: block
evictionRequested: false
path: /dev/sdb
storageReserved: 0
tags: []
|
Using NVMe Disks
To let SUSE Storage use the nvme driver, add the disk by its BDF instead of the Linux device path.
-
Identify the available disks on the node. For example:
ls -al /sys/block/Example output:
lrwxrwxrwx 1 root root 0 Jul 30 12:20 loop0 -> ../devices/virtual/block/loop0 lrwxrwxrwx 1 root root 0 Jul 30 12:20 nvme0n1 -> ../devices/pci0000:00/0000:00:01.2/0000:02:00.0/nvme/nvme0/nvme0n1 lrwxrwxrwx 1 root root 0 Jul 30 12:20 nvme1n1 -> ../devices/pci0000:00/0000:00:01.2/0000:05:00.0/nvme/nvme1/nvme1n1 -
Find the BDF of the target NVMe disk. In the example above, the BDF of
/dev/nvme1n1is0000:05:00.0. -
Add the disk to
spec.disks. For example:nvme-disk: allowScheduling: true diskType: block diskDriver: auto evictionRequested: false path: 0000:05:00.0 storageReserved: 0 tags: []
If you instead add the same disk using /dev/nvme1n1, SUSE Storage treats it as an aio disk instead of an nvme disk.
Using VirtIO Disks
VirtIO disks follow the same pattern. To let SUSE Storage use the virtio-blk driver, add the disk by its BDF.
-
Identify the available disks on the node. For example:
ls -al /sys/block/Example output:
lrwxrwxrwx 1 root root 0 Feb 22 14:04 vda -> ../devices/pci0000:00/0000:00:02.3/0000:04:00.0/virtio2/block/vda lrwxrwxrwx 1 root root 0 Feb 22 14:24 vdb -> ../devices/pci0000:00/0000:00:02.6/0000:07:00.0/virtio5/block/vdb -
Find the BDF of the target VirtIO disk. In the example above, the BDF of
/dev/vdbis0000:07:00.0. -
Add the disk to
spec.disks. For example:virtio-disk: allowScheduling: true diskType: block diskDriver: auto evictionRequested: false path: 0000:07:00.0 storageReserved: 0 tags: []
If you instead add the same disk using /dev/vdb, SUSE Storage treats it as an aio disk instead of a virtio-blk disk.
Root Disk Reservation
You can use the Space Reserved field in the UI or spec.disks.<disk-name>.storageReserved to reserve a portion of any disk’s space (in bytes) for other purposes. This reserved space will not be used by SUSE Storage for volume data.
To maintain node stability when compute resources (for example, memory or disk) are under pressure, the kubelet requires some space to remain free. If these critical resources are exhausted, it can lead to node instability.
For the default file system-type disk at /var/lib/longhorn, SUSE Storage reserves 30% of the root disk space by default to help prevent issues such as DiskPressure conditions from the kubelet, particularly after scheduling multiple volumes. This behavior is controlled by the storage-reserved-percentage-for-default-disk setting.
This automatic reservation applies only to the default file system-type disk created for V1 volumes. Block-type disks for V2 volumes must be configured explicitly, including any storageReserved value that you want to apply.
Remove a Disk
Nodes and disks can be excluded from future scheduling. Note that any storage already scheduled on a node would not be automatically released when scheduling is disabled for that node.
To remove a disk:
-
Disable scheduling for the disk.
-
Ensure that no replicas or backing images remain on the disk, including any in an error state. For instructions on how to evict replicas from disabled disks, see Select Disks or Nodes for Eviction.
Once the disk is empty and scheduling is disabled, you can safely remove it from the node configuration.
Disk-Scheduling Configuration
There are two global settings that affect disk scheduling.
These settings apply to both file system-type and block-type disks. However, the V1 Data Engine uses sparse files for thin provisioning, so over-provisioning behavior is commonly discussed in the context of file system-type disks.
-
StorageOverProvisioningPercentagedefines the maximum total storage that can be scheduled on a disk, relative to its usable capacity. The formula is:
ScheduledStorage / (MaximumStorage - ReservedStorage)
By default, this setting is 100%.
For example, on a 200 GiB disk with 50 GiB reserved, SUSE Storage considers 150 GiB of usable space. With the default setting, SUSE Storage can schedule up to 150 GiB of volume data.
Since workloads typically do not consume the entire allocated volume size, increasing this setting can help optimize disk utilization. For V1 volumes, higher values are commonly used because the V1 Data Engine uses sparse files for thin provisioning.
-
StorageMinimalAvailablePercentagespecifies the minimum percentage of free space that must remain on a disk to schedule new replicas. The formula is:
AvailableStorage / MaximumStorage
By default, this setting is 25%.
For example, for a 200 GiB disk with 50 GiB reserved, SUSE Storage stops scheduling new replicas if available space falls below 37.5 GiB (25% of 150 GiB). A new volume also will not be scheduled if its size would push available space below that limit.
This setting helps prevent disks from becoming too full, which could lead to scheduling failures or volume operation issues.
|
SUSE Storage currently cannot fully enforce the
|