seraphyの日記

日記というよりは過去を振り返るときのための単なる備忘録

CentOS5.2を使ったサーバのレスキューモードでの手順(訓練メモ)

LinuxソフトウェアRAIDや論理ボリュームを使ったマシンのリカバリ作業なんて経験ないから、なにかあってからでは怖いので、
ためしに同じ構成をVMWareで作ってリカバリ作業を試してみた。

結論的には、いくつか注意事項がわかったので、なにかあったときのためのメモを残す。

RAID構成をフロッピー等に保存しておく。

mdadm.confはレスキューモードで必要である。

mdadm.confがなくても通常の運用は何の問題もなく、何のためにあるのかいまいちわからなかった。
実際、レスキューモードでも両方のRAID1デバイスが生きていれば問題なく、/mnt/sysimageにマウントしてくれる。

ところが、RAIDバイスの片方が死んでいたりすると、レスキューモードではRAIDバイスを認識せず、結果、/mnt/sysimageには何もマウントされない。
RAIDバイスが死んでいるので、/dev/md0 とかも使えない。

これではメンテナンスができない。

RAIDバイスを認識させるには、RAIDの構成情報を納めたconfファイルがあると簡単なようである。
(ない場合は、どうするのかわからない…。地道にデバイスを指定してゆけば認識できるらしいけれど??)

なので、とりあえずmdadm.confファイルだけはバックアップをとっておく必要がありそうだ。

まず現在のRAID情報を保存する。
mdadm -E --scan >> mdadm.conf

で現在のRAID構成の情報を「mdadm.conf」ファイルに保存する。

保存するにはフロッピーとかがよいのではないかと思う。少なくともRAID1化されているHDDに入れても意味がないと思う。


mdadm.confの先頭には

device /dev/hda* /dev/hdb*

のようにスキャンするデバイスを書いておく。

レスキューモードで立ち上げる

レスキューモード等で立ち上げたときに/dev/md?が生きていない場合、

mdadm -A --config=mdadm.conf --scan

RAIDバイスを構成しなおして起動することができるようになる。

cat /proc/mdstat

RAIDバイスが起動していることを確認する。


論理ボリュームマネージャをアクティブにする

レスキューモードで立ち上がったときに/dev/md? が認識されていなければ、その下にある論理ボリュームもアクティブになっていない。

論理ボリュームの構成そのものはデバイスのスーパーブロック上にテキストとして埋め込まれているらしくて、デバイスさえ見える状態になっていれば認識させるのは簡単らしい。

でも、一応、論理ボリュームの構成を保存する方法があるらしいので、これも保存しておいたほうが良さそうだ。

論理ボリュームの構成を保存する。
lvm vgcfgbackup -f lvm.conf

で論理ボリュームの代替パックアップファイルを作成しておく。

これは念のため。たぶん、これを明示的に使うことはないと思う。

論理ボリュームの構成がかわるたびに自動的に実行され、ふだんは気にすることはないらしい。


論理ボリュームマネージャをアクティブにする。


RAIDバイスが見えている状態で、LVMが開始されていないのならば、

lvm pvscan
lvm vgscan
lvm lvscan

を順に実行して論理ボリュームをスキャンすれば、たぶん、認識はできる。

だめなら、lvm vgcfgresroteとかで保存した構成ファイルを使うのかもしれないが、未確認。


認識できたら、

lvm vgchange -a y ...

でLVMを開始できる。

論理ボリュームをマウントする

あとは、いつもどおりにマウントすればよい。

mount -o ro /dev/VolGroup00/LogVol00 /mnt/sysimage

ルートに対してマウント解除せずfsckを実行する方法

fsckはマウントされている状態では実行してはならないのはLinuxの常識らしい。*1

では、ルートに対してfsckをかけるにはどうしたらよいのか?

わからなかったので調べてみた。

何回マウントする毎に、あるいは何日ごとにfsckをかけるというオプションがあるらしいので、これを使うのが良いらしい。

そこで、ルートとしてマウントされる論理ボリュームには、どんな設定がされているのか見てみた。

すると、回数は-1、日付は無期限になっていて、つまり、fsckはしない、という設定になっている。(これはCentOS5.2デフォルトの設定だと思う。)

この意図するところがわからないのだが、つまりfsckは再起動しても永久にかかることはなさそうだ。

では、他にWindowschkdskのようにお手軽に確認する方法はないものだろうか?(あれもシステムドライブは起動時にチェックするしかないけれど。)

レスキューモードで立ち上げれば、むろん可能だが、論理ボリュームを使っているのならばスナップショットを使うことで確認はできるようである。

lvcreate --snapshot --size=1G --name=snap /dev/VolGroup00/LogVol00
fsck -f /dev/VolGroup00/snap

こんな感じでスナップショットを作れば、それに対してチェックはできるようである。

ただし、仮に修復してもsnapshotへの書き込みは本体へは反映されないので、その場合はレスキューモードでやることになるのだと思う。

とりあえず、これでシステムを止めずに確認することはできそう。*2

サイズの大きなボリュームに対して起動時にfsckをかけるのはbad ideas、やるならスナップショットをとってやれ、と、どこかの掲示板に書かれていたが、たぶん、CentOS5.2の標準でそうなっているのは、そうゆう理由なのだと思う。

*1:やってみましたよorz。仮想イメージだったからよかったけれど、これが実機だったら最悪ですね。もう、本当に確実に壊れてくれました。

*2:物理的に問題があればスナップショットの作成時点でエラーになりそうな気が一瞬したのだけれど、そうじゃないのか。スナップショットを作成した時点では物理ディスクを走査したりコピーしたりするわけではないから、その時点ではエラーはわからないのか。なので、fsckでチェックすれば実際のボリュームに対してチェックをかけているのとイコールということになりそう。これは、たしかに良い方法かもしれない。

vmware/virtualboxの仮想フロッピーメディアの作り方(余談)

VMWareでの仮想fdメディアの作り方

今回の実験をするのにVMWare Playerを使ったが、VMWareの仮想ハードディスクを作成するにはqemu-img.exeを使っている。

では、レスキューモードでmdadm.confを読ませるための仮想フロッピーはどうやって作れるのか?

結論的には、vmwareで仮想フロッピーイメージを作るには、何らソフトは必要ないようである。

単にサイズゼロの「ファイル名.flp」ファイルを作成するだけで良いようである。

これが仮想フロッピーイメージとなり、vmwareでフロッピーイメージを接続するだけで良い。

そのあと、

fdformat /dev/fd0

とフォーマットすれば、仮想イメージが1.44MBぐらいになるのが確認できる。

あとは、いつものように

mkfs -t ext2 /dev/fd0

とかでフォーマットすればファイルシステムとしてマウントして使えるようになる。

VirtualBoxでの仮想fdメディアの作り方

VirtualBoxでは仮想フロッピーは実サイズのファイルが必要なようである。

中身はどうでも良いので、コマンドプロンプトよりfsutilコマンドをつかって固定サイズのファイルを作成する。

fsutil file createnew myimage.vfd 1474560

https://gist.github.com/seraphy/6787353 (2013/10/02)より転記