LVM-逻辑卷管理 – Rin-Linux网络技术学习

LVM是 Logical Volume Manager（逻辑卷管理）的简写，它是Linux环境下对磁盘分区进行管理的一种机制，它由Heinz Mauelshagen在Linux 2.4内核上实现，目前最新版本为：稳定版1.0.5，开发版 1.1.0-rc2，以及LVM2开发版。
每个Linux使用者在安装Linux时都会遇到这样的困境：在为系统分区时，如何精确评估和分配各个硬盘分区的容量，因为系统管理员不但要考虑到当前某个分区需要的容量，还要预见该分区以后可能需要的容量的最大值。因为如果估计不准确，当遇到某个分区不够用时管理员可能甚至要备份整个系统、清除硬盘、重新对硬盘分区，然后恢复数据到新分区。
虽然有很多动态调整磁盘的工具可以使用，例如PartitionMagic等等，但是它并不能完全解决问题，因为某个分区可能会再次被耗尽；另外一个方面这需要重新引导系统才能实现，对于很多关键的服务器，停机是不可接受的，而且对于添加新硬盘，希望一个能跨越多个硬盘驱动器的文件系统时，分区调整程序就不能解决问题。
因此完美的解决方法应该是在零停机前提下可以自如对文件系统的大小进行调整，可以方便实现文件系统跨越不同磁盘和分区。幸运的是Linux提供的逻辑卷管理（LVM LogicalVolumeManager）机制就是一个比较可行的解决方案。
逻辑卷管理器(Logical Volume Manager)本质上是一个虚拟设备驱动，是在内核中块设备和物理设备之间添加的一个新的抽象层次，如图所示。它可以将几块磁盘(物理卷，PhysicalVolume)组合起来形成一个存储池或者卷组(Volume Group)。LVM可以每次从卷组中划分出不同大小的逻辑卷(Logical Volume)创建新的逻辑设备。底层的原始的磁盘不再由内核直接控制，而由LVM层来控制。对于上层应用来说卷组替代了磁盘块成为数据存储的基本单元。LVM管理着所有物理卷的物理盘区，维持着逻辑盘区和物理盘区之间的映射。LVM逻辑设备向上层应用提供了和物理磁盘相同的功能，如文件系统的创建和数据的访问等。但LVM逻辑设备不受物理约束的限制，逻辑卷不必是连续的空间，它可以跨越许多物理卷，并且可以在任何时候任意的调整大小。相比物理磁盘来说，更易于磁盘空间的管理。
简单来说，LVM就是将各个磁盘或者分区全部转化成以自己规则运行的一个素材——pv，又将这些素材全部组成一个庞大（也可能并不庞大）的存储空间——vg，然后我们可以在这个空间之上来创建实际使用的模拟单元——逻辑卷

LVM重点词句释义：

PV(physical volume)：物理卷在逻辑卷管理系统最底层，可为整个物理硬盘或实际物理硬盘上的分区。它只是在物理分区中划出了一个特殊的区域，用于记载与LVM相关的管理参数。
VG(volume group)：卷组建立在物理卷上，一卷组中至少要包括一物理卷，卷组建立后可动态的添加卷到卷组中，一个逻辑卷管理系统工程中可有多个卷组。
LV(logical volume)：逻辑卷建立在卷组基础上，卷组中未分配空间可用于建立新的逻辑卷，逻辑卷建立后可以动态扩展和缩小空间。
PE(physical extent)：物理区域是物理卷中可用于分配的最小存储单元，物理区域大小在建立卷组时指定，一旦确定不能更改，同一卷组所有物理卷的PE(物理区域大小)需一致，新的pv加入到vg后，pe的大小自动更改为vg中定义的pe大小。
LE(logical extent)：逻辑区域是逻辑卷中可用于分配的最小存储单元，逻辑区域的大小取决于逻辑卷所在卷组中的物理区域的大小。由于受内核限制的原因，一个逻辑卷（Logic Volume）最多只能包含65536个PE（Physical Extent），所以一个PE的大小就决定了逻辑卷的最大容量，4 MB(默认) 的PE决定了单个逻辑卷最大容量为 256 GB，若希望使用大于256G的逻辑卷，则创建卷组时需要指定更大的PE。在Red Hat Enterprise Linux AS 4中PE大小范围为8 KB 到 16GB，并且必须总是 2 的倍数。

LVM的各阶段创建

由上文，我们可以得知：想要创建一个逻辑卷，必须以**创建物理卷—创建卷组—创建逻辑卷**这个顺序来执行，具体的操作以及指令如下:

第一阶段：PV的创建

这一阶段可使用的命令为pvcreate、pvscan（pvs） pvdisplay

我们使用pvcreate指令来创建物理卷：

注意：

被创建的对象可以是一个分区，亦可以是一整个磁盘，此处我们将整个磁盘都进行向物理卷的转化
如上所示，我们将5块磁盘全部写入在一条指令之中，但并非指将这5块磁盘纳入一个物理卷，而是每一个都独立创建一个物理卷，也就是说，在pvcreate指令中的每一个目标对象，都会被视为一个独立的个体，系统会将这些目标对象都创建成一个独立的物理卷

创建完成之后，我们可以使用pvs(pvscan)指令来扫描系统中的所有pv，以便来检查pv有没有被创建，或者使用pvdisplay指令来查看pv的属性信息：

也可以指定目标来显示：

第二阶段：VG的创建

这一阶段可使用的命令为vgcreate、vgscan（vgs） vgdisplay

我们使用vgcreate指令来创建卷组：

用法：vgcreate [option] [卷组的名字] [PV设备名1] [PV设备名2] ….

常见参数 -s：卷组中的物理卷的PE大小，默认为4M

该参数在使用时，请注意单位，默认为M，支持：T、G、M、K -l：卷组上允许创建的最大逻辑卷数

  **-p：卷级中允许添加的最大物理卷数**

示例：

创建完成之后，我们可以使用vgs(vgscan)指令来扫描系统中的所有vg，以便来检查vg有没有被创建，或者使用vgdisplay指令来查看vg的属性信息：

也可以指定目标来显示：

第三阶段：lv的创建

这一阶段可使用的命令为lvcreate、lvscan（lvs）lvdisplay

我们使用lvcreate指令来创建逻辑卷：

用法：lvcreate [option] [逻辑卷的名字] [基于的卷组]

常见参数 -L：指定逻辑卷的大小

该参数在使用时，请注意单位，默认为M，支持：T、G、M、K -l：以指定LE数的方式，来指定逻辑卷的大小

使用该参数时，需要知道le的默认大小，一般与pe成1:1比例，如果pe大小也是默认大小，那么一般来说le大小为4MB

  **-n： 指定逻辑卷的卷名**

示例：

使用-L来创建：

注意：此处我们没有指定单位，则此处的1500为1500M的容量

使用-l来创建：

我们知道，如果没有特殊配置，le的大小与pe的大小默认成1:1的比例关系

那么首先，我们来看看测试用的vgtest卷组的PE的大小：

那么理论上来说，我们使用-l参数去指定逻辑卷的大小，所给参数是1那么逻辑卷就应该是8M的大小，10就是80M…以此类推

我们来看结果：

我们再创建一个10和100来佐证结论：

创建成功后我们可以使用lvs(lvscan)指令来扫描系统中的所有lv，以便来检查lv有没有被创建，或者使用lvdisplay指令来查看lv的属性信息：

也可以指定目标来显示：

卷组的扩容和缩容

卷组的扩容和缩容其实比较简单，因为在LVM理念之中，卷组的概念就相当于是一个空间池，所以其扩容和缩容也就是将物理卷添加或者删除

扩容/缩容的指令：

卷组的扩容指令：vgextend [目标卷组] [新添加的物理卷]
卷组的缩容指令：vgreduce [目标卷组] [被删除的物理卷] 但是需要注意的是，已经被使用的物理卷（比如该物理卷的部分上已经有逻辑卷被创建）则不可以将其删除，这与之后会阐明的各阶段删除的关系有关

示例：

逻辑卷的扩容和缩容

逻辑卷的扩容和缩容需要牵扯到许多细节方面的问题，比起卷组的扩容和缩容来说，有些繁琐

逻辑卷扩容和缩容的指令：

lvreduce：缩容
lvextend：扩容
lvresize：更改容量，可以用作缩容，也可以用作扩容

为了防止出现各种意外情况，一下我们统一使用lvresize指令进行扩容和缩容

lvresize的用法：

lvresize [参数] [指定数值] [目标对象的逻辑卷]

一般来说，此处的参数只为-l或者-L，其释义与创建时指定的大小释义一致，-l对应le数，而-L代表了具体的大小，默认单位为M
而指定的数值也不一定非得是扩容或者缩容后的数值，也可以直接写出扩容多少，或者缩容多少，其对应的符号为 + 和 –

示例：

扩容100M：+100M
缩容300M：-300M 然而，我们并不能像卷组的扩/缩容那样直接使用该指令，在逻辑卷上的扩/缩容有着自己的规则和额外操作，具体如下：

增容示例：

扩容其实也相对容易，首先进行resize操作：

进行了 lv 的 resize 之后，我们需要进行额外的两个操作
首先，我们需要使用e2fsck -f命令(-f是强制检查，若不加-f可以执行，可以不加-f)去检查逻辑卷文件系统的正确性：

注意：如果lv已经被被挂载，则上述步骤可以省去，但是如果未被挂载，则必须先行执行上述步骤，否则在执行下一步骤时会有以下报错：

如上图，我们最后的步骤是使用resize2fs命令来将resize的变化部分（此处为扩充部分）格式化：

在此我们也给出挂载后的情况：

  **注意，在挂载后我们可以发现一个有趣的现象：**

如上图，我们可以发现，在扩容指令lvresize敲入后，再使用lsblk来检查我们的逻辑卷lvtest1会发现，它已经变成了我们指定的扩充后的容量，但是那并没有被挂载系统认同，如下图：

从上图我们可以发现，在这里的扩充部分虽然被系统认同，但是由于各种原因，其存在不被挂载系统认可，那么实际上，我们就无法使用这个被lsblk检查出来的部分，以下是该论证的测试：

首先，我们使逻辑卷的大小处于一个偏小的值，以便测试：

然后我们来进行扩充操作：

在此，我们不进行扩充部分的格式化，也不去进行系统的正确性，直接进行挂载：

可以看得出，使用df指令得出的逻辑卷实际容量大小仍然为初始值，为了进一步证实，我们来使用吐零机创建一个越过100M但不越过1000M的文件，看看效果：

可以看见，我们给出200M的文件，最终被复制成功的只有83M左右，而这个83M，就是被挂载系统承认的逻辑卷所拥有的实际容量大小

此时，我们再进行扩充部分的格式化，使其被挂载系统承认：

如上，进行扩充部分的格式化后，扩充部分被承认，我们再次次使用dd来进行测试：

200M文件创建成功！

缩容示例：

如果说，逻辑卷的扩容看起来也并不是那么的麻烦，那么就下来的缩容，就稍稍有些棘手了
…老样子，先进行resize操作：

如果你按照以上步骤去做了，那么恭喜你，你这一整个逻辑卷都将被报废：

逻辑卷的缩容，断不可以像扩容一样先进行resize操作，一旦如此操作，其缩容的部分由于未被提前格式化掉，导致了一系列的惨剧，再如下，我们甚至可以发现其逻辑卷已经被损坏：

如果出现这种情况，那么等待你的就只有两个选项：格式化整个逻辑卷，或者重启以及祈祷…在此我们是测试环境，所以可以直接将整个逻辑卷格式化，重新操作：
先格式化，使逻辑卷恢复正常：

再做缩容…...请切记先进行缩容部分的格式化：

先执行的e2fsck操作缘由已在扩容部分释义过了，在此不再赘述，重点在于此处的resize2fs，格式化缩容部分操作上，可以发现，我们在尾部添加上了一个500M参数，这个参数亦是十分重要的部分，这个数值代表了进行之后resize操作后，更改到的size大小
简单来说，这个500M即是我们缩容后的逻辑卷容量大小，**它必须和之后resize后的大小一致**，否则也会导致逻辑卷损坏

在此我们给出不一致的情况下和一致的情况：

一致的情况：

如上，成功挂载，没有问题！

不一致的情况：

如上，逻辑卷已经损坏，无法挂载！

LVM的各阶段删除

LVM各阶段的删除指令：

物理卷：pvremove
卷组：vgremove
逻辑卷：lvremove 由创建部分加深理解可以得知：我们在删除LVM各个阶段时，需要按照以创建完全相反的步骤来进行，也就是先删除逻辑卷，再删除卷组，最后删除物理卷。**但各个阶段也有其各自的法则**，具体的说明如下: 首先我们需要明白一个逻辑，我们创建的物理卷是一个单独的个体。卷组是物理卷的集合，是由物理卷组成的一个存储池。而逻辑卷则是建立于这个存储池之上的存储单元。

有关卷组的删除

虽然卷组将物理卷整合为了一体，但是在建立逻辑卷时，还是根据各个物理卷的大小来分配逻辑卷应该挂属于哪一个物理卷之下，比如说，我们创建了一个卷组，其每一个下属的物理卷都是2G大小，一共有a、b、c三块，lvtes1的大小是500M，那么很显然，根据a、b、c的顺序来说，lvtest1一定是挂属于物理卷a下的，而lvtest2的大小是2.5G，那么lvtest2则会利用掉物理卷a的剩余资源，然后不足的空间用物理卷b补全，则lvtest2会同时挂属于物理卷a和物理卷b，具体示例如下：