A Logical Volume Manager is a software layer on top of physical hard disks and partitions, which creates an abstraction of continuity and ease-of-use for managing the lifecycle of those devices (ie: addition, removal, replacement, repartitioning, backup, etc).
Over the years, the role of LVM has expanded greatly to include data redundancy (RAID), compression, deduplication, and more…
These exercises will help you get familiar with the basic concepts of LVM and also introduce deduplication with the Virtual Data Optimizer (VDO).
For these exercises, you will be using the host node3 as user root.
From host bastion, ssh to node3.
$ ssh node3
Use sudo to elevate your priviledges.
sudo -iVerify that you are on the right host for these exercises.
workshop-vdo-checkhost.shYou are now ready to proceed with these exercises.
Install the required packages - this will pull in several related dependencies.
yum install -y vdoThat’s it! All LVM components are a standard part of RHEL. Only the vdo kmod and related utilities need to be installed.
-
Flexibility
-
Grow, shrink or relocate your data/filesystems
-
Aggregate or subdivide devices as needed
-
Performance
-
Striping across multiple devices
-
Caching via SSDs
-
Fault Tolerance (redundancy & resiliency)
-
RAID 0, 1, 5, 6, 10
-
Snapshots: Historical Recovery
-
Data Optimization: Compression and De-Duplication
From the bottom up, here is a basic explanation of the layered technology stack that comprises modern storage.
File-systems |
Formatted LV’s become filesystems |
Logical Volume |
A virtual storage device that may span multiple physical devices. Allocatable chunks (PEs) are assembled into “Logical Extents” that form the addressable space. |
Volume Group |
A collection of Physical Volumes that are divided into discrete allocatable chunks called “physical extents” (PEs). |
Physical Volume |
An LVM concept that identifies physical devices for LVM use. |
Physical Device |
Disks (IDE [hda], SCSI, SATA & SAS [sda], etc…) Partitions (ex: hda1, sda1, cciss/c0d0p1, etc…) LUNs (FCOE, SAN, etc…) loopback |
| Physical Volumes | Volumes Groups | Logical Volumes | |
|---|---|---|---|
Core Utilities |
pvcreate pvdisplay pvremove pvs pvscan pvmove |
vgcreate vgdisplay vgextend vgreduce vgremove vgrename vgs vgscan vgcfgbackup vgcfgrestore |
lvconvert lvcreate lvdisplay lvextend lvreduce lvremove lvrename lvresize lvs lvscan |
Other Stuff |
fdisk parted partprobe multipath smartd |
mkfs mount fsadm |
In this exercise, you will perform steps to make a new filesystem available to the system using the Logical Volume Management tools.
We will begin with a simple linear volume (concatination).
Since we will be reusing the same resources for many exercises, we will begin by wiping everything clean. Don’t worry if you get an error message.
umount /mnt/lab*vgremove -ff vg_labpvremove /dev/sd{b..e}wipefs -a /dev/sd{b..e}partprobemkfs -t ext4 /dev/vg_lab/lab1mkdir -p /mnt/lab1mount /dev/vg_lab/lab1 /mnt/lab1|
ℹ️
|
If this were going to be a persistent filesystem, you would also need to add an entry to /etc/fstab.
|
lvsLV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lab1 vg_lab -wi-ao---- <4.75g home vg_rhel -wi-ao---- 1.95g root vg_rhel -wi-ao---- 19.73g swap01 vg_rhel -wi-ao---- 1.95g tmp vg_rhel -wi-ao---- 1.95g var vg_rhel -wi-ao---- <3.91g
lvs vg_lab/lab1LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lab1 vg_lab -wi-ao---- <4.75g
lvs -o lv_name,lv_size,lv_attr,segtype,devices vg_lab/lab1 LV LSize Attr Type Devices
lab1 <4.75g -wi-ao---- linear {disk1}(0)
lvs --units g -o +devices vg_lab/lab1 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices
lab1 vg_lab -wi-ao---- 4.75g {disk1}(0)
df /mnt/lab1Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_lab-lab1 4832912 19448 4548248 1% /mnt/lab1
pvcreate /dev/sdcvgextend vg_lab /dev/sdclvresize -l 95%VG /dev/vg_lab/lab1resize2fs /dev/vg_lab/lab1Let us take a look at the logical volume. Notice a few things:
-
we added
seg_sizeto the options to report segment size -
the logical volume is comprised of 2 devices (vdb, vdc)
-
the first segment is completely used at 5g
-
the second segment is almost used, but has some space remaining
-
Over all, the volume group has approximately 500mb remaining
lvs -o vg_name,vg_free,lv_name,lv_size,seg_size,segtype,devices vg_lab/lab1 VG VFree LV LSize SSize Type Devices
vg_lab 508.00m lab1 <9.50g <5.00g linear {disk1}(0)
vg_lab 508.00m lab1 <9.50g 4.50g linear {disk2}(0)
df /mnt/lab1Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vg_lab-lab1 9735476 21840 9249360 1% /mnt/lab1
It is not always optimal to allocate 100% of volume group to the logical volumes. For example, the unused space in the volume group could be used for a temporary snapshot.
We will be leveraging devices /dev/vd{b..e}. As before, we will cleanup up prior work and start fresh.
Since we will be reusing the same resources for many exercises, we will begin by wiping everything clean. Don’t worry if you get an error message.
umount /mnt/lab*vdo stop --allvdo remove --all --forcevgremove -ff vg_labpvremove /dev/sd{b..e}wipefs -a /dev/sd{b..e}partprobeThis time, we are going to use all four disks to create a mirrored set of striped disks. Otherwise known as RAID10
lvcreate -y --type raid10 -m1 -i 2 -n lv_raid10 -l 95%FREE vg_labvdo create --name=lab2 --device=/dev/vg_lab/lv_raid10 --vdoLogicalSize=30Gmkfs.xfs -K /dev/mapper/lab2mkdir /mnt/lab2mount /dev/mapper/lab2 /mnt/lab2|
ℹ️
|
To make the mount persistent across reboots, you would still need to either add a systemd unit to mount the filesystem, or add an entry to /etc/fstab. |
Let us now populate the filesystem with some content. Create a bunch of random subdirectories in our new filesystems with the following command.
for i in {1..100} ; do mktemp -d /mnt/lab2/XXXXXX ; doneNow we will copy the same content into each of the folders as follows.
|
ℹ️
|
This could take a few minutes. |
for i in /mnt/lab2/* ; do echo "${i}" ; cp -rf /usr/share/locale $i ; doneThe prevoius command should have copied approximately 100MB in 100 folders yielding about 10G of traditional fielsystem consumption.
Let us now check some statistics.
du -sh /mnt/lab2df /mnt/lab2vdostats --human-readableSo in summary, we built a 30GB filesystem that only has 10GB of actual physical disk capacity. We then copied 10GB of data into the filesystem, but after deduplication vdostats --human-readable should reflect something near 4GB of available plysical space.
A few additional high-level things to know about VDO.
First, the VDO systemd unit is installed and enabled by default when the vdo package is installed. This unit automatically runs the vdo start --all command at system startup to bring up all activated VDO volumes
Second, VDO uses a high-performance deduplication index called UDS to detect duplicate blocks of data as they are being stored. The deduplication window is the number of previously written blocks which the index remembers. The size of the deduplication window is configurable. The index will require a specific amount of RAM and a specific amount of disk space.
Last, Red Hat generally recommends using a "sparse" UDS index for all production use cases. This indexing data structure requires approximately one-tenth of a byte of DRAM (memory) per block in its deduplication window. On disk, it requires approximately 72 bytes of disk space per block.
The default configuration of the index is to use a "dense" index. This index is considerably less efficient (by a factor of 10) in DRAM, but it has much lower (also by a factor of 10) minimum required disk space, making it more convenient for evaluation in constrained environments.
Please refer to the Red Hat Storage Administration Guide further information on provisioning and managing your data with VDO:
Red Hat Enterprise Linux Storage Administration Guide (VDO)
Red Hat Documentation