LVMの構築方法（論理ボリュームの大きさを拡張する） [Linux(LVM/RAID/Storage)]
すでにあるLVMの論理ボリュームの容量が不足してしまい、いよいよ増設しなければ！というケースでの操作について説明します。
論理ボリュームを拡張しても、それはすぐにファイルシステムの容量が広がる…というものではありません。論理ボリュームの拡張のほかに、ファイルシステムの拡張という手順が必要になりますので注意が必要です。
手順を整理すると…
①とにかくディスクを増設する
↓
②増設したディスクに、物理ボリュームを作成してからボリュームグループへの追加を行う
↓
③論理ボリュームの拡張を行う
↓
④ファイルシステムの拡張を行う
という手順を踏みます。
なお、我が家ではファイルシステムのext3を使用しているので、④の手順がちょっぴり面倒くさくてイカしてないです。
ステップ１：とにかくディスクを増設する
省略
ステップ２：増設したディスクに、物理ボリュームを作成してからボリュームグループへの追加を行う
今回の場合、例によって例のごとく、USBなHDDを増設したので、dmesgをみてデバイス名を確認します。
ということで、新しいディスクはsdcということがわかります。
まあ、必要無いといえば必要無いけど、個人的な宗教上の理由によりfdiskでパーティションを切りまして、pvcreate、vgextendの一連の処理を行います。
ここまででボリュームグループは大きくなりました。確認してみます。
ステップ３：論理ボリュームの拡張を行う
今度は、ボリュームグループ内の空き物理エクステント（Free PE）をすでにある論理ボリュームに追加で割り当てる操作を行います。
物理エクステントの状態といえば…
現時点で59617個の物理エクステントを使っていて、あと24310個を追加できます。要するに全体としては83927個なので、これを全部すでにある論理ボリュームに割り当てたいのです。
使用するコマンドは lvextend コマンドです。「-l」オプションに続けて物理エクステントの個数を指定しますが、2通りの記述方法が使えます。
前者の記述方法は、「拡張後の」物理エクステントの個数を直接指定する方法。後者の記述方法は「増加させる」物理エクステント数を指定する相対的な方法です。どっちでも支障ありません。
ちなみに私は前者の方が好みです。（笑）というわけで、前者の方法でさくっと容量拡張します。
あっという間に終了します。これで論理ボリュームとしては拡張が完了しました。確認してみましょう。
ステップ４：ファイルシステムの拡張を行う
論理ボリュームの拡張をしても、dfコマンドで容量を確認すると…
論理ボリュームとしては2.56TBあることになっていますが、ファイルシステムとしては1.8Tほどしか無いことになっています。これでは都合が悪いので、ファイルシステムを拡張しなければなりません。
ファイルシステムの種類によってこの操作方法は異なりますので、もしもあなたがext3以外のファイルシステムを使用している場合、この手順をそっくりそのまま実行しないでください。
ext3のファイルシステムの拡張方法としては、 以下のような手順を踏みます。
手順１：ファイルシステムをいったんアンマウントします
手順２：アンマウントしたファイルシステムを fsck コマンドでチェックします
手順３：ファイルシステムを resize2fs コマンドで拡張します
手順４：ファイルシステムを再びマウントします
そんな訳で、基本的にはext2/ext3ファイルシステムをオンラインのまま拡張することは残念ながらできません。（できるようにするツールはあるそうですが…）
では、実行します。
ファイルシステムをいったんアンマウントするところは、特に難しいことはありませんので省略。
続いてアンマウントしたファイルシステムをfsckコマンドでチェックします。コマンドとしては、「-f」オプションを使用することになります。チェックに時間がかかるので気長に待ちましょう。
fsckが終わればいよいよファイルシステムの拡張です。
resize2fsコマンドに、ファイルシステムのデバイス名と、拡張（変更後）のファイルシステムの容量を指定しますが、容量については指定を省略すると「最大容量」まで拡張してくれます。
あとはマウントしてみて容量が拡張されたことを確認してみます。
論理ボリュームを拡張しても、それはすぐにファイルシステムの容量が広がる…というものではありません。論理ボリュームの拡張のほかに、ファイルシステムの拡張という手順が必要になりますので注意が必要です。
手順を整理すると…
①とにかくディスクを増設する
↓
②増設したディスクに、物理ボリュームを作成してからボリュームグループへの追加を行う
↓
③論理ボリュームの拡張を行う
↓
④ファイルシステムの拡張を行う
という手順を踏みます。
なお、我が家ではファイルシステムのext3を使用しているので、④の手順がちょっぴり面倒くさくてイカしてないです。
ステップ１：とにかくディスクを増設する
省略
ステップ２：増設したディスクに、物理ボリュームを作成してからボリュームグループへの追加を行う
今回の場合、例によって例のごとく、USBなHDDを増設したので、dmesgをみてデバイス名を確認します。
[root@chihiro ~]# dmesg Linux version 2.6.18-92.1.13.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Wed Sep 24 19:32:05 EDT 2008 Command line: ro root=LABEL=/1 （途中省略） usb 1-2: new high speed USB device using ehci_hcd and address 3 usb 1-2: configuration #1 chosen from 1 choice scsi3 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning Vendor: I-O DATA Model: HDZ-UE810 Rev: 4B04 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdc: 1593188352 512-byte hdwr sectors (815712 MB) sdc: test WP failed, assume Write Enabled sdc: assuming drive cache: write through （以下略）
ということで、新しいディスクはsdcということがわかります。
まあ、必要無いといえば必要無いけど、個人的な宗教上の理由によりfdiskでパーティションを切りまして、pvcreate、vgextendの一連の処理を行います。
[root@chihiro ~]# fdisk /dev/sdc このディスクのシリンダ数は 99171 に設定されています。 間違いではないのですが、1024 を超えているため、以下の場合 に問題を生じうる事を確認しましょう: 1) ブート時に実行するソフトウェア (例. バージョンが古い LILO) 2) 別の OS のブートやパーティション作成ソフト (例. DOS FDISK, OS/2 FDISK) コマンド (m でヘルプ): p Disk /dev/sdc: 815.7 GB, 815712436224 bytes 255 heads, 63 sectors/track, 99171 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sdc1 1 99171 796591026 8e Linux LVM コマンド (m でヘルプ): w 領域テーブルは交換されました！ [root@chihiro ~]# pvcreate /dev/sdc1 Physical volume "/dev/sdc1" successfully created [root@chihiro ~]# vgextend mystorage /dev/sdc1 Volume group "mystorage" successfully extended
ここまででボリュームグループは大きくなりました。確認してみます。
[root@chihiro ~]# vgdisplay -v
Finding all volume groups
Finding volume group "mystorage"
--- Volume group ---
VG Name mystorage
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 2.56 TB
PE Size 32.00 MB
Total PE 83927
Alloc PE / Size 59617 / 1.82 TB
Free PE / Size 24310 / 759.69 GB
VG UUID Rh2eH5-oVGz-kw50-MEb7-DnPy-Kj6v-7BMelq
--- Logical volume ---
LV Name /dev/mystorage/vol00
VG Name mystorage
LV UUID CzkjoT-deWp-ashv-n3t2-ESv8-5yx5-Onj1oF
LV Write Access read/write
LV Status available
# open 1
LV Size 1.82 TB
Current LE 59617
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Physical volumes ---
PV Name /dev/sdb1
PV UUID wf4W3u-M1jZ-WN06-oevF-6G3e-MFCA-PGERP8
PV Status allocatable
Total PE / Free PE 59617 / 0
PV Name /dev/sdc1
PV UUID h1RkfJ-9NZX-iL65-iJA6-sBVJ-Aqv4-eMsoaP
PV Status allocatable
Total PE / Free PE 24310 / 24310
ステップ３：論理ボリュームの拡張を行う
今度は、ボリュームグループ内の空き物理エクステント（Free PE）をすでにある論理ボリュームに追加で割り当てる操作を行います。
物理エクステントの状態といえば…
Total PE 83927 Alloc PE / Size 59617 / 1.82 TB Free PE / Size 24310 / 759.69 GB
現時点で59617個の物理エクステントを使っていて、あと24310個を追加できます。要するに全体としては83927個なので、これを全部すでにある論理ボリュームに割り当てたいのです。
使用するコマンドは lvextend コマンドです。「-l」オプションに続けて物理エクステントの個数を指定しますが、2通りの記述方法が使えます。
# lvextend -l 83927 /dev/mystorage/vol00 #lvextend -l +24310 /dev/mystorage/vol00
前者の記述方法は、「拡張後の」物理エクステントの個数を直接指定する方法。後者の記述方法は「増加させる」物理エクステント数を指定する相対的な方法です。どっちでも支障ありません。
ちなみに私は前者の方が好みです。（笑）というわけで、前者の方法でさくっと容量拡張します。
[root@chihiro ~]# lvextend -l 83927 /dev/mystorage/vol00 Extending logical volume vol00 to 2.56 TB Logical volume vol00 successfully resized
あっという間に終了します。これで論理ボリュームとしては拡張が完了しました。確認してみましょう。
[root@chihiro ~]# vgdisplay -v
Finding all volume groups
Finding volume group "mystorage"
--- Volume group ---
VG Name mystorage
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 5
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 2.56 TB
PE Size 32.00 MB
Total PE 83927
Alloc PE / Size 83927 / 2.56 TB
Free PE / Size 0 / 0
VG UUID Rh2eH5-oVGz-kw50-MEb7-DnPy-Kj6v-7BMelq
--- Logical volume ---
LV Name /dev/mystorage/vol00
VG Name mystorage
LV UUID CzkjoT-deWp-ashv-n3t2-ESv8-5yx5-Onj1oF
LV Write Access read/write
LV Status available
# open 1
LV Size 2.56 TB
Current LE 83927
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Physical volumes ---
PV Name /dev/sdb1
PV UUID wf4W3u-M1jZ-WN06-oevF-6G3e-MFCA-PGERP8
PV Status allocatable
Total PE / Free PE 59617 / 0
PV Name /dev/sdc1
PV UUID h1RkfJ-9NZX-iL65-iJA6-sBVJ-Aqv4-eMsoaP
PV Status allocatable
Total PE / Free PE 24310 / 0
ステップ４：ファイルシステムの拡張を行う
論理ボリュームの拡張をしても、dfコマンドで容量を確認すると…
[root@chihiro ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/sda3 89G 2.2G 82G 3% /
/dev/sda1 251M 22M 217M 9% /boot
tmpfs 1001M 0 1001M 0% /dev/shm
/dev/mapper/mystorage-vol00
1.8T 196M 1.7T 1% /mnt/mystorage
論理ボリュームとしては2.56TBあることになっていますが、ファイルシステムとしては1.8Tほどしか無いことになっています。これでは都合が悪いので、ファイルシステムを拡張しなければなりません。
ファイルシステムの種類によってこの操作方法は異なりますので、もしもあなたがext3以外のファイルシステムを使用している場合、この手順をそっくりそのまま実行しないでください。
ext3のファイルシステムの拡張方法としては、 以下のような手順を踏みます。
手順１：ファイルシステムをいったんアンマウントします
手順２：アンマウントしたファイルシステムを fsck コマンドでチェックします
手順３：ファイルシステムを resize2fs コマンドで拡張します
手順４：ファイルシステムを再びマウントします
そんな訳で、基本的にはext2/ext3ファイルシステムをオンラインのまま拡張することは残念ながらできません。（できるようにするツールはあるそうですが…）
では、実行します。
ファイルシステムをいったんアンマウントするところは、特に難しいことはありませんので省略。
続いてアンマウントしたファイルシステムをfsckコマンドでチェックします。コマンドとしては、「-f」オプションを使用することになります。チェックに時間がかかるので気長に待ちましょう。
[root@chihiro ~]# fsck -f /dev/mystorage/vol00 fsck 1.39 (29-May-2006) e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information LABEL=MyStorage: 14/244203520 files (7.1% non-contiguous), 7713456/488382464 blocks
fsckが終わればいよいよファイルシステムの拡張です。
resize2fsコマンドに、ファイルシステムのデバイス名と、拡張（変更後）のファイルシステムの容量を指定しますが、容量については指定を省略すると「最大容量」まで拡張してくれます。
[root@chihiro ~]# resize2fs /dev/mystorage/vol00 resize2fs 1.39 (29-May-2006) Resizing the filesystem on /dev/mystorage/vol00 to 687529984 (4k) blocks. The filesystem on /dev/mystorage/vol00 is now 687529984 blocks long.
あとはマウントしてみて容量が拡張されたことを確認してみます。
[root@chihiro ~]# mount /dev/mystorage/vol00 /mnt/mystorage
[root@chihiro ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/sda3 89G 2.2G 82G 3% /
/dev/sda1 251M 22M 217M 9% /boot
tmpfs 1001M 0 1001M 0% /dev/shm
/dev/mapper/mystorage-vol00
2.6T 203M 2.5T 1% /mnt/mystorage
LVMの構築方法（物理エクステントの大きさを変更する） [Linux(LVM/RAID/Storage)]
LVM2ではあまり意識する必要も無くなりましたが、LVMのver1では、1個の論理ボリュームに組み込める物理エクステントの個数は65536個までという制限がありました。このため、デフォルトのままでLVMを構築しても、1個のボリュームはたかだか256GBまでしか使えないという切ない制限がありました。
そこで、もっと大きなボリュームが必要という場合は、物理エクステント1個あたりの大きさを大きくして対応するということになっていました。標準状態では1個4MBですが、これを16MBにすれば1TBまで使えるし、64MBにすれば4TBとかいけるようになる…というものでした。
LVM2の場合は個数制限が緩やかになったので、とてつもなく大きな数値にすることが出来るようになった訳ではありますが、特性上、物理エクステントの個数がやたら増えるとパフォーマンスが低下する…と、言われています。そこで、最初から大きな容量になることが判っているような場合は、物理エクステントの1個あたりの大きさをあらかじめ大きくしておくことが推奨されているようです。
では、物理エクステントの大きさを変更するにはどうすればよいか、記述しておきます。
ボリュームグループを作成する時点（つまり、最初）から変更しておきたいという場合は、 vgcreate コマンドに「-s」オプションを追加します。
↑この例ですと、物理エクステント1個あたりの大きさは16MBになります。通常の4倍です。
また、私は試したことがないのですが、ボリュームグループ作成後にも変更できそうな雰囲気ではあります。 vgchange コマンドに「-s」オプションを指定します。
このようになるようです。ちょっと今は実験する環境が無いのでのちほど実験しておきたいとは思います。
こうして物理エクステントの大きさが変更されたことが vgdisplay コマンドで確認できますので見ておきましょう。
物理エクステント1個あたりの大きさ（PE Size）が16.00MBとなっていることが確認できました。
まあ、もっと大きくしておいてもいいのかもしれないけどねー。
そこで、もっと大きなボリュームが必要という場合は、物理エクステント1個あたりの大きさを大きくして対応するということになっていました。標準状態では1個4MBですが、これを16MBにすれば1TBまで使えるし、64MBにすれば4TBとかいけるようになる…というものでした。
LVM2の場合は個数制限が緩やかになったので、とてつもなく大きな数値にすることが出来るようになった訳ではありますが、特性上、物理エクステントの個数がやたら増えるとパフォーマンスが低下する…と、言われています。そこで、最初から大きな容量になることが判っているような場合は、物理エクステントの1個あたりの大きさをあらかじめ大きくしておくことが推奨されているようです。
では、物理エクステントの大きさを変更するにはどうすればよいか、記述しておきます。
ボリュームグループを作成する時点（つまり、最初）から変更しておきたいという場合は、 vgcreate コマンドに「-s」オプションを追加します。
# vgcreate -s 16M mystorage /dev/sdb1
↑この例ですと、物理エクステント1個あたりの大きさは16MBになります。通常の4倍です。
また、私は試したことがないのですが、ボリュームグループ作成後にも変更できそうな雰囲気ではあります。 vgchange コマンドに「-s」オプションを指定します。
# vgchange -s 16M mystorage
このようになるようです。ちょっと今は実験する環境が無いのでのちほど実験しておきたいとは思います。
こうして物理エクステントの大きさが変更されたことが vgdisplay コマンドで確認できますので見ておきましょう。
# vgdisplay --- Volume group --- VG Name mystorage System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 1.82 TB PE Size 16.00 MB Total PE 119234 Alloc PE / Size 119234 / 1.82 TB Free PE / Size 0 / 0 VG UUID Rh2eH5-oVGz-kw50-MEb7-DnPy-Kj6v-7BMelq
物理エクステント1個あたりの大きさ（PE Size）が16.00MBとなっていることが確認できました。
まあ、もっと大きくしておいてもいいのかもしれないけどねー。
LVMのトラブルShooting☆Star(ﾁｶﾞｳ その２ [Linux(LVM/RAID/Storage)]
●mixiからの転記（＆編集＆追記）
LVMを構成しているディスクのうちの1本が壊れそうだ！という場合の対応方法について基本的なところを記載しておきます。
LVMを構成して運用しているディスクには、何らかのデータが書き込まれているはずですが、これをそのまま引っこ抜いてしまうと、データを失ってしまいますので…
① 引っこ抜きたいディスク上のデータを他のディスク（同じボリュームグループ内の他のディスク）にデータを移動する
↓
② ディスクを引っこ抜く（交換する）
という手順が必要です。
「同じボリュームグループ内の他のディスク」と記述してはいますが、例えばRAIDのように同じ容量のディスクをもう一つ用意しなければならないという訳ではありません。LVMの場合は抜き取りたいディスクが持っている物理エクステントと同じだけの空き物理エクステント(Free PE)があればよいのです。
その辺の確認方法を以下に示します。
例えば、ここでは例として「/dev/sdn1」のディスクを交換（抜き取り）したいと想定します。vgdisplayコマンドに「-v」オプションを付けて実行しますと…
このLVMの場合、ボリュームグループ全体で1193228個のPEを保有し、全部使っています。一方で交換対象としたいディスクは59841個のPEがあります。
というわけで、このディスクを交換するためには少なくとも59841個の空きPEを捻出しなければならないということが判ります。
で、ここがLVMの良いところなんですが、普通、ディスク交換というと壊れたディスクを抜く→新しいディスクを差し込む→リビルドなり設定なりという手順を踏む訳ですが、LVMだったら、新しいディスクを差し込む→設定変更・データ移動→壊れたディスクを抜く という手順で実施することができます。これでほぼオンラインで交換作業ができちゃったりする訳ですよ奥さん。
また、交換作業中の一時的な対応と割り切るなら、容量（物理エクステントの個数）のつじつまさえあればディスクの種類やら接続方法やらを全く問いません。
では、ディスクを交換する操作を追ってみましょう。
ステップ１：新しいディスクを接続する。
ここでは約320GBのUSB接続なディスクを用意してUSBのポートにざくっと接続してみました。
dmesgで接続されたことが確認できます。
sdpってｗ
で、これをLVMの構築時と同様に物理ボリュームを作成し、ボリュームグループに追加する手順を踏みます。
これで交換準備は整いました。vgdisplayコマンドでボリュームグループの状態を見てみると…
と、ボリュームグループ内に76310個の空き物理エクステントが追加されました。
ステップ２：交換対象となるディスク上のデータを移動する
これから引っこ抜きたいディスクの上のデータを、ボリュームグループ内に確保された空き物理エクステントにコピーする処理を行います。使用するコマンドは pvmove です。引数として「引っこ抜きたいディスクのデバイス名」（ここでは/dev/sdn1）を指定します。
なお、ここで「 mirror: Required device-mapper target(s) not detected in your kernel」とかエラーが出たら、dm-mirrorドライバを組み込んでやる必要があります。
こんな感じ。
コピーしたいデータの量によってはコピーに時間がかかりますので気長に待ちましょう。
ステップ３：交換対象となるディスクをボリュームグループから除外する
ここまでの操作で、ボリュームグループ内に登録されている物理ボリュームは、こんな状態になっています。sdn1が、今回交換対象としたディスク。参考までに、sdm1も表示していますが、これはsdn1と全く同じディスクで交換はしないディスクです。また、sdp1はsdn1の代わりに今回追加したディスクです。
sdn1のFree PEがTotal PEと同じ数値になっていることから、すでにこのディスクは使われていない（ボリュームグループに所属しているだけの）状態になっていることが確認できます。
このような状態になったディスクをボリュームグループから除外するには、 vgreduce コマンドを使用します。
ちゃんと除外されたかどうか、確認してみましょう。
sdn1がいなくなっていることが判ります。
これで、sdn1をいつでも引っこ抜ける状態になりました。
ちなみに、今回追加したsdp1が「一時しのぎ用」みたいなケースで、本番運用のためには別のディスクを戻して使いたいという場合は、交換した新しいディスクに、物理ボリュームを作成→ボリュームグループに追加→「一時しのぎ用ディスク」のデータを空き物理エクステントに移動→「一時しのぎ用ディスク」をボリュームグループから除外→「一時しのぎ用ディスク」を引っこ抜く…というような、今回と同じような操作をもう一度やればOKです。
なお、この辺の一連の作業はオンライン状態のまま実施できます。
LVMを構成しているディスクのうちの1本が壊れそうだ！という場合の対応方法について基本的なところを記載しておきます。
LVMを構成して運用しているディスクには、何らかのデータが書き込まれているはずですが、これをそのまま引っこ抜いてしまうと、データを失ってしまいますので…
① 引っこ抜きたいディスク上のデータを他のディスク（同じボリュームグループ内の他のディスク）にデータを移動する
↓
② ディスクを引っこ抜く（交換する）
という手順が必要です。
「同じボリュームグループ内の他のディスク」と記述してはいますが、例えばRAIDのように同じ容量のディスクをもう一つ用意しなければならないという訳ではありません。LVMの場合は抜き取りたいディスクが持っている物理エクステントと同じだけの空き物理エクステント(Free PE)があればよいのです。
その辺の確認方法を以下に示します。
例えば、ここでは例として「/dev/sdn1」のディスクを交換（抜き取り）したいと想定します。vgdisplayコマンドに「-v」オプションを付けて実行しますと…
# vgdisplay -v
Finding all volume groups
Finding volume group "vgtera"
--- Volume group ---
VG Name vgtera
System ID
Format lvm2
Metadata Areas 8
（途中省略）
VG Size 4.55 TB
PE Size 4.00 MB
Total PE 1193228
Alloc PE / Size 1193228 / 4.55 TB
Free PE / Size 0 / 0
VG UUID RBEJZT-k2Vo-AKtl-OIYq-imHx-gnca-RDbvUU
--- Logical volume ---
LV Name /dev/vgtera/lva
VG Name vgtera
（途中省略）
--- Physical volumes ---
（途中省略）
PV Name /dev/sdn1
PV UUID Pp0EZz-2dNy-y5G3-Y92a-UZ7H-5pMA-RyM9rA
PV Status allocatable
Total PE / Free PE 59841 / 0
（以下略）
このLVMの場合、ボリュームグループ全体で1193228個のPEを保有し、全部使っています。一方で交換対象としたいディスクは59841個のPEがあります。
というわけで、このディスクを交換するためには少なくとも59841個の空きPEを捻出しなければならないということが判ります。
で、ここがLVMの良いところなんですが、普通、ディスク交換というと壊れたディスクを抜く→新しいディスクを差し込む→リビルドなり設定なりという手順を踏む訳ですが、LVMだったら、新しいディスクを差し込む→設定変更・データ移動→壊れたディスクを抜く という手順で実施することができます。これでほぼオンラインで交換作業ができちゃったりする訳ですよ奥さん。
また、交換作業中の一時的な対応と割り切るなら、容量（物理エクステントの個数）のつじつまさえあればディスクの種類やら接続方法やらを全く問いません。
では、ディスクを交換する操作を追ってみましょう。
ステップ１：新しいディスクを接続する。
ここでは約320GBのUSB接続なディスクを用意してUSBのポートにざくっと接続してみました。
dmesgで接続されたことが確認できます。
usb 3-1: new high speed USB device using ehci_hcd and address 3 usb 3-1: configuration #1 chosen from 1 choice scsi7 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning Vendor: I-O DATA Model: HDC-U Rev: 1.09 Type: Direct-Access ANSI SCSI revision: 02 SCSI device sdp: 625142448 512-byte hdwr sectors (320073 MB) （以下略）
sdpってｗ
で、これをLVMの構築時と同様に物理ボリュームを作成し、ボリュームグループに追加する手順を踏みます。
# fdisk /dev/sdp # pvcreate /dev/sdp1 Physical volume "/dev/sdp1" successfully created # vgextend vgtera /dev/sdp1 Volume group "vgtera" successfully extended
これで交換準備は整いました。vgdisplayコマンドでボリュームグループの状態を見てみると…
# vgdisplay -v （ばっさり省略） VG Size 4.84 TB PE Size 4.00 MB Total PE 1269538 Alloc PE / Size 1193228 / 4.55 TB Free PE / Size 76310 / 298.09 GB VG UUID RBEJZT-k2Vo-AKtl-OIYq-imHx-gnca-RDbvUU （ばっさり省略） PV Name /dev/sdn1 PV UUID Pp0EZz-2dNy-y5G3-Y92a-UZ7H-5pMA-RyM9rA PV Status allocatable Total PE / Free PE 59841 / 0 PV Name /dev/sdp1 PV UUID Q002wj-0dsD-rf42-Q0gF-xXRg-iTK8-6yeW6Z PV Status allocatable Total PE / Free PE 76310 / 76310
と、ボリュームグループ内に76310個の空き物理エクステントが追加されました。
ステップ２：交換対象となるディスク上のデータを移動する
これから引っこ抜きたいディスクの上のデータを、ボリュームグループ内に確保された空き物理エクステントにコピーする処理を行います。使用するコマンドは pvmove です。引数として「引っこ抜きたいディスクのデバイス名」（ここでは/dev/sdn1）を指定します。
# pvmove /dev/sdn1
なお、ここで「 mirror: Required device-mapper target(s) not detected in your kernel」とかエラーが出たら、dm-mirrorドライバを組み込んでやる必要があります。
# modprobe dm-mirror # pvmove /dev/sdn1 /dev/sdn1: Moved: 0.1% /dev/sdn1: Moved: 0.2% /dev/sdn1: Moved: 0.4% /dev/sdn1: Moved: 0.5% /dev/sdn1: Moved: 0.6%
こんな感じ。
コピーしたいデータの量によってはコピーに時間がかかりますので気長に待ちましょう。
ステップ３：交換対象となるディスクをボリュームグループから除外する
ここまでの操作で、ボリュームグループ内に登録されている物理ボリュームは、こんな状態になっています。sdn1が、今回交換対象としたディスク。参考までに、sdm1も表示していますが、これはsdn1と全く同じディスクで交換はしないディスクです。また、sdp1はsdn1の代わりに今回追加したディスクです。
--- Physical volume --- PV Name /dev/sdm1 VG Name vgtera PV Size 233.76 GB / not usable 2.90 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 59841 Free PE 0 Allocated PE 59841 PV UUID UjFfgA-XQgx-6xvl-PJ1m-aalI-HkIo-pv2kBB --- Physical volume --- PV Name /dev/sdn1 VG Name vgtera PV Size 233.76 GB / not usable 2.90 MB Allocatable yes PE Size (KByte) 4096 Total PE 59841 Free PE 59841 Allocated PE 0 PV UUID Pp0EZz-2dNy-y5G3-Y92a-UZ7H-5pMA-RyM9rA --- Physical volume --- PV Name /dev/sdp1 VG Name vgtera PV Size 298.09 GB / not usable 2.81 MB Allocatable yes PE Size (KByte) 4096 Total PE 76310 Free PE 16469 Allocated PE 59841 PV UUID Q002wj-0dsD-rf42-Q0gF-xXRg-iTK8-6yeW6Z
sdn1のFree PEがTotal PEと同じ数値になっていることから、すでにこのディスクは使われていない（ボリュームグループに所属しているだけの）状態になっていることが確認できます。
このような状態になったディスクをボリュームグループから除外するには、 vgreduce コマンドを使用します。
# vgreduce vgtera /dev/sdn1 Removed "/dev/sdn1" from volume group "vgtera"
ちゃんと除外されたかどうか、確認してみましょう。
# vgdisplay -v
Finding all volume groups
Finding volume group "vgtera"
--- Volume group ---
VG Name vgtera
（途中省略）
VG Size 4.61 TB
PE Size 4.00 MB
Total PE 1209697
Alloc PE / Size 1193228 / 4.55 TB
Free PE / Size 16469 / 64.33 GB
（途中省略）
PV Name /dev/sdm1
PV UUID UjFfgA-XQgx-6xvl-PJ1m-aalI-HkIo-pv2kBB
PV Status allocatable
Total PE / Free PE 59841 / 0
PV Name /dev/sdp1
PV UUID Q002wj-0dsD-rf42-Q0gF-xXRg-iTK8-6yeW6Z
PV Status allocatable
Total PE / Free PE 76310 / 16469
sdn1がいなくなっていることが判ります。
これで、sdn1をいつでも引っこ抜ける状態になりました。
ちなみに、今回追加したsdp1が「一時しのぎ用」みたいなケースで、本番運用のためには別のディスクを戻して使いたいという場合は、交換した新しいディスクに、物理ボリュームを作成→ボリュームグループに追加→「一時しのぎ用ディスク」のデータを空き物理エクステントに移動→「一時しのぎ用ディスク」をボリュームグループから除外→「一時しのぎ用ディスク」を引っこ抜く…というような、今回と同じような操作をもう一度やればOKです。
なお、この辺の一連の作業はオンライン状態のまま実施できます。
LVMのトラブルShooting☆Star(ﾁｶﾞｳ [Linux(LVM/RAID/Storage)]
●mixiからの転記（＆加筆）
LVMの構築方法とかはあちこちに紹介があるんだけど、トラブったときの情報とかめっちゃ少な杉なのでここに書いておくお。
☆他のサーバ（ＰＣ）で構築したlvmなディスクを移植する場合
例えばＰＣが壊れちゃったとかのケースで、他のマシンにLinuxをセットアップして中のデータをサルベージしたいとかありますよね。その場合にどうすればいいかな～？という時に役立つかもしれない役立たないかもしれない対処方法。
こういう時はさすがにUSBなハードディスクだとラクに救済できてラッキーとか思いますよほんとに。（笑）
手順としてはこんな感じ。
①他のサーバでlvmが使えるようにしておく
→確認方法とかセットアップ方法とかは基本編を参照汁！
②ディスクを他のサーバに接続する
→USBならざくざく差し込めばいいですな。
③移設したディスクにある「物理ボリューム」を認識させる
④移設したディスクにある「ボリュームグループ」を認識させる
⑤「ボリュームグループ」を活性化させる
⑥マウント汁
ということになります。
てなわけで解説いきますお。
ステップ１：他のサーバでlvmが使えるようにしておく
省略！
ステップ２：ディスクを他のサーバに接続する
省略！
なお、cat /proc/partitionsで接続したディスクがちゃんと見えていることをあらかじめ確認しておきましょう。この際に、デバイス名が元々のサーバと違っていても全く気にする必要はありません。例えば、元々のサーバに接続されていた時に「/dev/sdg1」だったデバイス名が他のサーバで「/dev/sdj1」とかになっていても、無問題だということです。
ステップ３：移設したディスクにある「物理ボリューム」を認識させる
なんも難しいことは無くて、 pvscan コマンドをポンと実行して終了。
エラーがなければ特に何も表示されないかと。
認識されたかどうか、 pvdisplay コマンドで確認しておきませう。
ステップ４：移設したディスクにある「ボリュームグループ」を認識させる
これも難しいことはなくて、 vgscan コマンドをポンと実行して終了。
なお、ここでは触れてないけども、元々のサーバで vgexport コマンドを実行した場合は、ディスクを移設した先のマシンで vgimport コマンドを実行するですよ。まあ、この手順を省略してもほとんどの場合はサクっとボリュームグループが認識されるはずです。サーバがハングアップしたとかいうケースで運が悪いとこの手順が無いとダメぽ！…みたいなこともあるようなないような。
ボリュームグループが本当に認識されたかどうか vgdisplay コマンドで確認しましょう。
ただし、この状態だとまだボリュームグループが非活性という状態になっていて、そのボリュームをマウントできない状態になっていますので、あと一手間必要です。
ステップ５：「ボリュームグループ」を活性化させる
実際にそのファイルシステムを使用するために必要なおまじないがあります。 vgchange コマンドを使用します。「-ay」オプションに続けてボリュームグループ名を記述するのです。前アーティクル(LVMの構築方法（基本編）)の例では「vgtera」という名前を割り当てましたから…
ということになりますな。これでlvmが活性化されましたので…
ステップ６：マウント汁
まうんとしる。
mount /dev/vgtera/lva /mnt/hoge
とか
mount LABEL=DATAAREA /mnt/hoge
とかでおっけーですお。
なお、こんな場末なblogの落書きを見てしまった識者の方で指摘とかツッコミとかありましたらコメントよろしこです。
LVMの構築方法とかはあちこちに紹介があるんだけど、トラブったときの情報とかめっちゃ少な杉なのでここに書いておくお。
☆他のサーバ（ＰＣ）で構築したlvmなディスクを移植する場合
例えばＰＣが壊れちゃったとかのケースで、他のマシンにLinuxをセットアップして中のデータをサルベージしたいとかありますよね。その場合にどうすればいいかな～？という時に役立つかもしれない役立たないかもしれない対処方法。
こういう時はさすがにUSBなハードディスクだとラクに救済できてラッキーとか思いますよほんとに。（笑）
手順としてはこんな感じ。
①他のサーバでlvmが使えるようにしておく
→確認方法とかセットアップ方法とかは基本編を参照汁！
②ディスクを他のサーバに接続する
→USBならざくざく差し込めばいいですな。
③移設したディスクにある「物理ボリューム」を認識させる
④移設したディスクにある「ボリュームグループ」を認識させる
⑤「ボリュームグループ」を活性化させる
⑥マウント汁
ということになります。
てなわけで解説いきますお。
ステップ１：他のサーバでlvmが使えるようにしておく
省略！
ステップ２：ディスクを他のサーバに接続する
省略！
なお、cat /proc/partitionsで接続したディスクがちゃんと見えていることをあらかじめ確認しておきましょう。この際に、デバイス名が元々のサーバと違っていても全く気にする必要はありません。例えば、元々のサーバに接続されていた時に「/dev/sdg1」だったデバイス名が他のサーバで「/dev/sdj1」とかになっていても、無問題だということです。
ステップ３：移設したディスクにある「物理ボリューム」を認識させる
なんも難しいことは無くて、 pvscan コマンドをポンと実行して終了。
エラーがなければ特に何も表示されないかと。
認識されたかどうか、 pvdisplay コマンドで確認しておきませう。
ステップ４：移設したディスクにある「ボリュームグループ」を認識させる
これも難しいことはなくて、 vgscan コマンドをポンと実行して終了。
なお、ここでは触れてないけども、元々のサーバで vgexport コマンドを実行した場合は、ディスクを移設した先のマシンで vgimport コマンドを実行するですよ。まあ、この手順を省略してもほとんどの場合はサクっとボリュームグループが認識されるはずです。サーバがハングアップしたとかいうケースで運が悪いとこの手順が無いとダメぽ！…みたいなこともあるようなないような。
ボリュームグループが本当に認識されたかどうか vgdisplay コマンドで確認しましょう。
ただし、この状態だとまだボリュームグループが非活性という状態になっていて、そのボリュームをマウントできない状態になっていますので、あと一手間必要です。
ステップ５：「ボリュームグループ」を活性化させる
実際にそのファイルシステムを使用するために必要なおまじないがあります。 vgchange コマンドを使用します。「-ay」オプションに続けてボリュームグループ名を記述するのです。前アーティクル(LVMの構築方法（基本編）)の例では「vgtera」という名前を割り当てましたから…
[root@server1 root]# vgchange -ay vgtera
ということになりますな。これでlvmが活性化されましたので…
ステップ６：マウント汁
まうんとしる。
mount /dev/vgtera/lva /mnt/hoge
とか
mount LABEL=DATAAREA /mnt/hoge
とかでおっけーですお。
なお、こんな場末なblogの落書きを見てしまった識者の方で指摘とかツッコミとかありましたらコメントよろしこです。
LVMの構築方法（基本編） [Linux(LVM/RAID/Storage)]
●mixiからの転記（＆加筆）
HDDがアフォみたいに安くなってくる一方で、動画ファイルとか使う方もサイズがでっかくなってくるので、「ニコイチ」とか「ヨンコイチ」とかああいうディスクケースを使ったりRAIDしたりする訳ですが、特にUSBのHDDを使い出すと、だんだんPCにディスクが「鈴なり」状態に、ディスクスペースが細切れ状態になってきて微妙にもったいなかったり、使いづらかったりする訳ですよ。
で、そこで複数のディスクをガッチャンコしちゃおうという目的でLinuxでLVMしちまおう…ということでこのエントリーとあいなった訳ですよ。
基本路線としては、
・LinuxでSambaな環境を構築して、Windowsには「ネットワークドライブ」という形で見せよう
・ネットワークドライブがいっぱいになるのはかんべんな
・バックアップとか考えると頭が痛くなるので、本当ならRAID5とかしたい訳だが、失業した古いHDDを再利用してでっかいディスクとして見せたいので、「壊れたら壊れたであきらめる」前提とする（ちゃんと守りたいデータは新しいディスクを買ってきてRAIDしる！）
ということで。
なお、当方の環境の都合上話は全てCentOS5.2とかその辺の上で進行しますので念のため。
で、lvmを使うにはおおざっぱにいって3段階の手順とか必要になる。
①ハードディスクに「物理ボリューム」を作成する。
→まずは全部のハードディスクに物理ボリュームを作成することになる
②作成した物理ボリュームを、「ボリュームグループ」に登録する。
→この「ボリュームグループ」は「1個の巨大なハードディスク」みたいな感じに見えることになる。
③複数の物理ボリュームが登録されたボリュームグループから、必要に応じて「論理ボリューム」を切り出す。
→ボリュームグループは「1個の巨大なハードディスク」なら、「物理ボリューム」は「パーティション」に相当すると考えるとよろし。今回のような目的で使うなら、「1個のハードディスクに1個のパーティション」みたいな感じになるですよ。
これ以降は、普通にファイルシステムを作成してマウントして使えるですよ。
これだけならまあRAID0したり「テラタワー」みたいな製品を使えばいいじゃんということになるんだろうけども、lvmにしておけば…
メリット１：あとからハードディスクを追加して、ボリュームグループとか論理ボリュームを大きくできる
メリット２：ディスクの「交換」にも割と柔軟に対応できる（ダメな時はダメぽ…ということもあるけどなー）
メリット３：SASだろうとSATAだろうとUSBなHDDだろうとお構いなしに全部「がっちゃんこ」できる
要するに、RAIDよりもずーっと敷居が低い訳ですよ。いろんな意味で。（特に資金的にも！）まあ、その分、RAID1とかRAID5とかのようにファイルをがっちり守るとかはちょっとアレな面も。（lvmでミラーリングもできるけどなー）
そんな訳で、lvm構築方法を以下に書き殴っておく。
ステップ０：準備・lvmに必要なパッケージは入っているかな？＆ディスクをつなごう～！
おそらく、普通にCentOSをセットアップしておけば標準で入ってくるような気がする今日この頃ですが、パッケージは入っているかな？チェックしてみませう。
コマンドが入っててLVM versionの表示が２以降なら多分問題ない希ガス。必要なパッケージは…
入ってない場合は、yumでさくっと入れてしまいませう。
ということなので、
ですな。なお、Vineなお友達は…
つーことなので
とするよろし。
で、ディスクをざくざく接続するですよ。OSから認識できているディスクについてはdmesgで確認するとか/proc/partitionsを見るとかしませう。
まあ、健全なパソコンオタクちゃんならこれくらいはディスクが鈴なりになっているんじゃなかろうかと思います。健全でない「マル廃」なオタクちゃんの場合はきっと「すげー高級なRAIDカード」とか使っていそうなのでそういう「マル廃本仕込み」なオタクちゃんはどっか他いくよろし。
ちなみにこのマシンの場合、sdaとsdcがマザボに接続されているHDD、sdoはRAID5なUSB-HDD（具体的にはバッキャローのUSBなアレ）で今回「がっちゃんこ」する対象外。md0はLinuxのソフトウェアRAIDなデバイスで、sdf、sde、sdd、sdbを4本束ねてRAID5してるので、これも今回の「がっちゃんこ」する対象外。
そんな訳で、sdg、sdh、sdi、sdj、sdk、sdl、sdm、sdnの８本がlvmで「がっちゃんこ」される対象となるですよ。
では、さっそく「がっちゃんこ」してまいります。
ステップ１：ハードディスクに「物理ボリューム」を作成する
えーと、本当はいらないんだけど、私はコレを省略するとどーしても気持ちが悪いのでやってますが、よい子のみんなはやってもやらなくてもどっちでもいいお。
それぞれのディスクにパーティションを切ります。おきまりの「fdisk」ですな。（サンプル中のデバイス名は適宜読み替えよう。）
１個のハードディスクを丸ごと１個のパーティションにしておいて、パーティションのIDを変更します。「n」して「t」して「8e」にして「w」すればオッケーです。（リサイクルだという場合は最初に「d」してくだちい。）何のことかさっぱりわからんという人はお帰りください。
lvmで「がっちゃんこ」したい全てのディスクにLinuxLVMのパーティションを作成したら、いよいよlvmの操作に入ります。
lvmの「物理ボリューム」の作成には pvcreate コマンドを使います。基本形としては…
です。いちいちコマンド8回も実行するのは面倒くさいので
とでもしておけば8本全部に物理ボリュームが作成されるですよ。
物理ボリュームが作成されたかどうかチェックするには pvdisplay コマンド。
すでにこのサーバではLVMでボリュームを作成してあるのでFree PEが０になってますが、作成したばっかりの状態だとFree PEになんらかの数値が入っていることでせう。VG Nameも表示されなはずですお。
ステップ２：作成した物理ボリュームを、「ボリュームグループ」に登録する。
複数ある「物理ボリューム」を「ボリュームグループ」に登録して、「1個の巨大なハードディスクのようなもの」を作成します。
このボリュームグループには何か分かり易そうな名前を付けておきます。で、使用するコマンドは vgcreate です。引数として、「ボリュームグループ名」と「登録する物理ボリュームのデバイス名」を続けて書きます。
今回の例として、「ボリュームグループ名」に「vgtera」と名前を付けることにします。
なんてことになりますが、最初から複数の物理ボリュームを追加しつつ新規作成できますので、その場合は物理ボリュームのデバイス名を書き並べることになります。
たとえば↑こんな感じ。ちなみに今回のケースだと
と、なる訳です。
ちなみに、「初めてだから1個だけ登録してみた～」とか「やっう゛ぇー。デバイス名書き忘れてしまった～」みたいな場合は、 vgextend コマンドで既存のボリュームグループに物理ボリュームを追加します。
とかこんな感じで。
ディスクが「がっちゃんこ」された様子を見たい場合は、 vgdisplay コマンドで表示されます。
↑上記の例だと、すでにlvmが以下略なのでFree PE/Sizeが以下略ですが、ボリュームグループを作成した直後の場合は以下略。
なお、コマンドにボリュームグループ名「vgtera」を付けてますが、これを省略するとそのマシンで作成されている全てのボリュームグループの情報が表示されます。また、「-v」オプションを付けると登録されている物理ボリュームの情報とかも全て表示されます。
↑上記の例だと、すでにlvmが以下略なので論理ボリュームの情報が表示されていたり以下略ですが新規に作成したばっかりの状態だと以下略。
ステップ３：複数の物理ボリュームが登録されたボリュームグループから、必要に応じて「論理ボリューム」を切り出す。
ここまでで、ディスク８本を「がっちゃんこ」して約4.5TBのでっかい領域が作成されてニヨニヨしてますが、これではまだ不完全で、ここから「論理ボリューム」を作成します。
さきほと vgdisplay コマンドで…
という表示があったと思う。この「PE」という物は「物理エクステンド」という物で、ボリュームグループをデフォルトで4MB単位のブロックに区切り、そのブロックの個数を示しています。この物理エクステンドのサイズは変更することが出来るのだけども、ぶっちゃけ、lvm2を使っている限りあんまり意味はないです。
大きくするとディスク容量の端数が無駄になりやすいとかあったり、小さくすると物理エクステンドの個数がやたら多くなってパフォーマンスが低下するとかありますが、まあ、USB-HDDを使ってる時点でパフォーマンス云々言うのは筋違いかなと思うところではありますが。（笑）
で、論理ボリュームにこの「物理エクステンド」を何個割り当てます…みたいな指定をやることで、ようやくファイルシステムをそこに作成できるようになるわけです。
今回は8個全てのディスクを「がっちゃんこ」して1個の広大な領域にしたいので、1個の論理ボリュームに全ての物理エクステンドを割り当てることになります。
使用するコマンドは lvcreate です。「-l」オプションと「-n」オプションを併用します。「-l」オプションに続けて使用する物理エクステンドの個数を、「-n」オプションに続けて論理ボリュームの名前を指定します。最後に切り出す元となるボリュームグループ名です。なお、「-n」オプションを省略するとデフォルトで変な名前が割り当てられます。別にそっちでも構わないのですがね。
今回の例でいくとこんな具合になる訳ですな。これで、論理ボリュームが作成されました。
この論理ボリュームに対して、ファイルシステムを作成したり、マウントしたりする訳ですが、デバイス名の組み立て方としては…
/dev/（ボリュームグループ名)/（論理ボリューム名)
ということになります。今回の場合は、ボリュームグループ名に「lvtera」、論理ボリューム名に「lva」と名前を付けたので、「/dev/lvtera/lva」というデバイス名が付くことになります。
ステップ４：あとはもうファイルシステムを作成してマウントしる。
あとはもう詳しく説明するのもアレなんですが、mke2fs -j /dev/lvtera/lva して、tune2fs -c 0 -i 0 /dev/lvtera/lva して、お好みに応じてe2label /dev/lvtera/lva DATAAREA とかやってからmkdir -p /mnt/mountpoint でマウントポイントを適宜作成してmount /dev/lvteta/lva /mnt/mountpoint とかやるよろしね。
これで、4.5TBの領域がウヒヒヒヒ…
まあ、もう実際に使用しているので容量がアレですが以下略。
なお、こんな場末なblogの落書きを見てしまった識者の方で指摘とかツッコミとかありましたらコメントよろしこです。
HDDがアフォみたいに安くなってくる一方で、動画ファイルとか使う方もサイズがでっかくなってくるので、「ニコイチ」とか「ヨンコイチ」とかああいうディスクケースを使ったりRAIDしたりする訳ですが、特にUSBのHDDを使い出すと、だんだんPCにディスクが「鈴なり」状態に、ディスクスペースが細切れ状態になってきて微妙にもったいなかったり、使いづらかったりする訳ですよ。
で、そこで複数のディスクをガッチャンコしちゃおうという目的でLinuxでLVMしちまおう…ということでこのエントリーとあいなった訳ですよ。
基本路線としては、
・LinuxでSambaな環境を構築して、Windowsには「ネットワークドライブ」という形で見せよう
・ネットワークドライブがいっぱいになるのはかんべんな
・バックアップとか考えると頭が痛くなるので、本当ならRAID5とかしたい訳だが、失業した古いHDDを再利用してでっかいディスクとして見せたいので、「壊れたら壊れたであきらめる」前提とする（ちゃんと守りたいデータは新しいディスクを買ってきてRAIDしる！）
ということで。
なお、当方の環境の都合上話は全てCentOS5.2とかその辺の上で進行しますので念のため。
で、lvmを使うにはおおざっぱにいって3段階の手順とか必要になる。
①ハードディスクに「物理ボリューム」を作成する。
→まずは全部のハードディスクに物理ボリュームを作成することになる
②作成した物理ボリュームを、「ボリュームグループ」に登録する。
→この「ボリュームグループ」は「1個の巨大なハードディスク」みたいな感じに見えることになる。
③複数の物理ボリュームが登録されたボリュームグループから、必要に応じて「論理ボリューム」を切り出す。
→ボリュームグループは「1個の巨大なハードディスク」なら、「物理ボリューム」は「パーティション」に相当すると考えるとよろし。今回のような目的で使うなら、「1個のハードディスクに1個のパーティション」みたいな感じになるですよ。
これ以降は、普通にファイルシステムを作成してマウントして使えるですよ。
これだけならまあRAID0したり「テラタワー」みたいな製品を使えばいいじゃんということになるんだろうけども、lvmにしておけば…
メリット１：あとからハードディスクを追加して、ボリュームグループとか論理ボリュームを大きくできる
メリット２：ディスクの「交換」にも割と柔軟に対応できる（ダメな時はダメぽ…ということもあるけどなー）
メリット３：SASだろうとSATAだろうとUSBなHDDだろうとお構いなしに全部「がっちゃんこ」できる
要するに、RAIDよりもずーっと敷居が低い訳ですよ。いろんな意味で。（特に資金的にも！）まあ、その分、RAID1とかRAID5とかのようにファイルをがっちり守るとかはちょっとアレな面も。（lvmでミラーリングもできるけどなー）
そんな訳で、lvm構築方法を以下に書き殴っておく。
ステップ０：準備・lvmに必要なパッケージは入っているかな？＆ディスクをつなごう～！
おそらく、普通にCentOSをセットアップしておけば標準で入ってくるような気がする今日この頃ですが、パッケージは入っているかな？チェックしてみませう。
[root@server1 root]# pvdisplay --version LVM version: 2.02.28 (2007-08-24) Library version: 1.02.22 (2007-08-21) Driver version: 4.5.0
コマンドが入っててLVM versionの表示が２以降なら多分問題ない希ガス。必要なパッケージは…
[root@server1 root]# rpm -qa | fgrep lvm lvm2-2.02.28-0vl0.1
入ってない場合は、yumでさくっと入れてしまいませう。
[root@server2 ~]# yum search lvm Loading "fastestmirror" plugin Loading mirror speeds from cached hostfile * base: ftp.iij.ad.jp * updates: ftp.iij.ad.jp * addons: ftp.iij.ad.jp * extras: ftp.iij.ad.jp lvm2.i386 : ユーザーランド論理ボリューム管理ツール system-config-lvm.noarch : A utility for graphically configuring Logical Volumes lvm2.i386 : Userland logical volume management tools lvm2-cluster.i386 : Cluster extensions for userland logical volume management tools
ということなので、
[root@server2 ~]# yum install lvm2.i386
ですな。なお、Vineなお友達は…
[root@server1 root]# apt-cache search lvm lvm2 - 論理ボリューム管理ツール lvm - Linux Logical Volume Manager utilities. ocaml - Objective Caml コンパイラとプログラミング環境
つーことなので
[root@server1 root]# apt-get install lvm2
とするよろし。
で、ディスクをざくざく接続するですよ。OSから認識できているディスクについてはdmesgで確認するとか/proc/partitionsを見るとかしませう。
[root@server1 root]# cat /proc/partitions major minor #blocks name 8 0 312570167 sda 8 1 104391 sda1 8 2 312464250 sda2 8 16 976762584 sdb 8 17 976760001 sdb1 8 32 312571224 sdc 8 33 2040223 sdc1 8 34 310528417 sdc2 8 48 976762584 sdd 8 49 976760001 sdd1 8 64 976762584 sde 8 65 976760001 sde1 8 80 976762584 sdf 8 81 976760001 sdf1 9 0 2930279808 md0 8 96 976762584 sdg 8 97 976760001 sdg1 8 112 976762584 sdh 8 113 976760001 sdh1 8 128 976762584 sdi 8 129 976760001 sdi1 8 144 976762584 sdj 8 145 976760001 sdj1 8 160 245117376 sdk 8 161 245111706 sdk1 8 176 245117376 sdl 8 177 245111706 sdl1 8 192 245117376 sdm 8 193 245111706 sdm1 8 208 245117376 sdn 8 209 245111706 sdn1 253 0 4887461888 dm-0 8 224 1464845256 sdo 8 225 1464838798 sdo1
まあ、健全なパソコンオタクちゃんならこれくらいはディスクが鈴なりになっているんじゃなかろうかと思います。健全でない「マル廃」なオタクちゃんの場合はきっと「すげー高級なRAIDカード」とか使っていそうなのでそういう「マル廃本仕込み」なオタクちゃんはどっか他いくよろし。
ちなみにこのマシンの場合、sdaとsdcがマザボに接続されているHDD、sdoはRAID5なUSB-HDD（具体的にはバッキャローのUSBなアレ）で今回「がっちゃんこ」する対象外。md0はLinuxのソフトウェアRAIDなデバイスで、sdf、sde、sdd、sdbを4本束ねてRAID5してるので、これも今回の「がっちゃんこ」する対象外。
そんな訳で、sdg、sdh、sdi、sdj、sdk、sdl、sdm、sdnの８本がlvmで「がっちゃんこ」される対象となるですよ。
では、さっそく「がっちゃんこ」してまいります。
ステップ１：ハードディスクに「物理ボリューム」を作成する
えーと、本当はいらないんだけど、私はコレを省略するとどーしても気持ちが悪いのでやってますが、よい子のみんなはやってもやらなくてもどっちでもいいお。
それぞれのディスクにパーティションを切ります。おきまりの「fdisk」ですな。（サンプル中のデバイス名は適宜読み替えよう。）
[root@server1 root]# fdisk /dev/sdg このディスクのシリンダ数は 121601 に設定されています。 間違いではないのですが、1024 を超えているため、以下の場合 に問題を生じうる事を確認しましょう: 1) ブート時に実行するソフトウェア (例. バージョンが古い LILO) 2) 別の OS のブートやパーティション作成ソフト (例. DOS FDISK, OS/2 FDISK) コマンド (m でヘルプ): p Disk /dev/sdg: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sdg1 1 121601 976760001 8e Linux LVM コマンド (m でヘルプ):
１個のハードディスクを丸ごと１個のパーティションにしておいて、パーティションのIDを変更します。「n」して「t」して「8e」にして「w」すればオッケーです。（リサイクルだという場合は最初に「d」してくだちい。）何のことかさっぱりわからんという人はお帰りください。
lvmで「がっちゃんこ」したい全てのディスクにLinuxLVMのパーティションを作成したら、いよいよlvmの操作に入ります。
lvmの「物理ボリューム」の作成には pvcreate コマンドを使います。基本形としては…
[root@server1 root]# pvcreate /dev/sdg1
です。いちいちコマンド8回も実行するのは面倒くさいので
[root@server1 root]# pvcreate /dev/sd[g-n]1
とでもしておけば8本全部に物理ボリュームが作成されるですよ。
物理ボリュームが作成されたかどうかチェックするには pvdisplay コマンド。
[root@server1 root]# pvdisplay -v /dev/sdg1
Using physical volume(s) on command line
Wiping cache of LVM-capable devices
--- Physical volume ---
PV Name /dev/sdg1
VG Name vgtera
PV Size 931.51 GB / not usable 3.19 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 238466
Free PE 0
Allocated PE 238466
PV UUID abEiuq-JRcs-3AOl-qxEB-BP8k-QSmx-8YxlUA
すでにこのサーバではLVMでボリュームを作成してあるのでFree PEが０になってますが、作成したばっかりの状態だとFree PEになんらかの数値が入っていることでせう。VG Nameも表示されなはずですお。
ステップ２：作成した物理ボリュームを、「ボリュームグループ」に登録する。
複数ある「物理ボリューム」を「ボリュームグループ」に登録して、「1個の巨大なハードディスクのようなもの」を作成します。
このボリュームグループには何か分かり易そうな名前を付けておきます。で、使用するコマンドは vgcreate です。引数として、「ボリュームグループ名」と「登録する物理ボリュームのデバイス名」を続けて書きます。
今回の例として、「ボリュームグループ名」に「vgtera」と名前を付けることにします。
[root@server1 root]# vgcreate vgtera /dev/sdg1
なんてことになりますが、最初から複数の物理ボリュームを追加しつつ新規作成できますので、その場合は物理ボリュームのデバイス名を書き並べることになります。
[root@server1 root]# vgcreate vgtera /dev/sdg1 /dev/sdx1 /dev/sdy1
たとえば↑こんな感じ。ちなみに今回のケースだと
[root@server1 root]# vgcreate vgtera /dev/sd[g-n]1
と、なる訳です。
ちなみに、「初めてだから1個だけ登録してみた～」とか「やっう゛ぇー。デバイス名書き忘れてしまった～」みたいな場合は、 vgextend コマンドで既存のボリュームグループに物理ボリュームを追加します。
[root@server1 root]# vgextend vgtera /dev/sdz1
とかこんな感じで。
ディスクが「がっちゃんこ」された様子を見たい場合は、 vgdisplay コマンドで表示されます。
[root@server1 root]# vgdisplay vgtera --- Volume group --- VG Name vgtera System ID Format lvm2 Metadata Areas 8 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 1 Max PV 0 Cur PV 8 Act PV 8 VG Size 4.55 TB PE Size 4.00 MB Total PE 1193228 Alloc PE / Size 1193228 / 4.55 TB Free PE / Size 0 / 0 VG UUID RBEJZT-k2Vo-AKtl-OIYq-imHx-gnca-RDbvUU
↑上記の例だと、すでにlvmが以下略なのでFree PE/Sizeが以下略ですが、ボリュームグループを作成した直後の場合は以下略。
なお、コマンドにボリュームグループ名「vgtera」を付けてますが、これを省略するとそのマシンで作成されている全てのボリュームグループの情報が表示されます。また、「-v」オプションを付けると登録されている物理ボリュームの情報とかも全て表示されます。
[root@server1 root]# vgdisplay -v vgtera
Using volume group(s) on command line
Finding volume group "vgtera"
--- Volume group ---
VG Name vgtera
System ID
Format lvm2
Metadata Areas 8
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 8
Act PV 8
VG Size 4.55 TB
PE Size 4.00 MB
Total PE 1193228
Alloc PE / Size 1193228 / 4.55 TB
Free PE / Size 0 / 0
VG UUID RBEJZT-k2Vo-AKtl-OIYq-imHx-gnca-RDbvUU
--- Logical volume ---
LV Name /dev/vgtera/lva
VG Name vgtera
LV UUID suPCyY-vhXr-ptAP-sQph-TZFY-8msV-Km4cJa
LV Write Access read/write
LV Status available
# open 1
LV Size 4.55 TB
Current LE 1193228
Segments 8
Allocation inherit
Read ahead sectors 0
Block device 253:0
--- Physical volumes ---
PV Name /dev/sdg1
PV UUID abEiuq-JRcs-3AOl-qxEB-BP8k-QSmx-8YxlUA
PV Status allocatable
Total PE / Free PE 238466 / 0
PV Name /dev/sdh1
PV UUID ztiGC4-cO3A-He3a-2f2x-Dz82-qBPY-Imc45D
PV Status allocatable
Total PE / Free PE 238466 / 0
PV Name /dev/sdi1
PV UUID Sz7dZh-LkUM-ltYw-gKaY-PKn8-PpMY-La3TGa
PV Status allocatable
Total PE / Free PE 238466 / 0
PV Name /dev/sdj1
PV UUID FNhgGT-22dc-W0HJ-qDYQ-ye3L-SEG6-hn4XEi
PV Status allocatable
Total PE / Free PE 238466 / 0
PV Name /dev/sdk1
PV UUID mLw2JO-emCp-3auI-if98-cw4u-e82r-6znQ5D
PV Status allocatable
Total PE / Free PE 59841 / 0
PV Name /dev/sdl1
PV UUID lDPisv-2kgJ-kt32-OLeZ-V4uo-3Eqx-lG1rv1
PV Status allocatable
Total PE / Free PE 59841 / 0
PV Name /dev/sdm1
PV UUID UjFfgA-XQgx-6xvl-PJ1m-aalI-HkIo-pv2kBB
PV Status allocatable
Total PE / Free PE 59841 / 0
PV Name /dev/sdn1
PV UUID Pp0EZz-2dNy-y5G3-Y92a-UZ7H-5pMA-RyM9rA
PV Status allocatable
Total PE / Free PE 59841 / 0
↑上記の例だと、すでにlvmが以下略なので論理ボリュームの情報が表示されていたり以下略ですが新規に作成したばっかりの状態だと以下略。
ステップ３：複数の物理ボリュームが登録されたボリュームグループから、必要に応じて「論理ボリューム」を切り出す。
ここまでで、ディスク８本を「がっちゃんこ」して約4.5TBのでっかい領域が作成されてニヨニヨしてますが、これではまだ不完全で、ここから「論理ボリューム」を作成します。
さきほと vgdisplay コマンドで…
Total PE 1193228
という表示があったと思う。この「PE」という物は「物理エクステンド」という物で、ボリュームグループをデフォルトで4MB単位のブロックに区切り、そのブロックの個数を示しています。この物理エクステンドのサイズは変更することが出来るのだけども、ぶっちゃけ、lvm2を使っている限りあんまり意味はないです。
大きくするとディスク容量の端数が無駄になりやすいとかあったり、小さくすると物理エクステンドの個数がやたら多くなってパフォーマンスが低下するとかありますが、まあ、USB-HDDを使ってる時点でパフォーマンス云々言うのは筋違いかなと思うところではありますが。（笑）
で、論理ボリュームにこの「物理エクステンド」を何個割り当てます…みたいな指定をやることで、ようやくファイルシステムをそこに作成できるようになるわけです。
今回は8個全てのディスクを「がっちゃんこ」して1個の広大な領域にしたいので、1個の論理ボリュームに全ての物理エクステンドを割り当てることになります。
使用するコマンドは lvcreate です。「-l」オプションと「-n」オプションを併用します。「-l」オプションに続けて使用する物理エクステンドの個数を、「-n」オプションに続けて論理ボリュームの名前を指定します。最後に切り出す元となるボリュームグループ名です。なお、「-n」オプションを省略するとデフォルトで変な名前が割り当てられます。別にそっちでも構わないのですがね。
[root@server1 root]# lvcreate -l 1193228 -n lva vgtera
今回の例でいくとこんな具合になる訳ですな。これで、論理ボリュームが作成されました。
この論理ボリュームに対して、ファイルシステムを作成したり、マウントしたりする訳ですが、デバイス名の組み立て方としては…
/dev/（ボリュームグループ名)/（論理ボリューム名)
ということになります。今回の場合は、ボリュームグループ名に「lvtera」、論理ボリューム名に「lva」と名前を付けたので、「/dev/lvtera/lva」というデバイス名が付くことになります。
ステップ４：あとはもうファイルシステムを作成してマウントしる。
あとはもう詳しく説明するのもアレなんですが、mke2fs -j /dev/lvtera/lva して、tune2fs -c 0 -i 0 /dev/lvtera/lva して、お好みに応じてe2label /dev/lvtera/lva DATAAREA とかやってからmkdir -p /mnt/mountpoint でマウントポイントを適宜作成してmount /dev/lvteta/lva /mnt/mountpoint とかやるよろしね。
これで、4.5TBの領域がウヒヒヒヒ…
[root@server root]# df -h
ファイルシステム サイズ 使用 残り 使用% マウント位置
/dev/sda2 294G 4.3G 275G 2% /
（見せられないよ！ ＞＜）
/dev/mapper/vgtera-lva
4.5T 3.1T 1.4T 69% /mnt/mountpoint
（見せられないよ ＞＜）
まあ、もう実際に使用しているので容量がアレですが以下略。
なお、こんな場末なblogの落書きを見てしまった識者の方で指摘とかツッコミとかありましたらコメントよろしこです。
ぴろりん さん
-
nice! 18
記事 143
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
