データ領域のLVM化で悩む のソース :: Nest Of Hawk

• 差分^[1] を表示
• データ領域のLVM化で悩む^[2] へ行く。

[[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に入っているソフトデータ等を玄箱に退避
+120GのHDをLVM化して、/var（20G)、/share(95G)に分ける
+140Gの領域にある/var、/share、の内容をLVMの/var、/shareに移動して、実運用システムにマウント。しばらく様子を見る
+データ整合性などに問題なしとなったら、140GをLVM化し、グループ統合する
+/shareにこの140Gを追加して、200G程度のデータ領域を作る
+玄箱に退避したデータを/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、もしくはモジュール化してやります。~


**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のファイルサイズを拡張して、作業終了でっす。再度マウントしたら、データが消去されずにディスク領域が広がってるのが分かるはず。これはすごいっしょ??

*ディスクの交換 [#be751a58]
しばらく使用していたら、ディスクから異音が…そろそろ寿命かしら。ど、どうしよう～～～。てなときに、LVMの場合データを生かしたまま移動する手段があるんですよ。やってみましょう。~

さて、このとき増設ディスクを/dev/sdc、故障間近のディスクを/dev/hddとしますね。
このとき注意するのは、交換するディスクのデータを移動するために、最低限同じ容量のディスクが必要ってことね。この時、ボリュームグループlvmのパーティションは、マウント解除しておくのをおすすめします。
**ディスクをまず増設してみる [#td0277c2]
バラして、ディスクをのっけてみましょうね。
**増設したディスクを使用できるようにする。 [#f8e67436]
-fdiskでパーティション切る
-パーティションタイプを8eに
-fdiskプロンプトのwコマンドでパーティション情報を書き込む
-qで終了

**増設したディスクをpvcreateして、vgextendする [#b54ebdea]
増設したディスクを、1ボリュームのパーティション切ったとして、話を進めましょう
 # pvcreate /dev/sdc1
 # vgextend lvm /dev/sdc1
これで、容量はそのままで、ボリュームグループlvmが使用されていないFree PEが増えた状態になります。

**/dev/hddの内容を移動 [#cd6f31fa]
pvmoveコマンドを使用します。/dev/hddは、同じく1ボリュームのパーティションだとします。
 # pvmove /dev/hdd1
これで、せこせことhdd1にあるPEが、sdc1に移動し始めます…移動が100%になったところで、pvdisplayコマンド打ってみてください。hdd1の Allocated PEが0になって、 Free PEが増えているはず。~
かわりに、/dev/sdc1に、hdd1分のAllocated PEが増えているはずです。
**/dev/hddをボリュームグループから削除する [#c39e69bd]
 # vgreduce lvm /dev/hdd1
最後に
 # pvremove /dev/hdd1
これで、/dev/hddを引っこ抜いてもOKな状態になりました。電源落として、HDDを引っこ抜きましょう。ね、簡単でしょ…


*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を書いて登録してやれば自動バックアップが取れるという寸法。これで安全♪

• データ領域のLVM化で悩む のバックアップ一覧^[4]
• データ領域のLVM化で悩む のバックアップソース(No. All)
  • 1: 2009-08-19 (水) 00:33:50^[5] maruo^[6]
  • 2: 2009-08-19 (水) 00:34:40^[7] maruo^[6]
  • 3: 2009-10-04 (日) 17:27:08^[8] maruo^[6]
  • 4: 2010-06-22 (火) 02:43:40^[9] maruo^[6]
  • 現: 2010-06-23 (水) 02:49:55 maruo^[6]