mdadmでソフトRAIDを領域縮小してみる その２（RAID 5編） [Linux(LVM/RAID/Storage)]
結論から行くと、RAID5のアレイの縮小には成功しなかった。これは私の知識が足りないだけかもしれないので、絶対に出来ないのか？と聞かれても「Ｙｅｓ」とは答えられないところではあるけどね。
--growオプションでディスクの本数を減らす方法は「その１」で失敗したとおり。
次に、「--grow --size」でサイズを縮小してからディスクの本数を減らす方法も試したが、ダメだった。そもそもサイズの縮小が出来なかった。
私のつたない英語力でman mdadmを読んでみた感じでは、「--growオプションで--sizeオプションを使用できるのは、その時点でのアレイサイズが最大サイズよりも小さい場合に限られる」ようであった。ということは、最大サイズからの縮小はできないと理解するのが正解なんだろうか。
とにかくよく判らなかったので、あとは識者の方のアドバイスを請いたいところである。
そんな訳で、領域縮小は失敗～♪
--growオプションでディスクの本数を減らす方法は「その１」で失敗したとおり。
次に、「--grow --size」でサイズを縮小してからディスクの本数を減らす方法も試したが、ダメだった。そもそもサイズの縮小が出来なかった。
私のつたない英語力でman mdadmを読んでみた感じでは、「--growオプションで--sizeオプションを使用できるのは、その時点でのアレイサイズが最大サイズよりも小さい場合に限られる」ようであった。ということは、最大サイズからの縮小はできないと理解するのが正解なんだろうか。
とにかくよく判らなかったので、あとは識者の方のアドバイスを請いたいところである。
そんな訳で、領域縮小は失敗～♪
mdadmでソフトRAIDを領域縮小してみる その１（RAID 5編） [Linux(LVM/RAID/Storage)]
はい。領域を拡張したなら、今度は縮小してみたくなるのが世の常というもの。そんな訳で、RAIDアレイの縮小をやってみた。
容量を指定して縮小するか、アレイを構成するディスクをアレイから引っこ抜くか、2通りの方法があるようだけども、おそらく前者のやり方は使い道がないと思われるので、アレイを構成するディスクを減らす方向でトライしてみることとした。
まずはアレイの状態を確認するところから。RAID 5のアレイを5本のディスクで構成している。
で、これを4本のディスクを構成するように変更した上で、ちゃんと状態がcleanになっているかどうかチェックしてみる。（単に1本引っこ抜くだけなら、デグレード状態にしてしまうという手もある。が、それでは耐障害性が無いのでRAID 5の意味がない）
おそらく、コマンドは「mdadm --grow /dev/md0 --raid-disks=4」じゃないかと思われ。
レッツトライ！
なんか違うらしい。
じゃあ、ディスク1本にダメポマークを付けてデグレード状態にしてみて、そこからディスクさっきのコマンドを実行してみるとどうなるか？
まずはここまでで本来5本のディスクで動作しているはずのRAIDアレイが4本で稼働状態になっている。ただ、このままではパリティデータからデータを逆算しながらの動作になっているし、そもそもこの状態からさらに1本ディスクが飛んだら全てダメになってしまう。
ここでさっきのコマンドをもう一度試してみよう。
やはりダメらしい。
RAIDのリビルドに154分もかかるらしいので、この続きはまた明日（以降）ということで。。。。（笑）
容量を指定して縮小するか、アレイを構成するディスクをアレイから引っこ抜くか、2通りの方法があるようだけども、おそらく前者のやり方は使い道がないと思われるので、アレイを構成するディスクを減らす方向でトライしてみることとした。
まずはアレイの状態を確認するところから。RAID 5のアレイを5本のディスクで構成している。
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Mon Nov 10 13:00:21 2008
Raid Level : raid5
Array Size : 40033536 (38.18 GiB 40.99 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Nov 10 17:04:44 2008
State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : c6f7e061:1d02572e:f8555d58:8d5c0851
Events : 0.6
Number Major Minor RaidDevice State
0 3 5 0 active sync /dev/hda5
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 3 9 4 active sync /dev/hda9
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda9[4] hda8[3] hda7[2] hda6[1] hda5[0]
40033536 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
unused devices: (none)
で、これを4本のディスクを構成するように変更した上で、ちゃんと状態がcleanになっているかどうかチェックしてみる。（単に1本引っこ抜くだけなら、デグレード状態にしてしまうという手もある。が、それでは耐障害性が無いのでRAID 5の意味がない）
おそらく、コマンドは「mdadm --grow /dev/md0 --raid-disks=4」じゃないかと思われ。
レッツトライ！
# mdadm --grow /dev/md0 --raid-disks=4 mdadm: /dev/md0: Cannot reduce number of data disks (yet).
なんか違うらしい。
じゃあ、ディスク1本にダメポマークを付けてデグレード状態にしてみて、そこからディスクさっきのコマンドを実行してみるとどうなるか？
# mdadm --manage /dev/md0 --fail /dev/hda9
mdadm: set /dev/hda9 faulty in /dev/md0
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Mon Nov 10 13:00:21 2008
Raid Level : raid5
Array Size : 40033536 (38.18 GiB 40.99 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Nov 10 17:19:47 2008
State : clean, degraded
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : c6f7e061:1d02572e:f8555d58:8d5c0851
Events : 0.8
Number Major Minor RaidDevice State
0 3 5 0 active sync /dev/hda5
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 0 0 4 removed
5 3 9 - faulty spare /dev/hda9
まずはここまでで本来5本のディスクで動作しているはずのRAIDアレイが4本で稼働状態になっている。ただ、このままではパリティデータからデータを逆算しながらの動作になっているし、そもそもこの状態からさらに1本ディスクが飛んだら全てダメになってしまう。
ここでさっきのコマンドをもう一度試してみよう。
# mdadm --grow /dev/md0 --raid-disks=4 mdadm: /dev/md0: Cannot reduce number of data disks (yet).
やはりダメらしい。
RAIDのリビルドに154分もかかるらしいので、この続きはまた明日（以降）ということで。。。。（笑）
mdadmでソフトRAIDを領域拡張してみる（RAID 5編） [Linux(LVM/RAID/Storage)]
そういえば、manコマンドでmdadmの英語の説明をがんばって読んでいたら、微妙に気になる記述を発見。
Growオプションは、「アレイを大きくする（または縮小する）、か、アレイをどうにかして作り替える。現在のところ、サポートされているgrowthオプションは、適切に「write-intent bitmap」を追加か削除して、構成機器のアクティブサイズを変更することと、RAIDレベル1/4/5/6の中のアクティブデバイス数を変更する機能を含んでいる。」
と、あります。（私の非常に乏しい英語力ではそう読めた！）
ということは…
この機能を使えば、すでに稼働しているRAIDデバイスにディスクを追加してRAIDの大きさを拡張（とか縮小）できるんじゃね？と、妄想しました。
さっそくやってみた。
まず、4本のハードディスクで稼働しているRAID 5のアレイがある。ここに一旦ホットスペアとしてディスクを1本追加してみる。
4本の稼働ディスク（hda5 hda7 hda8 hda9）＋1本のホットスペアディスク（hda6）という状態になった。
私の想像通りならば、mdadm --grow コマンド（とオプション）でhda6が運用系のディスクに投入され、（RAIDのリビルドが完了した後に）アレイサイズが10Gくらい広がってウマウマなことになるんじゃないかと妄想。
オンラインヘルプを見る限りでは、「mdadm --grow /dev/md0 --raid-disks=5」と実行したらうまくいくんじゃなかろうかと思われ。
試してみた。
うまくいってるくさいよママン！
なんか、デバイス的にはうまくいってるっぽ！？
まだアレイのサイズ自体は広がっていないけども結果が分かるのは214分後みたいなので、記事の更新は来週のお楽しみに！（笑）
MDADM(8) MDADM(8)
NAME
mdadm - manage MD devices aka Linux Software RAID
SYNOPSIS
mdadm [mode] [options]
（途中省略）
Grow Grow (or shrink) an array, or otherwise reshape it in some way. Currently supported growth options
including changing the active size of component devices and changing the number of active devices in
RAID levels 1/4/5/6, as well as adding or removing a write-intent bitmap.
（以下省略）
Growオプションは、「アレイを大きくする（または縮小する）、か、アレイをどうにかして作り替える。現在のところ、サポートされているgrowthオプションは、適切に「write-intent bitmap」を追加か削除して、構成機器のアクティブサイズを変更することと、RAIDレベル1/4/5/6の中のアクティブデバイス数を変更する機能を含んでいる。」
と、あります。（私の非常に乏しい英語力ではそう読めた！）
ということは…
この機能を使えば、すでに稼働しているRAIDデバイスにディスクを追加してRAIDの大きさを拡張（とか縮小）できるんじゃね？と、妄想しました。
さっそくやってみた。
まず、4本のハードディスクで稼働しているRAID 5のアレイがある。ここに一旦ホットスペアとしてディスクを1本追加してみる。
# mdadm --manage /dev/md0 --add /dev/hda6
mdadm: added /dev/hda6
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Nov 7 20:46:12 2008
State : clean
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.546
Number Major Minor RaidDevice State
0 3 9 0 active sync /dev/hda9
1 3 5 1 active sync /dev/hda5
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 3 6 - spare /dev/hda6
4本の稼働ディスク（hda5 hda7 hda8 hda9）＋1本のホットスペアディスク（hda6）という状態になった。
私の想像通りならば、mdadm --grow コマンド（とオプション）でhda6が運用系のディスクに投入され、（RAIDのリビルドが完了した後に）アレイサイズが10Gくらい広がってウマウマなことになるんじゃないかと妄想。
オンラインヘルプを見る限りでは、「mdadm --grow /dev/md0 --raid-disks=5」と実行したらうまくいくんじゃなかろうかと思われ。
試してみた。
# mdadm --grow /dev/md0 --raid-disks=5 mdadm: Need to backup 768K of critical section.. mdadm: ... critical section passed.
うまくいってるくさいよママン！
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.91.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Nov 7 20:51:31 2008
State : clean, recovering
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Reshape Status : 1% complete
Delta Devices : 1, (4->5)
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.688
Number Major Minor RaidDevice State
0 3 9 0 active sync /dev/hda9
1 3 5 1 active sync /dev/hda5
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 3 6 4 active sync /dev/hda6
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda6[4] hda5[1] hda9[0] hda8[3] hda7[2]
30025152 blocks super 0.91 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.2% (27456/10008384) finish=214.4min speed=773K/sec
unused devices: (none)
なんか、デバイス的にはうまくいってるっぽ！？
まだアレイのサイズ自体は広がっていないけども結果が分かるのは214分後みたいなので、記事の更新は来週のお楽しみに！（笑）
mdadmでソフトRAIDにホットスペアディスクを追加してみる(RAID 5編) [Linux(LVM/RAID/Storage)]
さて。先ほど作成したり再構築したりしたRAIDアレイに、ホットスペアディスクを追加してみる。
「ホットスペアディスクってなんなのさ？」という人に簡単な解説をしておこう。先ほどまでに作成していたRAID 5のアレイ（ボリューム）は、4本のディスクを使って単独のディスク障害に耐えられるように構成していた。しかし、RAID 5にもアキレス腱となる部分があり、それはディスクが1本故障した状態で運用を継続している状況は、もはや新たなディスク障害には耐えられないということであった。
まあ、新たに2本目のディスクが故障してしまう前に、ディスクを交換して通常の運用状態に戻せば、また別のディスクが故障しても耐えることができる状態にすることはできる。
が、しかし。その2本目のディスク故障がいつ起きるのか。それは誰にも判らないものである。今週末にでも秋葉原に行って、新しいハードディスクを買ってくればいいお＾－＾なんて悠長なことを言っても、たいていの場合はまあそれでも問題になることは少ないものであるけども、残念ながらそれよりも先に別のディスクが故障してしまうケースも否定できないのである。
ではどうすべきか。ディスク障害が発生した際には可及的速やかにディスクを交換してしまうべきなのである。べきなのであるば、夜中だったり週末だったり、あるいは年末年始だったりして即座に対応できないこともありうるから、即座にディスク交換…という対応が出来ないかもしれないシチュエーションだってあり得るのである。
そんな時のために、「ホットスペアディスク」は存在するのである。
ホットスペアディスクというものは…
・普段は使用されない → マシンに接続され、通電はしているがアクセスは全くない
・RAIDのアレイで異常が生じた際に、自動的に壊れたディスクの代わりにRAIDアレイに投入され、リビルド後通常の運用体制に復帰する
と、いうものなのである。
つまり、先に交換用のディスク（スペア）を用意しておいて、いざというときに自動的に交換作業を行っちゃうというものなのである。
通常、RAIDアレイ一つに対して1本のホットスペアディスクを用意しておけばまず問題にはならない…と言われている。まあ、健全なパソコンオタクちゃんがそこまで必要とするか…と聞かれるとちょっと答えに窮するところではあるけれども。（笑）いざというときの安心料をとるか、ディスクを遊ばせておくのはもったいないととるか、それは使用する人の使い方とか考え方とか経済状況とかにもよるので一概にはなんとも言えないなあ。
それでは、先ほどのRAIDアレイにホットスペアディスクを追加してみる。ちなみに、ホットスペアディスクを追加しても、RAIDのリビルドは全く発生しないので、追加作業はサクッと完了する。
まずは、RAIDの状態から。
先ほどまでいじって遊んだRAIDの情報のまんまである。hda6～hda9の4本のディスクで構成されている。ここに、ホットスペアディスクディスクとして、さきほど撤去してしまったhda5をホットスペアディスクとして追加することにする。
使用するコマンドはやはり「mdadm」。「mdadm --manage RAIDデバイス名 --add ホットスペアとして追加するディスクデバイス名」という感じで。
こんだけ。はい。もう完了しましたよっと。
RAIDの情報を確認してみると…
/dev/hda5がホットスペアとしてちゃんと登録されていることがこれで判ります。
それじゃさっそく、ディスクが壊れた際にホットスペアディスクが自動的に運用ディスクに組み込まれることを確認してみよう。
前回と同じように、現在運用しているディスクに「だめぽマーク」を付けてみる。ここでは/dev/hda6が壊れた（ことにする）ディスクに見立てる。
これで、/dev/hda6が故障した（ことになる）ので、ホットスペアディスクが自動的に運用ディスクとして稼働を開始するはず。確認してみる。
/dev/hda6が故障扱いに、さきほどホットスペアディスクとして追加した/dev/hda5が運用系ディスクとして実際に組み込まれ、RAIDのリビルドが実施されているのがこれで判る。136分ほどかかるという訳ですな。
そんな訳で、ホットスペアディスクがあることでディスク交換作業待ちの時間の脆弱性がフォローされるということになる訳。ホットスペアディスクの交換なら、今週末にでも秋葉原に出かけてディスクを購入してくれば良い訳だしね。
つーわけで、次なる実験は、このRAIDのリビルドが終了する136分後ということで…（笑）
「ホットスペアディスクってなんなのさ？」という人に簡単な解説をしておこう。先ほどまでに作成していたRAID 5のアレイ（ボリューム）は、4本のディスクを使って単独のディスク障害に耐えられるように構成していた。しかし、RAID 5にもアキレス腱となる部分があり、それはディスクが1本故障した状態で運用を継続している状況は、もはや新たなディスク障害には耐えられないということであった。
まあ、新たに2本目のディスクが故障してしまう前に、ディスクを交換して通常の運用状態に戻せば、また別のディスクが故障しても耐えることができる状態にすることはできる。
が、しかし。その2本目のディスク故障がいつ起きるのか。それは誰にも判らないものである。今週末にでも秋葉原に行って、新しいハードディスクを買ってくればいいお＾－＾なんて悠長なことを言っても、たいていの場合はまあそれでも問題になることは少ないものであるけども、残念ながらそれよりも先に別のディスクが故障してしまうケースも否定できないのである。
ではどうすべきか。ディスク障害が発生した際には可及的速やかにディスクを交換してしまうべきなのである。べきなのであるば、夜中だったり週末だったり、あるいは年末年始だったりして即座に対応できないこともありうるから、即座にディスク交換…という対応が出来ないかもしれないシチュエーションだってあり得るのである。
そんな時のために、「ホットスペアディスク」は存在するのである。
ホットスペアディスクというものは…
・普段は使用されない → マシンに接続され、通電はしているがアクセスは全くない
・RAIDのアレイで異常が生じた際に、自動的に壊れたディスクの代わりにRAIDアレイに投入され、リビルド後通常の運用体制に復帰する
と、いうものなのである。
つまり、先に交換用のディスク（スペア）を用意しておいて、いざというときに自動的に交換作業を行っちゃうというものなのである。
通常、RAIDアレイ一つに対して1本のホットスペアディスクを用意しておけばまず問題にはならない…と言われている。まあ、健全なパソコンオタクちゃんがそこまで必要とするか…と聞かれるとちょっと答えに窮するところではあるけれども。（笑）いざというときの安心料をとるか、ディスクを遊ばせておくのはもったいないととるか、それは使用する人の使い方とか考え方とか経済状況とかにもよるので一概にはなんとも言えないなあ。
それでは、先ほどのRAIDアレイにホットスペアディスクを追加してみる。ちなみに、ホットスペアディスクを追加しても、RAIDのリビルドは全く発生しないので、追加作業はサクッと完了する。
まずは、RAIDの状態から。
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 17:07:58 2008
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.540
Number Major Minor RaidDevice State
0 3 9 0 active sync /dev/hda9
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda9[0] hda8[3] hda7[2] hda6[1]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices: (none)
先ほどまでいじって遊んだRAIDの情報のまんまである。hda6～hda9の4本のディスクで構成されている。ここに、ホットスペアディスクディスクとして、さきほど撤去してしまったhda5をホットスペアディスクとして追加することにする。
使用するコマンドはやはり「mdadm」。「mdadm --manage RAIDデバイス名 --add ホットスペアとして追加するディスクデバイス名」という感じで。
# mdadm --manage /dev/md0 --add /dev/hda5 mdadm: added /dev/hda5
こんだけ。はい。もう完了しましたよっと。
RAIDの情報を確認してみると…
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 17:07:58 2008
State : clean
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.540
Number Major Minor RaidDevice State
0 3 9 0 active sync /dev/hda9
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 3 5 - spare /dev/hda5
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda5[4](S) hda9[0] hda8[3] hda7[2] hda6[1]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices: (none)
/dev/hda5がホットスペアとしてちゃんと登録されていることがこれで判ります。
それじゃさっそく、ディスクが壊れた際にホットスペアディスクが自動的に運用ディスクに組み込まれることを確認してみよう。
前回と同じように、現在運用しているディスクに「だめぽマーク」を付けてみる。ここでは/dev/hda6が壊れた（ことにする）ディスクに見立てる。
# mdadm --manage /dev/md0 --fail /dev/hda6 mdadm: set /dev/hda6 faulty in /dev/md0
これで、/dev/hda6が故障した（ことになる）ので、ホットスペアディスクが自動的に運用ディスクとして稼働を開始するはず。確認してみる。
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 19:40:52 2008
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 1
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Rebuild Status : 0% complete
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.542
Number Major Minor RaidDevice State
0 3 9 0 active sync /dev/hda9
4 3 5 1 spare rebuilding /dev/hda5
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
5 3 6 - faulty spare /dev/hda6
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda5[4] hda9[0] hda8[3] hda7[2] hda6[5](F)
30025152 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
[>....................] recovery = 0.0% (6016/10008384) finish=136.6min speed=1203K/sec
unused devices: (none)
/dev/hda6が故障扱いに、さきほどホットスペアディスクとして追加した/dev/hda5が運用系ディスクとして実際に組み込まれ、RAIDのリビルドが実施されているのがこれで判る。136分ほどかかるという訳ですな。
そんな訳で、ホットスペアディスクがあることでディスク交換作業待ちの時間の脆弱性がフォローされるということになる訳。ホットスペアディスクの交換なら、今週末にでも秋葉原に出かけてディスクを購入してくれば良い訳だしね。
つーわけで、次なる実験は、このRAIDのリビルドが終了する136分後ということで…（笑）
mdadmで作ったソフトRAIDを壊してみる(RAID 5編) [Linux(LVM/RAID/Storage)]
おまちどうさまでした。（笑）昨日作成したRAID 5のボリュームのリビルドが完成しましたので、これでこのボリュームのデータは、ディスクの障害からは守られるはずです。
まずはおさらいがてら、RAID5のボリュームの状態とかみておきます。
/mnt/workにマウントされている、/dev/md0というデバイスが、4本のディスクでRAID 5を構成しているデバイスになります。ここはディスク1本飛んだくらいではヘコたれないはずです。
今はまだカラッポでつまらないので、「/etc」の下あたりをまるっとコピーしてみましょうか。
ちなみに、/proc/mdstatの中身よりもさらに詳細な情報を見たいという場合は、「mdadm」コマンドに「--misc --detail」オプションを付けて実行してみます。
それでは、この状態で/dev/hda5が壊れたことを想定してみることに。RAIDが動作し、また正常にアクセスできてるっぽい状態が確保されているかどうか、検証してみる。ボリュームへのアクセスが継続できていることを調べるため、別のターミナルから（ちょっとアンチョクだけども）「cd /mnt/work/etc;while :;do find . -print;done」とかやっておいて、この状態でRAIDへの操作を行う。
では、/dev/hda5に対して、mdadmコマンドにて「故障マーク」を付けてみる。
これで、4本のディスクで構築していたRAID5のボリュームは3本のディスクで運用状態を継続していることとなった。さっき、別のターミナルで実行していたfind コマンドの無限ループは、相変わらずダーっと表示を継続していることから、一応何事もなかったかのように使用できているということが判る。
それでは、故障した（ことにした）/dev/hda5をRAIDのアレイから撤去することにする。やはり「mdadm」コマンドを使用する。ディスクをRAIDアレイから撤去するには、「mdadm --manage RAIDデバイス名 --remove 引き抜くディスクのデバイス名」を実行する。
これで、壊れた（ことにした）/dev/hda5はアレイから撤去されたことに。チェックしてみる。
確かに/dev/hda5がいなくなっていることが判る。
これらの操作を行ったにもかかわらず、別ターミナルから実行しているfindコマンドの無限ループは相変わらず快調に動作している。
では、このRAIDデバイスを本来の4本のディスクで運用する状態に復元する。（要するに新しいディスクを突っ込むってことね）「mdadm --manage RAIDデバイス名 --add 新たに追加するディスクのデバイス名」を実行すればオッケー。
ここでは、さきほど壊れた（ことにした）/dev/hda5の代わりに、/dev/hda9を新しいディスクとしてアレイに投入している。この状態でRAIDアレイのリビルドが動き出す。状態を見てみると…
という訳で、これから153分ほどかけてRAID 5のリビルドが行われるということが判る。なお、この状態でもなお、別ターミナルで実行しているfindコマンドの無限ループは快調に動作していて、運用状態が確保されていることがわかる。
なお、今この状態（RAIDのリビルドが走っている状態）で別のディスクが故障した場合はオワタ＼（＾○＾）／オワタということになるので要注意！
まずはおさらいがてら、RAID5のボリュームの状態とかみておきます。
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda8[3] hda7[2] hda6[1] hda5[0]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices: (none)
# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda2 9.7G 1.7G 7.6G 18% /
/dev/hda1 99M 11M 83M 12% /boot
tmpfs 252M 0 252M 0% /dev/shm
/dev/md0 29G 173M 27G 1% /mnt/work
/mnt/workにマウントされている、/dev/md0というデバイスが、4本のディスクでRAID 5を構成しているデバイスになります。ここはディスク1本飛んだくらいではヘコたれないはずです。
今はまだカラッポでつまらないので、「/etc」の下あたりをまるっとコピーしてみましょうか。
# mkdir /mnt/work/etc # cp -r /etc/* /mnt/work/etc # ls -la /mnt/work/etc 合計 2148 drwxr-xr-x 80 root root 4096 11月 6 12:27 . drwxr-xr-x 4 root root 4096 11月 6 12:27 .. -rw-r--r-- 1 root root 2518 11月 6 12:27 DIR_COLORS -rw-r--r-- 1 root root 2420 11月 6 12:27 DIR_COLORS.xterm drwxr-xr-x 2 root root 4096 11月 6 12:27 NetworkManager drwxr-xr-x 7 root root 4096 11月 6 12:27 X11 drwxr-xr-x 4 root root 4096 11月 6 12:27 acpi -rw-r--r-- 1 root root 46 11月 6 12:27 adjtime -rw-r--r-- 1 root root 1512 11月 6 12:27 aliases -rw-r----- 1 root root 12288 11月 6 12:27 aliases.db ：：：
ちなみに、/proc/mdstatの中身よりもさらに詳細な情報を見たいという場合は、「mdadm」コマンドに「--misc --detail」オプションを付けて実行してみます。
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 12:52:26 2008
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.8
Number Major Minor RaidDevice State
0 3 5 0 active sync /dev/hda5
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
それでは、この状態で/dev/hda5が壊れたことを想定してみることに。RAIDが動作し、また正常にアクセスできてるっぽい状態が確保されているかどうか、検証してみる。ボリュームへのアクセスが継続できていることを調べるため、別のターミナルから（ちょっとアンチョクだけども）「cd /mnt/work/etc;while :;do find . -print;done」とかやっておいて、この状態でRAIDへの操作を行う。
では、/dev/hda5に対して、mdadmコマンドにて「故障マーク」を付けてみる。
# mdadm --manage /dev/md0 --fail /dev/hda5
mdadm: set /dev/hda5 faulty in /dev/md0
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 13:39:02 2008
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 1
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.12
Number Major Minor RaidDevice State
0 0 0 0 removed
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
4 3 5 - faulty spare /dev/hda5
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda5[4](F) hda8[3] hda7[2] hda6[1]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
unused devices: (none)
これで、4本のディスクで構築していたRAID5のボリュームは3本のディスクで運用状態を継続していることとなった。さっき、別のターミナルで実行していたfind コマンドの無限ループは、相変わらずダーっと表示を継続していることから、一応何事もなかったかのように使用できているということが判る。
それでは、故障した（ことにした）/dev/hda5をRAIDのアレイから撤去することにする。やはり「mdadm」コマンドを使用する。ディスクをRAIDアレイから撤去するには、「mdadm --manage RAIDデバイス名 --remove 引き抜くディスクのデバイス名」を実行する。
# mdadm --manage /dev/md0 --remove /dev/hda5 mdadm: hot removed /dev/hda5
これで、壊れた（ことにした）/dev/hda5はアレイから撤去されたことに。チェックしてみる。
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 14:01:18 2008
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.110
Number Major Minor RaidDevice State
0 0 0 0 removed
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda8[3] hda7[2] hda6[1]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
unused devices: (none)
確かに/dev/hda5がいなくなっていることが判る。
これらの操作を行ったにもかかわらず、別ターミナルから実行しているfindコマンドの無限ループは相変わらず快調に動作している。
では、このRAIDデバイスを本来の4本のディスクで運用する状態に復元する。（要するに新しいディスクを突っ込むってことね）「mdadm --manage RAIDデバイス名 --add 新たに追加するディスクのデバイス名」を実行すればオッケー。
# mdadm --manage /dev/md0 --add /dev/hda9 mdadm: added /dev/hda9
ここでは、さきほど壊れた（ことにした）/dev/hda5の代わりに、/dev/hda9を新しいディスクとしてアレイに投入している。この状態でRAIDアレイのリビルドが動き出す。状態を見てみると…
# mdadm --misc --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Wed Nov 5 15:51:20 2008
Raid Level : raid5
Array Size : 30025152 (28.63 GiB 30.75 GB)
Used Dev Size : 10008384 (9.54 GiB 10.25 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Nov 6 15:03:59 2008
State : clean, degraded, recovering
Active Devices : 3
Working Devices : 4
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Rebuild Status : 0% complete
UUID : 22eea7b2:c6461c41:bbe89505:7e45ea96
Events : 0.370
Number Major Minor RaidDevice State
4 3 9 0 spare rebuilding /dev/hda9
1 3 6 1 active sync /dev/hda6
2 3 7 2 active sync /dev/hda7
3 3 8 3 active sync /dev/hda8
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda9[4] hda8[3] hda7[2] hda6[1]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
[>....................] recovery = 0.1% (14080/10008384) finish=153.5min speed=1083K/sec
unused devices: (none)
という訳で、これから153分ほどかけてRAID 5のリビルドが行われるということが判る。なお、この状態でもなお、別ターミナルで実行しているfindコマンドの無限ループは快調に動作していて、運用状態が確保されていることがわかる。
なお、今この状態（RAIDのリビルドが走っている状態）で別のディスクが故障した場合はオワタ＼（＾○＾）／オワタということになるので要注意！
mdadmでソフトRAIDを構築してみる（RAID 5編） [Linux(LVM/RAID/Storage)]
というわけで、RAID 5のボリュームを作成して、いろいろとアレなことをしてみよう。（笑）
そんな訳だから、アレなことがお気軽に出来るよう、Virtual PCでCentOS5.2な環境を構築。実物のディスクを用意するのも面倒というかもったいないので…
およそ10GBの領域を10個作成してみた。（笑）hda5～hda14までが、そのテスト用の領域ということで。
まず、ソフトRAIDを構築するにあたって必要なパッケージがインストールされているかどうか確認する。
ちなみに、LinuxでソフトRAIDする場合は、「mdadm」というコマンドを使用することになる。このコマンドで様々なオペレーションが出来るのだ。
とりあえず、mdadmコマンドがあるかな？チェックしてみると…
なんと。今時のCentOSだと標準でインストールされてくるくさい。
ちなみに、もし入っていない場合はパッケージをチェックしてみよう。
こんなパッケージが入っているはずなんだけども、入っていない場合はyumでさくっとインストールする。
と、いうことなので、インストールする際は
とかで。なお、VineLinuxなお友達は…
ということなので、
ということになる。
それでは、実際にRAID5のボリュームを作成してみる。使用するコマンドは「mdadm」しかない。これに機能毎に決められたオプションを指定してやることで、RAIDの構築を行ったり、設定を変更したり状態をチェックしたり…ということを行う。
RAID 5ボリュームの作成を行う場合は…
mdadm --create RAIDデバイス名 --level=5 --raid-devices=RAIDに参加するディスクの数 RAIDに参加するデバイス名…
という具合にコマンドを記述する。
それぞれの項目について補足する。
「RAIDデバイス名」とは、複数のハードディスクを使って構成したRAIDのボリュームにアクセスする際に使用するデバイス名のことで、通常は「md*」（1個目のRAIDデバイスなら md0 になる）が割り当てられる。なので、通常は「/dev/md0」とかそんな風に指定することになる。
「--level=」オプションに続けて記述している「5」という数値は、RAIDのレベルを意味している。RAID 0を構成したい場合はここを「0」、RAID 1なら「1」、RAID 6にしたいなら「6」という具合になる。今回はRAID 5を構築するので「5」を指定している。
「RAIDに参加するディスクの数」とは、そのまま読んで字のごとく。RAIDを構成するハードディスクの数を記述する。4本のディスクでRAID 5を構成するならば、「4」と記述することになる。
「RAIDに参加するデバイス名」には、ハードディスクのデバイス名を列挙する。4台のディスクでRAID 5を構築するとしたら、ここに4台分のハードディスクのデバイス名を並べることになる。
というわけで、4台のハードディスク（hda5 hda6 hda7 hda8）でRAID 5を構築するとしたら…
mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/hda[5678]
こんな風に記述することになる。
コマンドが正常に受け付けられれば、このように「/dev/md0」がスタートしたことが表示される。
ちなみに、RAID 5等の場合は、「アレイのビルド」が行われる。（これが結構時間が掛かる）進行状態は、「/proc/mdstat」を見れば一目瞭然である。
「recovery」の項目がリビルドの進捗状態を示している。この環境の場合、あと60分はかかる（「finish」の項目を参照）ことが判る。
なお、リビルドが終わっている状態のサーバであれば、以下のような表示になっている（はず）。
（違うサーバの表示なのでデバイス名とかサイズとかが違っている点については容赦してもらいたい）
RAIDデバイスが開始したら、さくっとファイルシステムを作成してマウント可能である。
なお、リビルド中はCPUの負荷が高めになるので、その辺はソフトRAIDの宿命だと割り切ってもらいたい。（笑）
さて。上記のdfコマンドの結果を見てもらえば判るように、約10GBの領域を4個使ってRAID5を構成しているが、実際に使用可能なサイズは約30GBになっている。RAID 5であるために、n-1本のディスクが使用できるということが理解できると思う。
RAID の構築が出来たら、いろいろとアレなことをしてみようと思うのだが、まだあと57分くらいかかるらしいので、続きは後ほど。（笑）
なお、RAID 5のリビルドが終了するまでの間にディスクが故障した場合はデータは救済されないので注意が必要である。心配性な人は、/proc/mdstatを見てリビルドが完了している（＝通常の運用状態にある）ことを確認してからこのボリュームを使用するようにしよう。
そんな訳だから、アレなことがお気軽に出来るよう、Virtual PCでCentOS5.2な環境を構築。実物のディスクを用意するのも面倒というかもったいないので…
コマンド (m でヘルプ): p Disk /dev/hda: 136.8 GB, 136897904640 bytes 255 heads, 63 sectors/track, 16643 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 1318 10482412+ 83 Linux /dev/hda3 1319 1449 1052257+ 82 Linux swap / Solaris /dev/hda4 1450 16643 122045805 5 拡張領域 /dev/hda5 1450 2695 10008463+ 83 Linux /dev/hda6 2696 3941 10008463+ 83 Linux /dev/hda7 3942 5187 10008463+ 83 Linux /dev/hda8 5188 6433 10008463+ 83 Linux /dev/hda9 6434 7679 10008463+ 83 Linux /dev/hda10 7680 8925 10008463+ 83 Linux /dev/hda11 8926 10171 10008463+ 83 Linux /dev/hda12 10172 11417 10008463+ 83 Linux /dev/hda13 11418 12663 10008463+ 83 Linux /dev/hda14 12664 13909 10008463+ 83 Linux
およそ10GBの領域を10個作成してみた。（笑）hda5～hda14までが、そのテスト用の領域ということで。
まず、ソフトRAIDを構築するにあたって必要なパッケージがインストールされているかどうか確認する。
ちなみに、LinuxでソフトRAIDする場合は、「mdadm」というコマンドを使用することになる。このコマンドで様々なオペレーションが出来るのだ。
とりあえず、mdadmコマンドがあるかな？チェックしてみると…
# mdadm --help
mdadm is used for building, managing, and monitoring
Linux md devices (aka RAID arrays)
Usage: mdadm --create device options...
Create a new array from unused devices.
mdadm --assemble device options...
Assemble a previously created array.
mdadm --build device options...
Create or assemble an array without metadata.
mdadm --manage device options...
make changes to an existing array.
mdadm --misc options... devices
report on or modify various md related devices.
mdadm --grow options device
resize/reshape an active array
mdadm --incremental device
add a device to an array as appropriate
mdadm --monitor options...
Monitor one or more array for significant changes.
mdadm device options...
Shorthand for --manage.
Any parameter that does not start with '-' is treated as a device name
or, for --examine-bitmap, a file name.
The first such name is often the name of an md device. Subsequent
names are often names of component devices.
For detailed help on the above major modes use --help after the mode
e.g.
mdadm --assemble --help
For general help on options use
mdadm --help-options
なんと。今時のCentOSだと標準でインストールされてくるくさい。
ちなみに、もし入っていない場合はパッケージをチェックしてみよう。
# rpm -qa | fgrep mdadm mdadm-2.6.4-1.el5
こんなパッケージが入っているはずなんだけども、入っていない場合はyumでさくっとインストールする。
# yum search mdadm base 100% |=========================| 1.1 kB 00:00 updates 100% |=========================| 951 B 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 mdadm.i386 : mdadm は Linux md デバイスを制御します(ソフトウェア RAID アレイ) mdadm.i386 : mdadm controls Linux md devices (software RAID arrays)
と、いうことなので、インストールする際は
# yum install mdadm.i386
とかで。なお、VineLinuxなお友達は…
# apt-cache search mdadm mdadm - Linux の MD デバイス(ソフトウエアRAIDアレイ)用のユーティリティ
ということなので、
# apt-get install mdadm
ということになる。
それでは、実際にRAID5のボリュームを作成してみる。使用するコマンドは「mdadm」しかない。これに機能毎に決められたオプションを指定してやることで、RAIDの構築を行ったり、設定を変更したり状態をチェックしたり…ということを行う。
RAID 5ボリュームの作成を行う場合は…
mdadm --create RAIDデバイス名 --level=5 --raid-devices=RAIDに参加するディスクの数 RAIDに参加するデバイス名…
という具合にコマンドを記述する。
それぞれの項目について補足する。
「RAIDデバイス名」とは、複数のハードディスクを使って構成したRAIDのボリュームにアクセスする際に使用するデバイス名のことで、通常は「md*」（1個目のRAIDデバイスなら md0 になる）が割り当てられる。なので、通常は「/dev/md0」とかそんな風に指定することになる。
「--level=」オプションに続けて記述している「5」という数値は、RAIDのレベルを意味している。RAID 0を構成したい場合はここを「0」、RAID 1なら「1」、RAID 6にしたいなら「6」という具合になる。今回はRAID 5を構築するので「5」を指定している。
「RAIDに参加するディスクの数」とは、そのまま読んで字のごとく。RAIDを構成するハードディスクの数を記述する。4本のディスクでRAID 5を構成するならば、「4」と記述することになる。
「RAIDに参加するデバイス名」には、ハードディスクのデバイス名を列挙する。4台のディスクでRAID 5を構築するとしたら、ここに4台分のハードディスクのデバイス名を並べることになる。
というわけで、4台のハードディスク（hda5 hda6 hda7 hda8）でRAID 5を構築するとしたら…
mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/hda[5678]
こんな風に記述することになる。
# mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/hda[5678] mdadm: array /dev/md0 started.
コマンドが正常に受け付けられれば、このように「/dev/md0」がスタートしたことが表示される。
ちなみに、RAID 5等の場合は、「アレイのビルド」が行われる。（これが結構時間が掛かる）進行状態は、「/proc/mdstat」を見れば一目瞭然である。
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 hda8[4] hda7[2] hda6[1] hda5[0]
30025152 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
[>....................] recovery = 0.3% (35712/10008384) finish=60.3min speed=2747K/sec
unused devices:
「recovery」の項目がリビルドの進捗状態を示している。この環境の場合、あと60分はかかる（「finish」の項目を参照）ことが判る。
なお、リビルドが終わっている状態のサーバであれば、以下のような表示になっている（はず）。
# cat /proc/mdstat
Personalities : [raid5] [raid4]
md0 : active raid5 sdf1[3] sde1[2] sdd1[1] sdb1[0]
2930279808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices:
（違うサーバの表示なのでデバイス名とかサイズとかが違っている点については容赦してもらいたい）
RAIDデバイスが開始したら、さくっとファイルシステムを作成してマウント可能である。
# mke2fs -j /dev/md0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
3753600 inodes, 7506288 blocks
375314 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
230 block groups
32768 blocks per group, 32768 fragments per group
16320 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
# mkdir /mnt/work
# mount /dev/md0 /mnt/work
# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda2 9.7G 1.6G 7.6G 18% /
/dev/hda1 99M 11M 83M 12% /boot
tmpfs 252M 0 252M 0% /dev/shm
/dev/md0 29G 173M 27G 1% /mnt/work
なお、リビルド中はCPUの負荷が高めになるので、その辺はソフトRAIDの宿命だと割り切ってもらいたい。（笑）
さて。上記のdfコマンドの結果を見てもらえば判るように、約10GBの領域を4個使ってRAID5を構成しているが、実際に使用可能なサイズは約30GBになっている。RAID 5であるために、n-1本のディスクが使用できるということが理解できると思う。
RAID の構築が出来たら、いろいろとアレなことをしてみようと思うのだが、まだあと57分くらいかかるらしいので、続きは後ほど。（笑）
なお、RAID 5のリビルドが終了するまでの間にディスクが故障した場合はデータは救済されないので注意が必要である。心配性な人は、/proc/mdstatを見てリビルドが完了している（＝通常の運用状態にある）ことを確認してからこのボリュームを使用するようにしよう。
RAID導入編 [Linux(LVM/RAID/Storage)]
これまで、LVMについてドバドバと書いてきたので（まあ、自分用のメモの延長でしたが：笑）、今度はRAIDについてもちょろちょろと書いておこうかと思う。
で、LVMの時には「そもそもLVMって…」というのを書かずにおっぱじめたので、RAIDについては最初に簡単に説明してから、LinuxでRAIDを使おう！編に入りたいと思う。
RAIDというのは、大切なデータを、ハードディスクの故障という非常事態からいかにして守るかということをテーマに、多少多少寄り道をして考えられた仕組みのことです。（その寄り道の最たる物が「RAID 0」ストライピングということですね）
単にデータを守るだけにとどまらず、運用状態をいかに確保し続けるかとか、そういった方面についても工夫が凝らされている…そういう特徴をもっているとも思っておいて欲しい。
で。
RAIDには「レベル」があり、昨今よく使われるものとしては
・RAID 0 ストライピング
・RAID 1 ミラーリング
・RAID 5 パリティ分散記録式ストライピング
・RAID 6 複数パリティ分散記録式ストライピング
また、これらの組み合わせとして「RAID 0+1」「RAID 1+0」「RAID 0+5」「RAID 5+0」「RAID 5+5」というものも存在している。まあ、健全なパソコンおたくちゃんが使用するようなものではない。（笑）
さらに、上記のRAIDとは別に、「JBOD」とよばれる機能をもつRAIDコントローラも少なくない。
・JBOD スパニング
で、ここまで見た段階できっと、「あれ？『RAID 2』とか『RAID 3』とか『RAID 4』とか無いの？」と思った人もいると思う。それは…
・RAID 2 → 冗長性の確保という点ではほとんど最強ではあるものの、そんな冗長性が必要になるほどハードディスクの信頼性は低く無いし、そもそもコストがかかりすぎるので、最初から相手にされなかった
・RAID 3 → RAIDの処理のためにディスクの読み書き性能が猛烈に劣化してしまい、RAID 3が出た当初に少し製品が出たくらいで今はRAID 5に取って代わられてしまった
・RAID 4 → RAID 3の性能を改善したソリューションだったが、こちらもRAID 5に比べてディスクアクセス性能が低いため、RAID 5に取って代わられてしまった
と、いうことです。もしかしたら、RAID 4の製品はまだどこかで稼働しているものもあるかもしれない。
RAID 1、5、6については、ハードディスクの容量を犠牲にして信頼性を高めたいという発想であり、RAID 0やJBODについてはこれとは逆に信頼性を犠牲にしても容量（や速度）を求めたいという発想のものになっている。よって、JBODはともかく、RAID 0はそれ単体で用いることはリスキーであり、多くの場合はRAID 1と組み合わせて用いられることが多い。RAID 0はRAID 1ととても相性が良く、この両者の組み合わせについては多くのRAIDコントローラが対応している。
RAID 0 ストライピングとは
RAID 0 ストライピングとは、複数のディスクを同時にアクセスして、ディスクに対する読み書き性能を向上させる仕組みだと思ってもらうとよい。
例えば、「１バイトのデータ」を１台のハードディスクに書き込んだり読み取ったりするとする。（普通、そんなことしないけど、あくまでも「例」として）その場合、１バイト（８ビット）のデータを全て１個のディスクに書き込んだり、あるいは読み取ったりすることになる。
ここで、ディスクを４台用意し、これでRAID 0を構成したとする。この場合は、「１バイトのデータ」をハードディスクの台数の分だけ分割（つまり、１バイトのデータを４分割するので、２ビット）することになる。ただ、これをこのまま２ビットだけアクセスしても結局は全体にかかるアクセス時間は変化しないので、ディスク１台に対するアクセス量を増加させて、あくまでも１台のハードディスクに対するアクセスは「１バイト（８ビット）」分のアクセスを行うようにする。つまり、２ビットのデータを４個組み合わせて（つまり４バイト分）アクセスすることになる。
単独のディスクに１バイトずつ、合計４バイトアクセスを行うのではなく、１個のデータを分割（分散）してアクセスすることで、ハードディスクへの接続経路（バス）がディスク台数分だけ広がった状態になる。このため、ディスクへのアクセスが高速化される…という寸法。
RAID 0では、一般的にハードディスクの台数が多ければ多いほど高速化されるが、一方でただでさえ壊れやすいハードディスクが増えれば増えるほど全体の信頼性は低下するのでRAID 1とかRAID 5とかと組み合わせて用いるのが無難。
なお、RAID 0ではディスクが1本でも飛んだら全てのデータがおしゃかになることに特に注意が必要。
RAID 1 ミラーリングとは
RAID 1とは最低2本のハードディスクをペアにして、その両方のディスクに全く同じデータを保存しておくもの。これなら、どちらか片方のディスクが壊れてももう1本のディスクが生きていれば中のデータは無傷でいられる…というもの。（さすがに両方のディスクが同時に壊れることはそうそう無いだろう…という前提の下だけどね）高い信頼性が求められる場合に多用されるものだけども、弱点があって、実質的に使える容量は全体の容量の１／２しかないということ。たとえば、200GBの容量が必要ということになった場合は、200GBのハードディスクが2本必要ということなので、バラバラに使えば400GB分の容量があるはずのところを200GBとして使うので、容量的には最ももったいない贅沢な使い方…と言える。
ただ、次に解説するRAID 5やRAID 6と比べて、障害発生時に起こりうるペナルティが少ないという点はメリットであるとも言える。
RAID 5 パリティ分散記録式ストライピング
RAID 5は、最低でも3本のディスクを使ってデータを保全する仕組み。実際に使えるディスクの容量は全体のディスクの本数-1個分となる。例えば、200GBのディスクを3本用意してRAID 5を構築したとすると、1本少ない2本文の容量…つまり400GBが実際に使用できる容量と言うことになる。
RAID 5では、RAID 0のようにディスクの中のデータを丸ごとコピーするのではなく、「パリティデータ」という、いわばヒントみたいなデータを生成し、さらにそのデータをあちこちのディスクに分散して記録するという方法を採っている。また、RAID 0のようにデータ自身も分散して記録するので、通常時であればディスクに対する読み込み性能が上昇するというオマケもついてくる。（ただし、パリティデータを生成する都合上、データをディスクに書き込む際の性能は多くの場合低下してしまう）
で、RAID 5を構成するディスクが1本壊れた場合、どうなるのかというと、データもパリティデータも複数のディスクに分散して記録されているので、読み取れるデータは「虫食い状態のデータ」と「パリティデータ」という組み合わせか、または「無事だったデータ」（この場合はパリティデータが失われている）という状態になっている。無事だったデータについてはまあ良いとして、問題は「虫食い状態のデータ」である。これを元々の姿に復元するためのヒントとして、「パリティデータ」が使われることになる。
このようにして、ディスクが1本壊れたくらいでは全体のデータは失われずに済むようになっている。RAID 5はディスクの使用効率が良いため、ビジネスの世界ではいろいろなところで使われているし、最近では家庭用のNASでも堂々とRAID 5対応を謳っている製品も登場している。
なお、RAID 5特有の弱点としては
・パリティデータを生成する都合上、書き込み性能は高くない
・ディスク障害中には、虫食い状態のデータをパリティデータと組み合わせて復元する処理が必要となるので、読み取り性能も（ほとんどの場合は猛烈に）悪化する
・飛んでもよいディスクは1本まで。1本飛んでいる状態でさらにもう1本のディスクが壊れたら全体のデータが失われてしまう
RAID 6 複数パリティ分散記録式ストライピング
で、RAID 5の「飛んでもよいディスクは1本まで。1本飛んでいる状態でさらにもう1本のディスクが壊れたら全体のデータが失われてしまう」という問題を解決すべく登場したのが、このRAID 6。要するに、パリティデータを複数用意してやれば、同時に複数のディスクが壊れても大丈夫だ！というなんともアメリカンな発想のソリューション。（笑）
今のところ世に出回っている多くのRAID 6ソリューションは、パリティデータを2種類用意して同時に2台のハードディスクの故障まで耐えられるようにしている物がほとんどのようだ。（３種類以上…というものは私はまだ見たことがないけどね）
RAID 6では用意したパリティデータの数だけ、ディスクが同時に壊れても大丈夫なように考えられているが、同時にそれだけ必要となるハードディスクの本数が増えてしまうことにもなる。
例えば、RAID 5の場合は全体の台数-1台分のハードディスクをデータ保存領域として使用できた。しかし、パリティデータを2種類用意するRAID 6の場合は「全体の台数-2台」が必要と言うことになる。200GBのハードディスクを用意して、400GBのデータ領域を使用したい場合を想定すると、RAID 5なら3本のハードディスクが必要で、パリティデータを2種類用意するRAID 6の場合は4本のハードディスクが必要ということとなる。
RAID 6はRAID 5と同じような長所をもち、さらにRAID 5よりも堅牢性は高いと言える。しかし、RAID 5と同じような弱点を持つが、特にディスクへの書き込み性能についてはパリティデータを複数生成する必要があることから、RAID 5よりもさらに性能が劣化する傾向にあることは否めない。
で、健全なパソコンオタクちゃんが自宅でLinuxでファイルサーバを作ったときに、ディスクが壊れてもデータが失われないようにしたいな～というケースでは、おそらくRAID 5を使用しておくのが現実的な対応ではないかと思う。また、ネットワーク越しに画像ファイルを保存するようなケースでは、ハードRAIDとかが必要になるということも家庭用用途としては薄いだろうから、ソフトRAIDを使ってこれを実現するにはどうすれば良いか…というあたりにターゲットを置いて記述しておこうと思う。
で、LVMの時には「そもそもLVMって…」というのを書かずにおっぱじめたので、RAIDについては最初に簡単に説明してから、LinuxでRAIDを使おう！編に入りたいと思う。
RAIDというのは、大切なデータを、ハードディスクの故障という非常事態からいかにして守るかということをテーマに、多少多少寄り道をして考えられた仕組みのことです。（その寄り道の最たる物が「RAID 0」ストライピングということですね）
単にデータを守るだけにとどまらず、運用状態をいかに確保し続けるかとか、そういった方面についても工夫が凝らされている…そういう特徴をもっているとも思っておいて欲しい。
で。
RAIDには「レベル」があり、昨今よく使われるものとしては
・RAID 0 ストライピング
・RAID 1 ミラーリング
・RAID 5 パリティ分散記録式ストライピング
・RAID 6 複数パリティ分散記録式ストライピング
また、これらの組み合わせとして「RAID 0+1」「RAID 1+0」「RAID 0+5」「RAID 5+0」「RAID 5+5」というものも存在している。まあ、健全なパソコンおたくちゃんが使用するようなものではない。（笑）
さらに、上記のRAIDとは別に、「JBOD」とよばれる機能をもつRAIDコントローラも少なくない。
・JBOD スパニング
で、ここまで見た段階できっと、「あれ？『RAID 2』とか『RAID 3』とか『RAID 4』とか無いの？」と思った人もいると思う。それは…
・RAID 2 → 冗長性の確保という点ではほとんど最強ではあるものの、そんな冗長性が必要になるほどハードディスクの信頼性は低く無いし、そもそもコストがかかりすぎるので、最初から相手にされなかった
・RAID 3 → RAIDの処理のためにディスクの読み書き性能が猛烈に劣化してしまい、RAID 3が出た当初に少し製品が出たくらいで今はRAID 5に取って代わられてしまった
・RAID 4 → RAID 3の性能を改善したソリューションだったが、こちらもRAID 5に比べてディスクアクセス性能が低いため、RAID 5に取って代わられてしまった
と、いうことです。もしかしたら、RAID 4の製品はまだどこかで稼働しているものもあるかもしれない。
RAID 1、5、6については、ハードディスクの容量を犠牲にして信頼性を高めたいという発想であり、RAID 0やJBODについてはこれとは逆に信頼性を犠牲にしても容量（や速度）を求めたいという発想のものになっている。よって、JBODはともかく、RAID 0はそれ単体で用いることはリスキーであり、多くの場合はRAID 1と組み合わせて用いられることが多い。RAID 0はRAID 1ととても相性が良く、この両者の組み合わせについては多くのRAIDコントローラが対応している。
RAID 0 ストライピングとは
RAID 0 ストライピングとは、複数のディスクを同時にアクセスして、ディスクに対する読み書き性能を向上させる仕組みだと思ってもらうとよい。
例えば、「１バイトのデータ」を１台のハードディスクに書き込んだり読み取ったりするとする。（普通、そんなことしないけど、あくまでも「例」として）その場合、１バイト（８ビット）のデータを全て１個のディスクに書き込んだり、あるいは読み取ったりすることになる。
ここで、ディスクを４台用意し、これでRAID 0を構成したとする。この場合は、「１バイトのデータ」をハードディスクの台数の分だけ分割（つまり、１バイトのデータを４分割するので、２ビット）することになる。ただ、これをこのまま２ビットだけアクセスしても結局は全体にかかるアクセス時間は変化しないので、ディスク１台に対するアクセス量を増加させて、あくまでも１台のハードディスクに対するアクセスは「１バイト（８ビット）」分のアクセスを行うようにする。つまり、２ビットのデータを４個組み合わせて（つまり４バイト分）アクセスすることになる。
単独のディスクに１バイトずつ、合計４バイトアクセスを行うのではなく、１個のデータを分割（分散）してアクセスすることで、ハードディスクへの接続経路（バス）がディスク台数分だけ広がった状態になる。このため、ディスクへのアクセスが高速化される…という寸法。
RAID 0では、一般的にハードディスクの台数が多ければ多いほど高速化されるが、一方でただでさえ壊れやすいハードディスクが増えれば増えるほど全体の信頼性は低下するのでRAID 1とかRAID 5とかと組み合わせて用いるのが無難。
なお、RAID 0ではディスクが1本でも飛んだら全てのデータがおしゃかになることに特に注意が必要。
RAID 1 ミラーリングとは
RAID 1とは最低2本のハードディスクをペアにして、その両方のディスクに全く同じデータを保存しておくもの。これなら、どちらか片方のディスクが壊れてももう1本のディスクが生きていれば中のデータは無傷でいられる…というもの。（さすがに両方のディスクが同時に壊れることはそうそう無いだろう…という前提の下だけどね）高い信頼性が求められる場合に多用されるものだけども、弱点があって、実質的に使える容量は全体の容量の１／２しかないということ。たとえば、200GBの容量が必要ということになった場合は、200GBのハードディスクが2本必要ということなので、バラバラに使えば400GB分の容量があるはずのところを200GBとして使うので、容量的には最ももったいない贅沢な使い方…と言える。
ただ、次に解説するRAID 5やRAID 6と比べて、障害発生時に起こりうるペナルティが少ないという点はメリットであるとも言える。
RAID 5 パリティ分散記録式ストライピング
RAID 5は、最低でも3本のディスクを使ってデータを保全する仕組み。実際に使えるディスクの容量は全体のディスクの本数-1個分となる。例えば、200GBのディスクを3本用意してRAID 5を構築したとすると、1本少ない2本文の容量…つまり400GBが実際に使用できる容量と言うことになる。
RAID 5では、RAID 0のようにディスクの中のデータを丸ごとコピーするのではなく、「パリティデータ」という、いわばヒントみたいなデータを生成し、さらにそのデータをあちこちのディスクに分散して記録するという方法を採っている。また、RAID 0のようにデータ自身も分散して記録するので、通常時であればディスクに対する読み込み性能が上昇するというオマケもついてくる。（ただし、パリティデータを生成する都合上、データをディスクに書き込む際の性能は多くの場合低下してしまう）
で、RAID 5を構成するディスクが1本壊れた場合、どうなるのかというと、データもパリティデータも複数のディスクに分散して記録されているので、読み取れるデータは「虫食い状態のデータ」と「パリティデータ」という組み合わせか、または「無事だったデータ」（この場合はパリティデータが失われている）という状態になっている。無事だったデータについてはまあ良いとして、問題は「虫食い状態のデータ」である。これを元々の姿に復元するためのヒントとして、「パリティデータ」が使われることになる。
このようにして、ディスクが1本壊れたくらいでは全体のデータは失われずに済むようになっている。RAID 5はディスクの使用効率が良いため、ビジネスの世界ではいろいろなところで使われているし、最近では家庭用のNASでも堂々とRAID 5対応を謳っている製品も登場している。
なお、RAID 5特有の弱点としては
・パリティデータを生成する都合上、書き込み性能は高くない
・ディスク障害中には、虫食い状態のデータをパリティデータと組み合わせて復元する処理が必要となるので、読み取り性能も（ほとんどの場合は猛烈に）悪化する
・飛んでもよいディスクは1本まで。1本飛んでいる状態でさらにもう1本のディスクが壊れたら全体のデータが失われてしまう
RAID 6 複数パリティ分散記録式ストライピング
で、RAID 5の「飛んでもよいディスクは1本まで。1本飛んでいる状態でさらにもう1本のディスクが壊れたら全体のデータが失われてしまう」という問題を解決すべく登場したのが、このRAID 6。要するに、パリティデータを複数用意してやれば、同時に複数のディスクが壊れても大丈夫だ！というなんともアメリカンな発想のソリューション。（笑）
今のところ世に出回っている多くのRAID 6ソリューションは、パリティデータを2種類用意して同時に2台のハードディスクの故障まで耐えられるようにしている物がほとんどのようだ。（３種類以上…というものは私はまだ見たことがないけどね）
RAID 6では用意したパリティデータの数だけ、ディスクが同時に壊れても大丈夫なように考えられているが、同時にそれだけ必要となるハードディスクの本数が増えてしまうことにもなる。
例えば、RAID 5の場合は全体の台数-1台分のハードディスクをデータ保存領域として使用できた。しかし、パリティデータを2種類用意するRAID 6の場合は「全体の台数-2台」が必要と言うことになる。200GBのハードディスクを用意して、400GBのデータ領域を使用したい場合を想定すると、RAID 5なら3本のハードディスクが必要で、パリティデータを2種類用意するRAID 6の場合は4本のハードディスクが必要ということとなる。
RAID 6はRAID 5と同じような長所をもち、さらにRAID 5よりも堅牢性は高いと言える。しかし、RAID 5と同じような弱点を持つが、特にディスクへの書き込み性能についてはパリティデータを複数生成する必要があることから、RAID 5よりもさらに性能が劣化する傾向にあることは否めない。
で、健全なパソコンオタクちゃんが自宅でLinuxでファイルサーバを作ったときに、ディスクが壊れてもデータが失われないようにしたいな～というケースでは、おそらくRAID 5を使用しておくのが現実的な対応ではないかと思う。また、ネットワーク越しに画像ファイルを保存するようなケースでは、ハードRAIDとかが必要になるということも家庭用用途としては薄いだろうから、ソフトRAIDを使ってこれを実現するにはどうすれば良いか…というあたりにターゲットを置いて記述しておこうと思う。
LVMってそもそもなんなのさ！？ [Linux(LVM/RAID/Storage)]
…と、タイトルみたいな質問をされたのですが、そういえばここには「そもそも…」という話を書いてなかったので、良い機会なので書いておこうかなと思う。
とはいえ、LVMについては他のサイトでもいろいろ解説記事は書かれているのでどの程度書くか…というところが難しいところではあるんだけども。（笑）
LVMというのは、まあ要するに「動的かつ自在にディスクのパーティションを変更できる仕組み」とでも理解してもらうのがとっても簡単かと思う。（多少の補足は必要だけどもね）
ディスクのパーティションというと、Linuxならばfdiskとかpartedとかがぱっと出てくると思うんだけども、LVMもまあこいつらみたいな機能を持っている。fdiskやpartedでも一応パーティションのサイズを広げたり縮小したりすることは出来るけども、その場合は原則的に「連続した領域」でなければならないところ、LVMにはそういった制限が無い。
例えば、あるディスクにパーティションが3個あったとして、それぞれをsdc1、sdc2、sdc3だったとします。通常、1から順にディスクの先頭からパーティションを割り付けて行きます。たとえばこんな感じに。
シリンダ番号（StartとEndのところの数値）が隣接している状態なので、この状態でsdc2を拡張したい！ということになっても、そのままでは拡張できず、sdc3を一旦開放してからsdc2を拡張し、その後にsdc3を再度作成みたいなことをしないといけなくなる。ということは、sdc3が使用中だったりすると、その中身を一旦どこかに待避するなどの作業が必要になってしまう訳。
Windows等の場合には、市販のソフトでそういう操作を全部自動でやってくれるものがあるけども、Linuxの場合にはLVMがそれをやってくれる…ということになる。
また、LVMが突出して優れているのはパーティションを複数のディスクにまたがって作成できるという点。
つまり、この点を強調すると、容量の小さな複数のディスクを1個の大きなディスクに束ねる…みたいな使い方もできるよ！ということ。
ここで、「それってRAIDコントローラが持ってるようなJBOD（スパニング）と何が違うのよ！」という質問が当然に出てくると思うのですが、効能的にはぶっちゃけ一緒です。（笑）ハードRAIDなコントローラにお任せしてしまえばCPUに負荷が掛からないのに対して、LVMだとその辺の処理を全部CPUがやることになるので負荷的には不利と言えば不利になります。が、LVMだとディスクの容量を動的に変更できる点がJBOD（スパニング）に対して優位であると言うことも出来るでしょう。
JBOD（スパニング）の場合にディスクを追加して全体の容量を拡張したいなんて場合には、それこそ先ほどのfdiskやpartedでパーティションのサイズ変更をするのと同じような話になってしまう。つまり、そのディスク上にあるデータを一旦全部どけてからRAID（JBOD）を再構築しなおして…というハメになる訳ですよもう。しかし、LVMだったらディスクを増設したらそのディスクを次々と追加すればよい訳。
また、よっぽどその筋な人でもない限りは、そんな上等なRAIDコントローラカードなんて使わないだろうけども、LVMでディスクを束ねるにあたっては、ディスクを接続するインタフェースをまったく選ばないという点も大きな魅力になってくる。昔からあるパラレルATAだろうと、シリアルATAだろうとIEEE1394接続したディスクだろうとUSB接続したディスクだろうと、Linux上から認識できるディスクはすべからくLVMの管理下に置いてディスクを束ねたり、束ねたディスクから自在にパーティションを切り出して使うことが出来るという訳。
まあ、会社などでビジネスに使うにはアレかもしれないけども、自宅で個人的にLinuxを使ってファイルサーバにする…なんていうケースにおいてはこれほどありがたい物は他にないかもしれない。それくらい、便利な仕組みだったりするんだなこれが。
で、LVMを使うにあたっては特徴的な用語を覚える必要がある。他のサイトでもいろいろと解説されているけども、念のためここにも記載しておく。
① 物理ボリューム
「PV」と省略されて記述されることが多い。要するに、ハードディスクそのものを言うと覚えてもらっても構わないと思う。この物理ボリュームを単位としてLVMの制御下に置くこととなる。ハードディスク全体をLVMの制御下に置くこともできるし、ハードディスクの領域を部分的にLVMの制御下に置くこともできる。その場合は、fdiskやpartedでハードディスクそのものに一度パーティションを切っておき、そのパーティションに対して物理ボリュームを作成する（割り当てる）ことになる。
Linuxをインストールする際にはLVMを使ってディスクを構成することが標準になっているけども、その際、Linuxのインストーラはブートディスクの「/boot」領域をLVMの制御下に置かず、それ以外の領域をLVMの制御下に置くようにセットアップしている。参照してもらうと分かり易いかもしれない。
ちなみに、物理ボリュームの操作に関連するコマンドの多くは、「pv」で始まるコマンド名となっている。
② ボリュームグループ
「VG」と省略されて記述されることが多い。１個以上の物理ボリュームをまとめて一つのボリュームグループを構成する。１個以上の物理ボリュームをまとめて1個の大きなディスクを仮想的に作っていると思えばよく、このボリュームグループが要するにRAIDでいうJBOD（スパニング）が構成された状態…みたいな感じになっている。
ボリュームグループの操作に関連するコマンドの多くは、「vg」で始まるコマンド名となっている。
③物理エクステント
「PE」と省略されて記述されることが多い。LVMはこの物理エクステントを最小の単位として、容量を管理している。要するに、物理エクステントという名前のカゴが沢山ある状態…だと思ってもらうとよい。
物理ボリュームの中をたくさんの物理エクステントに分割している。標準の状態では物理エクステント1個につき4MBで割り当てられている。この大きさはボリュームグループを作成するときに自由に変更することが出来る他、ボリュームグループを作成した後であっても、条件付きで動的に変更することもできる。まあ、ぶっちゃけ今時のハードディスクをLVMの制御下に置くには４MBなんて容量は小さすぎる気がするので、もっと大きな数値にするのが良いと思う。
ちなみに、LVMが自在にパーティションのサイズを変更できる理由も、この物理エクステントにある。パーティションの管理をハードディスクに固有の「シリンダ」でなく、物理エクステントを単位として管理しているため、パーティションが作成されている物理エクステントの位置そのものは連続している必要性が全くない上に、同一のディスク上にある必要性も無い。このため、パーティションを拡張するにしても、ボリュームグループの中に空いている物理エクステントがあればいつでもパーティションの拡張は可能ということになる。
④論理ボリューム
「LV」と省略されて記述されることが多い。論理ボリュームとは、要するに「パーティション」と似たものだと思ってもらえばほぼ問題ないかとおもう。最終的に作成された、この論理ボリュームに対してファイルシステムを作成する操作をする。これはまさに、ハードディスクにfdiskやpartedで作成したパーティションに対してファイルシステムを作成する操作をすることを思えば理解しやすいと思う。
論理ボリュームの大きさは動的に変更することが可能。１点だけ要注意なのは、論理ボリュームを拡張したからといって、ファイルシステムの大きさが自動的に広がるわけではないということ。論理ボリューム（やパーティション）≠ファイルシステムであることに留意が必要。
論理ボリュームの操作に関するコマンドの多くは「lv」で始まるコマンド名になっている。
細かいことはLVMの構築方法（基本編）をみてもらうとして。
LVMを実際に使うための流れとしては…
①LVMの使用に必要なパッケージのインストール（の確認）
②ハードディスクの接続
③接続したハードディスクに物理ボリュームを作成する
④ボリュームグループを作成し、そこに先ほど作成した物理ボリュームを登録する
⑤ボリュームグループから論理ボリュームを切り出す
⑥論理ボリュームにファイルシステムを作成し、マウントして使う
というような手順を踏むことになる。
まあ、「①」については、よほど変なディストリビューションだったり古いバージョンだったりしない限りは問題ないと思うが、念のため確認しておこう。
LVMのパッケージがセットアップされていることがこれで確認できる。
「②」は特に説明不要だと思うのでパス。まあ、接続したハードディスクがLinuxで認識されていることを確認しておこおう。方法は「/proc/partitions」の中をcatコマンドなどで見てみればよい。
他にdmesgとかも見ておこうね。
きちんと認識できているようなら、物理ボリュームを作成してボリュームグループを作成して論理ボリュームを作成してファイルシステムを作成してマウントして/etc/fstabを変更して完了。詳しい手順・コマンドについてはもう面倒くさくなってきたのでLVMの構築方法（基本編）を参照しる。
最後に、LVMとRAIDとの比較を簡単にまとめておく。まあ、参考程度に…ということで。
とはいえ、LVMについては他のサイトでもいろいろ解説記事は書かれているのでどの程度書くか…というところが難しいところではあるんだけども。（笑）
LVMというのは、まあ要するに「動的かつ自在にディスクのパーティションを変更できる仕組み」とでも理解してもらうのがとっても簡単かと思う。（多少の補足は必要だけどもね）
ディスクのパーティションというと、Linuxならばfdiskとかpartedとかがぱっと出てくると思うんだけども、LVMもまあこいつらみたいな機能を持っている。fdiskやpartedでも一応パーティションのサイズを広げたり縮小したりすることは出来るけども、その場合は原則的に「連続した領域」でなければならないところ、LVMにはそういった制限が無い。
例えば、あるディスクにパーティションが3個あったとして、それぞれをsdc1、sdc2、sdc3だったとします。通常、1から順にディスクの先頭からパーティションを割り付けて行きます。たとえばこんな感じに。
デバイス Boot Start End Blocks Id System /dev/sdc1 1 25 200781 83 Linux /dev/sdc2 26 286 2096482+ 83 Linux /dev/sdc3 287 4421 33214387+ 83 Linux
シリンダ番号（StartとEndのところの数値）が隣接している状態なので、この状態でsdc2を拡張したい！ということになっても、そのままでは拡張できず、sdc3を一旦開放してからsdc2を拡張し、その後にsdc3を再度作成みたいなことをしないといけなくなる。ということは、sdc3が使用中だったりすると、その中身を一旦どこかに待避するなどの作業が必要になってしまう訳。
Windows等の場合には、市販のソフトでそういう操作を全部自動でやってくれるものがあるけども、Linuxの場合にはLVMがそれをやってくれる…ということになる。
また、LVMが突出して優れているのはパーティションを複数のディスクにまたがって作成できるという点。
つまり、この点を強調すると、容量の小さな複数のディスクを1個の大きなディスクに束ねる…みたいな使い方もできるよ！ということ。
ここで、「それってRAIDコントローラが持ってるようなJBOD（スパニング）と何が違うのよ！」という質問が当然に出てくると思うのですが、効能的にはぶっちゃけ一緒です。（笑）ハードRAIDなコントローラにお任せしてしまえばCPUに負荷が掛からないのに対して、LVMだとその辺の処理を全部CPUがやることになるので負荷的には不利と言えば不利になります。が、LVMだとディスクの容量を動的に変更できる点がJBOD（スパニング）に対して優位であると言うことも出来るでしょう。
JBOD（スパニング）の場合にディスクを追加して全体の容量を拡張したいなんて場合には、それこそ先ほどのfdiskやpartedでパーティションのサイズ変更をするのと同じような話になってしまう。つまり、そのディスク上にあるデータを一旦全部どけてからRAID（JBOD）を再構築しなおして…というハメになる訳ですよもう。しかし、LVMだったらディスクを増設したらそのディスクを次々と追加すればよい訳。
また、よっぽどその筋な人でもない限りは、そんな上等なRAIDコントローラカードなんて使わないだろうけども、LVMでディスクを束ねるにあたっては、ディスクを接続するインタフェースをまったく選ばないという点も大きな魅力になってくる。昔からあるパラレルATAだろうと、シリアルATAだろうとIEEE1394接続したディスクだろうとUSB接続したディスクだろうと、Linux上から認識できるディスクはすべからくLVMの管理下に置いてディスクを束ねたり、束ねたディスクから自在にパーティションを切り出して使うことが出来るという訳。
まあ、会社などでビジネスに使うにはアレかもしれないけども、自宅で個人的にLinuxを使ってファイルサーバにする…なんていうケースにおいてはこれほどありがたい物は他にないかもしれない。それくらい、便利な仕組みだったりするんだなこれが。
で、LVMを使うにあたっては特徴的な用語を覚える必要がある。他のサイトでもいろいろと解説されているけども、念のためここにも記載しておく。
① 物理ボリューム
「PV」と省略されて記述されることが多い。要するに、ハードディスクそのものを言うと覚えてもらっても構わないと思う。この物理ボリュームを単位としてLVMの制御下に置くこととなる。ハードディスク全体をLVMの制御下に置くこともできるし、ハードディスクの領域を部分的にLVMの制御下に置くこともできる。その場合は、fdiskやpartedでハードディスクそのものに一度パーティションを切っておき、そのパーティションに対して物理ボリュームを作成する（割り当てる）ことになる。
Linuxをインストールする際にはLVMを使ってディスクを構成することが標準になっているけども、その際、Linuxのインストーラはブートディスクの「/boot」領域をLVMの制御下に置かず、それ以外の領域をLVMの制御下に置くようにセットアップしている。参照してもらうと分かり易いかもしれない。
ちなみに、物理ボリュームの操作に関連するコマンドの多くは、「pv」で始まるコマンド名となっている。
② ボリュームグループ
「VG」と省略されて記述されることが多い。１個以上の物理ボリュームをまとめて一つのボリュームグループを構成する。１個以上の物理ボリュームをまとめて1個の大きなディスクを仮想的に作っていると思えばよく、このボリュームグループが要するにRAIDでいうJBOD（スパニング）が構成された状態…みたいな感じになっている。
ボリュームグループの操作に関連するコマンドの多くは、「vg」で始まるコマンド名となっている。
③物理エクステント
「PE」と省略されて記述されることが多い。LVMはこの物理エクステントを最小の単位として、容量を管理している。要するに、物理エクステントという名前のカゴが沢山ある状態…だと思ってもらうとよい。
物理ボリュームの中をたくさんの物理エクステントに分割している。標準の状態では物理エクステント1個につき4MBで割り当てられている。この大きさはボリュームグループを作成するときに自由に変更することが出来る他、ボリュームグループを作成した後であっても、条件付きで動的に変更することもできる。まあ、ぶっちゃけ今時のハードディスクをLVMの制御下に置くには４MBなんて容量は小さすぎる気がするので、もっと大きな数値にするのが良いと思う。
ちなみに、LVMが自在にパーティションのサイズを変更できる理由も、この物理エクステントにある。パーティションの管理をハードディスクに固有の「シリンダ」でなく、物理エクステントを単位として管理しているため、パーティションが作成されている物理エクステントの位置そのものは連続している必要性が全くない上に、同一のディスク上にある必要性も無い。このため、パーティションを拡張するにしても、ボリュームグループの中に空いている物理エクステントがあればいつでもパーティションの拡張は可能ということになる。
④論理ボリューム
「LV」と省略されて記述されることが多い。論理ボリュームとは、要するに「パーティション」と似たものだと思ってもらえばほぼ問題ないかとおもう。最終的に作成された、この論理ボリュームに対してファイルシステムを作成する操作をする。これはまさに、ハードディスクにfdiskやpartedで作成したパーティションに対してファイルシステムを作成する操作をすることを思えば理解しやすいと思う。
論理ボリュームの大きさは動的に変更することが可能。１点だけ要注意なのは、論理ボリュームを拡張したからといって、ファイルシステムの大きさが自動的に広がるわけではないということ。論理ボリューム（やパーティション）≠ファイルシステムであることに留意が必要。
論理ボリュームの操作に関するコマンドの多くは「lv」で始まるコマンド名になっている。
細かいことはLVMの構築方法（基本編）をみてもらうとして。
LVMを実際に使うための流れとしては…
①LVMの使用に必要なパッケージのインストール（の確認）
②ハードディスクの接続
③接続したハードディスクに物理ボリュームを作成する
④ボリュームグループを作成し、そこに先ほど作成した物理ボリュームを登録する
⑤ボリュームグループから論理ボリュームを切り出す
⑥論理ボリュームにファイルシステムを作成し、マウントして使う
というような手順を踏むことになる。
まあ、「①」については、よほど変なディストリビューションだったり古いバージョンだったりしない限りは問題ないと思うが、念のため確認しておこう。
[root@chihiro ~]# rpm -qa | fgrep lvm lvm2-2.02.32-4.el5
LVMのパッケージがセットアップされていることがこれで確認できる。
「②」は特に説明不要だと思うのでパス。まあ、接続したハードディスクがLinuxで認識されていることを確認しておこおう。方法は「/proc/partitions」の中をcatコマンドなどで見てみればよい。
[root@chihiro ~]# cat /proc/partitions major minor #blocks name 8 0 97685784 sda 8 1 265041 sda1 8 2 2096482 sda2 8 3 95321677 sda3 8 32 1271591496 sdc 8 33 1271584881 sdc1 8 16 1953546336 sdb 8 17 1953544131 sdb1 8 64 1122630768 sde 8 65 1122630201 sde1 8 80 1465159752 sdf 8 81 1465152066 sdf1 8 48 625142448 sdd 8 49 625137313 sdd1
他にdmesgとかも見ておこうね。
きちんと認識できているようなら、物理ボリュームを作成してボリュームグループを作成して論理ボリュームを作成してファイルシステムを作成してマウントして/etc/fstabを変更して完了。詳しい手順・コマンドについてはもう面倒くさくなってきたのでLVMの構築方法（基本編）を参照しる。
最後に、LVMとRAIDとの比較を簡単にまとめておく。まあ、参考程度に…ということで。
| 比較項目 | LVM | RAID JBOD | RAID 0 |
|---|---|---|---|
| 最初の構築 | 少しとっつきにくい | 割と簡単 | 難しくはない |
| 容量増設 | 簡単で動的にできる | 面倒で動的には出来ない | 面倒で動的には出来ない |
| 速度 | たかがしれてる | たかがしれてる | ハードRAIDならディスク本数が多いほど高速 |
| 信頼性 | 高くない。LVMミラーリングも出来るけど… | 高くない | １本飛んだら全滅 |
| 費用面 | チープに構築可 | 大抵は「ニコイチ」「ヨンコイチ」ケースが必要 | RAIDコントローラカードが必要。ソフトRAIDなら安いけど速度メリットは出ない。なお、同じ容量のディスクを用意する必要があるので、それ用のディスクを買ってくる必要がある。 |
| 最大容量 | やろうと思えば256台までディスクを統合できる。USB-HDDを使えばそれこそ鈴なりに（笑）まあ、Linuxの都合でそこまでつなげないとは思うけど。 | 数台を束ねる程度の物なら安価にゲットできる | ハードRAIDするなら4台とか8台とか12台とかそれくらいか？ |
mdadmでソフトRAIDを手動で起動する方法 [Linux(LVM/RAID/Storage)]
どちらかというと備忘録っぽいですが…
mdadmコマンドでソフトRAIDを構築した後、/etc/mdadm.confを作成しないと再起動時にソフトRAIDがスタートしない模様。この場合は以下のようにコマンドを投入すればよろし。
「/dev/md0」はRAIDデバイス名、「/dev/sd[d-g]1」はRAIDに参加しているディスク群のデバイス名。
RAIDの設定とかはディスクに保存されるようなので、RAID5でbuildしてあればそのままRAID5として、RAID1でbuildにしてあればそのままRAID1として起動してくる。
あとは忘れないうちに/etc/mdadm.confを作成しておきましょう。
他の方のサイトからの引用ではこんな感じで作成しる。
DEVICE句については適切に修正しましょうとのこと。
mdadmコマンドでソフトRAIDを構築した後、/etc/mdadm.confを作成しないと再起動時にソフトRAIDがスタートしない模様。この場合は以下のようにコマンドを投入すればよろし。
# mdadm --assemble /dev/md0 /dev/sd[d-g]1
「/dev/md0」はRAIDデバイス名、「/dev/sd[d-g]1」はRAIDに参加しているディスク群のデバイス名。
RAIDの設定とかはディスクに保存されるようなので、RAID5でbuildしてあればそのままRAID5として、RAID1でbuildにしてあればそのままRAID1として起動してくる。
あとは忘れないうちに/etc/mdadm.confを作成しておきましょう。
他の方のサイトからの引用ではこんな感じで作成しる。
# echo 'DEVICE /dev/sd*[0-9]' > /etc/mdadm.conf # mdadm --detail --scan >> /etc/mdadm.conf
DEVICE句については適切に修正しましょうとのこと。
LVMを構成するディスクをddでまるっとコピーするとどうなる？（前編） [Linux(LVM/RAID/Storage)]
例えば、ストレージサーバみたいなハードを使っているとして、運用系ディスク上でLVMを使っているとします。このディスクをストレージサーバが持っているような、運用系ディスクをまるっとバックアップ用ディスクにコピーしてしまう機能でコピーした場合、そのバックアップした側のディスクがどのように見えるか…というところに興味がわいたので試してみた。
とはいえ、そんな凄い環境は当然のごとく無いので、VirtualPC上で、/dev/hdb2と/dev/hdb3とを用意。
/dev/hdb2をLVMに組み込み、適当なデータを置いてみる。
ここまでで、/dev/hdb2はLVMに組み込まれた状態で稼働しているボリュームということになります。
これを/dev/hdb3にddコマンドでまるっとコピーしてみましょう。
これで、/dev/hdb2と/dev/hdb3と、同じ内容になっている「はず」。
PV UUIDが同一になっていることが判りますし、「Found duplicate PV...」と警告表示も出ていますので、物理ボリュームの情報が重複している（＝複製された）ことが判ります。
つーか、/dev/hdb2を見ているはずなのに/dev/hdb3が表示されてますよ！？＠＠；
で、ここまでやって発見その１。ボリュームグループ内に登録されている物理ボリュームが勝手に変更されている件！
さきほどのLVM構築直後のvgdisplayコマンドでは…
でも、今再びvgdisplayしてみると…
あれれれー？/dev/hdb3になってるお？
これは、PV UUIDで管理していて、ドライブデバイス名はどうでもいい…ということなんでしょうかね？
このままの状態で、うっかりファイルシステムを再マウントしてファイルを読み書きしようものなら、運用系ではなくバックアップ系のボリュームを読み書きしてしまうかもしれない？というオペミスを引き起こしそうな雰囲気が微妙にしてきましたね。
これが、マウントされたままでコピーした状態だとどうなるでしょうか。/dev/hdb3を一旦たたき壊してからやってみましょう。
…。
…。
あれ？
間違って dd if=/dev/zero of=/dev/hda3 bs=1M count=100 とかうっかりやってしまい、テストする環境をたたき壊してしまったので、続きはまた後でね！！！！＞＜；
とはいえ、そんな凄い環境は当然のごとく無いので、VirtualPC上で、/dev/hdb2と/dev/hdb3とを用意。
# fdisk /dev/hdb このディスクのシリンダ数は 66575 に設定されています。 間違いではないのですが、1024 を超えているため、以下の場合 に問題を生じうる事を確認しましょう: 1) ブート時に実行するソフトウェア (例. バージョンが古い LILO) 2) 別の OS のブートやパーティション作成ソフト (例. DOS FDISK, OS/2 FDISK) コマンド (m でヘルプ): p Disk /dev/hdb: 34.3 GB, 34359214080 bytes 16 heads, 63 sectors/track, 66575 cylinders Units = シリンダ数 of 1008 * 512 = 516096 bytes デバイス Boot Start End Blocks Id System /dev/hdb1 1 2000 1007968+ 83 Linux /dev/hdb2 2001 22001 10080504 83 Linux /dev/hdb3 22002 42002 10080504 83 Linux
/dev/hdb2をLVMに組み込み、適当なデータを置いてみる。
# pvcreate /dev/hdb2
Physical volume "/dev/hdb2" successfully created
# vgcreate vg_test /dev/hdb2
Volume group "vg_test" successfully created
# vgdisplay -v
Finding all volume groups
Finding volume group "vg_test"
--- Volume group ---
VG Name vg_test
System ID
Format lvm2
Metadata Areas 1
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 1
Act PV 1
VG Size 9.61 GB
PE Size 4.00 MB
Total PE 2461
Alloc PE / Size 0 / 0
Free PE / Size 2461 / 9.61 GB
VG UUID SqA0jd-h9fp-U5Pk-vox6-71Gh-6HtJ-fOAkRb
--- Physical volumes ---
PV Name /dev/hdb2
PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A
PV Status allocatable
Total PE / Free PE 2461 / 2461
# lvcreate vg_test -l 2461 -n vol00
Logical volume "vol00" created
# mke2fs -j /dev/vg_test/vol00
# mkdir -p /mnt/test
# mount /dev/vg_test/vol00 /mnt/test
# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/hda3 15G 1.7G 13G 12% /
/dev/hda1 122M 11M 105M 10% /boot
tmpfs 252M 0 252M 0% /dev/shm
/dev/mapper/vg_test-vol00
9.5G 150M 8.9G 2% /mnt/test
# cd /mnt/test
# cp -r /etc/* .
ここまでで、/dev/hdb2はLVMに組み込まれた状態で稼働しているボリュームということになります。
これを/dev/hdb3にddコマンドでまるっとコピーしてみましょう。
# cd # umount /mnt/test # df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/hda3 15102624 1703976 12619096 12% / /dev/hda1 124427 11126 106877 10% /boot tmpfs 257748 0 257748 0% /dev/shm # dd if=/dev/hdb2 of=/dev/hdb3 20161008+0 records in 20161008+0 records out 10322436096 bytes (10 GB) copied, 7884.98 seconds, 1.3 MB/s
これで、/dev/hdb2と/dev/hdb3と、同じ内容になっている「はず」。
# pvdisplay /dev/hdb2 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2 --- Physical volume --- PV Name /dev/hdb3 VG Name vg_test PV Size 9.61 GB / not usable 248.00 KB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 2461 Free PE 0 Allocated PE 2461 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A # pvdisplay /dev/hdb3 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb2 not /dev/hdb3 Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2 --- Physical volume --- PV Name /dev/hdb3 VG Name vg_test PV Size 9.61 GB / not usable 248.00 KB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 2461 Free PE 0 Allocated PE 2461 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A
PV UUIDが同一になっていることが判りますし、「Found duplicate PV...」と警告表示も出ていますので、物理ボリュームの情報が重複している（＝複製された）ことが判ります。
つーか、/dev/hdb2を見ているはずなのに/dev/hdb3が表示されてますよ！？＠＠；
で、ここまでやって発見その１。ボリュームグループ内に登録されている物理ボリュームが勝手に変更されている件！
さきほどのLVM構築直後のvgdisplayコマンドでは…
# vgdisplay -v （途中省略） --- Physical volumes --- PV Name /dev/hdb2 PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A PV Status allocatable Total PE / Free PE 2461 / 2461
でも、今再びvgdisplayしてみると…
vgdisplay -v
Finding all volume groups
Found duplicate PV moE0a36fLXIRjj3JcQbzC24mkO9m6c5A: using /dev/hdb3 not /dev/hdb2
Finding volume group "vg_test"
（途中省略）
--- Physical volumes ---
PV Name /dev/hdb3
PV UUID moE0a3-6fLX-IRjj-3JcQ-bzC2-4mkO-9m6c5A
PV Status allocatable
Total PE / Free PE 2461 / 0
あれれれー？/dev/hdb3になってるお？
これは、PV UUIDで管理していて、ドライブデバイス名はどうでもいい…ということなんでしょうかね？
このままの状態で、うっかりファイルシステムを再マウントしてファイルを読み書きしようものなら、運用系ではなくバックアップ系のボリュームを読み書きしてしまうかもしれない？というオペミスを引き起こしそうな雰囲気が微妙にしてきましたね。
これが、マウントされたままでコピーした状態だとどうなるでしょうか。/dev/hdb3を一旦たたき壊してからやってみましょう。
…。
…。
あれ？
間違って dd if=/dev/zero of=/dev/hda3 bs=1M count=100 とかうっかりやってしまい、テストする環境をたたき壊してしまったので、続きはまた後でね！！！！＞＜；
ぴろりん さん
-
nice! 18
記事 143
テーマ パソコン・インターネット
プロフィール
ブログを紹介する
