LVM学习笔记

LVM Logical Volume Manager

Volume management creates a layer of abstraction over physical storage, allowing you to create logical storage volumes.

Logical volumes provide the following advantages over using physical storage directly:

Flexible capacity

When using logical volumes, file systems can extend across multiple disks, since you can aggregate disks and partitions into a single logical volume.

Resizeable storage pools

You can extend logical volumes or reduce logical volumes in size with simple software commands, without reformatting and repartitioning the underlying disk devices.

Online data relocation

To deploy newer, faster, or more resilient storage subsystems, you can move data while your system is active. Data can be rearranged on disks while the disks are in use. For example, you can empty a hot-swappable disk before removing it.

Convenient device naming

Logical storage volumes can be managed in user-defined groups, which you can name according to your convenience.

Disk striping

You can create a logical volume that stripes data across two or more disks. T his can dramatically increase throughput.

Mirroring volumes

Logical volumes provide a convenient way to configure a mirror for your data.

Volume Snapshots

Using logical volumes, you can take device snapshots for consistent backups or to test the effect of changes without affecting the real data.

LVM

The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk.

This device is initialized as an LVM physical volume (PV).

To create an LVM logical volume, the physical volumes are combined into a volume group (VG).

This creates a pool of disk space out of which LVM logical volumes (LVs) can be allocated.

CLVM

The Clustered Logical Volume Manager (CLVM) is a set of clustering extensions to LVM.

These extensions allow a cluster of computers to manage shared storage (for example, on a SAN) using LVM.

In order to use CLVM, the High Availability Add-On and Resilient Storage Add-On software, including the clvmd daemon, must be running.

The clvmd daemon is the key clustering extension to LVM.

The clvmd daemon runs in each cluster computer and distributes LVM metadata updates in a cluster, presenting each cluster computer with the same view of the logical volumes.

LVM Components : Physical Volumes

The underlying physical storage unit of an LVM logical volume is a block device such as a partition or whole disk.

To use the device for an LVM logical volume the device must be initialized as a physical volume (PV).

Initializing a block device as a physical volume places a label near the start of the device.

By default, the LVM label is placed in the second 512-byte sector.

An LVM label provides correct identification and device ordering for a physical device, since devices can come up in any order when the system is booted. An LVM label remains persistent across reboots and throughout a cluster.

The LVM label identifies the device as an LVM physical volume. It contains a random unique identifier (the UUID) for the physical volume. It also stores the size of the block device in bytes, and it records where the LVM metadata will be stored on the device.

The LVM metadata contains the configuration details of the LVM volume groups on your system.

By default, an identical copy of the metadata is maintained in every metadata area in every physical volume within the volume group. LVM metadata is small and stored as ASCII.

LVM allows you to create physical volumes out of disk partitions.

It is generally recommended that you create a single partition that covers the whole disk to label as an LVM physical volume for the following reasons:

–Administrative convenience: It is easier to keep track of the hardware in a system if each real disk only appears once. This becomes particularly true if a disk fails. In addition, multiple physical volumes on a single disk may cause a kernel warning about unknown partition types at boot-up.

–Striping performance: LVM cannot tell that two physical volumes are on the same physical disk. If you create a striped logical volume when two physical volumes are on the same physical disk, the stripes could be on different partitions on the same disk. This would result in a decrease in performance rather than an increase.

LVM Components : Volume Groups

Physical volumes are combined into volume groups (VGs).

This creates a pool of disk space out of which logical volumes can be allocated.

Within a volume group, the disk space available for allocation is divided into units of a fixed-size called extents.

An extent is the smallest unit of space that can be allocated.

Within a physical volume, extents are referred to as physical extents.

A logical volume is allocated into logical extents of the same size as the physical extents.

The extent size is thus the same for all logical volumes in the volume group.

The volume group maps the logical extents to physical extents.

LVM Components : LVM Logical Volumes

In LVM, a volume group is divided up into logical volumes.

There are three types of LVM logical volumes:

linear volumes, striped volumes, and mirrored volumes

Linear Volumes

A linear volume aggregates space from one or more physical volumes into one logical volume.

For example, if you have two 60GB disks, you can create a 120GB logical volume. The physical storage is oncatenated.

Creating a linear volume assigns a range of physical extents to an area of a logical volume in order.

For example, logical extents 1 to 99 could map to one physical volume and logical extents 100 to 198 could map to a second physical volume.

The physical volumes that make up a logical volume do not have to be the same size.

You can configure more than one linear logical volume of whatever size you require from the pool of physical extents.

Striped Logical Volumes

When you write data to an LVM logical volume, the file system lays the data out across the underlying physical volumes.

You can control the way the data is written to the physical volumes by creating a striped logical volume.

For large sequential reads and writes, this can improve the efficiency of the data I/O.

Striping enhances performance by writing data to a predetermined number of physical volumes in round robin fashion.

–the first stripe of data is written to PV1

–the second stripe of data is written to PV2

–the third stripe of data is written to PV3

–the fourth stripe of data is written to PV1

In a striped logical volume, the size of the stripe cannot exceed the size of an extent.

Striped logical volumes can be extended by concatenating another set of devices onto the end of the first set.

In order to extend a striped logical volume, however, there must be enough free space on the underlying physical volumes that make up the volume group to support the stripe.

For example, if you have a two-way stripe that uses up an entire volume group, adding a single physical volume to the volume group will not enable you to extend the stripe.

Instead, you must add at least two physical volumes to the volume group.

Mirrored Logical Volumes

A mirror maintains identical copies of data on different devices.

When data is written to one device, it is written to a second device as well, mirroring the data.

This provides protection for device failures. When one leg of a mirror fails, the logical volume becomes a linear volume and can still be accessed.

LVM supports mirrored volumes. When you create a mirrored logical volume, LVM ensures that data written to an underlying physical volume is mirrored onto a separate physical volume.

With LVM, you can create mirrored logical volumes with multiple mirrors.

An LVM mirror divides the device being copied into regions that are typically 512KB in size.

LVM maintains a small log which it uses to keep track of which regions are in sync with the mirror or mirrors.

This log can be kept on disk, which will keep it persistent across reboots, or it can be maintained in memory.

RAID Logical Volumes

Thinly-Provisioned Logical Volumes (Thin Volumes)

Logical volumes can be thinly provisioned. T his allows you to create logical volumes that are larger than the available extents.

By using thin provisioning, a storage administrator can over-commit the physical storage, often avoiding the need to purchase additional storage.

For example, if ten users each request a 100GB file system for their application, the storage administrator can create what appears to be a 100GB file system for each user but which is backed by less actual storage that is used only when needed.

When using thin provisioning, it is important that the storage administrator monitor the storage pool and add more capacity if it starts to become full.

To make sure that all available space can be used, LVM supports data discard. T his allows for re-use of the space that was formerly used by a discarded file or other block range.

Snapshot Volumes

The LVM snapshot feature provides the ability to create virtual images of a device at a particular instant without causing a service interruption.

When a change is made to the original device (the origin) after a snapshot is taken, the snapshot feature makes a copy of the changed data area as it was prior to the change so that it can reconstruct the state of the device.

Because a snapshot copies only the data areas that change after the snapshot is created, the snapshot feature requires a minimal amount of storage.

You can use the --merge option of the lvconvert command to merge a snapshot into its origin volume.

One use for this feature is to perform system rollback if you have lost data or files or otherwise need to restore your system to a previous state.

Thinly-Provisioned Snapshot Volumes

This simplifies administration and allows for the sharing of data between snapshot volumes.

As for all LVM snapshot volumes, as well as all thin volumes, thin snapshot volumes are not supported across the nodes in a cluster.

A thin snapshot volume can reduce disk usage when there are multiple snapshots of the same origin volume.

Thin snapshot volumes can be used as a logical volume origin for another snapshot.

A snapshot of a thin logical volume also creates a thin logical volume.

You cannot change the chunk size of a thin pool.

You cannot limit the size of a thin snapshot volume

LVM Administration Overview

The following is a summary of the steps to perform to create an LVM logical volume.

Initialize the partitions you will use for the LVM volume as physical volumes (this labels them).
Create a volume group.
Create a logical volume.

After creating the logical volume you can create and mount the file system. The examples in this document use GFS2 file systems.

Create a GFS2 file system on the logical volume with the mkfs.gfs2 command.
Create a new mount point with the mkdir command. In a clustered system, create the mount point on all nodes in the cluster.
Mount the file system. You may want to add a line to the fstab file for each node in the system.

To grow a file system on a logical volume, perform the following steps:

Make a new physical volume.
Extend the volume group that contains the logical volume with the file system you are growing to include the new physical volume.
Extend the logical volume to include the new physical volume.
Grow the file system.

Logical Volume Backup

Metadata backups and archives are automatically created on every volume group and logical volume configuration change unless disabled in the lvm.conf file.

By default, the metadata backup is stored in the /etc/lvm/backup file and the metadata archives are stored in the /etc/lvm/archive file.

A daily system backup should include the contents of the /etc/lvm directory in the backup.

You can manually back up the metadata to the /etc/lvm/backup file with the vgcfgbackup command. You can restore metadata with the vgcfgrestore command.

root:/etc/lvm/backup# cat cinder-volumes
# Generated by LVM2 version 2.02.98(2) (2012-10-15): Mon Jul 7 03:34:24 2014

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'lvextend -L 20G /dev/cinder-volumes/lv_cliu8_test'"

creation_host = "escto-bj-hp-z620" # Linux escto-bj-hp-z620 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC 2014 x86_64
creation_time = 1404675264 # Mon Jul 7 03:34:24 2014

cinder-volumes {
        id = "86NpeF-RjB1-vBGd-8LDO-N1nJ-ssK7-862yFH"
        seqno = 15
        format = "lvm2" # informational
        status = ["RESIZEABLE", "READ", "WRITE"]
        flags = []
        extent_size = 8192              # 4 Megabytes
        max_lv = 0
        max_pv = 0
        metadata_copies = 0

physical_volumes {

                pv0 {
                        id = "anOUYC-Ia27-xkf2-A6rY-ALPP-N6dF-pHp523"
                        device = "/dev/sdc"     # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 500118192    # 238.475 Gigabytes
                        pe_start = 2048
                        pe_count = 61049        # 238.473 Gigabytes
                }
        }

logical_volumes {

                volume-f6ba87f7-d0b6-4fdb-ac82-346371e78c48 {
                        id = "PKRR9B-nUCI-Ob1Y-U97W-b1Rh-RhuH-Ow4h5P"
                        status = ["READ", "WRITE", "VISIBLE"]
                        flags = []
                        creation_host = "escto-bj-hp-z620"
                        creation_time = 1404253343      # 2014-07-02 06:22:23 +0800
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 2816     # 11 Gigabytes