第 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:
device-classes:
- name: thin
default: true
spare-gb: 0
thin-pool:
name: thin
overprovision-ratio: 1
type: thin
volume-group: ssd
- 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-classcreates 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/fstypeparameter selects the file system types. Bothxfsandext4file system types are supported. -
The
topolvm.io/device-classparameter 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"
name: topolvm-provisioner
parameters:
"csi.storage.k8s.io/fstype": "xfs"
provisioner: topolvm.io
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion:
- 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
WaitForFirstConsumerandImmediate.WaitForFirstConsumeris recommended to ensure that storage is only provisioned for pods that can be scheduled. - 5
- Specifies if PVCs provisioned from the
StorageClasspermit expansion. The MicroShift LVMS CSI plugin does support volume expansion, but if this value is set tofalse, expansion is blocked.