LVMを店じまいする（解除・後始末） [Linux(LVM/RAID/Storage)]
またえらく久しぶりに記事を追加する気がしますが、LVMで構成したストレージ領域を「店じまい」（解除というか後始末というか）する手順を紹介しておきます。
ぶっちゃけ、「アンマウントしてディスク外せば終わりじゃん！」っていう感じではあるんですけども、ディスクを外しただけだとrebootした時等にまだLVM領域が見えてしまい困るケースも無い訳では無いので、次にそのディスクを接続する事があっても、LVMとして全く認識されなくする必要が発生する…ことがある…かもしれないということで。
基本的な手順としては、
① そのディスク領域を使用しているプロセス・デーモンを停止する
② そのディスク領域に保存されているデータをどうにかする（必要に応じてコピーする等）
③ アンマウントする
④ 論理ボリュームを削除する
⑤ ボリュームグループを削除する
⑥ 物理エクステントを削除する
このうち、⑤と⑥については一つのボリュームグループ内に複数の論理ボリュームが存在し、その論理ボリュームを削除してもなお他の論理ボリュームが残っている場合には実施しません。（というかやったら消えるけどそもそもエラーになります）
では、手順を追っていきます。
① そのディスク領域を使用しているプロセス・デーモンを停止する
多分、sambaなりapacheなりnginxなりgitなりなにがしかのデーモンがそういう領域を使っていると思いますので、そいつらを始末します。
必要に応じてchkconfig あるいは systemctl でデーモンを自動起動しないようにするとか忘れずに実行します。
② そのディスク領域に保存されているデータをどうにかする（必要に応じてコピーする等）
当然、LVMの論理ボリュームを削除したらその中にあるデータも消し飛んでしまいますので、必要ならrsyncするなりscpするなり tar / cpio するなりしてデータをバックアップしておくとかコピーしておくとか実施します。
③ アンマウントする
いよいよアンマウントします。
umount /mnt/local/storage
とかそんな感じで。エラーになるようならfuserコマンドで原因となるプロセスを特定してkillしてやりましょう。
よくあるミスとしては、「自分自身がそこにcd コマンドで移動していた」なんていう事です。（大笑）
あと、/etc/fstabとかその辺も忘れずに修正しましょう。/etc/exportsとかも忘れがちだよ～。
④ 論理ボリュームを削除する
lvdisplay コマンドでサーバ上に存在するLVM論理ボリュームが確認できます。削除したい「LV Path」を確認しておきます。
[root@peorth ~]# lvdisplay
--- Logical volume ---
LV Path /dev/vgStorage/lvPrivate
LV Name lvPrivate
VG Name vgStorage
LV UUID xulASs-wZ0N-1bnl-IXxq-3yQm-vAnT-t4iM93
LV Write Access read/write
LV Creation host, time peorth, 2018-10-15 10:23:36 +0900
LV Status available
# open 1
LV Size <7.28 TiB
Current LE 1907599
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 253:2
ここでは、「/dev/vgStorage/lvPrivate」が必要な論理ボリューム名になります。なお、LVM論理ボリュームはＯＳによってはインストール時にインストーラが自動でいくつかのLVM論理ボリュームを作成します。それを間違って削除しないように気をつけましょう。（アンマウントしていなければえらーになるはずだけどね）多分、酷い目に遭います。（笑）
論理ボリュームを削除するコマンドは、 lvremove になります。このコマンドに先ほどの論理ボリューム名（LV Path）を指定して実行します。
Do you really want to remove active logical volume vgStorage/lvPrivate? [y/n]:
と、聞かれると思うので、本当に削除しても良いのなら「y」を入力しましょう。
コマンドを実行すると、 lvdisplay でももはや先ほどの論理ボリュームは表示されないはずです。
⑤ ボリュームグループを削除する
必要に応じてボリュームグループを削除します。ボリュームグループの確認方法は vgdisplay コマンドです。
[root@peorth ~]# vgdisplay
--- Volume group ---
VG Name vgStorage
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
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 <7.28 TiB
PE Size 4.00 MiB
Total PE 1907599
Alloc PE / Size 0 / 0
Free PE / Size 1907599 / <7.28 TiB
VG UUID X8BIeD-jWLi-NVT7-jnER-h3XW-5yfC-JjMw9b
このボリュームグループは、もはや全くの未使用状態になりました（Alloc PE / Size が「0」になっている）ので、遠慮なく削除します。削除する際にはボリュームグループ名が必要となりますので、「VG Name」の項目を確認しておきます。削除に用いるコマンドは vgremove です。
[root@peorth ~]# vgremove vgStorage
Volume group "vgStorage" successfully removed
これで vgdisplay コマンドを使ってもボリュームグループは表示されないはずです。
⑥ 物理エクステントを削除する
最後に、ボリュームグループに加わっていたディスクの上から物理エクステントを削除します。
物理エクステントを確認するコマンドは pvdisplay です。
[root@peorth ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sdb
VG Name
PV Size <1.89 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID sg4Q5g-HSXp-fyBF-aIVi-rVNy-3KOA-3WKGfg
Allocated PE の項目が「0」になっている物理ボリュームは全くの未使用状態になっています。そのボリュームの「PV Name」を確認しておきます。複数のディスクを束ねているような場合には、複数ボリューム分のAllocated PEとPV Nameとを確認しておきましょう。
物理エクステントを削除するコマンドは、 pvremove です。
[root@peorth ~]# pvremove /dev/sdb
Labels on physical volume "/dev/sdb" successfully wiped.
複数の物理ボリュームを指定することができます。（別に、１個ずつ実行しても害は無いけどね）
これで pvdisplay コマンドで物理ボリューム名が表示されなくなれば完了です。
当該ボリュームはもうLVMとして認識されることはありません。
「私たち、普通の女の子に戻ります！」
って感じで普通のボリュームに戻りました。（年齢踏み絵
ぶっちゃけ、「アンマウントしてディスク外せば終わりじゃん！」っていう感じではあるんですけども、ディスクを外しただけだとrebootした時等にまだLVM領域が見えてしまい困るケースも無い訳では無いので、次にそのディスクを接続する事があっても、LVMとして全く認識されなくする必要が発生する…ことがある…かもしれないということで。
基本的な手順としては、
① そのディスク領域を使用しているプロセス・デーモンを停止する
② そのディスク領域に保存されているデータをどうにかする（必要に応じてコピーする等）
③ アンマウントする
④ 論理ボリュームを削除する
⑤ ボリュームグループを削除する
⑥ 物理エクステントを削除する
このうち、⑤と⑥については一つのボリュームグループ内に複数の論理ボリュームが存在し、その論理ボリュームを削除してもなお他の論理ボリュームが残っている場合には実施しません。（というかやったら消えるけどそもそもエラーになります）
では、手順を追っていきます。
① そのディスク領域を使用しているプロセス・デーモンを停止する
多分、sambaなりapacheなりnginxなりgitなりなにがしかのデーモンがそういう領域を使っていると思いますので、そいつらを始末します。
必要に応じてchkconfig あるいは systemctl でデーモンを自動起動しないようにするとか忘れずに実行します。
② そのディスク領域に保存されているデータをどうにかする（必要に応じてコピーする等）
当然、LVMの論理ボリュームを削除したらその中にあるデータも消し飛んでしまいますので、必要ならrsyncするなりscpするなり tar / cpio するなりしてデータをバックアップしておくとかコピーしておくとか実施します。
③ アンマウントする
いよいよアンマウントします。
umount /mnt/local/storage
とかそんな感じで。エラーになるようならfuserコマンドで原因となるプロセスを特定してkillしてやりましょう。
よくあるミスとしては、「自分自身がそこにcd コマンドで移動していた」なんていう事です。（大笑）
あと、/etc/fstabとかその辺も忘れずに修正しましょう。/etc/exportsとかも忘れがちだよ～。
④ 論理ボリュームを削除する
lvdisplay コマンドでサーバ上に存在するLVM論理ボリュームが確認できます。削除したい「LV Path」を確認しておきます。
[root@peorth ~]# lvdisplay
--- Logical volume ---
LV Path /dev/vgStorage/lvPrivate
LV Name lvPrivate
VG Name vgStorage
LV UUID xulASs-wZ0N-1bnl-IXxq-3yQm-vAnT-t4iM93
LV Write Access read/write
LV Creation host, time peorth, 2018-10-15 10:23:36 +0900
LV Status available
# open 1
LV Size <7.28 TiB
Current LE 1907599
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 8192
Block device 253:2
ここでは、「/dev/vgStorage/lvPrivate」が必要な論理ボリューム名になります。なお、LVM論理ボリュームはＯＳによってはインストール時にインストーラが自動でいくつかのLVM論理ボリュームを作成します。それを間違って削除しないように気をつけましょう。（アンマウントしていなければえらーになるはずだけどね）多分、酷い目に遭います。（笑）
論理ボリュームを削除するコマンドは、 lvremove になります。このコマンドに先ほどの論理ボリューム名（LV Path）を指定して実行します。
Do you really want to remove active logical volume vgStorage/lvPrivate? [y/n]:
と、聞かれると思うので、本当に削除しても良いのなら「y」を入力しましょう。
コマンドを実行すると、 lvdisplay でももはや先ほどの論理ボリュームは表示されないはずです。
⑤ ボリュームグループを削除する
必要に応じてボリュームグループを削除します。ボリュームグループの確認方法は vgdisplay コマンドです。
[root@peorth ~]# vgdisplay
--- Volume group ---
VG Name vgStorage
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 5
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 <7.28 TiB
PE Size 4.00 MiB
Total PE 1907599
Alloc PE / Size 0 / 0
Free PE / Size 1907599 / <7.28 TiB
VG UUID X8BIeD-jWLi-NVT7-jnER-h3XW-5yfC-JjMw9b
このボリュームグループは、もはや全くの未使用状態になりました（Alloc PE / Size が「0」になっている）ので、遠慮なく削除します。削除する際にはボリュームグループ名が必要となりますので、「VG Name」の項目を確認しておきます。削除に用いるコマンドは vgremove です。
[root@peorth ~]# vgremove vgStorage
Volume group "vgStorage" successfully removed
これで vgdisplay コマンドを使ってもボリュームグループは表示されないはずです。
⑥ 物理エクステントを削除する
最後に、ボリュームグループに加わっていたディスクの上から物理エクステントを削除します。
物理エクステントを確認するコマンドは pvdisplay です。
[root@peorth ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sdb
VG Name
PV Size <1.89 TiB
Allocatable NO
PE Size 0
Total PE 0
Free PE 0
Allocated PE 0
PV UUID sg4Q5g-HSXp-fyBF-aIVi-rVNy-3KOA-3WKGfg
Allocated PE の項目が「0」になっている物理ボリュームは全くの未使用状態になっています。そのボリュームの「PV Name」を確認しておきます。複数のディスクを束ねているような場合には、複数ボリューム分のAllocated PEとPV Nameとを確認しておきましょう。
物理エクステントを削除するコマンドは、 pvremove です。
[root@peorth ~]# pvremove /dev/sdb
Labels on physical volume "/dev/sdb" successfully wiped.
複数の物理ボリュームを指定することができます。（別に、１個ずつ実行しても害は無いけどね）
これで pvdisplay コマンドで物理ボリューム名が表示されなくなれば完了です。
当該ボリュームはもうLVMとして認識されることはありません。
「私たち、普通の女の子に戻ります！」
って感じで普通のボリュームに戻りました。（年齢踏み絵
離れた場所にある２つのストレージの同期 その３のおまけ～もうちょっとハードに書き込みしてみる～ [Linux(LVM/RAID/Storage)]
「その３」でファイルを1個置いてみて確認はしてみたものの、もっとハードにファイルを書き込んでみたくなったので、reinとfineと両方で以下のようなスクリプトを実行して激しく書き込みしてみた。（笑）
これでファイルをひたすら書き込み、両方から同時にアクセスができることをしっかり確認しておこう。
もう1枚ターミナルを開いてls -la /mnt/work/testとか実行してみると…
という具合に、ファイルが同時に沢山書き込まれていることが確認できる。
while :
do
uname -a > /mnt/work/test/`uname -n``uuidgen`
done
これでファイルをひたすら書き込み、両方から同時にアクセスができることをしっかり確認しておこう。
もう1枚ターミナルを開いてls -la /mnt/work/testとか実行してみると…
[root@fine ~]# ls -la /mnt/work/test 合計 548 drwxr-xr-x 2 root root 2048 11月 15 15:31 . drwxr-xr-x 3 root root 3864 11月 15 15:24 .. -rw-r--r-- 1 root root 93 11月 15 15:31 fine020f54e6-195b-4f24-9645-cfb0d1b87ffd -rw-r--r-- 1 root root 93 11月 15 15:30 fine09f8c760-ae39-436a-9678-d79a11630040 -rw-r--r-- 1 root root 93 11月 15 15:30 fine141393f8-5374-4623-b1cc-0566bf53f478 -rw-r--r-- 1 root root 93 11月 15 15:30 fine1cb9170c-fa5c-4429-9315-051f836cbfd0 -rw-r--r-- 1 root root 93 11月 15 15:30 fine1e54c792-ef90-44d1-b251-d160190d85e2 -rw-r--r-- 1 root root 93 11月 15 15:30 fine21b4ae78-9cc3-49ef-81ca-3bbde86d47cd -rw-r--r-- 1 root root 93 11月 15 15:30 fine2282bebc-86dd-49bd-bf0f-a06eb51a9e72 -rw-r--r-- 1 root root 93 11月 15 15:30 fine25830222-800e-4f04-af2e-8fc3dfef13df -rw-r--r-- 1 root root 93 11月 15 15:30 fine29bb8b26-163c-4451-aa00-e4019587fd16 -rw-r--r-- 1 root root 93 11月 15 15:30 fine2b41a505-be42-4b9c-8801-126f10717868 -rw-r--r-- 1 root root 93 11月 15 15:30 fine2e79bc04-1d76-4246-bd26-3f9446e504bc -rw-r--r-- 1 root root 93 11月 15 15:30 fine33310032-adbb-4212-9081-5f9f32207a3a -rw-r--r-- 1 root root 93 11月 15 15:30 fine3d34441c-1ee3-4d28-a7b9-6dcfb852829e -rw-r--r-- 1 root root 93 11月 15 15:30 fine44241d81-a746-400c-9a86-8304008e3876 -rw-r--r-- 1 root root 93 11月 15 15:30 fine4cb7414c-b143-4977-8eb7-a4222a21f3b9 -rw-r--r-- 1 root root 93 11月 15 15:30 fine4d1a967e-d6b3-40a4-8fae-526c9c47a7fd -rw-r--r-- 1 root root 93 11月 15 15:30 fine4ea833e9-6185-40ed-bd5e-7a8867f7bb4f -rw-r--r-- 1 root root 93 11月 15 15:30 fine50130551-8d1b-410e-b6c3-879f29db1fa5 -rw-r--r-- 1 root root 93 11月 15 15:30 fine50ab21ef-d75c-4ef0-81f5-73d565bfa0f3 -rw-r--r-- 1 root root 93 11月 15 15:30 fine541f2e5a-ce89-4a2e-94de-1813551491fc -rw-r--r-- 1 root root 93 11月 15 15:30 fine547ff03f-6ee9-4cfd-9497-36d10d3ee810 -rw-r--r-- 1 root root 93 11月 15 15:30 fine559116f6-f703-4bcc-b0cb-2d784ba69dc7 -rw-r--r-- 1 root root 93 11月 15 15:30 fine56a0134e-6483-4962-91f1-973db4ba5680 -rw-r--r-- 1 root root 93 11月 15 15:30 fine5ba34224-052b-4c24-b7d6-feec59d84f1d -rw-r--r-- 1 root root 93 11月 15 15:30 fine5f24a6bd-38b9-435a-887f-111e7dfa9179 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6b2188a7-0f68-4927-b8b8-bac7687dca8d -rw-r--r-- 1 root root 93 11月 15 15:30 fine6d065f4f-5b80-4e3a-a07c-8e22e6b98ff0 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6e156d70-32d6-4d05-81f7-ea7d2f568806 -rw-r--r-- 1 root root 93 11月 15 15:30 fine6e3bfc04-d632-4a5e-b28a-118190bd68d1 -rw-r--r-- 1 root root 93 11月 15 15:31 fine72e7d769-8a79-47ea-ad63-4e80f583d9ec -rw-r--r-- 1 root root 93 11月 15 15:30 fine758fa94f-5176-4b69-9fe0-16769f92b568 -rw-r--r-- 1 root root 93 11月 15 15:30 fine7bf6221c-8353-4133-90ff-87233df602ce -rw-r--r-- 1 root root 93 11月 15 15:30 fine7e09cb0d-2c84-475c-91df-da265b452380 -rw-r--r-- 1 root root 93 11月 15 15:30 fine7f0b8322-c08b-4fc4-9e8f-a289b91d5896 -rw-r--r-- 1 root root 93 11月 15 15:30 fine84aa99b0-c75b-448e-9e6d-294425b3a666 -rw-r--r-- 1 root root 93 11月 15 15:30 fine89e2d111-1f2e-4714-a51c-78bb4935e283 -rw-r--r-- 1 root root 93 11月 15 15:30 fine8f04106a-a478-4c47-9b0a-b0895455d7f3 -rw-r--r-- 1 root root 93 11月 15 15:30 fine94ba56a2-d0ce-43d1-a01e-8c7bc10f0f92 -rw-r--r-- 1 root root 93 11月 15 15:30 fine99a83750-05e2-44de-a417-6d5984408e16 -rw-r--r-- 1 root root 93 11月 15 15:30 fine9a90ae1c-1c61-4544-918f-d04fb52a2122 -rw-r--r-- 1 root root 93 11月 15 15:30 finea1befcf9-be98-4f65-88aa-6af070f7f6eb -rw-r--r-- 1 root root 93 11月 15 15:30 finea4f6b961-6b57-4a44-b221-9490c0557f33 -rw-r--r-- 1 root root 93 11月 15 15:30 fineaa9c5e5e-3897-482e-9b3c-8ff12c5b10b3 -rw-r--r-- 1 root root 93 11月 15 15:30 fineaac93dc6-0485-42a7-b372-bbb5b7c40329 -rw-r--r-- 1 root root 93 11月 15 15:30 fineab4680ad-a1cc-40fd-a2ad-caa366c58a05 -rw-r--r-- 1 root root 93 11月 15 15:30 fineac6cb486-26e9-4bc1-aa6e-35a36dabf85c -rw-r--r-- 1 root root 93 11月 15 15:30 finebc0295d6-a293-4fc6-807d-5e86954d29df -rw-r--r-- 1 root root 93 11月 15 15:30 finecdcf3f7f-e854-46a8-aca9-2d3a5b065eec -rw-r--r-- 1 root root 93 11月 15 15:30 finecef23114-aab5-44ed-8f79-3b52d24cf2df -rw-r--r-- 1 root root 93 11月 15 15:30 finecf2eeaec-997b-4041-8208-a8490a84beeb -rw-r--r-- 1 root root 93 11月 15 15:30 fined17dfba1-e421-4890-a385-ba6dd9f62b61 -rw-r--r-- 1 root root 93 11月 15 15:30 fined5044510-dad9-4192-8e71-291791fdedac -rw-r--r-- 1 root root 93 11月 15 15:30 fined6b62bd3-c716-48c3-bfc7-864f6de01d46 -rw-r--r-- 1 root root 93 11月 15 15:30 fined743a9c7-e90e-40ee-b855-07834e0f98e6 -rw-r--r-- 1 root root 93 11月 15 15:30 finedd23f670-5282-45db-8490-84b74d15695d -rw-r--r-- 1 root root 93 11月 15 15:30 finedf06f755-203f-4f9e-91e3-221054fef6f5 -rw-r--r-- 1 root root 93 11月 15 15:30 finedff8c296-08f0-41d1-b10e-6739980a2f2f -rw-r--r-- 1 root root 93 11月 15 15:30 finee0ce9764-dad7-4eb1-bafd-7df849bc7b2b -rw-r--r-- 1 root root 93 11月 15 15:30 finee5feaf17-8b20-4270-9f80-660a79cbada5 -rw-r--r-- 1 root root 93 11月 15 15:30 fineeafc997a-2f23-4cb6-83f7-fb1aecac5808 -rw-r--r-- 1 root root 93 11月 15 15:30 fineee0ef138-5bcc-4b24-a57b-a13a10e7b3b1 -rw-r--r-- 1 root root 93 11月 15 15:30 finef21378a2-fb69-4b9a-a14f-795f3ace7318 -rw-r--r-- 1 root root 93 11月 15 15:30 finef73891e3-8d08-4ead-9ac8-d8b6ae459df9 -rw-r--r-- 1 root root 93 11月 15 15:31 rein00f937fe-7fcf-4613-b418-2ebf56f8e175 -rw-r--r-- 1 root root 93 11月 15 15:30 rein02657eeb-1d4b-48de-a25d-082ab3c329ce -rw-r--r-- 1 root root 93 11月 15 15:30 rein057e374a-cf8e-4255-a69c-ec02a477d8de -rw-r--r-- 1 root root 93 11月 15 15:30 rein0b019417-0169-48f2-bc16-441119b362f2 -rw-r--r-- 1 root root 93 11月 15 15:31 rein128878f8-99b2-443f-a30b-2402925e96f1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein131cf5c0-87e9-4f03-a78e-36045310a16e -rw-r--r-- 1 root root 93 11月 15 15:30 rein1a1cf207-7422-4073-881b-ce60a5e3f9d8 -rw-r--r-- 1 root root 93 11月 15 15:30 rein1bbe7f52-383c-4e41-97a0-697cd67398de -rw-r--r-- 1 root root 93 11月 15 15:30 rein1e6925da-9409-484b-9434-69dfc52edcd1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein2230892d-54b4-4d48-995d-03f7c34c5236 -rw-r--r-- 1 root root 93 11月 15 15:30 rein250bc279-d4d0-4fe7-9378-32685229acfa -rw-r--r-- 1 root root 93 11月 15 15:30 rein27067fdd-8060-437e-80ed-b401215221fa -rw-r--r-- 1 root root 93 11月 15 15:30 rein2a7d89cb-11f6-4ba5-85a1-f53522f60a75 -rw-r--r-- 1 root root 93 11月 15 15:31 rein2aacc0ab-edd5-4b9e-93c4-8f83288c8791 -rw-r--r-- 1 root root 93 11月 15 15:30 rein2be05eb8-de21-4f9e-b6b5-c96eb05c2762 -rw-r--r-- 1 root root 93 11月 15 15:30 rein343839e2-62d3-4a75-ab0d-5520051e3c6d -rw-r--r-- 1 root root 93 11月 15 15:30 rein3a3ff93e-1c18-4d22-a5c3-ac53d8fbd6ad -rw-r--r-- 1 root root 93 11月 15 15:30 rein3c63ae8f-c595-4fad-8c54-a1b6241c8dc6 -rw-r--r-- 1 root root 93 11月 15 15:31 rein3cc0c01c-b7e3-4a86-abb0-892f527b9dc7 -rw-r--r-- 1 root root 93 11月 15 15:31 rein3ea2440d-224a-477d-b56e-a416d5c8fcfb -rw-r--r-- 1 root root 93 11月 15 15:31 rein3f9ebeed-50fc-439f-8afa-05dd01711d12 -rw-r--r-- 1 root root 93 11月 15 15:31 rein40d2e874-4f23-4047-b82b-0f0a695ea635 -rw-r--r-- 1 root root 93 11月 15 15:30 rein4c6a5a13-1751-4a81-8944-74d646cdfdb1 -rw-r--r-- 1 root root 93 11月 15 15:30 rein52a52616-33c5-432c-afe4-4b2119b48994 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5319b164-4e83-4621-8f96-ff77c9e3533a -rw-r--r-- 1 root root 93 11月 15 15:31 rein58fdc617-0eef-4593-8fa1-d2ac5991c971 -rw-r--r-- 1 root root 93 11月 15 15:31 rein59c543a4-cc4f-4786-83b5-34dd8e482689 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5ac6319b-6238-4136-8b48-682c36dc7313 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5e0ac165-5977-4db3-a989-9add26c23e59 -rw-r--r-- 1 root root 93 11月 15 15:30 rein5ef04f24-16ff-472e-bc50-c6fa700dc639 -rw-r--r-- 1 root root 93 11月 15 15:31 rein72082469-3c28-4108-bfbd-9a22e10edd4d -rw-r--r-- 1 root root 93 11月 15 15:30 rein739fe3f6-def2-4e58-8621-095e962d6fca -rw-r--r-- 1 root root 93 11月 15 15:30 rein78adf4a3-b095-40e7-b950-03750b119e71 -rw-r--r-- 1 root root 93 11月 15 15:30 rein7d3b8e5a-34e8-485e-af0a-dca5a7ae84bd -rw-r--r-- 1 root root 93 11月 15 15:30 rein80aa70fc-3d22-4ba4-8270-24237a2e3a4b -rw-r--r-- 1 root root 93 11月 15 15:30 rein83e688c6-a1ea-4db7-a7bb-8e3ae52cf543 -rw-r--r-- 1 root root 93 11月 15 15:31 rein86ba7cdf-c6a4-4e42-aab5-917a4f563108 -rw-r--r-- 1 root root 93 11月 15 15:30 rein8c308a3d-83c3-486c-b0aa-85c41b3c5a4b -rw-r--r-- 1 root root 93 11月 15 15:30 rein8f7d2d89-8abd-4ee6-9e45-e52947a9aa88 -rw-r--r-- 1 root root 93 11月 15 15:31 rein955d927a-db6f-41b7-bb42-b00a8c4dcc18 -rw-r--r-- 1 root root 93 11月 15 15:31 rein9b1dc4b7-3458-47f2-acc7-36a541ad184c -rw-r--r-- 1 root root 93 11月 15 15:30 rein9e4f62fa-bf5a-41aa-b34b-7eecf22bd9f1 -rw-r--r-- 1 root root 93 11月 15 15:30 reina0c86554-8e99-41b6-bc95-a03a7593d044 -rw-r--r-- 1 root root 93 11月 15 15:30 reina3d80147-5463-4f45-a9d9-4534bf2163e3 -rw-r--r-- 1 root root 93 11月 15 15:30 reinadcca1a8-f8f9-4288-b825-4e695c2c9475 -rw-r--r-- 1 root root 93 11月 15 15:30 reinb2c15117-da75-4f0e-b1df-773059523e1e -rw-r--r-- 1 root root 93 11月 15 15:30 reinb504886d-f3b9-4ad1-9cb2-e0278ee064f4 -rw-r--r-- 1 root root 93 11月 15 15:30 reinb722f38e-8e57-4a8d-b8c2-e6239a57e6ba -rw-r--r-- 1 root root 93 11月 15 15:30 reinbadbd91d-5e84-4517-a36a-6f6ee3095679 -rw-r--r-- 1 root root 93 11月 15 15:31 reinbd21184a-9466-4c0a-a36a-80e77272dd1a -rw-r--r-- 1 root root 93 11月 15 15:30 reinc064282a-0da7-4079-8d2b-b0916419aecb -rw-r--r-- 1 root root 93 11月 15 15:30 reinc13881b0-f90a-4709-b7c2-bdd936ae0a62 -rw-r--r-- 1 root root 93 11月 15 15:30 reinc2256c89-e748-42f0-aa4c-9542ec6dd08b -rw-r--r-- 1 root root 93 11月 15 15:30 reinca69cf79-cf89-41c5-9f1d-661e7e708e5b -rw-r--r-- 1 root root 93 11月 15 15:30 reincf300319-f5e2-417a-a55e-d2f24b64fa77 -rw-r--r-- 1 root root 93 11月 15 15:30 reind05e880b-576a-4037-8cfc-ce165f8b564d -rw-r--r-- 1 root root 93 11月 15 15:30 reind6df0ac4-ffc1-4477-9650-6027d8cd4437 -rw-r--r-- 1 root root 93 11月 15 15:30 reind90728d1-de74-4175-b6e6-98b1395f17d9 -rw-r--r-- 1 root root 93 11月 15 15:31 reindf840098-78c1-4846-941d-f4cdcc130041 -rw-r--r-- 1 root root 93 11月 15 15:30 reindf9ed5c1-4ab5-4448-a09a-973d517435d3 -rw-r--r-- 1 root root 93 11月 15 15:30 reine117018e-76ed-415b-a650-617bf3d7f276 -rw-r--r-- 1 root root 93 11月 15 15:30 reine377bca4-c462-4587-ac0b-21de83cee585 -rw-r--r-- 1 root root 93 11月 15 15:30 reine3a886d1-64d8-4ebe-8307-b9eca2678561 -rw-r--r-- 1 root root 93 11月 15 15:31 reinead72745-0ba1-49c0-b394-4e4dc662d29e -rw-r--r-- 1 root root 93 11月 15 15:31 reinee88d638-a1d3-4da5-8827-2b7a51ad2393 -rw-r--r-- 1 root root 93 11月 15 15:30 reinf8fbf2d9-07ff-4ada-a2bf-ecf6a367d806 -rw-r--r-- 1 root root 93 11月 15 15:30 reinfca56832-b09d-4358-be90-41d3563d662d -rw-r--r-- 1 root root 93 11月 15 15:30 reinfe85813c-0aaa-4c18-a161-5f78e67ff522
という具合に、ファイルが同時に沢山書き込まれていることが確認できる。
離れた場所にある２つのストレージの同期 その３～共用アクセス可能なファイルシステムを作成する～ [Linux(LVM/RAID/Storage)]
drbdを用いて両方のサーバから同時にアクセス可能なボリュームを作成できたので、今度は、両方のサーバから同時にアクセス可能なファイルシステムを作成することとします。
細かいことは割愛しますが、ext3はダメなので他のファイルシステムを使用しなければなりません。共有ボリュームに同時アクセスの可能なファイルシステムとしてよく知られている物としては…
１：GFS2 (Global File System)
２：ocfs2 （Oracle Cluster File System）
あたり。残念なことに、今テスト環境として構築しているCentOS5.7の環境ではocfs2はサクッとyumっちゃうことが出来ないので、GFS2でいくより他はなさそう。
「No Matches found」という表示が寂しい。
GFS2ならCentOSのオリジナルにあたるRedHat Linuxが対応しているくらいなのでCentOSでも問題無くいけることでしょう。
と、いう訳で、GFS2でいくことに大決定。
手順としては以下の通りか。
① 必要なパッケージをyumでサクッとインストール
② cmanまわりの設定
③ clvmまわりの設定
④ GFS2でファイルシステムを作成
⑤ マウント
ではレッツトライ。
① 必要なパッケージをyumでサクッとインストール。
yumでインストールするなら、yum install kmod-gfs gfs2-utils cman lvm2-cluster あたりをインストール。「lvm2」は最初から入っていると思うので書いてないが、書いても特に害はないので心配性な人はlvm2も書いて差し支えない。
② cmanまわりの設定
/etc/cluster/cluster.conf を書く。XMLファイルなので面倒くさい。ちなみにGUIでサポートしてくれるものもあるが、そんなゆとり教育は（ｒｙ
RedHatの公式・英文なドキュメントに四苦八苦しながらも、以下のような内容を記述。おそらくこれが最低限の内容じゃないかと思われる。
ちなみにこのファイルは両方のサーバに設置する。
設置したら、service cman start（または「restart」）で設定を反映しておく。
あと、忘れずにchkconfig cman onとかも実行。
③ clvmまわりの設定
続いて、clvm（クラスタ対応のlvm）まわりの設定。
ロック方法の設定と、lvmの書き込みキャッシュの設定を変更すればよい。変更するファイルは/etc/lvm/lvm.confである。
デフォルトでは「locking_type = 1」と記述されている（はず）なので、これを「locking_type = 3」に変更する。
さらに、「write_cache_state = 1」と記述されている箇所を「write_cache_state = 0」と書き換える。
また、drbdより先にlvmがボリュームを握ってしまう現象を回避するため、フィルター設定も変更する。まず、オリジナルのフィルター部分の記述は…
と記述されている（はず）。これは、「全てのデバイスについてpvscanしまくる」ということを言っている。しかし、drbdの起動より先に、生のデバイスについてpvscanされてしまうと、drbdが起動する際にエラーとなってしまうので、/dev/drbd*についてはpvscanをしてほしいがdrbdが使用する領域についてはpvscanしないで欲しいのである。そこで、テスト環境の場合は
と、なっていてhda*についてはOSの起動用ディスクなのでpvscanをしてほしいがhdb*以降についてはpvscanなどしないで欲しい。しかしdrbd*についてはpvscanをして欲しいので、filterの設定を以下のように修正する必要が生じる。
変更したら、キャッシュファイルを手動で削除するため、rm -f /etc/lvm/cache/.cacheを実行し、service clvmd start（または「restart」）で設定を反映しておく。
こちらも同様にchkconfig clvmd onを忘れずに。
④ GFS2でファイルシステムを作成
いよいよ、ファイルシステムを作成する。まずはlvmの操作から。なお、drbdの公式サイトの情報では以下のコマンドを「両方のサーバで実行する」ようなことが書いてあるんだけども、個人的には片方でよくね？とも思うんだけどどうだろう…。
lvmについては通常の手順通り。
これでlvmの論理ボリュームを作成すれば、clvmが即座に相手側サーバに伝達する模様。公式サイトには「--clustered y」の記述が無いが、コレがないと同時に書き込みしたときにサーバが返事をしなくなる模様。（へんじがない。ただのしかばねのようだ。）
mkfsする際はクラスタ用にいくつかオプションが増えることに注意する。
「-t gfs2」は、ファイルシステムの指定。
「-p lock_dlm」はロックマネージャの指定。
「-t fushigiStar:ShareVolume」はロックテーブルの名前を指定する。fushigiStarは/etc/cluster/cluster.confに記述したクラスタシステム名。ShareVolumeはクラスタシステム内で一意の名前であればよいとのこと。
さあ！それでは両方で同時にマウントしてみましょう！！！！！！！！
まずはrein側！！
そしてfine側！！
というわけで、まずは同時にマウント出来ました。
/mnt/work/testというディレクトリを作成し、両方のサーバからこのディレクトリにファイルを保存して、相手側サーバで作成したファイルをそれぞれ確認してみましょう。
まずはrein側
そしてfine側
おっおっおっ ＾ω＾
うまくいってるくさいお ＾ω＾
細かいことは割愛しますが、ext3はダメなので他のファイルシステムを使用しなければなりません。共有ボリュームに同時アクセスの可能なファイルシステムとしてよく知られている物としては…
１：GFS2 (Global File System)
２：ocfs2 （Oracle Cluster File System）
あたり。残念なことに、今テスト環境として構築しているCentOS5.7の環境ではocfs2はサクッとyumっちゃうことが出来ないので、GFS2でいくより他はなさそう。
[root@rein cluster]# yum search ocfs Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: www.ftp.ne.jp * extras: www.ftp.ne.jp * updates: www.ftp.ne.jp Warning: No matches found for: ocfs No Matches found
「No Matches found」という表示が寂しい。
GFS2ならCentOSのオリジナルにあたるRedHat Linuxが対応しているくらいなのでCentOSでも問題無くいけることでしょう。
[root@rein cluster]# yum search gfs
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: www.ftp.ne.jp
* extras: www.ftp.ne.jp
* updates: www.ftp.ne.jp
====================================== Matched: gfs ======================================
（略）
Global_File_System-ja-JP.noarch : Global File System
（略）
e2fsprogs.i386 : Utilities for managing the second and third extended (ext2/ext3)
: filesystems
e4fsprogs.i386 : Utilities for managing the fourth extended (ext4) filesystem
gfs-utils.i386 : Utilities for managing the global filesystem (GFS)
gfs2-utils.i386 : Utilities for managing the global filesystem (GFS)
gnbd.i386 : GFS's Network Block Device
kmod-gfs.i686 : gfs kernel module(s)
kmod-gfs-PAE.i686 : gfs kernel module(s)
kmod-gfs-xen.i686 : gfs kernel module(s)
と、いう訳で、GFS2でいくことに大決定。
手順としては以下の通りか。
① 必要なパッケージをyumでサクッとインストール
② cmanまわりの設定
③ clvmまわりの設定
④ GFS2でファイルシステムを作成
⑤ マウント
ではレッツトライ。
① 必要なパッケージをyumでサクッとインストール。
yumでインストールするなら、yum install kmod-gfs gfs2-utils cman lvm2-cluster あたりをインストール。「lvm2」は最初から入っていると思うので書いてないが、書いても特に害はないので心配性な人はlvm2も書いて差し支えない。
② cmanまわりの設定
/etc/cluster/cluster.conf を書く。XMLファイルなので面倒くさい。ちなみにGUIでサポートしてくれるものもあるが、そんなゆとり教育は（ｒｙ
RedHatの公式・英文なドキュメントに四苦八苦しながらも、以下のような内容を記述。おそらくこれが最低限の内容じゃないかと思われる。
<?xml version="1.0"?>
<cluster name="fushigiStar" config_version="1">
<clusternodes>
<clusternode name="rein" nodeid="1">
</clusternode>
<clusternode name="fine" nodeid="2">
</clusternode>
</clusternodes>
</cluster>
ちなみにこのファイルは両方のサーバに設置する。
設置したら、service cman start（または「restart」）で設定を反映しておく。
あと、忘れずにchkconfig cman onとかも実行。
③ clvmまわりの設定
続いて、clvm（クラスタ対応のlvm）まわりの設定。
ロック方法の設定と、lvmの書き込みキャッシュの設定を変更すればよい。変更するファイルは/etc/lvm/lvm.confである。
デフォルトでは「locking_type = 1」と記述されている（はず）なので、これを「locking_type = 3」に変更する。
さらに、「write_cache_state = 1」と記述されている箇所を「write_cache_state = 0」と書き換える。
また、drbdより先にlvmがボリュームを握ってしまう現象を回避するため、フィルター設定も変更する。まず、オリジナルのフィルター部分の記述は…
filter = [ "a/.*/" ]
と記述されている（はず）。これは、「全てのデバイスについてpvscanしまくる」ということを言っている。しかし、drbdの起動より先に、生のデバイスについてpvscanされてしまうと、drbdが起動する際にエラーとなってしまうので、/dev/drbd*についてはpvscanをしてほしいがdrbdが使用する領域についてはpvscanしないで欲しいのである。そこで、テスト環境の場合は
[root@fine test]# cat /proc/partitions major minor #blocks name 3 0 16777152 hda 3 1 104391 hda1 3 2 16667437 hda2 3 64 16777152 hdb 3 65 16777120 hdb1 253 0 15073280 dm-0 253 1 1572864 dm-1 147 0 16776572 drbd0 253 2 16773120 dm-2
と、なっていてhda*についてはOSの起動用ディスクなのでpvscanをしてほしいがhdb*以降についてはpvscanなどしないで欲しい。しかしdrbd*についてはpvscanをして欲しいので、filterの設定を以下のように修正する必要が生じる。
filter = [ "a/drbd.*/", "a/hda.*/", "r/.*/" ]
変更したら、キャッシュファイルを手動で削除するため、rm -f /etc/lvm/cache/.cacheを実行し、service clvmd start（または「restart」）で設定を反映しておく。
こちらも同様にchkconfig clvmd onを忘れずに。
④ GFS2でファイルシステムを作成
いよいよ、ファイルシステムを作成する。まずはlvmの操作から。なお、drbdの公式サイトの情報では以下のコマンドを「両方のサーバで実行する」ようなことが書いてあるんだけども、個人的には片方でよくね？とも思うんだけどどうだろう…。
lvmについては通常の手順通り。
pvcreate /dev/drbd0 vgcreate --clustered y vgShareDrbd /dev/drbd0 lvcreate -l 100%VG -n lvData vgShareDrbd
これでlvmの論理ボリュームを作成すれば、clvmが即座に相手側サーバに伝達する模様。公式サイトには「--clustered y」の記述が無いが、コレがないと同時に書き込みしたときにサーバが返事をしなくなる模様。（へんじがない。ただのしかばねのようだ。）
mkfsする際はクラスタ用にいくつかオプションが増えることに注意する。
mkfs -t gfs2 -p lock_dlm -j 2 -t fushigiStar:ShareVolume /dev/vgShareDrbd/lvData
「-t gfs2」は、ファイルシステムの指定。
「-p lock_dlm」はロックマネージャの指定。
「-t fushigiStar:ShareVolume」はロックテーブルの名前を指定する。fushigiStarは/etc/cluster/cluster.confに記述したクラスタシステム名。ShareVolumeはクラスタシステム内で一意の名前であればよいとのこと。
さあ！それでは両方で同時にマウントしてみましょう！！！！！！！！
まずはrein側！！
[root@rein lvm]# mount -t gfs2 /dev/vgShareDrbd/lvData /mnt/work
[root@rein lvm]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/mapper/vgShareDrbd-lvData
16G 259M 16G 2% /mnt/work
そしてfine側！！
[root@fine lvm]# mount -t gfs2 /dev/vgShareDrbd/lvData /mnt/work
[root@fine lvm]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/mapper/vgShareDrbd-lvData
16G 259M 16G 2% /mnt/work
というわけで、まずは同時にマウント出来ました。
/mnt/work/testというディレクトリを作成し、両方のサーバからこのディレクトリにファイルを保存して、相手側サーバで作成したファイルをそれぞれ確認してみましょう。
まずはrein側
[root@rein ~]# mkdir /mnt/work/test [root@rein ~]# uname -a > /mnt/work/test/rein [root@rein ~]# cat /mnt/work/test/fine Linux fine 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:20:37 EDT 2011 i686 athlon i386 GNU/Linux
そしてfine側
[root@fine lvm]# uname -a > /mnt/work/test/fine [root@fine lvm]# cat /mnt/work/test/rein Linux rein 2.6.18-274.7.1.el5 #1 SMP Thu Oct 20 16:20:37 EDT 2011 i686 athlon i386 GNU/Linux
おっおっおっ ＾ω＾
うまくいってるくさいお ＾ω＾
離れた場所にある２つのストレージの同期 その２～デュアルプライマリモードに設定する～ [Linux(LVM/RAID/Storage)]
検証用環境をVirtualPCで２サーバ作成して実行しているため、drbdのディスク同期が猛烈に遅くて重いので、夜間ほったらかして同期実行をさせていたら、Windows Updateの自動更新でPCが勝手に再起動してしまい、また１から同期をすることになってしまって悲しい今日この頃、皆様いかがお過ごしでしょうか。（滝涙）
さて、前アーティクルでdrbdをごく普通にセットアップしたので今回は両方のサーバから同時に更新できるようにするためdrbdを「デュアルプライマリモード」にすることとします。
結論から言ってしまうと、物凄くあっけないです。（笑）
手順を確認しますと、以下のような感じ。
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
② 両サーバにてdrbdの切断＆再接続＆プライマリ昇格を実行（コマンド３発）
こんだけ。drbd.confへの追記内容も非常に簡単で拍子抜けします。（笑）
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
drbd.confに以下を追記します。場所は「resource」ブロックの中。（外でもいいみたいですが、リソースが1個しかないのでどちらでも一緒。一応ここではブロックの中に書いています。）
意味としては「net」ブロックでデュアルプライマリモードの動作を許可して、「startup」ブロックで両方のサーバが起動時にプライマリモードになるように設定しています。こんだけ。これを「resource」ブロックの中に記述するだけです。
念のため、今回のテスト環境におけるdrbd.confを晒しておくと…
という具合。
なお、このファイルはreinとfineと両方に同じファイルを置く必要がある。片方で編集したら、scpなりなんなりしてやればよろしいかと。
② 両サーバにてdrbdの切断＆再接続＆プライマリ昇格を実行（コマンド３発）
で、drbd.confの編集と配布が終わったら、この内容を反映させるべくコマンドを3発ほど投入する。
これらのコマンドは両方のサーバで実行する必要がある。
作業としてはたったこれだけ。簡単ですなあ。
では、drbdの状態を確認してみることにする。/proc/drbdを見れば一目瞭然。
「ro:Primary/Primary」という表示部分がソレ。ロールが両方のサーバ共に「Primary」となっている。ちなみに前アーティクルでは「ro:Primary/Secondary」となっていたので、明らかにロールが異なっていることが確認できよう。
では、両方のサーバで同じボリュームをマウントしてみよう…。
なお、先に断っておくがまだこの状態では双方のサーバから「同時に」ファイルやディレクトリのアクセス・更新は出来ないので要注意。なぜなら前アーティクルで/dev/drbd0の領域を「ext3」でフォーマットしているが、ext3は複数のサーバから同時にアクセスされることを想定していないファイルシステムなので、ファイルやディレクトリを破壊してしまう恐れがある。この対策は次アーティクルで。
…という訳なので、確認の内容としては前アーティクルでやったような「プライマリ・セカンダリの切り替えをすることなく」mount/umountできるということにとどまる。
まず、reinでマウントしてみよう。
はい。きちんと確認できました。
では、fine側でも同じ事をしてみます。この時drbdadmコマンドでprimary/secondaryの切り替えを行わないでマウント出来ることに注目。
コマンドプロンプトのサーバ名の所をエディタか何かで書き換えたんじゃないか？と思うような全く同じ結果になっていますな。（笑）
このように、両方のサーバから同じデータにアクセスできるということが確認できました。
次は両方のボリュームを同時にマウントして、同時にアクセスできるようにします。
さて、前アーティクルでdrbdをごく普通にセットアップしたので今回は両方のサーバから同時に更新できるようにするためdrbdを「デュアルプライマリモード」にすることとします。
結論から言ってしまうと、物凄くあっけないです。（笑）
手順を確認しますと、以下のような感じ。
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
② 両サーバにてdrbdの切断＆再接続＆プライマリ昇格を実行（コマンド３発）
こんだけ。drbd.confへの追記内容も非常に簡単で拍子抜けします。（笑）
① /etc/drbd.confにデュアルプライマリモード用の設定を追加する
drbd.confに以下を追記します。場所は「resource」ブロックの中。（外でもいいみたいですが、リソースが1個しかないのでどちらでも一緒。一応ここではブロックの中に書いています。）
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
意味としては「net」ブロックでデュアルプライマリモードの動作を許可して、「startup」ブロックで両方のサーバが起動時にプライマリモードになるように設定しています。こんだけ。これを「resource」ブロックの中に記述するだけです。
念のため、今回のテスト環境におけるdrbd.confを晒しておくと…
include "/etc/drbd.d/global_common.conf";
include "/etc/drbd.d/*.res";
resource r0 {
net {
allow-two-primaries;
}
startup {
become-primary-on both;
}
on rein {
device /dev/drbd0;
disk /dev/hdb1;
address ***.***.***.241:7789;
meta-disk internal;
}
on fine {
device /dev/drbd0;
disk /dev/hdb1;
address ***.***.***.242:7789;
meta-disk internal;
}
}
という具合。
なお、このファイルはreinとfineと両方に同じファイルを置く必要がある。片方で編集したら、scpなりなんなりしてやればよろしいかと。
② 両サーバにてdrbdの切断＆再接続＆プライマリ昇格を実行（コマンド３発）
で、drbd.confの編集と配布が終わったら、この内容を反映させるべくコマンドを3発ほど投入する。
drbdadm disconnect r0 drbdadm connect r0 drbdadm primary r0
これらのコマンドは両方のサーバで実行する必要がある。
作業としてはたったこれだけ。簡単ですなあ。
では、drbdの状態を確認してみることにする。/proc/drbdを見れば一目瞭然。
[root@rein ~]# cat /proc/drbd
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r----
ns:480676 nr:8 dw:76 dr:597401 al:0 bm:36 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:3399932
[=>..................] sync'ed: 12.5% (3399932/3880540)K delay_probe: 658127
finish: 1:46:14 speed: 416 (308) K/sec
「ro:Primary/Primary」という表示部分がソレ。ロールが両方のサーバ共に「Primary」となっている。ちなみに前アーティクルでは「ro:Primary/Secondary」となっていたので、明らかにロールが異なっていることが確認できよう。
では、両方のサーバで同じボリュームをマウントしてみよう…。
なお、先に断っておくがまだこの状態では双方のサーバから「同時に」ファイルやディレクトリのアクセス・更新は出来ないので要注意。なぜなら前アーティクルで/dev/drbd0の領域を「ext3」でフォーマットしているが、ext3は複数のサーバから同時にアクセスされることを想定していないファイルシステムなので、ファイルやディレクトリを破壊してしまう恐れがある。この対策は次アーティクルで。
…という訳なので、確認の内容としては前アーティクルでやったような「プライマリ・セカンダリの切り替えをすることなく」mount/umountできるということにとどまる。
まず、reinでマウントしてみよう。
[root@rein ~]# mount /dev/drbd0 /mnt/work
[root@rein ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/drbd0 16G 222M 15G 2% /mnt/work
[root@rein ~]# find /mnt/work/etc -print | head
/mnt/work/etc
/mnt/work/etc/fonts
/mnt/work/etc/fonts/fonts.dtd
/mnt/work/etc/fonts/conf.d
/mnt/work/etc/fonts/conf.d/60-latin.conf
/mnt/work/etc/fonts/conf.d/80-delicious.conf
/mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf
/mnt/work/etc/fonts/conf.d/69-unifont.conf
/mnt/work/etc/fonts/conf.d/90-synthetic.conf
/mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
[root@rein ~]# umount /mnt/work
はい。きちんと確認できました。
では、fine側でも同じ事をしてみます。この時drbdadmコマンドでprimary/secondaryの切り替えを行わないでマウント出来ることに注目。
[root@fine ~]# mount /dev/drbd0 /mnt/work
[root@fine ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/drbd0 16G 222M 15G 2% /mnt/work
[root@fine ~]# find /mnt/work/etc -print | head
/mnt/work/etc
/mnt/work/etc/fonts
/mnt/work/etc/fonts/fonts.dtd
/mnt/work/etc/fonts/conf.d
/mnt/work/etc/fonts/conf.d/60-latin.conf
/mnt/work/etc/fonts/conf.d/80-delicious.conf
/mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf
/mnt/work/etc/fonts/conf.d/69-unifont.conf
/mnt/work/etc/fonts/conf.d/90-synthetic.conf
/mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
[root@fine ~]# umount /mnt/work
コマンドプロンプトのサーバ名の所をエディタか何かで書き換えたんじゃないか？と思うような全く同じ結果になっていますな。（笑）
このように、両方のサーバから同じデータにアクセスできるということが確認できました。
次は両方のボリュームを同時にマウントして、同時にアクセスできるようにします。
離れた場所にある２つのストレージの同期 その１～drbdのインストールとセットアップ～ [Linux(LVM/RAID/Storage)]
離れた場所にある（隣り合っててもいいんだけど…）２つのサーバがあるとして、そのストレージ領域の内容を同期したいんだけどどうすればいいか…ということを考えるとき、まずもっともアンチョクな方法としては
定期的にrsyncすればよくね？
ってのがありますな。
１日に１回とか、数時間に１回とかにrsyncを実行すればよろしいかと。
ところが、この方法では注意しておかないと「どっちかが原本」で、「どっちかがコピー」というような運用になってしまう。しかし場合によっては「どちら側からでも原本としてアクセスできないものか」という需要もあろう。例えば会社だったら本社と支社との間をＶＰＮでつなげておいて両方から単一の共有ディスクにアクセスさせたいが、ＶＰＮごしにアクセスすると死ぬほど遅いなんてこともあり得るので、両方の拠点にストレージサーバを置いて、そのストレージサーバ間で常時同期を取ったりできないか？ みたいなケース。
これ、結構需要あるんだよねー。例えば「同じExcelのデータを両方で見たり書いたりしたい」とかさー。
そんな訳で、物は試しに、「drbdのデュアルプライマリーモード」を使って、それっぽい環境を作れないか試してみた。
まずは、何はなくともdrbdをインストールしてセットアップするところから。
まず、用意した環境は（本当に遠隔地の環境を用意するのはとっても面倒くさいので）VirtualPCにCentOSなサーバを２個用意。
サーバA：rein
サーバB：fine
ということにでもしておこうか。
まずは、両方のサーバでdrbdをインストール。
はい。インストール終了。ラクチンポンである。（笑）
ちなみに、drbdが使用する領域は独立したボリュームかパーティションである必要があるそうなので、fdiskでパーティションを作るなりしてこれを用意する。
今回はVirtualPCを使っているので、一本目のディスク/dev/hdaはOSが入っている。二本目のディスク/dev/hdbをdrbd用に用意。fdiskで/dev/hdb1を作成している。
↓こんな感じ。
次に、drbdの設定を行う。drbd公式サイトの情報を見て、ひとまず/etc/drbd.confに以下の通り記述した。
「include」はグローバル設定項目とかを読み込んでくる呪文。ひとまず詳しいことは割愛する。
「resource」で始まるブロックが、今回準備するdrbdで使用するディスクリソースの内容。「r0」と記述してあるのがリソース名。
「on」で始まるブロックが、個々のサーバで使用するリソースの設定。「rein」と「fine」がサーバ名。/etc/hostsやDNSにしっかり指定しておくこと。後の項目は空気が読める人なら説明不要かと思うが（察して！）、addressについてはIPアドレスで記述している。ここは/etc/hostsやDNSでの設定ときれいに一致させておくように。
さて、これでdrbdについては必要最低限の設定が完了したので、
①両ホストのdrbdデバイスにメタデータ領域を作成する
②両方ストのdrbdデバイス（リソース）をそれぞれアタッチする
③両ホストのdrbdデバイス（リソース）に対して同期を指示する（まだ同期しない）
④両ホストのdrbdどうしを接続させる
⑤ディスクの同期を開始する
という手順を踏む。
①両ホストのdrbdデバイスにメタデータ領域を作成する
これはコマンド一発でおわる。
②両方ストのdrbdデバイス（リソース）をそれぞれアタッチする
これもコマンド一発。
正常終了時なら何も表示されないので心配しないように。
③両ホストのdrbdデバイス（リソース）に対して同期を指示する（まだ同期しない）
これもコマンド一発。しかも無言。（笑）
④両ホストのdrbdどうしを接続させる
これも以下略
⑤ディスクの同期を開始する
さて、ここまで①～④については両方のホストで同じコマンドを実行するのだが、この項目についてはどちらか一方（原本になる方）だけで実行するので注意すること。ぶっちゃけ、まだディスクの中身は空っぽなので、どちらでやっても構わないのだが。
これを実行すると、両サーバ間でディスクの内容が同期される。イメージとしてはRAID0のミラーを最初に同期しにいくような感じだろうか。
同期の状態は/proc/drbdの中を見れば確認できる。
…。結構かかるなあ。（笑）
なお、drbdの同期が実行中であっても、mdadmと同様に直ちにこのボリュームを使用することも可能だ。
ためしに、このボリュームをフォーマットしてマウントしてみよう。
…さすがに、VirtualPCで２個サーバを起動してdrbdの同期中にこんなこと実行すると超重い。（笑）
まずはrein側で、ディスクをマウントしてみた。ちゃんと領域が見えていることが判る。
ここに何かファイルを置いてみよう。
こんな感じでファイルを置いてみた。（重い！：笑）
では、これを対向側のfineで見てみよう。
そうそう。今はext3でファイルシステムを作成しているので、対向側でマウントする前に、アンマウントしておかないといけない。同時にこのファイルシステムは使えないのだ。（対策は後ほど）
また、今回reinが「Primary」で、fineが「Secondary」になっているので、これもひっくり返さなければならない。（今はまだ「シングルプライマリモード」で動作しているため。
rein側でアンマウントと、Secondaryにするためのコマンドを投入する。
と、した後で、さっそく対向側のfineをPrimaryにしてからマウントしてみよう。
マウントできた。fine側ではファイルシステムを作成していないのにマウントできている。ということは、rein側の変更内容が確かに伝わっているということが判る。
ディスクの中身も確認してみよう。
内容も確認できている。
reinとfineは/dev/drbd0デバイスによって同じ内容が確認できる状態になった。
しかし、今はまだ同時に読み書き出来る状態にはないので、次のアーティクルでは両方から同時にアクセスが通るようにしたい。（多分その「前編」になるかな…）
それにしても…PC重いぜ…（笑）
定期的にrsyncすればよくね？
ってのがありますな。
１日に１回とか、数時間に１回とかにrsyncを実行すればよろしいかと。
ところが、この方法では注意しておかないと「どっちかが原本」で、「どっちかがコピー」というような運用になってしまう。しかし場合によっては「どちら側からでも原本としてアクセスできないものか」という需要もあろう。例えば会社だったら本社と支社との間をＶＰＮでつなげておいて両方から単一の共有ディスクにアクセスさせたいが、ＶＰＮごしにアクセスすると死ぬほど遅いなんてこともあり得るので、両方の拠点にストレージサーバを置いて、そのストレージサーバ間で常時同期を取ったりできないか？ みたいなケース。
これ、結構需要あるんだよねー。例えば「同じExcelのデータを両方で見たり書いたりしたい」とかさー。
そんな訳で、物は試しに、「drbdのデュアルプライマリーモード」を使って、それっぽい環境を作れないか試してみた。
まずは、何はなくともdrbdをインストールしてセットアップするところから。
まず、用意した環境は（本当に遠隔地の環境を用意するのはとっても面倒くさいので）VirtualPCにCentOSなサーバを２個用意。
サーバA：rein
サーバB：fine
ということにでもしておこうか。
まずは、両方のサーバでdrbdをインストール。
yum install drbd83 kmod-drbd83
はい。インストール終了。ラクチンポンである。（笑）
ちなみに、drbdが使用する領域は独立したボリュームかパーティションである必要があるそうなので、fdiskでパーティションを作るなりしてこれを用意する。
今回はVirtualPCを使っているので、一本目のディスク/dev/hdaはOSが入っている。二本目のディスク/dev/hdbをdrbd用に用意。fdiskで/dev/hdb1を作成している。
↓こんな感じ。
[root@fine ~]# fdisk -l Disk /dev/hda: 17.1 GB, 17179803648 bytes 255 heads, 63 sectors/track, 2088 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 2088 16667437+ 8e Linux LVM Disk /dev/hdb: 17.1 GB, 17179803648 bytes 16 heads, 63 sectors/track, 33288 cylinders Units = シリンダ数 of 1008 * 512 = 516096 bytes デバイス Boot Start End Blocks Id System /dev/hdb1 1 33288 16777120+ 83 Linux
次に、drbdの設定を行う。drbd公式サイトの情報を見て、ひとまず/etc/drbd.confに以下の通り記述した。
include "/etc/drbd.d/global_common.conf";
include "/etc/drbd.d/*.res";
resource r0 {
on rein {
device /dev/drbd0;
disk /dev/hdb1;
address ***.***.***.241:7789;
meta-disk internal;
}
on fine {
device /dev/drbd0;
disk /dev/hdb1;
address ***.***.***.242:7789;
meta-disk internal;
}
}
「include」はグローバル設定項目とかを読み込んでくる呪文。ひとまず詳しいことは割愛する。
「resource」で始まるブロックが、今回準備するdrbdで使用するディスクリソースの内容。「r0」と記述してあるのがリソース名。
「on」で始まるブロックが、個々のサーバで使用するリソースの設定。「rein」と「fine」がサーバ名。/etc/hostsやDNSにしっかり指定しておくこと。後の項目は空気が読める人なら説明不要かと思うが（察して！）、addressについてはIPアドレスで記述している。ここは/etc/hostsやDNSでの設定ときれいに一致させておくように。
さて、これでdrbdについては必要最低限の設定が完了したので、
①両ホストのdrbdデバイスにメタデータ領域を作成する
②両方ストのdrbdデバイス（リソース）をそれぞれアタッチする
③両ホストのdrbdデバイス（リソース）に対して同期を指示する（まだ同期しない）
④両ホストのdrbdどうしを接続させる
⑤ディスクの同期を開始する
という手順を踏む。
①両ホストのdrbdデバイスにメタデータ領域を作成する
これはコマンド一発でおわる。
drbdadm create-md r0
②両方ストのdrbdデバイス（リソース）をそれぞれアタッチする
これもコマンド一発。
drbdadm attach r0
正常終了時なら何も表示されないので心配しないように。
③両ホストのdrbdデバイス（リソース）に対して同期を指示する（まだ同期しない）
これもコマンド一発。しかも無言。（笑）
drbdadm syncer r0
④両ホストのdrbdどうしを接続させる
これも以下略
drbdadm connect r0
⑤ディスクの同期を開始する
さて、ここまで①～④については両方のホストで同じコマンドを実行するのだが、この項目についてはどちらか一方（原本になる方）だけで実行するので注意すること。ぶっちゃけ、まだディスクの中身は空っぽなので、どちらでやっても構わないのだが。
drbdadm -- --overwrite-data-of-peer primary r0
これを実行すると、両サーバ間でディスクの内容が同期される。イメージとしてはRAID0のミラーを最初に同期しにいくような感じだろうか。
同期の状態は/proc/drbdの中を見れば確認できる。
[root@rein etc]# cat /proc/drbd
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:16
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----
ns:1792 nr:0 dw:0 dr:1792 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:16774780
[>....................] sync'ed: 0.1% (16380/16380)M delay_probe: 0
finish: 11:38:56 speed: 356 (356) K/sec
…。結構かかるなあ。（笑）
なお、drbdの同期が実行中であっても、mdadmと同様に直ちにこのボリュームを使用することも可能だ。
ためしに、このボリュームをフォーマットしてマウントしてみよう。
[root@rein etc]# mkfs -t ext3 -j /dev/drbd0
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2097152 inodes, 4194143 blocks
209707 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
128 block groups
32768 blocks per group, 32768 fragments per group
16384 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 23 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@rein etc]# mkdir -p /mnt/work
[root@rein etc]# mount /dev/drbd0 /mnt/work
[root@rein etc]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/drbd0 16G 173M 15G 2% /mnt/work
…さすがに、VirtualPCで２個サーバを起動してdrbdの同期中にこんなこと実行すると超重い。（笑）
まずはrein側で、ディスクをマウントしてみた。ちゃんと領域が見えていることが判る。
ここに何かファイルを置いてみよう。
[root@rein etc]# mkdir /mnt/work/etc [root@rein etc]# cp -r /etc/* /mnt/work/etc/ [root@rein etc]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
こんな感じでファイルを置いてみた。（重い！：笑）
では、これを対向側のfineで見てみよう。
そうそう。今はext3でファイルシステムを作成しているので、対向側でマウントする前に、アンマウントしておかないといけない。同時にこのファイルシステムは使えないのだ。（対策は後ほど）
また、今回reinが「Primary」で、fineが「Secondary」になっているので、これもひっくり返さなければならない。（今はまだ「シングルプライマリモード」で動作しているため。
rein側でアンマウントと、Secondaryにするためのコマンドを投入する。
[root@rein etc]# umount /mnt/work
[root@rein etc]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
[root@rein etc]# drbdadm secondary r0
と、した後で、さっそく対向側のfineをPrimaryにしてからマウントしてみよう。
[root@fine ~]# drbdadm primary r0
[root@fine ~]# mkdir -p /mnt/work
[root@fine ~]# mount /dev/drbd0 /mnt/work
[root@fine ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
14G 1.2G 13G 9% /
/dev/hda1 99M 19M 76M 20% /boot
tmpfs 379M 0 379M 0% /dev/shm
/dev/drbd0 16G 222M 15G 2% /mnt/work
マウントできた。fine側ではファイルシステムを作成していないのにマウントできている。ということは、rein側の変更内容が確かに伝わっているということが判る。
ディスクの中身も確認してみよう。
[root@fine ~]# find /mnt/work/etc -print | head /mnt/work/etc /mnt/work/etc/fonts /mnt/work/etc/fonts/fonts.dtd /mnt/work/etc/fonts/conf.d /mnt/work/etc/fonts/conf.d/60-latin.conf /mnt/work/etc/fonts/conf.d/80-delicious.conf /mnt/work/etc/fonts/conf.d/20-fix-globaladvance.conf /mnt/work/etc/fonts/conf.d/69-unifont.conf /mnt/work/etc/fonts/conf.d/90-synthetic.conf /mnt/work/etc/fonts/conf.d/64-nonlatin-fedora.conf
内容も確認できている。
reinとfineは/dev/drbd0デバイスによって同じ内容が確認できる状態になった。
しかし、今はまだ同時に読み書き出来る状態にはないので、次のアーティクルでは両方から同時にアクセスが通るようにしたい。（多分その「前編」になるかな…）
それにしても…PC重いぜ…（笑）
mdadmで壊れたアレイを修復できるか？ [Linux(LVM/RAID/Storage)]
※ この方法が必ず成功するかどうか、確証は全く持てないので、ダメだったとしても文句は言わないように！（笑） ※
さて。LinuxのソフトウェアRAIDでアレイを構築している状態で、ディスク以外のパーツでトラブルが発生することもある。
例えば、拡張スロットに挿しているSATAカードの故障とか、SATAのポートマルチプライヤとか、あるいはケーブル類とか。特にSATAポートマルチプライヤの故障は頻度が多い気がしてならないんだが…。個人的に。そう、あくまでも個人的に。
で、RAID5の場合、原則論としてはディスク１本の障害までは耐えられることになっているが、２本飛んだらゲームオーバーということになっている。その故障の原因は全く問われないが、ディスクそのものの故障よりも、前述のSATAカードやパーツ類の故障の場合は一気に複数のディスクがアクセス不能になる傾向にあるのもまた事実。
ディスクが壊れていなければ、アレイの中のデータが無事である可能性はある。ダメになっているかもしれないが、そこに一縷の望みをかけて「なんとか復旧」させたいと思うのもまた心情。そこで、復旧方法の一つについてここに記載しておく。
ちなみに、我が家の最近のSATAポートマルチプライヤの故障によるRAIDアレイ停止問題はコレで解決できた。
サーバ起動時のログは、こんな感じだった。ちょっと長いけど全部晒すと…
RAIDアレイを構成する9本のディスクのうち、2本がFailedの扱いになっていて、
そしてアレイをスタートするのにディスクが足りないよというエラーに。
ひとまず手動でRAIDをスタートさせてみる。
mdadm --assemble /dev/md0 --run /dev/sd[a-k]1 とか実行してみる。/dev/md0は始動するも、ディスク2本（sdi1とsdj1）がFailedの扱いになって組み込まれないので、 mdadm --misc --detail /dev/md0 で確認してもアクセスは不能に。
このような場合、2つの方法がある模様。
① 思い切ってmdadm --createをやってしまう方法
② ディスクが歯抜けになっているアレイに、Failedなディスクをaddする方法
実は、昔①を試したことがあって、１勝１敗という状況。勝率５０％ではあるが今回コレを再度実行する勇気がもてなかったので（笑）、②を実施することにした。（笑）
どうやら、コレには条件があるようだ。ざっくり調べてみた限りでは、mdadm --misc --examineでディスクに保存されているアレイの情報が綺麗に一致する状態でなければならないとのこと。おそらく、RAIDの情報（管理情報？）を更新している瞬間とかにエラーになったらダメとか、そういうことなのだろうか？よく判らないのでその筋の識者の方、コメントを求む。
そんな訳で、
Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdj1 from array!
Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdi1 from array!
ということだったので、mdadm --misc --examine /dev/sdj1とmdadm --misc --examine /dev/sdi1 と実行してみる。
ちなみにこのコマンドを実行すると、↓こんな具合の情報が出る。
（上記の表示例は正常に起動してからのものなので、停止中とかだとちょっと違う場合も考えられる。）
幸い、「Checksum : ナントカカントカ - correct」だったので、このまま組み込んでも大丈夫かな？と思えた。思っただけで確証は全く無かったが！！
と言うわけで、sdj1とsdi1とをアレイに組み込む。コマンドはmdadm --manage /dev/md0 --add /dev/sd[ij]1だ。特にエラーも無く、sdj1とsdi1とをaddしたお＾－＾ みたいなメッセージがちょろっと出て終了。
mdadm --misc --detail /dev/md0で表示を確認すると、こちらも特にエラーなど無く、それぞれのディスクは「active sync」の状態に。
こいつ・・・動くぞ！？
という心境になった。（笑）しかし、アレイ自体はまだ起動していないので、あと一発コマンドを流し込んでアレイを起動する。コマンドはmdadm --manage /dev/md0 --runだ。
お・・・
エラーとか出ない！！
mdadm --misc --detail /dev/md0でも正常起動を確認！！mount /dev/md0 /mnt/local/storage とか実行してみてdf -hとか実行してみて内部のデータの無事を確認！！ いや、もしかしたら何か壊れたファイルもあるかもしれないが、とりあえずサルベージは可能な状態には達した！！
とりあえず、中のデータを救い出してしまおう。そのうちに！
さて。LinuxのソフトウェアRAIDでアレイを構築している状態で、ディスク以外のパーツでトラブルが発生することもある。
例えば、拡張スロットに挿しているSATAカードの故障とか、SATAのポートマルチプライヤとか、あるいはケーブル類とか。特にSATAポートマルチプライヤの故障は頻度が多い気がしてならないんだが…。個人的に。そう、あくまでも個人的に。
で、RAID5の場合、原則論としてはディスク１本の障害までは耐えられることになっているが、２本飛んだらゲームオーバーということになっている。その故障の原因は全く問われないが、ディスクそのものの故障よりも、前述のSATAカードやパーツ類の故障の場合は一気に複数のディスクがアクセス不能になる傾向にあるのもまた事実。
ディスクが壊れていなければ、アレイの中のデータが無事である可能性はある。ダメになっているかもしれないが、そこに一縷の望みをかけて「なんとか復旧」させたいと思うのもまた心情。そこで、復旧方法の一つについてここに記載しておく。
ちなみに、我が家の最近のSATAポートマルチプライヤの故障によるRAIDアレイ停止問題はコレで解決できた。
サーバ起動時のログは、こんな感じだった。ちょっと長いけど全部晒すと…
Jun 17 22:22:36 urd kernel: md: Autodetecting RAID arrays. Jun 17 22:22:36 urd kernel: md: autorun ... Jun 17 22:22:36 urd kernel: md: considering sdk1 ... Jun 17 22:22:36 urd kernel: md: adding sdk1 ... Jun 17 22:22:36 urd kernel: md: adding sdj1 ... Jun 17 22:22:36 urd kernel: md: adding sdi1 ... Jun 17 22:22:36 urd kernel: md: adding sdh1 ... Jun 17 22:22:36 urd kernel: md: adding sdg1 ... Jun 17 22:22:36 urd kernel: md: adding sdf1 ... Jun 17 22:22:36 urd kernel: md: adding sde1 ... Jun 17 22:22:36 urd kernel: md: adding sdd1 ... Jun 17 22:22:36 urd kernel: md: adding sdc1 ... Jun 17 22:22:36 urd kernel: md: adding sdb1 ... Jun 17 22:22:36 urd kernel: md: adding sda1 ... Jun 17 22:22:36 urd kernel: md: created md0 Jun 17 22:22:36 urd kernel: md: bindJun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: bind Jun 17 22:22:36 urd kernel: md: running: Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdj1 from array! Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdj1) Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdi1 from array! Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdi1) Jun 17 22:22:36 urd kernel: raid5: automatically using best checksumming function: generic_sse Jun 17 22:22:36 urd kernel: generic_sse: 5868.000 MB/sec Jun 17 22:22:36 urd kernel: raid5: using function: generic_sse (5868.000 MB/sec) Jun 17 22:22:36 urd kernel: raid6: int64x1 1339 MB/s Jun 17 22:22:36 urd kernel: raid6: int64x2 1667 MB/s Jun 17 22:22:36 urd kernel: raid6: int64x4 1523 MB/s Jun 17 22:22:36 urd kernel: raid6: int64x8 1265 MB/s Jun 17 22:22:36 urd kernel: raid6: sse2x1 2609 MB/s Jun 17 22:22:36 urd kernel: raid6: sse2x2 3160 MB/s Jun 17 22:22:36 urd kernel: raid6: sse2x4 4792 MB/s Jun 17 22:22:36 urd kernel: raid6: using algorithm sse2x4 (4792 MB/s) Jun 17 22:22:36 urd kernel: md: raid6 personality registered for level 6 Jun 17 22:22:36 urd kernel: md: raid5 personality registered for level 5 Jun 17 22:22:36 urd kernel: md: raid4 personality registered for level 4 Jun 17 22:22:36 urd kernel: raid5: device sdh1 operational as raid disk 8 Jun 17 22:22:36 urd kernel: raid5: device sdg1 operational as raid disk 5 Jun 17 22:22:36 urd kernel: raid5: device sdf1 operational as raid disk 3 Jun 17 22:22:36 urd kernel: raid5: device sdd1 operational as raid disk 7 Jun 17 22:22:36 urd kernel: raid5: device sdc1 operational as raid disk 2 Jun 17 22:22:36 urd kernel: raid5: device sdb1 operational as raid disk 6 Jun 17 22:22:36 urd kernel: raid5: device sda1 operational as raid disk 4 Jun 17 22:22:36 urd kernel: raid5: not enough operational devices for md0 (2/9 failed) Jun 17 22:22:36 urd kernel: RAID5 conf printout: Jun 17 22:22:36 urd kernel: --- rd:9 wd:7 fd:2 Jun 17 22:22:36 urd kernel: disk 2, o:1, dev:sdc1 Jun 17 22:22:36 urd kernel: disk 3, o:1, dev:sdf1 Jun 17 22:22:36 urd kernel: disk 4, o:1, dev:sda1 Jun 17 22:22:36 urd kernel: disk 5, o:1, dev:sdg1 Jun 17 22:22:36 urd kernel: disk 6, o:1, dev:sdb1 Jun 17 22:22:36 urd kernel: disk 7, o:1, dev:sdd1 Jun 17 22:22:36 urd kernel: disk 8, o:1, dev:sdh1 Jun 17 22:22:36 urd kernel: raid5: failed to run raid set md0 Jun 17 22:22:36 urd kernel: md: pers->run() failed ... Jun 17 22:22:36 urd kernel: md: do_md_run() returned -5 Jun 17 22:22:36 urd kernel: md: md0 stopped. Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdk1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdh1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdg1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdf1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sde1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdd1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdc1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdb1) Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sda1) Jun 17 22:22:36 urd kernel: md: ... autorun DONE.
RAIDアレイを構成する9本のディスクのうち、2本がFailedの扱いになっていて、
Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdj1 from array! Jun 17 22:22:36 urd kernel: md: unbindJun 17 22:22:36 urd kernel: md: export_rdev(sdj1) Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdi1 from array! Jun 17 22:22:36 urd kernel: md: unbind Jun 17 22:22:36 urd kernel: md: export_rdev(sdi1)
そしてアレイをスタートするのにディスクが足りないよというエラーに。
Jun 17 22:22:36 urd kernel: raid5: device sdh1 operational as raid disk 8 Jun 17 22:22:36 urd kernel: raid5: device sdg1 operational as raid disk 5 Jun 17 22:22:36 urd kernel: raid5: device sdf1 operational as raid disk 3 Jun 17 22:22:36 urd kernel: raid5: device sdd1 operational as raid disk 7 Jun 17 22:22:36 urd kernel: raid5: device sdc1 operational as raid disk 2 Jun 17 22:22:36 urd kernel: raid5: device sdb1 operational as raid disk 6 Jun 17 22:22:36 urd kernel: raid5: device sda1 operational as raid disk 4 Jun 17 22:22:36 urd kernel: raid5: not enough operational devices for md0 (2/9 failed) Jun 17 22:22:36 urd kernel: RAID5 conf printout: Jun 17 22:22:36 urd kernel: --- rd:9 wd:7 fd:2 Jun 17 22:22:36 urd kernel: disk 2, o:1, dev:sdc1 Jun 17 22:22:36 urd kernel: disk 3, o:1, dev:sdf1 Jun 17 22:22:36 urd kernel: disk 4, o:1, dev:sda1 Jun 17 22:22:36 urd kernel: disk 5, o:1, dev:sdg1 Jun 17 22:22:36 urd kernel: disk 6, o:1, dev:sdb1 Jun 17 22:22:36 urd kernel: disk 7, o:1, dev:sdd1 Jun 17 22:22:36 urd kernel: disk 8, o:1, dev:sdh1 Jun 17 22:22:36 urd kernel: raid5: failed to run raid set md0
ひとまず手動でRAIDをスタートさせてみる。
mdadm --assemble /dev/md0 --run /dev/sd[a-k]1 とか実行してみる。/dev/md0は始動するも、ディスク2本（sdi1とsdj1）がFailedの扱いになって組み込まれないので、 mdadm --misc --detail /dev/md0 で確認してもアクセスは不能に。
このような場合、2つの方法がある模様。
① 思い切ってmdadm --createをやってしまう方法
② ディスクが歯抜けになっているアレイに、Failedなディスクをaddする方法
実は、昔①を試したことがあって、１勝１敗という状況。勝率５０％ではあるが今回コレを再度実行する勇気がもてなかったので（笑）、②を実施することにした。（笑）
どうやら、コレには条件があるようだ。ざっくり調べてみた限りでは、mdadm --misc --examineでディスクに保存されているアレイの情報が綺麗に一致する状態でなければならないとのこと。おそらく、RAIDの情報（管理情報？）を更新している瞬間とかにエラーになったらダメとか、そういうことなのだろうか？よく判らないのでその筋の識者の方、コメントを求む。
そんな訳で、
Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdj1 from array!
Jun 17 22:22:36 urd kernel: md: kicking non-fresh sdi1 from array!
ということだったので、mdadm --misc --examine /dev/sdj1とmdadm --misc --examine /dev/sdi1 と実行してみる。
ちなみにこのコマンドを実行すると、↓こんな具合の情報が出る。
/dev/sdj1:
Magic : a92b4efc
Version : 0.90.00
UUID : 920f0fa0:3134624c:9777e46a:4cafd8b9
Creation Time : Mon Feb 1 23:09:17 2010
Raid Level : raid5
Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
Array Size : 15628095488 (14904.11 GiB 16003.17 GB)
Raid Devices : 9
Total Devices : 11
Preferred Minor : 0
Update Time : Mon Jun 20 04:03:47 2011
State : clean
Active Devices : 9
Working Devices : 11
Failed Devices : 0
Spare Devices : 2
Checksum : 5e9e5268 - correct
Events : 1521164
Layout : left-symmetric
Chunk Size : 256K
Number Major Minor RaidDevice State
this 0 8 145 0 active sync /dev/sdj1
0 0 8 145 0 active sync /dev/sdj1
1 1 8 129 1 active sync /dev/sdi1
2 2 8 33 2 active sync /dev/sdc1
3 3 8 81 3 active sync /dev/sdf1
4 4 8 1 4 active sync /dev/sda1
5 5 8 97 5 active sync /dev/sdg1
6 6 8 17 6 active sync /dev/sdb1
7 7 8 49 7 active sync /dev/sdd1
8 8 8 113 8 active sync /dev/sdh1
9 9 8 65 9 spare /dev/sde1
10 10 8 161 10 spare /dev/sdk1（上記の表示例は正常に起動してからのものなので、停止中とかだとちょっと違う場合も考えられる。）
幸い、「Checksum : ナントカカントカ - correct」だったので、このまま組み込んでも大丈夫かな？と思えた。思っただけで確証は全く無かったが！！
と言うわけで、sdj1とsdi1とをアレイに組み込む。コマンドはmdadm --manage /dev/md0 --add /dev/sd[ij]1だ。特にエラーも無く、sdj1とsdi1とをaddしたお＾－＾ みたいなメッセージがちょろっと出て終了。
mdadm --misc --detail /dev/md0で表示を確認すると、こちらも特にエラーなど無く、それぞれのディスクは「active sync」の状態に。
こいつ・・・動くぞ！？
という心境になった。（笑）しかし、アレイ自体はまだ起動していないので、あと一発コマンドを流し込んでアレイを起動する。コマンドはmdadm --manage /dev/md0 --runだ。
お・・・
エラーとか出ない！！
mdadm --misc --detail /dev/md0でも正常起動を確認！！mount /dev/md0 /mnt/local/storage とか実行してみてdf -hとか実行してみて内部のデータの無事を確認！！ いや、もしかしたら何か壊れたファイルもあるかもしれないが、とりあえずサルベージは可能な状態には達した！！
とりあえず、中のデータを救い出してしまおう。そのうちに！
（お詫び）丸ごとコピーしたLVM領域を同時にマウントできないか？ [Linux(LVM/RAID/Storage)]
すいません。コメント放置してましたごめんなさい、m(__)m
で、コメントを寄せられた方の趣旨に添うかどうか判りませんが、以前書き換えて途中で止まってるエントリーを再度調査してみました。
まず、LVMの領域を一つつくります。
ディスク/dev/sdbにパーティションを2個作りまして…
そこに物理ボリュームをそれぞれ作成
作成した二つの物理ボリュームを1個のボリュームグループに加えます。
で、論理ボリュームを作成します。
マウントポイントを作成してファイルシステムを作成してマウントします。
マウントされた状態を確認してみます。
はい。というわけで、/dev/sdbにはLVMのボリュームが作成されました。
/dev/sdbを、/dev/sdcに丸ごとコピーしてみましょう。
というわけでコピーされました。
sdb1とsdc1、sdb2とsdc2はそれぞれ「全く同じもの」のはずです。
物理ボリュームの情報を確認してみます。
と、おかしなことになってますね。（/dev/hdaのエラーは忘れて！：笑）
この、重複しているUUIDなどのせいでLVMが混乱しているようです。（笑）
これを別々のボリュームにする方法を以下に示します。
手順①：まずアンマウントする
手順②：ボリュームグループを不活性状態にする
手順③：vgimportcloneコマンドでボリュームグループの複製を作成する
手順④：コピー元・コピー先のボリュームグループを活性状態にする
手順⑤：必要に応じて複製したボリュームをマウントするためのマウントポイントを作成する
手順⑥：必要に応じて再度マウントする
手順①：まずアンマウントする
マウントされた状態であればアンマウントします。
LVMがおかしなことになる前に、一刻も早くアンマウントしましょうね。
手順②：ボリュームグループを不活性状態にする
続いて、ボリュームグループを不活性状態にします。vgchangeコマンドを用います。
これで、オリジナル（のはずの）ボリュームグループが不活性状態となりアクセスできなくなります。
手順③：vgimportcloneコマンドでボリュームグループの複製を作成する
vgimportcloneコマンドを使って、重複したボリュームグループ・物理ボリュームの情報を複製・インポートします。
ここでは、/dev/sdb1と/dev/sdb2から、/dev/sdc1と/dev/sdc2をコピーしたので、/dev/sdc1と/dev/sdc2を複製したボリュームグループに移動させることにします。
これで、/dev/sdc1と/dev/sdc2のUUID等の情報が適切に変更され、またvgStorageと同じ属性を持つボリュームグループvgStorage1が複製されます。複製されたボリュームグループの名前は…
Volume group "vgStorage" successfully renamed to "vgStorage1"
という行で確認できます。
では確認してみましょう。
まずはオリジナルのvgStorageから。
ただしく/dev/sdb1と/dev/sdb2とボリュームグループ内に加わっていることが判ります。
では、今複製したvgStorage1も見てみます。
と、無事に複製されているっぽく見えます。
手順④：コピー元・コピー先のボリュームグループを活性状態にする
では、ボリュームグループを両方とも活性状態にしてアクセスできるようにします。
両方とも活性化されました。
手順⑤：必要に応じて複製したボリュームをマウントするためのマウントポイントを作成する
vgStorage1のボリュームをマウントするマウントポイントはまだ無いので、ここでマウントポイントを作成します。
手順⑥：必要に応じて再度マウントする
じゃ、両方ともマウントしてみましょう！！
お？マウントできたかな！？
キタコレ！
でも、もしかしたら「同じものが別々のマウントポイントにマウントされただけ」なんてことも！？
そんな訳で、両方のマウントポイントがそれぞれ別物もであることを確認してみます。
/mnt/local/dataに何か適当なファイルを置いてみて、/mnt/local/data1でそのファイルが表示されなければＯＫのはず。
レッツトライ！
キターーーーーーー！！！
というわけで、LVMまるっとコピーしたボリュームを両方とも同時にマウントすることに成功しました。
で、コメントを寄せられた方の趣旨に添うかどうか判りませんが、以前書き換えて途中で止まってるエントリーを再度調査してみました。
まず、LVMの領域を一つつくります。
ディスク/dev/sdbにパーティションを2個作りまして…
[root@nanako ~]# fdisk -l /dev/sdb Disk /dev/sdb: 8589 MB, 8589934592 bytes 255 heads, 63 sectors/track, 1044 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sdb1 1 522 4192933+ 83 Linux /dev/sdb2 523 1044 4192965 83 Linux
そこに物理ボリュームをそれぞれ作成
[root@nanako ~]# pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created [root@nanako ~]# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created
作成した二つの物理ボリュームを1個のボリュームグループに加えます。
[root@nanako ~]# vgcreate vgStrage /dev/sdb[12] Volume group "vgStrage" successfully created
で、論理ボリュームを作成します。
[root@nanako ~]# lvcreate -l 2046 -n lvData vgStorage Logical volume "lvData" created
マウントポイントを作成してファイルシステムを作成してマウントします。
[root@nanako ~]# mkdir -p /mnt/local/data [root@nanako ~]# mke2fs -j /dev/vgStorage/lvData [root@nanako ~]# mount /dev/vgStorage/lvData /mnt/local/data
マウントされた状態を確認してみます。
[root@nanako ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vgStorage-lvData on /mnt/local/data type ext3 (rw)
[root@nanako ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
28G 1.1G 25G 4% /
/dev/sda1 99M 12M 82M 13% /boot
tmpfs 1014M 0 1014M 0% /dev/shm
/dev/mapper/vgStorage-lvData
7.9G 147M 7.4G 2% /mnt/local/data
はい。というわけで、/dev/sdbにはLVMのボリュームが作成されました。
/dev/sdbを、/dev/sdcに丸ごとコピーしてみましょう。
[root@nanako ~]# dd if=/dev/sdb of=/dev/sdc 16777216+0 records in 16777216+0 records out 8589934592 bytes (8.6 GB) copied, 773.854 seconds, 11.1 MB/s
というわけでコピーされました。
sdb1とsdc1、sdb2とsdc2はそれぞれ「全く同じもの」のはずです。
物理ボリュームの情報を確認してみます。
[root@nanako ~]# pvdisplay /dev/sdb1
/dev/hda: open failed: メディアが見つかりません
Found duplicate PV qeHj8CK19irbVD6528Rn5BWR3V6453IL: using /dev/sdc1 not /dev/sdb1
--- Physical volume ---
PV Name /dev/sdc1
VG Name vgStorage
PV Size 4.00 GB / not usable 2.66 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 1023
Free PE 0
Allocated PE 1023
PV UUID qeHj8C-K19i-rbVD-6528-Rn5B-WR3V-6453IL
[root@nanako ~]# pvdisplay /dev/sdc1
/dev/hda: open failed: メディアが見つかりません
Found duplicate PV qeHj8CK19irbVD6528Rn5BWR3V6453IL: using /dev/sdb1 not /dev/sdc1
--- Physical volume ---
PV Name /dev/sdb1
VG Name vgStorage
PV Size 4.00 GB / not usable 2.66 MB
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 1023
Free PE 0
Allocated PE 1023
PV UUID qeHj8C-K19i-rbVD-6528-Rn5B-WR3V-6453IL
[root@nanako ~]# vgdisplay -v
Finding all volume groups
/dev/hda: open failed: メディアが見つかりません
Found duplicate PV qeHj8CK19irbVD6528Rn5BWR3V6453IL: using /dev/sdc1 not /dev/sdb1
Finding volume group "vgStorage"
--- Volume group ---
VG Name vgStorage
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 7.99 GB
PE Size 4.00 MB
Total PE 2046
Alloc PE / Size 2046 / 7.99 GB
Free PE / Size 0 / 0
VG UUID 0sOu0l-Ka3J-jQcv-m4eQ-OU3z-w2Qn-qsTtT8
--- Logical volume ---
LV Name /dev/vgStorage/lvData
VG Name vgStorage
LV UUID pEjAL9-YYta-9q02-VW4T-GPf3-IhRV-BvOt3g
LV Write Access read/write
LV Status available
# open 0
LV Size 7.99 GB
Current LE 2046
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
--- Physical volumes ---
PV Name /dev/sdc1
PV UUID qeHj8C-K19i-rbVD-6528-Rn5B-WR3V-6453IL
PV Status allocatable
Total PE / Free PE 1023 / 0
PV Name /dev/sdb2
PV UUID At1sAz-VIr9-agGc-PxdP-hKL1-BRRF-qFcnK7
PV Status allocatable
Total PE / Free PE 1023 / 0
と、おかしなことになってますね。（/dev/hdaのエラーは忘れて！：笑）
この、重複しているUUIDなどのせいでLVMが混乱しているようです。（笑）
これを別々のボリュームにする方法を以下に示します。
手順①：まずアンマウントする
手順②：ボリュームグループを不活性状態にする
手順③：vgimportcloneコマンドでボリュームグループの複製を作成する
手順④：コピー元・コピー先のボリュームグループを活性状態にする
手順⑤：必要に応じて複製したボリュームをマウントするためのマウントポイントを作成する
手順⑥：必要に応じて再度マウントする
手順①：まずアンマウントする
マウントされた状態であればアンマウントします。
umount /mnt/local/data
LVMがおかしなことになる前に、一刻も早くアンマウントしましょうね。
手順②：ボリュームグループを不活性状態にする
続いて、ボリュームグループを不活性状態にします。vgchangeコマンドを用います。
vgchange -an vgStorage
これで、オリジナル（のはずの）ボリュームグループが不活性状態となりアクセスできなくなります。
手順③：vgimportcloneコマンドでボリュームグループの複製を作成する
vgimportcloneコマンドを使って、重複したボリュームグループ・物理ボリュームの情報を複製・インポートします。
ここでは、/dev/sdb1と/dev/sdb2から、/dev/sdc1と/dev/sdc2をコピーしたので、/dev/sdc1と/dev/sdc2を複製したボリュームグループに移動させることにします。
[root@nanako ~]# vgimportclone /dev/sdc1 /dev/sdc2 WARNING: Activation disabled. No device-mapper interaction will be attempted. Physical volume "/tmp/snap.RzVp2305/vgimport1" changed 1 physical volume changed / 0 physical volumes not changed WARNING: Activation disabled. No device-mapper interaction will be attempted. Physical volume "/tmp/snap.RzVp2305/vgimport0" changed 1 physical volume changed / 0 physical volumes not changed WARNING: Activation disabled. No device-mapper interaction will be attempted. Volume group "vgStorage" successfully changed Volume group "vgStorage" successfully renamed to "vgStorage1" Reading all physical volumes. This may take a while... Found volume group "vgStorage1" using metadata type lvm2 Found volume group "vgStorage" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2
これで、/dev/sdc1と/dev/sdc2のUUID等の情報が適切に変更され、またvgStorageと同じ属性を持つボリュームグループvgStorage1が複製されます。複製されたボリュームグループの名前は…
Volume group "vgStorage" successfully renamed to "vgStorage1"
という行で確認できます。
では確認してみましょう。
まずはオリジナルのvgStorageから。
Finding volume group "vgStorage"
--- Volume group ---
VG Name vgStorage
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 10
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 7.99 GB
PE Size 4.00 MB
Total PE 2046
Alloc PE / Size 2046 / 7.99 GB
Free PE / Size 0 / 0
VG UUID 0sOu0l-Ka3J-jQcv-m4eQ-OU3z-w2Qn-qsTtT8
--- Logical volume ---
LV Name /dev/vgStorage/lvData
VG Name vgStorage
LV UUID pEjAL9-YYta-9q02-VW4T-GPf3-IhRV-BvOt3g
LV Write Access read/write
LV Status NOT available
LV Size 7.99 GB
Current LE 2046
Segments 2
Allocation inherit
Read ahead sectors auto
--- Physical volumes ---
PV Name /dev/sdb1
PV UUID 1r23pR-o5JI-uNC3-TdqB-CgvU-Ss34-717xkj
PV Status allocatable
Total PE / Free PE 1023 / 0
PV Name /dev/sdb2
PV UUID EBAX8L-00HP-vJO4-0r0r-BSVx-wEQx-WM0q71
PV Status allocatable
Total PE / Free PE 1023 / 0
ただしく/dev/sdb1と/dev/sdb2とボリュームグループ内に加わっていることが判ります。
では、今複製したvgStorage1も見てみます。
Finding volume group "vgStorage1"
--- Volume group ---
VG Name vgStorage1
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 14
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 7.99 GB
PE Size 4.00 MB
Total PE 2046
Alloc PE / Size 2046 / 7.99 GB
Free PE / Size 0 / 0
VG UUID MctxTX-2HJN-iDxr-rLb0-70Sc-0rqg-sTHLuX
--- Logical volume ---
LV Name /dev/vgStorage1/lvData
VG Name vgStorage1
LV UUID pEjAL9-YYta-9q02-VW4T-GPf3-IhRV-BvOt3g
LV Write Access read/write
LV Status NOT available
LV Size 7.99 GB
Current LE 2046
Segments 2
Allocation inherit
Read ahead sectors auto
--- Physical volumes ---
PV Name /dev/sdc1
PV UUID mnYhMw-xUiA-I92F-P50s-eCiL-8n3F-zHFMSO
PV Status allocatable
Total PE / Free PE 1023 / 0
PV Name /dev/sdc2
PV UUID 10OpsF-V2W1-Fg7P-ZYnb-gbC0-satd-K809C4
PV Status allocatable
Total PE / Free PE 1023 / 0
と、無事に複製されているっぽく見えます。
手順④：コピー元・コピー先のボリュームグループを活性状態にする
では、ボリュームグループを両方とも活性状態にしてアクセスできるようにします。
[root@nanako ~]# vgchange -ay vgStorage 1 logical volume(s) in volume group "vgStorage" now active [root@nanako ~]# vgchange -ay vgStorage1 1 logical volume(s) in volume group "vgStorage1" now active
両方とも活性化されました。
手順⑤：必要に応じて複製したボリュームをマウントするためのマウントポイントを作成する
vgStorage1のボリュームをマウントするマウントポイントはまだ無いので、ここでマウントポイントを作成します。
[root@nanako ~]# mkdir -p /mnt/local/data1
手順⑥：必要に応じて再度マウントする
じゃ、両方ともマウントしてみましょう！！
[root@nanako ~]# mount /dev/vgStorage/lvData /mnt/local/data [root@nanako ~]# mount /dev/vgStorage1/lvData /mnt/local/data1
お？マウントできたかな！？
[root@nanako ~]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vgStorage-lvData on /mnt/local/data type ext3 (rw)
/dev/mapper/vgStorage1-lvData on /mnt/local/data1 type ext3 (rw)
[root@nanako ~]# df -h
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/mapper/VolGroup00-LogVol00
28G 1.1G 25G 4% /
/dev/sda1 99M 12M 82M 13% /boot
tmpfs 1014M 0 1014M 0% /dev/shm
/dev/mapper/vgStorage-lvData
7.9G 147M 7.4G 2% /mnt/local/data
/dev/mapper/vgStorage1-lvData
7.9G 147M 7.4G 2% /mnt/local/data1
キタコレ！
でも、もしかしたら「同じものが別々のマウントポイントにマウントされただけ」なんてことも！？
そんな訳で、両方のマウントポイントがそれぞれ別物もであることを確認してみます。
/mnt/local/dataに何か適当なファイルを置いてみて、/mnt/local/data1でそのファイルが表示されなければＯＫのはず。
レッツトライ！
[root@nanako ~]# date > /mnt/local/data/file [root@nanako ~]# ls -la /mnt/local/data 合計 28 drwxr-xr-x 3 root root 4096 10月 15 21:14 . drwxr-xr-x 4 root root 4096 10月 15 21:13 .. -rw-r--r-- 1 root root 43 10月 15 21:14 file drwx------ 2 root root 16384 10月 15 20:00 lost+found [root@nanako ~]# ls -la /mnt/local/data1 合計 24 drwxr-xr-x 3 root root 4096 10月 15 20:00 . drwxr-xr-x 4 root root 4096 10月 15 21:13 .. drwx------ 2 root root 16384 10月 15 20:00 lost+found
キターーーーーーー！！！
というわけで、LVMまるっとコピーしたボリュームを両方とも同時にマウントすることに成功しました。
LinuxでHDDをホットリリース（電源切らずにディスクを抜き取る） [Linux(LVM/RAID/Storage)]
SATA（SCSI/SASとかでもいいけど）なHDDでホットスワップできるケースにディスクを入れて運用している場合等で、Linuxが動作中のままホットスワップしたくなることがある。
例えばRAIDのアレイが壊れてディスク交換するとかなんとか。
で、その方法。
なお、SATAでもSCSIでもSASでもUSBでもIEEE1394（FireWire）でも全部やり方は同じ方法が使える（はず）。
①まずは抜き取りたいディスクを特定する。
/dev/sd? というデバイス名の特定と、物理的なディスクの特定を行う。
これを間違うとひどい目にあう。
ちなみに、HDD１個１個にLED等アクセスランプが備わっている場合は、実際にそのディスクにアクセスしてみるのが手っ取り早い。例えば…
dd if=/dev/sda of=/dev/null bs=1M count=1024
とかこんな具合に。「sda」の部分は適宜確認したいディスクデバイス名に読み替えてほしい。
ただ、この方法では確認しきれない場合もある。そんなときは逆に「抜き取る必要の無いディスク」にアクセスしてみて、LEDが点灯しなかったものが壊れたディスクだということで調べる方法もある。
あるいは、S.M.A.R.T.が有効になっていれば、
smartctl --test=short /dev/sda
とかみたいな方法を実行してみる。アクセスランプが点灯するか、壊れたディスクならきっとすごい異音がするので（笑）、これで物理的なディスクが特定できるだろう。
②「delete」ファイルに「1」を書き込んでやる
/sys/block/(デバイス名)/device/delete というファイルに「1」を書き込んでやると、そのディスクがＯＳ上の認識が削除されることとなる。
例えば、「sdn」を削除したいよ！ という場合は…
これでよい。世の中的にはデバイスＩＤを調べて…という方法が多いようだが、今時のカーネルなら調べる必要も無い。（調べなきゃいけない場合もあるかもしれないが、少なくともCentOS5.3以降なら大丈夫だった）
③ディスクを引っこ抜く
ディスクを注意深く抜き取ろう。
なお、まだ生きているディスクをこの方法で引き抜く場合は、もしかしたらメモリ上にキャッシュされているデータをあわてて書き込んでいるかもしれないので、ディスクアクセスが無いことを確認してから引き抜こう。
というか、事前に sync してからdeleteに「1」を書いてやるべきだろうね。
例えばRAIDのアレイが壊れてディスク交換するとかなんとか。
で、その方法。
なお、SATAでもSCSIでもSASでもUSBでもIEEE1394（FireWire）でも全部やり方は同じ方法が使える（はず）。
①まずは抜き取りたいディスクを特定する。
/dev/sd? というデバイス名の特定と、物理的なディスクの特定を行う。
これを間違うとひどい目にあう。
ちなみに、HDD１個１個にLED等アクセスランプが備わっている場合は、実際にそのディスクにアクセスしてみるのが手っ取り早い。例えば…
dd if=/dev/sda of=/dev/null bs=1M count=1024
とかこんな具合に。「sda」の部分は適宜確認したいディスクデバイス名に読み替えてほしい。
ただ、この方法では確認しきれない場合もある。そんなときは逆に「抜き取る必要の無いディスク」にアクセスしてみて、LEDが点灯しなかったものが壊れたディスクだということで調べる方法もある。
あるいは、S.M.A.R.T.が有効になっていれば、
smartctl --test=short /dev/sda
とかみたいな方法を実行してみる。アクセスランプが点灯するか、壊れたディスクならきっとすごい異音がするので（笑）、これで物理的なディスクが特定できるだろう。
②「delete」ファイルに「1」を書き込んでやる
/sys/block/(デバイス名)/device/delete というファイルに「1」を書き込んでやると、そのディスクがＯＳ上の認識が削除されることとなる。
例えば、「sdn」を削除したいよ！ という場合は…
# echo "1" > /sys/block/sdn/device/delete
これでよい。世の中的にはデバイスＩＤを調べて…という方法が多いようだが、今時のカーネルなら調べる必要も無い。（調べなきゃいけない場合もあるかもしれないが、少なくともCentOS5.3以降なら大丈夫だった）
③ディスクを引っこ抜く
ディスクを注意深く抜き取ろう。
なお、まだ生きているディスクをこの方法で引き抜く場合は、もしかしたらメモリ上にキャッシュされているデータをあわてて書き込んでいるかもしれないので、ディスクアクセスが無いことを確認してから引き抜こう。
というか、事前に sync してからdeleteに「1」を書いてやるべきだろうね。
mdadmでソフトRAIDを構築してみる（RAID 5編） のVineLinuxなお友達への補足編 [Linux(LVM/RAID/Storage)]
先日（つーか、もう結構たつけど）、「mdadmでソフトRAIDを構築してみる(RAID 5編)」という記事を書いた。ここでは主にCentOSなお友達向けに記載していたが、VineLinuxでこれと同じ操作をしてもRAIDのアレイが構築できないという問題に直面するかもしれない。
具体的には、２個目のアレイを作成しようとしてmdadm --create...コマンドを投入すると、/dev/md?が無いというエラーが出るというもの。
CentOSの場合は、mdadm --create /dev/mdナントカ を実行すると、新しい/dev/mdナントカを自動で作成してくれるのだが、VineLinuxの場合、mdadmコマンドのバージョンがやや古いせいか、新しく作成してくれない。（/dev/md0だけは最初からあるので、1個目のアレイは正常に作成できるはず）
上記の例では、「/dev/md1」というデバイスが無いというエラーになっている。CentOSではこのようなエラーは出ないのであるが…
で、このような場合は、/dev/mdナントカ というデバイスファイルを手動で作成する必要がある。手動で作成した後で、mdadmコマンドでアレイを構築すれば解決。
まず、/devディレクトリ配下を見ておこう。
確かに/dev/md0しか無く、/dev/md1は存在していない。
ここでmknodコマンドを用いて/dev/md1を作成する。書式は
mknod デバイス名 b デバイスメジャー番号 デバイスマイナー番号
ということになる。デバイスメジャー番号・デバイスマイナー番号に何を指定すればよいか。それは先ほどのlsコマンドの結果にヒントがある。ファイルのオーナー表示（「root disk」）に続いて「9, 0」という表示があるのが判る。この9が/dev/md0のデバイスメジャー番号、0が/dev/md0のデバイスマイナー番号ということになる。/dev/mdナントカを新規に作成する場合は、デバイスメジャー番号は同じに、デバイスマイナー番号は「/dev/mdナントカ」の『ナントカ』と同じ番号を指定することとなる。つまり、/dev/md1を作成する場合は、デバイスメジャー番号は９に、デバイスマイナー番号は１に指定すればよいということである。
ということは、mknodコマンドの指定方法としては…
mknod /dev/md1 b 9 1
と記述すれば良いことに。
実行して確認してみよう。
と、/dev/md1がそれっぽく作成されたことが判る。
それでは、mdadmコマンドを再度実行してみよう。
mdadmコマンドがエラーにならず、新しいアレイが構築されていることが判る。（ディスクを使い回ししているので途中確認を求められている表示があるがキニシナイ！）
あとはCentOSと同じように操作してもらえばよい。
具体的には、２個目のアレイを作成しようとしてmdadm --create...コマンドを投入すると、/dev/md?が無いというエラーが出るというもの。
CentOSの場合は、mdadm --create /dev/mdナントカ を実行すると、新しい/dev/mdナントカを自動で作成してくれるのだが、VineLinuxの場合、mdadmコマンドのバージョンがやや古いせいか、新しく作成してくれない。（/dev/md0だけは最初からあるので、1個目のアレイは正常に作成できるはず）
[root@k1 root]# mdadm --create /dev/md1 --level=5 --raid-devices=8 /dev/sd[ghijklmn] mdadm: error opening /dev/md1: No such file or directory
上記の例では、「/dev/md1」というデバイスが無いというエラーになっている。CentOSではこのようなエラーは出ないのであるが…
で、このような場合は、/dev/mdナントカ というデバイスファイルを手動で作成する必要がある。手動で作成した後で、mdadmコマンドでアレイを構築すれば解決。
まず、/devディレクトリ配下を見ておこう。
[root@k1 root]# ls -la /dev/md* brw-r----- 1 root disk 9, 0 3月 3日 13:45 /dev/md0
確かに/dev/md0しか無く、/dev/md1は存在していない。
ここでmknodコマンドを用いて/dev/md1を作成する。書式は
mknod デバイス名 b デバイスメジャー番号 デバイスマイナー番号
ということになる。デバイスメジャー番号・デバイスマイナー番号に何を指定すればよいか。それは先ほどのlsコマンドの結果にヒントがある。ファイルのオーナー表示（「root disk」）に続いて「9, 0」という表示があるのが判る。この9が/dev/md0のデバイスメジャー番号、0が/dev/md0のデバイスマイナー番号ということになる。/dev/mdナントカを新規に作成する場合は、デバイスメジャー番号は同じに、デバイスマイナー番号は「/dev/mdナントカ」の『ナントカ』と同じ番号を指定することとなる。つまり、/dev/md1を作成する場合は、デバイスメジャー番号は９に、デバイスマイナー番号は１に指定すればよいということである。
ということは、mknodコマンドの指定方法としては…
mknod /dev/md1 b 9 1
と記述すれば良いことに。
実行して確認してみよう。
[root@k1 root]# mknod /dev/md1 b 9 1 [root@k1 root]# ls -la /dev/md* brw-r----- 1 root disk 9, 0 3月 3日 13:45 /dev/md0 brw-r----- 1 root disk 9, 1 3月 4日 11:21 /dev/md1
と、/dev/md1がそれっぽく作成されたことが判る。
それでは、mdadmコマンドを再度実行してみよう。
[root@k1 root]# mdadm --create /dev/md1 --level=5 --raid-devices=8 /dev/sd[ghijklmn]
mdadm: /dev/sdi appears to contain an ext2fs file system
size=-2147483648K mtime=Wed Jul 23 15:17:05 2008
Continue creating array? y
mdadm: array /dev/md1 started.
[root@k1 root]# cat /proc/mdstat
Personalities : [raid5] [raid4]
md1 : active raid5 sdn[8] sdm[6] sdl[5] sdk[4] sdj[3] sdi[2] sdh[1] sdg[0]
6837337472 blocks level 5, 64k chunk, algorithm 2 [8/7] [UUUUUUU_]
[>....................] recovery = 0.0% (17272/976762496) finish=3763.9min speed=4318K/sec
md0 : active raid5 sdf1[3] sde1[2] sdd1[1] sdb1[0]
2930279808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices:
mdadmコマンドがエラーにならず、新しいアレイが構築されていることが判る。（ディスクを使い回ししているので途中確認を求められている表示があるがキニシナイ！）
あとはCentOSと同じように操作してもらえばよい。
LVMのボリュームグループ名を変更したい [Linux(LVM/RAID/Storage)]
そうそう頻繁に発生するような事態ではないけども、ボリュームグループ名を変更したい…というケースもあるかもしれない。その方法は以下の通り。
vgrename 古いVG名 新しいVG名
これでVG名が変更できる。当然だが、これをやるとマウントしたりする際のデバイス名も変更になるので要注意。（当然、マウントしたままでは実行できない）つまり、「/dev/古いVG名/LV名」が「/dev/新しいVG名/LV名」と、いうことになるので。
vgrename 古いVG名 新しいVG名
これでVG名が変更できる。当然だが、これをやるとマウントしたりする際のデバイス名も変更になるので要注意。（当然、マウントしたままでは実行できない）つまり、「/dev/古いVG名/LV名」が「/dev/新しいVG名/LV名」と、いうことになるので。
ぴろりん さん
-
nice! 18
記事 143
テーマ パソコン・インターネット
プロフィール
ブログを紹介する