レベル: 中級 Klaus Heinrich Kiwi (klausk@br.ibm.com), Software Development Engineer, IBM
2007年 9月 11日
2007年 9月 20日 更新 ボリューム管理は -ix の世界 (UNIX®、AIX など) では目新しいものではありません。論理ボリューム管理 (LVM) にしても、すでに Linux® カーネル 2.4v1 および 2.6.9v2 から導入されています。この記事で紹介する LVM2 は、論理ボリューム管理機能を提供する比較的新しいユーザー空間のツール・セットです。ここではとりわけ役に立つ LVM2 の機能を紹介するとともに、システム管理タスクを容易にする方法をいくつか提案します。読者からのフィードバックを基に、著者によりリスト 10、14、15、および 16 が更新されています (編集者より)。
論理ボリューム管理 (LVM) は、システムが物理ボリューム管理をより総体的で一般にはより単純なパラダイムへと抽象化する 1 つの方法です。LVM を用いることで、すべての物理ディスクおよびパーティションをそのサイズや分散状態に関わらず単一のストレージ・ソースとして抽象化し、把握できるようになります。その一例として、図 1 の物理対論理のマッピング・レイアウトを見てください。これらのディスクのうち、最大のディスクが 80GB の容量だとすると、例えば 150GB のファイルシステムを作成するにはどうすればいいでしょうか。
図 1. 物理対論理のマッピング
LVM はパーティションとディスク全体を仮想ディスクに集約することによって、こまごまとしたストレージ・スペースを 1 つの大きな統合スペースに繋ぎ合わせます。この仮想ディスクのことを、LVM 用語ではボリューム・グループと呼んでいます。
このようにストレージ管理を総体的にとらえたパラダイムが持つ驚くべき機能は、最大のディスクより大きなファイルシステムを実現できることだけではありません。LVM には以下の機能もあります。
- ディスク/パーティションをディスク・プールに追加し、既存のファイルシステムをオンライン状態のまま拡張する
- システムをオフライン状態に切り替えたり、ディスク間でデータを手動で移動させることなく、80GB のディスク 2 基を 160GB の ディスク 1 基と交換する
- ディスクのストレージ・スペースが必要なくなった場合、ファイルシステムを縮小してディスクをプールから削除する
- スナップショットを使用して一貫性のあるバックアップを行う (この記事のなかで詳しく説明)
LVM2 は、Linux で論理ボリューム管理機能を提供する新しいユーザー空間のツール・セットで、元の LVM ツール・セットとの完全な後方互換性を持ちます。この記事では、LVM2 のなかでもとりわけ便利な機能を取り上げるとともに、その他にもシステム管理タスクを容易にする LVM2 の用途を紹介します (ちなみに、LVM の基本的ガイドをお探しの方は、「参考文献」セクションに記載した LVM HowTo を参照してください)。
それではまず、LVM の構成から見ていきましょう。
LVM の構成
LVM には以下の 3 つの構成要素があります。
- ボリューム: 物理ボリューム、論理ボリューム、ボリューム・グループ
- エクステント: 物理および論理エクステント
- デバイス・マッパー: Linux カーネル・モジュール
ボリューム
Linux LVM は、物理ボリューム (PV)、ボリューム・グループ (VG)、そして論理ボリューム (LV) に分けられます。物理ボリュームとは、物理ディスクまたは物理ディスク・パーティションのことです (/dev/hda や /dev/hdb1 など)。物理ボリュームを集約するとボリューム・グループとなり、ボリューム・グループを論理的に区分化したものが論理ボリュームとなります。
図 2 に、ディスク 3 基のレイアウトを示します。
図 2. 物理ボリュームと論理ボリュームのマッピング
上記の図では、物理ディスク 0 (physical disk 0) (/dev/hda[1-4]) の 4 つのパーティション、そして物理ディスク 1 (physical disk 1) (/dev/hdb) と物理ディスク 2 (physical disk 2) (/dev/hdd) がそれぞれ PV としてボリューム・グループ VG0 に追加されています。
ボリューム・グループでは、(n 個の PV が m 個の LV と見なされるように) n 対 m という巧妙なマッピングが行われています。したがって、PV がボリューム・グループに割り当てられた後は (VG のサイズを最大サイズとして) 任意のサイズの論理ボリュームを作成することが可能となります。図 2 の例では、LV0 というボリューム・グループを作成し、残りの LV については空きスペースのままにしてあります (後で LV0 を拡張できるようにするため)。
論理ボリュームは、LVM の物理ディスク・パーティションに相当します。実際に、論理ボリュームは物理ディスク・パーティションであると言えます。
このような理由から、作成した LV はどのファイルシステムでも使用することが可能で、マウント・ポイントにマウントすれば早速使い始めることができます。図 3 に、/var にマウントしたフォーマット済み論理ボリューム LV0 を示します。
図 3. 物理ボリュームとファイルシステムのマッピング
エクステント
n 対 m の物理ボリューム対論理ボリュームのマッピングを行うには、PV と VG の基本ブロックの定量サイズが共通していなければなりません。この基本ブロックはそれぞれ物理エクステント (PE)、論理エクステント (LE) と呼ばれます。n 個の物理ボリュームから m 個の論理ボリュームへのマッピングとは関係なく、PE と LE は常に 1 対 1 でマッピングされます。
LVM2 では、PV/LV あたりの最大エクステント数に制限はありません。デフォルトのエクステント･サイズは 4MB です。エクステント・サイズの大小による入出力パフォーマンスへの影響は一切ないので、ほとんどの構成ではこのデフォルト･サイズを変更する必要はありません。ただし、エクステント数が多いと LVM ツールを使用しにくくなる場合があるので、エクステント・サイズを大きくしてエクステント数を抑えることが得策となります。ここで注意する点として、単一の VG には異なるエクステント・サイズを混在させられないので、エクステント・サイズの変更は LVM で唯一の安全ではない操作です。エクステント・サイズを変更することによってデータを破壊するおそれもあります。最善の策は、初期セットアップで選択したエクステント・サイズをそのまま維持することです。
エクステント・サイズが異なるということは、VG の粒度が異なることを意味します。例えば、エクステント・サイズを 4GB にした場合、LV は 4GB 単位でしか縮小/拡大できないことになります。
図 4 に、前の例で使用したレイアウトに PE と LE を追加で記載しました (ここには記載していませんが、VG0 内の空きスペースも未使用の LE で構成されています)。
図 4. 物理エクステントと論理エクステントのマッピング
図 4 のエクステント割り当てポリシーにも注目してください。LVM2 では常に PE を連続して割り当てるわけではありません。この詳細については、lvm に関する Linux マニュアル・ページを参照してください (「参考文献」にリンクを記載)。システム管理者は別の割り当てポリシーを設定することもできますが、通常、その必要はありません。デフォルトのポリシー (標準割り当てポリシー) では、例えば同じ物理ボリュームには並行ストライプを配置しないなど、常識的なルールを使用するためです。
図 5 は、2 つ目の LV (LV1) を作成した場合の PE 分布の例です。
図 5. 物理エクステントと論理エクステントのマッピング
デバイス・マッパー
デバイス・マッパー (dm_mod としても知られます) は、カーネル 2.6.9 から組み込まれた Linux カーネル・モジュールです (組み込まれている場合もあります)。デバイス・マッパーの役割はその名のとおりデバイスをマッピングすることで、これは LVM2 に必須です。
主要なディストリビューションのほとんどでは、デフォルトでデバイス・マッパーがインストールされます。通常、デバイス・マッパーはブート時、あるいは LVM2/EVMS パッケージがインストールされたり、有効に設定された時点で自動的にロードされます (EVMS は代替ツールです。詳細は「参考文献」を参照)。ロードされない場合は、dm_mod に対して modprobe を実行した上で (modprobe dm_mod)、ディストリビューションの資料でブート時に有効にする方法を調べてください。
VG と LV を作成する際には、それぞれに意味のある名前を指定できます (これまでの例ではそれとは対照的に、説明のために VG0、LV0、LV1 という名前を使用しました)。これらの名前を物理デバイスに正しくマッピングするのが、デバイス・マッパーの役割です。例えば上記の例の場合、デバイス・マッパーは /dev ファイルシステムに以下のデバイス・ノードを作成することになります。
- /dev/mapper/VG0-LV0
- このノードへのリンクは /dev/VG0/LV0 です。
- /dev/mapper/VG0-LV1
- このノードへのリンクは /dev/VG0/LV1 です。
(名前の標準的なフォーマットは、/dev/{vg_name}/{lv_name} -> /dev/mapper/{vg_name}{lv_name} です)。
物理ディスクとは異なり、ボリューム・グループには直接アクセスできません (つまり、/dev/mapper/VG0 といったファイルは存在しないということです。また、dd if=/dev/VG0 of=dev/VG1 を実行することもできません)。通常は lvm(8) コマンドを使用して操作します。
一般的なタスク
LVM2 を使って実行する一般的なタスクは、システム検証 (LVM2 がインストールされているかどうか)、そしてボリュームの作成、拡張、管理です。
システムで LVM2 を使用するための準備
ディストリビューションの LVM2 パッケージがインストールされているかどうかを確認してください。インストールされていない場合はインストールします (常に元のパッケージを優先させること)。
デバイス・マッパーはシステムの起動時にロードされなければなりません。lsmod | grep dm_mod でロードされるかどうかを調べてください。ロードされない場合、追加のパッケージをインストールして構成しなければならない可能性が考えられます (元の資料に、LVM2 を有効にする方法が記載されています)。
単にテスト (または、システム・レスキューなど) を行うだけの場合は、LVM2 を起動する以下の基本コマンドを実行します。
リスト 1. LVM2 を起動する基本コマンド
#this should load the Device-mapper module
modprobe dm_mod
#this should find all the PVs in your physical disks
pvscan
#this should activate all the Volume Groups
vgchange -ay |
ルート・ファイルシステムを LVM の LV に組み込む予定なら、初期 RAM ディスク・イメージには特に注意が必要です。通常このイメージはディストリビューションによって処理されるため、LVM2 パッケージをインストールするときには適切なカーネル・モジュールと起動スクリプトで initrd イメージがリビルドまたは更新されるはずです。そうとは言え、該当するディストリビューションの資料をよく読んで、LVM2 ルート・ファイルシステムがサポートされていることを確認する必要があります。
初期 RAM ディスク・イメージは、ルート・ファイルシステムが VG に含まれていることを検出した場合にのみ LVM を起動します。その検出方法としては root= カーネル・パラメーターを構文解析するというのが一般的ですが、ルート・ファイルシステム・パスがボリューム・グループに含まれるかどうかを判断する方法はディストリビューションによって異なるため、使用しているディストリビューションの資料で詳細を確認する必要があります。確実でない場合は、initrd または initramdisk の構成を調べてください。
ボリュームの新規作成
お好みのパーティショナー (fdisk、parted、gparted) を使用して、LVM 用の新しいパーティションを作成してください。LVM でサポートされてはいるものの、ディスクをまるごと 1 つの単位として LVM を使用することは推奨されません。そのようなディスクは他のオペレーティング・システムが未初期化ディスクと見なし、消去する可能性があるためです。ディスク全体をカバーするパーティションを作成するようお勧めします。
たいていのパーティショナーは、通常、パーティション ID として 0x83 (Linux のパーティション ID) を使用して新規パーティションを作成するようにデフォルト設定されています。このデフォルト設定をそのまま使っても構いませんが、0x8e (Linux LVM) に変更したほうがより適切な構成が可能になります。
パーティションが作成されると、パーティション表に 1 つ以上の Linux LVM パーティションが表示されます。
root@klausk:/tmp/a# fdisk -l
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 1623 13036716 7 HPFS/NTFS
/dev/hda2 1624 2103 3855600 8e Linux LVM
/dev/hda3 2104 2740 5116702+ 83 Linux
/dev/hda4 3000 9729 54058725 5 Extended
/dev/hda5 9569 9729 1293232+ 82 Linux swap / Solaris
/dev/hda6 3000 4274 10241374+ 83 Linux
/dev/hda7 4275 5549 10241406 83 Linux
/dev/hda8 5550 6824 10241406 83 Linux
/dev/hda9 6825 8099 10241406 83 Linux
/dev/hda10 8100 9568 11799711 8e Linux LVM
Partition table entries are not in disk order
root@klausk:/tmp/a#
|
ここで、pvcreate を実行して各パーティションを初期化します。
リスト 2. パーティションの初期化
root@klausk:/tmp/a# pvcreate /dev/hda2 /dev/hda10
Physical volume "/dev/hda2" successfully created
Physical volume "/dev/hda10" successfully created
root@klausk:/tmp/a#
|
vgcreate を実行すると、PV と VG の両方が作成されます。
リスト 3. PV および VG の作成
root@klausk:~# vgcreate test-volume /dev/hda2 /dev/hda10
Volume group "test-volume" successfully created
root@klausk:~#
|
上記のコマンドは、/dev/hda2 と /dev/hda10 を初期 PV として使用して、test-volume という名前の論理ボリュームを作成します。
VG test-volume の作成後、この新しく作成した VG に関する一般情報を確認するために vgdisplay コマンドを実行します。
リスト 4. 新規 VG に関する一般情報の確認
root@klausk:/dev# vgdisplay -v test-volume
Using volume group(s) on command line
Finding volume group "test-volume"
--- Volume group ---
VG Name test-volume
System ID
Format lvm2
Metadata Areas 2
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 2
Act PV 2
VG Size 14.93 GB
PE Size 4.00 MB
Total PE 3821
Alloc PE / Size 0 / 0
Free PE / Size 3821 / 14.93 GB
VG UUID lk8oco-ndQA-yIMZ-ZWhu-LtYX-T2D7-7sGKaV
--- Physical volumes ---
PV Name /dev/hda2
PV UUID 8LTWlw-p1OJ-dF6w-ZfMI-PCuo-8CiU-CT4Oc6
PV Status allocatable
Total PE / Free PE 941 / 941
PV Name /dev/hda10
PV UUID vC9Lwb-wvgU-UZnF-0YcE-KMBb-rCmU-x1G3hw
PV Status allocatable
Total PE / Free PE 2880 / 2880
root@klausk:/dev#
|
リスト 4 で、この VG には 2 つの PV が割り当てられていて、VG の合計サイズが 14.93GB であること (つまり、それぞれ 4MB の PE が 3,821 あること) を確認します。すべての PE が使用可能であることも忘れずに確認してください。
これでボリューム・グループの準備は整ったので、ボリューム・グループを仮想ディスクのように使用してパーティション (LV) を作成、削除、サイズ変更できるようになります。ただし、ボリューム・グループは LVM ツール・セットだけが認識する抽象エンティティーであることに注意してください。次に、lvcreate を使って新しい論理ボリュームを作成します。
リスト 5. 論理ボリューム (パーティション) の新規作成
root@klausk:/# lvcreate -L 5G -n data test-volume
Logical volume "data" created
root@klausk:/#
|
リスト 5 が作成するのは、data という名前の 5GB の LV です。data が作成されたら、そのデバイス・ノードを確認します。
リスト 6. LV デバイス・ノードの確認
root@klausk:/# ls -l /dev/mapper/test--volume-data
brw-rw---- 1 root disk 253, 4 2006-11-28 17:48 /dev/mapper/test--volume-data
root@klausk:/# ls -l /dev/test-volume/data
lrwxrwxrwx 1 root root 29 2006-11-28 17:48 /dev/test-volume/data ->
/dev/mapper/test--volume-data
root@klausk:/#
|
lvdisplay コマンドで LV プロパティーを調べることもできます。
リスト 7. LV プロパティーの検索
root@klausk:~# lvdisplay /dev/test-volume/data
--- Logical volume ---
LV Name /dev/test-volume/data
VG Name test-volume
LV UUID FZK4le-RzHx-VfLz-tLjK-0xXH-mOML-lfucOH
LV Write Access read/write
LV Status available
# open 0
LV Size 5.00 GB
Current LE 1280
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 253:4
root@klausk:~#
|
お気付きだと思いますが、実際の LV 名/パスは /dev/{VG_name}/{LV_name} (例えば、/dev/test-volume/data) となります。/dev/mapper/{VG_name}-{LV_name} ファイルを使用できるのは、/dev/{VG_name}/{LV_name} リンクのターゲットとしてのみです。大多数の LVM コマンドには、/dev/{vg-name}/{lv-name} のフォーマットで操作のターゲットを指定しなければなりません。
これでついに論理ボリュームの準備ができたので、お好みのファイルシステムでフォーマット設定してから目的のマウント・ポイントにマウントします。
リスト 8. LV のマウント
root@klausk:~# mkfs.reiserfs /dev/test-volume/data
root@klausk:~# mkdir /data
root@klausk:~# mount -t reiserfs /dev/test-volume/data /data/
root@klausk:~# df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test--volume-data
5.0G 33M 5.0G 1% /data
root@klausk:~#
|
fstab(5) ファイルを編集して、ブート時にファイルシステムが自動的にマウントされるようにすることもできます。
リスト 9. LV の自動マウント
#mount Logical Volume 'data' under /data
/dev/test-volume/data /data reiserfs defaults 0 2
|
論理ボリュームは汎用ブロック・デバイスのようなもので、そのままデータベースのパーティションとして使用するだけではなく、あらゆる用途に対応します。事実、LVM スナップショットによって一貫性のあるデータベースのバックアップを行うには、論理ボリュームを使用するのが標準的なベスト・プラクティスです。
ボリュームの拡張
簡単なところから説明すると、ボリューム・グループに十分な空きスペースがある場合には lvextend を使用するだけでボリュームを拡張できます。ボリュームをアンマウントする必要はありませんが、後で論理ボリューム内のファイルシステムも拡張する必要があります (前述したように、この 2 つは別個のものです)。使用しているファイルシステムによっては、オンライン状態のまま (つまり、マウントした状態のまま) 拡張することも可能です。
一方、VG に十分なスペースがない場合は、まず物理ディスクを追加しなければなりません。その方法は以下のとおりです。
- 空いているパーティションを使用して物理ディスクを作成します。LVM パーティション/ディスクを識別しやすくするため、パーティション・タイプは 0x8e (Linux LVM) に変更することをお勧めします。次に、
pvcreate を使用して物理ディスクを初期化します (pvcreate /dev/hda3)。
-
vgextendを使用して既存の VG に物理ディスクを追加します (vgextend test-volume /dev/hda2)。
複数の物理ディスクを同時に作成または追加することもできます。それには以下のコマンドを実行します。
pvcreate /dev/hda2 /dev/hda3 /dev/hda5
vgextend test-volume /dev/hda2 /dev/hda3 /dev/hda5
|
PV を追加して論理ボリュームを拡張するのに十分なスペースが用意できたら、lvextend を使って論理ボリュームを拡張します (lvextend -L 8G /dev/test-volume/data)。このコマンドは、/dev/test-volume/data LV のサイズを 8GB に拡張します。
lvextend にはいくつかの便利なパラメーターがあります。
-
-L +5G を指定すると、LV を 5GB のチャンク (相対サイズ) 単位で拡張することができます。
- 新しい拡張の配置場所を (PV の観点から) 指定するには、使用する PV をコマンドに追加します。
- PE の観点から絶対/相対拡張サイズを指定することもできます。
詳細は、lvextend(8) を参照してください。
LV を拡張したら、ファイルシステムも同じく拡張することを忘れないでください (実際に追加スペースを使用できるようにするため)。ファイルシステムによっては、オンラインで (ファイルシステムをマウントしたまま) 拡張することができます。
リスト 10 は、resize_reiserfs を使用して reiserfs(v3) をサイズ変更する例です。これはマウントされたファイルシステムでも使用することができます (resize_reiserfs /dev/test-volume/data)。
ボリュームの管理
ボリュームを管理するには、LV を縮小する方法、そして PV を削除する方法を知っていなければなりません。
論理ボリュームの縮小方法
LV を縮小するには、LV を拡張する方法と同じく lvreduce コマンドを使用します。この操作は LVM 側からオンライン状態のボリュームに対して常に実行することができます。1 つ注意する点として、大多数のファイルシステムはオンライン・ファイルシステムの縮小をサポートしません。リスト 10 は縮小手順の一例です。
リスト 10. LV の縮小
#unmount LV
umount /path/to/mounted-volume
#shrink filesystem to 4G
resize_reiserfs -s 4G /dev/test-volume/data
#reduce LV
lvreduce -L 4G /dev/test-volume/data
|
サイズと単位に注意してください。ファイルシステムを LV より大きくすることはできません。
物理ボリュームの削除方法
例えば、ボリューム・グループを構成する 2 基の 80GB のディスクを 160GB のディスクにアップグレードするとします。LVM では PV を VG に追加した方法と同じように (つまり、オンライン状態で) PV を削除できますが、LV で使用中の PV については削除できません。そのような場合に使用できるのが、pvmove という優れたユーティリティーです。このユーティリティーはオンライン状態の PV を解放して、PV を簡単に交換できるようにします。ホット・スワップ環境であれば、ダウン時間をまったく発生させることなく、すべてのディスクを交換することさえ可能です。
pvmove で唯一の要件となるのは、VG 内で連続する未使用のエクステントの数が PV から削除するエクステントの数と同じであることです。連続する未使用の PE の最大数を直接判断する簡単な方法はありませんが、pvdisplay -m を使用すれば PV 割り当てマップを表示することができます。
リスト 11. PV 割り当てマップの表示
#shows the allocation map
pvdisplay -m
--- Physical volume ---
PV Name /dev/hda6
VG Name test-volume
PV Size 4.91 GB / not usable 1.34 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 1200
Free PE 0
Allocated PE 1200
PV UUID BA99ay-tOcn-Atmd-LTCZ-2KQr-b4Z0-CJ0FjO
--- Physical Segments ---
Physical extent 0 to 2367:
Logical volume /dev/test-volume/data
Logical extents 5692 to 8059
Physical extent 2368 to 2499:
Logical volume /dev/test-volume/data
Logical extents 5560 to 5691
--- Physical volume ---
PV Name /dev/hda7
VG Name test-volume
PV Size 9.77 GB / not usable 1.37 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 2500
Free PE 1220
Allocated PE 1280
PV UUID Es9jwb-IjiL-jtd5-TgBx-XSxK-Xshj-Wxnjni
--- Physical Segments ---
Physical extent 0 to 1279:
Logical volume /dev/test-volume/LV0
Logical extents 0 to 1279
Physical extent 1280 to 2499:
FREE
|
リスト 11 では、有効な隣接する未使用のエクステントの数は 2,499-1,280 = 1,219 となります。つまり、最大 1,219 のエクステントを別の PV から /dev/hda7 に移せるということです。
交換するために PV を解放するのであれば、PV の割り当てを無効にして、ボリューム・グループから削除するまで確実に PV を未使用の状態に維持するのが得策です。それにはデータを移動させる前に、以下のコマンドを実行します。
リスト 12. 解放に備えた PV 割り当ての無効化
#Disable /dev/hda6 allocation
pvchange -xn /dev/hda6
|
解放した PV /dev/hda6 で、エクステント数が 1,200 であること、そして未使用のエクステントがないことを確認してください。この PV からデータを移動させるには、以下のコマンドを実行します。
リスト 13. 解放された PV からのデータの移動
#Move allocated extents out of /dev/hda6
pvmove -i 10 /dev/hda6
|
リスト 13 の -i 10 パラメーターは、pvmove に 10 秒間隔でステータスをレポートするよう指示するものです。移動するデータの大きさによっては、この操作に数分 (あるいは数時間) かかることもあります。そこで、-b パラメーターを指定してこの操作をバックグラウンドで行うという手段もあります。この場合、ステータスは syslog にレポートされます。
連続する未使用のエクステント数が pvmove 操作で使用するには足りないという場合は、いつでも VG に 1 つ以上のディスク/パーティションを追加して pvmove に使用可能な連続するスペースを増やすことができます。
その他の便利な LVM 操作
他にも以下の便利な LVM 操作があります。それぞれの詳細については、マニュアル・ページを参照してください。
-
pvresize は、基本となるパーティションが拡張された場合に PV を拡張します。割り当てマップで許容される場合には PV を縮小します。
-
pvremove は、PV を破棄します (PV のメタデータを消去します)。このコマンドは、vgreduce によって VG から PV が削除された後にだけ使用してください。
-
vgreduce は、未割り当ての PV をボリューム・グループから削除して VG を縮小します。
-
vgmerge は、2 つの異なる VG を 1 つに統合します。オンライン状態の VG をターゲットにできます。
-
vgsplit は、ボリューム・グループを分割します。
-
vgchange は、VG の属性およびアクセス権を変更します。
-
lvchange は、LV の属性およびアクセス権を変更します。
-
lvconvert は、線形ボリュームからミラーまたはスナップショットへの変換、あるいはその逆の変換を行います。
スナップショットによるバックアップの作成
一貫性のあるバックアップを作成するには、バックアップ・プロセスが開始してから終了するまでの間、データが変更されないことが要件となりますが、コピー・プロセスに必要な時間だけシステムを停止しなければ、この要件を保証するのは困難です。
Linux LVM は、スナップショットという機能を実装します。これはその名のとおり、特定の時点で論理ボリュームのいわば写真を撮る機能です。スナップショットでは、同じ LV の 2 つのコピーが提供されます。一方のコピーはバックアップ用として使用することが可能で、もう一方はそのまま動作に使用されます。
スナップショットには、以下の 2 つの大きな利点があります。
- スナップショットは瞬時に作成されるため、実動環境を停止しなくても済みます。
- コピーは 2 つ作成されますが、サイズが 2 倍になることはありません。スナップショットは、2 つの LV 間の違いを収容するのに必要なスペースしか使用しないからです。
上記の利点をもたらすのは、例外リストです。このリストは LV 間で何らかの変更が発生するたびに更新されます (以前は CoW (Copy-on-Write) として知られていました)。
スナップショットの新規作成
新しいスナップショット LV を作成するには、論理ボリュームを作成するときと同じ lvcreate コマンドに、-s パラメーターと元の LV を指定します。この場合の -L size は、例外テーブルのサイズを指定します。これはスナップショットがサポートする LV 間の差異の量で、このサイズを超えると一貫性が失われます。
リスト 14. 最初のスナップショットの取得
#create a Snapshot LV called 'snap' from origin LV 'test'
lvcreate -s -L 2G -n snap /dev/test-volume/test
|
lvdisplay を使用して、CoW サイズや CoW 使用量などの特殊な情報を照会します。
リスト 15. CoW の合計サイズおよび使用量の照会
lvdisplay /dev/vg00/snap
--- Logical volume ---
LV Name /dev/test-volume/snap
VG Name vg00
LV UUID QHVJYh-PR3s-A4SG-s4Aa-MyWN-Ra7a-HL47KL
LV Write Access read/write
LV snapshot status active destination for /dev/test-volume/test
LV Status available
# open 0
LV Size 4.00 GB
Current LE 1024
COW-table size 2.00 GB
COW-table LE 512
Allocated to snapshot 54.16%
Snapshot chunk size 8.00 KB
Segments 1
Allocation inherit
Read ahead sectors 0
Block device 254:5
|
リスト 15 から、CoW のサイズは 2GB で、その 54.16 % が使用されていることがわかります。
あらゆる点から見て、このスナップショットは元の LV そのままです。ファイルシステムがあれば、以下のコマンドでマウントできます。
#mount snapshot volume
mount -o ro /dev/test-volume/snap /mnt/snap
|
上記のコード・スニペットでのマウントで使用されている ro フラグは、read-only (読み取り専用) のことです。LVM レベルで読み取り専用にするには、lvcreate コマンドに -p r を追加してください。
ファイルシステムがマウントされたら、tar、rsync など任意のバックアップ・ツールを使ってバックアップを開始できます。LV にファイルシステムが含まれていない場合、あるいは直接バックアップしたほうがよい場合には、デバイス・ノードに直接 dd をディレクトリーを使うことも可能です。
コピー・プロセスが完了してスナップショットが必要なくなったら、単純に lvremove でアンマウントして破棄します。
#remove snapshot
lvremove /dev/test-volume/snap
|
LV をベースとするデータベースでバックアップの一貫性を実現するためには、テーブルをフラッシュしてスナップショット・ボリュームを作成すると同時に読み取りロックを取得することを忘れないでください (以下のサンプル擬似コードを参照)。
SQL> flush tables read lock
{create Snapshot}
SQL> release read lock
{start copy process from the snapshot LV}
|
バックアップ・スクリプトの例
リスト 16 のスクリプトは私のラップトップからそのまま引用したものです。このラップトップでは毎日、rsync を使ってリモート・サーバーにバックアップを取っています。このスクリプトはエンタープライズ・ユースを意図したものではありません。エンタープライズ・ユースの場合は、履歴を付けた増分バックアップのほうが適していますが、考え方は何ら変わりありません。
リスト 16. 単純なバックアップ・スクリプトの例
#!/bin/sh
# we need the dm-snapshot module
modprobe dm-snapshot
if [ -e /dev/test-volume/home-snap ]
then
# remove left-overs, if any
umount -f /mnt/home-snap && true
lvremove -f /dev/test-volume/home-snap
fi
# create snapshot, 1GB CoW space
# that should be sufficient for accommodating changes during copy
lvcreate -vs -p r -n home-snap -L 1G /dev/test-volume/home
mkdir -p /mnt/home-snap
# mount recently-created snapshot as read-only
mount -o ro /dev/test-volume/home-snap /mnt/home-snap
# magical rsync command
rsync -avhzPCi --delete -e "ssh -i /home/klausk/.ssh/id_rsa" \
--filter '- .Trash/' --filter '- *~' \
--filter '- .local/share/Trash/' \
--filter '- *.mp3' --filter '- *Cache*' --filter '- *cache*' \
/mnt/home-snap/klausk backuphost.domain.net:backupdir/
# unmount and scrap snapshot LV
umount /mnt/home-snap
lvremove -f /dev/test-volume/home-snap
|
サイクルを推定できなかったり、あるいはプロセス時間が長いなどといった特殊な場合には、lvdisplay でスナップショットの CoW 使用量を照会し、必要に応じて LV を拡張するというスクリプトも考えられます。また極端な場合、スナップショットを元の LV と同じサイズにすることも一考です。このようにすれば、変更の量がボリューム全体のサイズより大きくなることはありません。
その他の LVM2 の sysadmin の技
記事の締めくくりとして、LVM2 で実行できる見事な sysadmin の技をいくつか紹介します。具体的には、オンデマンド仮想化、ミラーリングによる耐障害性の改善、そしてブロック・デバイスの透過的暗号化です。
スナップショットと仮想化
LVM2 では、スナップショットは読み取り専用に制限されてはいません。つまり、スナップショットを作成した後で、通常のブロック・デバイスと同じようにスナップショットのマウントや読み取り、書き込みを行うことができます。
Xen、VMWare、Qemu、KVM など、よく使われる仮想化システムではブロック・デバイスをゲスト・イメージとして使用できるため、ブロック・デバイスのイメージの完全なコピーを作成して、フィンガープリントの小さいオンデマンド仮想マシンのように使用することができます。このような仮想マシンには、デプロイメントがすぐに完了し (スナップショットは通常、数秒で作成できるため)、スペースを節約できる (ゲストはデータの大部分と元のイメージと共有するため) という利点もあります。
そのための一般的なガイドラインには、以下の手順も含まれます。
- 元のイメージに対する論理ボリュームを作成します。
- LV をディスク･イメージとして使用して、ゲスト仮想マシンをインストールします。
- 仮想マシンをサスペンドまたはフリーズさせます。メモリー・イメージは、その他すべてのスナップショットが常駐する通常ファイルにすることができます。
- 元の LV の読み取り-書き込みスナップショットを作成します。
- スナップショット・ボリュームをディスク･イメージとして使用して、新規仮想マシンを作成します。必要に応じて、ネットワーク/コンソールの設定を変更します。
- 作成した仮想マシンにログオンし、ネットワーク設定/ホスト名を変更します。
上記の手順を完了したら、新しく作成された仮想マシンへのアクセス情報をユーザーに提供します。別の仮想マシンが必要な場合は、手順 4 から 6 を繰り返してください (マシンを再インストールする必要はないということです)。あるいは、この手順をスクリプトで自動化するという方法もあります。
仮想マシンを使用し終えたら、仮想マシンを停止してスナップショットを破棄しても構いません。
耐障害性の改善
最近の LVM2 開発では、論理ボリュームに複数のミラーを持たせ、それぞれのミラーを異なる物理ボリューム (異なるデバイス) に配置することによって高可用性機能を実現できるようになっています。デバイスで入出力エラーが検出された場合、dmeventd を使用すればサービスに影響を与えずに PV をオフラインに切り替えられます。詳細は、lvcreate(8)、lvconvert(8)、および lvchange(8) マニュアル・ページを参照してください。
ハードウェアがサポートするのであれば、dm_multipath を使用して複数のチャネルで単一のデバイスにアクセスし、チャネルがダウンした場合にフェイル･オーバーできるようにすることも可能です。dm_multipath および multipathd の資料に詳細が記載されています。
デバイスの透過的暗号化
dm_crypt ではブロック・デバイスや論理ボリュームを透過的に暗号化することができます。dm_crypt の資料および cryptsetup(8) マニュアル・ページで詳細を確認してください。
参考文献 学ぶために
製品や技術を入手するために
-
SEK for Linux を注文してください。この 2 枚組 DVD セットには、Linux 対応の DB2®、Lotus®、Rational®、Tivoli®、そして WebSphere® の最新 IBM トライアル・ソフトウェアが収録されています。
- developerWorks から直接ダウンロードできる IBM トライアル・ソフトウェアを使用して、Linux で次の開発プロジェクトを構築してください。
議論するために
著者について  | 
| | Klaus Heinrich Kiwi は Unicamp をコンピューター・エンジニアリングの学位で卒業した 2004年以来、UNIX 環境でのシステム開発とネットワーク管理のデプロイメントに取り組んでいます。IBM に入社したのは 2006 年で、現在は Linux Technology Center の Security Development Team でソフトウェア・エンジニアとして活躍しています。 |
記事の評価
|