付録A よくある質問

問: クラスター化された環境で Kdump を使用する場合には、何に注意したら良いですか?
問: 起動初期に Kdump が失敗します。どのようにしてブートログをキャプチャーするのですか?
問: デバッグ用に、どのようにして makedumpfile からのメッセージを増やすのですか?
問: どのようにして Dracut をデバッグするのですか?
問: 仮想マシンで利用可能なダンプの方法は何ですか?
問: Red Hat サポートサービスに大きなサイズのダンプをアップロードする場合はどうしたらいいですか ?
問: クラッシュダンプが完了するまでに、どれくらい時間がかかりますか?
問: インストール時に Kdump をどのように設定するのですか?
問:
クラスター化された環境で Kdump を使用する場合には、何に注意したら良いですか?
答:
How do I configure kdump for use with the RHEL 6, 7 High Availability Add-On?」の記事に、High Availability アドオンを使用しているシステム管理者が利用可能なオプションが説明されています。
問:
起動初期に Kdump が失敗します。どのようにしてブートログをキャプチャーするのですか?
答:
2 番目のカーネルの起動に問題がある場合は、起動初期のブートログを確認する必要があります。問題のあるマシンに対するシリアルコンソールを有効にすることで、このログを取得することができます。
How does one set up a serial terminal and/or console in Red Hat Enterprise Linux?」の記事に、起動初期のブートメッセージへアクセスするために必要な設定が説明されています。
問:
デバッグ用に、どのようにして makedumpfile からのメッセージを増やすのですか?
答:
makedumpfile が失敗する時には、何が悪いのかを理解するためにログのレベルを増やさなければならない場合があります。これはダンプレベルを設定するのとは異なる操作です。ログのレベルについては、/etc/kdump.confcore_collector 行エントリーを編集して、makedumpfile に対する message_level オプションを増やします。
デフォルトでは makedumpfile はレベル 7 に設定されていて、プログレスインジケーター、共通メッセージ、およびエラーメッセージの出力が含まれます。このレベルを 31 に設定して、詳細なデバッグ情報を取得します。
core_collector 設定行は、設定時にはこのようになっているはずです。
core_collector makedumpfile -l --message-level 1 -d 31
問:
どのようにして Dracut をデバッグするのですか?
答:
dracut が initramfs の構築に失敗することがあります。その場合には、問題を切り分けるために dracut のログレベルを増やす必要があります。
/etc/kdump.conf を編集して dracut_args 行を変更し、必要なすべての dracut 引数と共にオプション -L 5 を含めます。
dracut_args で他のオプションを設定しなければ、このような結果になるはずです。
dracut_args -L 5
問:
仮想マシンで利用可能なダンプの方法は何ですか?
答:
多くの場合、クラッシュやパニックの後にマシンからメモリーダンプを取得するには kdump の仕組みがあれば十分です。これは、ベアメタルのインストールと同じように設定することができます。
しかし、場合によっては、ハイパーバイザーと直接連携してクラッシュダンプを取得する必要がある場合があります。ハイパーバイザーを使用したクラッシュダンプの取得方法として libvirt には pvpanicvirsh dump という 2 つの仕組みがあります。これらの方法は『仮想化の導入および管理ガイド』に記載されています。
pvpanic の仕組みについては、『仮想化の導入および管理ガイド』の「パニックデバイスの設定」に記載されています。
問:
Red Hat サポートサービスに大きなサイズのダンプをアップロードする場合はどうしたらいいですか ?
答:
分析のため Red Hat グローバルサポートサービスにカーネルクラッシュのダンプファイルを送信していただかなければならない場合があります。ただし、ダンプファイルのサイズはフィルターで特定の情報に絞り込んだ場合でも非常に大きくなる可能性があります。新しいサポートケースを開いた場合、250 MB を超えるファイルは Red Hat カスタマーポータルからは直接アップロードしていただくことができないため、Red Hat では大きなサイズのファイルのアップロード用に FTP サーバーを用意しています。
FTP サーバーのアドレスは dropbox.redhat.com になります。ファイルは /incoming/ ディレクトリーにアップロードしてください。ご使用の FTP クライアントを passive モードに設定しておく必要があります。ご使用のファイアウォールでこのモードを許可していない場合は origin-dropbox.redhat.com サーバーを active モードで使用していただくことができます。
アップロードするファイルは必ず gzip などで圧縮し、ファイル名にはわかりやすい名前を付けてください。ファイル名にサポートケース番号を使用されることをお勧めします。必要なファイルをすべてアップロードしたらサポートケース担当のエンジニアへ正確なファイル名とその SHA1 または MD5 チェックサムをお知らせください。
詳細な説明については「How to provide files to Red Hat Support」をご覧ください。
問:
クラッシュダンプが完了するまでに、どれくらい時間がかかりますか?
答:
災害対策計画を作成するためには、通常、ダンプ完了までの時間を把握している必要がありますが、所要時間は、ディスクにコピーされるメモリーの量や、メモリーとストレージのインターフェースのスピードに大きく左右されます。
テストがどのようなタイミングで行われても、システムは典型的な負荷をかけた状態で稼働させておく必要があります。そうでないと、除外されるページによって、完全に負荷がかかった実稼動システムでの kdump 動作が得られない場合があります。この差異は、大量の RAM が使用されている状況でより顕著に見られます。
ダンプの所要時間を評価する際に、ストレージインターフェースもプランニング時に考慮する必要があります。ネットワーク制約事項が原因で、ローカルに接続された SATA ディスクと比べると、ssh などを使用した接続ダンプは完了までに長く時間がかかる可能性があります。
問:
インストール時に Kdump をどのように設定するのですか?
答:
キックスタートまたは対話型の GUI を使用すれば、わずかなオプションを指定するだけでインストール時に kdump を設定することができます。
anaconda インストール GUI を使用した kdump の設定については、『インストールガイド』の「Kdump」セクションに詳しい説明が記載されています。
kickstart の構文は、以下のとおりです。
%addon com_redhat_kdump [--disable,enable] [--reserve-mb=[auto,value]]
%end
キックスタートに対するこのアドオンにより、kdump 機能の無効化/有効化や、オプションとして予約メモリーサイズの定義 (自動のデフォルトオプションを明示的に呼び出す、またはメガバイト単位で数値を指定する) が可能になります。なお、スイッチ全体が省略された場合も、デフォルトオプションが呼び出されます。
キックスタートを使用してシステムのデプロイメントを自動化する方法の詳細は、『インストールガイド』の「キックスタートを使ったインストール」を参照してください。
キックスタートアドオン構文の詳細については、『インストールガイド』の「キックスタート構文の参考資料」を参照してください。