##目標
LVMを利用して論理ボリュームを作成する。
AWS EC2上での構築とする。
##前提
・EC2の構築手順を知っていること。
・LINUXでの基本的なディスク操作方法を知っていること。
・LVMの基本的な概念や用語を知っていること。
##LVMとは
物理ディスクや物理パーティションを束ねて、仮想ディスクや仮想パーティションを作成する機能のこと。
LVMを利用することで以下のような物理ディスク上の制約を回避することが可能となります。
・一度パーティションを作成するとサイズ変更が出来ない。
（⇒LVMではlvextendやlvreduceを利用して仮想パーティションのサイズを柔軟に変更することが可能）
・別のディスクにパーティションを移動させることができない。
（⇒LVMではpvmoveを利用してパーティション内のデータを別ディスクに移動させることが可能）
・ディスクのサイズを超える大きさのパーティションは作成できない。
（⇒LVMでは複数の物理ディスクにまたがって仮想ディスクを構築することが可能なため、所属するディスクサイズ以上のパーティションを構築することができる）
図とかも記載している参考サイトを掲載致します。
【Linuxの基礎知識】LVMとは？LVMを理解しよう！
##利用環境
ハードウェア ： AWS EC2サーバ 1台
OS（AMI） : Amazon Linux 2 AMI (HVM), SSD Volume Type
##作業の流れ
| 項番 | タイトル |
|---|---|
| 1 | EC2インスタンスの作成 |
| 2 | パーティション構築 |
| 3 | LVMの構築 |
| 4 | LVMの管理操作 |
##手順
###1.EC2インスタンスの作成
以下のように、データボリューム/dev/sdbと/dev/sdc（両デバイス最小の1GB）をアタッチしたEC2インスタンスを作成します。
###2.パーティション構築
作成したEC2インスタンスの/dev/sdbと/dev/sdc内に2つの基本パーティション（パーティションサイズは全て300MB）を構築します（※）。
パーティションタイプは8e（Linux LVM）とします。
※パーティション構築の手順は以下に記載しています、参考として掲載致します。
【RAID5】基本構築（2.RAID用パーティション構築）
[root@ip-172-31-38-158 tmp]# fdisk -l
# ルートボリューム/dev/xvda
Disk /dev/xvda: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 55BAE540-16DE-4A92-90DF-3330D51DF457
Device Start End Sectors Size Type
/dev/xvda1 4096 16777182 16773087 8G Linux filesystem
/dev/xvda128 2048 4095 2048 1M BIOS boot
Partition table entries are not in disk order.
# データボリューム/dev/xvdb（/dev/sdb）
# 基本パーティション2つを構築、どちらもサイズは300MBでパーティションタイプは8e
Disk /dev/xvdb: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x69289ddb
Device Boot Start End Sectors Size Id Type
/dev/xvdb1 2048 616447 614400 300M 8e Linux LVM
/dev/xvdb2 616448 1230847 614400 300M 8e Linux LVM
# データボリューム/dev/xvdc（/dev/sdc）
# 基本パーティション2つを構築、どちらもサイズは300MBでパーティションタイプは8e
Disk /dev/xvdc: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2654e9ba
Device Boot Start End Sectors Size Id Type
/dev/xvdc1 2048 616447 614400 300M 8e Linux LVM
/dev/xvdc2 616448 1230847 614400 300M 8e Linux LVM
###3.LVMの構築
①物理ボリュームの構築
pvcreateで前手順で作成したパーティションを物理ボリュームとしてLVMの管理対象とします。
pvcreate /dev/xvdb1 /dev/xvdb2 /dev/xvdc1 /dev/xvdc2
pvscanで物理ボリューム群の簡単な情報を表示します。
# 全パーティションがエントリに入っていればOK
[root@ip-172-31-38-158 ~]# pvscan
PV /dev/sdb1 lvm2 [300.00 MiB]
PV /dev/sdb2 lvm2 [300.00 MiB]
PV /dev/sdc2 lvm2 [300.00 MiB]
PV /dev/sdc1 lvm2 [300.00 MiB]
Total: 4 [1.17 GiB] / in use: 0 [0 ] / in no VG: 4 [1.17 GiB]
②ボリュームグループの構築
vgcreateで物理ボリューム/dev/xvdb1、/dev/xvdb2、/dev/xvdc1を束ねてボリュームグループtestvgを構築します。
vgcreate testvg /dev/xvdb1 /dev/xvdb2 /dev/xvdc1
vgdisplayで構築したボリュームグループの内容を確認します。
[root@ip-172-31-38-158 ~]# vgdisplay testvg
--- Volume group ---
VG Name testvg
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 3
Act PV 3
VG Size 888.00 MiB
PE Size 4.00 MiB
Total PE 222
Alloc PE / Size 0 / 0
Free PE / Size 222 / 888.00 MiB
VG UUID duuKl7-ogCc-FSEX-6EA6-7q1h-8hlE-2t5wFy
③論理ボリュームの構築
lvcreateでボリュームグループ（888MB）のうち500MBを論理ボリュームlv01として切り出します。
lvcreate -L 500M -n lv01 testvg
lvscanで作成した論理ボリュームの簡単な情報を表示します。
# /dev/testvg/lv01としてACTIVEのエントリが存在していればOK
[root@ip-172-31-38-158 ~]# lvscan
ACTIVE '/dev/testvg/lv01' [500.00 MiB] inherit
③論理ボリュームのマウント
論理ボリューム/dev/testvg/lv01にファイルシステムext4を作成します。
mkfs.ext4 /dev/testvg/lv01
/mntにマウントします。
mount /dev/testvg/lv01 /mnt
df-hでマウントの確認
/dev/mapper/testvg-lv01（※）のエントリが存在すれば論理ボリュームが利用可能となり完了です。
※Device Mapper（LVMに必須の機能）によってマウント時、/dev/ボリュームグループ名/論理ボリューム名は/dev/mapper/ボリュームグループ名-論理ボリューム名にマッピングされるようです。
[root@ip-172-31-38-158 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 474M 0 474M 0% /dev
tmpfs 492M 0 492M 0% /dev/shm
tmpfs 492M 428K 492M 1% /run
tmpfs 492M 0 492M 0% /sys/fs/cgroup
/dev/xvda1 8.0G 1.3G 6.8G 17% /
tmpfs 99M 0 99M 0% /run/user/1000
/dev/mapper/testvg-lv01 477M 2.3M 445M 1% /mnt
###4.LVMの管理操作
いくつかLVMの管理操作を試してみます。
①ボリュームグループの拡張と縮小
現状のボリュームグループtestvgの物理ボリュームの数は3つ、ボリュームグループサイズは888MB
[root@ip-172-31-38-158 ~]# vgdisplay
--- Volume group ---
VG Name testvg
System ID
Format lvm2
Metadata Areas 3
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 3 # 物理ボリューム数
Act PV 3
VG Size 888.00 MiB # ボリュームグループサイズ
PE Size 4.00 MiB
Total PE 222
Alloc PE / Size 125 / 500.00 MiB
Free PE / Size 97 / 388.00 MiB
VG UUID duuKl7-ogCc-FSEX-6EA6-7q1h-8hlE-2t5wFy
vgextendでボリュームグループtestvgに未使用の物理ボリューム/dev/xvdc2（300MB）を追加します。
vgextend testvg /dev/xvdc2
ボリュームグループの、物理ボリュームの数が4つ、ボリュームサイズが1.16GBまで拡大しました
[root@ip-172-31-38-158 ~]# vgdisplay testvg
--- Volume group ---
VG Name testvg
System ID
Format lvm2
Metadata Areas 4
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 4 # 物理ボリューム数が3から4に増えた
Act PV 4
VG Size <1.16 GiB # ボリュームグループサイズが888MBから1.16GBに増えた
PE Size 4.00 MiB
Total PE 296
Alloc PE / Size 125 / 500.00 MiB
Free PE / Size 171 / 684.00 MiB
VG UUID duuKl7-ogCc-FSEX-6EA6-7q1h-8hlE-2t5wFy
vgreduceで追加したデバイスをボリュームグループからデタッチします。
vgreduce testvg /dev/xvdc2
②論理ボリュームの拡張
現状の論理ボリューム/dev/testvg/lv0のサイズは500MB
[root@ip-172-31-38-158 ~]# lvscan
ACTIVE '/dev/testvg/lv01' [500.00 MiB] inherit
lvextendで論理ボリューム/dev/testvg/lv01を100MB拡張してみます
lvextend -L +100M /dev/testvg/lv01
サイズが600MBまで拡張されました。
[root@ip-172-31-38-158 ~]# lvscan
ACTIVE '/dev/testvg/lv01' [600.00 MiB] inherit
しかし、論理ボリュームを拡張してもファイルシステム（ext4）自体のサイズが自動拡張されるわけではないようなので、
resize2fsを利用してファイルシステムサイズを拡張した論理ボリュームのサイズに合わせます。
その前に事前にe2fsckを利用してファイルシステムの整合性チェックを行います。
アンマウント⇒e2fsck実行という流れです。
umount /dev/testvg/lv01
e2fsck -f /dev/testvg/lv01
ファイルシステムのリサイズを実行
resize2fs /dev/testvg/lv01
マウント実行をしてファイルシステムのサイズも共に拡張した論理ボリュームが利用可能になります。
mount /dev/testvg/lv01 /mnt
③スナップショットの作成とバックアップ取得及びリストア実行
LVMにはスナップショット（ある時点での論理ボリューム状態の断面記録）取得機能があり、これを利用することでdumpによるバックアップ取得時、**ファイルシステムをアンマウントしたり読み取り専用にすることなく、バックアップ取得を行うことが可能（dumpでディスクのバックアップを取得する際はアンマウントor読み取り専用にしてバックアップ取得を行うのがセオリー）**となります。
本項目では論理ボリュームのスナップショット取得⇒dumpコマンドによるバックアップ取得⇒restoreコマンドによるリストアという流れを試します。
リストア確認用のテストファイルとして/mnt/testfileを作成
touch /mnt/testfile
echo "test" >> /mnt/testfile
lvcreateコマンドに-sオプションをつけることで、スナップショットの取得が可能です。
サイズは論理ボリュームの10%-20%にするということなので100MBで作成、スナップショットの名前はsnap0とします。
lvcreate -s -L 100M -n snap0 /dev/testvg/lv01
lvscanでスナップショットの作成確認を行います。
# スナップショット/dev/testvg/snap0が作成されている
[root@ip-172-31-38-158 mnt]# lvscan
ACTIVE Original '/dev/testvg/lv01' [600.00 MiB] inherit
ACTIVE Snapshot '/dev/testvg/snap0' [100.00 MiB] inherit
dumpでのバックアップ保存に使用するファイルを作成します。
mkdir /backup
touch /backup/data.dump
dump -f /backup/data.dump /dev/testvg/snap0でスナップショット/dev/testvg/snap0のデータを/backup/data.dump内にバックアップとして保存します。
# 特にエラーなくDUMP: DUMP IS DONEが出力されること
[root@ip-172-31-38-158 mnt]# dump -f /backup/data.dump /dev/testvg/snap0
DUMP: Date of this level 0 dump: Sat Aug 29 07:22:51 2020
DUMP: Dumping /dev/testvg/snap0 (an unlisted file system) to /backup/data.dump
DUMP: Label: none
DUMP: Writing 10 Kilobyte records
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 54 blocks.
DUMP: Volume 1 started with block 1 at: Sat Aug 29 07:22:51 2020
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: Closing /backup/data.dump
DUMP: Volume 1 completed at: Sat Aug 29 07:22:51 2020
DUMP: Volume 1 50 blocks (0.05MB)
DUMP: 50 blocks (0.05MB) on 1 volume(s)
DUMP: finished in less than a second
DUMP: Date of this level 0 dump: Sat Aug 29 07:22:51 2020
DUMP: Date this dump completed: Sat Aug 29 07:22:51 2020
DUMP: Average transfer rate: 0 kB/s
DUMP: DUMP IS DONE
/tmp配下で、取得したバックアップを利用したリストアを実行します。
cd /tmp/
restore -r -f /backup/data.dump
以下のように事前作成したtestfileが/tmp内に展開されているため正常にリストアされたことが分かります。
[root@ip-172-31-38-158 tmp]# ls
restoresymtable testfile
[root@ip-172-31-38-158 tmp]# cat /tmp/testfile
test
バックアップ取得後、スナップショットは削除するのがセオリーのようです（スナップショット取得後、取得元の論理ボリュームに変更が加われば加わるほどスナップショット領域が拡大し、システムのパフォーマンスに影響が出るからとのこと）
lvremove /dev/testvg/snap0