ダンプ採取について

[KN]

いつもご利用させていただいております。

lvol2をswap+dumpに設定し、内臓ディスク2つでミラーリングしています。

マスタディスクにトラブルが発生し、ミラー先のディスクだけで運用するようになった場合、ダンプの採取は可能なのでしょうか？

[N.Hanyu]

こんにちは。

可能ですよ。

この質問に至った経緯は、lvlnbootでdump領域が

1つしか見えないからでしょうか？

ダンプ取得時は、ミラーをしていてもどちらか片方

のディスクしか使用しません。

[KN]

こんにちは。

早速のご回答どうもありがとうございます。

はい、lvlnboot -vの結果は以下となってます。

# lvlnboot -v

Boot Definitions for Volume Group /dev/vg00:

Physical Volumes belonging in Root Volume Group:

/dev/dsk/c0t6d0 (1/0/0/3/0.6.0) -- Boot Disk

/dev/dsk/c3t6d0 (1/0/1/0/0/1/1.6.0) -- Boot Disk

Boot: lvol1 on: /dev/dsk/c0t6d0

/dev/dsk/c3t6d0

Root: lvol3 on: /dev/dsk/c0t6d0

/dev/dsk/c3t6d0

Swap: lvol2 on: /dev/dsk/c0t6d0　　　

/dev/dsk/c3t6d0

Dump: lvol2 on: /dev/dsk/c0t6d0, 0

この場合、c0t6d0が故障して、c3t6d0で運用中にクラッシュしても、再起動時には、/var/adm/crash配下にダンプが採取されているということになるのでしょうか？

なにかでダンプ領域はミラーされないと伺ったので、ミラー先ディスクのc3t6d0のlvol2には、swap領域としてのみ確保されているのかなと考えました。

[N.Hanyu]

こんにちは。

プライマリディスクに障害が発生し、セカンダリディスク

運用に入った際に、セカンダリディスクのlvol2が、

dump領域としても使用されるようになります。

なぜdumpは片方のディスクしか使わないのか？

　システムクラッシュ時に、swap領域にごみが

残っていた場合、起動時に逆方向で同期を行われた場合

メモリダンプが消滅する恐れがあるからです。

　ちなみにミラー一貫性回復off設定するのはswapには

boot時に同期を取る必要が無いからです。dumpの上書き

を回避する為。

　

[KN]

非常に納得できました。

ミラー一貫性回復設定の付加情報もありがとうございます。

申し訳ないですが、追加で質問させてください。

例えば、lvol2をswap、lvol3をdumpに設定し、内臓ディスク2つでミラーリングした場合、プライマリディスクに障害が発生し、セカンダリディスクの運用に入った際は、セカンダリディスクのlvol3がdump領域としても使用されることになるのでしょうか？

[N.Hanyu]

>セカンダリディスクのlvol3がdump領域としても

>使用されることになるのでしょうか？

　KNさんの例では、lvol3はswap（lvol2）と分けている

ので、上記事象の場合は、dump領域としてもではなく

dump領域として使われます。

　揚げ足をとっているような気もしますが・・・

[KN]

承知しました！

どうもありがとうございました。

[小山亜紀子]

いつもお世話になっております。

以前、swap+dump領域をミラーリングしていて、プライマリディスクにトラブルがあったため、プライマリディスクを抜いて、ミラーディスクのみで運用したことがありました。

そのときcrashconf -vコマンドでダンプデバイスを

確認すると以下のようなメッセージが表示され、OSは

ダンプデバイスを認識できていないようでした。

”No crash dump devices defined.”

恐らく、ミラーディスクに2次ダンプを作成しなけらば、ミラーディスクのみの運用時には、ダンプ採取はできないと思います。

以下は、crashconf　-vコマンドの実行結果です。

# crashconf -v Hewlett-Packard Company

CLASS PAGES INCLUDED IN DUMP DESCRIPTION

-------- ---------- ---------------- -------------------------------------

UNUSED 4476 no, by default unused pages

USERPG 35589 no, by default user process pagess are as set

BCACHE 6033 no, by default buffer cache pages

KCODE 2430 no, by default kernel code pages

USTACK 663 yes, by default user process stacks

FSDATA 53 yes, by default file system metadata

KDDATA 12239 yes, by default kernel dynamic data

KSDATA 4053 yes, by default kernel static data

Total pages on system: 65536

Total pages included in dump: 17008

No crash dump devices defined.

[N.Hanyu]

こんにちは。

参考にしたいので教えてください。

この状態で、lvlnboot -d /dev/vg00/lvol2

などで再設定は効きましたか？

[oops]

ダンプはミラーできませんので、採取は不可能です。

壊れたことに気づいたら、一度ダンプを lvrmboot で削除して、lvlnboot で再度ダンプを設定すれば、残ってる側を新しいダンプエリアとして使えますが、それだと修理後にまた設定をやり直さないといけませんし、あまり良い方法とは思えません。

一番いいのは、壊れていることに気づいたら、冗長性もなくなりますし、早く修理することだと思います。

[oops]

追加になりますが、壊れたディスクにアクセスに行くのも良くないと思いますので、そういう意味でも lvrmboot/lvlnboot は止めた方がいいと思います。ディスクの壊れ方にもよると思いますが、コマンドがハングする可能性もありますから。

やはり早く修理することが一番でしょう。