Beginners Guide to Stratis local storage management in CentOS/RHEL 8

Describing the Stratis Architecture

The current local storage solution in CentOS/RHEL includes many stable and mature technologies, including the device mapper (dm), the logical volume manager (LVM), and the XFS file system. Features provided by these components include massively scalable file systems, snapshots, redundant (RAID) logical devices, multipathing, thin provisioning, caching, deduplication, and support for virtual machines and containers. Each storage stack layer (dm, LVM, and XFS) is managed using layer-specific commands and utilities, requiring that system administrators manage physical devices, fixed-size volumes, and file systems as separate storage components.

A new generation of storage management solutions appeared in recent years, referred to as volume-managing file systems, that dynamically and transparently manage the volume layer as file systems are created and sized. However, although the community development of these file systems was ongoing for years, none reached the level of feature support and stability required to become the primary local storage for Red Hat Enterprise Linux.

With CentOS/RHEL 8, Red Hat introduces the Stratis storage management solution. Instead of developing from scratch, as other storage projects attempted, Stratis works with existing RHEL storage components. Stratis runs as a service that manages pools of physical storage devices and transparently creates and manages volumes for the file systems being created. Because Stratis uses existing storage drivers and tools, all of the advanced storage features that you currently use in LVM, XFS, and the device-mapper are also supported by Stratis.

In a volume-managed file system, file systems are built inside shared pools of disk devices using a concept known as thin provisioning. Stratis file systems do not have fixed sizes and no longer preallocate unused block space. Although the file system is still built on a hidden LVM volume, Stratis manages the underlying volume for you and can expand it when needed. The in-use size of a file system is seen as the amount of actual blocks in use by contained files. The space available to a file system is the amount of space still unused in the pooled devices on which it resides. Multiple file systems can reside in the same pool of disk devices, sharing the available space, but file systems can also reserve pool space to guarantee availability when needed.

Stratis uses stored metadata to recognize managed pools, volumes, and file systems. Therefore, file systems created by Stratis should never be reformatted or reconfigured manually; they should only be managed using Stratis tools and commands. Manually configuring Stratis file systems could cause the loss of that metadata and prevent Stratis from recognizing the file systems it has created.

You can create multiple pools with different sets of block devices. From each pool, you can create one or more file systems. Currently, you can create up to 224 file systems per pool. The following diagram illustrates how the elements of the Stratis storage management solution are positioned.

A pool groups block devices into the data tier and optionally the cache tier. The data tier focuses on flexibility and integrity and the cache tier focuses on improved performance. Because the cache tier is intended to improve performance, you should use block devices that have higher input/output per second (IOPS), such as SSDs.

Describing the Simplified Storage Stack

Stratis simplifies many aspects of local storage provisioning and configuration across a range of Red Hat products. For example, in earlier versions of the Anaconda installer, system administrators had to layer each aspect of disk management over the other. Now, the installer uses Stratis, simplifying disk setup. Other products that use Stratis include Cockpit, Red Hat Virtualization, and Red Hat Enterprise Linux Atomic Host. For all of these products, Stratis makes it simpler and less error-prone to manage storage space and snapshots. Stratis allows easier integration with the higher-level management tools than using any CLI programmatically.

Describing Stratis Layers

Internally, Stratis uses the Backstore subsystem to manage the block devices, and the Thinpool subsystem to manage the pools. The Backstore subsystem has a data tier that maintains the on-disk metadata on block devices and detects and corrects data corruption. The cache tier uses high-performance block devices to act as a cache on top of the data tier. The Thinpool subsystem manages the thin-provisioned volumes associated with the Stratis file systems. This subsystem uses the dm-thin device-mapper driver to replace LVM on the virtual volume sizing and management. dm-thin creates volumes with a large virtual size, formatted with XFS, but with a small physical size. As the physical size nears full, Stratis enlarges it automatically.

Managing Thin-provisioned File Systems

To manage the thin-provisioned file systems using the Stratis storage management solution, install the stratis-cli and stratisd packages. The stratis-cli package provides the stratis command, which translates user requests to the stratisd service via the D-Bus API. The stratisd package provides the stratisd service, which implements the D-Bus interface, and manages and monitors the elements of Stratis, such as block devices, pools, and file systems. The D-Bus API is available if the stratisd service is running.

Install and activate Stratis using the usual tools:

1. Install stratis-cli and stratisd using the yum install command.

[root@host ~]# yum install stratis-cli stratisd
...output omitted...
Is this ok [y/N]: y
...output omitted...
Complete!

2. Activate the stratisd service using the systemctl command.

[root@host ~]# systemctl enable --now stratisd

The following are common management operations performed using the Stratis storage management solution.

1. Create pools of one or more block devices using the stratis pool create command.

[root@host ~]# stratis pool create pool1 /dev/vdb

Each pool is a sub-directory under the /stratis directory.

2. Use the stratis pool list command to view the list of available pools.

[root@host ~]# stratis pool list
Name     Total Physical Size  Total Physical Used
pool1                  5 GiB               52 MiB

3. Use the stratis pool add-data command to add additional block devices to a pool.

[root@host ~]# stratis pool add-data pool1 /dev/vdc

4. Use the stratis blockdev list command to view the block devices of a pool.

[root@host ~]# stratis blockdev list pool1
Pool Name  Device Node    Physical Size   State  Tier
pool1      /dev/vdb               5 GiB  In-use  Data
pool1      /dev/vdc               5 GiB  In-use  Data

5. Use the stratis filesystem create command to create a dynamic and flexible file system from a pool.

[root@host ~]# stratis filesystem create pool1 filesystem1

The links to the Stratis file systems are in the /stratis/pool1 directory.

6. Stratis supports file-system snapshotting with the stratis filesystem snapshot command. Snapshots are independent of the source file systems.

[root@host ~]# stratis filesystem snapshot pool1 filesystem1 snapshot1

7. Use the stratis filesystem list command to view the list of available file systems.

[root@host ~]# stratis filesystem list
...output omitted...

To ensure that the Stratis file systems are persistently mounted, edit **/etc/fstab **and specify the details of the file system. The following command displays the UUID of the file system that you should use in **/etc/fstab **to identify the file system.

[root@host ~]# lsblk --output=UUID /stratis/pool1/filesystem1
UUID
31b9363b-add8-4b46-a4bf-c199cd478c55

The following is an example entry in the /etc/fstab file to persistently mount a Stratis file system.

UUID=31b9...8c55  /dir1  xfs  defaults,x-systemd.requires=stratisd.service    0 0

The x-systemd.requires=stratisd.service mount option delays mounting the file system until after systemd starts the stratisd.service during the boot process.