レンタルサーバーに関連しているというよりは、VPS(バーチャル・プライベート・サーバー:Virtual Private Server)や自宅サーバー向けの話題です。
LVMとは?
LVMはディスク(ボリューム)管理をするツールです。
LVMは「論理ボリューム管理:Logical Volume Manager」の略です。
論理的にLinuxのボリューム(ディスク)を管理するツールですが、最近ではLinuxをインストールする際に自動的にLVMで管理されます。
今回は、この LVM について説明します。
LVMによる論理的なパーティション管理
「物理的」にパーティションを管理するのではなく、「論理的」にパーティションを管理します。
「直接管理する」のではなく仮想的なパーティションを動的に管理します。
※パーティションとは、「partition→仕切り、区切り、区画」という意味です。Linuxでパーティションとは「/」「/usr」「/home」「/var」などの独立したファイルシステムのことを言います。
ハードディスクをパーティションに分割して、それぞれのパーティションに個別にファイルシステムを定義しています。
LVMが役に立つケース(LVMのメリット)
メリット1.小さいHDDを合わせて、巨大な1つのパーティションを作りたい
例えば、古くて100GBなどサイズが小さいHDDが複数個あったとして、1つずつなら使い物にならなくても複数のHDD(ハードディスクドライブ)を組み合わせて1つのボリュームにしてしまうことでOSもアプリもインストールできるサイズのディスクを作成することができます。
今までならサイズが小さいHDDはまだ使えるのに捨てていたかもしれませんが、LVMで管理することにより問題なく使用することができるようになります。
メリット2.巨大なサイズのHDDを細かく分割したいが、サイズに柔軟性を持たせたい
逆にLVMを利用して1つの巨大なHDDを細かく分割することもできます。
ただ分割するだけならLVMを使わなくても十分可能ですが、LVMのいいところは細かく分割して管理して、万が一パーティションが足りなくなってもサイズを拡大させることができます。
例えば、レンタルサーバーは多数の人間が1台のレンタルサーバーを共有していますが、セキュリティや障害に備えて細かくパーティションを分けて運用管理をして、いざレンタルサーバーのパーティションサイズが足りなくなった場合に救済策としてLVMでサイズを増やすことができます。
もしLVMで管理をしていない場合は、データを移動したり複雑な作業が発生するので障害を引き起こすリスクが高くなります。
自宅PCで自分しか使っていないなら、最悪再インストールをすればいいだけの話ですが、商用でレンタルサーバーなどを運用している場合はデータが消えましたでは済まされません。
メリット3.スナップショットを取りたい
スナップショットとは、その瞬間のボリュームのイメージのことです。
スナップショットは、サービスを停止せずに取得することができます。
(もちろん多数のデータ更新があるデータベースが入っているボリュームのスナップショットの場合、整合性は保証できなくなります)
スナップショットはコピーバックアップと異なり、基本的にデータは持っていません。
そのため、スナップショット取得後にデータが更新された場合は、更新される前のデータをスナップショットが保持することでスナップショット取得時の状態を保持します。
※スナップショットはバックアップではありません。
メリット4.パーティションの設定や管理で頭を悩みたくない
サーバーを管理していると大変です。
レンタルサーバーも、突然100GBで契約しているのに、1TB使いたいと言ってくるユーザーがいるかもしれません。
データを壊さずに柔軟に対応できれば、ユーザーにとって価値のあるサービスを提供してくれるレンタルサーバー会社になれます。
※でも大体のレンタルサーバー会社は、プランを変更したらファイルも全部消去されるので自分でデータを移してくださいという契約になっている。
→責任範囲とかいろいろ難しい面があるからか。しかしここまでサービスをしてれるといいアピールにはなりそう。
LVMで管理せずに直接管理をする場合は、以下の制約があります。
LVMを使わないことによる制約とは?
制約1.一度パーティションを作成すると簡単にサイズ変更ができない
例えば、/varのパーティション(ファイルシステム)を10GBで作成したとします。
/var配下にはログがどんどんたまっていきます。
その結果、あっという間に/var配下のファイルが10GBになりました。
しかしLVMを使っていないと簡単に/varのパーティションのサイズは変更できません。
(リスクの高いオペレーション、OSの再起動、レスキューモードでの作業等、リスクが高くストレスがかかる作業が必要になります)
制約2.別のディスクにパーティションを移動できない
手持ちのディスクA(サイズ:10GB)にLinuxをインストールしました。
/homeのパーティションの容量が増えました。
そのため、ディスクB(サイズ:20GB)を追加しました。
では、「/home」が格納されているディスクAからディスクBに動かせるかというと、LVMで管理をしていないと動かせません。
最近のLinuxではインストーラが自動的に「LVM」でパーティションを作成する
実際にCentOS7をインストールして確認してみました。
下図はインストール時のパーティション作成の場面です。
「パーティション構成」に関して「パーティションを自動構成する」を選択してインストールをしました。
インストール完了後、ログインしてパーティション構成を確認してみます。
[root@localhost ~]# fdisk /dev/sda Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. コマンド (m でヘルプ): p ← fdiskの内部コマンド「p」でパーティションを確認します。 Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors デバイス ブート 始点 終点 ブロック Id システム コマンド (m でヘルプ): |
旧来のパーティション分割方式の場合、1つのハードディスクをいくつかのパーティションに分割することしかできませんでした。
そのため、個々のハードディスクの容量を超える大きさのパーティションを作ることはできませんでした。
それに一度設定したパーティション容量をあとからサイズ変更するのは大変です。
LVMは、このような従来のパーティション分割方式の不便さを解消し、パーティションを柔軟に管理できるようにするディスク管理ツールです。
LVMの基本的な仕組み
LVMの基本的な仕組みは「物理的な」パーティションを細かなブロックに分割し、そのブロックを多数寄せ集めて「論理的な」パーティションとして再構成する仕組みです。
LVMは下図のような構成になっています。
下図を例として説明します。
HDDが2台あるとして、この2台のHDDから「/dev/sda1」「/dev/sdb1」の2つのパーティションが作成されます。
LVMはこの「/dev/sda1」「/dev/sdb1」を「PV(物理ボリューム:Physical Volume)」に変換します。
変換された「PV」を更に「PE(物理エクステント:Physical Extent)」に分割します。
PEはLVMが管理する最小単位となります。
PEのサイズは 8KB ~ 512MB まで自由に設定できます。
ただしあまり大きくPEのサイズを取りすぎると、ディスクI/Oが効率的になる反面、ディスクの無駄遣いが発生するなどトレードオフを考慮した設計が必要になります。
そしてこのPEを集めて「VG(Volume Group)ボリューム・グループ」が作成されます。
このVGを分割して「LV(Logical Volume)論理ボリューム」が作成されます。
このLVから「/dev/cl/root」パーティションや「/dev/cl/home」パーティションが作られます。
LVMの操作手順
CentOS上での操作方法を解説します。
今回は、新しくHDDを追加した場合に既存のLVMのシステムに組み入れる手順です。
設計
何はともあれ設計です。
今回は
- 新しくHDDを追加する
- 追加した1つのHDDから2つのLVM用のパーティション(論理ボリューム:LV)を作成する
- 1つの論理ボリューム(LV)を「/dev/cl/lv_test」にする
- もう1つの論理ボリュームを「/dev/cl/lv_home_test」にする
- 作成した「/dev/cl/lv_test」を「/」にマウントする
- 作成した「/dev/cl/lv_home_test」を「/home」にマウントする
という構成で構築してみます。
図解すると下図のようになります。
作業概要
- 1.HDDを追加する
- 2.PV(物理ボリューム)を作成する
- 3.PE(物理エクステント)を作成する
- 4.VG(ボリュームグループ)を作成する
- 5.LV(論理ボリューム)を作成する
- 6.ファイルシステムを作成する
です。
パーティションを作成する
パーティションを作成します。
全体の構成図で見ると下図の青線で囲まれた個所となります。
早速、現状の構成を確認します。
fdiskコマンドで現在のディスク構成(どんなディスクがパソコンに搭載されているのか)を確認します。
また、dfコマンドでディスクとパーティションの関係を確認します。
# fdisk -l
Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors ← /dev/sdaは全体で32.2GBです。この/dev/sdaが「/dev/mapper/cl-root」と「/dev/mapper/cl-swap」に分かれています。 デバイス ブート 始点 終点 ブロック Id システム Disk /dev/sdb: 7516 MB, 7516192768 bytes, 14680064 sectors ← 新規で追加したディスク「/dev/sdb」は7GBあります。
Disk /dev/mapper/cl-root: 29.0 GB, 28982640640 bytes, 56606720 sectors
Disk /dev/mapper/cl-swap: 2147 MB, 2147483648 bytes, 4194304 sectors # df -h |
実際に/dev/sdbをLVMで構成されたパーティションに設定してみましょう。
※物理ボリューム(PV)はHDD単位ではなくパーティション単位で作成します。
# fdisk /dev/sdb Changes will remain in memory only, until you decide to write them. Device does not contain a recognized partition table コマンド (m でヘルプ): p ← パーティションを表示させます。 Disk /dev/sdb: 7516 MB, 7516192768 bytes, 14680064 sectors ← /dev/sdbの容量は7GBあります。 デバイス ブート 始点 終点 ブロック Id システム コマンド (m でヘルプ): m ← fdiskの内部コマンドを確認します。 コマンド (m でヘルプ): n ← 新しくパーティションを作成します。 コマンド (m でヘルプ): t ← 続けてfdiskの内部コマンド「t」を実行します。「t」コマンドはパーティションのタイプを設定します。 0 空 24 NEC DOS 81 Minix / 古い Li bf Solaris コマンド (m でヘルプ): p ← 正しく設定されていることを確認します。 Disk /dev/sdb: 7516 MB, 7516192768 bytes, 14680064 sectors デバイス ブート 始点 終点 ブロック Id システム コマンド (m でヘルプ): w ← fidskの内部コマンド「w」で設定を反映させます。 ioctl() を呼び出してパーティションテーブルを再読込みします。 Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors デバイス ブート 始点 終点 ブロック Id システム Disk /dev/sdb: 7516 MB, 7516192768 bytes, 14680064 sectors デバイス ブート 始点 終点 ブロック Id システム Disk /dev/mapper/cl-root: 29.0 GB, 28982640640 bytes, 56606720 sectors
Disk /dev/mapper/cl-swap: 2147 MB, 2147483648 bytes, 4194304 sectors |
PV(物理ボリューム)の作成
次に作成したパーティションに対して pvcreate コマンドを実行し PV(物理ボリューム) を作成します。
全体の構成図で見ると、下図の青い線の部分です。
PVを作成するためには「pvcreate」コマンドを実行します。
下のコマンドは「/dev/sdb1」に対して実行しています。
# pvcreate /dev/sdb1 Physical volume “/dev/sdb1” successfully created. |
パーティションは4つに分割出来て(プライマリの場合)「/dev/sdb1」とか「/dev/sdc3」とか番号がついていくよ。
PVを確認します。
PVを確認する場合は「pvscan」および「pvdisplay」コマンドを実行します。
# pvscan PV /dev/sda2 VG cl lvm2 [29.00 GiB / 4.00 MiB free] PV /dev/sdb1 lvm2 [7.00 GiB] ← PVが作成されましたが、まだどこにも所属していません。 Total: 2 [36.00 GiB] / in use: 1 [29.00 GiB] / in no VG: 1 [7.00 GiB] # pvdisplay “/dev/sdb1” is a new physical volume of “7.00 GiB” |
問題なく物理ボリュームが作成されています。
次はボリュームグループを作成します。
VG(ボリューム・グループ)の作成
PV(物理ボリューム)を作成してもLVMで使うためには必ず「VG(ボリュームグループ)」に組み入れなければいけません。
PVが1つだけでも、VGに組み入れます。
全体の構成図を見ると下図の青線の部分になります。
(既存のVGに組み入れるため、青線が半分の位置にまたがっています)
今回の場合は CentOS のインストール時に自動的にLVMでファイルシステムを作成していますのですでにVG(cl)は存在していますので、このVG(cl)に「/dev/sdb1」を組み込みます。
すでにあるVGを確認します。
# vgdisplay — Volume group — VG Name cl ← すでにお気づきかもしれませんが、dfコマンドを実行して「/dev/mapper/cl-root」という結果が返ってきていましたが、この「cl-root」の「cl」がボリュームグループ名になります。「/dev/sdb1」も「cl」に組み込みます。 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 29.00 GiB PE Size 4.00 MiB Total PE 7423 Alloc PE / Size 7422 / 28.99 GiB Free PE / Size 1 / 4.00 MiB VG UUID x3BtfV-h2D7-DFIn-Klhr-dolK-jHS5-daqRUt |
今回は、ゼロからボリュームグループを作成するのではなく、既存のボリュームグループ「cl」に組み込むので「vgextend」コマンドを実行します。
# vgdisplay ← vgextendコマンドを実行する前に現在の構成を確認します。 — Volume group — VG Name cl System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 29.00 GiB ← 「vgextend」コマンドを実行する前は29GBしかありません。 PE Size 4.00 MiB Total PE 7423 Alloc PE / Size 7422 / 28.99 GiB Free PE / Size 1 / 4.00 MiB VG UUID x3BtfV-h2D7-DFIn-Klhr-dolK-jHS5-daqRUt # vgextend cl /dev/sdb1 ← 「/dev/sdb1」を既存のボリュームグループ「cl」に組み込みます。 # vgdisplay ← ボリュームグループを確認します。 # pvscan ← pvscanコマンドでも確認します。 |
今回はOSインストール時に作成した既存のボリュームグループに追加する形になっていますが、ゼロから作成する場合は以下のように「vgcreate」コマンドを実行します。
【例】
新規でボリュームグループ「cl」を作成して、PV(物理ボリューム)の「/dev/sda2」と「/dev/sdb1」を物理エクステント(PE)のサイズを8MBで組み込む場合
# vgcreate -s 8M cl /dev/sda2 /dev/sdb1 |
LV(論理ボリューム)の作成
次はVG(ボリュームグループ)からLV(論理ボリューム)を作成します。
LV(論理ボリューム)は仮想的なパーティションになります。
LVはVGから必要なサイズを切り出す形で作成します。
全体の構成図で見ると下図の青線の部分になります。
今回は以下のような設計にします。
全体のVG:37GB
/(root) ディレクトリ:LV名:root:30GB(既存、変更しない)
/test ディレクトリ:LV名:lv_test:4GB
/home/test01 ディレクトリ:LV名:lv_home_test:約3GB(残り全部)
※すでにOSのインストールで「/(rootディレクトリ)」が作成されているので、これは変更しません。
初めに「lvscan」と「lvdisplay」コマンドで既存のLVを確認します。
# lvscan ACTIVE ‘/dev/cl/swap’ [2.00 GiB] inherit ACTIVE ‘/dev/cl/root’ [26.99 GiB] inherit # lvdisplay — Logical volume — |
次に新規でlvを作成します。
# lvcreate -L 4G -n lv_test cl ← ボリュームグループ(cl)から4GBを使って論理ボリューム(lv_test)を作成します。 Logical volume “lv_test” created. # lvscan ← lvscanコマンドで確認します。 # lvcreate -l 100%FREE -n lv_home_test cl ← 残りの領域をすべてlv_home_testに割り当てます。 # lvscan # lvdisplay — Logical volume — — Logical volume — — Logical volume — |
ファイルシステムを作成
最後にLV(論理ボリューム)にファイルシステムを作成し、既存のファイルシステムにマウントして利用できるようにします。
全体の構成図から見ると青線の部分になります。
ここまでの作業によって、通常のパーティションと同じように扱えるよう論理ボリュームを2つ作成しました。
あとはこのLVにファイルシステムを作成すれば、マウントしてファイルを読み書きすることができるようになります。
今回はOSがCentOS7なので「xfs」でファイルシステムを作成しました。
# mkfs.xfs /dev/mapper/cl-lv_test meta-data=/dev/mapper/cl-lv_test isize=512 agcount=4, agsize=262144 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=0, sparse=0 data = bsize=4096 blocks=1048576, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 # mkfs.xfs /dev/mapper/cl-lv_home_test |
次にマウントポイントを作成します。
# mkdir /test
# mkdir /home/test |
マウントします。
# mount /dev/cl/cl-lv_test /test # mount /dev/cl/lv_home_test /home/test # df -h |
最後に忘れがちですが、OSを再起動しても自動的にマウントするように「/etc/fstab」を編集します。
# cat /etc/fstab
# # cp -ip /etc/fstab /home/test/backup/fstab ← 念のためバックアップを取ります。 # vi /etc/fstab # /etc/fstab # Created by anaconda on Thu May 18 07:05:01 2017 # # Accessible filesystems, by reference, are maintained under ‘/dev/disk’ # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/cl-root / xfs defaults 0 0 UUID=acfad4b8-0209-4f14-b6bf-71fba5ccbe80 /boot xfs defaults 0 0 /dev/mapper/cl-swap swap swap defaults 0 0 /dev/mapper/cl-lv_test /test xfs defaults 0 0 /dev/mapper/cl-lv_home_test /home/test xfs defaults 0 0 |
LVMの基本用語
一通り手順を基にLVMについて解説しましたが、基本的な仕組みはさほど難しくはないと思います。
ただ単に重層化しているだけで順番通りに作業をすれば問題なくファイルシステムが作成できます。
ただ、LVMの構成要素を指す独特の用語が使われるために、最初だけ混乱するかもしれませんが、何度か作業をすることで理解できるようになると思います。
下に基本用語について解説しますが、個人的には用語よりも作業をすることの方が早く覚えられると思います。
参考に全体の構成図を載せます。
PV(物理ボリューム:Pysical Volume)
「物理ボリューム」とはパーティションのことです。
PVは「物理的な」ボリューム、つまりハードディスク上に作成したパーティションを指します。
パーティションを作成する際に指定する種類 (type)は、 [LVM」で作成します。
このボリュームをPVとして使えるようにするために物理工クステント(PE) を作成します。
PE(物理工クステント:Pysical Extent)
PVを一定サイズの領域に分割したものがPEです。
LVMは、この小さなPEを集めてボリューム・グループ(VG)を構成します。
ボリューム・グループ(VG: Volume Group)
複数の物理ボリューム(PV)を1つにまとめて名付けたものがボリューム・グループ(VG)です。
このVGを切り分けてLVを作成します。
PEを寄せ集めて構成されているので物理的なハードディスクの制約を受けず、追加・切り離しなど自由に構成することができます。
サイズの拡大/縮小も可能です。
LV(論理ボリューム:Logical Volume)
VGから切り取ってLVを作成します。
物理ボリューム(PV)と異なり、LV(論理ボリューム)は「仮想上の」パーティションです。
コメント