共通テーマ: Linux LVMについて学ぶ: 第2回

cvs.gentoo.orgのアップグレード

Comments

Linux LVMについて学ぶ、第1回 では、LVMを実現する基盤となっている概念を説明しました。さあ今回は、LVMを実際に使ってみましょう。今回の記事では、正式なGentoo Linux web/cvs/emailサーバー cvs.gentoo.org にLVMをセットアップしてみます。cvs.gentoo.orgにはハード・ディスクが1つしかありませんが、LVMを用いることにより、標準の静的区画アプローチに、信じられないほどの柔軟性が付け加えられます。LVM移行プロセスのすべてのステップを紹介しますので、興味をお持ちの場合は、ぜひご自分のマシンで同様の移行を実行してください。

始める前に、注意を1つ申し上げます。LVMの実装は、システム上の大きな変更ですので(新しい区画の作成や他の障害を引き起こす可能性があるアクションを行いますので)、このプロセスを開始する前に、システムの完全なバックアップを実行しておくことを強く お勧めします。バックアップを実行しない場合は、重要なデータが入っていないテスト・マシンを使用ください。LVMへの移行中に問題を経験したことはありませんが、万一に備えて準備しておくことをぜひお勧めします。

それでは、続けましょう。移行プロセスを開始する前に、以下のパッケージを使用するようにcvs.gentoo.orgをアップグレードしました。わたしがLVM移行を実行した時点では、これらが利用可能な最新バージョンでした (今回の記事最後の 参考文献 を参照してください)。

  • Linuxカーネル2.4.1-ac19
  • LVM 0.9.1_beta5
  • reiserfs-utils 3.6.25

次は、ハード・ディスクです。cvs.gentoo.orgには、新品のIBM 45 GBハード・ディスクが装備されていました。cvsにGentoo Linuxをインストールしたときは、約10ギガバイトのディスクしか区画化せず、残りの35 GBは「将来の区画」用に残しておきました。LVMを使用しない場合は、このようなちょっとした工夫が必要です。ドライブの一部を区画化しないでおくことは原始的な方法ですが、将来の拡張に備えた効果的な方法でもあります。ただし、LVMに移行すれば、もっと上手い方法もあります。

スペースの問題

この "df" 出力を見ても分かるように、ここ数週間、わたしはルートのReiserFS区画へのデータ格納が遅いことに気付いていました。

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda3              9765200   6989312   2775888  72% /
tmpfs                   269052         0    269052   0% /dev/shm

ルート区画の72%が使用済みであることは、危機的状況というわけではありませんが、申し分のない状況でもありません。ReiserFSは、他の多くのファイル・システムと同様に、フリー・スペースが少なくなるにつれて速度が遅くなるので、わたしのルート・ファイル・システム内にフリー・スペースがまったくなくなり、ファイル・システムのパフォーマンスが危機に陥るのはまさに時間の問題でした。

そこで、LVMを使用して、ハード・ディスクの最後にある、まだ区画化されていない 35 GBのスペースから新しい論理ボリュームを作成することで、この問題を解決することにしました。そして、このボリューム上にファイル・システムを作成し、/dev/hda3の内容の大半をそこに移動することにしました。

同じような移行を行うことを考えている場合、まず最初に行わなければならないことは、論理ボリュームに移動するルート・ファイル・システムの適切な部分を探し出すことです。わたしの場合、この選択は簡単でした。/homeツリーは約5.7 GBを占有していました。/homeを独自のLVM論理ボリュームに移動することで、わたしのルート・ファイル・システムの容量は約20 %になります。新しいデータの大半は /homeに追加されるので、ルート・ファイル・システムの使用量も約20%になり、非常に健全な状況です。

解決に向けて

移行を始めるには、まずハード・ディスクの最後の部分にある未使用のスペースを区画化しなければなりませんでした。cfdiskを使用して、35 GBの区画 (/dev/hda5) を作成し、この区画の区画タイプを "8E" (正式なLVM区画タイプ) に設定しました。この変更後、リブートして区画テーブルを強制的に再読み取りしました。リブート後、区画テーブルは以下のようになりました。

# sfdisk -l
Disk /dev/hda: 89355 cylinders, 16 heads, 63 sectors/track
Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0
   Device Boot Start     End   #cyls   #blocks   Id  System
/dev/hda1   *      0+    247     248-   124960+  83  Linux
/dev/hda2        248     743     496    249984   82  Linux swap
/dev/hda3        744   20119   19376   9765504   83  Linux
/dev/hda4      20120   89354   69235  34894440    5  Extended
/dev/hda5      20120+  89354   69235- 34894408+  8e  Linux LVM

これで、空の35 GBの区画を用意でき、LVMに備えて初期設定する準備が整いました。では、手順を紹介しましょう。まず、35ギガバイトを物理 ボリュームとして初期設定します。次に、この物理ボリュームを使用してボリューム・グループ を作成します。最後に、ボリューム・グループ上のエクステントの一部を割り振り、新しいファイル・システムを入れる論理ボリューム を作成し、現在 /homeに格納されているすべてのファイルを収容します。

プロセスを開始するため、pvcreateコマンドを使用して /dev/hda5を物理ボリュームとして初期設定しました。

# pvcreate /dev/hda5
pvcreate -- physical volume "/dev/hda5" successfully created

pvcreateは、/dev/hda5上にVGDA (volume group descriptor area) という特殊な「アカウンティング」領域を設定します。LVMは、特に、この領域を使用して、物理エクステントがどのように割り振られているかを追跡します。

次のステップは、ボリューム・グループを作成し、このグループに /dev/hda5を追加することでした。ボリューム・グループは、エクステントのプール (ストレージ・ブロックの塊) の役割を果たします。ボリューム・グループが作成されれば、必要なだけ多くの論理ボリュームを作成することができます。わたしのボリューム・グループの名前は "main" にしました。

# vgcreate main /dev/hda5
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "main"
vgcreate -- volume group "main" successfully created and activated

vgcreateコマンドはいくつかのことを実行しました。"main" ボリューム・グループを作成しただけでなく、4 MBエクステント (デフォルトのエクステント・サイズ) を使用するように /dev/hda5を設定しました。つまり、このボリューム・グループから作成する論理ボリュームはすべて4 MB単位で拡張および縮小できます。

カーネルの制限により、エクステント・サイズから、論理ボリュームに有効な最大サイズが決まります。前述の出力からお分かりのように、4 MBのエクステント・サイズにより、256ギガバイトの論理ボリューム・サイズ制限が課せられます。つまり、ボリューム・グループに高容量ディスクを追加する場合には簡単に到達する論理ボリューム・サイズです。ボリュームが最終的に256 GBより大きくなった場合は、vgcreateの実行時により大きいエクステント・サイズを指定することをお勧めします。エクステントの範囲は8 KB?512 MBまで可能ですが、必ず2の倍数でなければなりません。エクステント・サイズを4 MBより大きくすることにより、最大物理ボリュームのサイズはそれに従って最大1ペタバイトまで拡大されます (ただし、x86システムにおける現在のサイズ限度は2テラバイトです)。たとえば、エクステントが32メガバイトのボリューム・グループを作成したい場合は、以下のように入力します。

# vgcreate -s 32M main /dev/hda5

32 MBは管理可能な単位であり、最大論理ボリューム・サイズを2テラバイトに拡張するので、32 MBは適正なエクステント・サイズです。ボリューム・グループを作成したら、"vgdisplay" と入力することでその情報を表示することができます。

# vgdisplay
--- Volume group ---
VG Name               main
VG Access             read/write
VG Status             available/resizable
VG #                  0
MAX LV                256
Cur LV                0
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                1
Act PV                1
VG Size               33.28 GB
PE Size               4 MB
Total PE              8519
Alloc PE / Size       0 / 0
Free  PE / Size       8519 / 33.28 GB
VG UUID               2qC2H2-iA8s-qW6F-cwXx-JVIh-I6VC-VVCGmn

これで、ボリューム・グループができあがり、論理ボリュームを作成する準備が整いました。最初は論理ボリュームのサイズを8ギガバイトにし、"lv_home" という名前にしました。

# lvcreate -L8G -nlv_home main
lvcreate -- doing automatic backup of "main"
lvcreate -- logical volume "/dev/main/lv_home" successfully created

次に、ボリューム上にファイル・システムを作成しました。

# mkreiserfs /dev/main/lv_home
 
  <----------- MKREISERFSv2 ----------->
   Block size 4096 bytes
   Block count 2097152
   Used blocks 8275
          Journal - 8192 blocks (18-8209), journal header is in block 8210
		                  Bitmaps: 17, 32768, 65536, 98304, 131072, 163840,
		                  196608, 229376, 262144, 294912, 327680, 360448,
		                  393216, 425984, 458752, 491520, 524288, 557056,
		                  589824, 622592, 655360, 688128, 720896, 753664,
		                  786432, 819200, 851968, 884736, 917504, 950272,
		                  983040, 1015808, 1048576, 1081344, 1114112,
		                  1146880, 1179648, 1212416, 1245184, 1277952,
		                  1310720, 1343488, 1376256, 1409024, 1441792,
		                  1474560, 1507328, 1540096, 1572864, 1605632,
		                  1638400, 1671168, 1703936, 1736704, 1769472,
		                  1802240, 1835008, 1867776, 1900544, 1933312,
		                  1966080, 1998848, 2031616, 2064384
	         Root block 8211
Hash function "r5"
ATTENTION: ALL DATA WILL BE LOST ON '/dev/main/lv_home'! (y/n)y
journal size 8192 (from 18)
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..done.

これで、ファイル・システムが作成されたので、/mnt/newhomeにマウントすることができました。

# mkdir /mnt/newhome
# mount /dev/main/lv_home /mnt/newhome
# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda3              9765200   6989840   2775360  72% /
tmpfs                   291388         0    291388   0% /dev/shm
/dev/main/lv_home      8388348     32840   8355508   1% /mnt/newhome

お分かりのように、これですべてのデータを /homeにコピーする準備がほぼ整いました。始める前に、実行レベル1に落とし、コピー中にユーザーまたはプロセスが /home 内のファイルにアクセスしたり変更したりできないようにしました。

# init 1

次に、ファイルのコピーを開始しました。

# cp -avx /home/* /mnt/newhome

コピーが完了するまで約10分かかりました。次に、コピー中に問題が発生した場合に備えて、オリジナルの /homeのバックアップを /home.oldに取りました。新しいマウント・ポイントを作成し、新しいホームを /homeに再マウントしました。

# cd /
# mv home home.old
# mkdir home
# umount /mnt/newhome
# mount
/dev/main/lv_home /home

次は、マシンを起動するたびに新しい /home区画を利用できるようにサーバーを設定する時間です。まず、新しい /homeエントリーを取り込むように /etc/fstabを変更しました。

# /etc/fstab: static file system information.
#
# fs          	        mountpoint       type         opts          dump/pass
/dev/hda3           /               reiserfs     defaults      1 1
/dev/main/lv_home  /home            reiserfs     defaults      2 2
/dev/hda2          none             swap         sw            0 0
/dev/hda1          /boot            reiserfs     noauto        0 0
/dev/cdrom         /mnt/cdrom       iso9660      noauto,ro     0 0
proc                /proc            proc        defaults      0 0
none                /dev/pts         devpts      mode=620      0 0
tmpfs               /dev/shm         tmpfs       defaults      0 0

次に、初期設定スクリプトに小さい変更を加えました。ルート区画の再マウント直後に以下のコマンドが実行されるように、"checkroot" 始動スクリプトを変更しました。

/sbin/vgscan
/sbin/vgchange -a y

次に、すべてのファイル・システムをアンマウントした後 すぐに以下のコマンドが実行されるように、シャットダウン時に実行するファイル・システム・アンマウント・スクリプトを変更しました。

/sbin/vgchange -a n

これらのステップを実行し終えた後、マシンをリブートしました。うれしいことに、すべて問題なく動作しました。数日たってもまったく問題が発生しなかったので、/home.oldを削除して、ルート・ファイル・システムのスペースを解放しました。できました!LVMへの移行は成功しました。

LVMの利点

LVMへの移行は大変な作業ですが、移行が完了すれば、ファイル・システムの管理は驚くほど楽になります。たとえば、わたしは新しい /home論理ボリュームのサイズを変更し、ファイル・システムの最後に約2ギガバイトの有効なスペースを追加しました。まず、追加容量を "lv_home" 論理ボリュームに追加してから、resize_reiserfsユーティリティーを使用して、この追加容量を使用するようにファイル・システムを拡張しました。以下に、これを実行した2つのコマンドを示します。

# lvextend -L+2G /dev/main/lv_home
# resize_reiserfs -f /dev/main/lv_home

/homeファイル・システムはすぐに2GB増加しました。驚くことに、サイズ変更のためにリブートしたり、実行レベル1に落としたり、/homeをアンマウントしたりする必要はありませんでした。すべて、変更前と同じように作業し続けました。すばらしいではありませんか。以下に、わたしのファイル・システムの現在の状態を示します。

# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda3              9765200   1413340   8351860  15% /
/dev/main/lv_home     10485436   5609836   4875600  54% /home

LVMが本当に管理者の仕事を楽にしてくれることをお分かりいただけたことと思います。今後は、LVMにルート・ファイル・システムの追加部分を移動し、徐々にルート・ファイル・システムをLVM論理ボリュームに移行したいと考えています。LVMの詳細については、以下の参考文献を参照してください。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=262594
ArticleTitle=共通テーマ: Linux LVMについて学ぶ: 第2回
publish-date=04012001