Can I take snapshots of clustered logical volumes in RHEL 6, or 7?

Solution Verified - Updated 7 Aug 2024

Environment

Red Hat Enterprise Linux (RHEL) 6, 7 with the Resilient Storage Add On
lvm2-cluster
- locking_type = 3 in /etc/lvm/lvm.conf
- One or more volume groups with the clustered (c bit) attribute set

Issue

Are LVM snapshots supported across the nodes in a cluster?
Can I take an LVM snapshot of my cluster LVM?
If I have an LVM snapshot of my cluster LVM, can I use that to restore the volume to a previous state?

Resolution

LVM snapshots of clustered logical volume are only supported while logical volume is deactivated OR activated exclusively. LVM snapshots of clustered logical volume are not supported against LVM logical volumes which are active on multiple nodes at a time. In other words unless the volumes are activated exclusively (ie, with the -e flag which only allows for activation on a single node).

If the filesystem on the logical volume is a gfs2 filesystem then this will require that the filesystem is unmounted on all cluster nodes and activate the logical volume exclusively on one node only so other nodes won't have the LV active.

For more information, see the following documentation resources:

RHEL 6

RHEL 7

Below are two methods that outline how to take a snapshot for logical volume that contains a gfs2 filesystem. For both methods unmounting gfs2 is necessary in this case because we will take the logical volumes down to ensure it is not active on multiple nodes (so only 1 cluster node has access to the volume group while the snapshot takes place). Snapshot is also possible while the LV is deactivated on all nodes. Unmounting gfs2 filesystem is required because even exclusive activation of LV requires temporary deactivation of the volume - this wouldn't be possible if gfs2 was mounted (device would be reported busy and deactivation would fail).

Snapshot with deactivated logical volume

If a [gfs2 filesystem](/solutions/916233) resides on a clustered logical volume where a snapshot needs to be taken then the following is an outline on the safest method of achieving this by deactivating the logical volume.

Unmount gfs2 filesystem on all cluster nodes.
Then deactivate the logical volume on all cluster nodes.
```
 # lvchange -an <logical volume>
```

Since the logical volume is deactivated we can perform a snapshot without having to set volume as exclusive.

 # lvcreate --size <size> --snapshot --name <name of snapshot i.e. snap>  <logical volume i.e. /dev/vg00/lvol1>

Above command creates a snapshot logical volume named /dev/vg00/snap which has access to the contents of the original logical volume named /dev/vg00/lvol1 at snapshot logical volume creation time.

After the snapshot has finished then activate and mount the gfs2 filesystem.
```
 # lvchange -ay <volume group>
```

Snapshot with activated logical volume

If for some reason logical volume that contains a [gfs2 filesystem](/solutions/916233) needs to be active then set the volume exclusive bit, perform snapshot and then disable the exclusive bit. Deactivating and activating the logical volume is not needed because activating the exclusive attribute will automatically deactivate logical volume on other nodes (`clvmd` activates it in exclusive mode - with an exclusive lock).

Unmount gfs2 filesystem on all cluster nodes.
Then activate exclusive mode on the logical volume.
```
 # lvchange -aey <volume group>
```

Since the logical volume is now in exclusive mode we can perform a snapshot.

 # lvcreate --size <size> --snapshot --name <name of snapshot i.e. snap>  <logical volume i.e. /dev/vg00/lvol1>

After the snapshot has finished then deactivate the exclusive mode.
```
 # lvchange -aen <volume group>
```

Root Cause

As described here the LVM snapshot feature provides the ability to capture a device's state at particular instant without causing a service interruption. When data is changed on that device, the snapshot can be used to restore the device back to a previous state.

Clustered volume groups, utilizing CLVM, require different considerations. If you are using CLVM, it is probably because two or more cluster nodes are actively using the volumes. It is in those cases where CLVM features conflict with the ease of taking and using LVM snapshots as needed, and thus snapshots can only be taken in situations where the volumes are not shared across nodes. To enforce this, the volume must be activated exclusively.

This is purely LVM restriction because there is no monitoring implemented for snapshot so there would be chance metadata getting out of sync on nodes -that is why we don't support it. In addition, the cmirror daemon has monitoring implemented but still does not have support for snapshot - it only tracks the mirror log.

Note: Freezing gfs2 filesystem with gfs2_tool, fs_freeze, or dmsetup (with commands: dmsetup --suspend or dmsetup --suspend --nolockfs) before exclusive activation of logical volume is not enough to prevent the filesystem from being modified by a cluster node that has the gfs2 filesystem mounted. GFS2 needs to be unmounted on all cluster nodes in order to release the device and proceed with snapshot. Using dmsetup should be avoided completely while volume is active no matter if it is clustered or not - all operations should proceed through LVM commands in such a case.

SBR

Clusterha

Product(s)

Red Hat Enterprise Linux

Components

cluster
lvm2

Category

Supportability

Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.