JP2004030363A

JP2004030363A - 論理計算機システム、論理計算機システムの構成制御方法および論理計算機システムの構成制御プログラム

Info

Publication number: JP2004030363A
Application number: JP2002187262A
Authority: JP
Inventors: Toshiyuki Ukai; 鵜飼　敏之; Yoshifumi Takamoto; 高本　良史
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2002-06-27
Filing date: 2002-06-27
Publication date: 2004-01-29
Anticipated expiration: 2022-06-27
Also published as: US20040003319A1; US7328367B2; JP4054616B2

Abstract

【課題】論理計算機を用いた高信頼化において、予備システム用の論理計算機をあらかじめ用意することなく、信頼性を向上させる。
【解決手段】一つの物理プロセッサ上に，運用論理計算機とその運用論理計算機の動作監視を行う監視用論理計算機を設ける．稼動中の運用論理計算機のシステムの，監視用論理計算機による状態監視に基づく障害の事前予測により、予備論理計算機を生成し、システムを稼動する論理計算機を切り替えることによる。
【選択図】　図１

Description

【０００１】
【発明の属する技術分野】
本発明は論理計算機を用いたシステムにおける、障害発生に対する信頼性の向上に関する。
【０００２】
【従来の技術】
プロセッサ技術の進歩により、高い性能のプロセッサを容易に利用できるようになった。従来は性能が不足した場合、複数の計算機を並列に実行することで性能不足を解消していた。しかし、高性能なプロセッサの出現により、逆に高性能なプロセッサをいかに有効に使用するかに観点が移りつつある。その一つが論理計算機機能である。これは、物理的に一つの計算機から、仮想的な複数の計算機を生成する技術である。
【０００３】
例えば、一つの物理プロセッサを時分割で複数の論理計算機に割り当てることで、論理計算機上で稼動するソフトウェアはあたかも別個の物理計算機があるかのように動作することが出来る。この機能により、一つの高性能なプロセッサを有効に使用することができる。この論理計算機の機能をさらに発展させ、より高信頼なものにする例がある。
【０００４】
ＵＳ００５３４５５９０Ａでは２つの論理計算機でホットスタンバイを構築し、いずれかの論理計算機に障害が発生すると、もう一方の論理計算機に切り替えて処理を継続する方法について述べられている。ホットスタンバイは通常異なる計算機で構成する高信頼化方法である。２つの異なる計算機を用意し、通常は一つの計算機で処理を行い、もし、障害が発生すると、待機しているもう一つの計算機に切り替えることで処理を停止させない技術である。ＵＳ００５３４５５９０Ａでは、同一計算機上に生成された２つの論理計算機間でホットスタンバイを構築している。こうすることで、システムレベルの信頼性を向上することができる。
【０００５】
特開２００１−３４４９５では、二重化された処理装置の障害を予測に基づく実行状態のセーブと系切り替えにより、系切り替えに起因する装置処理の異常終了を防ぐ技術について述べられている。このようにハードウェアレベルで障害を予測する技術はある。
【０００６】
【発明が解決しようとする課題】
ＵＳ００５３４５５９０Ａでは、２つの論理計算機でホットスタンバイを構築することで信頼性を向上する方法について述べられている。この方法では、ホットスタンバイ用に予備論理計算機をあらかじめ用意している。ＵＳ００５３４５５９０Ａの課題は、予備論理計算機をあらかじめ用意することにより、いつ発生するか不明な障害に対して、計算機資源が消費されることである。
【０００７】
特開２００１−３４４９５では、ハードウェア障害を予測して、二重化された装置の動作を変える方法について述べられている。この方法では障害を予測しているが、装置は二重化を前提としており、同様に計算機資源が消費される。
【０００８】
【課題を解決するための手段】
上記問題を解決するために、少なくとも一つの物理プロセッサから構成される計算機を用いた論理計算機において、運用中の論理計算機の障害を予測する手段を用意し、障害予測に基づき予備の論理計算機を生成し、障害発生前に予備の論理計算機に切り替える。
【０００９】
【発明の実施の形態】
［実施例１］
以下、本発明に係る多重化システムの高信頼化方法の実施例１を図面に示し、詳細に説明する。
【００１０】
図１は、本発明による多重化システムの高信頼化方法の概略構成図を示している。１０１と１０２はそれぞれ論理計算機であり、１１１は物理計算機である。物理計算機１１１は物理プロセッサ装置１０８，ディスク装置１０９，ネットワーク装置１１０および計算機資源分割機構１０７から構成される。
【００１１】
１０１と１０２の論理計算機は物理計算機１１１の資源を元に作成された仮想的な計算機である。図では省略してあるが、本番システムの論理計算機は一般には複数個作成されている。即ち、一般には複数個の本番システムに対して一つの監視システムが設けられる。論理計算機１０１と１０２は、物理計算機１１１が有するプロセッサ装置１０８とディスク装置１０９とネットワーク装置１１０がそれぞれ分割され割り当てられている。こうすることで１０１と１０２の論理計算機上で稼動するオペレーティングシステム（ＯＳ）やアプリケーション（アプリ）などのソフトウェア１０３は、あたかもそれぞれ別個の物理計算機があるかのように動作することができる。具体的には、プロセッサやネットワークは時分割で各論理計算機に割り当てられ、ディスク装置やメモリは分割して割り当てられている。この機能を実現しているのが計算機論理資源分割機構１０７である。本実施例では、論理計算機１０１に論理計算機マネージャ１０６を追加し、論理計算機１０２に論理計算機エージェント１０５を追加することにより、論理計算機１０２上で動作するソフトウェア１０３を高信頼化する機能を有している。
【００１２】
図２は、本方式を実現するための論理計算機マネージャ１０６と論理計算機エージェント１０５の構成を示している。論理計算機エージェント１０５は、監視対象データ採取機構２０１、引継ぎ情報退避機構２０２、監視対象データ・テーブル２０３から構成される。論理計算機マネージャ１０６は、障害予測判定機構２０４、システム切り替え機構２０５、障害予測判定用状態管理テーブル２０６、障害予測レベル定義テーブル２０７、論理計算機構成テーブル２０８から構成される。
【００１３】
監視対象データ・テーブル２０３には障害予測のために用いるデータが記述されている。障害予測判定用状態管理テーブル２０６には、発生した事象の障害予測レベルを判定するために用いる情報が記述されている。障害予測レベル定義テーブル２０７には、予測される障害のレベルを判定するための定義が記述されている。論理計算機構成テーブル２０８には、複数の論理計算機に対して割り当てられている資源と障害予測判定に用いる情報が記述されている。
【００１４】
監視対象データ採取機構２０１は、監視対象としたデータを採取する機能を有している。引継ぎ情報退避機構２０２は、障害が予測される論理計算機において、予備論理計算機で引き継がれるべき情報を退避する機能を有している。障害予測判定機構２０４は、監視対象データを解析し、障害予測を行う機能を有している。システム切替機構２０５は、論理計算機に障害が予測される場合、運用中論理計算機システムを予備論理計算機システムに切り替える機能を有する。
【００１５】
図３は、監視対象データ・テーブル２０３を示している。このテーブルには、障害予測に用いるデータ（ログ）の出力先ファイル名が記されている。ログ・ファイルは基本的にシスログによって出力される。シスログの機能は、デーモンプログラムであるｓｙｓｌｏｇｄが、カーネルやデーモン、各種アプリケーション・プログラムなどから出力されるログ・メッセージを受け取り、それをログ・ファイルやコンソールなどへ出力することにより実現されている。シスログによってログを出力するファイルはシステム管理者が自由に設定できるため、監視対象データ・テーブルの監視対象データ３０１のカラムに出力ファイル名を示すことにより、監視するデータを指定する。また、アプリケーションによっては、独自の仕組みでログ・ファイルを生成するものもある。これらも監視する必要のあるログ・ファイルを監視対象データ・テーブルに登録する。
【００１６】
図４は監視対象データ採取機構２０１のフローを示している。ステップ４０１では、監視データ・テーブル２０３に登録されている監視対象データ（ログ・ファイル）を監視する。ステップ４０２で、監視対象データ３０１に書き込みがあった場合、ステップ４０３で書き込まれたメッセージを論理計算機マネージャ１０６に送信する。このとき、書き込まれたメッセージをすべて送信する必要はなく、例えば、後述（図７）する障害予測判定用状態管理テーブル２０６で障害予測の判定に用いる判定対象のみを送ってもよい。この場合は、判定対象が記述してある障害予測判定用状態管理テーブル２０６に相当するテーブルを論理計算機エージェント１０５に置く必要がある。また、シスログ等のログ出力機構では、構成定義ファイルなどの記述により、ネットワークに接続された他のホストにログを出力する機能を有するものもある。このログを論理計算機マネージャ１０６に送信する機構は、この機能を用いて実現してもよい。
【００１７】
図５は、障害予測レベル定義テーブル２０７を示している。このテーブルには図７で後述する図７で読み取られた障害予測レベル毎に新しい論理計算機に切り換える必要があるかどうかを判定するための条件（閾値）と、その閾値に達した場合に実行する動作（切り替えの要否）を記述している。カラム５０１には障害予測レベルが記述され、その障害予測レベルに達したと判定されるための条件（障害予測判定の閾値）がカラム５０２に記述されている。本実施例では、ある事象が発生した場合において、障害予測判定に用いる閾値として、総累積回数（カラム５０３）と、単位時間内の累積回数（カラム５０４）を、それぞれ管理している。カラム５０２に記述される障害予測判定の閾値を超えた場合の動作（切り替え要否）をカラム５０５に示し、さらにそれを実行するための条件をカラム５０６に示している。例えば、障害予測レベル１の場合は、その事象が一回発生した時点で無条件に切り替え処理を実施することを示す。障害予測レベル３では、事象の発生が累積で１００回を超えた場合、または、一分間で１０回発生した場合に、管理者の許可を得て、切り替え処理を実施することを示す。また、障害予測レベル４では、事象の発生が累積で１００回を超えた場合、または、一分間で１０回発生した場合に、管理者に切り替えを推奨する通知（メールなど）を出し、切り替え処理自体は実施しないことを示す。
【００１８】
図６には、本実施例で用いる障害予測判定用の項目を示している。ここではシスログを例に述べている。シスログには、カラム６０１のファシリティとカラム６０２のプライオリティという考え方がある。ファシリティはシステムログの種類を表す。プライオリティは優先度を表わし、表の上方がより高い優先度となっている。これらのファシリティとプライオリティを組み合わせることによって、シスログの種類を指定することになる。この種類とカラム６０３に示すようなメッセージが組み合わされて出力される。
【００１９】
図７は、障害予測判定用状態管理テーブルを示している。このテーブルには、判定対象となる事象が発生した場合の、障害予測レベルと、該事象の現在の状態（発生状況）を表す。カラム７０１は判定対象を表す。この内容は、図６で示した障害予測判定用の項目の組み合わせである。カラム７０２はファシリティ、カラム７０３はプライオリティ、カラム７０４はメッセージの組み合わせを表している。カラム７０１の各項目中「＊」は、その項目については「関知しない」ことを表す。つまり、事象１の場合は、プライオリティ７０３のログ・メッセージ全てに対しての項目となる。カラム７０５は、カラム７０１で示した事象が発生した場合の障害予測レベル（障害予測レベル定義テーブル２０７で定義）である。カラム７０６は判定対象の状態（発生状況）を示している。本実施例では、カラム７０７で発生の総累積回数を保持し、カラム７０８で所定時間（図５の障害予測レベル定義テーブルで障害予測レベルに応じて設定した単位時間）内に発生した累積回数を保持している。このとき、カラム７０８の所定時間内の発生累積は、発生事象の時系列の記録が必要である。このため、カラム７０９で事象の時系列の発生時刻を管理する図８に示す発生時刻管理テーブルをポイントする。また、事象２の項目は、プライオリティが「ＡＬＥＲＴ」のログ・メッセージが出力された場合、障害予測レベルが「１」となることを示し、現在の発生累積が０であることを示している。図５の障害予測レベル定義テーブルに従うと、障害予測レベルが「１」では、一回でもその事象が発生した場合は無条件にシステム切り替え処理を実施する。このため、事象２では、カラム７０８の所定時間内の発生累積は評価の対象にならず、従ってカラム７０９の発生時刻管理テーブルもないことを示している。同様に事象３と事象４では、メッセージの内容が「Ｄｅｖｉｃｅ　ｅｒｒｏｒ」の場合に、障害予測レベル「２」および「３」の両方で管理することを示している。この場合は所定時間内の発生累積７０８が意味を持つため、発生時刻管理テーブルが必要となり、カラム７０９で、そのテーブルをポイントしている。図７の事象４では障害予測レベルは３であり、事象６では障害予測レベルは４である。これに基づいて図５を参照すると障害予測レベル３と４とでは障害予測判定の閾値が同じでも条件と切り替え要否の結果が異なっている。これは図７でプライオリティＣＬＩＴが１００回起きるよりＤｅｖｉｃｅ　ｅｒｒｏｒというメッセージが１００回起きる方がシステムがより不安定な状態にあると判断しているからである。
【００２０】
図８は、図７のカラム７０９でポイントされる、発生時刻管理テーブルの例を示している。発生時刻管理テーブルは図７のポインタの数だけ別個に設けられる。発生時刻管理テーブルは、テーブル内のスロット数を示す「テーブル内スロット数」フィールド８０１（スロット数を「ｎ」とする）と、最新のデータが格納されたスロット番号を示す「最新データ格納スロット番号」フィールド８０２と、「最古データ格納スロット番号」フィールド８０３と、時刻情報を格納する複数のスロット８０４から構成される。スロット群８０４は、スロット＃（ｎ−１）のスロットの次はスロット＃０に戻るようにラップアラウンドで事象の発生時刻を格納していく構造である。「最古データ格納スロット番号」フィールド８０３は、前回の該当事象発生時において、障害予測レベル定義テーブル（図５）で定義される単位時間分さかのぼった時間内における最も古いデータを格納するスロット番号を格納する。
【００２１】
この発生時刻管理テーブルの管理方法は次のようになる。まず、発生時刻管理テーブルに格納すべき事象が発生した場合、「最新データ格納スロット番号」フィールド８０２で表されるスロットの次の番号のスロットにその事象が発生した時刻を記録する。このときに、「最古データ格納スロット番号」として格納すべきスロット番号を探して、フィールド８０３に格納する。そして、「最古」のスロットから「最新」のスロットの数を、図７のカラム７０８に格納することにより、発生時刻管理テーブルの更新を終了する。
【００２２】
なお、「テーブル内スロット数」８０１を、障害予測レベル定義テーブル（図５）における単位時間内累積の回数で示される数と等しくしておくと、「最古データ格納スロット番号」フィールド８０３は必ずしも必要なくなる。この理由は、これから記録しようとする時刻情報と、上書きされる古い時刻情報を比較し、それが障害予測レベル定義テーブル（図５）で定義している「単位時間」より大きければ閾値を超えておらず、小さければ閾値を超えていると判断できるためである。
【００２３】
図９は、障害予測判定機構２０４のフローを示している。ステップ９０１では監視対象とする論理計算機のログを解析し、障害予測判定用状態管理テーブル（図７）の判定対象７０１となる事象が発生しているかどうかを解析する。判定対象であった場合は、障害予測レベル（カラム７０５）を参照してその事象の障害予測レベルを求める。求めた障害予測レベルに対して、障害予測レベル定義テーブル（図５）から障害予測判定の閾値（カラム５０２）を求める。本実施例では障害予測判定の閾値として、その事象の総累積回数（カラム５０３）または単位時間内の累積回数（カラム５０４）を用いている。従って、まず、障害予測判定用状態テーブル（図７）において、発生した事象に対応する、判定対象の状態（カラム７０６）の発生総累積（カラム７０７）に１を加算する。さらに、カラム７０９から事象に対応する発生時刻管理テーブル（図８）を求めて、図８の説明で記述した発生時刻管理テーブルの更新処理に従い、所定時間内の累積回数を得て、その値をカラム７０８に格納する。ステップ９０２で、発生総累積（カラム７０７）と所定時間内発生累積（カラム７０８）の両方あるいは片方が、障害予測レベル定義テーブル（図５）の総累積回数（カラム５０３）と単位時間内累積（カラム５０４）の閾値以上であるかどうかにより、切り替えの要否（カラム５０５）を判定する。切り替えが必要と判断された場合は、ステップ９０３で、障害予測レベル定義テーブル（図５）のカラム５０６に記述される条件を求める。この条件に記述される動作を実施し、満たせばステップ９０４のシステム切り替え処理を実行する。満たさなければそのまま処理を終了する。このとき、条件として、管理者の返答（許可を得る等）を必要とする場合は、適当にタイムアウトする時間を設定する。この障害予測判定機構は必ずしも論理計算機マネージャで動作させる必要がなく、論理計算機エージェントで障害予測を判定し、その結果を論理計算機マネージャに送付する形にしてもよい。
【００２４】
図１０は、システム切り替え機構２０５のフローを示している。ステップ１００１では、同時に複数の論理計算機でシステム切り替えを必要とする事象が発生した場合に、どの論理計算機のシステム切り替えを優先するかを判断する。この優先度の判定は、障害予測判定用状態管理テーブル（図７）における障害予測レベル７０５の高い事象（本実施例では）が発生している論理計算機を優先してもよいし、論理計算機毎に優先度を決めておいてもよいし、実行しているアプリケーションの重要度によって決めてもよい。論理計算機構成情報テーブルに、論理計算機の切り替え優先順位を付与した例を後述する（図１５）。システム切り替えの優先度の高い論理計算機があった場合は、ステップ１００２で、その論理計算機の切り替え終了まで待機する。他に優先度の高いシステム切り替え処理がなければ、ステップ１００３で新たな論理計算機（予備システム用）を生成する。予備論理計算機の作成が完了した時点で、ステップ１００４に進む。ステップ１００４では、論理計算機マネージャが切り替え元の論理計算機の論理計算機エージェントに対して、本番システムの一時停止と引継ぎ情報の退避を指令する。引継ぎ情報の例としては、Ｗｅｂサービスにおけるセッション情報や買い物リスト情報などが挙げられる。ステップ１００５で、論理計算機マネージャは、新たに作成した論理計算機に先に退避した情報を引き継がせ、システムのクローン（予備システム）を生成する。ステップ１００６で、予備システムを本番システムとして、本番システムのサービスを再開する。ステップ１００７で、旧本番システム用に使われていた論理計算機を消去して、処理を終了する。
【００２５】
図１１は、論理計算機エージェントにおける引継ぎ情報退避機構のフローである。ステップ１１０１で本番システムにおけるサービスを停止し、ステップ１１０２で引き継ぐべき情報を他の論理計算機からもアクセス可能な共有記憶域に格納し、処理を終了する。
【００２６】
図１５は、論理計算機構成情報テーブルを示している。この論理計算機構成情報テーブルには、生成された論理計算機に割り当てられた資源に関する情報が格納されている（カラム１５０２）。本実施例では切り替え優先順位（カラム１５０３）を追加している。これにより、もしも複数の論理計算機において同時に障害の事前予測がなされた場合にどの論理計算機を優先してシステム切り替えを実施するかを記述する。この切り替え優先順位は、論理計算機で動作するアプリケーションの重要度に応じて決定してもよい。
【００２７】
本実施例の効果は、ＯＳやアプリケーションが出力するログ・メッセージを解析して障害予測を行い、その判定に基づいて予備の論理計算機を新たに生成し、システムの切り替えを行うため、予備論理計算機をあらかじめ作成しておく必要がなく、これにより高信頼化を図りつつ計算機資源の有効活用が可能になることである。また、障害発生前にシステムの切り替えが行えるため、システム切り替えに伴うオーバーヘッドを小さくすることも可能になる。また、障害予測レベルごとに、切り替えの要否と切り替えるための条件を設定できることにより、多様な運用に対応することも可能になる。
【００２８】
［実施例２］
上記実施例では、ＯＳやアプリケーションが出力するログ・メッセージに基づき障害予測を行っているが、別の実施例で異なる観点での障害予測方法について述べる。
【００２９】
図１２は、論理計算機の稼働時間を監視することにより障害予測を行う、障害予測レベル定義テーブルの例である。障害予測判定の閾値として、論理計算機の稼動時間（カラム１２０１）を設定している。
【００３０】
計算機やアプリケーション・プログラムの稼働時間が延びると、計算機資源の管理の断片化や、ソフトウェアの欠陥に起因する使用可能資源量の減少により、処理時間が遅延したり、システム障害が発生する可能性が高まったりすることがある。本実施例は、そのようなケースにおいて、システムの定期的なリフレッシュが可能となる。
【００３１】
同様に、図１３は、アプリケーションのサービス内容を監視することにより障害予測を行う、障害予測レベル定義テーブルの例である。障害予測判定の閾値として、アプリケーションのサービス回数（カラム１３０１）や、アプリケーションの平均応答時間（カラム１３０２）を設定している。
【００３２】
上記図１２および図１３の例における、障害予測判定用状態管理テーブルの例を図１４に示している。評価対象（カラム７０１）としては、論理計算機の稼働時間、アプリケーションごと（本実施例ではＡＰ＃１から４）のサービス回数および平均応答時間を用いている。図１４では事象ごとに切り替えレベル（カラム７０３）を複数設定する例を示している。これにより、ある事象に対して段階的に動作を切り替える運用を可能にしている。また、前記実施例と同様、評価対象の状態（カラム７０４）が各々の評価対象における現在の状態を記述している。評価対象の状態（カラム７０４）の値が、図１２および図１３で示した障害予測レベル定義テーブルにおける閾値以上の値になったとき、システム切り替え等の動作を開始することになるのも前記実施例と同様である。
【００３３】
本実施例の効果は、論理計算機の稼働時間や、アプリケーションのサービス回数、平均応答時間を監視することにより、障害予測だけではなく、サービス・レベルの低下を事前に予測し、その防止が可能となることである。
【００３４】
【発明の効果】
本発明により、複数の論理計算機を利用したシステムの信頼性をシステム資源を無駄に消費することなく向上させることができる。
【図面の簡単な説明】
【図１】本発明の実施例１における全体構成図を示す。
【図２】本発明の実施例１における論理計算機マネージャと論理計算機エージェントの構成を示す。
【図３】本発明の実施例１における監視対象データ・テーブルを示す。
【図４】本発明の実施例１における監視対象データ採取機構のフローを示す。
【図５】本発明の実施例１における障害予測レベル定義テーブルを示す。
【図６】本発明の実施例１における障害予測判定用の項目を示す。
【図７】本発明の実施例１における障害予測判定用状態管理テーブルを示す。
【図８】本発明の実施例１における発生時刻管理テーブルを示す。
【図９】本発明の実施例１における障害予測判定機構のフローを示す。
【図１０】本発明の実施例１におけるシステム切り替え機構のフローを示す。
【図１１】本発明の実施例１における引継ぎ情報退避機構のフローを示す。
【図１２】本発明の実施例２の障害予測レベル定義テーブルを示す。
【図１３】本発明の実施例２の障害予測レベル定義テーブルを示す。
【図１４】本発明の実施例２の障害予測判定用状態管理テーブルを示す。
【図１５】本発明の実施例の論理計算機構成情報テーブルを示す。
【符号の説明】
１０１および１０２は論理計算機，１０３は論理計算機上で動作するＯＳおよびアプリケーション，１０５は論理計算機エージェント，１０６は論理計算機マネージャ，１０７は計算機資源分割機構，１０８は物理プロセッサ，１０９はディスク装置，１１０はネットワーク装置，１１１は物理計算機を示している。

Claims

第１の論理計算機上で稼動するプログラムの実行状態を監視する監視手段と、前記監視手段の状態から第１の論理計算機の障害の予兆を検知する検知手段と、障害の予兆が検出されると第２の論理計算機を生成し第１の論理計算機から第２の論理計算機に切り替える切替手段とを備えたことを特徴とする論理計算機システム。
前記監視手段はプログラムの実行に伴って出力する情報を監視することを特徴とする請求項１記載の論理計算機システム。
前記検知手段は前記監視手段で検出された情報の複数の特定の組み合わせ事象について障害予測レベルを設定する障害予測判定用状態管理テーブルを備えていることを特徴とする請求項２記載の論理計算機システム。
前記検知手段は更に前記障害予測判定用状態管理テーブルから求めた障害予測レベル毎に論理計算機の切替の要否を判定する前記事象の出現回数の閾値を有することを特徴とする請求項３記載の論理計算機システム。
前記検知手段は更に前記出現回数が前記閾値を超えたとき論理計算機の切替を行う条件を有していることを特徴とする請求項４記載の論理計算機システム。
前記監視手段はプログラムの実行上の異常を示す情報を監視することを特徴とする請求項１記載の論理計算機システム。
前記監視手段はあるアプリケーションプログラムでの応答時間を監視することを特徴とする請求項１記載の論理計算機システム。
前記監視手段は論理計算機上で稼動するプログラムの動作に伴って累積する統計情報を用いることを特徴とする請求項１記載の論理計算機システム。
第１の論理計算機上で稼動するプログラムの実行状態を監視し、前記監視手段の状態から第１の論理計算機の障害の予兆を検知し、障害の予兆が検出されると第２の論理計算機を生成し第１の論理計算機から第２の論理計算機に切り替えることを特徴とする論理計算機システムの構成制御方法。
論理計算機の信頼性を上げるため計算機を、第１の論理計算機上で稼動するプログラムの実行状態を監視する監視手段と、前記監視手段の状態から第１の論理計算機の障害の予兆を検知する検知手段と、障害の予兆が検出されると第２の論理計算機を生成し第１の論理計算機から第２の論理計算機に切り替える切替手段として機能させるための論理計算機システムの構成制御プログラム。