JP2006092055A - 計算機システム - Google Patents

Abstract

【課題】
動作中ＯＳの障害を検知し、障害原因の解決策となるＯＳ制御パラメータを算出して再起動ＯＳが、再び同じ原因によって障害に陥る危険性を回避する。
【解決手段】
システム運用中ＯＳが、実行継続不可能になった場合に同じＯＳもしくは同種のＯＳを再起動する手段を持つシステムにおいて、自分自身の負荷状態や障害解析を行う手段、かつ障害監視手段により、運用継続不可の障害を検出する手段、その状況を解決、もしくは回避するカーネル制御パラメータ項目と値を特定する手段とを持ち、特定したパラメータが静的制御パラメータを含む場合は、特定したパラメータを指定して同じＯＳ、もしくは同種のＯＳを再起動する。特定したパラメータが動的可能なパラメータである場合には、ＯＳの再起動は行わずに稼動中ＯＳに適用する。また、管理者の指示によるＯＳの再起動の場合に、それまでに特定した最適化パラメータを適用して再起動する。
【選択図】 図１

Description

本発明は計算機システムに関し、特に稼動中のオペレーティングシステムの障害を回復・回避する方法に関するものである。

一般の計算機システムでは、オペレーティングシステム（以下「ＯＳ」とも言う）と呼ばれるプログラムの実行により、計算機システムが有するハードウェア（以下「計算機資源」とも言う）、具体的には、処理装置（「プロセッサ」とも言う）、主記憶装置、二次記憶装置、入出力装置、ファイル装置、通信装置などの管理およびこれら計算機資源の使用スケジュールの制御が行われる。又ＯＳは、ユーザが計算機の資源を容易に利用するためのソフトウエアインタフェースを提供する。一般的なアプリケーションプログラム（例えば表計算ソフトやワープロソフト等）は、ＯＳの制御を介して計算機の有するハードウェアを使用する。

このＯＳは、ハードウェアの故障やＯＳ自身を含めたプログラムの不具合によって発生する障害により、その実行が停止（以下「ハングアップ」とも言う）したり、誤動作する場合がある。

しかしＯＳは上述したように、計算機システムが有する計算機資源の管理を一手に引き受けているため、特に信頼性や可用性が高く求められる計算機システム（例えば基幹系で使用される計算機システム）では、ＯＳのハングアップや誤動作の原因となる障害をすばやく解決、もしくは回避することが求められている。

この要求に対応するため、計算機システムにおける障害によりＯＳの実行継続が困難になった場合、計算機システムはメモリダンプを取得する。ここでメモリダンプとは、計算機システムにおいて障害が発生した時点の、計算機システムが有する主記憶装置（以下「メモリ」とも言う）に格納された情報を障害情報として二次記憶装置に退避したものを指す。システム管理者などは、そのメモリダンプの内容を解析することにより、障害原因の特定と修正を行い、計算機システムを再起動する。

メモリダンプを利用した障害解析方法の従来技術として、特許文献１に開示された技術がある。この技術は、計算機システムを再起動する際に、前回のシステム運用においてシステムクラッシュ（ドライバやＯＳ自身のバグによってこれ以上のシステム運用継続が困難と判断した時に、ＯＳが二次記憶装置にメモリダンプ出力を行った後に機能停止する状況）が発生していたかどうかをメモリダンプの存在有無から検知する。メモリダンプが存在しシステムクラッシュが発生していた場合にはＯＳを自己診断モード（デバック機能を有効にしたモード）で再起動し、ドライバなどソフトウェアコンポーネントのメモリ使用状況などをトレースしながら運用する。トレースしている情報はメモリ使用状況テーブルに記録され、システムアドミニストレータや他のデバッガが障害原因となったドライバの絞込み、特定を行うために利用する。

一方、上述したメモリダンプとは異なるが、計算機システムの障害に伴う再起動方式について特許文献２に開示されている。特許文献２では、計算機システムを再起動する際に、再起動の対象となる計算機システムが平均故障間隔時間程度の運用が可能かどうかに基づいて計算機を再起動するか否かを判断する。

更に、業務処理用のアプリケーションが同一原因の障害によって再起動を繰り返すことを回避する技術が特許文献３に開示されている。本文献では、障害情報、たとえば障害時間間隔、データ種別、障害種別、障害頻度からアプリケーションが再起動ループに陥るかどうかを判断して、再起動の是非を判定する。

米国特許６７２８９０７号公報 特開平６−２６６５７３号公報 特開平５−２３３３４１号公報

上述した従来技術では、メモリダンプを利用して障害解析を行ったり、障害の再発が予測される場合に計算機システム等を再起動させないという処理を行うことで、障害の特定又は回避を行っている。

しかしながら、特許文献１に開示された技術では、メモリダンプの内容あるいは再起動後のトレースにより障害の原因が特定されるが、その内容解析に基づく障害の特定には時間がかかり、計算機システムの早期復旧という要求には十分に応えられていない。

一方、特許文献２及び３に開示されている技術では、そもそも障害が再発しそうな計算機システムは再起動しないという発想であり、障害の根本的な解決にならず、継続運用が要求される計算機システムにおける早期の障害解決という要求には応えられない。

すなわち、上述した従来技術では、計算機システムの障害原因に対する障害対策を実施しないまま同じまたは同種のＯＳを再起動すると、再起動したＯＳは再び同じ原因によって障害に陥る危険性が高く、運用継続を保障できないという問題が十分に解決できていない。

上記課題を解決するために、本発明は以下の構成とする。すなわち、計算機において、自身で実行されるオペレーティングシステム（以下「ＯＳ」）の状態を監視し、その監視結果に基づいて、ＯＳの設定パラメータを再計算し、再計算された設定パラメータを二次記憶装置に格納し、ＯＳを再起動する際には、二次記憶装置に格納された設定パラメータに基づいてＯＳを再起動する構成である。

より具体的には、本発明は、システム運用中ＯＳが、実行継続不可能になった場合に同じＯＳもしくは同種のＯＳを再起動する手段を持つシステムにおいて、自分自身の負荷状態や障害解析を行う手段を持ち、かつ障害監視手段により、運用継続不可の障害を検出する手段と、その状況を解決、もしくは回避するカーネル制御パラメータ項目と値を特定する手段とを持ち、特定したパラメータが静的制御パラメータを含む場合は、特定したパラメータを指定して同じＯＳ、もしくは同種のＯＳを再起動するという構成である。また特定したパラメータが動的可能なパラメータである場合には、ＯＳの再起動は行わずに稼動中ＯＳに適用する。本発明の他の構成等については、明細書の記載から明らかにされる。

本発明により、障害等が発生した計算機システムにおいて、同じ障害状況を再発することがないようにして計算機システムを早急に再起動できる。さらに、計算機システムを継続的に運用できるので、計算機システムの信頼性を向上させることができる。

以下に、本発明の実施の形態を説明する。

図1は、第１の実施形態における計算機システムのハードウェア構成例を示す図である。
計算機システムは、計算機１０００、キーボード１３００、マウス１４００、ディスプレイ１１００及び二次記憶装置１２００を有する。キーボード１３００、マウス１４００、ディスプレイ１１００、及び二次記憶装置１２００は各々計算機１０００に接続されている。

計算機１０００は、プロセッサ（以下「ＣＰＵ」）１０１０、主記憶装置（メモリ）１０２０、ビデオアダプタ１０３０、ネットワークインタフェース１０４０、二次記憶装置インタフェース１０５０、シリアルポートインタフェース１０６０、およびこれらの間を接続するシステムバス１０７０を有する。尚、各構成要素の数は任意であり、単数でも複数でも構わない。計算機システム１０００は、シリアルポートインタフェース１０６０を介してキーボード１３００及びマウス１４００と、ビデオアダプタ１０３０を介してディスプレイ１１００と、二次記憶装置インタフェース１０５０を介して二次記憶装置１２００と接続されている。

又、計算機１０００は、ネットワークインタフェース１０４０を介してネットワーク１５００に接続され、遠隔地に存在する計算機１６００と通信を行う。

図２は、計算機１０００に接続される二次記憶装置１２００に格納されているプログラムや情報の例を示す図である。尚、これらのプログラム等は、二次記憶装置の障害に対応するために複数台の二次記憶装置１２００に格納されてもよい。又、以下に説明するプログラムは、ＣＰＵ１０１０で実行されるプログラム群であるが、説明を簡便にするために、プログラムを主語として説明する場合がある。

二次記憶装置１２００には、ＯＳ２０００と、ＯＳをメモリ１０２０上にロードするためにＣＰＵ１０１０が実行するブートローダ２５００が格納されている。
ＯＳ２０００は、計算機１０００を制御するＯＳの基本機能を実行するためのプログラムであるＯＳカーネル２０１０、必要に応じてメモリ１０２０にロードされ、ＯＳに組み込まれるカーネルモジュール２０２０、カーネル内のイベント情報取得および稼動状況を取得するために実行されるプログラムであるカーネルモニタ２０３０、計算機１０００が安定稼動しているかどうか判定するプログラムである計算機安定性評価器２０４０、障害情報や負荷情報に基づいて変更（以下「チューニング」とも言う）すべきカーネル制御パラメータを算出するために実行されるプログラムであるカーネル制御パラメータ算出制御器２０５０、ＯＳ起動時に静的にカーネルに設定される設定情報（以下「パラメータ」とも言う）が記録される静的カーネル制御パラメータテーブル２０６０、ＯＳ稼動中であっても動的に変更可能なパラメータが記録される動的カーネル制御パラメータテーブル２０７０、動的カーネル制御パラメータテーブル２０７０に登録されたパラメータをカーネルに反映させる際に実行されるプログラムであるカーネルパラメータモディファイア２０８０、静的／動的カーネル制御パラメータテーブル２０６０、２０７０を二次記憶装置１２００に格納するプログラムであるカーネルパラメータレコーダ２０９０、ＯＳ再起動時に静的／動的カーネル制御パラメータテーブル２０６０、２０７０をメモリ１０２０にロードするプログラムであるカーネルパラメータローダ２１００、ＯＳがパニックした時に呼び出されて実行されるプログラムであるパニックノーティファイア２１１０、ＯＳを再起動する際に呼び出されて実行されるプログラムであるＯＳ切替ドライバ２１２０を有している。

尚、「安定稼動」とは、計算機システムの稼動を継続できる状態、逆説的に言えば、これ以上のシステム稼動が困難であり、再起動が余儀なくされる状態ではない状態を指す。一方、安定稼動で無い場合についてのより具体的な定義は、図９で説明する。
「カーネル制御パラメータ」とは、具体的にはカーネルの動作や制御を変更するためのパラメータであり、本実施形態では、図１３や図１４に示すパラメータである。

「静的カーネル制御パラメータ」とは、ＯＳ稼働中、カーネルに対するパラメータ変更が不可能であり、ＯＳ起動時の一度だけ指定可能なパラメータを指す。
又「動的カーネル制御パラメータ」とは、ＯＳ稼働中いつでも何回でもカーネルに対するパラメータ変更が可能なパラメータを指す。
更に「パニック」とは、ＯＳが、ドライバやＯＳ自身のバグによってこれ以上のシステム運用継続が困難と判断することを指す。尚、パニック時にＯＳによって行なわれる処理は、コンソールへのＣＰＵレジスタ情報表示、フック関数の実行、ＣＰＵ停止処理などがある。

図３は、計算機１０００が起動された後のメモリ１０２０に格納される各種プログラムの例を示す図である。ここで、メモリ１０２０は、ＯＳが使用する記憶領域（以下「ＯＳカーネル領域」とも言う）３０００と、その他、アプリケーション等に使用される記憶領域（以下「アプリケーション領域」とも言う）３０１０に区分される。

以下、本実施形態における計算機の動作概要を示す。
メモリ１０２０に各種プログラムがロードされた後、計算機１０００は、運用中ＯＳのカーネル内のイベント情報および稼働状況を随時取得する。

そして任意のタイミングで、計算機１０００は、これ以上のシステム稼動が困難でありＯＳの再起動が必要かどうか判定する。再起動が不要な場合、計算機１０００は、その時点の自身の負荷状況および障害状況を算出する。その後計算機は、算出された負荷状況および障害状況に応じて新たな静的／動的カーネル制御パラメータを算出し、動的カーネル制御パラメータについては即座にＯＳカーネルに反映させる。又、計算機１０００は、算出した新たな静的／動的カーネル制御パラメータを二次記憶装置に保存する。

一方、これ以上のシステム稼動が困難でありＯＳの再起動が必要と判定された場合、計算機１０００はＯＳを再起動する。再起動されるＯＳは、再起動時に、二次記憶装置に格納された静的／動的カーネル制御パラメータを読み出してカーネルに反映させる。

図４は、計算機１０００を起動する際に、図３に示す構成をメモリ１０２０に作成するための手順例を示す図である。
計算機１０００の起動が開始されると（４０００）、ブートローダ２５００の実行により、ＯＳカーネル２０１０がメモリ１０２０上にロードされる。ロードされたＯＳカーネル２０１０は、カーネルの初期化処理および必要なカーネルモジュール２０２０のロードを行う（４００１）。その後、ＯＳカーネルによって最初に起動されるプロセス（以下「初期化プロセス」）は、カーネルモニタ２０３０をカーネルモジュールとしてＯＳカーネル領域３０００にロードする（４００２）。

次に初期化プロセスは、ＯＳがパニックした時にパニックノーティファイア２１１０がコールされるようにＯＳカーネル領域３０００のフックへパニックノーティファイア２１１０を登録する（４００３）。フックとは、ＯＳの処理命令列の変更を要求する他のモジュールに対するインタフェースである。フックへの登録は例えば次の方法がある。ＯＳがパニック関数を呼んだ事を契機として別の関数を実行させる処理（以下「コールバック」）を計算機１０００が実行できる場合、そのコールバックの関数としてパニックノーティファイア２１１０をＯＳカーネル領域３０００のフックに登録する。もしくは、ＯＳがパニックした時、ＯＳ内のいくつかの決まった関数がコールされることを利用して、それらの関数の命令列をパニックノーティファイア２１１０と置き換えてもよい。

続いて初期化プロセスは、ＯＳ切替ドライバ２１２０をカーネルモジュールとしてＯＳカーネル領域３０００にロードする（４００４）。
更に初期化プロセスは、計算機安定性評価器２０４０、カーネル制御パラメータ算出制御器２０５０、カーネルパラメータモディフィヤ２０８０、カーネルパラメータレコーダ２０９０、カーネルパラメータローダ２１００をアプリケーション領域３０１０にロードする（４００５）。

その後カーネルパラメータローダ２１００は、二次記憶装置１２００に格納されている静的／動的カーネル制御パラメータテーブル２０６０、２０７０をメモリ１０２０にロードする（４００６）。

図５は、本実施形態におけるＯＳ実行時の動作フローを説明する図である。
計算機１０００の稼動中、カーネルモニタ２０３０は、ＯＳにおけるサービス処理中にＯＳカーネル内のイベント情報をトレース（カーネル内で発生したイベント情報をイベントが発生した順に時系列に記録する動作）により取得し、ＯＳ稼動状況をサンプリング（ある時間におけるＯＳ稼働状況を取得する動作。すなわち、ある時間という一点の状態を観測・記録する動作）により取得する（５００１）。

一方、計算機安定性評価器２０４０は、カーネルモニタ２０３０から得られた情報を基に、マシン負荷状況および障害状況を算出（具体的には図９で詳細に説明する情報）し、計算機１０００が安定稼動しているかを判断する（５００２）。安定稼動していれば、計算機安定性評価器２０４０は、カーネル制御パラメータ算出制御器２０５０へ実行を移す（５００３）。計算機１０００の稼動が不安定になり、計算機１０００のシステム稼動の継続がこれ以降困難であると判断された場合、計算機安定性評価器２０４０はＯＳ切替ドライバ２１２０へ実行を移す。そしてＯＳ切替ドライバ２１２０はＯＳの再起動を行う（５００８）。

一方計算機１０００が安定稼動している場合（より正確には「計算機１０００が再起動に到るほど不安定でなかった場合」）、カーネル制御パラメータ算出制御器２０５０は、計算機安定性評価器２０４０から得られたマシン負荷状況および障害情報からチューニングすべきカーネル制御パラメータおよびその最適値を決定する（５００３）。尚、ここで「最適値」とは計算機の高負荷および障害状態を回避するように設定されるカーネル制御パラメータの値を指す。つまり、計算機１０００は、再起動に到るほど自身が不安定でない場合でも、後に再起動に到る原因となるような状態の有無をマシン負荷状況及び障害情報から検出し、その状態を回避するように、パラメータを変更する。

カーネル制御パラメータ算出制御器２０５０は、算出されたカーネル制御パラメータをアプリケーション領域３０１０に確保された静的／動的カーネル制御パラメータテーブル２０６０、２０７０へ記録する（５００４）。

その後、カーネルパラメータモディファイア２０８０は、動的カーネル制御パラメータ２０７０に関して、カーネルが備える動的可変パラメータ変更インタフェース２０１２を介してＯＳ稼動中のカーネルへ算出した値を反映する。具体的な反映の仕方は、後述する（５００５）。

一方、カーネルパラメータレコーダ２０９０は、二次記憶装置１２００に格納された静的／動的カーネル制御パラメータテーブル２０６０、２０７０の内容を更新する（５００６）。尚、格納先の二次記憶装置１２００が複数ある場合、そのうちのいずれか１つ又は複数に格納する。

計算機１０００は、以上説明した手順を、ＯＳの再起動が実行されない限り、任意の周期（例えば1[s]、10[s]ごとなど）で繰り返し実行する（５００７）。

上述したように、通常の障害は計算機安定性評価器２０４０で検出され、その結果に基づいてＯＳの再起動（又はパラメータの変更）が実行される。しかし、計算機安定性評価器２０４０は計算機１０００の全ての障害を検出できる訳ではない。計算機安定性評価器２０４０で検出できない障害が発生した場合、計算機１０００は、その障害に対応するための処理（パニック処理）を行う。

図６は、計算機１０００に、計算機安定性評価器２０４０で検出できない障害が発生した時に、計算機１０００が行うパニック処理の動作手順例を示すフロー図である。
計算機安定性評価器２０４０で検出できない障害が発生すると、ＯＳ（ＯＳカーネル２０１０およびカーネルモジュール２０２０）はパニック処理２０１１を呼び出す。そしてパニック処理２０１１が実行される際に、図４の初期化時にコールバックとして登録されたパニックノーティファイア２１１０が呼び出される（６００１）。

パニックノーティファイア２１１０は、本パニック処理が開始された時点のプロセッサが有するレジスタの情報から、障害の原因となったカーネルドライバモジュールを特定（具体的には、レジスタのスタック情報に障害が発生したドライバモジュールのアドレスが存在し、そのアドレスからドライバを特定）する（６００２）。
次にパニックノーティファイア２１１０は、二次記憶装置１２００に格納された静的カーネルパラメータテーブル２０６０のカーネルモジュールベクタ１３０１３（図１３参照）および動的カーネルパラメータテーブル２０７０のカーネルモジュールベクタ１４０１３（図１４参照）における特定されたカーネルモジュールの有効フラグを０とする。尚、パニック処理時には、ＯＳの再起動が行われるので、メモリ１０２０の情報は全て無効となる。したがって、パニックノーティファイア２１１０は、二次記憶装置１２００の静的／動的ーネルパラメータ２０６０、２０７０のフラグしか更新せず、メモリ１０２０に格納された静的／動的カーネルパラメータ２０６０、２０７０のフラグは更新しない（６００３）。

その後、パニックノーティファイア２００９は、ＯＳ切替ドライバ２０１０へ実行を移し、ＯＳを再起動する（６００４）。そして、計算機１０００は、再起動後のＯＳで処理を行う（６００５）。

次に、本実施形態の各プログラムの実行による計算機１０００の動作例について説明する。
上述したように、計算機１０００は、カーネルモニタ２０３０を実行して、ＯＳカーネルで実行されるイベントの記録を行う。そのために、計算機１０００は記録用のバッファをメモリ１０２０に確保する。図７は、カーネルモニタ２０３０によって取得されるカーネル内イベント記録情報を記録するバッファ７０００の例を示す図である。カーネルモニタ２０３０は、ＯＳカーネルで実行される処理について、時系列にバッファ７０００に登録する。

イベント情報バッファ７０００は、取得したイベントに関する情報を登録するためのレコードを複数有する。一つのレコードは一つのイベントに対応し、イベントの発生した時刻を示すエントリ７１００、取得したイベントの種類を示すエントリ７２００、取得したイベントに関する補助情報を示すエントリ７３００を有する。

エントリ７２００に登録されるイベント情報としては、例えば、コンテキストスイッチ、プロセスウェイクアップ、タイマ割り込み、外部デバイス割り込み待ち、外部デバイス割り込み、ロック取得、ロック解放、ページ解放ルーチンの開始と終了及びスワップスレッドの起動等がある。尚、イベント情報バッファ７０００には、必要に応じて、システムコールやメモリ取得などのイベント情報も記録される。

尚、ＣＰＵ１０１０が複数存在する場合、イベント記録情報バッファ７０００は、イベントが発生するＣＰＵ１０１０ごとに作成される。
又、イベント記録情報バッファ７０００は、カーネルモニタ２０３０が確保するバッファであり、本実施形態では、確保したバッファが一杯になったらバッファ先頭に戻り（サイクリックバッファ）、記録を続ける仕様とする。

又、計算機１０００は、上述したように、自身（特にＯＳ）の稼動状況（ＣＰＵやメモリといったハードウェアの使用状況等含む）を、カーネルモニタ２０３０を実行して記録する。このため、計算機１０００は、ＯＳ稼動状態記録情報を記録するバッファ８０００をメモリ１０２０に確保する。

図８は、ＯＳ稼動状態記録情報を記録するバッファ８０００の内容例を示す図である。カーネルモニタ２０３０は、ＯＳ稼動状態もカーネル内イベント記録情報７０００と同様に時系列でＯＳ稼動状態記録情報バッファ８０００へ記録する。尚、同じ稼動状態の情報、例えばＣＰＵ使用率等について複数回情報を取得したら、別々に記録し、バッファの空き容量が無くなったら、古い情報から順に消去され、空き領域として使用される。

ＯＳ稼動状態記録情報を記録するバッファ８０００は、複数のエントリを有する。一つのエントリはある時刻にサンプリングされた一つの稼動状態の情報に対応する。したがって、本図の場合、ある時刻にサンプリングされた稼動状態の情報は、エントリ８１００に登録され、その次の時刻にサンプリングされた稼動状態の情報は、エントリ８２００に登録される。

エントリ８１００等に記録されるカーネル稼動状態情報としては、例えば、取得時刻、各ＣＰＵのＣＰＵ利用率、物理メモリ使用量、スワップメモリ使用量、フリーページ数、ダーティページ数、inode使用数、dentry使用数、ファイルハンドル使用数、ネットワーク通信量が考えられる。

尚、ＯＳ稼動状態記録情報バッファ８０００もカーネル内イベント記録情報バッファ７０００と同様に、カーネルモニタ２０３０が確保するバッファであり、本実施形態では、確保したバッファが一杯になったらバッファ先頭に戻り記録を続ける仕様とする。

上述したように、本実施形態では、計算機安定性評価器２０４０を実行することで、計算機１０００は自身の稼動状況を確認し、障害等の検出も行う。そして、その稼動状況の確認結果に基づいて、計算機１０００は、カーネル制御パラメータ算出制御器２０５０を実行し、計算機１０００自身のカーネルの設定情報すなわちパラメータの変更の要否とその値を決定する。本実施形態における計算機安定性評価器２０４０による負荷状態や障害の検知、およびカーネル制御パラメータ算出制御器２０５０によるカーネル制御パラメータとその最適値の決定処理の例として、ハードウェア障害とプロセスの沈み込みを取り上げて後述する。

上述した計算機安定性評価器２０４０は、所定の条件に基づいて、計算機１０００の稼動状況が安定しているか否かを判断する。そのために、計算機１０００は、所定の条件に関する情報を登録するためのテーブルを有する。

図９は、上述した所定の情報を登録するための安定性評価テーブル９０００の構成例を示す図である。
安定性評価テーブル９０００は、所定の条件の数分の複数のレコードを有する。個々のレコードは、計算機安定性評価器２０４０がこれ以上のシステム稼動を困難と判断するＯＳ切替条件を示すエントリ９１００及び安定性評価の実施時にそのＯＳ切替条件エントリ９１００による評価を実施するかを示す有効フラグエントリ９２００を有する。

ＯＳ切替条件エントリ９１００の内容および有効フラグエントリ９０２００の設定の内容は、あらかじめ設定されているが、管理者が動的に設定内容を追加変更することもできる。具体的には、管理者は、計算機が有するに入力装置を用いて、メモリに登録されたＯＳ切替条件エントリの内容を適宜変更する。
ＯＳ切替条件を示すエントリ９１００に登録される条件としては、例えば「ＣＰＵ利用率過大状態の継続している時間が指定時間以上」かつ「起動ＣＰＵ数ベクタ１３０１５においてＯＳ再起動時の起動ＣＰＵ数が現在の起動ＣＰＵ数と同じでない」、「プロセスによる物理メモリ使用量が大きく」かつ「スワップメモリ量が大きく」かつ「起動メモリ量ベクタ１３０１６においてＯＳ再起動時の起動メモリ量が現在の起動メモリ量と同じでない」、計算機１０００の各デバイス障害（←ここでは「デバイス」とは障害監視可能な外部デバイスを指す）、各カーネルモジュール障害、プロセススケジューラの切替時刻の情報、「カーネル処理のスローダウンが指定時間以上」かつ「カーネル処理のスローダウンの発生頻度が指定回数を超えた場合」等がある。

図１２は、安定性評価の一例である、ハードウェア障害に関する計算機安定性評価器２０４０の処理フローを示す図である。
まず安定性評価器２０４０は、収集されたバッファ７０００と８０００の情報と安定性評価テーブル９０００の有効フラグエントリ９２００が有効であるＯＳ切替条件エントリ９１００に登録された内容とを比較して（１２００１）、一致するＯＳ切替条件エントリ９１００があるかどうか評価を実施する（１２００２）。
一致するＯＳ切替条件エントリ９１００があるならば、安定性評価器２０４０はＯＳ切替ドライバ２１２０へ制御を移す（１２００３）。

一方、一致するＯＳ切替条件エントリ９１００がなければ、安定性評価器２０４０は、ハードウェア入出力完了割り込み情報テーブル１００００をメモリ１０２０に作成する（１２００４）。このハードウェア入出力完了割り込み情報テーブル１００００は、計算機に接続される外部デバイスごとに、割り込み待ち制限値、割り込み待ち状態フラグ、割り込み待ち状態時刻、再試行回数制限値と回数を管理するために用いられる。したがって、このテーブルは、ハードウェア障害の有無に関わらず全ての外部デバイスについて作成される。

図１０は、ハードウェア入出力完了割り込み情報テーブル１００００の構成例を示す図である。
ハードウェア入出力完了割り込み情報テーブル１００００は、計算機１０００に接続されるハードウェア（以下「外部デバイス」とも言う）毎に対応するレコードを有する。各レコードは、計算機１０００に接続される各ハードウェアのデバイス名が登録されるエントリ１００１０、ＯＳが各ハードウェアによる入出力完了割り込みを待つ際の許容最大待ち時間の情報が登録されるエントリ１００２０、ＯＳが各外部デバイスに関して割り込み待ち状態であるかを示す情報が登録されるエントリ１００３０、ＯＳが各ハードウェアに関して割り込み待ち状態となった時間を示す情報が登録されるエントリ１００４０、各ハードウェアからの入出力完了割り込みがない場合に命令を再試行する最大回数を示す情報が登録されるエントリ１００５０、及び実際に再試行した回数を示す情報が登録されるエントリ１００６０を有する。尚、割り込み待ち時間制限値エントリ１００２０および再試行回数制限値エントリ１００５０の値は、外部デバイスごとにあらかじめ設定されているが、管理者が動的に設定を追加変更することもできる。

ここで、安定性評価器２０４０は、上述した各エントリの情報を、カーネルイベント記録情報バッファ７０００の外部デバイス割り込み待ち発生エントリ７１０４および外部デバイス割り込み発生エントリ７１０５に登録されるデバイス名とイベント発生時刻の情報を用いて登録する。割り込み待ち状態フラグエントリ１００３０は、外部デバイスからの割り込み待ちをしていた場合には１とし、外部デバイスからの割り込みが発生していた場合には０とする。割り込み待ち状態時刻エントリ１００４０には、外部デバイスの割り込み待ちをしていた場合にはその割り込み待ち発生７１０４のイベント発生時刻が登録される。

次に安定性評価器２０４０は、作成したテーブル１００００のうちの一つのレコードを選択し、そのレコードの割り込み待ち状態フラグ１００３０を参照する（１２００６）。選択したレコードの割り込み待ち状態フラグが０ならば、安定性評価器２０４０は、選択されたレコードの割り込み待ち状態時刻エントリ１００４０及び再試行回数エントリ１００６０を０でクリアする（ステップ１２００８、１２００９）。

一方、選択したレコードの割り込み待ち状態フラグが１ならば、安定性評価器２０４０は、現在時刻と割り込み待ち状態時刻１００４０との差分を取得し、取得した差分と割り込み待ち時間制限値１００２０に登録された値と比較する（１２０１０）。取得した差分値が割り込み待ち時間制限値を超過しているならば、安定性評価器２０４０は、選択したレコードの再試行回数制限値１００５０と再試行回数１００６０との値を比較する（１２０１１）。

再試行回数１００６０が再試行回数制限値１００５０を超過しているならば、安定性評価器２０４０は、選択したレコードに対応する外部デバイスの障害と判定し、デバイス障害情報バッファ１１０００へ障害と判定された外部デバイスのデバイス名を追加する（１２０１２、３）。

図１１は、デバイス障害情報バッファ１１０００の構成例を示す図である。デバイス障害情報バッファ１１０００は、計算機安定性評価器２０４０において障害発生が検知されたデバイス名が登録されるエントリ１００１０を有する。外部デバイスの障害発生が検知されない時、デバイス障害情報バッファ１１０００は空である。

一方、再試行回数１００６０が再試行回数制限値１００５０を超過していないならば、安定性評価器２０４０は、選択したレコードに対応する外部デバイスを制御するデバイスドライバへ再試行命令を発行し、選択したレコードの再試行回数１００６０に１を加える（１２０１４、５）。

ステップ１２００９の処理後、ステップ１２０１０で取得した差分値が割り込み待ち時間制限値を超過していない場合、ステップ１２０１３の処理後又はステップ１２０１５の処理後、安定性評価器２０４０は、ハードウェア入出力完了割り込み情報テーブル１００００に登録され、上述の判断が成されていないレコードの有無を確認し、まだ判断がされていないレコードが有る場合には、ステップ１２００６へ戻って、全てのレコードについて判断が終了するまで処理を繰り返す（１２０１６）。すべてのレコードについて判断した後、安定性評価器２０４０は処理を終了する（１２０１７）。尚、再試行が命令された外部デバイスについては、次の周期において計算機安定性評価器２０４０が実行される際に、再試行の成功の有無についての割り込み状況が上述のようにチェックされる。

安定性評価器２０４０による評価の終了後、計算機１０００は、カーネル制御パラメータ算出制御器２０５０を実行して、制御パラメータの修正の要否を検討する。以下、検討処理の詳細について説明する。
図１３は、静的カーネル制御パラメータテーブル２０６０の構成例を示す図である。静的カーネル制御パラメータテーブル２０６０は、登録されるパラメータの数だけのレコードを有する。各レコードは、静的カーネル制御パラメータの種類を示す静的カーネル制御パラメータエントリ１３０１０、及びエントリ１３０１０に登録された種類に対応する値が登録されるパラメータエントリ１３０２０を有する。

尚、本実施形態においては、静的カーネル制御パラメータテーブル２０６０には、静的カーネル制御パラメータテーブル２０６０を更新した時刻を示すレコード１３０１１、計算機システムの外部デバイスの数だけ、デバイス名と、デバイス有効を表すフラグの要素を持つベクトルを示すレコード１３０１２、計算機システムのカーネルモジュール数だけ、カーネルモジュール名と、モジュール有効を表すフラグの要素を持つベクトルを示すレコード１３０１３、ＯＳが持つプロセススケジューラの数だけ、スケジューラ名、スケジューラ選択フラグの要素を持つベクトルを示すレコード１３０１４、現在稼動中ＯＳにおける起動ＣＰＵ数、再起動時の起動ＣＰＵ、計算機１０００が有するＣＰＵ数の三つの要素を持つベクトルを示すレコード１３０１５、現在稼動中ＯＳにおける起動メモリ量、再起動時の起動メモリ量、計算機１０００が有するメモリ量の三つの要素を持つベクトルを示すレコード１３０１６が登録されている。

図１４は、動的カーネル制御パラメータテーブル２０７０の構成例を示す図である。動的カーネル制御パラメータテーブル２０７０は、登録されるパラメータの数だけのレコードを有する。各レコードは、動的カーネル制御パラメータの種類を示す動的カーネル制御パラメータエントリ１４０１０、エントリ１４０１０に登録されたパラメータの値が登録されるパラメータエントリ１４０２０、及びＯＳ再起動時にエントリ１４０１０に登録されたパラメータのエントリ１４０２０に登録された値をカーネルに反映させるかどうかを示すフラグが登録されるＯＳ再起動時フィードバックフラグエントリ１４０３０を有する。

尚、本実施形態においては、動的カーネル制御パラメータテーブル２０７０には、動的カーネル制御パラメータテーブル２０７０を更新した時刻を示すレコード１４０１１、計算機システムの外部デバイス数だけ、デバイス名と、デバイス有効を表すフラグの要素を持つレコード１４０１２、計算機システムのカーネルモジュール数だけ、カーネルモジュール名と、モジュール有効を表すフラグの要素を持つベクトルを示すレコード１４０１３、監視対象プロセス数だけ、監視対象プロセス名、プロセスＩＤおよび優先度の要素を持つベクトル１４０１４、カーネルがメモリ回収スレッドを起動する時間間隔を示すレコード１４０１５、カーネルがメモリ回収スレッドを起動し始めるダーティページ量のシステムページ数に対する割合を示すレコード１４０１６、システム内に存在を許すinode数の制限値を示すレコード１４０１７、ファイル名とそのファイルに対応するinode番号を管理するためのディレクトリ・エントリ（dentry）数の制限値を示すレコード１４０１８、ファイルハンドル数の制限値を示すレコード１４０１９が登録されている。尚、双方のパラメータテーブルに登録されるレコードの種類は、上述したものに限られないことは言うまでも無い。

図１５は、ハードウェア障害に関するカーネル制御パラメータ算出制御器２０５０の処理手順例を示す図である。
まずカーネル制御パラメータ算出制御器２０５０は、安定性評価器２０４０が作成したデバイス障害情報バッファ１１０００のエントリに登録された外部デバイスのうち一つを選択する（１５００１）。

そして、カーネル制御パラメータ算出制御器２０５０は、静的カーネル制御パラメータテーブル２０６０のデバイスベクタレコード１３０１２において、選択された外部デバイスに対応する有効フラグを０とする。もし、ＯＳが選択された外部デバイスのデバイスドライバをカーネルモジュールとして提供している場合には、カーネル制御パラメータ算出制御器２０５０は、静的カーネル制御パラメータテーブル２０６０のカーネルモジュールベクタレコード１３０１３において、選択した外部デバイスに関するカーネルモジュールの有効フラグを０とする。その後、カーネル制御パラメータ算出制御器２０５０は、静的カーネル制御パラメータテーブル２０６０の更新時刻レコード１３０１１を更新する（１５００２）。

次に、カーネル制御パラメータ算出制御器２０５０は、動的カーネル制御パラメータテーブル２０７０のデバイスベクタレコード１４０１２において、デバイス障害情報バッファ１１０００のエントリに登録された、選択された外部デバイスに対応する有効フラグを０とする。もし、ＯＳが選択された外部デバイスのデバイスドライバをカーネルモジュールとして提供している場合には、カーネル制御パラメータ算出制御器２０５０は、動的カーネル制御パラメータテーブル２０７０のカーネルモジュールベクタレコード１４０１３において、選択された外部デバイスに関するカーネルモジュールの有効フラグを０とする。その後、カーネル制御パラメータ算出制御器２０５０は、動的カーネル制御パラメータテーブル２０７０の更新時刻レコード１４０１１を更新する（１５００３）。

次に、カーネル制御パラメータ算出制御器２０５０は、安定性評価テーブル９０００を参照し、選択された外部デバイスの有効フラグエントリ９２００の内容を確認する（１５００４）。

選択された外部デバイスの有効フラグエントリ９２００のフラグがOFFならば、カーネル制御パラメータ算出制御器２０５０は、選択された外部デバイスの稼動を停止（以下「縮退」とも言う）しても計算機システムの継続運転が可能と判定し、選択した外部デバイスを縮退する（１５００５）。

ステップ１５００５の処理後あるいはステップ１５００４でフラグの値がＯＮだった場合、カーネル制御パラメータ算出制御器２０５０は、選択した外部デバイスの情報を、デバイス障害情報バッファ１１０００から削除する（１５００６）。
その後、カーネル制御パラメータ算出制御器２０５０は、デバイス障害情報バッファ１１０００のエントリに登録された外部デバイス全てについて処理１５００２〜１５００６を繰り返し（１５００７）、全ての外部デバイスについて終了すると、カーネル制御パラメータ算出制御器２０５０は処理を終了する（１５００８）。

その後、カーネルパラメータモディファイア２０６０が動的カーネル制御パラメータをカーネルへ反映させ、カーネルパラメータレコーダ２０７０が更新されたカーネル制御パラメータを二次記憶装置１０２０に格納する。

次に、安定性評価の対象の例として、監視対象プロセスの沈み込みについて説明する。
ここで、「監視対象プロセスの沈み込み」とは、「プロセスの状態が実行可能状態であるにもかかわらず、プロセスの優先度が低いためそのプロセスがＣＰＵに割り当てられず、プロセスが実行されない状態」を指す。

図１６は、監視対象プロセスリストテーブル１６０００の構成例を示す図である。このテーブル１６０００は、計算機安定性評価器２０４０の起動時に、メモリ上へ登録される。尚、このテーブルの内容は、管理者等が計算機安定性評価器２０４０が提供するインタフェースを用いて設定および変更できる。

監視対象プロセスリストテーブル１６０００は、監視対象となる計算機１０００で実行されるプロセス（以下「監視対象プロセス」とも言う）の数に対応する分のレコードを有する。各レコードは、監視対象プロセスのプロセス名が登録されるエントリ１６０１０、監視対象プロセスのプロセスＩＤが登録されるエントリ１６０２０、監視対象プロセスの沈み込みを判断する為の実行待ち状態の時間の情報が登録されるエントリ１６０３０、監視対象プロセスが沈み込み状態にあることを示す情報が登録されるエントリ１６０４０、及び監視対象プロセスの優先度の算出方法を示す情報が登録されるエントリ１６０５０を有する。

優先度算出方法エントリ１６０５０には、たとえば平均、最大による優先度計算方法、または、ユーザが定義した優先度計算関数を登録することができる。

図１７は、監視対象プロセスの状態遷移テーブル１７０００の構成例を示す図である。安定性評価器２０４０は、監視対象プロセスの沈み込みを判定するために、監視対象プロセスの状態遷移の情報を状態遷移テーブル１７０００に格納する。状態遷移テーブル１７０００は、監視対象プロセスリストテーブル１６０００に登録された監視対象プロセス毎に１つのテーブルを有する。

状態遷移テーブル１７０００は、複数のレコードを有する。個々のレコードは、テーブルに対応する監視対象プロセスの状態変化が発生した時刻が登録されるエントリ１７０１０と、その監視対象プロセスの変化後の状態を示す情報が登録されるエントリ１７０２０を有する。

安定性評価器２０４０は、監視対象プロセスの状態変化が発生している場合、その監視対象プロセスに対応する状態遷移テーブル１７０００に、その状態変化を記録する。尚、本実施形態では、状態遷移テーブル１７０００は、登録されたレコードの最上位が最新の時間に発生した状態遷移に関するレコードであるとし、計算機１０００は、新たな状態変化について、新たなレコードを状態テーブル１７０００の最上位に追加する。

図１８は、監視対象プロセスの沈み込みに関する安定性評価器２０４０の処理手順例を示す図である。
まず安定性評価器２０４０は、収集されたバッファ７０００と８０００の情報と安定性評価テーブル９０００の有効フラグエントリ９２００が有効であるＯＳ切替条件エントリ９１００に登録された内容とを比較して（１８００１）、一致するＯＳ切替条件エントリ９１００があるかどうか評価を実施する（１８００２）。
一致するＯＳ切替条件エントリ９１００があるならば、安定性評価器２０４０はＯＳ切替えドライバ２１２０へ制御を移す（１８００３）。

一致するＯＳ切替条件エントリ９１００が存在しない場合、まず安定性評価器２０４０は、監視対象プロセスリストテーブル１６０００から監視対象プロセスを選択し、監視対象プロセスの状態遷移テーブル１７０００を作成する。尚、選択した監視対象プロセスについて監視対象プロセスの状態遷移テーブル１７０００が作成されている場合、安定性評価器２０４０は、既に存在するテーブルに新たにレコードを追加する処理を行っても構わない（１８００５）。

安定性評価器２０４０は、カーネルモニタ２０３０が記録しているカーネルイベント記録情報テーブル７０００のプロセスコンテキストスイッチおよびプロセスウェイクアップに関するイベント発生時刻、プロセスＩＤとプロセス状態の情報を用いて状態遷移テーブル１７０００を作成する。

次に安定性評価器２０４０は、状態遷移テーブル１７０００の先頭エントリ（１７０１１）から監視対象プロセスが実行待ち状態に遷移している場合、現在時刻と監視対象プロセスが実行待ち状態に遷移した時間との差分を計算する。それ以外の場合には差分値を０とする（１８００６）。
安定性評価器２０４０は、計算した差分値から、選択した監視対象プロセスに対応する監視対象プロセスリストテーブル１６０００のレコードの監視対象プロセスエントリの沈み込み判定時間１６０３０を越えて監視対象プロセスが実行待ち状態になっているか否か判定する（１８００７）。

選択した監視対象プロセスが沈み込み判定時間以上実行待ち状態になっている場合、安定性評価器２０４０は、選択した監視対象プロセスの沈み込みが発生していると判定し、選択した監視対象プロセスに対応する、監視対象プロセスリストテーブル１６０００の沈み込み発生フラグエントリ１６０４０の値を１に設定する（１８００８、１８００９）。

一方、選択した監視対象プロセスが沈み込み判定時間以上実行待ち状態になっていない場合、安定性評価器２０４０は、選択された監視対象プロセスに対応する、監視対象プロセスリストテーブル１６０００の沈み込み発生フラグエントリ１６０４０を０でクリアする（１８０１０）。

その後、安定性評価器２０４０は、監視対象プロセスリストテーブル１６０００に登録された全ての監視対象プロセスについて、上述した処理１８００５〜１８０１０を繰り返し行う（１８０１２）。全ての監視対象プロセスについて処理が終了した後、安定性評価器２０４０は処理を終了する（１８０１２）。

図２０は、監視対象プロセスの沈み込みに関するカーネル制御パラメータ算出制御器２０５０の処理手順例を示す図である。カーネル制御パラメータ算出制御器２０５０は、監視対象プロセスリストテーブル１６０００の内容を確認し、沈み込みの発生しているプロセスの沈み込みを排除するように、動的パラメータの変更を行う。

より具体的には、カーネル制御パラメータ算出制御器２０５０は、監視対象プロセスリストテーブル１６０００の沈み込み発生フラグエントリ１６０４０が1である各監視対象プロセスに関して、当該監視対象プロセスをＣＰＵに実行状態として割り付けるような優先度を算出する。

まず、カーネル制御パラメータ算出制御器２０５０は、実行プロセス優先度履歴テーブル１９０００を作成する（２０００１）。
次に、カーネル制御パラメータ算出制御器２０５０は、監視対象プロセスリストテーブル１６０００の沈み込み発生フラグエントリ１６０４０が1である監視対象プロセスを一つ選択する（２０００２）。

図１９は、実行プロセス優先度履歴テーブル１９０００の構成例を示す図である。
カーネル制御パラメータ算出制御器２０５０は、選択した監視対象プロセスについて、カーネル内イベント記録情報バッファ７０００のコンテキストスイッチにおける実行プロセスの優先度情報を抽出して、実行プロセス優先度履歴テーブル１９０００を作成する。本実施形態においては、カーネル制御パラメータ算出制御器２０５０は、実行プロセス優先度履歴テーブル１９０００に、バッファ７０００から抽出した優先度の履歴の情報を、テーブルの上から順に最新の情報を記録する。

次に、カーネル制御パラメータ算出制御器２０５０は、選択した監視対象プロセスに対応する、監視対象プロセスリストテーブル１６０００の優先度算出方法エントリ１６０５０に登録された情報から、沈み込みが発生している該プロセスの優先度算出方法を判断する（２０００３）。

優先度算出方法が平均値であれば、カーネル制御パラメータ算出制御器２０５０は、実行プロセス優先度履歴テーブル１９０００を用いて、現在から過去数回にＣＰＵに割り付けられた任意のプロセスのプロセス優先度の平均値を算出する（２０００４）。
優先度算出方法が最大値であれば、カーネル制御パラメータ算出制御器２０５０は、実行プロセス優先度履歴テーブル１９０００を用いて、最大値を算出する（２０００５）。
優先度算出方法がユーザ定義であれば、カーネル制御パラメータ算出制御器２０５０は、ユーザが定義した優先度計算関数を実行して選択された監視対象プロセスの優先度を算出する（２０００６）。

その後、カーネル制御パラメータ算出制御器２０５０は、メモリ１０２０に格納された動的カーネル制御パラメータテーブル２０７０のプロセス優先度ベクタレコード１４０１４の内容を、算出した監視対象プロセスの優先度で更新する。監視対象プロセスの優先度の更新は、更新プロセス優先度ベクタテーブルレコード１４０１４において監視対象のプロセス名、プロセスＩＤから、監視対象のプロセスの要素の優先度を、算出した優先度で更新する（２０００７）。

次に、カーネル制御パラメータ算出制御器２０５０は、動的カーネル制御パラメータテーブル２０７０の更新時刻レコード１４０１１を現在時刻で更新する（２０００８）。
その後、カーネル制御パラメータ算出制御器２０５０は、監視対象プロセスリストテーブル１６０００に登録された監視対象プロセスのうち、沈み込みが発生していてかつ優先度が変更されていない監視対象プロセスの有無を確認し、沈み込みが発生している全ての監視対象プロセスについて、処理２０００２〜２０００８を繰り返し実行する（２０００９）。沈み込みが発生している全ての監視対象プロセスについて上記の処理を行ったカーネル制御パラメータ算出制御器２０５０は、処理を終了する（２００１０）。

その後、カーネルパラメータモディファイア２０８０が動的カーネル制御パラメータをカーネルへ反映させ、カーネルパラメータレコーダ２０９０が更新されたカーネル制御パラメータを二次記憶装置１２００に格納する。この手順は、図５の説明で記述した。

その他、静的カーネル制御パラメータ２０６０を変更することで障害対応する例を以下に示す。１つの例は、起動ＣＰＵ数に関するパラメータがある。
ＣＰＵ使用率（具体的にはユーザおよびカーネルのＣＰＵ使用率）の過大状態に関する問題では、カーネルモニタ２０３０が記録しているＯＳ稼動状態記録情報バッファ８０００に登録されたＣＰＵ使用率の情報を基に、安定性評価器２０４０が、ＣＰＵ使用率の統計を算出して、ＣＰＵ使用率が過大状態かどうかを判断する。

ＣＰＵ使用率が過大である場合、カーネル制御パラメータ算出制御器２０５０は、起動ＣＰＵ数ベクタレコード１３０１５について、現在の起動ＣＰＵ数が計算機１０００が搭載する総ＣＰＵ数よりも小さい場合、ＯＳを再起動する際の起動ＣＰＵ数を増加させるよう、静的パラメータを変更する。このパラメータ変更により、ＯＳの再起動後には、ＣＰＵ利用率の過大状態が回避される。

またスピンロック（排他処理を実現するために、条件が成立するまでループ待ちすること）奪い合いに関する問題では、カーネルモニタ２０３０が記録しているカーネル内イベント記録情報７０００のロック取得とロック解放の情報を基に、安定性評価器２０４０が、スピンロックの奪い合いによるカーネル処理のスローダウン発生を検知する。
スピンロックの奪い合いによるカーネル処理のスローダウンを検出した場合、カーネル制御パラメータ算出制御器２０５０は、ＯＳを再起動する際の起動ＣＰＵ数を１つにするように静的パラメータを変更する。このパラメータ変更により、ＯＳの再起動後には、スピンロックの奪い合いによるカーネル処理のスローダウンが回避される。

もう1つの例は、起動物理メモリ量に関するパラメータがある。
起動物理メモリ量の不足に関する問題では、カーネルモニタ２０３０が記録しているＯＳ稼動状態記録情報バッファ８０００の物理メモリ使用率及びスワップメモリ使用量の情報を基に、安定性評価器２０４０が、プロセスによる物理メモリ使用量とスワップメモリ使用量が過大状態かどうか判断する。

プロセスによる物理メモリ使用量とスワップメモリ使用量が過大であると判断された場合、カーネル制御パラメータ算出制御器２０５０は、起動物理メモリ量ベクタレコード１３０１６について、現在の起動メモリ量が、計算機１０００が搭載する総メモリ量よりも小さい場合、ＯＳを再起動する際の起動メモリ量を増加させるように静的パラメータを変更する。このパラメータ変更により、ＯＳが再起動された後、起動物理メモリ量の不足が回避される。

また、物理メモリ量が大き過ぎることに起因して発生するカーネルメモリ管理コストのオーバーヘッドに対して、起動物理メモリ量１３０１６を減らすよう静的パラメータを変更することも考えられる。このパラメータ変更により、ＯＳの再起動後に、物理メモリ量が変更後の値で割り当てられる。

また、動的カーネル制御パラメータの変更で障害対応する例を以下に述べる。１つの例は、メモリのページキャッシュ管理制御のメモリ回収スレッド起動時間間隔およびメモリ回収スレッド起動制限値がある。
物理メモリのページキャッシュ利用の過大状態に関する問題では、カーネルモニタ２０３０が記録しているＯＳ稼動状態記録情報バッファ８０００のフリーページ数及びダーティページ数の情報を基に、安定性評価器２０４０が、物理メモリのページキャッシュ利用が過大状態にあるかどうか判定する。

物理メモリのページキャッシュ利用が過大である場合、カーネル制御パラメータ算出制御器２０５０が、メモリ回収スレッドの定期的な起動時間の間隔レコード１４０１５に登録されている軌道時間間隔を短く、及びメモリ回収スレッドが起動し始めるダーティページ量レコード１４０１６に登録された値を小さくするよう、動的パラメータの値を変更する。このようにして早めにクリーンなページを用意できるようにすることで、物理メモリのページキャッシュ利用の過大状態を回避する。

もう1つの例は、inodeリミット値、dentryリミット値又はファイルハンドル数リミット値が挙げられる。
カーネルモニタ２０３０が記録しているＯＳ稼動状態記録情報バッファ８０００のinode使用数、inode使用数又はファイルハンドル使用数の情報を基に、安定性評価器２０４０が、inode使用数等が不足状態にあるかどうか判定する。Inode使用数等が不足状態にあると判断された場合、カーネル制御パラメータ算出制御器２０５０は、inodeリミット値レコード１４０１７、dentryリミット値レコード１４０１８やファイルハンドル数リミット値レコード１４０１９に登録された上限値を上げるよう、動的パラメータを変更する。

図２１は、ＯＳ切替えドライバ２１２０の処理手順例を示す図である。
ＯＳ切替ドライバ２１２０は、まずアプリケーションプログラムの終了処理を行う（２１００１）。アプリケーションプログラムの終了処理後、ＯＳ切替ドライバ２１２０は、ＯＳ再起動時に読み込まれる起動パラメータファイル（ブートローダが持つ設定ファイルのうちの一つ）を、二次記憶装置１２００に記録された静的カーネル制御パラメータテーブル２０６０を元に更新し（２１００２）、サービスを停止し（２１００３）、ＯＳを再起動する（２１００４）。

再起動されるＯＳは、その起動時に起動オプションとして静的カーネル制御パラメータテーブル２０６０を元に更新された起動パラメータファイルを読み込みカーネルに反映させて起動する。

図２２は、本実施形態におけるＯＳ再起動時の手順例を示す図である。
再起動を開始したＯＳは、通常のカーネル初期化処理を終了後に（２２００１）、障害が発生したＯＳ上で実施していたサービスやプログラムを、再起動したＯＳで継続するために起動する（２２００２）。

次に、ＯＳは、カーネルパラメータモディファイア２０８０、カーネルパラメータローダ２１００をアプリケーションとして起動する（２２００３）。
カーネルパラメータローダ２１００は、二次記憶装置１２００に格納された静的／動的カーネル制御パラメータテーブル２０６０、２０７０をメモリ１０２０にロードする（２２００４）。

カーネルパラメータモディファイア２０８０は、動的カーネル制御パラメータテーブル２０７０のＯＳ再起動時フィードバックフラグエントリ１４０３０がＯＮであるパラメータを、動的可変パラメータ変更インタフェース２０１２を介して、再起動したＯＳのカーネルに反映する。ただし、すぐにはカーネルに反映できない動的カーネルパラメータは反映できる条件が整うまで保留する。たとえば、プロセス優先度は該当するプロセスが起動するまで保留しておく（２２００５）。

上述したように、１台の計算機１０００とその主記憶１０２０にひとつのＯＳだけがロードされて実行される本実施形態において、ＯＳサービス処理中における障害やカーネル処理のスローダウンが発生した場合、その障害原因を検出し、再障害を回避するようにＯＳのカーネル制御パラメータを変更して再起動させる。これにより、現サービスに対して高信頼・高耐性・高処理能力を有するＯＳとして再起動し、サービス再開だけでなく同じ障害の再発の防止が可能となる。

次に、第２の実施形態について説明する。
第２の実施形態は、計算機１０００において発生した障害原因の改善・回避を目的としたＯＳの再起動ではなく、時刻トリガによって静的カーネル制御パラメータの変更を実施する例である。

図２３〜図２５を用いて時刻トリガによるプロセススケジューラの切替について説明する。
図２３は、プロセススケジューラ切替テーブル２３０００の構成を示す図である。このテーブル２３０００は、計算機安定性評価器２０４０の起動時に、メモリ上へ登録される。尚、このテーブルの内容は、管理者等が計算機安定性評価器２０４０が提供するインタフェースを用いて設定および変更できる。
している。
プロセススケジューラ切替テーブル２３０００は、プロセススケジューラ名を示すエントリ２３０１０、プロセススケジューラを切り替える時刻を示すエントリ２３０２０と、プロセススケジューラの切替を示すエントリ２３０３０により構成される。

図２４は、時刻トリガによるプロセススケジューラの切替に関する安定性評価器２０４０の処理フローを示す図である。
まず安定性評価器２０４０は、安定性評価テーブル９０００の有効フラグエントリ９２００が有効であるＯＳ切替条件エントリ９１００を参照して（２４００１）、一致するＯＳ切替条件エントリ９１００があるかどうか評価を実施する（２４００２）。
一致するＯＳ切替条件エントリ９１００があるならば、ＯＳ切替えドライバ２１２０へ制御を移す（２４００３）。

一致するＯＳ切替条件エントリ９１００がなければ、安定性評価器２０４０は、プロセススケジューラ切替テーブル２３０００のプロセススケジューラエントリ２３０１１〜２３０１２ついて以下で述べる処理２４００５〜２４００７を繰り返す（２４００４）。

まず安定性評価器２０４０は、プロセススケジューラの切替時間エントリ２３０２０を参照し、プロセススケジューラの切替時間かどうか判断する（２４００５）。切替時間であれば、プロセススケジューラの切替フラグエントリ２３０３０に1を設定する（２４００６）。切替時間でなければ、プロセススケジューラの切替フラグエントリ２３０３０を０でクリアする（２４００７）。安定性評価器２０４０による処理２４００５〜２４００７は、プロセススケジューラ切替テーブル２３０００のプロセススケジューラエントリ２３０１１〜２３０１２について繰り返し行う（１８０１２）。

その後、安定性評価器２０４０を終了する（２４００９）。
図２５は、プロセススケジューラを時刻ベースで変更するカーネル制御パラメータ算出制御器２０５０の処理の1つの例を示すフローである。

カーネル制御パラメータ算出制御器２０５０は、安定性評価器２０４０で更新した切替フラグエントリ２３０３０が1であるプロセススケジューラエントリがあるか判断する（２５００１）。ある場合には、静的カーネル制御パラメータテーブル２０７０のプロセススケジューラベクタ１３０１４を更新する。プロセススケジューラベクタ１３０１４は、プロセススケジューラとスケジューラ選択フラグの要素をＯＳが用意するプロセススケジューラの数だけもつベクトルである。

現在のプロセススケジューラはスケジューラ選択フラグが１となり、ＯＳ再起動により有効にされるプロセススケジューラはスケジューラ選択フラグを２とする（２５００２）。スケジューラ選択フラグが２であるプロセススケジューラが、ＯＳ再起動時にオプションとして指定される。最後にカーネル制御パラメータ算出制御器２０５０は、静的カーネル制御パラメータテーブル２０６０−１の更新時刻エントリ１３０１１を現在時刻で更新し（２５００３）、終了する（２５００４）。

その後、ＯＳ切替えドライバ２１２０へ制御を移し、ＯＳの再起動処理を行ない、再起動したＯＳは指定したプロセススケジューラでカーネルを起動する。
このように、第２の実施の形態を利用することにより、時間によって計算機１０００が対応するサービスが変わる場合に、サービス負荷に対応できる特性を有するカーネルとしてＯＳを再起動することができる。

次に第３の実施形態について説明する。
本実施形態では、上述した実施形態と異なり、最初に実行されるＯＳと再起動されるＯＳとが異なる（種類は同一とする）場合について説明する。更に、本実施形態では、再起動されるＯＳをあらかじめメモリ１０２０上にローディングしておく。以下、最初にサービスを提供しているＯＳを第１ＯＳと定義し、第１ＯＳの障害時に引き続いて起動するＯＳを第２ＯＳと定義する。

本実施形態のように、第２ＯＳをあらかじめメモリ１０２０にローディングしておくことにより、ディスク障害、ネットワークブートする場合のネットワーク障害などに対して、確実にＯＳを再起動することができ、サービス再開もしくは継続することが可能となる。さらに、第１ＯＳで発生した障害に対する処理、例えば、第１ＯＳが使用するメモリ領域のダンプ取得なども第２ＯＳによって確実に実施可能となる。

以下、第３の実施形態について第１の実施形態と異なる部分についてのみ説明する。
図２６は、計算機１０００に接続される二次記憶装置１２００に格納され、メモリ１０２０に読み出されるプログラム等の例を示す図である。
二次記憶装置１２００に格納されるプログラム等には、図２で説明したものに加え、本実施形態では、第１ＯＳと第２ＯＳの間でアクセスを可能とするプログラムであるゲートドライバ２１３０、第１ＯＳおよび第２ＯＳから共通領域にアクセスするためのプログラムである共通領域アクセスドライバ２１４０、第１ＯＳにおいて第２ＯＳをメモリ上にロードするプログラムである第２ＯＳローダ２１５０、第２ＯＳにおいて、退避した第１ＯＳメモリのダンプ取得を行うプログラムであるダンプサービス２１６０が含まれる。

図２７は、本実施形態において、第１ＯＳ初期化後のメモリ１０２０の状態例を示す図である。第１の実施形態と異なり、メモリ１０２０には、第１ＯＳ用の記憶領域（以下「第１ＯＳ領域」）２７０００、第２ＯＳ用の記憶領域（以下「第２ＯＳ領域」）２７１００及び双方のＯＳが使用可能な共通の記憶領域（以下「共通領域」）２７２００が設けられている。
図２８は、本実施形態における第１ＯＳの起動を行うための初期化手順例を示す図である。計算機１０００が起動され（２８０００）、ブートローダ２５００が第１ＯＳのＯＳカーネル２０１０をメモリ１０２０の第１ＯＳ領域２７０００にロードする（２８００１）。

第１ＯＳは、第１ＯＳ領域２７０００の初期化処理を行う（２８００２）。さらに第１ＯＳは、第２ＯＳ領域２７１００をメモリ１０２０に確保する。尚、第１ＯＳがデマンドページングをサポートしたＯＳの場合であっても、ページング非対象のメモリ領域として第２ＯＳ用のメモリ領域として確保する必要がある。もしくは、第１ＯＳの起動時に第１ＯＳ領域２７０００をあらかじめ制限し、第２ＯＳ領域２７１００から分離して置いてもよい（２８００３）。

又、第１ＯＳは、メモリ１０２０に共通領域２７２００を確保する（２８００４）。その後第１ＯＳは必要なカーネルモジュール２０２０を第１ＯＳ領域２７０００内のカーネル領域（以下「第１ＯＳカーネル領域」）２７０１０にロードし（２８００５）、ゲートドライバ２１３０を共通領域２７２００へロードする（２８００６）。

次に、第一の実施形態と同様に、第１ＯＳは、カーネルモニタ２０３０を第１ＯＳカーネル領域２７０１０へローディングする処理（２８００７）、第１ＯＳのパニック時にパニックノーティファイア２１１０をコールするように第１ＯＳカーネル領域２７０１０のフックへパニックノーティファイアを登録する処理（２８００８）、ＯＳ切替ドライバ２１２０を第１ＯＳカーネル領域２７０１０へロードする処理（２８００９）を行う。

次に、第１ＯＳは、図４の処理４００６の説明で記述したものを第１ＯＳ領域２７０００のアプリケーション領域（以下「第１ＯＳアプリケーション領域」）２７０２０にロードする。それに加えて、第１ＯＳは、第２ＯＳローダ２１５０を第１ＯＳアプリケーション領域にロードする（２８０１０）。

その後、第２ＯＳローダ２１５０は、ＯＳカーネル２０１０を第２ＯＳカーネルイメージとして第２ＯＳ領域にロードする（２８０１１）。
さらに第２ＯＳローダ２１５０は、第２ＯＳ用のカーネルモジュール２０２０、カーネルパラメータモディファイア２０８０、カーネルパラメータローダ２１００、共通領域アクセスドライバ２１４０及びダンプサービス２１６０を第２ＯＳ領域２７１００にロードする。尚、これらのプログラム群は、第１ＯＳと共通で良い（２８０１２）。

その後、図４の処理４００７と同様に、カーネルパラメータローダ２１００が、二次記憶装置１２００に格納された静的／動的カーネル制御パラメータテーブル２０６０、２０７０を第１ＯＳ領域２７０００にロードする（２８０１３）。
最後にカーネルパラメータレコーダ２０９０は、二次記憶装置１２００に格納された静的／動的カーネル制御パラメータテーブル２０６０、２０７０を、共通領域アクセスドライバ２１４０を利用して共通領域２７２００にロードし（２８０１４）、初期化処理を終了する（２８０１５）。

本実施形態においては、上述したように、ＯＳ切替ドライバ２１２０が実行されると、実行されるＯＳが第１ＯＳから第２ＯＳに切り替わる。ＯＳ切替ドライバ２１２０の実行タイミングは、第１の実施形態で示したタイミングと同様である。
図２９は、本実施形態におけるＯＳ切替ドライバ２１２０の動作手順例を示す図である。
ＯＳ切替ドライバ２１２０の実行が開始されると、ＯＳ切替ドライバ２１２０は、図２１の処理２１００１と同様に、まずアプリケーションの終了処理を行う（２９００１）。

次にＯＳ切替えドライバ２１２０は、第２ＯＳ初期化時に読み込まれる起動パラメータ（主記憶装置１０２０の第２ＯＳ領域２７１００にあるＯＳカーネル内に格納されている）の内容を、共通領域アクセスドライバ２１４０を利用しゲートドライバ２１３０を介して、共通領域２７２００に保存された静的カーネル制御パラメータテーブル２０６０を基に更新し（２９００２）、サービスを停止する（２９００３）。

その後、ＯＳ切替えドライバ２１２０は、障害が発生した第１ＯＳが使用していた第１ＯＳ領域２７０００に格納された内容を二次記憶装置１２００に退避するかどうか判断する。尚、管理者等は、第１ＯＳ領域のダンプ取得など障害対応サービスが必要な場合、第１ＯＳ領域２７０００の内容を二次記憶装置１２００に退避するようにＯＳ切替ドライバ２１２０に設定しておく（２９００４）。

第１ＯＳ領域２７０００の退避が必要な場合、ゲートドライバ２１３０は、第２ＯＳ領域２７１００と第１ＯＳ領域２７０００をスワップ（第２ＯＳの領域を第１ＯＳの領域へ変更し、第１ＯＳの領域を第２ＯＳの領域に変更）する（２９００５）。
一方、第１ＯＳ領域２７０００の退避が必要ない場合、ゲートドライバ２１３０は、第２ＯＳ領域２７１００を物理メモリ空間の先頭アドレスに一致させるように配置し、再起動の準備をする（２９００６）。

その後、ＯＳ切替ドライバ２１２０は、ゲートドライバ２１３０を用いて、第２ＯＳカーネルのエントリポイントへ制御を移動し（２９００７）、第２ＯＳを起動する（２９００８）。

図３０は、第２ＯＳ起動後のメモリ１０２０におけるプログラム等の格納状態の例を示す図である。
メモリ１０２０は、第２ＯＳ領域３００００、共通領域３０２００及び第１ＯＳ退避領域３０１００に領域分けされる。

図３１は、本実施形態における第２ＯＳ起動の手順の１例を示す図である。
第２ＯＳは、第２ＯＳ領域３００００を初期化し、通常のカーネル初期化処理を行う（３１００１）。

カーネル初期化後に起動する初期化プロセスは、第２ＯＳで行うサービス（ダンプ等）を判断する（具体的な方法としては、サービスの種類が起動パラメータで定義され、初期化プロセスは、その起動パラメータの内容を確認する）（３１００２）。

ステップ３１００２で第１ＯＳ領域のダンプ取得を行うと判断した場合（３１０１０）、第２ＯＳは、まず、共通処理を行う（３１０１１）。共通処理は起動されると（３１０４０）、まず、カーネルパラメータモディファイア２０８０、カーネルパラメータローダ２１００を起動する（３１０４１）。カーネルパラメータローダ２１００は、共通領域３０２００に保存された静的／動的カーネル制御パラメータ２０６０、２０７０を、共通領域アクセスドライバ２１４０を利用して、第２ＯＳ領域３００００にロードする（３１０４２）。

次に、図２２の処理２２００５と同様に、カーネルパラメータモディファイア２０８０は、第２ＯＳ領域３００００に格納された動的カーネル制御パラメータテーブル２０７０のＯＳ再起動時フィードバックフラグエントリ１４０３０がＯＮであるパラメータを、動的可変パラメータ変更インタフェース２０１２を介して、第２ＯＳカーネル３００１０に反映させる処理を行い（３１０４３）、終了する（３１０４４）。

次に、ダンプサービスアプリケーション２１６０は、ダンプ取得先デバイス（例えば二次記憶装置１２００）に障害が発生していないかどうかを、第２ＯＳ領域３００００の静的カーネル制御パラメータ２０６０のデバイスベクタエントリ１３０１２から判断する（３１０１２）。

ダンプ先デバイスに障害が発生していない場合、ダンプサービスアプリケーション２１６０は、第１ＯＳ退避領域３０１００に格納された情報をダンプ取得先デバイスへ格納（「ダンプ」）する（３１０１４）。
ダンプ先デバイスに障害が発生していた場合、ダンプサービスアプリケーション２１６０は、共通領域３０２００に格納された静的カーネル制御パラメータ２０６０のデバイスベクタエントリ１３０１２から有効デバイスフラグが１であるハードウェア（以下「代替ダンプ先デバイス」）を探す（３１０１３）。代替ダンプ先デバイスがあるならば、ダンプサービスアプリケーション２１６０は、共通領域アクセスドライバ２１４０を利用しゲートドライバ２１３０を介して、第１ＯＳのメモリ退避領域３０１００のダンプ取得を行う（３１０１４）。代替ダンプ先デバイスがないならば、ダンプサービスアプリケーション２１６０は、メール、画面表示、ログなどを用いて管理者に通知する（３１０１５）。
尚、本実施形態においては、第１ＯＳのメモリ退避領域３０１００の内容は、第２ＯＳ稼動中も変更されずに残っているので、管理者は通知を受けた後対処してもよい。

ステップ３１００２で第２ＯＳにおいて第１ＯＳでのサービスを再開すると判断した場合（３１０２０）、第２ＯＳの初期化プロセスは、障害が発生した第１ＯＳ上で実施していたサービスやプログラムを、再起動するために起動する（３１０２１）。その後、共通処理を行う（３１０２２）。
ステップ３１０３０で、第２ＯＳにおいてユーザが定義した処理関数を実行すると判断した場合（３１０３０）、第２ＯＳの初期化プロセスは、まず共通処理を行い（３１０３１）、ユーザが定義した処理関数の実行を行う（３１０３２）。

このように、再起動するＯＳをあらかじめメモリ上にローディングしておく第３の実施形態により、ディスク障害、ネットワークブートする場合のネットワーク障害などに対しても確実にＯＳを再起動することができ、サービス再開もしくは継続することができる。さらに、第１ＯＳで発生した障害に対するサービス、例えば、第１ＯＳメモリ領域のダンプ取得なども第２ＯＳによって実施可能となる。

第４の実施形態は、上述した再起動方法を複数台の計算機１０００を有する計算機システムに適用する例である。以下、第４の実施形態が第１の実施形態と異なる部分について図３２〜図３６を用いて説明する。

図３２は、第４の実施形態におけるシステム構成例を示す図である。
複数台の計算機１０００は、図１で示した構成に加え、それぞれ少なくとも、専用線３２３００、イーサネット（登録商標）３２４００、シリアルケーブル３２５００のいずれかで相互接続されており、また、ネットワーク１５００を介して遠隔地に存在する計算機１６００と接続され、相互に通信を行う。又、複数台の計算機１０００は、二次記憶装置１２００を共有する。尚、二次記憶装置１２００は、上述したように、冗長構成（ＲＡＩＤ構成、複数構成等）であって良い。

図３３は、計算機起動状態情報テーブル３３０００の構成例を示す図である。この計算機起動状態情報テーブル３３０００は、複数台の計算機１０００の起動状態および計算機１０００のスペック（計算機１０００が有するハードウェア資源の情報）を示すテーブルである。このテーブルに登録された情報に基づいて、ある計算機１０００の障害に基づいて起動される計算機１０００が選択される。計算機起動状態情報テーブル３３０００は、計算機システムが有する計算機１０００の数分のレコードを有する。各レコードは、該レコードに対応する計算機の情報が登録される計算機エントリ３３０１０、レコードに対応する計算機１０００が待機状態であるか否かを示す情報が登録されるエントリ３３０２０、レコードに対応する計算機１０００に搭載されたＣＰＵ数の情報が登録されるエントリ３３０３０、レコードに対応する計算機１０００に搭載された物理メモリ量の情報が登録されるエントリ３３０４０を有する。

待機フラグエントリ３３０２０は、そのエントリ３３０２０を有するレコードに対応する計算機１０００がサービス運用を開始する時に０と設定され、その計算機１０００が待機状態（「待機状態」とは、計算機が停止しているまたは起動していてもサービス再開の再起動命令を受信するのをただ待っている状態）となる時に１と設定される。
又、計算機起動状態情報テーブル３３０００は、二次記憶装置１２００にあらかじめ用意（例えば、複数台計算機のシステム構成時に、管理者等が二次記憶装置１２００に作成しておく）されているが、図３２で説明したシステム構成が変更された場合、各計算機１０００が、動的に計算機起動状態情報テーブル３３０００の設定を更新する。

又、図１３で説明した静的カーネル制御パラメータテーブル２０６０における起動ＣＰＵ数ベクタ１３０１５の総ＣＰＵ数および起動物理メモリ量ベクタ１３０１６の総メモリ量は、計算機起動状態情報テーブル３３０００の待機フラグが１のエントリの中で最大の搭載ＣＰＵ数３３０３０および最大の搭載物理メモリ量３３０４０の情報が使用されて良い。

図３４は、共有デバイステーブル３４０００の構成例を示す図である。各計算機１０００は、このテーブルに登録される情報に基づいて、計算機システムが有する各種ハードウェア（例えばキーボード等）が各計算機１０００で共有されているか否かを判断する。
共有デバイステーブル３４０００は、行及び列に、計算機システムが有する計算機１０００が登録されたマトリックス構成を有している。そして、各々行と列が交わる升目（エントリ）に、行で示される計算機１０００と列に示される計算機１０００とで共有されるハードウェアの情報が登録される。例えば、図３４において、計算機１と計算機Ｎとでは、デバイスｍが共有されるため、マトリックスの該当する欄に、デバイスｍの情報が登録される。尚、各計算機１０００の間でデバイスを共有しない場合、エントリには何も情報が登録されない。

尚、共有デバイステーブル３４０００は、二次記憶装置１２００にあらかじめ用意（複数台計算機のシステム構成時に、管理者等が二次記憶装置１２００に作成しておく）されているが、図３２で説明した計算機システムの構成が変更された場合、計算機１０００は、動的に共有デバイステーブル３４０００の設定を行う。具体的には、図３２で説明した計算機システムの構成が変更された場合、管理者等が共有デバイステーブル３４０００を変更しておく。

図３５は、本実施形態におけるＯＳ切替ドライバ２１２０の処理手順例を示すフロー図である。本実施形態においては、ある計算機１０００におけるＯＳ切替ドライバ２１２０は、上述した実施形態と異なり、他の計算機１０００で実行されるＯＳへ処理の切替を行う。

ある計算機１０００で実行されるＯＳ切替ドライバ２１２０は、上述したアプリケーションプログラムの終了処理を行い（３５００１）、起動する計算機１０００（以下「待機系計算機」とも言う）を計算機起動状態情報テーブル３３０００を用いて決定する。この際、ＯＳ切替ドライバ２１２０は、二次記憶装置１２００に格納された計算機起動状態情報テーブル３３０００を自身を実行する計算機１０００のメモリ１０２０に読み出す。ＯＳ切替ドライバ２１２０は、読み出したテーブル３３０００から、待機状態となっている計算機を待機系計算機として選択する。
待機系計算機のより詳細な決定方法は、例えば以下の方法がある。
ＯＳ切替ドライバ２１２０は、計算機起動状態情報テーブル３３０００における待機フラグ３３０２０が１である計算機１０００の内、静的カーネル制御パラメータテーブル２０６０における起動ＣＰＵベクタ１３０１５のＯＳ再起動時ＣＰＵ数と起動物理メモリ量ベクタ１３０１６のＯＳ再起動時メモリ量を最低限満足する計算機１０００を選択する（３５００２）。

ＯＳ切替ドライバ２１２０は、二次記憶装置１２００に格納された静的カーネル制御パラメータテーブル２０６０と動的カーネル制御パラメータテーブル２０７０を、共有デバイステーブルを元に更新する。
更新方法は、例えば、共有デバイスに障害が発生している場合には、ＯＳ切替ドライバ２１２０は、静的／動的カーネル制御パラメータテーブル２０６０、２０７０のデバイスベクタ１３０１２、１４０１２における、障害が発生した共有デバイスの有効フラグおよびそのデバイスに対応するカーネルモジュールがあれば、その有効フラグを０のままとし、共有デバイス以外の障害の場合には、共有デバイスの有効フラグおよびデバイスに対応するカーネルモジュールがあればその有効フラグを１として更新する方法が考えられる（３５００３）。

ＯＳ切替ドライバ２１２０は、計算機の再起動時に読み込まれる起動パラメータファイル（ブートローダが持つ設定ファイル内の、起動パラメータが記述されているファイル）を、二次記憶装置１２００に格納された静的カーネル制御パラメータテーブル２０６０を元に更新し（３５００４）、サービスを停止する（３５００５）。

その後、ＯＳ切替ドライバ２１２０は、待機系計算機へ専用線３２３００またはイーサネット（登録商標）３２４００やシリアルケーブル３２５００を利用して起動信号または再起動命令を送信し（３５００５）、ＯＳ切替ドライバの処理を終了する（３５００６）。

図３６は、本実施形態における待機系計算機起動時の手順例を示すフロー図である。
サービスを停止した計算機１０００で実行されていたＯＳ切替ドライバ２１２０からの起動信号を受信した待機系計算機は、自己のＯＳの起動を開始する。
起動されたＯＳは、通常のカーネル初期化処理を終了後に（３６００１）、計算機起動状態情報テーブル３３０００の、自身に対応するレコードの待機状態フラグエントリ３３０２０を０に設定する（３６００２）。
その後の処理３６００３〜３６００６は、図２２の処理２２００２〜２２００５で説明した内容と同一である。

上述したように、本実施形態においては、複数台の計算機において、ＯＳサービス処理中における障害やカーネル処理のスローダウンが発生した場合、その障害原因を検出し、再障害を回避するようにＯＳのカーネル制御パラメータを変更して待機系計算機を起動させる。これにより、現サービスに対して高信頼・高耐性・高処理能力を有する計算機として再起動し、サービス再開だけでなく同じ障害の再発の防止が可能となる。

第一の実施形態における計算機ハードウェアの構成例を示す図である 第一の実施形態における二次記憶装置に格納されている内容例を示す図である。 第一の実施形態におけるＯＳ初期化後のメモリ上の状態例を示す図である。 第一の実施形態の初期化フロー例を示す図である。 第一の実施形態の動作フロー例を示す図である。 第一の実施形態における、ＯＳが行うパニック処理の動作フロー例を示す図である。 第一の実施形態におけるカーネル内イベント記録情報バッファの構成例を示す図である。 第一の実施形態におけるＯＳ稼動状態記録情報バッファの構成例を示す図である。 第一の実施形態における安定性評価テーブルの構成例を示す図である。 第一の実施形態におけるハードウェア入出力完了割り込み情報テーブルの構成例を示す図である。 第一の実施形態におけるデバイス障害情報バッファの構成例を示す図である。 第一の実施形態におけるハードウェア障害に関する安定性評価器の処理フロー例を示す図である。 静的カーネル制御パラメータテーブルの構成例を示す図である。 動的カーネル制御パラメータテーブルの構成例を示す図である。 第一の実施形態におけるハードウェア障害に関するカーネル制御パラメータ算出制御器の処理フロー例を示す図である。 第一の実施形態における監視対象プロセスリストテーブルの構成例を示す図である。 第一の実施形態における監視対象プロセスの状態遷移テーブルの構成例を示す図である。 第一の実施形態における監視対象プロセスの沈み込みに関する安定性評価器の処理フロー例を示す図である。 第一の実施形態における過去の実行プロセス優先度の履歴テーブルの構成例を示す図である。 第一の実施形態における監視対象プロセスの沈み込みに関するカーネル制御パラメータ算出制御器の処理例を示すフロー図である。 第一の実施形態におけるＯＳ切替えドライバの処理フロー例を示す図である。 第一の実施形態におけるＯＳ再起動時のフロー例を示す図である。 第２の実施形態におけるプロセススケジューラ切替テーブルの構成例を示す図である。 第２の実施形態におけるプロセススケジューラの切替に関する安定性評価器の処理フロー例を示す図である。 第２の実施形態におけるカーネル制御パラメータ算出制御器２０５０の処理例を示す図である。 第３の実施形態における二次記憶装置１２００に格納されている内容例を示す図である。 第３の実施形態におけるＯＳ初期化後のメモリ上の状態例を示す図である。 第３の実施形態における初期化フロー例を示す図である。 第３の実施形態におけるＯＳ切替えドライバの処理フロー例を示す図である。 第３の実施形態におけるＯＳ再起動後のメモリ上における状態例を示す図である。 第３の実施形態におけるＯＳ再起動時の１例を示す図である。 第４の実施形態におけるシステム構成例を示す図である。 第４の実施形態における計算機起動状態情報テーブルの構成例を示す図である。 第４の実施形態における共有デバイステーブルの構成例を示す図である。 第４の実施形態におけるＯＳ切替えドライバの処理フロー例を示す図である。 第４の実施形態におけるＯＳ再起動時のフロー例を示す図である。

符号の説明

１０００…計算機、１０１０…ＣＰＵ、１０２０…主記憶、１０３０…ビデオアダプタ、１０４０…ネットワークインタフェース、１０５０…二次記憶装置インタフェース、１０６０…シリアルポートインタフェース、１１００…ディスプレイ、１２００…記憶装置、１３００…キーボード、１４００…マウス、１５００…ネットワーク、１６００…計算機。

Claims (13)

1. プロセッサと、
   主記憶と、
   二次記憶装置を有し、
   前記プロセッサは、自身で実行されるオペレーティングシステム（以下「ＯＳ」）の状態を監視し、前記監視結果に基づいて、前記ＯＳの設定パラメータを再計算し、前記再計算された前記設定パラメータを前記二次記憶装置に格納し、前記ＯＳを再起動する際には、前記二次記憶装置に格納された前記設定パラメータに基づいて前記ＯＳを再起動することを特徴とする計算機システム。
2. 前記パラメータには、動的パラメータと静的パラメータが含まれていることを特徴とする、請求項１記載の計算機システム。
3. 前記状態とは、前記ＯＳの実行に基づく負荷や障害に関する情報であり、前記プロセッサは、前記設定パラメータを再計算する際に、前記負荷や前記障害を回避するように前記パラメータを再計算することを特徴とする請求項１記載の計算機システム。
4. 前記プロセッサは、前記監視結果が該計算機システムの運用の継続が不可能であることを示している場合には、前記ＯＳを再起動することを特徴とする請求項１記載の計算機システム。
5. 前記プロセッサは、前記動的パラメータを再計算した場合、前記主記憶に格納されている前記動的パラメータの値を更新し、更新した前記動的パラメータの値に基づいて前記ＯＳを実行することを特徴とする請求項２記載の計算機システム。
6. 前記動的パラメータには、プロセッサで実行されるプロセスの優先度が含まれていることを特徴とする請求項２記載の計算機システム。
7. 前記静的パラメータには、該計算機システムに含まれる装置の障害情報に基づく前記装置の使用の可否に関する情報が含まれることを特徴とする請求項２記載の計算機システム。
8. プロセッサと、
   主記憶と、
   二次記憶装置を有し、
   前記プロセッサは、第一のオペレーティングシステム（以下「第一のＯＳ」）を起動する際に、前記第一のＯＳと同種の第二のＯＳ自身の情報を前記主記憶に格納し、前記第一のＯＳの状態を監視し、前記監視結果に基づいて、前記第一のＯＳの設定パラメータを再計算し、前記再計算された前記設定パラメータを前記主記憶に格納し、前記第一のＯＳに障害が発生した場合は、前記主記憶に格納された前記設定パラメータに基づいて前記第二のＯＳを前記主記憶から起動することを特徴とする計算機システム。
9. 前記第二のＯＳを実行するプロセッサは、前記第一のＯＳが使用していた前記主記憶の領域に格納されているデータを前記第二のＯＳが使用する装置に格納することを特徴とする請求項８記載の計算機システム。
10. 前記状態とは、前記第一のＯＳの実行に基づく負荷や障害に関する情報であり、前記プロセッサは、前記設定パラメータを再計算する際に、前記負荷や前記障害を回避するように前記パラメータを再計算することを特徴とする請求項８記載の計算機システム。
11. 第一の計算機と、
    第二の計算機と、
    前記第一の計算機及び前記第二の計算機と接続される記憶装置とを有し、
    前記第一の計算機は、
    該第一の計算機で実行されるオペレーティングシステム（以下「ＯＳ」）の状態を監視し、前記監視結果に基づいて、前記ＯＳの設定パラメータを再計算し、前記再計算された前記設定パラメータを前記記憶装置に格納し、
    前記第二の計算機は、前記第一の計算機に障害が発生した場合には、前記記憶装置に格納された前記設定パラメータに基づいて、該第二の計算機で実行されるＯＳを起動することを特徴とする計算機システム。
12. 前記設定パラメータには、前記第一の計算機と前記第二の計算機とで共用される装置についての情報が含まれていることを特徴とする請求項９記載の計算機システム。
13. 前記状態とは、前記ＯＳの実行に基づく負荷や障害に関する情報であり、前記第一の計算機は、前記設定パラメータを再計算する際に、前記負荷や前記障害を回避するように前記パラメータを再計算することを特徴とする請求項１１記載の計算機システム。
    

Images