1号機は電源を再度入れても正しく起動しなかったことから、やはりハードウェア障害が発生していました。具体的には、ハードウェア保守ベンダーに連絡して調査してもらう必要があります。
それと平行して、今後の対策と対処に必要な準備と確認をあらためて行います。
一般的に、クラスタノードそのものが停止してしまうケースの場合は、SQL Serverの問題ではないところで起きるケースがほとんどです。ハードウェア障害で電源すら入らなくなるケースもあれば、ハードウェアドライバの問題でブルースクリーン(BSOD:Blue Screen of Death)になってOSが停止することもあります。なお、電源が突然落ちてしまう障害のケースではログ情報が残らないこともあるのですが、OSがハードウェアからの信号を受けて停止するケースならば、そのときの情報を残した後に停止します。その情報は「ダンプファイル」と呼ばれるファイルに保存されます。
今後の対策と万が一時に備えた準備として、あらかじめOS側でメモリダンプを取っておくことが肝要です。ある時点のメインメモリの内容をディスクに残しておく「メモリダンプ(クラッシュダンプ)」は、OSがBSODで急停止した場合以外に、ユーザー側のコマンド操作で明示的に取得することも可能です。OSのメモリダンプについては以下の種類があります。
Windowsが取得できるメモリダンプの種類 | 説明 |
---|---|
最小メモリダンプ | 最大でも1MB程度のサイズのダンプファイル。停止したエラーコードと周辺情報、パラメーター、ドライバのリストが含まれる |
カーネルダンプ | OSとデバイスドライバに割り当てられ、BSODが起きた時にロードされていたカーネルで使うメモリ情報が記録される |
完全メモリダンプ | BSODになったときにWindowsからアクセスできる全ての物理メモリの情報が記録される |
OSのメモリダンプは「完全メモリダンプ」の取得を推奨します。
その理由は、恒久対策のためです。最小メモリダンプ/カーネルダンプでは、障害解析のための情報が十分でないことがあります。完全メモリダンプを取得することで、最大限の障害情報を保全できます。
なお、完全メモリダンプの取得には、以下の条件を満たしておく必要があります。
これらの条件が満たされない場合にはダンプファイルが正しく作成されないので注意してください。
Windows Serverにおけるメモリダンプ取得の設定は、システムのプロパティ→詳細設定で開く「起動と回復」から行えます。デバッグ情報の書き込み欄から「完全メモリダンプ」を選び、ダンプファイル欄に保存先のディレクトリとファイル名を指定します(図24-2)。
今回はノード障害時におけるパターンと、その次を見据えた対策方法を紹介しました。障害によって発生した際のダンプファイルは、お使いのサーバを保守しているベンダーに併せて提出して、解析してもらうことで、ベンダー側の対策や早さ/確実さを含めて今後の対策につながります。
なお、ダンプファイルの解析は高いスキルと経験が必要となります。本記事のカバー範囲を超えることから、ここでは「少なくとも押さえておく対策」の紹介に留めます。ダンプファイルについては、別の機会にまた紹介できればと思います。
ユニアデックス株式会社 NUL System Services Corporation所属。Microsoft MVP Data Platform(2011〜)。OracleやSQL Serverなど商用データベースの重大障害や大型案件の設計構築、プリセールス、社内外の教育、新技術評価を担当。2016年IoTビジネス開発の担当を経て、2016年現在は米国シリコンバレーにて駐在員として活動中。目標は生きて日本に帰ること。
ユニアデックス株式会社所属。入社以来 SQL Serverの評価/設計/構築/教育などに携わりながらも、主にサポート業務に従事。SQL Serverのトラブル対応で社長賞の表彰を受けた経験も持つ。休日は学生時代の仲間と市民駅伝に参加し、銭湯で汗を流してから飲み会へと流れる。
Copyright © ITmedia, Inc. All Rights Reserved.