|
1: 2009-08-19 (水) 00:33:50 maruo  |
| | + | [[Gentoo Linuxな生活/システム管理関連]] |
| | | | |
| | + | *LVMとは？ [#m16f211c] |
| | + | ここを参照。 |
| | + | -[[GentooLVM2インストール:http://www.gentoo.org/doc/ja/lvm2.xml]] |
| | + | -[[Logical Volume Manager HOWTO:http://www.linux.or.jp/JF/JFdocs/LVM-HOWTO.html]] |
| | + | |
| | + | Logical Volume Managerのことです。これを行うと何が良いかというと、例えば皆さんもPCを長く使っているとこんなことがあるかと思います。 |
| | + | -古い中途半端な容量のHDがあったとします。どうにも使い回しが効かないから捨ててしまおうか、とか。でもLVMを使用すると、こういったHDをまとめてしまって、仮想的に1つのHDとして使用することができます。つまり/dev/hdb1 40Gと/dev/hdc1 40Gを合わせて/dev/lvm/dataとして75Gくらいの1ボリュームとして使用する、とか。 |
| | + | -100GbyteのHDを買ってきて、50、50で分けて使っていたら、かたっぽのパーティションが一杯になった。もう一方はまだ余ってるのに…かたっぽのパーティションを大きくできたらなー、とHDからデータを吸い出して、フォーマットして、また入れなおす、とか。これがLVMだとデータを削除しないで動的に増減できたりします。 |
| | + | -HDを使ってたら、HDの寿命がきた。交換しないといけないけど、データの退避がでかいデータ領域だと超大変。というときも、2つや3つのHDを1グループで使用していた場合は、データ構造を変えることなく、交換したいHD以外のHDに退避して、ディスクの交換作業ができたりする。 |
| | + | |
| | + | (」゜ロ゜)」(」゜ロ゜)」(」゜ロ゜)」オオオオオッッッ、これは便利！但し一つ問題が。HDに直接アクセスするのではなく、LVMというソフトウェアのオブラートを物理HDにかまし、上位アプリケーションはこいつにアクセスします。HDへの書き込みは、LVMが勝手にグループに属しているHDに分散書き込みします。なので、ディスクアクセス時のCPUオーバーヘッドが増えます。ですが/var、/home、データ置き場等、これだけあれば十分、という容量がはっきり分からないパーティションをきる場合は非常に有利といえますね。 |
| | + | |
| | + | *では導入手順 [#s065ddf1] |
| | + | おいちゃんところでは、LVMを最初は使用しない状態でスタートしましたので、LVM化する場合は、結局LVMを使わない場合と同じ事をする羽目になります。ですがこれは最初だけ。以下の方針を立てました。 |
| | + | :基本方針|現在120G、140Gの2つの領域がある。これをLVMで統合して250Gbyte相当のHDを作る |
| | + | +まずは120Gに入っているソフトデータ等を玄箱に退避 |
| | + | +１２０GのHDをLVM化して、/var（２０G)、/share(95G)に分ける |
| | + | +140Gの領域にある/var、/share、の内容をLVMの/var、/shareに移動して、実運用システムにマウント。しばらく様子を見る |
| | + | +データ整合性などに問題なしとなったら、140GをLVM化し、グループ統合する |
| | + | +/shareにこの１４０Gを追加して、２００G程度のデータ領域を作る |
| | + | +玄箱に退避したデータを/shareに戻す |
| | + | |
| | + | 多分これで大丈夫、なはず。ここで領域を若干残してあるのは、snapshotバックアップ領域を作っておくため。snapshotとは、データの書き換えとかが行われている運用中のディスクドライブのある瞬間の状態を保存する機能です。例えばバックアップ中にアプリによる書き換えが発生した場合、バックアップ開始時にバックアップされたデータが、バックアップ終了間際に書き換えられて、不整合が発生したりする可能性があります。本来は一旦アプリサービスを停止して書き換えを抑止した状態でバックアップを撮るのがいいのですが、サーバが停止するためそれもいや。そこでサービスを運用していながらディスクのsnapshotが取れる機能が生きてくるわけですね♪しかもこのsnapshot用に撮っておく領域は、実領域の1/10以下でいいときてるのでとても柔軟性があります。 |
| | + | |
| | + | と、言うわけで、基本的なLVMの使い方をやってみましょう。 |
| | + | **カーネルをLVM対応にする [#y3649ae1] |
| | + | カーネルのコンパイルオプションを確認してください。おいちゃんの所は2.6．ですので一般的にLVM2と言われる形式に合わせます。 |
| | + | Device Drivers ---> |
| | + | Multi-device support (RAID and LVM) ---> |
| | + | [*] Multiple devices driver support (RAID and LVM) |
| | + | < > RAID support |
| | + | <M> Device mapper support |
| | + | このDevice Mapper supportをON、もしくはモジュール化してやります。~ |
| | + | ここで、''カーネル2.6を利用して、udev化している''のであれば、/etc/udev/rules.d/50-udev.rulesを開いて、 |
| | + | KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c" |
| | + | |
| | + | のコメントをはずしてやります。でないと、リブートしたらLVMボリュームが消去されちゃうんだって。気をつけてね！ |
| | + | |
| | + | |
| | + | **LVM2パッケージ導入 [#hc2b28d4] |
| | + | # emerge lvm2 |
| | + | 終ったら |
| | + | # echo 'devices { filter=["r/cdrom/"] }' >/etc/lvm/lvm.conf |
| | + | |
| | + | CD-ROMドライブをLVMの検索対象からはずすってことね。起動時にLVM化されたドライブを検索するの。CD-ROMとかは絶対ありえないからはずしておくと良い。 |
| | + | |
| | + | # vgscan |
| | + | Reading all physical volumes. This may take a while... |
| | + | No volume groups found |
| | + | # vgchange -a y |
| | + | |
| | + | **パーティションタイプの変更 [#tde48cd7] |
| | + | まずはLVMにしたいディスクのパーティションタイプをfdiskで変更します |
| | + | #fdisk /dev/hdb |
| | + | |
| | + | このディスクのシリンダ数は 15017 に設定されています。 |
| | + | 間違いではないのですが、1024 を超えているため、以下の場合 |
| | + | に問題を生じうる事を確認しましょう: |
| | + | 1) ブート時に実行するソフトウェア (例. バージョンが古い LILO) |
| | + | 2) 別の OS のブートやパーティション作成ソフト |
| | + | (例. DOS FDISK, OS/2 FDISK) |
| | + | |
| | + | コマンド (m でヘルプ): p |
| | + | |
| | + | Disk /dev/hdb: 123.5 GB, 123522416640 bytes |
| | + | 255 heads, 63 sectors/track, 15017 cylinders |
| | + | Units = シリンダ数 of 16065 * 512 = 8225280 bytes |
| | + | |
| | + | デバイス Boot Start End Blocks Id System |
| | + | /dev/hdb1 1 15017 120624021 83 Linux |
| | + | |
| | + | Idが83ですよね。SystemがLinuxです。このhdb1を変更します。 |
| | + | |
| | + | コマンド (m でヘルプ): t |
| | + | Selected partition 1 |
| | + | 16進数コード (L コマンドでコードリスト表示): 8e |
| | + | |
| | + | コマンド (m でヘルプ): p |
| | + | |
| | + | Disk /dev/hdb: 123.5 GB, 123522416640 bytes |
| | + | 255 heads, 63 sectors/track, 15017 cylinders |
| | + | Units = シリンダ数 of 16065 * 512 = 8225280 bytes |
| | + | |
| | + | デバイス Boot Start End Blocks Id System |
| | + | /dev/hdb1 1 15017 120624021 8e Linux LVM |
| | + | 分かりますか?SystemがLinux LVMに変更されましたよね。 |
| | + | **物理HDをLVMに加える [#i18af3b4] |
| | + | pvcreateコマンドを使用して、物理HDをLVMのphysical volumeに加えます。 |
| | + | # pvcreate /dev/hdb1 |
| | + | No physical volume label read from /dev/hdb1 |
| | + | Physical volume "/dev/hdb1" successfully created |
| | + | **ボリュームグループを作成する [#e28c4ad5] |
| | + | 普通のHDで言うところのHD1ドライブに相当するボリュームグループってのを作ります。 |
| | + | # vgcreate -s 32M lvm /dev/hdb1 |
| | + | Volume group "lvm" successfully created |
| | + | |
| | + | ここでは、lvmというボリュームグループに先ほど作った/dev/hdb1を加えています。-s 32Mってのは何かというと、PhysicalExtentという、普通のHDで言うところのクラスタみたいなものを32Mbyteにする、という指定です。省略すると4Mbyteが指定されます。ディスク容量の増減が４Mbyte単位で行われるということ。但し、これが曲者。''４Mbyteの場合だと、この64000倍である256Gbyteのボリュームグループまでしか作れません。''なので32Mbyteに拡張してるのですね。すると、''32×64000=２Tbyte''までのボリュームグループが作れるというわけ。但し増減は32Mbyte単位です。 |
| | + | |
| | + | **ロジカルボリュームを作る [#b26ce0ad] |
| | + | ロジカルボリュームとは、普通のHDで言うところのパーティションを切る作業です。 |
| | + | |
| | + | # lvcreate -L20G -nvar lvm |
| | + | # lvcreate -L95G -nshare lvm |
| | + | |
| | + | これで先ほどのvar(20G)とshare(95G)ができたわけですね。あとは、/dev/lvm/var,/dev/lvm/shareで普通のディスクと同様にアクセスできます。~ |
| | + | /dev/ボリュームグループ/ロジカルボリューム~ |
| | + | がデバイス名ですね。 |
| | + | **フォーマットしてやる。 [#jb0cf5f5] |
| | + | あとは普通のディスクと同様に、初期化してやります。おいちゃんはReiserFS好きなので |
| | + | # mkreiserfs /dev/lvm/var |
| | + | とかやってフォーマットしてやります。ext2でもext3でもXFSでも好きにして。 |
| | + | これをfstabに書いてやったり、mountで指定したりするわけです。 |
| | + | |
| | + | **ディスクの追加 [#kf4ba0f7] |
| | + | さて、どーするかというと以下の手順。安全のため、一応/dev/lvm/shareのマウントははずしておいたほうが良いとは思います。 |
| | + | ここでは、/dev/hda7を新たに追加するとします。あらかじめパーティションタイプをfdiskで8eに変更しといてやって |
| | + | # pvcreate /dev/hda7 |
| | + | # vgextend lvm /dev/hda7 |
| | + | # lvextend -L+120G /dev/lvm/share |
| | + | # resize_reiserfs -s +120G /dev/lvm/share |
| | + | |
| | + | 順を追って説明すると/dev/hda7の物理ボリュームを作成。/dev/hda7を追加してボリュームグループlvmを拡張。ロジカルボリューム/dev/lvm/shareを120G拡張。最後にreiserfsのファイルサイズを拡張して、作業終了でっす。再度マウントしたら、データが消去されずにディスク領域が広がってるのが分かるはず。これはすごいっしょ?? |
| | + | |
| | + | *Snapshotを利用したバックアップ [#e404c303] |
| | + | Snapshotとは、さっきも書いた、ロジカルボリュームの一瞬を切り取ったバックアップです。仕組みでいうと、変更が無いファイルは、元領域のデータを用いる。その代わりsnapshot領域に、変更されたファイルだけを書き込んでいくのです。ですので、ず～っとsnapshotをとった瞬間が保存されていくという寸法。 |
| | + | ですので、Snapshot用に取っておく領域は、変更差分が書き込まれる程度の大きさでよいわけです。目安でいうと元領域の10％程度だといわれています。１Gだったら100Mぐらい。でも、サービスが暇な夜間にSnapをとって、バックアップ領域に退避して、すぐに消してしまうのであれば、書き換えが多くは発生しないのでもっと少なくても良いわけです。これは効率的ですね♪ |
| | + | **ではSnapshotの作り方 [#fc45962b] |
| | + | SnapshotはSnapshot用の論理ボリュームを作成してやります。基本はlvmのlvcreateと一緒。 |
| | + | # lvcreate --size 1G --snapshot --name snap /dev/lvm/example |
| | + | |
| | + | 上の例だと、/dev/lvm/snapという名前の、/dev/lvm/exampleのスナップショットを作成するということ。実際に動きをみてみると、/dev/lvm/exampleが10Ｇの領域で/exportにマウントして運用中として、上記コマンドでSnapshotを作ります。で、/dev/lvm/snapを適当な場所(仮に/mnt/snap)にマウントしてやります。/exportも/mnt/snapも同じイメージが見えていますね？/exportに何かファイルを追加したり、削除したりしてやりましょう。当然/exportの内容は変わっていますよね。/mnt/snapを見てみるとどうですか？変わりない/exportが見えていませんか？ |
| | + | |
| | + | **注意 [#p25755f2] |
| | + | 先ほど変更差分を記録していく、と言いました。この例では1Gの領域を取っています。当然変更差分が1Gを超えると記録し切れません。また、リブートが発生するとSnapshotは消えてしまいます。なので一時的なものだということを意識しましょう。別の領域にフルバックアップを必ずとりましょうね。 |
| | + | |
| | + | **というわけで [#y8fff0c6] |
| | + | # lvcreate --size 1G --snapshot --name snap /dev/lvm/example |
| | + | # mount /dev/lvm/snap /mnt/snap |
| | + | # rsync -auv --delete /mnt/snap/ /backup/ |
| | + | # umount /mnt/snap |
| | + | # lvremove /dev/lvm/snap |
| | + | |
| | + | とやってやれば、Snapshotとrsyncを使用した安全バックアップが取れるというわけですね。cronなんかにshellを書いて登録してやれば自動バックアップが取れるという寸法。これで安全♪ |
ページへ戻る
