Linux LVM--三种Logic Volume

概述

为了满足在性能和冗余等方面的需求，LVM支持了下面三种Logic Volume：

  1. Linear Logic Volume   --线性逻辑卷
  2. Striped Logic Volume --条带化逻辑卷
  3. Mirror Logic Volume   --镜像逻辑卷

Linear Logic Volume

我们用lvcreate命令默认创建出来的就是线性逻辑卷，线性逻辑卷使用的PE可以来自一个PV，也可以来自多个PV，一般情况下是先从第一个PV中分配PE，如果这个PV的PE已经分配完了，再依次从第二个PV、第三个PV里分配。可以通过指定PV甚至PE的号段来让Linear LV的PE分散到各个PV上，但是如果其中一个PV坏了，那么这个Linear LV可能也就没法用了。Linear LV的size可以直接用-L指定大小，也可以用-l指定分配PE的个数。往Linear LV中写入数据时，先往第一个PV的PE中写，直到第一个PV上分配的空间用完了才会将数据写到第二个PV。

Linear LV只能满足弹性分配的需求，无法满足性能和冗余的需求，是最普通的volume，但是Linear LV也可以通过lvconvert命令切换成Mirror LV来提供冗余能力。

  1.  
    root@hunk-virtual-machine:/home/hunk# lvcreate -l 100 -n linearlv VolGroup1 /dev/sdc:1280-1305 /dev/sdd:1280-1
  2.  
    305 /dev/sde:1280-1305 /dev/sdf:1280-1305

Striped Logic Volume

Striped LV的底层存储布局类似于RAID0，它是跨多个PV的，具体是跨多少个PV用-i指定，但是肯定不能超过VG中PV的数量，Striped LV的最大size取决于剩余PE最少的那个PV。

Striping的意思是将每个参与Striping的PV划分成等大小的chunk（也叫做stripe unit），每个PV同一位置的这些chunk共同组成一个stripe。比如下面这张图（来自于RedHat6官方文档），包含三个PV，那么红色标识的1、2、3这3个chunk就组成了stripe1，4、5、6组成stripe2。chunk的大小可以通过-I或者--stripesize来指定，但是不能超过PE的大小。

比如，向Striped LV写入数据时，数据被分成等大小的chunk，然后将这些chunk顺序写入这些PV中。这样的话就会有多个底层disk drive并发处理I/O请求，可以得到成倍的聚合I/O性能。还是下面这张图，假如现在有一个4M数据块需要写入LV，stripesize设置的512K，LVM把它切成8个chunk，分别标识为chunk1、chunk2...，这些chunk写入PV的顺序如下：

  1. chunk1写入PV1
  2. chunk2写入PV2
  3. chunk3写入PV3
  4. chunk4写入PV1
  5. ...

因为LVM无法判断多个Physics Volume是否来自同一个底层disk，如果Striped LV使用的多个Physics Volume实际上是同一个物理磁盘上的不同分区，就会导致一个数据块被切成多个chunk分多次发给同一个disk drive，这种情况实际上Striped LV并不能提升性能，反而会使性能下降。所以说，Striped LV提升I/O性能的本质是让多个底层disk drive并行处理I/O请求，而不是表面上的把I/O分散到了多个PV上。

Striped LV主要满足性能需求，没有做任何冗余，所以没有容错能力，如果单个disk损坏，就会导致数据损坏。

root@hunk-virtual-machine:/home# lvcreate -L 20G --stripes 4 --stripesize 256 --name stripevol VolGroup1
 

Mirror Logic Volume

Mirror LV就是各个PV之间做冗余，类似于RAID1，通过-m指定冗余数量。Mirror LV提供冗余能力，可以有效解决磁盘单点故障问题，但是性能方面没有帮助。Linear LV和Mirror LV直接用lvconvert工具来相互切换，Mirror LV在创建后也可以更改冗余数，具体用法请参考man page。

  1.  
    root@hunk-virtual-machine:/home/hunk# lvcreate -l 100 -m1 -n mirrorvol VolGroup1
  2.  
    Logical volume "mirrorvol" created.
  3.  
    root@hunk-virtual-machine:/home/hunk# lvdisplay /dev/VolGroup1/mirrorvol -m
  4.  
    --- Logical volume ---
  5.  
    LV Path /dev/VolGroup1/mirrorvol
  6.  
    LV Name mirrorvol
  7.  
    VG Name VolGroup1
  8.  
    LV UUID YxgfYi-c7nK-wk4v-rlu1-vRdh-MTMb-uVfl2v
  9.  
    LV Write Access read/write
  10.  
    LV Creation host, time hunk-virtual-machine, 2018-11-29 01:39:44 +0800
  11.  
    LV Status available
  12.  
    # open 0
  13.  
    LV Size 400.00 MiB
  14.  
    Current LE 100
  15.  
    Mirrored volumes 2
  16.  
    Segments 1
  17.  
    Allocation inherit
  18.  
    Read ahead sectors auto
  19.  
    - currently set to 256
  20.  
    Block device 252:8
  21.  
     
  22.  
    --- Segments ---
  23.  
    Logical extents 0 to 99:
  24.  
    Type raid1
  25.  
    Monitoring monitored
  26.  
    Raid Data LV 0
  27.  
    Logical volume mirrorvol_rimage_0
  28.  
    Logical extents 0 to 99
  29.  
    Raid Data LV 1
  30.  
    Logical volume mirrorvol_rimage_1
  31.  
    Logical extents 0 to 99
  32.  
    Raid Metadata LV 0 mirrorvol_rmeta_0
  33.  
    Raid Metadata LV 1 mirrorvol_rmeta_1

测试Linaer/Striped LV

准备多个disk

在测试环境中添加了4个virtual disk，size都是10GB。

先用这4个virtual disk创建一个type为linear，size为20GB的Linaer LV，从后面查询LV的详情可以看出，这个LV实际上跨了3个PV。

  1.  
    root@hunk-virtual-machine:/home/hunk# pvcreate /dev/sd[cdef]
  2.  
    Physical volume "/dev/sdc" successfully created
  3.  
    Physical volume "/dev/sdd" successfully created
  4.  
    Physical volume "/dev/sde" successfully created
  5.  
    Physical volume "/dev/sdf" successfully created
  1.  
    root@hunk-virtual-machine:/home/hunk# vgcreate VolGroup1 /dev/sd[cdef]
  2.  
    Volume group "VolGroup1" successfully created
  1.  
    root@hunk-virtual-machine:/home/hunk# lvcreate -L 20G -n linnervol VolGroup1
  2.  
    Logical volume "linnervol" created.
  1.  
    root@hunk-virtual-machine:/home/hunk# mkfs.ext4 /dev/VolGroup1/linnervol
  2.  
    root@hunk-virtual-machine:/home/hunk# mount /dev/VolGroup1/linnervol /volumetest
  3.  
    root@hunk-virtual-machine:/home/hunk# df -h |grep linnervol
  4.  
    /dev/mapper/VolGroup1-linnervol 20G 44M 19G 1% /volumetest

测试Linear LV

现在，用bonnie++来模拟IO，不停地向这个LV中写入数据。

  1.  
    root@hunk-virtual-machine:/volumetest# bonnie++ -n 0 -u 0 -r `free -m | grep 'Mem:' | awk '{print $2}'` -s $(echo "scale=0;`free -m | grep 'Mem:' | awk '{print $2}'`*2" | bc -l) -f -b -d /volumetest/
  2.  
    Using uid:0, gid:0.
  3.  
    Writing intelligently...

在新窗口用bwm-ng来监控4个磁盘的IO速率，我们发现只有sdc上面有I/O请求，然而其他disk都很空闲，看着sdc一个家伙在忙。

bwm-ng -i disk -I sdc,sdd,sde,sdf
 
  1.  
    bwm-ng v0.6 (probing every 0.500s), press 'h' for help
  2.  
    input: disk IO type: rate
  3.  
    \ iface Rx Tx Total
  4.  
    ==============================================================================
  5.  
    sdc: 0.00 KB/s 12263.47 KB/s 12263.47 KB/s
  6.  
    sdd: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  7.  
    sde: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  8.  
    sdf: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  9.  
    ------------------------------------------------------------------------------
  10.  
    total: 0.00 KB/s 12263.47 KB/s 12263.47 KB/s

我们继续查看LV中写入数据的量，直到写入数据超过10G时，发现sdc已经不再处理I/O请求了，因为数据已经塞满了嘛。而sdd开始继续处理持续的I/O请求。在写入数据10G多一点的时候，中间实际上有个过度过程，就是sdc和sdf都在处理I/O，这个是因为缓冲造成的。

  1.  
    root@hunk-virtual-machine:/home/hunk# df -h |grep linner
  2.  
    /dev/mapper/VolGroup1-linnervol 20G 11G 8.1G 57% /volumetest
  1.  
    bwm-ng v0.6 (probing every 0.500s), press 'h' for help
  2.  
    input: disk IO type: rate
  3.  
    | iface Rx Tx Total
  4.  
    ==============================================================================
  5.  
    sdc: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  6.  
    sdd: 0.00 KB/s 12263.47 KB/s 12263.47 KB/s
  7.  
    sde: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  8.  
    sdf: 0.00 KB/s 0.00 KB/s 0.00 KB/s
  9.  
    ------------------------------------------------------------------------------
  10.  
    total: 0.00 KB/s 12263.47 KB/s 12263.47 KB/s

测试Stripe LV

移除前面使用的Linear LV

  1.  
    root@hunk-virtual-machine:/home# lvremove /dev/VolGroup1/linnervol
  2.  
    Do you really want to remove and DISCARD active logical volume linnervol? [y/n]: y
  3.  
    Logical volume "linnervol" successfully removed

创建一个条带化的LV

  1.  
    root@hunk-virtual-machine:/home# lvcreate -L 20G --stripes 4 --stripesize 256 --name stripevol VolGroup1
  2.  
    WARNING: ext4 signature detected on /dev/VolGroup1/stripevol at offset 1080. Wipe it? [y/n]: y
  3.  
    Wiping ext4 signature on /dev/VolGroup1/stripevol.
  4.  
    Logical volume "stripevol" created.
  5.  
    root@hunk-virtual-machine:/home# lvdisplay /dev/VolGroup1/stripevol -m
  6.  
    --- Logical volume ---
  7.  
    LV Path /dev/VolGroup1/stripevol
  8.  
    LV Name stripevol
  9.  
    VG Name VolGroup1
  10.  
    LV UUID z0MGOg-g6JL-hiE8-9Gt0-RZAJ-K29m-I6tcrS
  11.  
    LV Write Access read/write
  12.  
    LV Creation host, time hunk-virtual-machine, 2018-11-27 01:45:41 +0800
  13.  
    LV Status available
  14.  
    # open 0
  15.  
    LV Size 20.00 GiB
  16.  
    Current LE 5120
  17.  
    Segments 1
  18.  
    Allocation inherit
  19.  
    Read ahead sectors auto
  20.  
    - currently set to 4096
  21.  
    Block device 252:6
  22.  
     
  23.  
    --- Segments ---
  24.  
    Logical extents 0 to 5119: #Striped LV映射的PE均匀分布在了4个PV上
  25.  
    Type striped
  26.  
    Stripes 4
  27.  
    Stripe size 256.00 KiB
  28.  
    Stripe 0:
  29.  
    Physical volume /dev/sdc
  30.  
    Physical extents 0 to 1279
  31.  
    Stripe 1:
  32.  
    Physical volume /dev/sdd
  33.  
    Physical extents 0 to 1279
  34.  
    Stripe 2:
  35.  
    Physical volume /dev/sde
  36.  
    Physical extents 0 to 1279
  37.  
    Stripe 3:
  38.  
    Physical volume /dev/sdf
  39.  
    Physical extents 0 to 1279
  1.  
    root@hunk-virtual-machine:/home# mkfs.ext4 /dev/VolGroup1/stripevol
  2.  
    mke2fs 1.42.13 (17-May-2015)
  3.  
    Creating filesystem with 5242880 4k blocks and 1310720 inodes
  4.  
    Filesystem UUID: 51dbdea0-48fc-4324-9974-42443e424aa0
  5.  
    Superblock backups stored on blocks:
  6.  
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
  7.  
    4096000
  8.  
     
  9.  
    Allocating group tables: done
  10.  
    Writing inode tables: done
  11.  
    Creating journal (32768 blocks): done
  12.  
    Writing superblocks and filesystem accounting information: done
  13.  
     
  14.  
    root@hunk-virtual-machine:/home# mount /dev/VolGroup1/stripevol /volumetest/
  15.  
    root@hunk-virtual-machine:/home# df -h |grep stripe
  16.  
    /dev/mapper/VolGroup1-stripevol 20G 44M 19G 1% /volumetest

用同样的方法测试这个条带化的LV，不过这里的测试比较粗糙，不仅忽略了很多测试要素，前面对Linear LV的测试中bwm的I/O速率是每0.5s一次的采样值，而这里Striped LV的取的I/O速率是30s内的均值。不过我们这里并不是想得到准确的I/O速率，就先不考虑这些因素吧。明显能看出来4个disk在并行的处理I/O请求，也就是给Striped LV的I/O请求最终被分散到了多个底层disk上面，这样聚合的I/O效率必然会高出好几倍。

bwm-ng -i disk -I sdc,sdd,sde,sdf
 

 

  1.  
    bwm-ng v0.6 (probing every 0.500s), press 'h' for help
  2.  
    input: disk IO type: avg (30s) --取30S内采用的均值
  3.  
    / iface Rx Tx Total
  4.  
    ==============================================================================
  5.  
    sdc: 0.13 KB/s 10010.92 KB/s 10011.05 KB/s
  6.  
    sdd: 0.00 KB/s 10174.32 KB/s 10174.32 KB/s
  7.  
    sde: 0.00 KB/s 6563.85 KB/s 6563.85 KB/s
  8.  
    sdf: 0.00 KB/s 6113.09 KB/s 6113.09 KB/s
  9.  
    ------------------------------------------------------------------------------
  10.  
    total: 0.13 KB/s 32862.18 KB/s 32862.32 KB/s

 

 

 

 

 
 posted on 2019-10-24 13:37  xibuhaohao  阅读(2032)  评论(0)  编辑  收藏  举报