第 6 章 Working with volume snapshots


MicroShift administrators can use volume snapshots to help protect against data loss by using the supported MicroShift logical volume manager storage (LVMS) Container Storage Interface (CSI) provider. Familiarity with persistent volumes is required.

A snapshot represents the state of the storage volume in a node at a particular point in time. Volume snapshots can also be used to provision new volumes. Snapshots are created as read-only logical volumes (LVs) located on the same device as the original data.

A MicroShift administrator can complete the following tasks using CSI volume snapshots:

  • Create a snapshot of an existing persistent volume claim (PVC).
  • Back up a volume snapshot to a secure location.
  • Restore a volume snapshot as a different PVC.
  • Delete an existing volume snapshot.
重要

Only the logical volume manager storage (LVMS) plugin CSI driver is supported by MicroShift.

6.1. About LVM thin volumes

To use advanced storage features such as creating volume snapshots or volume cloning, you must perform the following actions:

  • Configure both the logical volume manager storage (LVMS) provider and the node.
  • Provision a logical volume manager (LVM) thin-pool on the RHEL for Edge host.
  • Attach LVM thin-pools to a volume group.
重要

To create Container Storage Interface (CSI) snapshots, you must configure thin volumes on the RHEL for Edge host. The CSI does not support volume shrinking.

重要

When using thin provisioning, it is important that you monitor the storage pool and add more capacity as the available physical space runs out. You can configure the storage pool to auto expand when there is available space within the volume group (VG). See Creating thinly provisioned logical volumes.

For LVMS to manage thin logical volumes (LVs), a thin-pool device-class array must be specified in the etc/lvmd.yaml configuration file. Multiple thin-pool device classes are permitted.

If additional storage pools are configured with device classes, then additional storage classes must also exist to expose the storage pools to users and workloads. To enable dynamic provisioning on a thin-pool, a StorageClass resource must be present on the node. The StorageClass resource specifies the source device-class array in the topolvm.io/device-class parameter.

Example lvmd.yaml file that specifies a single device class for a thin-pool

socket-name: 
1

device-classes: 
2

  - name: thin 
3

    default: true
    spare-gb: 0 
4

    thin-pool:
      name: thin
      overprovision-ratio: 1 
5

    type: thin 
6

    volume-group: ssd 
7

1
String. The UNIX domain socket endpoint of gRPC. Defaults to /run/lvmd/lvmd.socket.
2
A list of maps for the settings for each device-class.
3
String. The unique name of the device-class.
4
Unsigned 64-bit integer. Storage capacity in GB to be left unallocated in the volume group. Defaults to 0.
5
Specify a float factor by which you can provision additional storage based on the available storage in the thin pool. For example, if this field is set to 10, you can provision up to 10 times the amount of available storage in the thin pool. To disable over-provisioning, set this field to 1.
6
Thin provisioning is required to create volume snapshots.
7
String. The group where the device-class creates the logical volumes.
重要

When multiple PVCs are created simultaneously, a race condition prevents LVMS from accurately tracking the allocated space and preserving the storage capacity for a device class. Use separate volume groups and device classes to protect the storage of highly dynamic workloads from each other.

6.1.1. Storage classes

Storage classes provide the workload layer interface for selecting a device class. The following storage class parameters are supported in MicroShift:

  • The csi.storage.k8s.io/fstype parameter selects the file system types. Both xfs and ext4 file system types are supported.
  • The topolvm.io/device-class parameter is the name of the device class. If a device class is not provided, the default device class is assumed.

Multiple storage classes can refer to the same device class. You can provide varying sets of parameters for the same backing device class, such as xfs and ext4 variants.

Example MicroShift default storage class resource

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true" 
1

  name: topolvm-provisioner
parameters:
  "csi.storage.k8s.io/fstype": "xfs" 
2

provisioner: topolvm.io 
3

reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer 
4

allowVolumeExpansion: 
5

1
An example of the default storage class. If a PVC does not specify a storage class, this class is assumed. There can only be one default storage class in a MicroShift node. Having no value assigned to this annotation is also supported.
2
Specifies which file system to provision on the volume. Options are "xfs" and "ext4".
3
Identifies which provisioner should manage this class.
4
Specifies whether to provision the volume before a client pod is present or immediately. Options are WaitForFirstConsumer and Immediate. WaitForFirstConsumer is recommended to ensure that storage is only provisioned for pods that can be scheduled.
5
Specifies if PVCs provisioned from the StorageClass permit expansion. The MicroShift LVMS CSI plugin does support volume expansion, but if this value is set to false, expansion is blocked.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部