(57)【要約】【課題】  ＣＰＵ上で同種または異種のＯＳが並列動作する実行環境で、ＣＰＵ又はＯＳで障害が発生すると、ＯＳ側でメモリダンプの内容を共有メモリ上に退避した後、直ちに障害発生ＯＳの再起動を行なうことにより、障害発生時のシステム再開時間を短縮することを目的とする。【解決手段】  第１のＣＰＵ又は第１のＯＳにより障害発生が検出されると、第２のＯＳが障害発生時の第１のＣＰＵのレジスタ情報と、第１のＯＳのメモリダンプ内容とを共有メモリに書き込み、第２のＯＳが共有メモリに書き込まれたレジスタ情報とメモリダンプ内容とを二次記憶装置に保存し、レジスタ情報とメモリダンプ内容とが共通メモリに書き込まれると第１のＯＳが直ちに再起動をする。【選択図】        図１
2007334403.tif 000002
【特許請求の範囲】
【請求項１】
第１のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）上で独立又は他のＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）と並列に動作する第１のＯＳと、
前記第１のＣＰＵ又は前記第１のＯＳにより障害発生が検出されると前記第１のＯＳにより障害発生時の前記第１のＣＰＵのレジスタ情報と、障害発生時の前記第１のＯＳのメモリダンプ内容とが書き込まれる共有メモリと、
前記レジスタ情報と前記メモリダンプ内容とが保存される二次記憶装置と、
前記第１のＣＰＵ又は前記第１のＯＳでの障害発生時に前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記二次記憶装置に保存し、第２のＣＰＵ上で独立又は他のＯＳと並列に動作する動作する第２のＯＳと、を備え、
前記第１のＯＳは、前記レジスタ情報と前記メモリダンプ内容とが前記共通メモリに保存されると直ちに再起動されることを特徴とする計算機システム障害対応方式。
【請求項２】
前記第１のＯＳは、前記第１のＣＰＵ又は前記第１のＯＳにより障害発生が検出されると前記レジスタ情報を前記共有メモリに書き込む障害検出手段と、前記メモリダンプ内容を前記共有メモリに書き込むダンプ退避手段と、前記第１のＣＰＵ又は前記第１のＯＳの障害発生通知を前記第２のＯＳに送信する障害通知手段と、前記共通メモリに前記レジスタ情報と前記メモリダンプ内容とが書き込まれると前記第１のＯＳを再起動する再起動実行手段とを備え、
前記第２のＯＳは、前記障害通知手段により送信された前記障害発生通知を受信する障害受信手段と、前記障害発生通知を受信すると前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記二次記憶装置に保存するダンプ保存手段とを備えたことを特徴とする請求項１記載の計算機システム障害対応方式。
【請求項３】
前記メモリダンプ内容は、前記第１のＯＳが占有するメモリ領域又は前記第１のＯＳ管理下のメモリ領域又は前記第１のＯＳにより起動するアプリケーションが占有するメモリ領域の各内容であり、
前記再起動実行手段は、前記共通メモリに前記レジスタ情報と前記メモリダンプ内容とが書き込まれると前記第１のＯＳ又は前記アプリケーションを再起動することを特徴とする請求項２記載の計算機システム障害対応方式。
【請求項４】
前記ダンプ退避手段は、前記第１のＯＳが占有するメモリ領域と前記第１のＯＳ管理下のメモリ領域との各内容に分割して前記共有メモリに書き込み、
前記障害通知手段は、前記ダンプ退避手段により前記第１のＯＳが占有するメモリ領域と前記第１のＯＳ管理下のメモリ領域との各内容が分割されて前記共有メモリに書き込まれる度に障害発生通知を前記第２のＯＳに送信し、
前記ダンプ保存手段は、前記ダンプ退避手段により前記共有メモリに書き込まれた前記第１のＯＳが占有するメモリ領域と前記第１のＯＳ管理下のメモリ領域との内容を区切って前記二次記憶装置に保存し、
前記再起動実行手段は、前記共有メモリ上に書き込まれた前記第１のＯＳが占有するメモリ領域と前記第１のＯＳ管理下のメモリ領域との内容を再起動することを特徴とする請求項３記載の計算機システム障害対応方式。
【請求項５】
前記ダンプ退避手段は、前記第１のＯＳにより起動するアプリケーションが占有するメモリ領域の内容をアプリケーション単位に分割して前記共有メモリに書き込み、
前記障害通知手段は、前記ダンプ退避手段により前記メモリ領域の内容がアプリケーション単位に分割されて前記共有メモリに書き込まれる度に障害発生通知を前記第２のＯＳに送信し、
前記ダンプ保存手段は、前記ダンプ退避手段により前記共有メモリに書き込まれたアプリケーション単位に分割されたアプリケーションのメモリ領域の内容を区切って前記二次記憶装置に保存し、
前記再起動実行手段は、前記共有メモリ上に書き込まれたアプリケーション単位に分割されたメモリ領域の内容毎に再起動することを特徴とする請求項３記載の計算機システム障害対応方式。
【請求項６】
前記レジスタ情報と前記メモリダンプ内容とを保存する複数の二次記憶装置を備え、
前記ダンプ保存手段は、前記複数の二次記憶装置の中から前記メモリダンプ内容を保存する二次記憶装置の選択を指示し、又選択された二次記憶装置に前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを保存し、
前記第２のＯＳは、前記複数の二次記憶装置毎にエントリされた二次記憶装置のＩＤと名称と空き容量と使用可否と保存先優先順位とにより構成されたダンプデバイステーブルと、前記ダンプ保存手段により二次記憶装置の選択が指示されると前記ダンプデバイステーブルに基づいて前記メモリダンプ内容を保存する二次記憶装置を選択し、この選択した二次記憶装置の情報を前記ダンプ保存手段に返信するデバイス選択部とを備えたことを特徴とする請求項２記載の計算機システム障害対応方式。
【請求項７】
前記障害受信手段と前記ダンプ保存手段とを有し複数のＣＰＵ上でそれぞれ独立かつ並列に動作する複数のＯＳを備え、
前記第１のＯＳは、ＣＰＵを特定するＣＰＵ番号とこのＣＰＵ番号に対応する二次記憶装置のＩＤと名称と空き容量と使用可否と保存先優先順位とを1つのエントリとする複数のエントリにより構成されたＯＳ選択テーブルと、前記ＯＳ選択テーブル基づいて前記メモリダンプ内容を保存するＯＳを起動するＣＰＵと前記メモリダンプ内容の保存先の二次記憶装置を選択する保存ＯＳ選択手段とを備え、
前記保存ＯＳ選択手段により選択されたＣＰＵにより起動されたＯＳのダンプ保存手段は、前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記保存ＯＳ選択手段により選択された二次記憶装置に保存することを特徴とする請求項２記載の計算機システム障害対応方式。
【請求項８】
前記第２のＯＳは、前記障害通知手段により前記障害発生通知を受信すると前記第２のＯＳを起動するＣＰＵのレジスタ情報を前記共有メモリに書き込み、さらに前記第２のＯＳ管理下のメモリ領域の内容又は障害発生が検出された前記第１のＯＳにより起動するアプリケーションと連携動作する他のアプリケーションのメモリ領域の内容であるメモリダンプ内容を前記共有メモリに書き込む第２のＯＳダンプ退避手段とを備え、
前記ダンプ保存手段は、前記第２のＯＳダンプ退避手段により前記共有メモリに書き込まれたメモリダンプ内容を前記二次記憶装置に保存することを特徴とする請求項２記載の計算機システム障害対応方式。
【請求項９】
第１のＣＰＵ上で独立又は他のＯＳと並列に動作する第１のＯＳと、レジスタ情報とメモリダンプ内容が一時的に書き込まれる共有メモリと、前記レジスタ情報と前記メモリダンプ内容とが保存される二次記憶装置と、前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記二次記憶装置に保存する第２のＣＰＵ上で独立又は他のＯＳと並列に動作する動作する第２のＯＳとを備えた計算機システム障害対応方式による計算機システム障害対応方法であって、
前記第１のＯＳは、前記第１のＣＰＵ又は前記第１のＯＳにより障害発生が検出されると前記レジスタ情報と前記メモリダンプ内容とを前記共有メモリに書き込む書き込みステップと、前記書き込みステップにより前記レジスタ情報と前記メモリダンプ内容とを前記共有メモリに書き込んだ後に、前記第１のＣＰＵ又は前記第１のＯＳの障害発生通知を前記第２のＯＳに送信する送信ステップと、前記送信ステップにより前記第１のＣＰＵ又は前記第１のＯＳの障害発生通知を前記第２のＯＳに送信すると前記第１のＯＳを再起動する再起動ステップとを備え、
前記第１のＯＳは、前記送信ステップにより送信された前記障害発生通知を受信する受信ステップと、前記障害発生通知を受信すると前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記二次記憶装置に保存する保存ステップを備えたことを特徴とする計算機システム障害対応方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、計算機システムに障害が発生した時の障害対応方式及び計算機システム障害対応方法に関するものである。
【背景技術】
【０００２】
計算機システムにおいて、障害発生時に物理メモリの内容を二次記憶装置に保存（これをメモリダンプと呼ぶ）しておき、障害原因の解析に活用する手法が一般的に利用されている。
従来のマルチＯＳ実行環境でのメモリダンプ実行方式を以下に説明する（特許文献１）。図１０は従来の計算機システムの構成、また、図１１は障害対応処理を行なう従来の計算機システムの第１ＯＳの割込み処理手順を示すフローチャートである。
従来の方式では、単一ＣＰＵ上で複数のＯＳが並行動作する実行環境において、障害が発生した第２ＯＳと並行に動作する第１ＯＳが第２ＯＳの障害対応処理を行なうことが開示されている。具体的には、第２ＯＳで障害が発生した時、第１ＯＳは障害発生割込みの通知を受け、第２ＯＳに割り付けられていた物理メモリ領域情報を格納した後（ステップＳ３０３）、この領域を除く新たな物理メモリ上に第２ＯＳをロードし（ステップＳ３０５）、再起動を行なう（ステップＳ３１０）。
【０００３】
次に、第１ＯＳは第２ＯＳの再起動終了割込みの通知を受け、先ほど格納した物理メモリ領域情報を元に、メモリダンプ処理を行なう（ステップＳ３１１）。なお、本従来方式では、メモリダンプ処理の具体的な方法や実施内容の詳細については、何ら開示も示唆もされていない。
以上のように、従来の方式は、障害発生ＯＳの再起動処理と非同期にメモリダンプを取得可能にすることによって、障害発生時のメモリダンプ取得処理によるＯＳ再起動時間の遅延を短縮していた。
【特許文献１】特開２００１−２９０６７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来のメモリダンプ実行方式は、第１ＯＳ側のメモリダンプ取得処理が割込み処理の延長として実行されるため、第２ＯＳ側も再起動の完了までは高速に実行できるとしても、アプリ起動を含めたシステム再開までの時間が短縮されるわけではなく、またメモリダンプ処理によって第１ＯＳの通常処理に影響が発生するという問題点があった。
また、メモリダンプ取得処理を行なう第１ＯＳと保存先用デバイスドライバは固定であって、これらの制御プログラムにおいて障害が発生した場合、第２ＯＳのメモリダンプが取得できなくなるという問題点があった。
本発明は上記のような問題点を解決するためになされたもので、共有メモリ型のマルチプロセッサ構成であって、各ＣＰＵ上で同種または異種のＯＳが並列動作する実行環境において、障害発生ＯＳ側でメモリダンプの内容を共有メモリ上の特定領域に退避した後、直ちに障害発生ＯＳまたは障害発生アプリのみの再起動を行なう一方、障害発生通知を受けた他ＯＳが退避内容を参照して二次記憶装置への保存処理を行なうことにより、障害発生時のメモリダンプ取得処理によるシステム再開時間を短縮することを目的とする。
また、メモリダンプの保存先デバイスの接続有無やドライバのサポート状況、デバイスの空き容量等のシステム状況に応じて、メモリダンプの保存先デバイスや保存処理ＯＳを切り替え可能にすることにより、確実にダンプを取得することを目的とする。
【課題を解決するための手段】
【０００５】
この発明に係る計算機システム障害対応方式は、第１のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）上で独立又は他のＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）と並列に動作する第１のＯＳと、
前記第１のＣＰＵ又は前記第１のＯＳにより障害発生が検出されると前記第１のＯＳにより障害発生時の前記第１のＣＰＵのレジスタ情報と、障害発生時の前記第１のＯＳのメモリダンプ内容とが書き込まれる共有メモリと、
前記レジスタ情報と前記メモリダンプ内容とが保存される二次記憶装置と、
前記第１のＣＰＵ又は前記第１のＯＳでの障害発生時に前記共有メモリに書き込まれた前記レジスタ情報と前記メモリダンプ内容とを前記二次記憶装置に保存し、第２のＣＰＵ上で独立又は他のＯＳと並列に動作する動作する第２のＯＳと、を備え、
前記第１のＯＳは、前記レジスタ情報と前記メモリダンプ内容とが前記共通メモリに保存されると直ちに再起動されるものである。
【発明の効果】
【０００６】
この発明は、第１のＣＰＵ又は第１のＯＳにより障害発生が検出されると、第２のＯＳが障害発生時の第１のＣＰＵのレジスタ情報と、障害発生時の第１のＯＳのメモリダンプ内容とを共有メモリに書き込み、第２のＯＳが共有メモリに書き込まれたレジスタ情報とメモリダンプ内容とを二次記憶装置に保存し、レジスタ情報とメモリダンプ内容とが共有メモリに保存されると第１のＯＳが直ちに再起動されることにより、メモリダンプ内容を二次記憶装置１４に保存する処理を第１のＯＳとは独立かつ並列に動作する第２のＯＳが行なうので、障害発生時のメモリダンプ取得処理によるシステム再開時間を短縮することができる。
【発明を実施するための最良の形態】
【０００７】
実施の形態１．
図１は、実施の形態１の計算機システム障害対応方式の構成図である。
図１において、計算機システム１０はＯＳやアプリケーション等のプログラムを実行するためのＣＰＵ（１）１１やＣＰＵ（２）１２等の二個以上のＣＰＵと、いずれのＣＰＵからもアクセス可能なＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等を用いた共有メモリ１３と、プログラムやメモリダンプ内容等を保存するためのハードディスクやＦｌａｓｈメモリ等を例とする二次記憶装置１４と、ＣＰＵ間割込み定義を含む割込みコントローラ１５を備え、これらが内部及び外部のバス１６上に接続されている。また、各ＣＰＵ上では、それぞれ独立かつ並列に動作する同種または異種のＯＳ（１）１７とＯＳ（２）１８、及びアプリケーション１９、２０が動作し、各ＯＳ内にはメモリダンプ処理部２１、２２を、ＯＳ２側には二次記憶装置用ドライバ２３を備える。
【０００８】
図２は、実施の形態１の計算機システム障害対応方式の詳細構成図である。
図２において、ＣＰＵ（１）１１上で動作するＯＳ（１）１７は障害発生ＯＳ、ＣＰＵ（２）１２上で動作するＯＳ（２）１８は障害対応ＯＳである。障害発生ＯＳ（１）１７は、ＣＰＵまたはＯＳがシステムの異常を検出した時に呼び出される障害検出手段としての障害検出部３０、共有メモリ１３上にメモリダンプ内容を書き込む、即ち、共有メモリ１３上にメモリダンプ内容の退避を行なうダンプ退避手段としてのダンプ退避部３１、他のＯＳに対して障害発生の通知を行なう障害通知手段としての障害通知部３２、ＯＳ（１）１７の再起動または障害が発生したアプリケーション１９のみの再起動する再起動実行手段としての再起動実行部３３を備える。
【０００９】
共有メモリ１３上には、障害発生ＯＳ（１）１７側が書き込むレジスタ情報４０とメモリダンプ内容４１を格納する特定領域を確保する。ここで、レジスタ情報４０は、障害発生時点のＣＰＵ（１）１１内のレジスタ群の値を指す。また、メモリダンプ内容４１は、障害発生ＯＳ（１）１７が占有するメモリ領域（データ領域等）、ＯＳ管理下のメモリ領域（共有バッファ領域等）、または各アプリケーション１９が占有するメモリ領域（データ領域等）の内容を含む。
一方、障害対応ＯＳ（２）１８は、障害通知部３２から障害発生通知を受ける障害受信手段としての障害受信部５０、共有メモリ１３上に書き込まれた（退避された）レジスタ情報４０とメモリダンプ内容４１を二次記憶装置１４に保存するダンプ保存手段としてのダンプ保存部５１、当該二次記憶装置１４への各種制御処理を行なう二次記憶装置用ドライバ２３を備える。
【００１０】
次に動作について説明する。
まず、ＯＳ（１）１７側で、ＣＰＵまたはＯＳがシステム異常を検出した時、障害検出部３０が呼び出され、障害検出部３０が障害発生時点のＣＰＵ（１）１１内のレジスタの内容を、共有メモリ１３上の特定領域にレジスタ情報４０として書き込む。
次に、ダンプ退避部３１は、ＣＰＵ（１）１１内のキャッシュの内容をフラッシュ（主メモリへの書き出し）した後、対象とするメモリダンプ内容に対応する物理メモリ領域の内容を読み出し、共有メモリ１３上の特定領域に書き込む。
【００１１】
その後、障害通知部３２は、ＯＳ（２）１８に対して、プロセッサ間割込み等を用いて、障害発生（メモリダンプ保存要求）を通知する。この時、障害通知部３２は、ダンプ退避部３１がメモリダンプ対象の内容全体を共有メモリ１３上に書き込み終わるのを待って通知するのではなく、例えば、障害発生ＯＳ（１）１７が、障害発生ＯＳ（１）１７が占有するメモリ領域の内容を共有メモリ１３上に書き込んだところで障害通知部３２が障害の発生を通知し、次にＯＳ管理下のメモリ領域の内容を共有メモリ１３上に書き込んだところで障害通知部３２が障害の発生を通知する、という具合に、共有メモリ１３上への書き込みと障害発生通知の処理を、適切な単位に区切って繰り返す。その後、前記再起動実行部３３が共有メモリ１３上に書き込まれた障害発生ＯＳ（１）１７が占有するメモリ領域とＯＳ管理下のメモリとの内容の再起動を実行する。
【００１２】
また、特定アプリケーション１９で障害が発生し、そのアプリケーション１９とその他の関連アプリケーションが占有するメモリ領域の内容を二次記憶装置１４に保存する場合、障害発生ＯＳ（１）１７での共有メモリ１３上への書き込みと障害発生通知の処理を、アプリケーション単位で分割して繰り返す。その後、再起動実行部３３が共有メモリ１３上に書き込まれたアプリケーション単位に分割されたメモリ領域毎の内容の再起動を順番に実行する。
【００１３】
ダンプ退避部３１と障害通知部３２の処理が終了すると、直ちに、再起動実行部３３は、ＯＳ（１）１７の再起動を実行するか、または障害が発生した特定アプリケーション１９のみの再起動を実行する。これにより、ＯＳ（２）１８側での二次記憶装置１４への保存処理とは独立・並行して、ＯＳ（１）１７または特定アプリケーション１９のみが再起動されて、システムが定常状態に戻る。
【００１４】
一方、障害対応ＯＳ（２）１８の障害受信部５０は、障害通知部３２からの障害発生通知を受けるたびに、ダンプ保存部５１を呼び出す。ダンプ保存部５１は、ＯＳ（１）１７側が共有メモリ１３上の特定領域に書き込まれたレジスタ情報４０とメモリダンプ内容４１を読み出し、二次記憶装置用ドライバ２３を介して二次記憶装置１４に保存する。なお、障害受信部５０の処理は、ＯＳ（２）１８の割込みハンドラとして、またダンプ保存部５１の処理はシステムタスクとして実現する。
【００１５】
以上のように本実施の形態によれば、障害発生ＯＳ（１）１７が、メモリダンプ内容を直接二次記憶装置１４に保存するのではなく、二次記憶装置１４へのアクセス速度と比べて桁違いに高速な共有メモリ１３上への書き込み処理を行い、メモリダンプ内容を二次記憶装置１４に保存する処理は、障害発生ＯＳ（１）１７とは独立かつ並列に動作するＯＳ（２）１８が行なうことにより、障害発生時のメモリダンプ取得処理によるシステム再開時間を短縮することができる。
【００１６】
また、複数のＯＳ間で処理を分割し、障害発生ＯＳ（１）１７側での共有メモリ１３上へのメモリダンプ内容の書き込みと障害発生通知の処理を適切な単位に区切って繰り返し、障害対応ＯＳ（２）１８側で共有メモリ１３上に書き込まれた適切な単位に区切られたメモリダンプ内容を二次記憶装置１４に繰り返し保存するようにしているので、ＯＳ間の並列実行が可能であるため、メモリダンプ内容を二次記憶装置14に保存するメモリダンプ保存処理時間を大幅に短縮することができる。
【００１７】
さらに、特定アプリケーション１９で障害が発生し、そのアプリケーション１９とその他の関連アプリケーションが占有するメモリ領域の内容を二次記憶装置１４に保存する場合、障害発生ＯＳ（１）１７での共有メモリ１３上への書き込みと障害発生通知の処理を、アプリケーション単位で分割して繰り返すようにしているので、アプリケーション毎の再起動を順番に実行できるため、システムが再び定常状態に戻るまでのシステム再開時間を短縮することができる。
【００１８】
また、障害対応ＯＳ（２）１８側での二次記憶装置１４への保存処理は、背景技術で説明したような割込み処理の延長ではなく、システムタスクとして実現するため、メモリダンプ保存処理が優先されて、ＯＳ（２）１８側の全ての通常処理が数秒から数分に渡って一時停止するような状況を回避することができる。
【００１９】
さらに、ＯＳ（１）または障害が発生したアプリケーション１９が再起動する時、背景技術で説明したように、再起動前と異なる物理メモリ領域を新たに確保して配置するようなことは行わないため、全てのプログラムが物理メモリ空間上の固定アドレスに配置されることを前提とした組込みシステム用のＯＳ実行環境にも適用できる。
【００２０】
本方式は、複数ＣＰＵ上で独立、かつ並列に動作するＯＳ構成において、システムの一部で障害が発生した時に、その全体を一時停止することなく、また障害が発生していないＯＳ側の通常処理に影響を与えることなく、（一部ＯＳの再起動による）一時的な縮退動作を経て、システムを継続させることができる。
【００２１】
実施の形態２．
実施の形態１では、障害対応ＯＳ（２）１８側はメモリダンプ保存先の二次記憶装置１４を固定にメモリダンプ内容を保存するようにしているが、次に、二次記憶装置である各保存先デバイスの接続有無やデバイスの空き容量等のシステム状況に応じて、メモリダンプの保存先デバイスを選択可能にする実施の形態を示す。
図３は、実施の形態２の計算機システム障害対応方式の構成図である。
図３において、障害対応ＯＳ（２）１８は、ダンプデバイステーブル５２と、デバイス選択手段としてのデバイス選択部５３を新たに備える。本図では、メモリダンプ保存先の選択候補となる二次記憶装置１４の例として、ＨＤＤ（ハードディスクドライブ）１４ａ、ＤＶＤ−ＲＡＭ１４ｂ、ＵＳＢメモリ１４ｃの各デバイスを示し、ＯＳ（２）１８はこれら各デバイスである二次記憶装置にレジスタ情報４０とメモリダンプ内容４１を保存するための二次記憶装置用ドライバとして、ＨＤＤ用ドライバ２３ａ、ＤＶＤ−ＲＡＭ用ドライバ２３ｂ、ＵＳＢメモリ用ドライバ２３ｃを保持するものとする。
【００２２】
図４は、実施の形態２におけるダンプデバイステーブル５２の構成図である。
図４において、ダンプデバイステーブル５２は、保存先デバイスのデバイスＩＤ５２ａ、デバイス名５２ｂ、空き容量５２ｃ、当該デバイスの接続有無やドライバのサポート状況により設定されるデバイス使用可否フラグ５２ｄ、システムの方針に基づき決定される保存先優先順位５２ｅを一つのエントリとする複数エントリから構成される。なお、ある二次記憶装置１４内を複数のパーティションに分割して使用している場合、パーティション毎に一つのエントリを登録してもよい。また、ダンプデバイステーブル５２の内容は、システムのコンフィグレーション情報の一つとして、固定的に設定されるだけでなく、システム稼動中に特定のユーザ等が変更することも可能とする。
図５は、実施の形態２におけるデバイス選択部５３の処理手順を示したフローチャートである。
【００２３】
次に動作について説明する。
障害対応ＯＳ（２）１８内の障害受信部５０は、障害通知部３２からの障害発生通知を受けて、ダンプ保存部５１を呼び出す。ダンプ保存部５１は、デバイス選択部５３に対してメモリダンプ内容の保存先デバイスを選択することを指示し、デバイス選択部５３で選択された保存先デバイスの情報を得る。その後、共有メモリ１３上の特定領域に書き込まれているレジスタ情報４０とメモリダンプ内容４１を順次読み出しながら、二次記憶装置用ドライバ２３ａ、２３ｂ、２３ｃのいずれかを介して、デバイス選択部５３で選択された保存先デバイスへメモリダンプの保存を行なう。
【００２４】
デバイス選択部５３は、まずステップＳ６０において、ダンプデバイステーブル５２内の保存先優先順位５２ｅを参照し、最も優先順位の高いエントリを選択する。図４の例では、保存先デバイスＩＤ５２ａが３のＵＳＢメモリ１４ｃが最も優先順位が高いことを示している。
次に、ステップＳ６１において、デバイス使用可否フラグ５２ｄを参照し、当該デバイスが現在使用可能かを判定し、使用不可の場合には、再度ステップＳ６０に戻り、次に優先順位の高いエントリを選択する。図４の例では、ＵＳＢメモリ１４ｃはデバイスが接続されていない等の理由により現在使用不可であるため、ステップＳ６１までで次に優先順位の高いＨＤＤ（ハードディスクドライブ）が選択される。
【００２５】
次に、ステップＳ６２において、デバイス空き容量５２ｃを参照し、メモリダンプ内容に対して十分な空き容量があるかを判定し、十分な空き容量がない場合には、再度ステップＳ６０に戻り、次のデバイスのエントリを選択する。最後に、ステップＳ６３において、保存先デバイスのデバイスＩＤ５２ａとデバイス名５２ｂをダンプ保存部５１へ返す。
【００２６】
以上のように本実施の形態によれば、障害対応ＯＳ（２）１８側にダンプデバイステーブル５２とデバイス選択部５３とを備え、保存先デバイスの接続有無やデバイスの空き容量等のシステム状況に応じて、メモリダンプの保存先デバイスを選択可能にしているため、障害発生ＯＳ（１）１７側からアクセスできない二次記憶装置やドライバが未サポートの二次記憶装置にメモリダンプを保存することができる。また、システムの状況を反映して最適の保存先デバイスを選択可能とするため、確実にダンプを取得することができる。
【００２７】
実施の形態３．
実施の形態２では、障害対応ＯＳ（２）１８があらかじめ決められていて、これがメモリダンプの保存処理を行なうようにしているが、次に、三個以上のＣＰＵ上でそれぞれ独立かつ並列にＯＳ及びアプリケーションが動作する構成において、保存先デバイスの接続有無やデバイスの空き容量等のシステム状況に応じて、障害発生ＯＳ（１）１７側でメモリダンプの保存処理ＯＳを切り替え可能にする実施の形態を示す。
【００２８】
図６は、実施の形態３の計算機システム障害対応方式の構成図である。
図６において、計算機システム１０は第三のＣＰＵ（ｎ）２４を保持し、ＣＰＵ（ｎ）２４上でＯＳ（ｎ）２５とアプリケーションが動作している。また、障害発生ＯＳ（１）１７は保存ＯＳ選択手段としての保存ＯＳ選択部３４を新たに備え、共有メモリ１３上にはＯＳ選択テーブル４２を新たに定義する。
図６では、メモリダンプ保存先の選択候補となる二次記憶装置１４の例として、ＨＤＤ（ハードディスクドライブ）１４ａ、ＤＶＤ−ＲＡＭ−１４ｂ、ＵＳＢメモリ１４ｃを示し、ＯＳ（２）１８はＨＤＤ（ハードディスクドライブ）１４ａ用のＨＤＤ用ドライバ２３ａ、ＤＶＤ−ＲＡＭ−１４ｂ用のＤＶＤ−ＲＡＭ用ドライバ２３ｂを保持し、ＯＳ（ｎ）２５はＵＳＢメモリ１４ｃ用のＵＳＢメモリ１４Ｃ用ドライバ２３ｃを保持するものとする。
【００２９】
図７は、実施の形態３におけるＯＳ選択テーブル４２の構成図である。
図７において、ＯＳ選択テーブル４２は、ＣＰＵ番号４２ａ、保存先デバイスのデバイスＩＤ４２ｂ、保存先デバイス名４２ｃ、デバイス空き容量４２ｄ、当該デバイスの接続有無やドライバのサポート状況により設定されるデバイス使用可否フラグ４２ｅ、システムの方針に基づき決定される保存先優先順位４２ｆを一つのエントリとする複数エントリから構成される。
図８は、実施の形態３における保存ＯＳ選択部３４の処理手順を示したフローチャートである。
【００３０】
次に動作について説明する。
障害発生ＯＳ（１）１７内のダンプ退避部３１は、ＣＰＵキャッシュの内容をフラッシュ（主メモリへの書き出し）した後、ＯＳ（１）１７の管理下の物理メモリ領域、または障害検出時に動作していたアプリケーション１９に割り当てられていた物理メモリ領域の各内容を読み出し、共有メモリ１３上の特定領域にメモリダンプ内容４１として書き込みした後、保存ＯＳ選択部３４を呼び出す。
保存ＯＳ選択部３４は、まずステップＳ７０において、ＯＳ選択テーブル４２内の保存先優先順位４２ｆを参照し、最も優先順位の高いエントリを選択する。図７の例では、ＣＰＵ番号４２ａがｎのＵＳＢメモリ１４Ｃが最も優先順位が高いことを示している。
【００３１】
次に、ステップＳ７１において、デバイス使用可否フラグ４２ｅを参照し、当該デバイスが現在使用可能かを判定し、使用不可の場合には、再度ステップＳ７０に戻り、次に優先順位の高いエントリを選択する。図７の例では、ＵＳＢメモリ１４Ｃは使用可能であるため、これが選択される。
その後、ステップＳ７２において、デバイス空き容量４２ｄを参照し、メモリダンプ内容に対して十分な空き容量があるかを判定し、十分な空き容量がない場合には、再度ステップＳ７０に戻り、次のデバイスのエントリを選択する。
最後に、ステップＳ７３において、決定されたエントリのＣＰＵ番号４２ａを取得する。本例では、保存先デバイスとしてＵＳＢメモリ１４Ｃが決定され、対応するＣＰＵ番号４２ａとしてｎが得られる。
【００３２】
次に、障害通知部３２は、保存ＯＳ選択部３４で選択されたＣＰＵ番号４２ａ上で動作するＯＳに対して、プロセッサ間割込み等を用いて、障害発生（メモリダンプ保存要求）を通知する。本例では、ＣＰＵ（ｎ）２４上のＯＳ（ｎ）２５に対して通知される。
一方、ＯＳ（ｎ）２５内の障害受信部６０は、障害通知部３２からの障害発生通知を受けて、ダンプ保存部６１を呼び出す。ダンプ保存部６１は、共有メモリ１３上の特定領域に書き込まれているレジスタ情報４０とメモリダンプ内容４１を順次読み出しながら、ＵＳＢメモリ用ドライバ２３Ｃを介してＵＳＢメモリ１４Ｃへメモリダンプの保存を行なう。
【００３３】
以上のように本実施の形態によれば、障害発生ＯＳ（１）１７側に保存ＯＳ選択部３４と、共有メモリ１３上にＯＳ選択テーブル４２とを備え、保存先デバイスの接続有無やデバイスの空き容量等のシステム状況に応じて、メモリダンプの保存処理ＯＳを切り替え可能にしているため、保存処理ＯＳ毎のドライバのサポート状況やシステム負荷状況等を勘案して、柔軟かつ確実にダンプを取得することができる。
【００３４】
実施の形態４．
以上の実施の形態３では、三個以上のＣＰＵ上でそれぞれ独立かつ並列にＯＳ及びアプリケーションが動作する構成において、保存先デバイスの接続有無やデバイスの空き容量等のシステム状況に応じて、障害発生ＯＳ（１）１７側でメモリダンプの保存処理ＯＳを切り替えるようにしているが、次に、障害発生ＯＳ（１）１７で障害が発生した時に、そのメモリダンプを取得するだけでなく、同時にその他のＯＳまたはその上のアプリケーションのメモリダンプを取得する実施の形態を示す。
【００３５】
図９は、実施の形態４の計算機システム障害対応方式の構成図である。
図９において、障害発生ＯＳ（１）１７以外のＯＳ（２）１８はダンプ退避部５４を新たに備え、共有メモリ１３上にはＯＳ（２）１８側で書き込まれる（退避される）レジスタ情報４３とメモリダンプ内容４４を格納する特定領域を新たに確保する。なお、本図ではＯＳ（１）１７とＯＳ（２）１８の二つのＯＳ構成の場合について示しているが、ＯＳ（２）１８と同様に障害受信部５０とダンプ退避部５４を含む第三のＯＳ（ｎ）２５が存在する構成であってもよい。
【００３６】
次に動作について説明する。
まず、ＯＳ（１）１７側で障害が発生した時、障害検出部３０が呼び出され、障害検出部３０は、障害発生時点のレジスタの内容を、共有メモリ１３上の特定領域にレジスタ情報４０として書き込む。次に、障害通知部３２は、ＯＳ（２）１８に対して、プロセッサ間割込み等を用いて、障害発生（メモリダンプ保存要求）を通知する。
【００３７】
その後、ダンプ退避部３１は、ＣＰＵキャッシュの内容をフラッシュ（主メモリへの書き出し）した後、ＯＳ（１）１７管理下の物理メモリ領域、または障害検出時に動作していたアプリケーション１９に割り当てられていた物理メモリ領域の各内容を読み出し、共有メモリ１３上の特定領域にメモリダンプ内容４１として書き込む。
ダンプ退避部３１の処理が終了すると直ちに、再起動実行部３３は、ＯＳ（１）１７の再起動または障害が発生したアプリケーション１９のみの再起動を実行し、ＯＳ（１）１７またはアプリケーション１９が再起動されて、システムが定常状態になる。
【００３８】
一方、ＯＳ（２）１８の障害受信部５０は、障害通知部３２からの障害発生通知を受けて、共有メモリ１３上の特定領域に、障害通知を受けた時点のレジスタ情報４３を保存した後、ダンプ退避部５４を呼び出す。ダンプ退避部５４は、ＯＳ（１）１７側のダンプ退避部３１の処理と同様に、ＯＳ（２）１８管理下の物理メモリ領域の内容、または障害が発生したＯＳ（１）１７により起動するアプリケーション１９と連携動作していたアプリケーション２０に割り当てられていた物理メモリ領域の内容を読み出し、共有メモリ１３上の特定領域にメモリダンプ内容４４として書き込む。
【００３９】
その後、障害受信部５０は、再度ＯＳ（１）１７の障害通知部３２からダンプ退避完了の通知を受けて、ダンプ保存部５１を呼び出す。ダンプ保存部５１は、ＯＳ（１）１７のダンプ退避部３１によって書き込まれたレジスタ情報４０とメモリダンプ内容４１、及びＯＳ（２）１８のダンプ退避部５４によって書き込まれたレジスタ情報４３とメモリダンプ内容４４を順次読み出しながら、二次記憶装置用ドライバ２３を介して二次記憶装置１４にメモリダンプの保存を行なう。
【００４０】
以上のように本実施の形態によれば、障害発生ＯＳ（１）１７以外のＯＳにダンプ退避部５４と、共有メモリ１３上の特定領域にＯＳ毎のメモリダンプ退避領域とを備え、障害発生ＯＳ（１）１７からの一斉通知により、その時点での他ＯＳ上のメモリダンプを同時に取得するようにしているため、障害が発生したＯＳ及びその上のアプリケーションの状態情報だけでなく、並列動作する他のＯＳ及び連携動作する他ＯＳ上のアプリケーションの状態情報を付き合わせて、障害原因の解析を進めることができる。
【図面の簡単な説明】
【００４１】
【図１】実施の形態１の計算機システム障害対応方式の構成図。
【図２】実施の形態１における計算機システム障害対応方式の詳細構成図。
【図３】実施の形態２の計算機システム障害対応方式の構成図
【図４】実施の形態２におけるダンプデバイステーブル５２の構成図。
【図５】実施の形態２におけるデバイス選択部５３の処理手順を示したフローチャート。
【図６】実施の形態３の計算機システム障害対応方式の構成図。
【図７】実施の形態３におけるＯＳ選択テーブル４２の構成図。
【図８】実施の形態３における保存ＯＳ選択部３４の処理手順を示したフローチャート。
【図９】実施の形態４の計算機システム障害対応方式の構成図。
【図１０】従来の計算機システムの構成図。
【図１１】従来の計算機システムの第１ＯＳの割込み処理手順を示すフローチャート。
【符号の説明】
【００４２】
１０  計算機システム、１１  ＣＰＵ（１）、１２  ＣＰＵ（２）、１３  共有メモリ、１４  二次記憶装置、１４ａ  ＨＤＤ、１４ｂ  ＤＶＤ−ＲＡＭ、１４ｃ  ＵＳＢメモリ、１５  割込みコントローラ、１６  バス、１７  ＯＳ（１）、１８  ＯＳ（２）、１９  アプリケーション、２０  アプリケーション、２１  メモリダンプ処理部、２２  メモリダンプ処理部、２３  二次記憶装置用ドライバ、２３ａ  ＨＤＤ用ドライバ、２３ｂ  ＤＶＤ−ＲＡＭ用ドライバ、２３ｃ  ＵＳＢメモリ用ドライバ、２４  ＣＰＵ（ｎ）、２５  ＯＳ（ｎ）、３０  障害検出部、３１  ダンプ退避部、３２  障害通知部、３３  再起動実行部、３４  保存ＯＳ選択部、４０  レジスタ情報、４１  メモリダンプ内容、４２  ＯＳ選択テーブル、４２ａ  ＣＰＵ番号、４２ｂ  保存先デバイスＩＤ、４２ｃ  保存先デバイス名、４２ｄ  デバイス空き容量、４２ｅ  デバイス使用可否フラグ、４２ｆ  保存先優先順位、４３  レジスタ情報、４４  メモリダンプ内容、５１  障害受信部、  ５２  ダンプデバイステーブル、５２ａ  保存先デバイスＩＤ、５２ｂ  デバイス名、５２ｃ  空き容量、５２ｄ  デバイス使用可否フラグ、５２ｅ  保存先優先順位、５３  デバイス選択部、５４  ダンプ退避部。
【図１】
2007334403.tif 000003
【図２】
2007334403.tif 000004
【図３】
2007334403.tif 000005
【図４】
2007334403.tif 000006
【図５】
2007334403.tif 000007
【図６】
2007334403.tif 000008
【図７】
2007334403.tif 000009
【図８】
2007334403.tif 000010
【図９】
2007334403.tif 000011
【図１０】
2007334403.tif 000012
【図１１】
2007334403.tif 000013