JPWO2013094006A1 - プログラム、情報処理装置および方法 - Google Patents

プログラム、情報処理装置および方法 Download PDF

Info

Publication number
JPWO2013094006A1
JPWO2013094006A1 JP2013549984A JP2013549984A JPWO2013094006A1 JP WO2013094006 A1 JPWO2013094006 A1 JP WO2013094006A1 JP 2013549984 A JP2013549984 A JP 2013549984A JP 2013549984 A JP2013549984 A JP 2013549984A JP WO2013094006 A1 JPWO2013094006 A1 JP WO2013094006A1
Authority
JP
Japan
Prior art keywords
server
evaluation value
computer
evaluation
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2013549984A
Other languages
English (en)
Other versions
JP5949780B2 (ja
Inventor
一人 櫻井
一人 櫻井
等 澤田
等 澤田
直広 田村
直広 田村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2013094006A1 publication Critical patent/JPWO2013094006A1/ja
Application granted granted Critical
Publication of JP5949780B2 publication Critical patent/JP5949780B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2041—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with more than one idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3031—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a motherboard or an expansion card
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3058—Monitoring arrangements for monitoring environmental properties or parameters of the computing system or of the computing system component, e.g. monitoring of power, currents, temperature, humidity, position, vibrations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

管理コンピュータは、冗長化システム中のアクティブな第１のコンピュータを含む、複数のコンピュータを管理する。管理コンピュータは、複数のコンピュータのそれぞれから、故障の発生に関連する複数の種類の現象についての情報を含む故障予兆情報を収集する。また、管理コンピュータは、冗長化システムにおいて第１のコンピュータと対応づけられている複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、評価値を算出する。評価値は、当該第２のコンピュータに将来故障が生じる蓋然性を示す。また、当該第２のコンピュータから収集された故障予兆情報と、複数のコンピュータのうち当該第２のコンピュータ以外の所定の１台以上のコンピュータから収集された故障予兆情報が、評価値の算出に用いられる。

Description

本発明は、高可用性コンピュータシステムに関する。
コンピュータシステムの可用性を高めるために、現用系と待機系を含む冗長化構成が採用されることがある。また、様々な冗長化システムが提案されており、冗長化システムに関して様々な研究が行われている。
例えば、ウォッチ・ドグ・タイマ（watchdog timer）方式により現用システムの正常性を監視する、情報処理システム監視装置が提案されている。当該情報処理システム監視装置は、ウォッチ・ドグ・タイマ方式により待機システムの正常性を監視する手段を有する。また、当該情報処理システム監視装置は、現用システムの故障により待機システムを現用に切り換えるように指示してから、所定の時間以内に、待機システムが現用システムとして立ち上がることを監視する手段も有する。
また、バックアップサーバを複数確保し、その複数のサーバに対する効果的なデータコピーを行うことで、より障害に強いシステムを実現することを目的として、次のような高可用性計算機システムも提案されている。
当該高可用性計算機システムには、ネットワーク接続される３台以上のサーバ（例えば第１〜第４のサーバ）が用意される。そして、これら３台以上のサーバのうち、優先順位に従ってマスタとなった第１のサーバは、スレーブサーバ（つまり第２〜第４のサーバ）との通信により、障害のあるサーバと障害のないサーバを探索する動作を定期的に行う。クライアントによりマスタサーバの持つファイルのデータが変更された場合、マスタサーバは、探索動作で見つけた障害のないサーバ（例えば第３と第４のサーバとする）に対し、変更されたデータのコピーを行う。
また、第３のサーバは、その時点で優先順位の最も高い第１のサーバから順位が低くなる方向に、マスタを探索する動作を定期的に行う。そして、マスタが見つけられなかった場合、第３のサーバは、障害のないサーバの中で第３のサーバ自身の優先順位が最も高いならば、新たにマスタとなる。第４のサーバも第３のサーバと同様に動作する。
ほかにも、例えば、性能要件とともに信頼性も考慮してサーバの動的配備を行うためのサーバ配備方法も提案されている。
具体的には、予備サーバ群の動作状態が、サーバ管理手段によって監視され、サーバ管理情報としてサーバ管理情報記憶手段に格納される。また、管理対象の各システムに関する需要予測データが取得されると、配備期間把握手段が、需要予測データに基づいて、各システムに予備サーバの配備が必要となる動的配備期間を把握する。
そして、配備サーバ候補選択手段が、動的配備期間とサーバ管理情報とに基づき、動的配備期間に故障の可能性が高いものを除外して配備サーバ候補を選択する。また、配備サーバ決定手段が、動的配備期間に要求される配備要件を満たすことができる配備サーバ候補を選択し、選択した配備サーバ候補を配備サーバに決定する。
さらに、マルチコアプロセッサ環境において、高信頼／高可用化を実現することを目的とした、高信頼化方法も提案されている。
具体的には、複数のマルチコアプロセッサからなるシステムに、プロセッサと、プロセッサが有するコアとを管理するテーブルが設けられる。そして、仮想サーバの生成時において、異なるプロセッサのコアを用いて、単一の仮想サーバが構成される。また、プロセッサが有するコアの数に応じて、プロセッサの数は可変とされる。そして、プロセッサの障害予兆が検出された場合に、障害の予兆を検出したプロセッサには仮想化機構の実行スケジュールを渡さないように制御される。
また、複数のマルチコアプロセッサからなるシステムにおいて、オペレーティングシステムのプロセスまたはスレッドの処理に、複数の異なるプロセッサが有する演算コアが割り当てられる。また、複数のマルチコアプロセッサからなるシステムにおいて、オペレーティングシステムに、複数の異なるプロセッサが有する演算コアが割り当てられる。
特開昭６２−４９４４６号公報 特開２００１−４３１０５号公報 国際公開ＷＯ２００８／０４１３０２号公報 特開２００８−１５２５９４号公報
ある種に冗長化システムでは、アクティブな第１のコンピュータに故障が生じた場合に備えて、複数の第２のコンピュータが設けられる。そして、第１のコンピュータに故障が生じると、第１のコンピュータから第２のコンピュータのうちの１台へのフェイルオーバ（failover）またはスイッチオーバ（switchover）が行われる。
ここで、複数の第２のコンピュータ間で、故障が将来発生する蓋然性が異なる可能性がある。もし、第１のコンピュータから、故障が発生する蓋然性の高い第２のコンピュータへのフェイルオーバまたはスイッチオーバが行われると、フェイルオーバまたはスイッチオーバから短い時間しか経たないうちに、別の故障が発生するかもしれない。その結果、再度フェイルオーバまたはスイッチオーバが必要になるかもしれない。しかし、頻繁なフェイルオーバまたはスイッチオーバは、冗長化システムの可用性を低下させるので、好ましくない。
よって、複数の第２のコンピュータの中から、故障が将来発生する蓋然性の低い１台を選ぶことが好ましい。ところが、ある１台の第２のコンピュータに故障が将来発生する蓋然性を、当該第２のコンピュータ自体の現在の状態だけから正確に評価することは、難しい。なぜなら、当該第２のコンピュータには、当該第２のコンピュータ自体に起因する故障が発生する可能性があるだけでなく、周囲の環境に起因する故障が発生する可能性もあるからである。
本発明は、１つの側面では、第２のコンピュータに故障が将来発生する蓋然性の評価の正確性を高める技術を提供することを目的とする。
一態様により提供されるプログラムは、管理コンピュータに処理を実行させる。管理コンピュータは、冗長化システム中のアクティブな第１のコンピュータを含む、複数のコンピュータを管理する。
前記処理は、前記複数のコンピュータのそれぞれから、故障の発生に関連する複数の種類の現象についての情報を含む故障予兆情報を収集することを含む。
さらに、前記処理は、前記冗長化システムにおいて前記第１のコンピュータと対応づけられている複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、評価値を算出することを含む。前記評価値は、当該第２のコンピュータに将来故障が生じる蓋然性を示す。また、前記評価値の算出には、当該第２のコンピュータから収集した前記故障予兆情報と、前記複数のコンピュータのうち当該第２のコンピュータ以外の所定の１台以上のコンピュータから収集した前記故障予兆情報が用いられる。
上記プログラムによれば、第２のコンピュータに故障が将来発生する蓋然性の評価の正確性を高めることができる。
第１〜第５実施形態の概要を説明するフローチャートである。 管理サーバと、管理サーバが管理する複数のコンピュータの例を示す図である。 コンピュータのハードウェア構成図である。 フェイルオーバ処理のフローチャートである。 フェイルオーバ処理の別のフローチャートである。 各種定数の例を示す図である。 管理ＤＢに含まれるサーバテーブルとシャーシテーブルの例を示す図である。 管理ＤＢに含まれるイベント管理テーブルの例を示す図（その１）である。 第１実施形態での総合評価処理のフローチャートである。 第１実施形態での各種評価値が記録される、管理ＤＢ内の結果テーブルを示す図である。 温度評価処理のフローチャート（その１）である。 温度評価処理のフローチャート（その２）である。 温度評価処理のフローチャート（その３）である。 電圧評価処理のフローチャート（その１）である。 電圧評価処理のフローチャート（その２）である。 第２実施形態での総合評価処理のフローチャートである。 劣化評価処理のフローチャート（その１）である。 劣化評価処理のフローチャート（その２）である。 管理ＤＢに含まれるイベント管理テーブルの例を示す図（その２）である。 第２実施形態での各種評価値が記録される、管理ＤＢ内の結果テーブルを示す図である。 第３実施形態での総合評価処理のフローチャートである。 時刻評価処理のフローチャートである。 第３実施形態での各種評価値が記録される、管理ＤＢ内の結果テーブルを示す図である。 第４実施形態での総合評価処理のフローチャートである。 第４実施形態での各種評価値が記録される、管理ＤＢ内の結果テーブルを示す図である。 第５実施形態で使われるＧＵＩ（Graphical User Interface）の例を示す図である。
以下、いくつかの実施形態について、図面を参照しながら詳細に説明する。具体的には、図１〜７を参照して、第１〜第５実施形態の概要について説明する。その後、図８〜１２Ｂを参照して、第１実施形態について説明し、図１３〜１６を参照して、第２実施形態について説明する。また、図１７〜１９を参照して、第３実施形態について説明し、図２０〜２１を参照して、第４実施形態について説明する。さらに、図２２を参照して、第５実施形態について説明する。最後に、その他の変形例についても説明する。
図１は、第１〜第５実施形態の概要を説明するフローチャートである。図１の処理は、管理コンピュータによって実行される。管理コンピュータは、冗長化システム中のアクティブな第１のコンピュータ（以下では「アクティブサーバ」ともいう）を含む、複数のコンピュータを管理する。以下では、管理コンピュータを「管理サーバ」ともいう。
冗長化システムにおいては、複数の第２のコンピュータ（以下では「スタンバイサーバ」ともいう）が、第１のコンピュータと対応づけられている。第１のコンピュータに故障（failure）が発生した場合には、対応づけに基づいて、第１のコンピュータから、ある１台の第２のコンピュータへのフェイルオーバまたはスイッチオーバが行われる。
冗長化システムのアーキテクチャに応じて、ホットスタンバイとコールドスタンバイのいずれの方式が採用されてもよい。コールドスタンバイ方式が採用される場合、スタンバイサーバは、アクティブサーバが正常な間は、アクティブサーバが実行する処理とは無関係な他のタスクを実行していてもよい。
なお、管理サーバが管理する上記複数のコンピュータの中には、上記冗長化システムには含まれないコンピュータが含まれていてもよい。例えば、上記冗長化システムと他の１つ以上のシステムを含む複数のシステムで使われる複数のコンピュータが、同じデータセンタ内に設置されていてもよい。あるいは、複数のシステムで使われる複数のコンピュータが、複数のデータセンタに地理的に分散されていてもよい。そして、管理サーバは、１つまたは複数のデータセンタ内の全コンピュータを管理してもよい。
例えば、管理サーバは、以下のような第１〜第３のシステム用のコンピュータすべてを管理してもよい。
・第１のシステム用の複数のコンピュータは、第１と第２のデータセンタに分散している。例えば、第１のシステムのアクティブサーバは、第１のデータセンタにあり、第１のシステムのスタンバイサーバの一部は、第１のデータセンタにあり、残りのスタンバイサーバは、第２のデータセンタにあってもよい。
・第２のシステム用の複数のコンピュータは、すべて第２のデータセンタ内に設置されている。
・第３のシステム用の複数のコンピュータは、第１と第３のデータセンタに分散している。
図１の処理は、具体的には、管理サーバが管理する上記複数のコンピュータのそれぞれから情報を収集する処理と、上記の複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、評価値を算出する処理を含む。
以下では、管理サーバにより収集される上記の情報を、説明の便宜上、「故障予兆情報」（failure-predictive information）ともいう。故障予兆情報は、故障の発生に関連する複数の種類の現象についての情報を含む。複数の種類の現象の中には、具体的には、温度に関する現象と、電圧に関する現象が含まれていることが好ましい。
また、ある第２のコンピュータについて管理サーバにより算出される評価値は、具体的には、当該第２のコンピュータに将来故障が生じる蓋然性を示す。管理サーバは、以下の双方の故障予兆情報を用いて、評価値を算出する。
・評価対象の当該第２のコンピュータから収集した、故障予兆情報。
・管理サーバが管理する上記の複数のコンピュータのうち、評価対象の当該第２のコンピュータ以外の、所定の１台以上のコンピュータから収集した、故障予兆情報。
故障予兆情報を収集する処理の例として、図１にはステップＳ１０２〜Ｓ１０４が例示されている。また、評価値を算出する処理の例として、図１にはステップＳ１０７が例示されている。以下では、図１中の各ステップについて、より具体的に説明する。
ステップＳ１０１に示すように、管理サーバは、所定の種類のイベントのいずれかが生じるまで、待機する。
そして、管理サーバの管理するいずれかのコンピュータから、管理サーバが故障予兆情報を受信すると、図１の処理はステップＳ１０２へと移行する。
また、管理サーバは、故障予兆情報を収集するために、管理サーバが管理する複数のコンピュータをポーリングしてもよい。ポーリングの時刻は、個々のコンピュータごとに異なっていてもよい。逆に、管理サーバが管理する全コンピュータについてポーリングの時刻が共通でもよい。いずれにせよ、管理サーバがポーリングを実行する時刻（つまり予定された時刻）になると、図１の処理は、ステップＳ１０３へと移行する。
また、管理サーバは、上記のとおり、１台以上の第２のコンピュータのそれぞれについて評価値を算出する。評価値を算出するためのトリガになり得るイベントの例として、図１には、次の３つのイベントが例示されている。
・アクティブサーバに故障が発生した、というイベント。
・評価値を算出する時刻になった、というイベント。
・評価値の算出をユーザに指示された、というイベント。
これら３つのイベントのいずれかが発生すると、図１の処理は、ステップＳ１０５へと移行する。
なお、管理サーバが複数のコンピュータから故障予兆情報を収集する方法は、実施形態に応じて任意である。図１には、以下の２つの方法が例示されているが、これら２つの方法のうち、一方のみが採用されてもよい。
・管理サーバが、能動的にポーリングを実行する方法。
・管理サーバが、管理対象のコンピュータから、受動的に故障予兆情報を受信する方法。
また、管理サーバが評価値を算出するタイミングも、実施形態に応じて任意である。図１には、評価値の算出のトリガになり得る３種類のイベントを例示したが、評価値を算出するためのトリガとなり得るイベントとして、これら３種類のイベントのうちの一部のみが採用されてもよい。
さて、ステップＳ１０２で管理サーバは、受信した故障予兆情報を適宜の記憶装置に格納する。そして、図１の処理はステップＳ１０１へ戻る。
また、ステップＳ１０３で管理サーバは、ポーリングする対象の１台または複数台のコンピュータのそれぞれに、問い合わせを送信する。
そして、次のステップＳ１０４で管理サーバは、各問い合わせに対する応答として、故障予兆情報を受信する。管理サーバは、受信した故障予兆情報を、ステップＳ１０２と同様に、適宜の記憶装置に格納する。そして、図１の処理はステップＳ１０１へ戻る。
また、ステップＳ１０５で管理サーバは、評価対象のスタンバイサーバを１台、選択する。例えば、アクティブサーバに対応付けられた複数のスタンバイサーバのすべてが、評価対象であってもよい。この場合、管理サーバは、アクティブサーバに対応付けられた複数のスタンバイサーバから、順に１台のスタンバイサーバを選択してもよい。
あるいは、ユーザから、評価対象の１台以上のスタンバイサーバが指定されてもよい。この場合、管理サーバは、指定された１台以上のスタンバイサーバから、順に１台のスタンバイサーバを選択してもよい。
次のステップＳ１０６で管理サーバは、ステップＳ１０５で選択したスタンバイサーバについての評価値を算出する。上記のとおり、評価値の算出において管理サーバは、選択したスタンバイサーバ自体から収集した故障予兆情報だけでなく、選択したスタンバイサーバとは別の所定の１台以上のコンピュータから収集した故障予兆情報も用いる。なお、上記の「所定の１台以上のコンピュータ」は、評価対象として選択されたスタンバイサーバに関連する、周囲の他の１台以上のサーバである。
例えば、温度の異常は故障の発生に関連する。そして、ある１台のコンピュータが何らかの原因により異常に高温になると、当該コンピュータと物理的に近い位置に設置されているコンピュータも、高温にさらされ得る。換言すれば、評価対象のスタンバイサーバと物理的に近い位置に設置されている他のコンピュータは、評価対象のスタンバイサーバにおける故障の発生に影響を及ぼすことがある。
そこで、評価対象のスタンバイサーバと物理的に近い位置に設置されている１台または複数台のコンピュータが上記の「所定の１台以上のコンピュータ」に含まれていることが好ましい。なお、上記の説明では「物理的に近い位置」と述べたが、「ある２台のコンピュータが互いに物理的に近い位置に設置されているか否か」ということは、実施形態に応じて適宜定義されてよい。また、詳しくは後述するが、複数のレベルの近さが定義されてもよい。
また、電圧の異常も故障の発生に関連する。そして、ある１台のコンピュータで電圧の異常が発生している場合、当該コンピュータ自体に起因して異常が発生している可能性もあるし、当該コンピュータに電力を供給する外部の電源ユニットに異常が発生している可能性もある。
もし、外部の電源ユニットに異常が発生しているとすると、当該電源ユニットに直接的にまたは間接的に接続されている他のコンピュータにおいても、電圧異常が発生する可能性があり、ひいては故障が発生する可能性がある。そこで、評価対象のスタンバイサーバと同じ電源ユニットを共有している他の１台または複数台のコンピュータが上記の「所定の１台以上のコンピュータ」に含まれていることが好ましい。
例えば上記のように、評価対象のスタンバイサーバが設置された位置との間の物理的な近さや、評価対象のスタンバイサーバが接続されている電源ユニットに応じて、適宜、上記の「所定の１台以上のコンピュータ」は定義される。したがって、ステップＳ１０６で管理サーバは、評価対象のスタンバイサーバおよび上記の「所定の１台以上のコンピュータ」から収集した故障予兆情報を用いて、評価値を算出する。なお、以下では説明の便宜上、評価値が低いほど、当該評価値は、将来故障が発生する蓋然性が低いことを示すものとする。
次に、ステップＳ１０７で管理サーバは、評価対象の他のスタンバイサーバがまだあるか否かを判断する。もし、評価対象の他のスタンバイサーバがまだあれば、図１の処理はステップＳ１０５に戻る。逆に、評価対象の他のスタンバイサーバがもうなければ、図１の処理はステップＳ１０８に移行する。
なお、ステップＳ１０７での判断は、ステップＳ１０６で算出された評価値に依存していてもよい。例えば、管理サーバは、所定の閾値以下の評価値が得られるまで、ステップＳ１０５〜Ｓ１０７の処理を繰り返し実行してもよい。
あるいは、アクティブサーバに対応づけられているスタンバイサーバの台数をＮとすると（Ｎ＞１）、Ｎ個の評価値のうち低い方からＭ位以内（１≦Ｍ＜Ｎ）の評価値が見つかるまで、管理サーバは、ステップＳ１０５〜Ｓ１０７の処理を繰り返し実行してもよい。例えば、Ｎ＝５かつＭ＝２の場合、管理サーバは、４（＝Ｎ−Ｍ＋１）台以上のスタンバイサーバについてそれぞれ評価値を算出すれば、低い方から２位以内の評価値を見つけることができる。
もちろん、ステップＳ１０７での判断は、ステップＳ１０６で算出された評価値に依存していなくてもよい。例えば、Ｎ台のスタンバイサーバすべてについて評価値を算出することが予め決められていてもよい。
さて、ステップＳ１０８で管理サーバは、適宜の処理を実行する。適宜の処理の実行後、図１の処理はステップＳ１０１に戻る。
例えば、アクティブサーバにおける故障の発生に応じて、管理サーバが、Ｎ台のスタンバイサーバについてそれぞれ評価値を算出する場合がある。この場合、ステップＳ１０８で管理サーバは、アクティブサーバから、評価値が最も低いスタンバイサーバへの、フェイルオーバを実行してもよい。
また、フェイルオーバによって新たなアクティブサーバとなるサーバは、評価値が最も低いスタンバイサーバでなくてもよい。フェイルオーバ制御部４は、決められた基準が示すある蓋然性以下の蓋然性を示す値が評価値として算出された１台のスタンバイサーバを、アクティブサーバと交代するスタンバイサーバとして選択してもよい。
上記基準は、評価値に関する所定の閾値により決められていてもよい。例えば、フェイルオーバ制御部４は、所定の閾値以下の評価値が算出された１台のスタンバイサーバを、新たなアクティブサーバとして選択してもよい。
あるいは、上記基準は、複数のスタンバイサーバの中での評価値の相対的順序に関して決められていてもよい。例えば、フェイルオーバ制御部４は、Ｎ個の評価値のうち低い方からＭ位以内（１≦Ｍ＜Ｎ）の評価値が算出された１台のスタンバイサーバを、新たなアクティブサーバとして選択してもよい。
あるいは、予め決められた時刻に、管理サーバが、Ｎ台のスタンバイサーバについてそれぞれ評価値を算出する場合がある。この場合、ステップＳ１０８で管理サーバは、単に、算出済みのＮ個の評価値を、適宜の記憶装置に格納してもよい。
また、ユーザからの指示に応じて、管理サーバが、１台または複数台のスタンバイサーバについてそれぞれ評価値を算出する場合がある。この場合、ステップＳ１０８で管理サーバは、評価値をディスプレイなどの出力装置に出力してもよい。
以上、図１を参照して説明したように、管理サーバは、複数のコンピュータからそれぞれ故障予兆情報を収集し、適宜のタイミングで１台または複数台のスタンバイサーバについてそれぞれ評価値を算出する。そして、評価値の算出には、評価対象のスタンバイサーバ自体から収集された故障予兆情報だけでなく、評価対象のスタンバイサーバにおける将来の故障の発生と関連する周辺の他のコンピュータから収集された故障予兆情報も用いられる。よって、管理サーバは、評価対象のスタンバイサーバの周辺の環境も考慮に入れて、スタンバイサーバに将来故障が発生する蓋然性を、より正確に評価することができる。
さて、図２は、管理サーバと、管理サーバが管理する複数のコンピュータの例を示す図である。図１のように動作する管理サーバは、具体的には、図２に示した管理サーバ１のように構成されていてもよい。
また、上記のとおり、管理サーバ１が管理する複数のコンピュータの中には、ある１つの冗長化システムにおけるアクティブサーバと、当該アクティブサーバに対応づけられた複数のスタンバイサーバだけでなく、他のコンピュータがさらに含まれていてもよい。しかし、以下では簡単化のため、管理サーバ１が、図２の７台のサーバ３０−１〜３０−７を管理する場合を例として、説明を行う。
管理サーバ１は、故障予兆情報やその他の情報を収集する収集部２と、評価値を算出する算出部３と、フェイルオーバを制御するフェイルオーバ制御部４を有する。管理サーバ１はさらに、収集部２が収集した情報と、算出部３が算出した結果を格納する管理ＤＢ（database）５を有する。管理ＤＢ５に含まれるテーブルの具体例は、後述する。
また、第１〜第５実施形態において算出部３は、温度評価部３ａと電圧評価部３ｂと総合評価部３ｃを有する。図２にはさらに劣化評価部３ｄと時刻評価部３ｅが図示されているが、実施形態によっては、劣化評価部３ｄと時刻評価部３ｅは省略されてもよい。具体的には、下記の第２実施形態、第４実施形態、および第５実施形態では、算出部３が劣化評価部３ｄを含み、第３〜第５実施形態では、算出部３が時刻評価部３ｅを含む。
温度評価部３ａは、温度に関する現象についての故障予兆情報を用いて、温度が故障の発生に与える影響を評価する。電圧評価部３ｂは、電圧に関する現象についての故障予兆情報を用いて、電圧が故障の発生に与える影響を評価する。劣化評価部３ｄは、いくつかの種類の故障予兆情報を用いて、経年劣化（degradation over time）が故障の発生に与える影響を評価する。時刻評価部３ｅは、いくつかの種類の故障予兆情報を用いて、特定の時間帯における故障の発生のしやすさを評価する。
総合評価部３ｃは、少なくとも温度評価部３ａと電圧評価部３ｂによる評価結果を用いて、総合的な評価値を算出することが好ましい。図１のステップＳ１０６で算出される評価値は、具体的には、最終的に総合評価部３ｃによって算出される値である。実施形態に応じて、総合評価部３ｃは、劣化評価部３ｄによる評価結果と時刻評価部３ｅによる評価結果の一方または双方を、さらに評価値の算出に用いてもよい。
システム管理者などのユーザに対するユーザインタフェイスは、管理サーバ１の不図示の入出力装置により提供されてもよい。あるいは、管理サーバ１は、図２に示すように、適宜のネットワーク（例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、またはそれらの任意の組み合わせ）を介して、クライアント６と接続されていてもよい。そして、クライアント６によってユーザインタフェイスが提供されてもよい。クライアント６は、例えば、入出力装置を有するＰＣ（Personal Computer）であってもよい。
ところで、図２には３台のラック１０−１〜１０−３が例示されている。ラック１０−１には、ラック管理装置１１−１と電源ユニット１２−１が搭載されている。同様に、ラック１０−２には、ラック管理装置１１−２と電源ユニット１２−２が搭載されており、ラック１０−３には、ラック管理装置１１−３と電源ユニット１２−３が搭載されている。ラック１０−１〜１０−３の各々は、さらに、不図示のその他の装置（例えば、ファンやＬＡＮスイッチなど）を含んでいてもよい。
また、ラック１０−１には、複数のブレード型サーバ（blade servers）を収容するためのシャーシ（chassis）２０−１が搭載されている。ラック１０−２にも、類似のシャーシ２０−２が搭載されている。
シャーシ２０−１は、シャーシ管理装置２１−１とＬＡＮスイッチ２２−１を含み、さらに２つの電源ユニット２３−１と２３−２を含む。また、シャーシ２０−２は、シャーシ管理装置２１−２とＬＡＮスイッチ２２−２を含み、さらに１つの電源ユニット２３−３を含む。なお、図２では紙幅の都合上、電源ユニット（Power Supply Unit）２３−１と２３−２は、「ＰＳＵ」と略されている。
シャーシ２０−１には、ブレード型サーバを搭載するための５つのスロットがある。図２の例では、１番目のスロットにサーバ３０−１が搭載されており、４番目のスロットにサーバ３０−２が搭載されており、５番目のスロットにサーバ３０−３が搭載されている。そして、サーバ３０−１はサーバ管理装置３１−１を有し、サーバ３０−２はサーバ管理装置３１−２を有し、サーバ３０−３はサーバ管理装置３１−３を有する。未使用の２番目と３番目のスロットには、図２では斜線が引かれている。
また、シャーシ２０−１においては、１番目のスロットに搭載されたサーバ３０−１には電源ユニット２３−１から電力が供給され、４番目と５番目のスロットにそれぞれ搭載されたサーバ３０−２と３０−３には、電源ユニット２３−２から電力が供給される。もし２番目のスロットにサーバが搭載された場合は、当該サーバには電源ユニット２３−１から電力が供給される。また、もし３番目のスロットにサーバが搭載された場合は、当該サーバには電源ユニット２３−２から電力が供給される。
シャーシ２０−２にも、ブレード型サーバを搭載するための５つのスロットがある。図２の例では、シャーシ２０−２の１番目と２番目と５番目のスロットは使われていない。３番目のスロットにサーバ３０−４が搭載されており、４番目のスロットにサーバ３０−５が搭載されている。また、サーバ３０−４はサーバ管理装置３１−４を有し、サーバ３０−５はサーバ管理装置３１−５を有する。なお、シャーシ２０−２においては、どのスロットに搭載されたサーバにも、電源ユニット２３−３から電力が供給される。
ところで、図２の例では、ラック１０−１に１台のシャーシ２０−１のみが搭載されているが、ラック１０−１には、さらにシャーシまたはラックマウント型サーバを搭載するためのスペースがある。ラック１０−１に搭載される各装置には、電源ユニット１２−１から、必要に応じて配電ユニット（ＰＤＵ：Power Distribution Unit）を介して、電力が供給される。したがって、シャーシ２０−１内のサーバ３０−１〜３０−３には、間接的には電源ユニット１２−１から電力が供給される。
同様に、図２の例では、ラック１０−２に１台のシャーシ２０−２のみが搭載されているが、ラック１０−２には、さらにシャーシまたはラックマウント型サーバ（rack-mount server）を搭載するためのスペースがある。ラック１０−２に搭載される各装置には、電源ユニット１２−２から、必要に応じて配電ユニットを介して、電力が供給される。したがって、シャーシ２０−２内のサーバ３０−４〜３０−５には、間接的には電源ユニット１２−２から電力が供給される。
また、ラック１０−３には、２台のラックマウント型サーバ３０−６と３０−７が搭載されている。そして、サーバ３０−６はサーバ管理装置３１−６を有し、サーバ３０−７はサーバ管理装置３１−７を有する。ラック１０−３にも、さらにシャーシまたはラックマウント型サーバを搭載するためのスペースがある。ラック１０−３に搭載される各装置には、電源ユニット１２−３から、必要に応じて配電ユニットを介して、電力が供給される。
ところで、ラック管理装置１１−１〜１１−３、ＬＡＮスイッチ２２−１〜２１−２、およびラックマウント型サーバ３０−６〜３０−７は、ネットワークを介して管理サーバ１に接続されている。また、シャーシ２０−１内のシャーシ管理装置２１−１とサーバ３０−１〜３０−３は、ＬＡＮスイッチ２２−１に接続されている。同様に、シャーシ２０−２内のシャーシ管理装置２１−２とサーバ３０−４〜３０−５は、ＬＡＮスイッチ２２−２に接続されている。
したがって、管理サーバ１は、ラック管理装置１１−１〜１１−３、シャーシ管理装置２１−１〜２１−２、およびサーバ管理装置３１−１〜３１−７と、ネットワークを介して通信することができる。
管理サーバ１の収集部２は、ネットワークを介した通信により、ラック管理装置１１−１〜１１−３、シャーシ管理装置２１−１〜２１−２、およびサーバ管理装置３１−１〜３１−７から、各種情報を収集する。収集部２が収集する情報の詳細は、管理ＤＢ５の詳細とともに後述する。
なお、収集部２による情報の収集は、適宜のプロトコルにしたがって行われる。例えば、収集部２による情報の収集に利用可能な技術の例として、以下の技術が挙げられる（もちろん、収集部２は、他のプロトコル（あるいは他のインタフェイス）にしたがって各種情報を収集してもよい）。
・ＳＮＭＰ（Simple Network Management Protocol）
・ＩＰＭＩ（Intelligent Platform Management Interface）
・ＳＭＡＳＨ（Systems Management Architecture for Server Hardware）
また、管理サーバ１のフェイルオーバ制御部４は、ネットワークを介して、サーバ３０−１〜３０−７と通信することができる。したがって、フェイルオーバ制御部４は、ネットワークを介して、サーバ３０−１〜３０−７間でのフェイルオーバを制御することができる。
具体的には、図２の例では、管理サーバ１が管理する冗長化システムは、７台のサーバ３０−１〜３０−７を含む。説明の便宜上、以下では、「サーバ３０−１がアクティブサーバとして稼働中である」と仮定する。すなわち、サーバ３０−２〜３０−７は、アクティブサーバとしてのサーバ３０−１と対応づけられたスタンバイサーバである。
もし、アクティブサーバであるサーバ３０−１に故障が発生すると、フェイルオーバ制御部４は、算出部３によって算出される評価値に基づいて、サーバ３０−２〜３０−７の中から適切な１台のサーバを選択する。そして、フェイルオーバ制御部４は、故障したサーバ３０−１から選択したサーバへのフェイルオーバを、ネットワークを介して制御する。
なお、フェイルオーバ制御部４がフェイルオーバの要否を判断するために、収集部２が収集した情報が使われてもよい。つまり、フェイルオーバ制御部４は、アクティブサーバ３０−１に故障が発生したか否かを、アクティブサーバ３０−１から収集部２が収集した情報に基づいて判断してもよい。
ところで、図２の管理サーバ１、クライアント６、およびサーバ３０−１〜３０−７は、いずれもコンピュータ（すなわち情報処理装置）の１種であり、例えば図３のコンピュータ１００のように構成されていてもよい。図３は、コンピュータのハードウェア構成図である。
コンピュータ１００は、プロセッサの１種であるＣＰＵ（Central Processing Unit）１０１と、ＲＡＭ（Random Access Memory）１０２と、ネットワークインタフェイス１０３を有する。ネットワークインタフェイス１０３は、例えば、有線ＬＡＮインタフェイス、無線ＬＡＮインタフェイス、またはその組み合わせである。ネットワークインタフェイス１０３は、具体的には、外付けのＮＩＣ（Network Interface Card）でもよいし、オンボード型のネットワークインタフェイスコントローラでもよい。
コンピュータ１００は、さらに入力装置１０４と出力装置１０５を有していてもよい。入力装置１０４の例は、キーボードや、ポインティングデバイスなどである。ポインティングデバイスは、例えば、マウスでもよいしタッチスクリーンでもよい。出力装置１０５の例は、ディスプレイやスピーカなどである。ディスプレイはタッチスクリーンであってもよい。
また、コンピュータ１００は、不揮発性記憶装置１０６を有する。不揮発性記憶装置１０６の例は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid-State Drive）などである。
コンピュータ１００は、さらに、コンピュータ読み取り可能な記憶媒体１０９の駆動装置１０７を有していてもよい。記憶媒体１０９の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、磁気ディスク、フラッシュメモリなどの半導体メモリカードなどである。
なお、コンピュータ１００内の各部は、バス１０８を介して互いに接続されている。また、コンピュータ１００は、ネットワークインタフェイス１０３を介してネットワーク１１０に接続されている。
コンピュータ１００は、ＣＰＵ１０１が適宜のプログラムを実行することにより適宜に動作する。例えば、図２の管理サーバ１を実現するコンピュータ１００においては、ＣＰＵ１０１が、図１の処理のためのプログラムを実行する。
ＣＰＵ１０１は、プログラムをＲＡＭ１０２にロードし、ＲＡＭ１０２をワーキングエリアとしても利用しながら、プログラムを実行する。ＣＰＵ１０１が実行するプログラムは、予め不揮発性記憶装置１０６にインストールされていてもよい。
あるいは、プログラムは、記憶媒体１０９に格納されて提供され、記憶媒体１０９から駆動装置１０７により読み取られて不揮発性記憶装置１０６にコピーされ、その後、ＲＡＭ１０２にロードされてもよい。または、ネットワーク１１０上のプログラム提供者１１１（例えばコンピュータ１００とは別のコンピュータ）から、ネットワーク１１０とネットワークインタフェイス１０３を介して、プログラムがコンピュータ１００にダウンロードされてもよい。
なお、ＲＡＭ１０２と不揮発性記憶装置１０６と記憶媒体１０９は、いずれも、有形の（tangible）記憶媒体であり、信号搬送波のような一時的な（transitory）媒体ではない。
ところで、図２の管理サーバ１が図３のコンピュータ１００により実現される場合、収集部２は、ネットワークインタフェイス１０３を介した通信を含む処理を実行するＣＰＵ１０１により、実現される。同様に、フェイルオーバ制御部４も、ネットワークインタフェイス１０３を介した通信を含む処理を実行するＣＰＵ１０１により、実現される。算出部３は、ＣＰＵ１０１により実現される。また、管理ＤＢ５は、ＲＡＭ１０２、不揮発性記憶装置１０６、またはその双方により、実現される。
続いて、図１に概要を示した処理の具体例について、フローチャートおよび各種テーブルの例を参照しながら説明する。
図４は、フェイルオーバ処理のフローチャートであり、図５は、フェイルオーバ処理の別のフローチャートである。第１〜第５実施形態では、アクティブサーバに故障が発生すると、図４または図５にしたがって、フェイルオーバが行われる。また、収集部２が収集する情報に基づいて、フェイルオーバ制御部４はアクティブサーバにおける故障の発生を認識することができる。
さて、ステップＳ２０１でフェイルオーバ制御部４は、アクティブサーバに対応付けられた複数のスタンバイサーバの中に、ステップＳ２０２〜Ｓ２０３の処理対象としてまだ選択していないスタンバイサーバが残っているか否かを判断する。そして、未選択のスタンバイサーバがまだ残っていれば、図４の処理はステップＳ２０２へと移行する。逆に、アクティブサーバに対応づけられたすべてのスタンバイサーバが選択済みならば、図４の処理はステップＳ２０４へと移行する。
例えば、図２の例では、サーバ３０−１がアクティブサーバであり、サーバ３０−２〜３０−７がスタンバイサーバである。よって、フェイルオーバ制御部４は、サーバ３０−２〜３０−７の中に未選択のサーバが残っているか否かを判断する。
そして、ステップＳ２０２でフェイルオーバ制御部４は、未選択のスタンバイサーバを１つ選択する。また、次のステップＳ２０３でフェイルオーバ制御部４は、選択したスタンバイサーバについて評価値を算出するよう、算出部３に指示する。
なお、詳しくは図７とともに後述するが、管理サーバ１が管理する冗長化システム内のサーバ３０−１〜３０−７の各々には、ＩＤ（identifier）が予め割り当てられている。よって、ステップＳ２０３でフェイルオーバ制御部４は、選択したスタンバイサーバのＩＤを算出部３に引数として渡すことで、評価対象のサーバを算出部３に通知してもよい。
フェイルオーバ制御部４からの指示に応じて、ステップＳ２０３で算出部３は、指定されたＩＤのスタンバイサーバについて評価値を算出する。ステップＳ２０３は図１のステップＳ１０６に対応する。
図２に関して説明したように、第１〜第５実施形態においては、算出部３の総合評価部３ｃは、少なくとも温度評価部３ａと電圧評価部３ｂによる評価結果を用いて、評価値を算出する。以下では説明の便宜上、温度評価部３ａ、電圧評価部３ｂ、および総合評価部３ｃがそれぞれ算出する値を、「温度評価値」、「電圧評価値」、および「総合評価値」という。
また、第２実施形態と第４実施形態と第５実施形態では、劣化評価部３ｄによる評価も行われ、第３〜第５実施形態では時刻評価部３ｅによる評価も行われる。以下では説明の便宜上、劣化評価部３ｄと時刻評価部３ｅがそれぞれ算出する値を、「劣化評価値」と「時刻評価値」という。
図４のステップＳ２０３の総合評価処理の詳細は、実施形態に応じて異なる。総合評価処理の詳細については、図９、１３、１７、および２０とともに後述する。なお、第１〜第５実施形態では、総合評価部３ｃは、算出した総合評価値を管理ＤＢ５に記録する。総合評価値の管理ＤＢ５への記録の後、図４の処理はステップＳ２０１へと戻る。
ところで、図１のステップＳ１０６に関して述べた仮定より、総合評価値が低いほど、将来故障が発生する蓋然性が低い。よって、二次故障を避けるためには、総合評価値が最も低いスタンバイサーバへのフェイルオーバが望ましい。
そこで、全スタンバイサーバについて、総合評価値が算出されて管理ＤＢ５に記録された後、ステップＳ２０４でフェイルオーバ制御部４は、管理ＤＢ５を参照することで、総合評価値が最も低いスタンバイサーバを認識する。フェイルオーバ制御部４は、総合評価値が最も低いスタンバイサーバを探すために、総合評価値をソートキーとするソート処理を実行してもよい。
あるいは、ステップＳ２０３で総合評価部３ｃが、管理ＤＢ５に記録済みの総合評価値と新たに算出した総合評価値とを比較して、新たに算出した総合評価値を適切な位置に挿入してもよい。すると、ステップＳ２０４の実行時点では、算出された総合評価値がソートされた状態で管理ＤＢ５に記録されている。よって、ステップＳ２０４でフェイルオーバ制御部４は、ソート済みのデータを参照することで、総合評価値が最も低いスタンバイサーバを認識することができる。
いずれにせよ、ステップＳ２０４でフェイルオーバ制御部４は、総合評価値が最も低いスタンバイサーバへのフェイルオーバを実行する。例えば、サーバ３０−２〜３０−７の中でサーバ３０−７の総合評価値が最も低い場合、フェイルオーバ制御部４は、サーバ３０−７に、アクティブサーバとして動作を開始するよう、ネットワークを介して命令する。そして、図４のフェイルオーバ処理は終了する。なお、ステップＳ２０４は図１のステップＳ１０８の一例である。
ところで、上記のとおり、フェイルオーバ処理は、図５にしたがって実行されてもよい。図４のフェイルオーバ処理によれば、アクティブサーバに故障が発生してから各スタンバイサーバについて総合評価値が算出されるが、総合評価値は、予め算出されて管理ＤＢ５に記録されていてもよい。例えば、算出部３は、「１時間に１回、各スタンバイサーバについて総合評価値を算出する」などの所定のスケジュールにしたがって、総合評価値を算出し、算出した総合評価値を管理ＤＢ５に格納してもよい。
すると、アクティブサーバに実際に故障が発生した場合には、フェイルオーバ制御部４は、各スタンバイサーバについて算出済みの総合評価値を管理ＤＢ５から取得することができる。よって、フェイルオーバ制御部４は、複数のスタンバイサーバそれぞれについて取得した総合評価値に基づいて、適切な１台のスタンバイサーバを選択することができる。
具体的には、図５のステップＳ３０１でフェイルオーバ制御部４は、アクティブサーバに対応付けられた複数のスタンバイサーバの中に、ステップＳ３０２〜Ｓ３０４の処理対象としてまだ選択していないスタンバイサーバが残っているか否かを判断する。そして、未選択のスタンバイサーバがまだ残っていれば、図５の処理はステップＳ３０２へと移行する。逆に、アクティブサーバに対応づけられたすべてのスタンバイサーバが選択済みならば、図５の処理はステップＳ３０５へと移行する。ステップＳ３０１はステップＳ２０１と類似である。
そして、ステップＳ３０２でフェイルオーバ制御部４は、未選択のスタンバイサーバを１つ選択する。また、次のステップＳ３０３でフェイルオーバ制御部４は、選択したスタンバイサーバについて算出済みの総合評価値を、管理ＤＢ５から取得する。フェイルオーバ制御部４は、取得した総合評価値を、選択したスタンバイサーバのＩＤと対応づけて、一時的にＲＡＭ１０２上に記憶する。
次のステップＳ３０４でフェイルオーバ制御部４は、取得済みの総合評価値をソートする。そして、処理はステップＳ３０１に戻る。
ステップＳ３０１〜Ｓ３０４の繰り返しにより、上記のようにＲＡＭ１０２上に次々と総合評価値が記憶される。よって、ステップＳ３０４の処理がｎ回目（ｎ≧１）に実行されるときには、取得済みのｎ個の総合評価値が、それぞれスタンバイサーバのＩＤと対応づけられて、ＲＡＭ１０２上に記憶されている。フェイルオーバ制御部４は、取得済みのｎ個の総合評価値をステップＳ３０４でソートする。
以上のようにして、全スタンバイサーバについて逐次的に総合評価値が取得された後、ステップＳ３０５でフェイルオーバ制御部４は、総合評価値が最も低いスタンバイサーバへのフェイルオーバを実行する。なお、ステップＳ３０４におけるソート処理の結果として、ステップＳ３０５の実行時には、全スタンバイサーバの総合評価値は既にソートされている。よって、フェイルオーバ制御部４は、総合評価値が最も低いスタンバイサーバ（すなわち、二次故障が発生する蓋然性が最も低いスタンバイサーバ）を認識することができる。
ステップＳ３０５も、図４のステップＳ２０４と同様に、図１のステップＳ１０８の一例である。総合評価値が最も低いスタンバイサーバに、アクティブサーバとして動作を開始するようにフェイルオーバ制御部４が命令した後、図５の処理は終了する。
ところで、総合評価値の具体的な算出方法は、上記のとおり実施形態に応じて異なる。以下では総合評価値の算出に関して、数式を参照することがある。そこで、後述の数式で使われる定数の例について、先に図６を参照して説明する。
図６には、係数２０１と重み２０２が、便宜上テーブル形式で例示されている。しかし、係数２０１と重み２０２は、例えば、算出部３を実現するためにＣＰＵ１０１が実行するプログラムに、固定的な定数として定義されていてもよい。
あるいは、係数２０１と重み２０２は、ユーザ定義可能な定数であってもよい。その場合、ユーザによって指定された係数２０１と重み２０２が、不図示の設定ファイルに適宜の形式で記録されていてもよい。設定ファイルは、管理サーバ１の不揮発性記憶装置１０６に格納される。もちろん、管理ＤＢ５が、ユーザ定義可能な係数２０１と重み２０２を記憶するためのテーブルを含んでいてもよい。
図６の係数２０１のテーブルの各行には、各係数に便宜上つけた名前と、後述の数式において当該係数を表す記号と、当該係数の例示的な値が示されている。
自己係数Ｃｓｅｌｆは、評価対象のスタンバイサーバ自体に発生中の異常が、当該スタンバイサーバでの将来の故障の発生にどれくらい影響するかを示す。他方、隣接係数Ｃａｄｊ、シャーシ係数Ｃｃｈｓｓｉｓ、およびラック係数Ｃｒａｃｋは、評価対象のスタンバイサーバの周辺の他のコンピュータに発生中の異常が、評価対象のスタンバイサーバでの将来の故障の発生にどれくらい影響するかを示す。また、同一電源係数Ｃｐｏｗｅｒは、評価対象のスタンバイサーバの周辺の他のコンピュータに発生中の異常から推測される故障要因（具体的には電源ユニットの異常）が、評価対象のスタンバイサーバでの将来の故障の発生にどれくらい影響するかを示す。
なお、異常にはいくつかのレベルがある。例えば、あるサーバに軽微な異常が発生した場合、サーバはしばらくすると回復することがある。また、異常が軽微ならば、異常が継続している間も、サーバは所望の機能を提供し続けられることがある。つまり、たとえ異常な現象が発生していても、「サーバが提供する機能」という観点から見れば、「故障が発生していない」と言える場合がある。
例えば、２つの閾値Ｔｈ１とＴｈ２（Ｔｈ１＜Ｔｈ２）により、正常な電圧の範囲が定義されている場合、閾値Ｔｈ１未満の電圧は異常な電圧であり、閾値Ｔｈ２を超える電圧も異常な電圧である。しかし、実際の電圧が正常な電圧の範囲からどの程度逸脱しているかに応じて、故障（すなわち、サーバが所望の機能を提供することのできない状態）が発生することもあるし、故障の発生に至らないこともある。
よって、仮に評価対象のスタンバイサーバ自体に異常が発生中であっても、評価対象のスタンバイサーバに将来故障が必ず発生するとは限らない。しかし、現在何らかの異常が発生しているサーバに将来故障が発生する蓋然性は、現在何の異常も発生していないサーバに将来故障が発生する蓋然性よりも高いと考えられる。よって、総合評価値には、評価対象のスタンバイサーバに発生中の異常の影響が反映される。自己係数Ｃｓｅｌｆは、その影響の度合を示すパラメタである。
同様に、評価対象のスタンバイサーバと関連する他のサーバに異常が発生中の場合、評価対象のスタンバイサーバに将来故障が必ず発生するとは限らない。しかし、評価対象のスタンバイサーバに将来故障が発生する蓋然性は、周囲のサーバに何の異常も発生していない場合よりも、周囲のサーバで何らかの異常が発生している場合の方が高いと考えられる。よって、総合評価値には、評価対象のスタンバイサーバの周囲の他のサーバに発生中の異常の影響が反映される。隣接係数Ｃａｄｊ、シャーシ係数Ｃｃｈｓｓｉｓ、ラック係数Ｃｒａｃｋ、および同一電源係数Ｃｐｏｗｅｒは、その影響の度合を示すパラメタである。
なお、周囲のサーバとは、換言すれば、図１に関して説明した「所定の１台以上のコンピュータ」（つまり、評価対象のスタンバイサーバに関する評価値の算出のために故障予兆情報が使われる、他の１台以上のコンピュータ）のことである。例えば、評価対象のスタンバイサーバがブレード型サーバの場合、評価対象のスタンバイサーバと同じシャーシ内にある他のサーバ（特に、シャーシ内で評価対象のスタンバイサーバに隣接するサーバ）は、評価対象のスタンバイサーバと関連する周囲のサーバの例である。また、評価対象のスタンバイサーバと同じラック内にある他のサーバや、評価対象のスタンバイサーバと電源ユニットを共有している他のサーバも、評価対象のスタンバイサーバと関連する周囲のサーバの例である。
また、第２実施形態と第４実施形態と第５実施形態では、劣化評価部３ｄが劣化評価値を算出する。電源投入係数Ｃｏｎ、経年劣化係数Ｃｏｆｆ、温度依存劣化係数ＣｄｇｒＴｍｐｒ、および電圧依存劣化係数ＣｄｇｒＯｖｅｒｖｏｌは、劣化評価値の算出に使われる。詳しくは後述するが、これらの係数は、将来故障が発生する蓋然性が各種の経年劣化によって高まる度合を示す。
そして、第３〜第５実施形態では、時刻評価部３ｅが時刻評価値を算出する。１ヶ月係数Ｃｏｎｅ、２ヶ月係数Ｃｔｗｏ、および３ヶ月係数Ｃｔｈｒｅｅは、時刻評価値の算出に使われる。
詳しくは後述するが、時刻評価部３ｅは、１日の中のある特定の時間帯における過去の異常の発生の履歴に基づいて、当該特定の時間帯に将来故障が発生する蓋然性を評価する。その評価結果が時刻評価値である。１ヶ月係数Ｃｏｎｅ、２ヶ月係数Ｃｔｗｏ、および３ヶ月係数Ｃｔｈｒｅｅは、当該特定の時間帯に将来故障が発生する蓋然性が、過去の履歴とどれくらい関連するのかを示す。
また、補正定数εは、総合評価部３ｃが総合評価値を算出する際に用いる定数である。補正定数εは、０による除算を防ぐために使われる、正の小さな値である。
さて、図６の重み２０２のテーブルの各行には、各重みの説明と、後述の数式において当該重みを表す記号と、当該重みに対応する異常のレベルと、当該重みの例示的な値が示されている。上記のとおり異常にはいくつかのレベルがあるが、以下では説明の便宜上、３つの異常のレベルがあるものとする。
具体的には、「レベル１」は軽微な異常に対応し、重みＷ１は軽微な異常の重みである。また、「レベル２」は重大な異常に対応し、重みＷ２は重大な異常の重みである。そして、「レベル３」は非常に重大な異常に対応し、重みＷ３は非常に重大な異常の重みである。
なお、数式の簡素化のため、正常な状態に対応する「レベル０」がさらに定義される。重みＷ０は正常を示し、重みＷ０の値は０である。また、図６に例示するとおり、異常のレベルが高いほど、重みの値も大きい。
続いて、各種評価値について、図６に例示した係数２０１と重み２０２および数式を用いて詳しく説明する。以下の数式で表される評価値は、具体的には、算出部３が後述のフローチャートにしたがって動作することにより、算出される。
以下では説明の便宜上、評価対象のサーバをｓｉとする。また、温度評価部３ａが算出するサーバｓｉの温度評価値をｆｔｍｐｒ（ｓｉ）とする。第１〜第５実施形態では、具体的には、式（１）の温度評価値ｆｔｍｐｒ（ｓｉ）が算出される。
Figure 2013094006
式（１）における係数Ｃｓｅｌｆ、Ｃａｄｊ、Ｃｃｈａｓｓｉｓ、およびＣｒａｃｋの値は、例えば図６に例示した値でもよい。これらの係数は、式（２）の関係を満たす。式（２）の関係は、サーバｓｉ以外の周囲の１台以上のサーバから収集された故障予兆情報よりも、サーバｓｉ自体から収集された故障予兆情報の方に重きを置いて、サーバｓｉの評価値が算出されることを意味する。
Figure 2013094006
ここで、式（１）中の重みｗｔｍｐｒ（ｓｉ）とｗｔｍｐｒ（ｓｊ）は、式（３）により定義される。また、式（３）中の重みＷ０〜Ｗ３の値の具体例が図６に例示されており、これらの重みＷ０〜Ｗ３は式（４）の関係を満たす。
Figure 2013094006
Figure 2013094006
また、式（１）における集合ａｄｊ（ｓｉ）、ｃｈａｓｓｉｓ（ｓｉ）、およびｒａｃｋ（ｓｉ）は、式（５）〜（７）により定義される。
Figure 2013094006
Figure 2013094006
Figure 2013094006
なお、式（５）と（６）の定義より、サーバｓｉがラックマウント型サーバの場合は、集合ａｄｊ（ｓｉ）は空集合であり、集合ｃｈａｓｓｉｓ（ｓｉ）も空集合である。
また、式（１）〜（７）から明らかなとおり、式（１）において、第１項は、サーバｓｉ自体で現在発生中の温度異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
サーバｓｉがラックマウント型サーバの場合、第２項と第３項はいずれも０である。
サーバｓｉがブレード型サーバの場合、第２項は、１つのシャーシ内でサーバｓｉに隣接するサーバｓｊで現在発生中の温度異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。また、サーバｓｉがブレード型サーバの場合、第３項は、サーバｓｉと同じシャーシ内にあるがサーバｓｉと隣接はしない他のサーバｓｊで現在発生中の温度異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
そして、第４項は、サーバｓｉと同じラック内にある他のサーバｓｊ（ただし、サーバｓｉがブレード型サーバの場合、サーバｓｉと同じシャーシ内にある他のサーバは除く）で現在発生中の温度異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
さて、電圧評価部３ｂが算出する電圧評価値をｆｖｏｌ（ｓｉ）とする。第１〜第５実施形態では、具体的には、式（８）の電圧評価値ｆｖｏｌ（ｓｉ）が算出される。
Figure 2013094006
式（８）における係数ＣｓｅｌｆとＣｐｏｗｅｒの値は、例えば図６に例示した値でもよい。これらの係数は、式（９）の関係を満たす。式（９）の関係は、サーバｓｉ以外の周囲の１台以上のサーバから収集された故障予兆情報よりも、サーバｓｉ自体から収集された故障予兆情報の方に重きを置いて、サーバｓｉの評価値が算出されることを意味する。
Figure 2013094006
ここで、式（８）中の重みｗｖｏｌ（ｓｉ）とｗｖｏｌ（ｓｊ）は、式（１０）により定義される。式（１０）中の重みＷ０〜Ｗ３は、前述のとおり、式（４）の関係を満たす。
Figure 2013094006
また、式（８）における集合ｐｏｗｅｒ（ｓｉ）は、式（１１）により定義される。
Figure 2013094006
なお、ラックマウント型サーバは、ラック内の電源ユニットから直接的に電力を供給されるかもしれないが、ブレード型サーバは、ラック内の電源ユニットから間接的に（すなわち、シャーシ内の電源ユニットを介して）電力を供給されるかもしれない。しかし、式（１１）の定義では、簡単化のため、直接的な電力供給と間接的な電力供給は区別されていない。
また、式（８）〜（１１）から明らかなとおり、式（８）において、第１項は、サーバｓｉ自体の電圧異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。また、第２項は、サーバｓｉと同じ電源ユニットを使う他のサーバｓｊにおける電圧異常から推測される当該電源ユニットの異常が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
さて、劣化評価部３ｄが算出する劣化評価値をｆｄｇｒ（ｓｉ）とする。第２、第４、および第５実施形態では、具体的には、式（１２）の劣化評価値ｆｄｇｒ（ｓｉ）が算出される
Figure 2013094006
式（１２）における係数ＣｏｎとＣｏｆｆの値は、例えば図６に例示した値でもよい。
なお、式（１２）において、関数ｔｏｎ（ｓｉ）は、今までにサーバｓｉに電源が投入されていた時間の合計の長さを示す。また、関数ｔｏｆｆ（ｓｉ）は、今までにサーバｓｉに電源が投入されていなかった時間の合計の長さを示す。
つまり、式（１２）の第１項は、たとえサーバｓｉが正常に動作するだけでも、時間の経過につれてサーバｓｉが劣化していくことに対応する。第１項は、そのような経年劣化が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
また、式（１２）の第２項は、たとえサーバｓｉに電源が入れられていなくても（つまり、たとえサーバｓｉが何も処理を実行しなくても）、時間の経過につれてサーバｓｉが劣化していくことに対応する。第２項は、そのような経年劣化が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
式（１２）の第３項と第４項は、式（１３）と（１４）により定義される。
Figure 2013094006
Figure 2013094006
式（１３）と（１４）における定数Ｌは、異常のレベルの数である。図６の例では、Ｌ＝３である。もちろん、実施形態に応じて、定数Ｌの値は、１でもよいし、２でもよいし、４以上でもよい。
また、式（１３）における関数ｔｔｍｐｒ（ｓｉ，ｈ）は、今までにサーバｓｉでレベルｈの温度異常が続いた時間の合計の長さを示す。そして、式（１４）における関数ｔｏｖｅｒｖｏｌ（ｓｉ，ｈ）は、今までにサーバｓｉでレベルｈの電圧超過が続いた時間の合計の長さを示す。
例えば、今までにサーバｓｉでレベル１の温度異常が２回発生したことがあったとし、１回目の温度異常は２時間続いたとし、２回目の温度異常は０．５時間続いたとする。この場合、関数ｔｔｍｐｒ（ｓｉ，１）の値は、２．５である。
サーバｓｉ自体に温度異常が発生した場合におけるサーバｓｉの劣化は、サーバｓｉが正常な場合におけるサーバｓｉの劣化よりも大きい。そして、劣化が大きいほど、サーバｓｉに将来故障が発生する蓋然性も高まる。式（１３）は、温度異常に起因する追加的な劣化が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
また、電圧異常には、電圧低下（undervoltage）と電圧超過（overvoltage）の２種類があるが、電圧超過の方が電圧低下よりも劣化に与える影響が大きい。式（１２）と（１４）は、「電圧低下に起因して、通常の経年劣化よりもさらに劣化が進む程度は、無視してもかまわない程度である」という前提に基づいている。
換言すれば、サーバｓｉに電圧低下が発生した場合におけるーバｓｉの劣化は、サーバｓｉが正常な場合におけるサーバｓｉの劣化とほぼ同じである。よって、劣化評価部３ｄは、劣化評価値ｆｄｇｒ（ｓｉ）の算出において、電源低下に起因する追加的な劣化を考慮しなくてもよい。
他方、サーバｓｉに電圧超過が発生した場合におけるサーバｓｉの劣化は、サーバｓｉが正常な場合におけるサーバｓｉの劣化よりも大きい。そして、劣化が大きいほど、サーバｓｉに将来故障が発生する蓋然性も高まる。式（１４）は、電圧超過に起因する追加的な劣化が、サーバｓｉにおける将来の故障の発生に与える影響を示す。
もちろん、実施形態によっては、電源低下に起因する追加的な劣化をさらに考慮に入れるため、式（１２）が変形されてもよい。すなわち、劣化評価部３ｄは、変形された式にしたがって劣化評価値を算出してもよい。
なお、上記の式（１３）と（１４）における温度依存劣化係数ＣｄｇｒＴｍｐｒと電圧依存劣化係数ＣｄｇｒＯｖｅｒｖｏｌの値は、例えば図６に例示した値でもよい。そして、式（１２）〜（１４）の各係数は、式（１５）の関係を満たす。
Figure 2013094006
ところで、第２、第４、および第５実施形態は、劣化評価部３ｄが、式（１２）以外の式にしたがって劣化評価値を算出するように、変形されてもよい。
例えば、評価対象のサーバｓｉの周囲のサーバで異常が発生すると、当該異常がサーバｓｉの劣化に影響を与えることがあり得る。例えば、近傍のサーバが異常な高温になっていれば、近傍のサーバからの熱の影響で、サーバｓｉの劣化が進むことがあり得る。
よって、劣化評価部３ｄは、周囲のサーバに発生する異常に起因して間接的にサーバｓｉに生じる劣化を考慮に入れてもよい。具体的には、劣化評価部３ｄは、式（１２）の代わりに式（１６）にしたがって、劣化評価値を算出してもよい。
Figure 2013094006
式（１６）の右辺の第５項は、周囲のサーバからの間接的な影響を示し、具体的には式（１７）により定義されてもよい。実施形態によっては、式（１７）の右辺第１項と第２項のいずれか一方が省略されてもよい。また、式（１７）の詳細は、式（１８）と（１９）のとおりであってもよい。
Figure 2013094006
Figure 2013094006
Figure 2013094006
なお、式（１７）中の係数ＣｉｎｄｉｒＴｍｐｒは、式（１３）の係数ＣｄｇｒＴｍｐｒよりも小さな適宜の正の値を持つ。また、式（１７）中の係数ＣｉｎｄｒＯｖｅｒｖｏｌは、式（１４）の係数ＣｄｇｒＯｖｅｒｖｏｌよりも小さな適宜の正の値を持つ。式（１７）〜（１９）中のその他の各種係数や関数は、既に説明したものばかりである。
また、他の変形例では、劣化評価部３ｄが式（１２）の代わりに式（２０）または（２１）にしたがって、劣化評価値を算出してもよい。
Figure 2013094006
Figure 2013094006
式（２０）と（２１）は、次のような考察に基づく。評価対象のサーバｓｉと同じモデルの他のサーバで異常が発生しやすい場合は、サーバｓｉでも異常が発生する蓋然性が高いと推測される。あるモデルのサーバで異常が発生しやすい原因としては、当該モデルの設計に何らかの不適切な点があることも考えられるし、当該モデルが既に古くなっていることも考えられる。モデル自体の設計には特に問題がなくても、古いモデルのサーバは、既に長期間にわたって運用され続けている蓋然性が高い。したがって、古いモデルのサーバにおける経年劣化は、比較的大きいと推測される。
つまり、あるモデルのサーバで異常が発生しやすい原因が、上記２つの原因のどちらであるにせよ、「もし、サーバｓｉと同じモデルの他のサーバで異常が発生しやすいならば、サーバｓｉに異常が発生する蓋然性も高い」と推測される。そして、異常が発生しやすければ、故障も発生しやすい。よって、同じモデルの他のサーバでの異常の発生のしやすさを考慮に入れるため、劣化評価部３ｄは、式（２０）または（２１）にしたがって、劣化評価値を算出してもよい。
式（２０）と（２１）中の評価関数ｆｍｏｄｅｌ（ｓｉ）は、サーバｓｉと同じモデルの他のサーバでの異常の発生のしやすさを示し、具体的には、例えば式（２２）により定義される。
Figure 2013094006
なお、式（２２）中の係数Ｃｍｏｄｅｌは、図６には例示されていないが、適宜の正の係数である。また、式（２２）中の関数ｔｖｏｌ（ｓｉ，ｈ）は、今までにサーバｓｉでレベルｈの電圧異常（すなわち電圧超過または電圧低下）が続いた時間の合計の長さを示す。
また、式（２２）における集合ｍｏｄｅｌ（ｓｉ）は式（２３）により定義される。
Figure 2013094006
モデルごとに集合ｍｏｄｅｌ（ｓｉ）の要素数は異なり得るので、式（２２）は、正規化のために、集合ｍｏｄｅｌ（ｓｉ）の要素数による除算を含む。なお、もし集合ｍｏｄｅｌ（ｓｉ）が空集合の場合は、評価関数ｆｍｏｄｅｌ（ｓｉ）は、０と定義される。
ところで、図５に関して説明したように、総合評価値は、アクティブサーバでの故障の発生とは関係なく、定期的に予め算出されて管理ＤＢ５などに記録されていてもよい。その場合、総合評価値の算出に使われた他の評価値（例えば温度評価値など）も、あわせて記録されていてもよい。
温度評価値と電圧評価値は、算出される時点における状況を反映している。よって、温度評価値と電圧評価値は、算出されるたびに、単純に上書きされる。時刻評価値も、同様に、算出されるたびに、単純に上書きされる。
他方、劣化評価値は、他の種類の評価値と同様に、単純な上書きにより更新されることもあるが、さらに、適宜更新されてもよい。具体的には、以下のいずれかの場合に、劣化評価部３ｄは、式（２４）にしたがって、記録されている劣化評価値ｆｄｇｒ（ｓｉ）を更新してもよい。
・サーバｓｉから既存の部品が取り除かれたとき。
・サーバｓｉに新たな部品が取り付けられたとき。
・サーバｓｉの既存の部品が新たな部品に交換されたとき。
Figure 2013094006
式（２４）において、右辺の劣化評価値ｆｄｇｒ（ｓｉ）は、以前の劣化評価値（つまり記録済みの劣化評価値）であり、左辺の劣化評価値ｆｄｇｒ（ｓｉ）は、更新後の新たな劣化評価値である。また、式（２４）中の本体係数Ｃｂｏｄｙは、図６では省略されているが、適宜の正の係数である。本体係数Ｃｂｏｄｙは、サーバｓｉ本体に含まれていてしかも着脱不能な部品の影響を示す。
式（２４）中の関数ｒｅｐｌａｃｅｄ（ｓｉ）は、サーバｓｉにおいて今回交換された部品の個数を示す。例えば、既存の２枚の拡張カードが新たな２枚の拡張カードに交換された場合、関数ｒｅｐｌａｃｅｄ（ｓｉ）の値は２である。
式（２４）中の関数ｉｎｃｄｅｃ（ｓｉ）は、サーバｓｉにおいて今回増えたか減った部品の個数を示す。例えば、既存の１枚のＮＩＣがサーバｓｉから取り除かれた場合、関数ｉｎｃｄｅｃ（ｓｉ）の値は１である。あるいは、新たな３枚のメモリモジュールがサーバｓｉに取り付けられた場合、関数ｉｎｃｄｅｃ（ｓｉ）の値は３である。
式（２４）中の関数ｒｅｍｏｖａｂｌｅ（ｓｉ）は、着脱可能な部品を最大でいくつまでサーバｓｉに搭載することが可能かを示す。なお、着脱可能な部品の例は、メモリモジュール、ＣＰＵ、ＮＩＣやＨＢＡ（Host Bus Adapter）などのインタフェイスカード、その他の種類の拡張カード、電源ユニット、ファン、ＨＤＤなどである。
関数ｒｅｐｌａｃｅｄ（ｓｉ）、ｉｎｃｄｅｃ（ｓｉ）、およびｒｅｍｏｖａｂｌｅ（ｓｉ）の以上の定義から明らかなように、式（２５）の関係が成立する。
Figure 2013094006
ところで、式（２４）の右辺において旧・劣化評価値に掛けられる被乗数の値は、０より大きく、１より小さい。なぜなら、本体係数Ｃｂｏｄｙが正であり、式（２５）の関係が成立するからである。
つまり、式（２４）にしたがって劣化評価部３ｄが行う劣化評価値の更新は、「部品の交換、追加、または削除によって、サーバｓｉに将来故障が発生する蓋然性が下がるだろう」という予測を示す。このような予測の根拠は次のとおりである。
古い既存の部品が新しい部品に交換される場合は、異常の発生しやすい部品が異常の発生しにくい部品に交換される場合である、と見なせる。よって、この場合、経年劣化に起因する故障がサーバｓｉに将来発生する蓋然性は、下がると予測される。
また、単に古い既存の部品がサーバｓｉから取り除かれる場合は、異常の発生しやすい部品の数が減る場合である、と見なせる。よって、この場合、サーバｓｉ全体としては、経年劣化に起因する異常が発生しにくくなり、ひいては故障も発生しにくくなると予測される。
そして、新たな部品がサーバｓｉに追加される場合は、サーバｓｉを構成する複数の部品に占める、異常の発生しにくい部品の割合が高まる場合である、と見なせる。よって、この場合も、サーバｓｉ全体としては、経年劣化に起因する異常が発生しにくくなり、ひいては故障も発生しにくくなると予測される。
以上のような考察に基づいて、劣化評価部３ｄは、例えば式（２４）にしたがって劣化評価値を更新してもよい。もちろん、実施形態によっては、サーバｓｉにおける部品の交換、追加、または削除の際に、劣化評価部３ｄが式（２４）以外の適宜の式にしたがって劣化評価値を更新してもよい。
ところで、時刻評価部３ｅが算出する時刻評価値をｆｔｉｍｅ（ｓｉ，ｐ）とすると、第３〜第５実施形態では、具体的には式（２６）の時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）が算出される。
Figure 2013094006
式（２６）の時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）の第２引数ｐは、１日の中のある時間帯を示す。時間帯ｐは、算出部３により時刻評価部３ｅに対して指定されてもよいし、現在時刻に基づいて時刻評価部３ｅにより決定されてもよい。例えば、時間帯ｐは、「午前９時から午前１０時までの１時間」という時間帯でもよい。時間帯ｐの長さは実施形態に応じて任意である。
時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）は、１日の中のある時間帯ｐにサーバｓｉに故障が発生する蓋然性を示す。ある種の状況下では、サーバｓｉの電圧は、ある特定の時間帯ｐに不安定になりやすいかもしれないし、サーバｓｉの温度は、ある特定の時間帯ｐに上昇しやすいかもしれない。そのため、ある特定の時間帯ｐにサーバｓｉにおいて故障が発生しやすいかもしれない。
上記の「ある種の状況」の例は、例えば、以下のような状況である。
・サーバｓｉは、コールドスタンバイ方式の冗長化システムにおけるスタンバイサーバである。
・アクティブサーバが正常な間、スタンバイサーバｓｉは、アクティブサーバが実行する処理とは無関係な、他のサービスを提供するために使われる。
・スタンバイサーバｓｉが提供するサービスに対して、ある特定の時間帯ｐに集中して、大量のアクセスがある。
例えば上記のような状況下では、故障の起きやすさが時刻に依存することがある。時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）は、時刻に依存する故障の起きやすさを、過去の履歴に基づいて表す。
式（２６）中に現れる関数ｆｒｅｑｍｏｎｔｈｌｙ（ｓｉ，ｈ，ｍ，ｐ）は、サーバｓｉにおいて最近ｍヶ月以内に時間帯ｐの少なくとも一部において発生中だった、レベルｈの異常の頻度を示す。なお、ある日発生した異常が、翌日以降まで継続することもあり得る。この場合、当該異常の頻度は、簡単のために「１回」とカウントされてもよいし、より精密な予測を期すために日ごとに別々にカウントされてもよい。
例えば、２０１１年１０月１日９時３０分に発生した異常が２０１１年１０月３日１１時まで継続したと仮定する。また、時間帯ｐが、午前９時から午前１０時までの１時間であると仮定する。
この場合、当該異常の頻度は「３回」とカウントされてもよい。なぜなら、当該異常が継続している時間帯は、２０１１年１０月１日の時間帯ｐとも重なっており、２０１１年１０月２日の時間帯ｐとも重なっており、２０１１年１０月３日の時間帯ｐとも重なっているからである。
なお、式（２６）における係数Ｃｏｎｅ、Ｃｔｗｏ、およびＣｔｈｒｅｅの値は、例えば図６に例示した値でもよい。これらの係数は、式（２７）の関係を満たす。式（２７）の関係は、将来故障が生じる蓋然性の評価においては、古い履歴よりも新しい履歴の方に重きが置かれることを意味する。
Figure 2013094006
ところで、第３〜第５実施形態は、時刻評価部３ｅが式（２６）以外の式にしたがって時刻評価値を算出するように、変形されてもよい。例えば、式（２６）の粒度は１ヶ月ごとだが、別の粒度（例えば、１週間ごとの粒度、または１日ごとの粒度）で、時刻評価値が算出されてもよい。また、式（２６）で注目される異常の範囲は、「最近３ヶ月以内」という範囲だが、実施形態に応じて範囲も任意に設定可能である。例えば、時刻評価部３ｅは、式（２８）にしたがって時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）を算出してもよい。
Figure 2013094006
式（２８）におけるインデックス変数ｄは、日付を示す。また、時刻評価部３ｅが時刻評価値を算出する当日をＴｏｄａｙとする。式（２８）中の日付Ｏｌｄｅｓｔは、時刻評価値の算出において考慮される履歴の範囲を規定する日付であり、実施形態に応じて任意に決められてよい。
式（２８）中に現れる関数ｆｒｅｑｄａｙｌｙ（ｓｉ，ｈ，ｄ，ｐ）は、サーバｓｉにおいて、日付ｄに、時間帯ｐの少なくとも一部において発生中だった、レベルｈの異常の頻度を示す。例えば、ある日ｄの時間帯ｐには、レベルｈの温度異常とレベルｈの電圧異常の双方が発生するかもしれない。この場合、関数ｆｒｅｑｄａｙｌｙ（ｓｉ，ｈ，ｄ，ｐ）の値は、２である。
また、式（２８）中に現れる関数ｇ（ｘ）は、０以上の任意のｘに対して０以上の値を返す単調減少関数であれば、どのような関数であってもよい。
ところで、総合評価部３ｃは、第１実施形態では式（２９）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出し、第２実施形態では式（３０）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。また、総合評価部３ｃは、第３実施形態では式（３１）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出し、第４〜第５実施形態では式（３２）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。
Figure 2013094006
Figure 2013094006
Figure 2013094006
Figure 2013094006
なお、式（２９）〜（３２）中の関数ｆｔｏｔ（ｓｉ）は、温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）の重み付け和である。重み付けは、サーバｓｉでの温度異常の発生しやすさと、サーバｓｉでの電圧異常の発生しやすさに依存する。
換言すれば、関数ｆｔｏｔ（ｓｉ）は、以下の２つの値に依存する。
・温度に関する現象（具体的には温度異常）に関連する故障の、サーバｓｉにおける発生のしやすさを示す値。
・電圧に関する現象（具体的には電圧低下または電圧超過）に関連する故障の、サーバｓｉにおける発生のしやすさを示す値。
上記２つの値は、具体的には、サーバｓｉ自体から収集された故障予兆情報に応じて得られる値であり、サーバｓｉで過去に発生した温度異常と電圧異常の履歴に基づく。重みづけにより、温度異常が発生しやすいサーバに関しては温度評価値が重視され、逆に、電圧異常が発生しやすいサーバに関しては電圧評価値が重視される。なお、関数ｆｔｏｔ（ｓｉ）のさらなる詳細は、式（３４）〜（３８）とともに後述する。
また、式（３１）と（３２）中の定数Ｎｏｗは、総合評価部３ｃが総合評価値を算出する時点を示す。そして、関数ｐｅｒｉｏｄ（Ｎｏｗ）は、時点Ｎｏｗを含む適宜の時間帯を示す。関数ｐｅｒｉｏｄ（Ｎｏｗ）は、例えば、時点Ｎｏｗを含む長さ１時間の期間でもよい。
ところで、式（２９）〜（３２）を一般化すると、式（３３）が得られる。３つの係数Ｃｔｏｔ、Ｃｄｇｒ、およびＣｔｉｍｅは、０以上の値であれば任意である。例えば、式（２９）は、式（３３）においてＣｔｏｔ＝１かつＣｄｇｒ＝０かつＣｔｉｍｅ＝０の場合である。総合評価部３ｃは、実施形態に応じた適宜の係数Ｃｔｏｔ、Ｃｄｇｒ、およびＣｔｉｍｅを用いて、式（３３）にしたがって総合評価を算出することができる。
Figure 2013094006
ここで、上記の式（２９）〜（３３）中の関数ｆｔｏｔ（ｓｉ）について説明する。関数ｆｔｏｔ（ｓｉ）は、第１〜５実施形態では、具体的には式（３４）により定義される。
Figure 2013094006
式（３４）における定数εの値は、例えば図６に例示した値でもよい。定数εは、０による除算を防ぐための、正のごく小さな値である。
また、式（３４）における関数ｔｔｍｐｒ（ｓｉ）は式（３５）により定義され、関数ｔｖｏｌ（ｓｉ）は式（３６）により定義される。式（３５）中の関数ｔｔｍｐｒ（ｓｉ，ｈ）については、式（１３）に関連して既に説明した。また、式（３５）中の関数ｔｖｏｌ（ｓｉ，ｈ）については、式（２２）に関連して既に説明した。
Figure 2013094006
Figure 2013094006
すなわち、式（３５）の関数ｔｔｍｐｒ（ｓｉ）は、今までにサーバｓｉで１つ以上の温度異常の各々が続いた時間の長さの合計を示す。もちろん、今までにサーバｓｉで温度異常が発生したことがなければ、関数ｔｔｍｐｒ（ｓｉ）の値は０である。
また、式（３６）の関数ｔｖｏｌ（ｓｉ）は、今までにサーバｓｉで１つ以上の電圧異常の各々が続いた時間の長さの合計を示す。もちろん、今までにサーバｓｉで電圧異常が発生したことがなければ、関数ｔｖｏｌ（ｓｉ）の値は０である。
なお、式（３５）と（３６）では、簡単のため、異常のレベルの違いが考慮されていない。しかし、実施形態によっては、式（３５）や（３６）のような単純な総和の代わりに、異常のレベルに応じた重みＷｈを用いた重み付け和が使われてもよい。
ここで、今までにサーバｓｉで少なくとも１回は、温度異常または電圧異常が発生したことがあるとする。この場合、定数εを０と見なすことにより、式（３４）は、式（３７）のように近似される。
Figure 2013094006
式（３７）の近似から分かるとおり、関数ｆｔｏｔ（ｓｉ）は、温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）の重み付け和を算出するための関数である。そして、温度評価値ｆｔｍｐｒ（ｓｉ）に掛けられる重みは、今までにサーバｓｉで温度異常と電圧異常が続いた時間の合計の長さに対する、今までにサーバｓｉで温度異常が続いた時間の合計の長さの割合である。他方、電圧評価値ｆｖｏｌ（ｓｉ）に掛けられる重みは、今までにサーバｓｉで温度異常と電圧異常が続いた時間の合計の長さに対する、今までにサーバｓｉで電圧異常が続いた時間の合計の長さの割合である。
温度異常と電圧異常のどちらが発生しやすいかは、サーバごとに異なり得る。また、温度異常の発生のしやすさと電圧異常の発生のしやすさがどの程度異なるかも、サーバごとに異なり得る。つまり、温度異常の発生のしやすさと電圧異常の発生のしやすさの比率は、各サーバに固有の性質である。
式（３７）のように近似される式（３４）での重み付けは、サーバｓｉに固有の性質を反映している。もし、サーバｓｉでは電圧異常よりも温度異常の方が発生しやすいならば、サーバｓｉに関しては温度異常に大きな重みが与えられる。逆に、もしサーバｓｉでは温度異常よりも電圧異常の方が発生しやすいならば、サーバｓｉに関しては電圧異常に大きな重みが与えられる。
そして、式（２９）〜（３３）に示すように、総合評価値ｆｔｏｔａｌ（ｓｉ）には、関数ｆｔｏｔ（ｓｉ）の値が反映される。つまり、第１〜第５実施形態のいずれにおいても、総合評価部３ｃは、各スタンバイサーバに固有の性質を考慮に入れて各スタンバイサーバを総合的に評価する。その結果、フェイルオーバ制御部４は、最も適切なスタンバイサーバへのフェイルオーバを実行することができる。
なお、今までにサーバｓｉで温度異常も電圧異常も発生したことがない場合は、式（３４）から式（３８）が得られる。もしサーバｓｉに実際に異常が発生したことがないならば、サーバｓｉで発生しやすい異常の種類は不明である。よって、この場合、「サーバｓｉでは、温度異常と電圧異常の発生のしやすさが互角である」と想定するのが妥当である。式（３８）はこの想定を表す。
Figure 2013094006
以上、第１〜第５実施形態の概要を説明するために、具体的な数式を参照した。しかし、もちろん、上記に例示した式以外の式に基づいて算出部３内の各部が各種評価値を算出してもよい。
以下では、上記の数式にしたがった総合評価値の算出を実現するための、具体的なデータの例およびフローチャートの例について説明する。図７は、図２の管理ＤＢ５に含まれるサーバテーブルとシャーシテーブルの例を示す図である。
図７のサーバテーブル２０３は、７つのエントリを含む。これらの７つのエントリは、管理サーバ１が管理する図２の７台のサーバ３０−１〜３０−７にそれぞれ対応する。各エントリは、サーバＩＤ、シャーシＩＤ、スロットＩＤ、ラックＩＤ、ラック内位置、シリアル番号、ＣＰＵ数、メモリサイズ、ＮＩＣ数、カード数、シャーシ内電源ＩＤ、ラック内電源ＩＤという、１２個のフィールドを含む。
サーバＩＤは、サーバを識別するＩＤである。管理サーバ１が管理する複数のサーバには、互いに異なるサーバＩＤが予め割り当てられている。
シャーシＩＤとスロットＩＤは、ブレード型サーバに対応するエントリでのみ有効である。ブレード型サーバに対応するエントリにおいて、シャーシＩＤは、サーバが搭載されているシャーシを識別するＩＤであり、スロットＩＤは、サーバが差し込まれているスロットを識別するＩＤである。
スロットＩＤの値は、１台のシャーシ内で一意であればよい。ただし、以下では説明の簡単化のため、スロットＩＤが数値であるものとし、スロットＩＤの値によりシャーシ内の位置が表されるものとする。例えば、「２」というスロットＩＤで表されるスロットには、「１」と「３」というスロットＩＤでそれぞれ表される２つのスロットが隣接しているものとする。なお、ラックマウント型サーバに対応するエントリのシャーシＩＤの値とスロットＩＤの値は、無効な値である。
ラックＩＤとラック内位置は、ラックマウント型サーバに対応するエントリでのみ有効である。ラックマウント型サーバに対応するエントリにおいて、ラックＩＤは、サーバが搭載されているラックを識別するＩＤであり、ラック内位置は、サーバが搭載されているラック内での位置を識別するＩＤである。
ラック内位置の値は、１台のラック内で一意であればよい。なお、ブレード型サーバに対応するエントリのラックＩＤの値とラック内位置の値は、無効な値である。
シリアル番号は、サーバに固有の製造番号である。便宜上「シリアル番号」と呼んでいるが、シリアル番号は記号と数字の任意の組み合わせでよい。
ＣＰＵ数は、サーバに搭載されているＣＰＵの数である。メモリサイズは、サーバに搭載されているメモリの容量をメガバイト（ＭＢ）単位で示す数値である。ＮＩＣ数は、サーバに取り付けられたＮＩＣの数と、サーバに内蔵されたオンボード型のネットワークインタフェイスコントローラの数の和である。カード数は、サーバに取り付けられた、ＮＩＣ以外の拡張カード（例えばグラフィックカードなど）の数である。
シャーシ内電源ＩＤは、ブレード型サーバに対応するエントリでのみ有効である。ブレード型サーバに対応するエントリにおいて、シャーシ内電源ＩＤは、サーバに接続されている、シャーシ内の電源ユニットを識別するＩＤである。シャーシ内電源ＩＤの値は、１台のシャーシ内で一意であればよい。ラックマウント型サーバに対応するエントリのシャーシ内電源ＩＤの値は、無効な値である。
ラック内電源ＩＤは、ラックマウント型サーバに対応するエントリでのみ有効である。ラックマウント型サーバに対応するエントリにおいて、ラック内電源ＩＤは、サーバに接続されている、ラック内の電源ユニットを識別するＩＤである。シャーシ内電源ＩＤの値は、１台のラック内で一意であればよい。ブレード型サーバに対応するエントリのラック内電源ＩＤの値は、無効な値である。
図２と比較しながら図７のサーバテーブル２０３の各エントリについて説明すると、以下のとおりである。
ブレード型サーバ３０−１のサーバＩＤは「１」である。また、サーバ３０−１は、「１」というシャーシＩＤのシャーシ２０−１内の、「１」というスロットＩＤのスロットに搭載されている。そして、サーバ３０−１のシリアル番号は「Ａ１」であり、サーバ３０−１は２台のＣＰＵ１０１を有し、サーバ３０−１のＲＡＭ１０２の容量は２０４８ＭＢである。また、サーバ３０−１には４つのネットワークインタフェイス１０３があるので、ＮＩＣ数は４である。サーバ３０−１には、さらに１枚の拡張カードも取り付けられている。そして、サーバ３０−１には、「１」というシャーシ内電源ＩＤの電源ユニット２３−１から、電力が供給される。
ブレード型サーバ３０−２のサーバＩＤは「２」である。また、サーバ３０−２は、「１」というシャーシＩＤのシャーシ２０−１内の、「４」というスロットＩＤのスロットに搭載されている。そして、サーバ３０−２のシリアル番号は「Ｂ１」であり、サーバ３０−２は２台のＣＰＵ１０１を有し、サーバ３０−２のＲＡＭ１０２の容量は２０４８ＭＢである。また、サーバ３０−２には４つのネットワークインタフェイス１０３があるので、ＮＩＣ数は４である。サーバ３０−２には、さらに１枚の拡張カードも取り付けられている。そして、サーバ３０−２には、「２」というシャーシ内電源ＩＤの電源ユニット２３−２から、電力が供給される。
ブレード型サーバ３０−３のサーバＩＤは「３」である。また、サーバ３０−３は、「１」というシャーシＩＤのシャーシ２０−１内の、「５」というスロットＩＤのスロットに搭載されている。そして、サーバ３０−３のシリアル番号は「Ｃ１」であり、サーバ３０−３は２台のＣＰＵ１０１を有し、サーバ３０−３のＲＡＭ１０２の容量は２０４８ＭＢである。また、サーバ３０−３には４つのネットワークインタフェイス１０３があるので、ＮＩＣ数は４である。サーバ３０−３には、さらに１枚の拡張カードも取り付けられている。そして、サーバ３０−３には、「２」というシャーシ内電源ＩＤの電源ユニット２３−２から、電力が供給される。
ブレード型サーバ３０−４のサーバＩＤは「４」である。また、サーバ３０−４は、「２」というシャーシＩＤのシャーシ２０−２内の、「３」というスロットＩＤのスロットに搭載されている。そして、サーバ３０−４のシリアル番号は「Ｄ１」であり、サーバ３０−４は４台のＣＰＵ１０１を有し、サーバ３０−４のＲＡＭ１０２の容量は４０９６ＭＢである。また、サーバ３０−４には２つのネットワークインタフェイス１０３があるので、ＮＩＣ数は２である。サーバ３０−４には、さらに２枚の拡張カードも取り付けられている。そして、サーバ３０−４には、「３」というシャーシ内電源ＩＤの電源ユニット２３−３から、電力が供給される。
ブレード型サーバ３０−５のサーバＩＤは「５」である。また、サーバ３０−５は、「２」というシャーシＩＤのシャーシ２０−２内の、「４」というスロットＩＤのスロットに搭載されている。そして、サーバ３０−５のシリアル番号は「Ｅ１」であり、サーバ３０−５は４台のＣＰＵ１０１を有し、サーバ３０−５のＲＡＭ１０２の容量は４０９６ＭＢである。また、サーバ３０−５には２つのネットワークインタフェイス１０３があるので、ＮＩＣ数は２である。サーバ３０−５には、さらに２枚の拡張カードも取り付けられている。そして、サーバ３０−５には、「３」というシャーシ内電源ＩＤの電源ユニット２３−３から、電力が供給される。
ラックマウント型サーバ３０−６のサーバＩＤは「６」である。また、サーバ３０−６は、「３」というラックＩＤのラック１０−３内の、「１」という値で識別される位置に搭載されている。そして、サーバ３０−６のシリアル番号は「Ｆ１」であり、サーバ３０−６は２台のＣＰＵ１０１を有し、サーバ３０−６のＲＡＭ１０２の容量は１０２４ＭＢである。また、サーバ３０−６には６つのネットワークインタフェイス１０３があるので、ＮＩＣ数は６である。サーバ３０−６には、さらに２枚の拡張カードも取り付けられている。そして、サーバ３０−６には、「３」というラック内電源ＩＤの電源ユニット１２−３から、電力が供給される。
ラックマウント型サーバ３０−７のサーバＩＤは「７」である。また、サーバ３０−７は、「３」というラックＩＤのラック１０−３内の、「２」という値で識別される位置に搭載されている。そして、サーバ３０−７のシリアル番号は「Ｇ１」であり、サーバ３０−７は２台のＣＰＵ１０１を有し、サーバ３０−７のＲＡＭ１０２の容量は１０２４ＭＢである。また、サーバ３０−７には６つのネットワークインタフェイス１０３があるので、ＮＩＣ数は６である。サーバ３０−７には、さらに２枚の拡張カードも取り付けられている。そして、サーバ３０−７には、「３」というラック内電源ＩＤの電源ユニット１２−３から、電力が供給される。
さて、図７にはシャーシテーブル２０４も例示されている。シャーシテーブル２０４は、２つのエントリを含む。これらの２つのエントリは、図２のシャーシ２０−１〜２０−２にそれぞれ対応する。各エントリは、シャーシＩＤ、ラックＩＤ、ラック内位置、ラック内電源ＩＤという、４つのフィールドを含む。
シャーシＩＤはシャーシを識別するＩＤであり、ラックＩＤはシャーシが搭載されているラックを識別するＩＤである。ラック内位置は、シャーシがラック内で占める範囲を示す。ブレード型サーバ用のシャーシの高さは、例えば、６Ｕであったり１０Ｕであったりするので、シャーシに応じて、シャーシがラック内で占める範囲は異なり得る。そこで、ラック内での位置を識別するＩＤのペアを用いて、シャーシがラック内で占める範囲を示すことができる。なお、「Ｕ」はラック単位（rack unit）を示す。また、ラック内電源ＩＤは、シャーシに接続されておりシャーシに電力を供給する、ラック内の電源ユニットを識別するＩＤである。
図２と比較しながら図７のシャーシテーブル２０４について説明すると、以下のとおりである。
シャーシ２０−１のシャーシＩＤは上記のとおり「１」である。シャーシ２０−１は、「１」というラックＩＤのラック１０−１に搭載されている。また、シャーシ２０−１の高さは６Ｕであり、シャーシ２０−１は、ラック１０−１内において、「１」と「６」という２つの値で示される範囲を占めている。また、シャーシ２０−１には、「１」というラック内電源ＩＤの電源ユニット１２−１から、電力が供給される。
シャーシ２０−２のシャーシＩＤは上記のとおり「２」である。シャーシ２０−２は、「２」というラックＩＤのラック１０−２に搭載されている。また、シャーシ２０−２の高さは１０Ｕであり、シャーシ２０−２は、ラック１０−２内において、「１」と「１０」という２つの値で示される範囲を占めている。また、シャーシ２０−２には、「２」というラック内電源ＩＤの電源ユニット１２−２から、電力が供給される。
ところで、サーバテーブル２０３とシャーシテーブル２０４は、例えばネットワーク管理者によって、クライアント６を介して予め用意されてもよいし、収集部２により自動的に生成されてもよい。
例えば、収集部２は、サーバＩＤとシリアル番号とＣＰＵ数とメモリサイズとＮＩＣ数とカード数を互いに対応づける情報を、サーバ管理装置３１−１〜３１−７から収集してもよい。また、収集部２は、ブレード型サーバに関して、サーバＩＤとシャーシＩＤとスロットＩＤとシャーシ内電源ＩＤを互いに対応づける情報を、シャーシ管理装置２１−１〜２１−２から収集してもよい。収集部２は、ラックマウント型サーバに関して、サーバＩＤとラックＩＤとラック内位置とラック内電源ＩＤを互いに対応づける情報を、ラック管理装置１１−１〜１１−３から収集してもよい。収集部２は、以上のようにして収集した情報を用いてサーバテーブル２０３を生成してもよく、生成したサーバテーブル２０３を管理ＤＢ５に格納してもよい。
また、収集部２は、シャーシＩＤとラックＩＤとラック内位置とラック内電源ＩＤを互いに対応づける情報を、ラック管理装置１１−１〜１１−３から収集してもよい。収集部２は、以上のようにして収集した情報を用いてシャーシテーブル２０４を生成してもよく、生成したシャーシテーブル２０４を管理ＤＢ５に格納してもよい。
続いて、図８〜１２Ｂを参照して、第１実施形態について説明する。
図８は、管理ＤＢ５に含まれるイベント管理テーブルの例を示す図である。図８のイベント管理テーブル２０５ａと２０５ｂは、同じイベント管理テーブルの異なる２つの時点の状態を示す。
また、イベント管理テーブルに記憶される情報は、図１に関して説明した故障予兆情報の具体例である。イベント管理テーブルのエントリは、収集部２により追加および更新される。
イベント管理テーブル２０５ａには１２個のエントリがあり、各エントリは、エントリＩＤ、サーバＩＤ、開始時刻、終了時刻、イベントのレベル、およびイベントの種類という、６個のフィールドを含む。各エントリは、１台のサーバにおける１つのイベントに対応する。なお、イベント管理テーブル２０５ｂは、エントリＩＤが「１３」と「１４」と「１５」のエントリをさらに含む点以外は、イベント管理テーブル２０５ａと同じである。
エントリＩＤは、イベント管理テーブル内でエントリを識別するＩＤである。サーバＩＤは、当該エントリがどのサーバに関するものなのかを示す。
また、開始時刻はイベントが発生した時刻を示す。発生したイベントは、何らかの長さの時間にわたって継続する。例えば、「温度異常」というイベントが何時間か継続するかもしれない。既に終了したイベントに関するエントリでは、イベントが終了した時刻が終了時刻として記録されている。他方、現在継続中のイベントに関するエントリでは、終了時刻のフィールドには無効な値が設定されている。
また、イベントのレベルは、図８と１５の例では、「Ｉｎｆｏｒｍａｔｉｏｎ」、「Ｍｉｎｏｒ」、「Ｍａｊｏｒ」、および「Ｃｒｉｔｉｃａｌ」の４つのレベルのいずれかである。また、イベントの種類には、「電源ＯＮ」、「電源ＯＦＦ」、「温度異常」、「電圧低下」、および「電圧超過」などがある。なお、図８と１５の例では、以上のようにイベントのレベルと種類が文字列で表記されているが、イベントのレベルと種類は、イベント管理テーブルにおいて、適宜の数値により表されてもよい。
ここで、「電源ＯＮ」イベントと「電源ＯＦＦ」イベントは、異常を示すイベントではない。よって、「電源ＯＮ」イベントまたは「電源ＯＦＦ」イベントに関するエントリにおいては、イベントのレベルは、「Ｉｎｆｏｒｍａｔｉｏｎ」レベルである。つまり、「Ｉｎｆｏｒｍａｔｉｏｎ」レベルは、図６の重み２０２に関して説明したレベル０に対応する。
他方、「温度異常」イベント、「電圧低下」イベント、および「電圧超過」イベントは、異常を示すイベントである。よって、「温度異常」イベント、「電圧低下」イベント、または「電圧超過」イベントに関するエントリにおいては、イベントのレベルは、異常のレベルに応じた値で表される。具体的には、図６の重み２０２に関して説明したレベル１、レベル２、およびレベル３が、それぞれ、「Ｍｉｎｏｒ」レベル、「Ｍａｊｏｒ」レベル、および「Ｃｒｉｔｉｃａｌ」レベルに対応する。
以下、具体的にイベント管理テーブル２０５ａと２０５ｂの各エントリについて説明する。なお、図８と１５の例では、エントリＩＤとしてシーケンス番号が使われているので、以下では単純化のため、エントリＩＤが「ｎ」のエントリのことを「ｎ番目のエントリ」ということがある。
なお、イベント管理テーブル２０５ａは、２０１１年１月１日１０時に１２番目のエントリが追加された直後の状態を示す。また、イベント管理テーブル２０５ｂは、２０１１年１月２日１１時に１５番目のエントリが追加された直後の状態を示す。
１番目のエントリは、「１」というサーバＩＤが割り当てられたサーバ３０−１のサーバ管理装置３１−１から収集部２が収集した情報に基づいて生成されたエントリである。１番目のエントリは、サーバ３０−１で２０１０年１２月２３日１０時に発生した「電源ＯＮ」イベントを示す。つまり、１番目のエントリは、サーバ３０−１の主電源スイッチが２０１０年１２月２３日１０時に入れられ、サーバ３０−１がブートしたことを示す。
サーバ３０−１の状態を監視するサーバ管理装置３１−１は、サーバ３０−１の主電源スイッチが入れられたことを収集部２に通知する。よって、収集部２は、通知の内容に基づいて、イベントの種類を「電源ＯＮ」と判断し、１番目のエントリを生成する。
サーバ３０−１はまだシャットダウンしていない。換言すれば、収集部２は、「電源ＯＮ」イベントの終了の通知をまだサーバ管理装置３１−１から受信していない。よって、１番目のエントリの終了時刻は無効な値である。
２番目のエントリは、「２」というサーバＩＤが割り当てられたサーバ３０−２のサーバ管理装置３１−２から収集部２が収集した情報に基づいて生成されたエントリである。２番目のエントリは、サーバ３０−２で２０１０年１２月２３日１０時に発生した「電源ＯＦＦ」イベントを示す。
ここで、サーバ３０−２は、具体的には図３のコンピュータ１００のように構成されていてもよい。その場合、コンピュータ１００には、サーバ管理装置３１−２（図３には不図示だが、図２に示されている）がさらに含まれる。サーバ管理装置３１−２は、具体的には、例えば「サービスプロセッサ」などと呼ばれる、ＣＰＵ１０１とは独立したプロセッサであってもよい。
また、コンピュータ１００の外部からコンピュータ１００に供給される電力は、コンピュータ１００内部において、異なる２つの経路によりＣＰＵ１０１とサーバ管理装置３１−２に供給されてもよい。この場合、「サーバ３０−２としての機能を果たすコンピュータ１００の本体には電源が入っていないが、サーバ管理装置３１−２には電源が入っている」という状況が起こり得る。
例えば、サーバ３０−２がシャーシ２０−１の４番目のスロットに挿入されると、電源ユニット２３−２からサーバ３０−２への電力の供給が可能となる。しかし、サーバ３０−２の主電源スイッチが入れられない限り、サーバ３０−２本体（具体的にはＣＰＵ１０１）はブートしなくてもよい。他方、電源ユニット２３−２からサーバ３０−２への電力の供給が可能となり次第、サーバ管理装置３１−２に自動的に電源が入るようになっていてもよい。
すると、サーバ管理装置３１−２はサーバ３０−２の状態を監視し始め、「サーバ３０−２の主電源はまだ入っていない」という状態を認識する。サーバ管理装置３１−２は、例えば以上のような認識に基づいて、サーバ３０−２の主電源がまだ入っていないことを２０１０年１２月２３日１０時に収集部２に通知してもよい。通知には、サーバ管理装置３１−２が状態を監視する対象のサーバ３０−２のサーバＩＤも含まれる。
通知を受信した収集部２は、通知の内容から、イベントの種類を「電源ＯＦＦ」と判断し、通知の内容に基づいて２番目のエントリを生成する。なお、エントリが生成される時点では、終了時刻は無効な値である。
図８の例では、サーバ３０−２の主電源スイッチが２０１０年１２月２８日１０時に入れられる。すると、サーバ管理装置３１−２はサーバ３０−２の主電源が入ったことを収集部２に通知する。通知の内容に基づいて、収集部２は、２番目のエントリの終了時刻として、２０１０年１２月２８日１０時という日時を記録する。また、この通知に基づいて、収集部２は、後述の８番目のエントリも生成する。
３番目のエントリも、２番目のエントリと類似の過程を経て生成および更新されたエントリである。３番目のエントリによれば、サーバ３０−４は、２０１０年１２月２３日１０時にはまだ単にシャーシ２０−２内のスロットに取り付けられただけである。しかし、２０１０年１２月２７日１０時には、サーバ３０−４の主電源が入れられている。
４番目のエントリも、２番目のエントリと類似の過程を経て生成されたエントリである。４番目のエントリによれば、サーバ３０−５は、２０１０年１２月２３日１０時にシャーシ２０−２のスロットに取り付けられたが、まだ主電源は入れられていない。そのため、４番目のエントリの「電源ＯＦＦ」イベントはまだ終了しておらず、終了時刻は無効な値である。
５番目のエントリも、２番目のエントリと類似の過程を経て生成および更新されたエントリである。５番目のエントリによれば、サーバ３０−６は、２０１０年１２月２３日１０時にはまだ単にラック１０−３に取り付けられただけである。しかし、２０１０年１２月２８日１０時には、サーバ３０−６の主電源が入れられている。
６番目のエントリも、２番目のエントリと類似の過程を経て生成および更新されたエントリである。６番目のエントリによれば、サーバ３０−７は、２０１０年１２月２３日１０時にはまだ単にラック１０−３に取り付けられただけである。しかし、２０１０年１２月３１日１０時には、サーバ３０−７の主電源が入れられている。
７番目のエントリは、３番目のエントリの終了時刻を収集部２が更新する契機となった、サーバ管理装置３１−４からの通知に基づいて、収集部２により生成される。つまり、サーバ３０−４の主電源が入れられることは、「電源ＯＦＦ」イベントの終了を意味するとともに、「電源ＯＮ」イベントの開始も意味する。そのため、収集部２は、サーバ管理装置３１−４から通知を受け取ると、「電源ＯＦＦ」イベントに関する３番目のエントリを更新するとともに、「電源ＯＮ」イベントに関する７番目のエントリを生成する。サーバ３０−４は、主電源スイッチが入れられた後、まだシャットダウンしていないので、７番目のエントリの終了時刻は無効な値である。
同様に、８番目のエントリは、２番目のエントリの終了時刻を収集部２が更新する契機となった、サーバ管理装置３１−２からの通知に基づいて、収集部２により生成される。サーバ３０−２は、主電源スイッチが入れられた後、まだシャットダウンしていないので、８番目のエントリの終了時刻は無効な値である。
９番目のエントリは、２番目のエントリと類似の過程を経て生成されたエントリである。９番目のエントリによれば、サーバ３０−３は、２０１０年１２月２８日１０時にシャーシ２０−１のスロットに取り付けられたが、まだ主電源は入れられていない。そのため、９番目のエントリの「電源ＯＦＦ」イベントはまだ終了しておらず、終了時刻は無効な値である。
１０番目のエントリは、５番目のエントリの終了時刻を収集部２が更新する契機となった、サーバ管理装置３１−６からの通知に基づいて、収集部２により生成される。サーバ３０−６は、主電源スイッチが入れられた後、まだシャットダウンしていないので、１０番目のエントリの終了時刻は無効な値である。
１１番目のエントリは、６番目のエントリの終了時刻を収集部２が更新する契機となった、サーバ管理装置３１−７からの通知に基づいて、収集部２により生成される。サーバ３０−７は、主電源スイッチが入れられた後、まだシャットダウンしていないので、１１番目のエントリの終了時刻は無効な値である。
１２番目のエントリは、サーバ３０−２に２０１１年１月１日１０時に発生した、「Ｍａｊｏｒ」レベルの「温度異常」イベントに対応する。具体的には、１２番目のエントリは以下のようにして生成される。
サーバ管理装置３１−２はサーバ３０−２の状態を監視し、２０１１年１月１日１０時に温度異常を検出する。例えば、サーバ３０−２のＣＰＵ１０１が温度センサを備えていてもよく、サーバ管理装置３１−２は、温度センサの出力を監視してもよい。
サーバ管理装置３１−２は、サーバ３０−２の温度異常（例えば、所定の閾値を超える高温）を検出すると、温度異常の検出を収集部２に通知する。サーバ管理装置３１−２からの通知は、温度センサにより計測された温度自体の値を含んでいてもよいし、温度からサーバ管理装置３１−２が判断した、温度異常のレベルを示す値を含んでいてもよい。
いずれにしろ、収集部２は、サーバ管理装置３１−２からの通知に基づいて、サーバ３０−２に「Ｍａｊｏｒ」レベルの「温度異常」イベントが発生したことを認識する。認識の結果、収集部２は、１２番目のエントリを生成する。
なお、サーバ３０−２における温度異常はまだ終熄していない。つまり、サーバ３０−２の温度が正常に戻ったことを示す通知を、収集部２はまだ受信していない。そのため、１２番目のエントリの終了時刻は無効な値である。
さて、イベント管理テーブル２０５ａには、以上説明したような１２個のエントリが含まれる。イベント管理テーブル２０５ｂは、その後さらに３つのエントリが追加された状態を示す。
１３番目のエントリは、サーバ３０−６において２０１１年１月１日１１時に発生し、２０１１年１月１日１２時に終熄した、「Ｍｉｎｏｒ」レベルの「電圧低下」イベントに対応する。具体的には、１３番目のエントリは、以下のようにして生成され、更新される。
サーバ管理装置３１−６はサーバ３０−６の状態を監視し、２０１１年１月１日１１時に電圧低下を検出する。すると、サーバ管理装置３１−６は、電圧低下の検出を収集部２に通知する。サーバ管理装置３１−６からの通知は、計測された電圧自体の値を含んでいてもよいし、電圧からサーバ管理装置３１−６が判断した、電圧低下のレベルを示す値を含んでいてもよい。
いずれにしろ、収集部２は、サーバ管理装置３１−６からの通知に基づいて、サーバ３０−６に「Ｍｉｎｏｒ」レベルの「電圧低下」イベントが発生したことを認識する。認識の結果、収集部２は、１３番目のエントリを生成する。生成された時点で、１３番目のエントリの終了時刻は、無効な値である。
その後も、サーバ管理装置３１−６は、サーバ３０−６の状態の監視を続ける。そして、サーバ管理装置３１−６は、電圧が正常に戻ったことを２０１１年１月１日１２時に検出する。すると、サーバ管理装置３１−６は、電圧が正常に戻ったことを収集部２に通知する。そして、収集部２は、サーバ管理装置３１−６からの通知に基づいて、１３番目のエントリの終了時刻として、２０１１年１月１日１２時という日時を記録する。
１４番目のエントリは、サーバ３０−４において２０１１年１月２日１０時に発生した「Ｃｒｉｔｉｃａｌ」レベルの「電圧低下」イベントに対応する。具体的には、１４番目のエントリは、以下のようにして生成される。
サーバ管理装置３１−４はサーバ３０−４の状態を監視し、２０１１年１月２日１０時に電圧低下を検出する。すると、サーバ管理装置３１−４は、電圧低下の検出を収集部２に通知する。サーバ管理装置３１−４からの通知は、計測された電圧自体の値を含んでいてもよいし、電圧からサーバ管理装置３１−４が判断した、電圧低下のレベルを示す値を含んでいてもよい。
いずれにしろ、収集部２は、サーバ管理装置３１−４からの通知に基づいて、サーバ３０−４に「Ｃｒｉｔｉｃａｌ」レベルの「電圧低下」イベントが発生したことを認識する。認識の結果、収集部２は、１４番目のエントリを生成する。生成された時点で、１４番目のエントリの終了時刻は、無効な値である。
１５番目のエントリは、サーバ３０−６において２０１１年１月２日１１時に発生した「Ｍｉｎｏｒ」レベルの「電圧低下」イベントに対応する。具体的には、１５番目のエントリは、以下のようにして生成される。
サーバ管理装置３１−６はサーバ３０−６の状態を監視し、２０１１年１月２日１１時に電圧低下を検出する。すると、サーバ管理装置３１−６は、電圧低下の検出を収集部２に通知する。サーバ管理装置３１−６からの通知は、計測された電圧自体の値を含んでいてもよいし、電圧からサーバ管理装置３１−６が判断した、電圧低下のレベルを示す値を含んでいてもよい。
いずれにしろ、収集部２は、サーバ管理装置３１−６からの通知に基づいて、サーバ３０−６に「Ｍｉｎｏｒ」レベルの「電圧低下」イベントが発生したことを認識する。認識の結果、収集部２は、１５番目のエントリを生成する。生成された時点で、１５番目のエントリの終了時刻は、無効な値である。
なお、以上の図８の説明においては、便宜上、サーバ管理装置３１−１〜３１−７からの通知を収集部２が受信する場合（つまり図１のステップＳ１０２に相当する場合）を例示した。しかし、図１のステップＳ１０３〜Ｓ１０４に示すように、収集部２による問い合わせに対してサーバ管理装置３１−１〜３１−７が応答を返し、応答の受信に応じて収集部２がイベント管理テーブルにエントリを追加してもよい。
さて、図９は、第１実施形態での総合評価処理のフローチャートである。図９の総合評価処理は、図１のステップＳ１０６で算出部３が実行する。より具体的には、フェイルオーバ処理が図４のように行われる場合は、図４のステップＳ２０３で算出部３が図９の総合評価処理を実行し、フェイルオーバ処理が図５のように行われる場合は、図５の処理と独立して算出部３が適宜のタイミングで図９の総合評価処理を実行する。
また、図９の総合評価処理は、ある１台のサーバ（説明の便宜上、「サーバｓｉ」とする）に関して実行される。例えば、フェイルオーバ制御部４が、サーバｓｉのＩＤを算出部３に指定して、算出部３に総合評価処理の実行を命じてもよい。あるいは、算出部３が定期的に各サーバｓｉについて図９の総合評価処理を実行してもよい。
いつ図９の総合評価処理が実行されるにせよ、第１実施形態では、管理ＤＢ５が図１０のような結果テーブルを含む。図１０の結果テーブル２０６ａと２０６ｂは、同じ結果テーブルの異なる２つの時点の状態を示す。
結果テーブルに記録されるデータの具体例は後述するが、図１０に示すとおり、第１実施形態の結果テーブルの各エントリは、サーバＩＤ、温度評価値、電圧評価値、および総合評価値という、４個のフィールドを含む。また、結果テーブルの各エントリは、各スタンバイサーバに対応する。図９の総合評価処理の進捗にともなって、結果テーブルは更新される。
さて、図９のステップＳ４０１で算出部３は、サーバｓｉのＩＤを温度評価部３ａに指定し、図１１Ａ〜１１Ｃの温度評価処理の実行を温度評価部３ａに命じる。すると、温度評価部３ａは、図１１Ａ〜１１Ｃのフローチャートにしたがって、式（１）の温度評価値ｆｔｍｐｒ（ｓｉ）を算出する。そして、温度評価部３ａは、結果テーブル中の、サーバｓｉに対応するエントリの温度評価値のフィールドに、算出結果を記録する。
次に、ステップＳ４０２で算出部３は、サーバｓｉのＩＤを電圧評価部３ｂに指定し、図１２Ａ〜１２Ｂの電圧評価処理の実行を電圧評価部３ｂに命じる。すると、電圧評価部３ｂは、図１２Ａ〜１２Ｂのフローチャートにしたがって、式（８）の電圧評価値ｆｖｏｌ（ｓｉ）を算出する。そして、電圧評価部３ｂは、結果テーブル中の、サーバｓｉに対応するエントリの電圧評価値のフィールドに、算出結果を記録する。
その後のステップＳ４０３〜Ｓ４１１では、総合評価部３ｃが、結果テーブルに記録された温度評価値と電圧評価値を用いて、式（２９）と（３４）にしたがって、総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。具体的には以下のとおりである。
ステップＳ４０３で総合評価部３ｃは、サーバｓｉに温度異常が発生していた時間の長さを示す変数Ｘｔに、初期値εを代入する。また、総合評価部３ｃは、サーバｓｉに電圧異常が発生していた時間の長さを示す変数Ｘｖに、初期値εを代入する。なお、初期値εの具体例は図６に示すとおりである。
次に、ステップＳ４０４で総合評価部３ｃは、ステップＳ４０５〜Ｓ４０６の処理対象として未選択の、サーバｓｉでの温度異常イベントがあるか否かを判断する。具体的には、総合評価部３ｃは、イベント管理テーブルの中に以下の３つの条件をすべて満たすエントリがあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが温度異常を示している。
・ステップＳ４０５〜Ｓ４０６の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ４０５に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合（つまり、サーバｓｉでの温度異常イベントに関するエントリが存在しないか、または、上記３つの条件を満たすすべてのエントリを総合評価部３ｃが選択済みの場合）、処理はステップＳ４０７に移行する。
ステップＳ４０５で総合評価部３ｃは、サーバｓｉでの未選択の温度異常イベントを１つ選択する。つまり、総合評価部３ｃは、サーバｓｉでの温度異常イベントに関する未選択のエントリ１つ選択する。
そして、総合評価部３ｃは、選択したエントリから、当該温度異常イベントの開始時刻と終了時刻を取得する。なお、選択したエントリには有効な終了時刻の値が記録されていない場合は、総合評価部３ｃは、終了時刻の代わりに現在時刻を取得する。なぜなら、無効な終了時刻は、当該温度異常イベントがまだ継続中であることを示すからである。
そして、ステップＳ４０６で総合評価部３ｃは、選択したエントリに対応する温度異常イベントが続いた時間の長さを算出する。つまり、総合評価部３ｃは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。そして、総合評価部３ｃは、減算により得た値を、変数Ｘｔに足す。そして、処理はステップＳ４０４に戻る。
ステップＳ４０４〜Ｓ４０６の繰り返しループの結果として、ステップＳ４０７の実行時点では、「Ｘｔ＝ε＋ｔｔｍｐｒ（ｓｉ）」という式が成り立つ（式（３４）と（３５）を参照）。
ステップＳ４０７で総合評価部３ｃは、ステップＳ４０８〜Ｓ４０９の処理対象として未選択の、サーバｓｉでの電圧異常イベントがあるか否かを判断する。具体的には、総合評価部３ｃは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、電圧低下または電圧超過を示している。
・ステップＳ４０８〜Ｓ４０９の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ４０８に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合（つまり、サーバｓｉでの電圧異常イベントに関するエントリが存在しないか、または、上記３つの条件を満たすすべてのエントリを総合評価部３ｃが選択済みの場合）、処理はステップＳ４１０に移行する。
ステップＳ４０８で総合評価部３ｃは、サーバｓｉでの未選択の電圧異常イベントを１つ選択する。つまり、総合評価部３ｃは、サーバｓｉでの電圧異常イベントに関する未選択のエントリ１つ選択する。そして、総合評価部３ｃは、選択したエントリから、当該電圧異常イベントの開始時刻と終了時刻を取得する。なお、選択したエントリには有効な終了時刻の値が記録されていない場合は、総合評価部３ｃは、終了時刻の代わりに現在時刻を取得する。なぜなら、当該電圧異常イベントはまだ継続中だからである。
そして、ステップＳ４０９で総合評価部３ｃは、選択したエントリに対応する電圧異常イベントが続いた時間の長さを算出する。つまり、総合評価部３ｃは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。そして、総合評価部３ｃは、減算により得た値を、変数Ｘｖに足す。その後、処理はステップＳ４０７に戻る。
ステップＳ４０７〜Ｓ４０９の繰り返しループの結果として、ステップＳ４１０の実行時点では、「Ｘｖ＝ε＋ｔｖｏｌ（ｓｉ）」という式が成り立つ（式（３４）と（３６）を参照）。
ステップＳ４１０で総合評価部３ｃは、変数ＸｔとＸｖから、温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）それぞれの影響の割合を算出する。すなわち、総合評価部３ｃは、Ｘｔ／（Ｘｔ＋Ｘｖ）とＸｖ／（Ｘｔ＋Ｘｖ）を算出する。
そして、ステップＳ４１１で総合評価部３ｃは、以下の４つの値を用いて、総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。
・結果テーブルに記録されている温度評価値ｆｔｍｐｒ（ｓｉ）
・結果テーブルに記録されている電圧評価値ｆｖｏｌ（ｓｉ）
・算出した割合Ｘｔ／（Ｘｔ＋Ｘｖ）
・算出した割合Ｘｖ／（Ｘｔ＋Ｘｖ）
具体的には、総合評価部３ｃは、結果テーブルからサーバｓｉの温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）を読み出す。そして、総合評価部３ｃは、温度評価値ｆｔｍｐｒ（ｓｉ）と割合Ｘｔ／（Ｘｔ＋Ｘｖ）との積を算出し、電圧評価値ｆｖｏｌ（ｓｉ）と割合Ｘｖ／（Ｘｔ＋Ｘｖ）の積を算出し、算出した２つの積の和を算出する。
こうして算出された結果は、式（３４）の総合評価値ｆｔｏｔａｌ（ｓｉ）である。総合評価部３ｃは、結果テーブル中の、サーバｓｉに対応するエントリの総合評価値のフィールドに、算出結果を記録する。そして、図９の総合評価処理は終了する。
さて、図１１Ａ〜１１Ｃは、温度評価処理のフローチャートである。第１実施形態では、図９のステップＳ４０１で温度評価部３ａがサーバｓｉに関して温度評価処理を実行する。
ステップＳ５０１で温度評価部３ａは、現在サーバｓｉに温度異常が発生中か否かを判断する。もし、イベント管理テーブルの中に、以下の３つの条件をすべて満たすエントリが存在すれば、サーバｓｉに現在温度異常が発生中である。逆に、以下の３つの条件をすべて満たすエントリが存在しなければ、現在サーバｓｉに温度異常は発生していない。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが温度異常を示している。
・「終了時刻」フィールドに無効な値が記録されている。
温度評価部３ａは、イベント管理テーブルから上記３つの条件をすべて満たすエントリを探すことで、ステップＳ５０１の判断を行う。そして、現在サーバｓｉに温度異常が発生中の場合、処理はステップＳ５０２に移行する。逆に、現在サーバｓｉに温度異常が発生していなければ、処理はステップＳ５０３に移行する。
ステップＳ５０２で温度評価部３ａは、サーバｓｉに発生中の温度異常の重み（つまり式（１）の重みｗｔｍｐｒ（ｓｉ））を取得する。具体的には、温度評価部３ａは、ステップＳ５０１の検索で見つかったエントリの「イベントのレベル」フィールドの値を読み取り、読み取った値に対応する重みを取得する。例えば、図６の重み２０２の例によれば、イベントのレベルが「Ｍａｊｏｒ」の場合、温度評価部３ａは「２」という重みを取得する。
さらに温度評価部３ａは、取得した重みと自己係数Ｃｓｅｌｆの積を、温度評価値用の変数Ｘに代入する。そして、処理はステップＳ５０４に移行する。
他方、ステップＳ５０３で温度評価部３ａは、温度評価用の変数Ｘに単に０を代入する。そして、処理はステップＳ５０４に移行する。以上のステップＳ５０２またはＳ５０３により、式（１）の第１項の値が変数Ｘに格納される。
さて、ステップＳ５０４で温度評価部３ａは、図７のサーバテーブル２０３を参照することで、サーバｓｉの種別がブレード型かラックマウント型かを判断する。サーバテーブル２０３中の、サーバｓｉに対応するエントリにおいて、シャーシＩＤに有効な値が設定されていれば、サーバｓｉはブレード型である。逆に、サーバテーブル２０３中の、サーバｓｉに対応するエントリにおいて、ラックＩＤに有効な値が設定されていれば、サーバｓｉはラックマウント型である。
サーバｓｉがブレード型の場合、処理はステップＳ５０５に移行する。逆に、サーバｓｉがラックマウント型の場合、処理は図１１ＢのステップＳ５１５に移行する。
ステップＳ５０５〜Ｓ５０９は、式（１）の第２項に対応する。具体的には、ステップＳ５０５で温度評価部３ａは、サーバｓｉのサーバＩＤを検索キーとして用いて、サーバｓｉのシャーシＩＤとスロットＩＤを図７のサーバテーブル２０３から取得する。
そして、次のステップＳ５０６で温度評価部３ａは、サーバｓｉに隣接する未選択のサーバがあるか否かを判断する。つまり、温度評価部３ａは、以下の３つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「シャーシＩＤ」フィールドの値が、ステップＳ５０５で取得されたシャーシＩＤと等しい。
・「スロットＩＤ」フィールドの値と、ステップＳ５０５で取得されたスロットＩＤとの差が、１または−１である。
・ステップＳ５０８〜Ｓ５０９の処理対象としてまだステップＳ５０７で選択されていない。
もし上記３つの条件をすべて満たすエントリがあれば、処理はステップＳ５０７に移行する。逆に、上記の３つの条件をすべて満たすエントリがなければ、処理は図１１ＢのステップＳ５１０に移行する。
ステップＳ５０７で温度評価部３ａは、未選択の隣接サーバを１つ選択する。つまり、温度評価部３ａは、ステップＳ５０６の上記３つの条件すべてを満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ５０８〜Ｓ５０９の説明においては、ステップＳ５０７で選択された隣接サーバを「サーバｓｊ」という。ステップＳ５０７で選択されたサーバｓｊは、式（５）の集合ａｄｊ（ｓｉ）に属する。
次に、ステップＳ５０８で温度評価部３ａは、ステップＳ５０７で選択したサーバｓｊに現在温度異常が発生中か否かを判断する。温度評価部３ａは、イベント管理テーブルを参照することで、ステップＳ５０１と同様にして、ステップＳ５０８の判断を行うことができる。
現在サーバｓｊに温度異常が発生中の場合、処理はステップＳ５０９に移行する。逆に、現在サーバｓｊに温度異常が発生していなければ、処理はステップＳ５０６に戻る。
ステップＳ５０９で温度評価部３ａは、サーバｓｊに発生中の温度異常の重み（つまり式（１）の第２項における重みｗｔｍｐｒ（ｓｊ））を取得する。具体的には、温度評価部３ａは、ステップＳ５０８の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、温度評価部３ａは、読み取った値に対応する重みを取得する。さらに温度評価部３ａは、取得した重みと隣接係数Ｃａｄｊの積を、変数Ｘに足す。そして、処理はステップＳ５０６に戻る。
さて、図１１ＢのステップＳ５１０〜Ｓ５１３は、式（１）の第３項に対応する。
ステップＳ５１０で温度評価部３ａは、サーバｓｉと同一シャーシ内の未選択のサーバがあるか否かを判断する。つまり、温度評価部３ａは、以下の４つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「シャーシＩＤ」フィールドの値が、ステップＳ５０５で取得されたシャーシＩＤと等しい。
・「サーバＩＤ」フィールドの値が、サーバｓｉのＩＤとは異なる。
・ステップＳ５１２〜Ｓ５１３の処理対象としてまだステップＳ５１１で選択されていない。
・ステップＳ５０７で選択されたエントリではない。
もし上記４つの条件をすべて満たすエントリがあれば、処理はステップＳ５１１に移行する。逆に、上記４つの条件をすべて満たすエントリがなければ、処理はステップＳ５１４に移行する。
ステップＳ５１１で温度評価部３ａは、サーバｓｉと同一のシャーシ内の未選択のサーバ（より詳しくは、上記の条件から明らかなように、サーバｓｉに隣接していない未選択のサーバ）を１つ選択する。つまり、温度評価部３ａは、ステップＳ５１０の上記４つの条件すべてを満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ５１２〜Ｓ５１３の説明においては、ステップＳ５１１で選択されたサーバを「サーバｓｊ」という。ステップＳ５１１で選択されたサーバｓｊは、式（６）の集合ｃｈａｓｓｉｓ（ｓｉ）に属する。
次に、ステップＳ５１２で温度評価部３ａは、ステップＳ５１１で選択したサーバｓｊに現在温度異常が発生中か否かを判断する。温度評価部３ａは、イベント管理テーブルを参照することで、ステップＳ５０１と同様にして、ステップＳ５１２の判断を行うことができる。
現在サーバｓｊに温度異常が発生中の場合、処理はステップＳ５１３に移行する。逆に、現在サーバｓｊに温度異常が発生していなければ、処理はステップＳ５１０に戻る。
ステップＳ５１３で温度評価部３ａは、サーバｓｊに発生中の温度異常の重み（つまり式（１）の第３項における重みｗｔｍｐｒ（ｓｊ））を取得する。具体的には、温度評価部３ａは、ステップＳ５１２の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、温度評価部３ａは、読み取った値に対応する重みを取得する。さらに温度評価部３ａは、取得した重みとシャーシ係数Ｃｃｈａｓｓｉｓの積を、変数Ｘに足す。そして、処理はステップＳ５１０に戻る。
さて、図１１ＢのステップＳ５１４から図１１ＣのステップＳ５２５は、式（１）の第４項に対応する。ここで、式（１）の第４項は、式（７）の集合ｒａｃｋ（ｓｉ）に属するサーバに関する項である。そして、式（７）の定義から分かるように、集合ｒａｃｋ（ｓｉ）に属する個々のサーバは、ラックマウント型サーバのこともあるし、ブレード型サーバのこともある。ステップＳ５１４〜Ｓ５２５のうち、ステップＳ５１６〜Ｓ５１９は、サーバｓｉと同じラック内のラックマウント型サーバに関するステップであり、ステップＳ５２０〜Ｓ５２５は、サーバｓｉと同じラック内のブレード型サーバに関するステップである。
ステップＳ５１４で温度評価部３ａは、ステップＳ５０５で取得したシャーシＩＤを用いてラックＩＤを取得する。具体的には、温度評価部３ａは、「シャーシＩＤ」フィールドの値がステップＳ５０５で取得したシャーシＩＤと同じエントリを、図７のシャーシテーブル２０４において探す。そして、温度評価部３ａは、見つかったエントリの「ラックＩＤ」フィールドの値を取得する。
ステップＳ５１４は、ブレード型サーバｓｉが搭載されているラックのＩＤを取得するためのステップである。ラックＩＤの取得後、処理はステップＳ５１６に移行する。
他方、温度評価値を算出する対象のサーバｓｉがラックマウント型の場合、温度評価部３ａはステップＳ５１５で、サーバｓｉのＩＤを用いてラックＩＤを取得する。具体的には、温度評価部３ａは、「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しいエントリを、サーバテーブル２０３において探す。そして、温度評価部３ａは、見つかったエントリの「ラックＩＤ」フィールドの値を取得する。
ステップＳ５１５は、ラックマウント型サーバｓｉが搭載されているラックのＩＤを取得するためのステップである。ラックＩＤの取得後、処理はステップＳ５１６に移行する。
ステップＳ５１６で温度評価部３ａは、サーバｓｉと同一ラック内の未選択のラックマウント型サーバがあるか否かを判断する。つまり、温度評価部３ａは、以下の５つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ５１４またはＳ５１５で取得されたラックＩＤと等しい。
・「サーバＩＤ」フィールドの値が、サーバｓｉのＩＤとは異なる。
・ステップＳ５０７で選択されたエントリではない。
・ステップＳ５１１で選択されたエントリではない。
・ステップＳ５１８〜Ｓ５１９の処理対象としてまだステップＳ５１７で選択されていない。
もし上記５つの条件をすべて満たすエントリがあれば、処理はステップＳ５１７に移行する。逆に、上記５つの条件をすべて満たすエントリがなければ、処理は図１１ＣのステップＳ５２０に移行する。
ステップＳ５１７で温度評価部３ａは、サーバｓｉと同一ラック内の未選択のラックマウント型サーバを１つ選択する。つまり、温度評価部３ａは、ステップＳ５１６の上記５つの条件すべてを満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ５１８〜Ｓ５１９の説明においては、ステップＳ５１７で選択されたサーバを「サーバｓｊ」という。ステップＳ５１７で選択されるサーバｓｊは、式（７）の集合ｒａｃｋ（ｓｉ）に属するラックマウント型サーバである。
次に、ステップＳ５１８で温度評価部３ａは、ステップＳ５１７で選択したサーバｓｊに現在温度異常が発生中か否かを判断する。温度評価部３ａは、イベント管理テーブルを参照することで、ステップＳ５０１と同様にして、ステップＳ５１８の判断を行うことができる。
現在サーバｓｊに温度異常が発生中の場合、処理はステップＳ５１９に移行する。逆に、現在サーバｓｊに温度異常が発生していなければ、処理はステップＳ５１６に戻る。
ステップＳ５１９で温度評価部３ａは、サーバｓｊに発生中の温度異常の重み（つまり式（１）の第４項における重みｗｔｍｐｒ（ｓｊ））を取得する。具体的には、温度評価部３ａは、ステップＳ５１８の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、温度評価部３ａは、読み取った値に対応する重みを取得する。さらに温度評価部３ａは、取得した重みとラック係数Ｃｒａｃｋの積を、変数Ｘに足す。そして、処理はステップＳ５１６に戻る。
さて、図１１ＣのステップＳ５２０で温度評価部３ａは、サーバｓｉと同一ラック内の未選択の他のシャーシがあるか否かを判断する。つまり、温度評価部３ａは、以下の３つの条件をすべて満たすエントリがシャーシテーブル２０４にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ５１４またはＳ５１５で取得されたラックＩＤと等しい。
・「シャーシＩＤ」フィールドの値が、サーバテーブル２０３においてサーバｓｉに対応するエントリの「シャーシＩＤ」フィールドの値とは異なる。
・ステップＳ５２２〜Ｓ５２５の処理対象としてまだステップＳ５２１で選択されていない。
もし上記３つの条件をすべて満たすエントリがあれば、処理はステップＳ５２１に移行する。逆に、上記３つの条件をすべて満たすエントリがなければ、処理はステップＳ５２６に移行する。
サーバｓｉがラックマウント型サーバの場合、上記３つの条件をすべて満たすエントリは、サーバｓｉと同じラックに搭載された、未選択のシャーシに対応する。逆に、サーバｓｉがブレード型サーバの場合、上記３つの条件をすべて満たすエントリは、サーバｓｉと同じラックに搭載されていて、かつ、サーバｓｉを搭載したシャーシとは異なる未選択のシャーシに対応する。
ステップＳ５２１で温度評価部３ａは、サーバｓｉと同一ラック内の未選択の他のシャーシを１つ選択する。つまり、温度評価部３ａは、ステップＳ５２０の上記３つの条件すべてを満たすエントリに対応するシャーシを１つ選択する。
次に、ステップＳ５２２で温度評価部３ａは、ステップＳ５２１で選択したシャーシ内の未選択のサーバがあるか否かを判断する。つまり、温度評価部３ａは、以下の３つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ５１４またはＳ５１５で取得されたラックＩＤと等しい。
・「シャーシＩＤ」フィールドの値が、ステップＳ５２１で選択したシャーシのシャーシＩＤと等しい。
・ステップＳ５２４〜Ｓ５２５の処理対象としてまだステップＳ５２３で選択されていない。
もし上記の３つの条件をすべて満たすエントリがあれば、処理はステップＳ５２３に移行する。逆に、上記の３つの条件をすべて満たすエントリがなければ、処理はステップＳ５２０に戻る。
ステップＳ５２３で温度評価部３ａは、ステップＳ５２１で選択したシャーシ内の未選択のサーバを１つ選択する。つまり、温度評価部３ａは、ステップＳ５２２の上記３つの条件をすべて満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ５２４〜Ｓ５２５の説明においては、ステップＳ５２３で選択されたサーバを「サーバｓｊ」という。ステップＳ５２３で選択されるサーバｓｊは、式（７）の集合ｒａｃｋ（ｓｉ）に属するブレード型サーバである。
次に、ステップＳ５２４で温度評価部３ａは、ステップＳ５２３で選択したサーバｓｊに現在温度異常が発生中か否かを判断する。温度評価部３ａは、イベント管理テーブルを参照することで、ステップＳ５０１と同様にして、ステップＳ５２４の判断を行うことができる。
現在サーバｓｊに温度異常が発生中の場合、処理はステップＳ５２５に移行する。逆に、現在サーバｓｊに温度異常が発生していなければ、処理はステップＳ５２２に戻る。
ステップＳ５２５で温度評価部３ａは、サーバｓｊに発生中の温度異常の重み（つまり式（１）の第４項における重みｗｔｍｐｒ（ｓｊ））を取得する。具体的には、温度評価部３ａは、ステップＳ５２４の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、温度評価部３ａは、読み取った値に対応する重みを取得する。さらに温度評価部３ａは、取得した重みとラック係数Ｃｒａｃｋの積を、変数Ｘに足す。そして、処理はステップＳ５２２に戻る。
以上の説明から明らかなとおり、ステップＳ５２６の実行時点において、変数Ｘには、式（１）の温度評価値ｆｔｍｐｒ（ｓｉ）が格納されている。よって、ステップＳ５２６で温度評価部３ａは、変数Ｘの値を、サーバｓｉの温度評価値ｆｔｍｐｒ（ｓｉ）として記録する。つまり、温度評価部３ａは、結果テーブル中の、サーバｓｉに対応するエントリの「温度評価値」フィールドに、変数Ｘの値を記録する。そして、図１１Ａ〜１１Ｃの温度評価処理は終了する。
さて、図１２Ａ〜１２Ｂは、電圧評価処理のフローチャートである。第１実施形態では、図９のステップＳ４０２で電圧評価部３ｂがサーバｓｉに関して電圧評価処理を実行する。
ステップＳ６０１で電圧評価部３ｂは、現在サーバｓｉに電圧異常が発生中か否かを判断する。もし、イベント管理テーブルの中に、以下の３つの条件をすべて満たすエントリが存在すれば、サーバｓｉに現在電圧異常が発生中である。逆に、以下の３つの条件をすべて満たすエントリが存在しなければ、現在サーバｓｉに電圧異常は発生していない。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが電圧異常（具体的には、電圧低下または電圧超過）を示している。
・「終了時刻」フィールドに無効な値が記録されている。
電圧評価部３ｂは、イベント管理テーブルから上記３つの条件をすべて満たすエントリを探すことで、ステップＳ６０１の判断を行う。そして、現在サーバｓｉに電圧異常が発生中の場合、処理はステップＳ６０２に移行する。逆に、現在サーバｓｉに電圧異常が発生していなければ、処理はステップＳ６０３に移行する。
ステップＳ６０２で電圧評価部３ｂは、サーバｓｉに発生中の電圧異常の重み（つまり式（８）の重みｗｖｏｌ（ｓｉ））を取得する。具体的には、電圧評価部３ｂは、ステップＳ６０１の検索で見つかったエントリの「イベントのレベル」フィールドの値を読み取り、読み取った値に対応する重みを取得する。
さらに電圧評価部３ｂは、取得した重みと自己係数Ｃｓｅｌｆの積を、電圧評価値用の変数Ｘに代入する。そして、処理はステップＳ６０４に移行する。
他方、ステップＳ６０３で電圧評価部３ｂは、電圧評価用の変数Ｘに単に０を代入する。そして、処理はステップＳ６０４に移行する。以上のステップＳ６０２またはＳ６０３により、式（８）の第１項の値が変数Ｘに格納される。
ステップＳ６０４で電圧評価部３ｂは、図７のサーバテーブル２０３を参照することで、サーバｓｉの種別がブレード型かラックマウント型かを判断する。ステップＳ６０４の判断は、図１１ＡのステップＳ５０４の判断と類似である。
サーバｓｉがブレード型サーバの場合、処理はステップＳ６０５に移行する。逆に、サーバｓｉがラックマウント型の場合、処理はステップＳ６０７に移行する。
ステップＳ６０５で電圧評価部３ｂは、サーバｓｉのサーバＩＤを検索キーとして用いて、サーバｓｉのシャーシＩＤをサーバテーブル２０３から取得する。
そして、次のステップＳ６０６で電圧評価部３ｂは、ステップＳ６０５で取得したシャーシＩＤから、ラックＩＤとラック内電源ＩＤを取得する。具体的には、電圧評価部３ｂは、「シャーシＩＤ」フィールドの値がステップＳ６０５で取得したシャーシＩＤと同じエントリを、図７のシャーシテーブル２０４において探す。そして、電圧評価部３ｂは、見つかったエントリの「ラックＩＤ」フィールドと「ラック内電源ＩＤ」フィールドの値を取得する。
サーバｓｉがブレード型サーバの場合、ステップＳ６０５〜Ｓ６０６の結果として、「サーバｓｉを搭載したシャーシには、ラック内のどの電源ユニットから電力が供給されるのか」ということが特定される。ラックＩＤとラック内電源ＩＤの取得後、処理はステップＳ６０８に移行する。
他方、電圧評価値を算出する対象のサーバｓｉがラックマウント型の場合、電圧評価部３ｂはステップＳ６０７で、サーバｓｉのＩＤを用いて、ラックＩＤとラック内電源ＩＤを取得する。具体的には、電圧評価部３ｂは、「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しいエントリをサーバテーブル２０３において探す。そして、電圧評価部３ｂは、見つかったエントリの「ラックＩＤ」フィールドと「ラック内電源ＩＤ」フィールドの値を取得する。
サーバｓｉがラックマウント型サーバの場合、ステップＳ６０７の結果として、「サーバｓｉには、ラック内のどの電源ユニットから電力が供給されるのか」ということが特定される。ラックＩＤとラック内電源ＩＤの取得後、処理はステップＳ６０８に移行する
ステップＳ６０８で電圧評価部３ｂは、サーバｓｉと同じラック内で同じラック内電源を使う未選択のラックマウント型サーバがあるか否かを判断する。つまり、電圧評価部３ｂは、以下の４つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ６０６またはＳ６０７で取得されたラックＩＤと等しい。
・「ラック内電源ＩＤ」フィールドの値が、ステップＳ６０６またはＳ６０７で取得されたラック内電源ＩＤと等しい。
・「サーバＩＤ」フィールドの値が、サーバｓｉのＩＤとは異なる。
・ステップＳ６１０〜Ｓ６１１の処理対象としてまだステップＳ６０９で選択されていない。
もし上記４つの条件をすべて満たすエントリがあれば、処理はステップＳ６０９に移行する。逆に、上記４つの条件をすべて満たすエントリがなければ、処理は図１２ＢのステップＳ６１２に移行する。
ステップＳ６０９で電圧評価部３ｂは、サーバｓｉと同一ラック内の未選択のラックマウント型サーバを１つ選択する。つまり、電圧評価部３ｂは、ステップＳ６０８の上記４つの条件をすべて満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ６１０〜Ｓ６１１の説明においては、ステップＳ６０９で選択されたサーバを「サーバｓｊ」という。ステップＳ６０９で選択されるサーバｓｊは、式（１１）の集合ｐｏｗｅｒ（ｓｉ）に属するラックマウント型サーバである。
次に、ステップＳ６１０で電圧評価部３ｂは、ステップＳ６０９で選択したサーバｓｊに現在電圧異常が発生中か否かを判断する。電圧評価部３ｂは、イベント管理テーブルを参照することで、ステップＳ６０１と同様にして、ステップＳ６１０の判断を行うことができる。
現在サーバｓｊに電圧異常が発生中の場合、処理はステップＳ６１１に移行する。逆に、現在サーバｓｊに電圧異常が発生していなければ、処理はステップＳ６０８に戻る。
ステップＳ６１１で電圧評価部３ｂは、サーバｓｊに発生中の電圧異常の重み（つまり式（８）の第２項における重みｗｖｏｌ（ｓｊ））を取得する。具体的には、電圧評価部３ｂは、ステップＳ６１０の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、電圧評価部３ｂは、読み取った値に対応する重みを取得する。さらに電圧評価部３ｂは、取得した重みと同一電源係数Ｃｐｏｗｅｒの積を、変数Ｘに足す。そして、処理はステップＳ６０８に戻る。
さて、図１２ＢのステップＳ６１２で電圧評価部３ｂは、サーバｓｉと同一ラック内の未選択のシャーシがあるか否かを判断する。つまり、電圧評価部３ｂは、以下の３つの条件をすべて満たすエントリがシャーシテーブル２０４にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ６０６またはＳ６０７で取得されたラックＩＤと等しい。
・「ラック内電源ＩＤ」フィールドの値が、ステップＳ６０６またはＳ６０７で取得されたラック内電源ＩＤと等しい。
・ステップＳ６１４〜Ｓ６１７の処理対象としてまだステップＳ６１３で選択されていない。
もし上記３つの条件をすべて満たすエントリがあれば、処理はステップＳ６１３に移行する。逆に、上記３つの条件をすべて満たすエントリがなければ、処理はステップＳ６１８に移行する。
サーバｓｉがラックマウント型サーバの場合、上記３つの条件をすべて満たすエントリは、サーバｓｉと同じラックに搭載された、未選択のシャーシに対応する。逆に、サーバｓｉがブレード型サーバの場合、上記３つの条件をすべて満たすエントリは、サーバｓｉと同じラックに搭載されている未選択のシャーシ（サーバｓｉが搭載されているシャーシのこともあるし、他のシャーシのこともある）に対応する。
ステップＳ６１３で電圧評価部３ｂは、サーバｓｉと同一ラック内の未選択のシャーシを１つ選択する。つまり、電圧評価部３ｂは、ステップＳ６１２の上記３つの条件すべてを満たすエントリに対応するシャーシを１つ選択する。
次に、ステップＳ６１４で電圧評価部３ｂは、ステップＳ６１３で選択したシャーシ内の未選択のサーバ（ただしサーバｓｉ以外）があるか否かを判断する。つまり、電圧評価部３ｂは、以下の４つの条件をすべて満たすエントリがサーバテーブル２０３にあるか否かを判断する。
・「ラックＩＤ」フィールドの値が、ステップＳ６０６またはＳ６０７で取得されたラックＩＤと等しい。
・「シャーシＩＤ」フィールドの値が、ステップＳ６１３で選択されたシャーシのシャーシＩＤと等しい。
・「サーバＩＤ」フィールドの値が、サーバｓｉのＩＤと異なる。
・ステップＳ６１６〜Ｓ６１７の処理対象としてまだステップＳ６１５で選択されていない。
もし上記４つの条件をすべて満たすエントリがあれば、処理はステップＳ６１５に移行する。逆に、上記４つの条件をすべて満たすエントリがなければ、処理はステップＳ６１２に戻る。
ステップＳ６１５で電圧評価部３ｂは、ステップＳ６１３で選択したシャーシ内の未選択のサーバを１つ選択する。つまり、電圧評価部３ｂは、ステップＳ６１４の上記４つの条件をすべて満たすエントリに対応するサーバを１つ選択する。
便宜上、以下のステップＳ６１６〜Ｓ６１７の説明においては、ステップＳ６１５で選択されたサーバを「サーバｓｊ」という。ステップＳ６１５で選択されるサーバｓｊは、式（１１）の集合ｐｏｗｅｒ（ｓｉ）に属するブレード型サーバである。
次に、ステップＳ６１６で電圧評価部３ｂは、ステップＳ６１５で選択したサーバｓｊに現在電圧異常が発生中か否かを判断する。電圧評価部３ｂは、イベント管理テーブルを参照することで、ステップＳ６０１と同様にして、ステップＳ６１６の判断を行うことができる。
現在サーバｓｊに電圧異常が発生中の場合、処理はステップＳ６１７に移行する。逆に、現在サーバｓｊに電圧異常が発生していなければ、処理はステップＳ６１４に戻る。
ステップＳ６１７で電圧評価部３ｂは、サーバｓｊに発生中の電圧異常の重み（つまり式（８）の第２項における重みｗｖｏｌ（ｓｊ））を取得する。具体的には、電圧評価部３ｂは、ステップＳ６１６の判断のための検索の結果としてイベント管理テーブルにおいて見つかったエントリの「イベントのレベル」フィールドの値を読み取る。そして、電圧評価部３ｂは、読み取った値に対応する重みを取得する。さらに電圧評価部３ｂは、取得した重みと同一電源係数Ｃｐｏｗｅｒの積を、変数Ｘに足す。そして、処理はステップＳ６１４に戻る。
以上の説明から明らかなとおり、ステップＳ６１８の実行時点において、変数Ｘには、式（８）の電圧評価値ｆｖｏｌ（ｓｉ）が格納されている。よって、ステップＳ６１８で電圧評価部３ｂは、変数Ｘの値を、サーバｓｉの電圧評価値ｆｖｏｌ（ｓｉ）として記録する。つまり、電圧評価部３ｂは、結果テーブル中の、サーバｓｉに対応するエントリの「電圧評価値」フィールドに、変数Ｘの値を記録する。そして、図１２Ａ〜１２Ｂの電圧評価処理は終了する。
さて次に、図９、１１Ａ〜１１Ｃ、および１２Ａ〜１２Ｂのフローチャートに示した処理によって算出される評価値の具体例を、図８および１０を参照しながら説明する。
図１０の結果テーブル２０６ａは、２０１１年１月２日９時３０分に、スタンバイサーバ３０−２〜３０−７のそれぞれについて図９の総合評価処理が実行された直後の状態を示す。
図８のイベント管理テーブル２０５ｂに示すように、２０１１年１月２日９時３０分には、スタンバイサーバ３０−２で温度異常が発生中である。しかし、２０１１年１月２日９時３０分には、他のスタンバイサーバ３０−３、３０−４、３０−５、３０−６、および３０−７は正常であり、アクティブサーバ３０−１も正常である。また、係数２０１と重み２０２の値は図６のとおりとする。
すると、サーバ３０−２に関して図９のステップＳ４０１で算出される温度評価値は、２００（＝ＣｓｅｌｆＷ２＋０＋０＋０＝１００×２）である。また、サーバ３０−２に関してステップＳ４０２で算出される電圧評価値は０である。
そして、サーバ３０−２では、２０１１年１月２日９時３０分に温度異常が発生中だが、当該温度異常以外の異常は、２０１１年１月２日９時３０分までには発生したことがない。つまり、サーバ３０−２では今まで温度異常のみが発生したことがあり、電圧異常は発生したことがない。
また、補正定数εは図６のとおり非常に小さい。よって、式（３７）で近似されるとおり、サーバ３０−２の総合評価値は、約２００（＝１×２００＋０×０）である。結果テーブル２０６ａにおいてサーバＩＤが「２」のエントリには、以上のようにして算出された２００、０、および２００という３つの値が記録される。
また、サーバ３０−３に関してステップＳ４０１で算出される温度評価値は、１２（＝０＋ＣａｄｊＷ２＋０＋０＝６×２）である。サーバ３０−３に関してステップＳ４０２で算出される電圧評価値は０である。
そして、サーバ３０−３では２０１１年１月２日９時３０分までに何の異常も発生していない。したがって、式（３８）に示すとおり、サーバ３０−３の総合評価値は、６（＝１／２×１２＋１／２×０）である。結果テーブル２０６ａにおいてサーバＩＤが「３」のエントリには、以上のようにして算出された１２、０、および６という３つの値が記録される。
また、サーバ３０−４〜３０−７のいずれに関しても、ステップＳ４０１で算出される温度評価値が０であり、ステップＳ４０２で算出される電圧評価値が０である。そのため、サーバ３０−４〜３０−７のいずれの総合評価値も、０である。したがって、結果テーブル２０６ａにおいてサーバＩＤが「３」、「４」、「５」、「６」、および「７」のエントリのいずれにおいても、以上のようにして算出された０、０、および０という３つの値が記録される。
以上のようにして得られる結果テーブル２０６ａによれば、将来故障が発生する蓋然性は、総合評価値が０のサーバ３０−３〜３０−７において最も低い。したがって、仮に２０１１年１月２日９時３０分にアクティブサーバ３０−１が故障した場合は、フェイルオーバ制御部４は、サーバ３０−３〜３０−７のいずれかを新たなアクティブサーバとして選択する。
ところで、アクティブサーバ３０−１が正常なままの場合もある。例えば、管理ＤＢ５内のイベント管理テーブルは、２０１１年１月２日１１時１０分においても図８のイベント管理テーブル２０５ｂの状態のままであり、変わっていないとする。この場合、アクティブサーバ３０−１は２０１１年１月２日１１時１０分の時点において、なお正常である。
図１０の結果テーブル２０６ｂは、２０１１年１月２日１１時１０分に、スタンバイサーバ３０−２〜３０−７のそれぞれについて図９の総合評価処理が実行された直後の状態を示す。
図８のイベント管理テーブル２０５ｂに示すように、２０１１年１月２日１１時１０分には、スタンバイサーバ３０−２で温度異常が発生中であり、スタンバイサーバ３０−４と３０−６で電圧異常が発生中である。しかし、２０１１年１月２日１１時１０分には、他のスタンバイサーバ３０−３、３０−５、および３０−７は正常であり、アクティブサーバ３０−１も正常である。また、係数２０１と重み２０２の値は図６のとおりとする。
すると、サーバ３０−２と３０−３に関する算出結果は、結果テーブル２０６ａに示した２０１１年１月２日９時３０分の算出結果と同じである。また、サーバ３０−４〜３０−７に関して図９のステップＳ４０１で算出される温度評価値も、結果テーブル２０６ａと同様である。
他方、サーバ３０−４に関して図９のステップＳ４０２で算出される電圧評価値は、６００（＝ＣｓｅｌｆＷ３＋０＝１００×６）である。そして、サーバ３０−４では、２０１１年１月２日１１時１０分に電圧異常が発生中だが、当該電圧異常以外の異常は、２０１１年１月２日１１時１０分までには発生したことがない。つまり、サーバ３０−４では電圧異常のみが発生したことがあり、温度異常は発生したことがない。
また、補正定数εは図６のとおり非常に小さい。よって、式（３７）で近似されるとおり、サーバ３０−４の総合評価値は、約６００（＝０×０＋１×６００）である。結果テーブル２０６ｂにおいてサーバＩＤが「４」のエントリには、以上のようにして算出された０、６００、および６００という３つの値が記録される。
また、サーバ３０−５に関してステップＳ４０２で算出される電圧評価値は、６０（＝０＋ＣｐｏｗｅｒＷ３＝１０×６）である。そして、サーバ３０−５では２０１１年１月２日１１時１０分までに何の異常も発生していない。したがって、式（３８）に示すとおり、サーバ３０−５の総合評価値は、３０（＝１／２×０＋１／２×６０）である。結果テーブル２０６ｂにおいてサーバＩＤが「５」のエントリには、以上のようにして算出された０、６０、および３０という３つの値が記録される。
そして、サーバ３０−６に関してステップＳ４０２で算出される電圧評価値は、１００（＝ＣｓｅｌｆＷ１＋０＝１００×１）である。また、サーバ３０−６では、２０１１年１月２日１１時１０分に電圧異常が発生中であり、２０１１年１月１日１１時から２０１１年１月１日１２時までの間にも、電圧異常が発生していた。しかし、サーバ３０−６において温度異常が発生したことはない。
また、補正定数εは図６のとおり非常に小さい。よって、式（３７）で近似されるとおり、サーバ３０−６の総合評価値は、約１００（＝０×０＋１×１００）である。結果テーブル２０６ｂにおいてサーバＩＤが「６」のエントリには、以上のようにして算出された０、１００、および１００という３つの値が記録される。
そして、サーバ３０−７に関してステップＳ４０２で算出される電圧評価値は、１０（＝０＋ＣｐｏｗｅｒＷ１＝１０×１）である。また、サーバ３０−７では２０１１年１月２日１１時１０分までに何の異常も発生していない。したがって、式（３８）に示すとおり、サーバ３０−７の総合評価値は５（＝１／２×０＋１／２×１０）である。結果テーブル２０６ｂにおいてサーバＩＤが「７」のエントリには、以上のようにして算出された０、１０、５という３つの値が記録される。
以上のようにして得られる結果テーブル２０６ｂによれば、将来故障が発生する蓋然性は、総合評価値が５のサーバ３０−７において最も低い。よって、仮に結果テーブル２０６ｂが更新される前にアクティブサーバ３０−１が故障し、当該故障を機に図５にしたがってフェイルオーバ処理が行われる場合は、フェイルオーバ制御部４は、サーバ３０−７を新たなアクティブサーバとして選択する。
続いて、図１３〜１６を参照して、第２実施形態について説明する。第２実施形態では式（３０）の総合評価値ｆｔｏｔａｌ（ｓｉ）が算出される。具体的には、第２実施形態の算出部３は、図１３のフローチャートにしたがって動作する。
図１３は、第２実施形態での総合評価処理のフローチャートである。図１３の総合評価処理は、図１のステップＳ１０６で算出部３が実行する。より具体的には、フェイルオーバ処理が図４のように行われる場合は、図４のステップＳ２０３で算出部３が図１３の総合評価処理を実行し、フェイルオーバ処理が図５のように行われる場合は、図５の処理と独立して算出部３が適宜のタイミングで図１３の総合評価処理を実行する。
また、図１３の総合評価処理は、ある１台のサーバ（説明の便宜上、「サーバｓｉ」とする）に関して実行される。例えば、フェイルオーバ制御部４が、サーバｓｉのＩＤを算出部３に指定して、算出部３に総合評価処理の実行を命じてもよい。あるいは、算出部３が定期的に各サーバｓｉについて図１３の総合評価処理を実行してもよい。
いつ図１３の総合評価処理が実行されるにせよ、第２実施形態では、管理ＤＢ５が図１６のような結果テーブルを含む。図１６の結果テーブルの詳細は後述するが、図１６に示すとおり、第２実施形態の結果テーブルの各エントリは、サーバＩＤ、温度評価値、電圧評価値、劣化評価値、および総合評価値という、５個のフィールドを含む。また、結果テーブルの各エントリは、各スタンバイサーバに対応する。図１３の総合評価処理の進捗にともなって、結果テーブルは更新される。
図１３のステップＳ７０１〜Ｓ７０２は、図９のステップＳ４０１〜Ｓ４０２と同様なので、詳しい説明を省略する。
次のステップＳ７０３で算出部３は、サーバｓｉのＩＤを劣化評価部３ｄに指定し、図１４Ａ〜１４Ｂの劣化評価処理の実行を劣化評価部３ｄに命じる。すると、劣化評価部３ｄは、図１４Ａ〜１４Ｂのフローチャートにしたがって、式（１２）の劣化評価値ｆｄｇｒ（ｓｉ）を算出する。そして、劣化評価部３ｄは、結果テーブル中の、サーバｓｉに対応するエントリの劣化評価値のフィールドに、算出結果を記録する。
また、次のステップＳ７０４では、総合評価部３ｃが、図９のステップＳ４０３〜Ｓ４１０と同様にして、温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）それぞれの影響の割合を算出する。
そして、ステップＳ７０５で総合評価部３ｃは、算出した割合を用いて温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）を重み付けした値（すなわち式（３４）のｆｔｏｔ（ｓｉ））を、算出する。ステップＳ７０５での重み付け和の算出方法は、図９のステップＳ４１１と同様である。
最後にステップＳ７０６で総合評価部３ｃは、ステップＳ７０５で算出した値ｆｔｏｔ（ｓｉ）に、ステップＳ７０３で結果テーブルに記録された劣化評価値ｆｄｇｒ（ｓｉ）を加算することにより、総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。つまり、総合評価部３ｃは、式（３０）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。
そして、総合評価部３ｃは、結果テーブル中の、サーバｓｉに対応するエントリの総合評価値のフィールドに、算出結果を記録する。すると、図１３の総合評価処理は終了する。
さて、図１４Ａ〜１４Ｂは、劣化評価処理のフローチャートである。第２実施形態では、図１３のステップＳ７０３で劣化評価部３ｄが劣化評価処理を実行する。
ステップＳ８０１で劣化評価部３ｄは、電源投入時間の長さを示す変数Ｘｏｎと、電源停止時間の長さを示す変数Ｘｏｆｆと、劣化評価値用の変数Ｘｄｇｒを、それぞれ０に初期化する。
次に、ステップＳ８０２で劣化評価部３ｄは、ステップＳ８０３〜Ｓ８０４の処理対象として未選択の、サーバｓｉでの電源ＯＮイベントがあるか否かを判断する。具体的には、劣化評価部３ｄは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、電源ＯＮを示している。
・ステップＳ８０３〜Ｓ８０４の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ８０３に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合、処理はステップＳ８０５に移行する。
ステップＳ８０３で劣化評価部３ｄは、サーバｓｉでの未選択の電源ＯＮイベントを１つ選択する。つまり、劣化評価部３ｄは、サーバｓｉでの電源ＯＮイベントに関する未選択のエントリ（すなわち上記３つの条件をすべて満たすエントリ）を１つ選択する。
そして、劣化評価部３ｄは、選択したエントリから、当該電源ＯＮイベントの開始時刻と終了時刻を取得する。なお、選択したエントリに有効な終了時刻の値が記録されていない場合は、サーバｓｉは現在電源が投入された状態なので、劣化評価部３ｄは、終了時刻の代わりに現在時刻を取得する。
そして、ステップＳ８０４で劣化評価部３ｄは、選択したエントリに対応する電源投入時間の長さを算出する。つまり、劣化評価部３ｄは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。そして、劣化評価部３ｄは、減算により得た値を、変数Ｘｏｎに足す。その後、処理はステップＳ８０２に戻る。
ステップＳ８０２〜Ｓ８０４の繰り返しループの結果として、ステップＳ８０５の実行時点では、「Ｘｏｎ＝ｔｏｎ（ｓｉ）」という式が成り立つ（式（１２）を参照）。
ステップＳ８０５で劣化評価部３ｄは、図６の電源投入係数Ｃｏｎを取得する。そして、劣化評価部３ｄは、電源投入係数Ｃｏｎと変数Ｘｏｎの値との積を算出し、算出した値を変数Ｘｄｇｒに足す。その結果、変数Ｘｄｇｒには、式（１２）の第１項の値が格納される。
次に、ステップＳ８０６で劣化評価部３ｄは、ステップＳ８０７〜Ｓ８０８の処理対象として未選択の、サーバｓｉでの電源ＯＦＦイベントがあるか否かを判断する。具体的には、劣化評価部３ｄは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、電源ＯＦＦを示している。
・ステップＳ８０７〜Ｓ８０８の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ８０７に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合、処理はステップＳ８０９に移行する。
ステップＳ８０７で劣化評価部３ｄは、サーバｓｉでの未選択の電源ＯＦＦイベントを１つ選択する。つまり、劣化評価部３ｄは、サーバｓｉでの電源ＯＦＦイベントに関する未選択のエントリ（すなわち上記３つの条件をすべて満たすエントリ）を１つ選択する。
そして、劣化評価部３ｄは、選択したエントリから、当該電源ＯＦＦイベントの開始時刻と終了時刻を取得する。なお、選択したエントリに有効な終了時刻の値が記録されていない場合は、サーバｓｉは現在電源が切られた状態なので、劣化評価部３ｄは、終了時刻の代わりに現在時刻を取得する。
そして、ステップＳ８０８で劣化評価部３ｄは、選択したエントリに対応する電源停止時間の長さを算出する。つまり、劣化評価部３ｄは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。そして、劣化評価部３ｄは、減算により得た値を、変数Ｘｏｆｆに足す。その後、処理はステップＳ８０６に戻る。
ステップＳ８０６〜Ｓ８０８の繰り返しループの結果として、ステップＳ８０９の実行時点では、「Ｘｏｆｆ＝ｔｏｆｆ（ｓｉ）」という式が成り立つ（式（１２）を参照）。
ステップＳ８０９で劣化評価部３ｄは、図６の経年劣化係数Ｃｏｆｆを取得する。そして、劣化評価部３ｄは、経年劣化係数Ｃｏｆｆと変数Ｘｏｆｆの値との積を算出し、算出した値を変数Ｘｄｇｒに足す。その結果、変数Ｘｄｇｒには、式（１２）の第１項と第２項の和が格納される。
次に、図１４ＢのステップＳ８１０で劣化評価部３ｄは、温度異常による劣化の評価用の（つまり式（１２）と（１３）のｆｄｇｒＴｍｐｒ（ｓｉ）を示すための）変数Ｘｔを０に初期化する。また、劣化評価部３ｄは、電圧超過による劣化の評価用の（つまり式（１２）と（１４）のｆｄｇｒＯｖｅｒｖｏｌ（ｓｉ）を示すための）変数Ｘｖも、０に初期化する。
そして、ステップＳ８１１で劣化評価部３ｄは、ステップＳ８１２〜Ｓ８１３の処理対象として未選択の、サーバｓｉでの温度異常イベントがあるか否かを判断する。具体的には、劣化評価部３ｄは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、温度異常を示している。
・ステップＳ８１２〜Ｓ８１３の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ８１２に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合、処理はステップＳ８１４に移行する。
ステップＳ８１２で劣化評価部３ｄは、サーバｓｉでの未選択の温度異常イベントを１つ選択する。つまり、劣化評価部３ｄは、サーバｓｉでの温度異常イベントに関する未選択のエントリ（すなわち上記３つの条件をすべて満たすエントリ）を１つ選択する。
そして、劣化評価部３ｄは、選択したエントリから、当該温度異常イベントの開始時刻と終了時刻を取得する。なお、選択したエントリに有効な終了時刻の値が記録されていない場合は、当該温度異常イベントがまだ終熄していないので、劣化評価部３ｄは、終了時刻の代わりに現在時刻を取得する。
そして、ステップＳ８１３で劣化評価部３ｄは、選択した温度異常が続いた時間の長さを算出する。つまり、劣化評価部３ｄは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。
さらに、劣化評価部３ｄは、選択した温度異常イベントの重みを取得する。具体的には、劣化評価部３ｄは、選択したエントリの「イベントのレベル」フィールドの値を読み取り、読み取った値に対応する重みを取得する。
そして、劣化評価部３ｄは、算出した時間の長さと取得した重みとの積を、変数Ｘｔに足す。その後、処理はステップＳ８１１に戻る。
ステップＳ８１１〜Ｓ８１３の繰り返しループの結果として、ステップＳ８１４の実行時点における変数Ｘｔには、式（１３）において図６の温度依存劣化係数ＣｄｇｒＴｍｐｒに掛けられる乗数が、格納されている。
ステップＳ８１４で劣化評価部３ｄは、温度依存劣化係数ＣｄｇｒＴｍｐｒを取得する。そして、劣化評価部３ｄは、温度依存劣化係数ＣｄｇｒＴｍｐｒと変数Ｘｔの値との積を算出し、算出した値を変数Ｘｄｇｒに足す。その結果、変数Ｘｄｇｒには、式（１２）の第１項から第３項までの和が格納される。
次に、ステップＳ８１５で劣化評価部３ｄは、ステップＳ８１６〜Ｓ８１７の処理対象として未選択の、サーバｓｉでの電圧超過イベントがあるか否かを判断する。具体的には、劣化評価部３ｄは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、電圧超過を示している。
・ステップＳ８１６〜Ｓ８１７の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ８１６に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合、処理はステップＳ８１８に移行する。
ステップＳ８１６で劣化評価部３ｄは、サーバｓｉでの未選択の電圧超過イベントを１つ選択する。つまり、劣化評価部３ｄは、サーバｓｉでの電圧超過イベントに関する未選択のエントリ（すなわち上記３つの条件をすべて満たすエントリ）を１つ選択する。
そして、劣化評価部３ｄは、選択したエントリから、当該電圧超過イベントの開始時刻と終了時刻を取得する。なお、選択したエントリには有効な終了時刻の値が記録されていない場合は、選択された電圧超過イベントはサーバｓｉにおいてまだ終熄していないので、劣化評価部３ｄは、終了時刻の代わりに現在時刻を取得する。
そして、ステップＳ８１７で劣化評価部３ｄは、選択した電圧超過が続いた時間の長さを算出する。つまり、劣化評価部３ｄは、取得した終了時刻または現在時刻から、取得した開始時刻を引く。
さらに、劣化評価部３ｄは、選択した電圧超過イベントの重みを取得する。具体的には、劣化評価部３ｄは、選択したエントリの「イベントのレベル」フィールドの値を読み取り、読み取った値に対応する重みを取得する。
そして、劣化評価部３ｄは、算出した時間の長さと取得した重みとの積を、変数Ｘｖに足す。その後、処理はステップＳ８１５に戻る。
ステップＳ８１５〜Ｓ８１７の繰り返しループの結果として、ステップＳ８１８の実行時点において変数Ｘｖに格納されている値は、式（１４）において図６の電圧依存劣化係数ＣｄｇｒＯｖｅｒｖｏｌに掛けられる乗数である。
ステップＳ８１８で劣化評価部３ｄは、電圧依存劣化係数ＣｄｇｒＯｖｅｒｖｏｌを取得する。そして、劣化評価部３ｄは、電圧依存劣化係数ＣｄｇｒＯｖｅｒｖｏｌと変数Ｘｖの値との積を算出し、算出した値を変数Ｘｄｇｒに足す。その結果、変数Ｘｄｇｒには、式（１２）の劣化評価値ｆｄｇｒ（ｓｉ）が格納される。
最後に、ステップＳ８１９で劣化評価部３ｄは、変数Ｘｄｇｒの値を、サーバｓｉの劣化評価値ｆｄｇｒ（ｓｉ）として記録する。つまり、劣化評価部３ｄは、結果テーブル中の、サーバｓｉに対応するエントリの「劣化評価値」フィールドに、変数Ｘｄｇｒの値を記録する。そして、図１４Ａ〜１４Ｂの劣化評価処理は終了する。
さて、図１５は、管理ＤＢに含まれるイベント管理テーブルの例を示す図である。図１５には、２０１１年１月３日１１時におけるイベント管理テーブル２０５ｃが例示されている。図８のイベント管理テーブル２０５ｂと比べると、イベント管理テーブル２０５ｃでは、１２番目と１４番目と１５番目のエントリの終了時刻が更新されており、１６番目と１７番目のエントリが追加されている。
具体的には、２０１１年１月２日１２時にサーバ管理装置３１−６は、サーバ３０−６の電圧が正常に戻ったことを検出する。すると、サーバ管理装置３１−６は、サーバ３０−６の電圧低下からの復旧を収集部２に通知する。通知に応じて、収集部２は、１５番目のエントリの終了時刻を２０１１年１月２日１２時に更新する。
また、２０１１年１月３日１０時にサーバ管理装置３１−２は、サーバ３０−２の温度が正常に戻ったことを検出する。すると、サーバ管理装置３１−２は、サーバ３０−２の温度異常からの復旧を収集部２に通知する。通知に応じて、収集部２は、１２番目のエントリの終了時刻を２０１１年１月３日１０時に更新する。
さらに、２０１１年１月３日１０時にサーバ管理装置３１−４は、サーバ３０−４の電圧が正常に戻ったことを検出する。すると、サーバ管理装置３１−４は、サーバ３０−４の電圧低下からの復旧を収集部２に通知する。通知に応じて、収集部２は、１４番目のエントリの終了時刻を２０１１年１月３日１０時に更新する。
その後、２０１１年１月３日１１時には、サーバ管理装置３１−２が、サーバ３０−２の温度異常を検出し、検出結果を収集部２に通知する。すると、収集部２は、サーバ管理装置３１−２からの通知に基づいて、サーバ３０−２に「Ｍｉｎｏｒ」レベルの「温度異常」イベントが発生したことを認識する。認識の結果、収集部２は、１６番目のエントリを生成する。図１５において、１６番目のエントリの終了時刻は無効な値である。
さらに、２０１１年１月３日１１時には、サーバ管理装置３１−４が、サーバ３０−４の電圧超過を検出し、検出結果を収集部２に通知する。すると、収集部２は、サーバ管理装置３１−４からの通知に基づいて、サーバ３０−４に「Ｍａｊｏｒ」レベルの「電圧超過」イベントが発生したことを認識する。認識の結果、収集部２は、１７番目のエントリを生成する。図１５において、１７番目のエントリの終了時刻は無効な値である。
さて次に、第２実施形態で算出される評価値の具体例を、図１５および図１６を参照しながら説明する。図１６の結果テーブル２０６ｃは、２０１１年１月３日１０時３０分に、スタンバイサーバ３０−２〜３０−７のそれぞれについて図１３の総合評価処理が実行された直後の状態を示す。
図１５のイベント管理テーブル２０５ｃに示すように、２０１１年１月３日１０時３０分には、サーバ３０−１〜３０−７のいずれも正常である。また、係数２０１と重み２０２の値は図６のとおりとする。
すると、サーバ３０−２〜３０−７のいずれに関しても、図１３のステップＳ７０１で算出される温度評価値は、０である。また、サーバ３０−２〜３０−７のいずれに関しても、ステップＳ７０２で算出される電圧評価値は、０である。よって、サーバ３０−２〜３０−７のいずれに関しても、ステップＳ７０５で算出される重み付け和は、０である。
なお、図１０と図１６の比較から明らかなとおり、温度異常が終熄すれば温度評価値も下がり、電圧異常が終熄すれば電圧評価値も下がる。
さて、サーバ３０−２に関する劣化評価値と総合評価値は、次のように算出される。
図１５のイベント管理テーブル２０５ｃにおいて、サーバ３０−２に関する２番目と８番目のエントリは、以下のことを示す。
・サーバ３０−２は、２０１０年１２月２３日１０時から２０１０年１２月２８日１０時までの１２０時間の間、電源が投入されていない状態である。
・サーバ３０−２は、２０１０年１２月２８日１０時から２０１１年１月３日１０時３０分までの１４４．５時間の間、電源が投入された状態である。
したがって、式（１２）においてｔｏｎ（ｓｉ）＝１４４．５かつｔｏｆｆ（ｓｉ）＝１２０である。つまり、図１４ＡのステップＳ８０５において変数Ｘｏｎの値は１４４．５であり、ステップＳ８０９において変数Ｘｏｆｆの値は１２０である。
また、イベント管理テーブル２０５ｃの１２番目のエントリによれば、サーバ３０−２では、２０１１年１月１日１０時から２０１１年１月３日１０時までの４８時間の間、「Ｍａｊｏｒ」レベルの温度異常が続いている。なお、２０１１年１月３日１０時３０分には、イベント管理テーブル２０５ｃの１６番目のエントリはまだ生成されていないことに注意されたい。
したがって、式（１３）の関数ｆｄｇｒＴｍｐｒ（ｓｉ）の値は、次の式から分かるとおり、約０．２７である。
CdgrTmpr×W2×48=1/360×2×48=4/15≒0.27
つまり、図１４ＢのステップＳ８１４では、変数Ｘｔの値は９６（＝２×４８）であり、変数Ｘｄｇｒには上記の約０．２７という値が足される。
なお、イベント管理テーブル２０５ｃによれば、２０１１年１月３日１０時３０分までにサーバ３０−２に電圧超過が生じたことはない。したがって、式（１４）の関数ｆｄｇｒＯｖｅｒｖｏｌ（ｓｉ）の値は、０である。つまり、図１４ＢのステップＳ８１８では、変数Ｘｖの値は０であり、変数Ｘｄｇｒには０が足される。
よって、サーバ３０−２に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．８３である。
1/360×144.5+1/720×120+4/15+0≒0.83
そして、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−２の総合評価値は、約０．８３（＝０＋０．８３）である。
さて、サーバ３０−３に関する劣化評価値と総合評価値は、次のように算出される。
イベント管理テーブル２０５ｃの９番目のエントリによれば、サーバ３０−３は、２０１０年１２月２８日１０時から２０１１年１月３日１０時３０分までの１４４．５時間の間、電源が投入されていない状態である。そして、サーバ３０−３に関する電源ＯＮイベントは記録されていない。したがって、式（１２）においてｔｏｎ（ｓｉ）＝０かつｔｏｆｆ（ｓｉ）＝１４４．５である。
また、サーバ３０−３には今まで温度異常も電圧超過も生じていない。よって、サーバ３０−３に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．２０である。
1/360×0+1/720×144.5+0+0≒0.20
また、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−３の総合評価値は、約０．２０（＝０＋０．２０）である。
さて、サーバ３０−４に関する劣化評価値と総合評価値は、次のように算出される。
イベント管理テーブル２０５ｃにおいてサーバ３０−４に関する３番目と７番目のエントリは、以下のことを示す。
・サーバ３０−４は、２０１０年１２月２３日１０時から２０１０年１２月２７日１０時までの９６時間の間、電源が投入されていない状態である。
・サーバ３０−４は、２０１０年１２月２７日１０時から２０１１年１月３日１０時３０分までの１６８．５時間の間、電源が投入された状態である。
したがって、式（１２）においてｔｏｎ（ｓｉ）＝１６８．５かつｔｏｆｆ（ｓｉ）＝９６である。
また、イベント管理テーブル２０５ｃによれば、２０１１年１月３日１０時３０分までの間に、サーバ３０−４には、電圧低下が生じたことはあるが、温度異常も電圧超過も生じたことはない。よって、サーバ３０−４に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．６０である。
1/360×168.5+1/720×96+0+0≒0.60
また、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−４の総合評価値は、約０．６０（＝０＋０．６０）である。
さて、サーバ３０−５に関する劣化評価値と総合評価値は、次のように算出される。
イベント管理テーブル２０５ｃの４番目のエントリによれば、サーバ３０−５は、２０１０年１２月２３日１０時から２０１１年１月３日１０時３０分までの２６４．５時間の間、電源が投入されていない状態である。そして、サーバ３０−５に関する電源ＯＮイベントは記録されていない。したがって、式（１２）においてｔｏｎ（ｓｉ）＝０かつｔｏｆｆ（ｓｉ）＝２６４．５である。
また、サーバ３０−５には今まで温度異常も電圧超過も生じていない。よって、サーバ３０−５に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．３７である。
1/360×0+1/720×264.5+0+0≒0.37
また、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−５の総合評価値は、約０．３７（＝０＋０．３７）である。
さて、サーバ３０−６に関する劣化評価値と総合評価値は、次のように算出される。
イベント管理テーブル２０５ｃにおいてサーバ３０−６に関する５番目と１０番目のエントリは、以下のことを示す。
・サーバ３０−６は、２０１０年１２月２３日１０時から２０１０年１２月２８日１０時までの１２０時間の間、電源が投入されていない状態である。
・サーバ３０−６は、２０１０年１２月２８日１０時から２０１１年１月３日１０時３０分までの１４４．５時間の間、電源が投入された状態である。
したがって、式（１２）においてｔｏｎ（ｓｉ）＝１４４．５かつｔｏｆｆ（ｓｉ）＝１２０である。
また、イベント管理テーブル２０５ｃによれば、２０１１年１月３日１０時３０分までの間に、サーバ３０−６には、電圧低下が生じたことは２回あるが、温度異常も電圧超過も生じたことはない。よって、サーバ３０−６に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．５７である。
1/360×144.5+1/720×120+0+0≒0.57
また、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−６の総合評価値は、約０．５７（＝０＋０．５７）である。
さて、サーバ３０−７に関する劣化評価値と総合評価値は、次のように算出される。
イベント管理テーブル２０５ｃにおいてサーバ３０−７に関する６番目と１１番目のエントリは、以下のことを示す。
・サーバ３０−７は、２０１０年１２月２３日１０時から２０１０年１２月３１日１０時までの１９２時間の間、電源が投入されていない状態である。
・サーバ３０−７は、２０１０年１２月３１日１０時から２０１１年１月３日１０時３０分までの７２．５時間の間、電源が投入された状態である。
したがって、式（１２）においてｔｏｎ（ｓｉ）＝７２．５かつｔｏｆｆ（ｓｉ）＝１９２である。
また、イベント管理テーブル２０５ｃによれば、２０１１年１月３日１０時３０分までの間に、サーバ３０−７には、温度異常も電圧超過も生じたことはない。よって、サーバ３０−７に関して式（１２）にしたがって算出される劣化評価値は、次の式から分かるとおり、約０．４７である。
1/360×72.5+1/720×192+0+0≒0.47
また、上記のとおり図１３のステップＳ７０５で算出される値は０である。よって、ステップＳ７０６で算出されるサーバ３０−７の総合評価値は、約０．４７（＝０＋０．４７）である。
算出部３は、以上に説明したような、サーバ３０−２〜３０−７それぞれについての各種評価値を算出し、算出した評価値を図１６の結果テーブル２０６ｃに格納する。結果テーブル２０６ｃによれば、将来故障が発生する蓋然性は、総合評価値が約０．２０のサーバ３０−３において最も低い。したがって、仮にアクティブサーバ３０−１が故障した場合は、フェイルオーバ制御部４は、サーバ３０−３を新たなアクティブサーバとして選択する。
続いて、図１７〜２０を参照して、第３実施形態について説明する。第３実施形態では、式（３１）の総合評価値ｆｔｏｔａｌ（ｓｉ）が算出される。具体的には、第３実施形態の算出部３は、図１７のフローチャートにしたがって動作する。
図１７は、第３実施形態での総合評価処理のフローチャートである。図１７の総合評価処理は、図１のステップＳ１０６で算出部３が実行する。より具体的には、フェイルオーバ処理が図４のように行われる場合は、図４のステップＳ２０３で算出部３が図１７の総合評価処理を実行し、フェイルオーバ処理が図５のように行われる場合は、図５の処理と独立して算出部３が適宜のタイミングで図１７の総合評価処理を実行する。
また、図１７の総合評価処理は、ある１台のサーバ（説明の便宜上、「サーバｓｉ」とする）に関して実行される。例えば、フェイルオーバ制御部４が、サーバｓｉのＩＤを算出部３に指定して、算出部３に総合評価処理の実行を命じてもよい。あるいは、算出部３が定期的に各サーバｓｉについて図１７の総合評価処理を実行してもよい。
いつ図１７の総合評価処理が実行されるにせよ、第３実施形態では、管理ＤＢ５が図１９のような結果テーブルを含む。図１９の結果テーブルの詳細は後述するが、図１９に示すとおり、第３実施形態の結果テーブルの各エントリは、サーバＩＤ、温度評価値、電圧評価値、時刻評価値、および総合評価値という、５個のフィールドを含む。また、結果テーブルの各エントリは、各スタンバイサーバに対応する。図１７の総合評価処理の進捗にともなって、結果テーブルは更新される。
図１７のステップＳ９０１〜Ｓ９０２は、図９のステップＳ４０１〜Ｓ４０２と同様なので、詳しい説明を省略する。
次のステップＳ９０３で算出部３は、次の２つの値を引数として時刻評価部３ｅに指定し、図１８の時刻評価処理の実行を時刻評価部３ｅに命じる。
・サーバｓｉのＩＤ
・現在時刻（式（３１）では「Ｎｏｗ」と表記されている）に応じて決まる、期間ｐｅｒｉｏｄ（Ｎｏｗ）
すると、時刻評価部３ｅは、図１８のフローチャートにしたがって、時刻評価値ｆｔｉｍｅ（ｓｉ，ｐｅｒｉｏｄ（Ｎｏｗ））を算出する。そして、時刻評価部３ｅは、結果テーブル中の、サーバｓｉに対応するエントリの時刻評価値のフィールドに、算出結果を記録する。
なお、式（３１）に関して説明したとおり、引数として与えられる期間ｐｅｒｉｏｄ（Ｎｏｗ）は、ステップＳ９０３が実行される時点を含む適宜の時間帯である。例えば、ステップＳ９０３が１１時に実行される場合は、期間ｐｅｒｉｏｄ（Ｎｏｗ）は、１１時から始まる時間帯（例えば１１時から１２時までの時間帯）でもよいし、１１時を中途に含む時間帯（例えば１０時３０分から１１時３０分までの時間帯）でもよい。
関数ｐｅｒｉｏｄ（）の詳細は、実施形態に応じて予め適宜決められる。したがって、算出部３は、ステップＳ９０３が実行される時点の現在時刻に応じて、適宜の期間ｐｅｒｉｏｄ（Ｎｏｗ）を、引数として時刻評価部３ｅに指定することができる。
また、次のステップＳ９０４では、総合評価部３ｃが、図９のステップＳ４０３〜Ｓ４１０と同様にして、温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）それぞれの影響の割合を算出する。
そして、ステップＳ９０５で総合評価部３ｃは、算出した割合を用いて温度評価値ｆｔｍｐｒ（ｓｉ）と電圧評価値ｆｖｏｌ（ｓｉ）を重み付けした値（すなわち式（３４）のｆｔｏｔ（ｓｉ））を、算出する。ステップＳ９０５での重み付け和の算出方法は、図９のステップＳ４１１と同様である。
最後にステップＳ９０６で総合評価部３ｃは、ステップＳ９０５で算出した値ｆｔｏｔ（ｓｉ）に、ステップＳ９０３で結果テーブルに記録された時刻評価値ｆｔｉｍｅ（ｓｉ，ｐｅｒｉｏｄ（Ｎｏｗ））を加算することにより、総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。つまり、総合評価部３ｃは、式（３１）にしたがって総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。
そして、総合評価部３ｃは、結果テーブル中の、サーバｓｉに対応するエントリの総合評価値のフィールドに、算出結果を記録する。すると、図１７の総合評価処理は終了する。
さて、図１８は、時刻評価処理のフローチャートである。第３実施形態では、図１７のステップＳ９０３で時刻評価部３ｅが時刻評価処理を実行する。なお、図１８の説明においては、時刻評価部３ｅに対して引数として指定される時間帯を「ｐ」とする。
ステップＳ１００１で時刻評価部３ｅは、時刻評価値用の変数Ｘを０に初期化する。また、時刻評価部３ｅは、図６の１ヶ月係数Ｃｏｎｅと２ヶ月係数Ｃｔｗｏと３ヶ月係数Ｃｔｈｒｅｅの値を取得する。
次に、ステップＳ１００２で時刻評価部３ｅは、ステップＳ１００３〜Ｓ１０１０の処理対象として未選択の、サーバｓｉでの異常イベントがあるか否かを判断する。具体的には、時刻評価部３ｅは、下記の３つの条件をすべて満たすエントリがイベント管理テーブルの中にあるか否かを判断する。
・「サーバＩＤ」フィールドの値がサーバｓｉのＩＤと等しい。
・「イベントの種類」フィールドが、何らかの異常（具体的には、温度異常、電圧低下、または電圧超過）を示している。
・ステップＳ１００３〜Ｓ１０１０の処理対象としてまだ選択されていない。
上記３つの条件をすべて満たすエントリがある場合、処理はステップＳ１００３に移行する。逆に、上記３つの条件をすべて満たすエントリがない場合、処理はステップＳ１０１１に移行する。
ステップＳ１００３で時刻評価部３ｅは、サーバｓｉでの未選択の異常イベントを１つ選択する。つまり、時刻評価部３ｅは、サーバｓｉでの異常イベントに関する未選択のエントリ（すなわち上記３つの条件をすべて満たすエントリ）を１つ選択する。
次に、ステップＳ１００４で時刻評価部３ｅは、選択した異常イベントが続いた期間が、時間帯ｐと重なっているか否かを判断する。なお、時間帯ｐの長さは、１日より短く定められるものとする。よって、時刻評価部３ｅは、具体的には以下のように判断する。
もし、選択したエントリに終了時刻が記録されていなければ（すなわち、選択した異常イベントがまだ続いていれば）、時刻評価部３ｅは、現在時刻を終了時刻と見なす。そして、時刻評価部３ｅは、選択した異常イベントの開始時刻から終了時刻までの期間と、時間帯ｐとが、一部分でも重なっているか否かを判断する。
例えば、時間帯ｐが１１時から１２時までの時間帯だとする。この場合、例えば、開始時刻が２０１１年１月４日９時で終了時刻が２０１１年１月４日１１時１０分の異常イベントは、時間帯ｐと一部重なる。また、開始時刻が２０１１年１月４日１３時で終了時刻が２０１１年１月５日１１時３０分の異常イベントも、時間帯ｐと一部重なる。他方、開始時刻が２０１１年１月４日１３時で終了時刻が２０１１年１月４日１４時の異常イベントは、時間帯ｐとまったく重ならない。
選択した異常イベントの開始時刻から終了時刻までの期間と、時間帯ｐとが、一部分でも重なっていれば、処理はステップＳ１００５に移行する、逆に、選択した異常イベントの開始時刻から終了時刻までの期間と、時間帯ｐとが、まったく重なっていなければ、処理はステップＳ１００２に戻る。
ステップＳ１００５で時刻評価部３ｅは、選択した異常イベントが最近１ヶ月以内に発生した異常イベントなのか否かを判断する。時刻評価部３ｅは、選択したエントリの開始時刻に記録されている日付と、図１８の時刻評価処理を実行している日から、ステップＳ１００５の判断を行う。
もし、選択した異常イベントが最近１ヶ月以内に発生した異常イベントであれば、処理はステップＳ１００６に移行する。逆に、選択した異常イベントが１ヶ月より前に発生した異常イベントであれば、処理はステップＳ１００７に移行する。
ステップＳ１００６で時刻評価部３ｅは、選択した異常イベントの重みを取得する。具体的には、時刻評価部３ｅは、選択したエントリの「イベントのレベル」フィールドの値を読み取り、読み取った値に対応する重みを取得する。
そして、時刻評価部３ｅは、取得した重みと１ヶ月係数Ｃｏｎｅとの積を、変数Ｘに足す。その後、処理はステップＳ１００２に戻る。
ステップＳ１００７で時刻評価部３ｅは、選択した異常イベントが最近２ヶ月以内に発生した異常イベントなのか否かを判断する。もし、選択した異常イベントが最近２ヶ月以内に発生した異常イベントであれば、処理はステップＳ１００８に移行する。逆に、選択した異常イベントが２ヶ月より前に発生した異常イベントであれば、処理はステップＳ１００９に移行する。
ステップＳ１００８で時刻評価部３ｅは、選択した異常イベントの重みを取得する。そして、時刻評価部３ｅは、取得した重みと２ヶ月係数Ｃｔｗｏとの積を、変数Ｘに足す。その後、処理はステップＳ１００２に戻る。
ステップＳ１００９で時刻評価部３ｅは、選択した異常イベントが最近３ヶ月以内に発生した異常イベントなのか否かを判断する。もし、選択した異常イベントが最近３ヶ月以内に発生した異常イベントであれば、処理はステップＳ１０１０に移行する。逆に、選択した異常イベントが３ヶ月より前に発生した異常イベントであれば、処理はステップＳ１００２に戻る。
ステップＳ１０１０で時刻評価部３ｅは、選択した異常イベントの重みを取得する。そして、時刻評価部３ｅは、取得した重みと３ヶ月係数Ｃｔｈｒｅｅとの積を、変数Ｘに足す。その後、処理はステップＳ１００２に戻る。
以上のステップＳ１００２〜Ｓ１０１０の繰り返しループの結果として、ステップＳ１０１１の実行時点では、サーバｓｉで最近３ヶ月以内に発生したすべての異常イベントが選択済みである。つまり、ステップＳ１０１１の実行時点では、式（２６）の時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）が変数Ｘに格納されている。
よって、ステップＳ１０１１で時刻評価部３ｅは、変数Ｘの値をサーバｓｉの時刻評価値ｆｔｉｍｅ（ｓｉ，ｐ）として記録する。つまり、時刻評価部３ｅは結果テーブル中の、サーバｓｉに対応するエントリの「時刻評価値」フィールドに、変数Ｘの値を記録する。そして、図１８の時刻評価処理は終了する。
なお、ステップＳ１００５、Ｓ１００７、およびＳ１００９における判断では、上記のように開始時刻が使われてもよい。しかし、実施形態によっては、開始時刻の代わりに、終了時刻（ただし、終了時刻が記録されていないエントリに関しては、現在時刻）が使われてもよい。
さて次に、第３実施形態で算出される評価値の具体例を、図１５および図１９を参照しながら説明する。図１９の結果テーブル２０６ｄは、２０１１年１月３日１１時１０分に、スタンバイサーバ３０−２〜３０−７のそれぞれについて図１７の総合評価処理が実行された直後の状態を示す。なお、以下では、管理ＤＢ５内のイベント管理テーブルは、２０１１年１月３日１１時１０分においても図１５のイベント管理テーブル２０５ｃの状態のままであり、変わっていないものとする。
図１５のイベント管理テーブル２０５ｃに示すように、２０１１年１月３日１１時１０分には、サーバ３０−２に温度異常が発生しており、サーバ３０−４に電圧超過が発生している。他方、他のサーバ３０−１、３０−３、３０−５、３０−６、３０−７は正常である。
よって、サーバ３０−２に関して図１７のステップＳ９０１で算出される温度評価値は、１００（＝ＣｓｅｌｆＷ１＋０＋０＋０＝１００×１）である。また、サーバ３０−２に関してステップＳ９０２で算出される電圧評価値は０である。
そして、サーバ３０−２では、今まで温度異常のみが発生したことがあり、電圧異常は発生したことがない。よって、式（３７）で近似されるとおり、サーバ３０−２に関してステップＳ９０５で算出される値は、約１００（＝１×１００＋０×０）である。
ここで、図１７の総合評価処理が行われるのは、上記のとおり２０１１年１月３日１１時１０分である。つまり、式（３１）において現在時刻を示す引数「Ｎｏｗ」の値は、２０１１年１月３日１１時１０分である。以下では説明の便宜上、式（３１）の時間帯ｐｅｒｉｏｄ（Ｎｏｗ）が、「１１時１０分から１２時１０分までの１時間」という時間帯であるとする。
以上の仮定と図１５のイベント管理テーブル２０５ｃによれば、１２番目と１６番目のエントリにより表される温度異常が、サーバ３０−２の時刻評価値の算出において考慮される。理由は以下のとおりである。
・１２番目のエントリが表す温度異常の開始時刻は、最近１ヶ月以内である。また、当該温度異常が続いた期間は、２０１１年１月１日（と２０１１年１月２日）における１１時１０分から１２時１０分までの時間帯と重なる。
・１６番目のエントリが表す温度異常の開始時刻は、最近１ヶ月以内である。また、当該温度異常は、まだ終熄しておらず、２０１１年１月３日１１時１０分の時点において継続中である。よって、当該温度異常が継続している期間は、２０１１年１月３日における１１時１０分から１２時１０分までの時間帯と、少なくとも一部が重なる。
具体的には、最近１ヶ月以内の上記時間帯ｐｅｒｉｏｄ（Ｎｏｗ）において、「Ｍａｊｏｒ」レベルの温度異常が「１回」とカウントされ、「Ｍｉｎｏｒ」レベルの温度異常が「１回」とカウントされる。よって、サーバ３０−２の時刻評価値は、次の式から分かるとおり、１２である。
Cone(W2×1+W1×1)=4×(2+1)=12
そして、上記のとおり図１７のステップＳ９０５で算出される値は約１００である。よって、ステップＳ９０６で算出されるサーバ３０−２の総合評価値は、約１１２（＝１００＋１２）である。
さて、サーバ３０−３に関して図１７のステップＳ９０１で算出される温度評価値は、６（＝０＋ＣａｄｊＷ１＋０＋０＝６×１）である。また、サーバ３０−３に関してステップＳ９０２で算出される電圧評価値は０である。
そして、サーバ３０−３では、今まで温度異常も電圧異常も発生したことがない。よって、式（３８）に示すとおり、サーバ３０−３に関してステップＳ９０５で算出される値は３（＝１／２×６＋１／２×０）である。
また、サーバ３０−３では今まで温度異常も電圧異常も発生したことがないので、当然、サーバ３０−３の時刻評価値は０である。よって、ステップＳ９０６で算出されるサーバ３０−３の総合評価値は、３（＝０＋３）である。
さて、サーバ３０−４に関してステップＳ９０１で算出される温度評価値は、０である。
他方、図１５のイベント管理テーブル２０５ｃの１７番目のエントリが示すように、サーバ３０−４では電圧超過が発生中である。よって、サーバ３０−４に関してステップＳ９０２で算出される電圧評価値は、２００（＝ＣｓｅｌｆＷ２＋０＝１００×２）である。
また、サーバ３０−４では今まで、電圧異常のみが発生したことがあり、温度異常は発生したことがない。よって、式（３７）で近似されるとおり、サーバ３０−４に関してステップＳ９０５で算出される値は、約２００（＝０×０＋１×２００）である。
また、サーバ３０−４の時刻評価値の算出においては、図１５のイベント管理テーブル２０５ｃの１４番目と１７番目のエントリにより表される電圧異常が、考慮される。理由は以下のとおりである。
・１４番目のエントリが表す電圧低下の開始時刻は、最近１ヶ月以内である。また、当該電圧低下が続いた期間は、２０１１年１月２日における１１時１０分から１２時１０分までの時間帯と重なる。
・１７番目のエントリが表す電圧超過の開始時刻は、最近１ヶ月以内である。また、当該電圧超過は、まだ終熄しておらず、２０１１年１月３日１１時１０分の時点において継続中である。よって、当該電圧超過が継続している期間は、２０１１年１月３日における１１時１０分から１２時１０分までの時間帯と、少なくとも一部が重なる。
具体的には、最近１ヶ月以内の上記時間帯ｐｅｒｉｏｄ（Ｎｏｗ）において、「Ｃｒｉｔｉｃａｌ」レベルの電圧低下が「１回」とカウントされ、「Ｍａｊｏｒ」レベルの電圧超過が「１回」とカウントされる。よって、サーバ３０−４の時刻評価値は、次の式から分かるとおり、３２である。
Cone(W3×1+W2×1)=4×(6+2)=32
そして、上記のとおり図１７のステップＳ９０５で算出される値は約２００である。よって、ステップＳ９０６で算出されるサーバ３０−４の総合評価値は、約２３２（＝２００＋３２）である。
さて、サーバ３０−５に関してステップＳ９０１で算出される温度評価値は、０である。他方、ステップＳ９０２で算出される電圧評価値は、２０（＝０＋ＣｐｏｗｅｒＷ２＝１０×２）である。
そして、サーバ３０−５では、今まで温度異常も電圧異常も発生したことがない。よって、式（３８）に示すとおり、サーバ３０−５に関してステップＳ９０５で算出される値は、１０（＝１／２×０＋１／２×２０）である。
また、サーバ３０−５では今まで温度異常も電圧異常も発生したことがないので、当然、サーバ３０−５の時刻評価値は０である。よって、ステップＳ９０６で算出されるサーバ３０−５の総合評価値は、１０（＝１０＋０）である。
さて、サーバ３０−６に関してステップＳ９０１で算出される温度評価値は、０である。また、ステップＳ９０２で算出される電圧評価値も、０である。よって、ステップＳ９０５で算出される値も、０である。
また、サーバ３０−６の時刻評価値の算出においては、図１５のイベント管理テーブル２０５ｃの１３番目と１５番目のントリにより表される電圧異常が、考慮される。理由は以下のとおりである。
・１３番目のエントリが表す電圧低下の開始時刻は、最近１ヶ月以内である。また、当該電圧低下が続いた期間は、２０１１年１月１日における１１時１０分から１２時１０分までの時間帯と、少なくとも一部が重なる。
・１５番目のエントリが表す電圧低下の開始時刻は、最近１ヶ月以内である。また、当該電圧低下が続いた期間は、２０１１年１月２日における１１時１０分から１２時１０分までの時間帯と、少なくとも一部が重なる。
具体的には、最近１ヶ月以内の上記時間帯ｐｅｒｉｏｄ（Ｎｏｗ）において、「Ｍｉｎｏｒ」レベルの電圧低下が「２回」とカウントされる。よって、サーバ３０−６の時刻評価値は、次の式から分かるとおり、８である。
Cone(W1×2)=4×(1×2)=8
そして、上記のとおり図１７のステップＳ９０５で算出される値は０である。よって、ステップＳ９０６で算出されるサーバ３０−６の総合評価値は、８（＝０＋８）である。
さて、サーバ３０−７に関してステップＳ９０１で算出される温度評価値は、０である。また、ステップＳ９０２で算出される電圧評価値も、０である。よって、ステップＳ９０５で算出される値も、０である。
そして、サーバ３０−７では、今まで温度異常も電圧異常も発生したことがないので、当然、サーバ３０−７の時刻評価値は０である。よって、ステップＳ９０６で算出されるサーバ３０−７の総合評価値は、０（＝０＋０）である。
算出部３は、以上に説明したような、サーバ３０−２〜３０−７それぞれについての各種評価値を算出し、算出した評価値を図１９の結果テーブル２０６ｄに格納する。結果テーブル２０６ｄによれば、将来故障が発生する蓋然性は、総合評価値が０のサーバ３０−７において最も低い。したがって、仮にアクティブサーバ３０−１が故障した場合は、フェイルオーバ制御部４は、サーバ３０−７を新たなアクティブサーバとして選択する。
続いて、図２０〜２１を参照して、第４実施形態について説明する。第４実施形態では、式（３２）の総合評価値ｆｔｏｔａｌ（ｓｉ）が算出される。具体的には、第４実施形態の３は、図２０のフローチャートにしたがって動作する。
図２０は、第４実施形態での総合評価処理のフローチャートである。図２０の総合評価処理は、図１のステップＳ１０６で算出部３が実行する。より具体的には、フェイルオーバ処理が図４のように行われる場合は、図４のステップＳ２０３で算出部３が図２０の総合評価処理を実行し、フェイルオーバ処理が図５のように行われる場合は、図５の処理と独立して算出部３が適宜のタイミングで図２０総合評価処理を実行する。
また、図２０の総合評価処理は、ある１台のサーバ（説明の便宜上、「サーバｓｉ」とする）に関して実行される。例えば、フェイルオーバ制御部４が、サーバｓｉのＩＤを算出部３に指定して、算出部３に総合評価処理の実行を命じてもよい。あるいは、算出部３が定期的に各サーバｓｉについて図２０の総合評価処理を実行してもよい。
いつ図２０の総合評価処理が実行されるにせよ、第４実施形態では、管理ＤＢ５が図２１のような結果テーブルを含む。図２１の結果テーブルの詳細は後述するが、図２１に示すとおり、第４実施形態の結果テーブルの各エントリは、サーバＩＤ、温度評価値、電圧評価値、劣化評価値、時刻評価値、および総合評価値という、６個のフィールドを含む。また、結果テーブルの各エントリは、各スタンバイサーバに対応する。図２０の総合評価処理の進捗にともなって、結果テーブルは更新される。
図２０のステップＳ１１０１〜Ｓ１１０３は、図１３のステップＳ７０１〜Ｓ７０３と同様なので、詳しい説明を省略する。また、その後のステップＳ１１０４〜Ｓ１１０６は、図１７のステップＳ９０３〜Ｓ９０５と同様なので、詳しい説明を省略する。
ステップＳ１１０６の後、ステップＳ１１０７で総合評価部３ｃは、ステップＳ１１０６で算出した値に、ステップＳ１１０３で記録された劣化評価値とステップＳ１１０４で記録された時刻評価値を加算する。それにより、総合評価部３ｃは、式（３２）の総合評価値ｆｔｏｔａｌ（ｓｉ）を算出する。
そして、総合評価部３ｃは、結果テーブル中の、サーバｓｉに対応するエントリの総合評価値のフィールドに、算出結果を記録する。すると、図２０の総合評価処理は終了する。
さて次に、第４実施形態で算出される評価値の具体例を、図１５および図２１を参照しながら説明する。図２１の結果テーブル２０６ｅは、２０１１年１月３日１１時３０分に、スタンバイサーバ３０−２〜３０−７のそれぞれについて図２０の総合評価処理が実行された直後の状態を示す。なお、以下では、管理ＤＢ５内のイベント管理テーブルは、２０１１年１月３日１１時３０分においても図１５のイベント管理テーブル２０５ｃの状態のままであり、変わっていないものとする。
結果テーブル２０６ｅにおける「温度評価値」、「電圧評価値」、および「時刻評価値」の列の値は、図１９の結果テーブル２０６ｄにおける値と同じである。理由は以下のとおりである。
・結果テーブル２０６ｄは、２０１１年１月３日１１時１０分に実行された総合評価処理の結果を表す。他方、結果テーブル２０６ｅは、２０１１年１月３日１１時３０分に実行された総合評価処理の結果を表す。
・しかし、２０１１年１月３日の１１時１０分から１１時３０分までの間に新たに発生した異常はない。また、２０１１年１月３日の１１時１０分から１１時３０分までの間に終熄した異常もない。
・算出部３は、２０１１年１月３日の１１時３０分に時刻評価部３ｅに時刻評価値の算出を命じる際に、例えば、「１１時３０分から１２時３０分」という期間を引数として指定してもよい。このように期間が指定された場合も、図１５のイベント管理テーブル２０５ｃの例の場合は、「１１時１０分から１２時１０分」という期間が引数として指定された場合と同じ時刻評価値が得られる。
よって、結果テーブル２０６ｅにおける「温度評価値」、「電圧評価値」、および「時刻評価値」の列の値についての詳しい説明は、省略する。
また、結果テーブル２０６ｅにおける「劣化評価値」の列の値は、図１６の結果テーブル２０６ｃにおける値と多少異なる。違いの理由は、結果テーブル２０６ｃは、２０１１年１月３日１０時３０分に実行された図１３の総合評価処理の結果を表すのに対し、結果テーブル２０６ｅは、２０１１年１月３日１１時３０分に実行された図２０の総合評価処理の結果を表すからである。
具体的には、以下のような要因があるため、サーバ３０−２〜３０−７のいずれに関しても、図１６よりも図２１において劣化評価値が大きい。
・サーバ３０−２、３０−４、３０−６、および３０−７に関しては、電源が投入されていた時間の長さｔｏｎ（ｓｉ）の値が、図１６の例よりは図２１の例において、１時間だけ大きい。時間の長さｔｏｎ（ｓｉ）の増加にともない、劣化評価値も図２１の例ではより大きくなる。
・サーバ３０−３および３０−５に関しては、電源が投入されていなかった時間の長さｔｏｆｆ（ｓｉ）の値が、図１６の例よりは図２１の例において、１時間だけ大きい。時間の長さｔｏｆｆ（ｓｉ）の増加にともない、劣化評価値も図２１の例ではより大きくなる。
・サーバ３０−２に関しては、２０１１年１月３日１１時に発生した温度異常も、図２１の劣化評価値を図１６の劣化評価値より大きくする要因である。
・サーバ３０−４に関しては、２０１１年１月３日１１時に発生した電圧超過も、図２１の劣化評価値を図１６の劣化評価値より大きくする要因である。
以上のような要因により、図１６と図２１では、劣化評価値が異なる。しかし、劣化評価値の算出方法は同様である。よって、サーバ３０−２〜３０−７それぞれの劣化評価値の算出については、以下のとおり簡単に説明する。
サーバ３０−２の劣化評価値は、以下の２つの式から分かるとおり、約０．８４である。
fdgrTmpr(si)=CdgrTmpr×(W2×48+W1×0.5)=1/360×(2×48+1×0.5)≒0.27
fdgr(si)=1/360×145.5+1/720×120+fdgrTmpr(si)+0≒0.84
サーバ３０−３の劣化評価値は、以下の式から分かるとおり、約０．２０である。
1/360×0+1/720×145.5+0+0≒0.20
サーバ３０−４の劣化評価値は、以下の２つの式から分かるとおり、約０．６１である。
fdgrOvervol(si)=CdgrOvervol×W2×0.5=1/360×2×0.5≒0.00
fdgr(si)=1/360×169.5+1/720×96+0+fdgrOvervol(si)≒0.61
サーバ３０−５の劣化評価値は、以下の式から分かるとおり、約０．３７である。
1/360×0+1/720×265.5+0+0≒0.37
サーバ３０−６の劣化評価値は、以下の式から分かるとおり、約０．５７である。
1/360×145.5+1/720×120+0+0≒0.57
サーバ３０−７の劣化評価値は、以下の式から分かるとおり、約０．４７である。
1/360×73.5+1/720×192+0+0≒0.47
そして、各サーバについて図２０のステップＳ１１０６で算出される値（つまり温度評価値と電圧評価値の重み付け和）は、図１７のステップＳ９０５で算出される値と同様である。したがって、各サーバの総合評価値は以下のとおりである。
サーバ３０−２の総合評価値は、約１１２．８４（＝１００＋０．８４＋１２）である。サーバ３０−３の総合評価値は、約３．２０（＝３＋０．２０＋０）である。サーバ３０−４の総合評価値は、約２３２．６１（＝２００＋０．６１＋３２）である。サーバ３０−５の総合評価値は、約１０．３７（＝１０＋０．３７＋０）である。サーバ３０−６の総合評価値は、約８．５７（＝０＋０．５７＋８）である。サーバ３０−７の総合評価値は、約０．４７（＝０＋０．４７＋０）である。
算出部３は、以上に説明したような、サーバ３０−２〜３０−７それぞれについての各種評価値を算出し、算出した評価値を図２１の結果テーブル２０６ｅに格納する。結果テーブル２０６ｅによれば、将来故障が発生する蓋然性は、総合評価値が約０．４７のサーバ３０−７において最も低い。したがって、仮にアクティブサーバ３０−１が故障した場合は、フェイルオーバ制御部４は、サーバ３０−７を新たなアクティブサーバとして選択する。
続いて、図２２を参照して、第５実施形態について説明する。第５実施形態では、第４実施形態と同様に、式（３２）の総合評価値ｆｔｏｔａｌ（ｓｉ）が算出される。第４実施形態と第５実施形態との違いは、ユーザインタフェイスである。
具体的には、第５実施形態では、図２のフェイルオーバ制御部４が、自動的に新たなアクティブサーバを選択する代わりに、算出部３による評価結果をクライアント６に通知する。クライアント６は、適宜のＧＵＩを用いて、通知された評価結果を表示する。
すると、クライアント６のユーザは、表示された評価結果を見て認識することができる。そして、ユーザは、クライアント６を介して、切り替え先のスタンバイサーバ（すなわち新たなアクティブサーバ）をフェイルオーバ制御部４に指示することができる。フェイルオーバ制御部４は、クライアント６から受け取った指示にしたがって、今までのアクティブサーバ３０−１から、指示された新たなサーバへの、切り替え（switchover）を制御する。
より具体的には、第５実施形態では、図２２に例示するようなＧＵＩが利用されてもよい。図２２には、クライアント６のディスプレイに表示される、結果表示画面３０１とダイアログボックス３０２の例が示されている。
結果表示画面３０１は、算出部３による算出結果（具体的には管理ＤＢ５中の結果テーブルの内容を含むデータ）をテーブル形式で示す画面である。結果表示画面３０１には、見出しと、スタンバイサーバ３０−２〜３０−７のそれぞれに対応する行が含まれる。例えば、「２」というＩＤの割り当てられたサーバ３０−２に対応する行は、以下のことを示している。
・サーバ３０−２は、「１」というＩＤの割り当てられたアクティブサーバ３０−１用に設けられたスタンバイサーバのうちの１台である。
・サーバ３０−２に関して、温度評価値が１２、電圧評価値が０、劣化評価値が２１、時刻評価値が０と算出され、これらの各評価値に基づいて、総合評価値が３３と算出された。
・アクティブサーバ３０−１からの切り替え先のサーバとしての優先度が、総合評価値が小さいほど高優先度となるように定義されており、６台のスタンバイサーバ３０−２〜３０−７の中でのサーバ３０−２の優先度は最低である。
他のサーバ３０−３〜３０−７についての行にも、同様に、アクティブサーバのＩＤと、優先度と、総合評価値と、温度評価値と、電圧評価値と、劣化評価値と、時刻評価値が表示されている。
そして、結果表示画面３０１の例においては、総合評価値が１１のサーバ３０−５の優先度が最も高く、総合評価値が１３のサーバ３０−７の優先度が２番目に高い。また、総合評価値が１８のサーバ３０−４の優先度が３番目に高く、総合評価値が２３のサーバ３０−３の優先度が４番目に高い。そして、総合評価値が２５のサーバ３０−６の優先度が５番目に高く、総合評価値が３３のサーバ３０−２の優先度は、上記のとおり最低である。
ユーザは、クライアント６のディスプレイに表示された結果表示画面３０１を見ることにより、サーバ３０−２〜３０−７のそれぞれにおいて将来故障が発生する蓋然性を判断することができる。また、結果表示画面３０１には、総合評価値だけでなく、総合評価値の算出に使われる他の評価値が「詳細」として示されている。よって、ユーザは、サーバ３０−２〜３０−７のそれぞれについて、故障に影響する各種要因の影響度を知ることもできる。
また、ユーザは、クライアント６のディスプレイに表示されたダイアログボックス３０２を介して、アクティブサーバ３０−１からの切り替え先のサーバを、フェイルオーバ制御部４に対して指定することができる。図２２の例では、「サーバ切り替え」という見出しがついたダイアログボックス３０２は、切り替え先のスタンバイサーバをユーザに選択させるためのプルダウンリストと、「ＯＫ」ボタンと、「キャンセル」ボタンを含む。図２２のように、ダイアログボックス３０２は、さらに「ヘルプ」ボタンなどの他のＧＵＩ要素を含んでいてもよい。
プルダウンリストには、アクティブサーバ３０−１に対応して設けられている６台のサーバ３０−２〜３０−６が、上記の優先度の降順に、６つの選択肢として挙げられている。ユーザの便宜のため、プルダウンリスト中の各選択肢には、サーバＩＤと、総合評価値が表示されている。ユーザは、プルダウンリストから任意のサーバ（例えば「５」というＩＤのサーバ３０−５）を選び、「ＯＫ」ボタンをクリックすることにより、フェイルオーバ制御部４に対して、切り替え先のサーバを指定することができる。
このように、第５実施形態によれば、ユーザの意向に応じた手動の切り替えも可能である。たとえアクティブサーバからの切り替えがユーザ操作に応じてなされるとしても、各スタンバイサーバに将来故障が発生する蓋然性を予測する結果表示画面３０１のような情報をユーザに対して提示することは有益である。なぜなら、提示された情報に基づいてユーザがより適切なスタンバイサーバを選択することができるからである。
ところで、本発明は上記実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の観点から様々に変形することもできる。下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
様々なフローチャートを例示したが、ステップの順序は、矛盾が生じない限り適宜入れ替えられてよい。また、入れ替え可能なステップ同士は、並列に実行されてもよい。
例えば、図２０の例において、ステップＳ１１０１〜Ｓ１１０４の順序は、任意に入れ替え可能である。また、ステップＳ１１０３〜Ｓ１１０４は、ステップＳ１１０５〜Ｓ１１０６の後に実行されてもよい。
算出部３は、スタンバイサーバだけでなく、アクティブサーバに関しても、評価値を算出してもよい。管理ＤＢ５の結果テーブルは、アクティブサーバに関する評価値をさらに格納していてもよい。
なお、イベント管理テーブルや結果テーブルなど、管理ＤＢ５中の各種データの例を、図面ではテーブル形式で例示した。しかし、データ形式は実施形態に応じて任意である。例えば、管理ＤＢ５は、ＸＭＬ（Extensible Markup Language）データベースであってもよいし、他の形式のデータベースであってもよい。また、管理ＤＢ５が結果テーブル２０６ａ〜２０６ｅのようなテーブルを保持する代わりに、結果テーブル２０６ａ〜２０６ｅと同等のデータを、単に算出部３がＲＡＭ１０２上の変数（例えばアレイ変数）に保持していてもよい。
また、時刻評価値が利用され、かつ、フェイルオーバ処理が図５のフローチャートにしたがって行われる場合は、異なる複数の時間帯それぞれに対応する複数の時刻評価値が、各サーバに対応づけられて管理ＤＢ５に格納されていてもよい。
例えば、１日が、長さ１時間の２４個の期間に分割されてもよい。そして、時刻評価部３ｅは、１日に１回、決められた時刻に、２４個の期間のそれぞれについて、各サーバの時刻評価値を算出し、算出結果を管理ＤＢ５に格納してもよい。総合評価部３ｃは、２４個の期間のそれぞれについて算出された時刻評価値に対応して、２４個の期間のそれぞれについて総合評価値を算出し、算出結果を管理ＤＢ５に格納してもよい。
また、劣化評価値が利用される場合、管理ＤＢ５には、下記の３つの値を互いに対応づける情報が格納されていてもよい。
・部品が交換、増加、または削除されたサーバのサーバＩＤ。
・部品が交換、増加、または削除された日時。
・交換、増加、または削除された部品の個数に応じて算出される、式（２４）の右辺における被乗数。
そして、劣化評価部３ｄは、劣化評価値の算出において時間の長さ（例えば、ｔｏｎ（ｓｉ）など）を評価する際に、部品が交換、増加、または削除された日時より前の期間の長さに対しては、記憶されている式（２４）の被乗数を掛けてもよい。
ところで、第５実施形態と類似のＧＵＩは、第１〜第３実施形態のいずれに対しても適用可能である。算出部３が式（２９）〜（３３）のいずれにしたがって総合評価値を算出するにせよ、フェイルオーバ制御部４は、自動的にフェイルオーバ処理を行ってもよいし、クライアント６を介してユーザから与えられる指示にしたがってスイッチオーバ処理を行ってもよい。
図６に示した係数２０１と重み２０２の具体的な値は、実施形態に応じて適宜変更されてもよい。また、係数２０１と重み２０２の値はユーザ定義可能な値であってもよい。
冗長化システムが複数のアクティブサーバを含んでいてもよい。また、第１のアクティブサーバ用に設けられる複数のスタンバイサーバは、第２のアクティブサーバ用に設けられる複数のスタンバイサーバと、異なっていてもよいし、一部または全部が共通であってもよい。
例えば、サーバプール内の複数のサーバの各々は、第１のアクティブサーバ用のスタンバイサーバとして第１のアクティブサーバに対応づけられるとともに、第２のアクティブサーバ用のスタンバイサーバとして第２のアクティブサーバに対応づけられてもよい。管理サーバ１は、例えば管理ＤＢ５の中に、アクティブサーバとスタンバイサーバの対応づけに関する情報を保持する。
いずれにせよ、算出部３は、各アクティブサーバに関して、当該アクティブサーバ用の複数のスタンバイサーバそれぞれの評価値を算出する。したがって、どのアクティブサーバに故障が生じた場合でも、フェイルオーバ制御部４は、総合評価値の小さなスタンバイサーバ（すなわち、故障が生じにくいと予測されるため、新たなアクティブサーバとして適切なサーバ）を選択することができる。
ところで、図２には、ある１つの冗長化システムにおけるアクティブサーバ３０−１と、サーバ３０−１に対応するスタンバイサーバ３０−２〜３０−７のみが例示されている。
しかし、実施形態によっては、例えば、ラック１０−１の中に、別のシステムのサーバ（以下、説明の便宜上「独立サーバ」という）が１台以上さらに設置されていることもあり得る。もちろん、ラック１０−２の中に独立サーバが１台以上設置されていることもあり得るし、ラック１０−３の中に独立サーバが１台以上設置されていることもあり得る。
独立サーバは、機能の面では（つまり論理的には）、サーバ３０−１〜３０−７を含む冗長化システムとは無関係である。しかし、独立サーバは、物理的にはサーバ３０−１〜３０−７と関係することがある。
そこで、もしラック１０−１〜１０−３の中に独立サーバが１台以上存在するならば、収集部２は、独立サーバからも故障予兆情報を収集する。そして、算出部３は、独立サーバから収集された故障予兆情報も用いて、スタンバイサーバ３０−２〜３０−７それぞれの評価値を算出する。
換言すれば、論理的には別々の複数のシステムに属するサーバが、物理的には同じラックの中に存在してもよい。そして、管理サーバ１は、それら複数のシステムに属する全サーバを管理してもよい。
例えば、ブレード型の独立サーバがシャーシ２０−１の３番目のスロットに搭載されており、当該独立サーバで温度異常が発生中だとする。この場合、温度異常が発生中の独立サーバは、シャーシ２０−１内でサーバ３０−２に隣接している。また、サーバ３０−３は、独立サーバと隣接してはいないが、同じシャーシ２０−１内にある。
よって、サーバ３０−２や３０−３は、当該独立サーバで発生中の温度異常の影響を受ける。したがって、収集部２が独立サーバからも故障予兆情報を収集することにより、サーバ３０−２および３０−３の温度評価値が、より正確に算出される。
あるいは、例えば、ラックマウント型の独立サーバがラック１０−２に搭載されており、当該独立サーバで電圧異常が発生中だとする。この場合、電圧異常が発生中の独立サーバは、サーバ３０−４および３０−５と電源ユニット１２−２を共用している。したがって、収集部２が独立サーバからも故障予兆情報を収集することにより、サーバ３０−４および３０−５の電圧評価値がより正確に算出される。
ところで、上記の説明においては、式（１）〜（３８）のような様々な式を例示したが、算出部３が他の式にしたがって評価値を算出してもよい。例えば、あるサーバｓｉに隣接するサーバの集合ａｄｊ（ｓｉ）は、上記のとおり式（５）により定義されてもよいが、別の定義が採用されてもよい。また、あるサーバｓｉの電圧評価値に影響を与えるサーバの集合ｐｏｗｅｒ（ｓｉ）は、上記のとおり式（１１）により定義されてもよいが、別の定義が採用されてもよい。
具体的には、例えば、「以下のいずれかの条件が成り立つとき、サーバｓｉとｓｊは隣接している」と定義されてもよい。
・サーバｓｉとｓｊはともにブレード型サーバであり、サーバｓｉとｓｊは、１つのシャーシ内で互いに隣接するスロットに搭載されている。
・サーバｓｉはブレード型サーバであり、サーバｓｊは、サーバｓｉの搭載されたシャーシのラック内位置のすぐ上（またはすぐ下）の位置に搭載された、ラックマウント型サーバである。
・サーバｓｉはラックマウント型サーバであり、サーバｓｊは、サーバｓｉのラック内位置のすぐ上（またはすぐ下）の位置に搭載されたシャーシに搭載された、ブレード型サーバである。
・サーバｓｉとｓｊはともにブレード型サーバであり、サーバｓｉを搭載したシャーシのラック内位置のすぐ上（またはすぐ下）の位置に、サーバｓｊを搭載したシャーシが搭載されている。
・サーバｓｉとｓｊはともにラックマウント型サーバであり、サーバｓｉのラック内位置のすぐ上（またはすぐ下）の位置に、サーバｓｊが搭載されている。
もちろん、実施形態によっては、さらに別の定義が採用されてもよい。また、例えば上記の５つの場合が区別されてもよく、互いに異なる５つの値を持つ５つの隣接係数が使われてもよい。
なお、例えばラック内位置が「１、２、３……」のようなシーケンス番号で表されるとすると、ラック内での上下方向の隣接関係は、ラックマウント型サーバまたはシャーシの高さと、ラック内位置を示す番号から、判定可能である。
例えば、高さが６Ｕのシャーシがラック内の３番から８番の位置を占めているとする。この場合、当該シャーシの上に隣接する装置は、２番の位置を占めている装置（例えば高さ１Ｕのラックマウント型サーバ）である。そして、当該シャーシの下に隣接する装置は、９番の位置を占めている装置である。９番の位置を占めている装置は、具体的には、例えば、９番から１４番の位置を占める高さ６Ｕの別のシャーシかもしれないし、あるいは、９番の位置だけを占める高さ１Ｕのラックマウント型サーバかもしれない。
また、式（５）または上記の変形例のように定義される集合ａｄｊ（ｓｉ）を利用して、「レベル１の隣接関係」、「レベル２の隣接関係」、「レベル３の隣接関係」など、複数のレベルの隣接関係が定義されてもよい。例えば、以下のような定義が利用されてもよい。
・ｓｊ∈ａｄｊ（ｓｉ）ならば、サーバｓｉとｓｊは、レベル１で互いに隣接している。
・∃ｓｋ（ｓｋ∈ａｄｊ（ｓｉ）∧ｓｋ∈ａｄｊ（ｓｊ））ならば、サーバｓｉとｓｊは、レベル２で互いに隣接している。
・∃ｓｋ，ｓｈ（ｓｋ∈ａｄｊ（ｓｉ）∧ｓｋ∈ａｄｊ（ｓｈ）∧ｓｈ∈ａｄｊ（ｓｊ））ならば、サーバｓｉとｓｊは、レベル３で互いに隣接している。
そして、温度評価値の算出においては、レベル１の隣接関係用の隣接係数と、レベル２の隣接関係用の隣接係数と、レベル３の隣接関係用の隣接係数が使われてもよい。つまり、あるサーバｓｉの温度評価値の算出においては、次のような様々な影響が考慮に入れられてもよい。
・サーバｓｉにレベル１で隣接している他のサーバからの影響。
・サーバｓｉにレベル２で隣接している他のサーバからの影響。
・サーバｓｉにレベル３で隣接している他のサーバからの影響。
・レベル１〜３ではサーバｓｉに隣接してはいないが、サーバｓｉと同じシャーシ内にある他のサーバからの影響。
・レベル１〜３ではサーバｓｉに隣接しておらず、サーバｓｉと同じシャーシ内にもないが、サーバｓｉと同じラック内にある他のサーバからの影響。
以上例示したように、あるサーバｓｉについての温度評価値の算出に、他のどのサーバｓｊが関係するかは、実施形態に応じて様々である。そして、上記の変形例とは逆に、例えば、式（１）の右辺の第４項を省略するか、あるいは、第３項と第４項を省略する変形も可能である。具体的には、以下のとおりである。
式（１）は、サーバｓｉとｓｊの近さについて式（５）〜（７）により定義された３つのレベルに基づいて、定義されている。しかし、サーバｓｉとｓｊの近さについて、１つのレベルだけが定義されてもよい。例えば、その１つのレベルは、式（３）または上記の変形例における集合ａｄｊ（ｓｉ）により定義されてもよい。もちろん、サーバｓｉとｓｊの近さについて、２つのレベルが定義されてもよいし、４つ以上のレベルが定義されてもよい。
そして、定義された近さのレベルの数に応じて、式（１）は適宜変形されてよい。例えば、実施形態によっては、式（１）の右辺の第４項が省略されてもよいし、あるいは、第３項と第４項の双方が省略されてもよい。
また、式（１１）による集合ｐｏｗｅｒ（ｓｉ）の定義では、以下の２つの場合が区別されていない。そして、式（８）では、１種類の同一電源係数Ｃｐｏｗｅｒが、以下の２つの場合の双方に対して使われる。
・サーバｓｉとｓｊが直接的に同じ電源ユニットから電力を供給される場合。
・サーバｓｉとｓｊが間接的に同じ電源ユニットから電力を供給される場合。
しかし、例えば以下の５つの場合が互いに区別されてもよく、互いに異なる値を持つ５つの同一電源係数が使われてもよい。
・サーバｓｉとｓｊはともにブレード型サーバであり、サーバｓｉとｓｊへの直接の電力供給源は、同じ１つのシャーシ内電源ユニットである。
・サーバｓｉとｓｊはともにブレード型サーバであり、同じ１つのシャーシに搭載されているが、サーバｓｉとｓｊには、異なる２つのシャーシ内電源ユニットからそれぞれ電力が供給されている。
・サーバｓｉとｓｊの一方はブレード型サーバであり、他方は、当該ブレード型サーバの搭載されたシャーシに電力を供給するラック内電源ユニットから電力を得ている、ラックマウント型サーバである。
・サーバｓｉとｓｊはともにラックマウント型サーバであり、サーバｓｉとｓｊへの直接の電力供給源は、同じ１つのラック内電源ユニットである。
・サーバｓｉとｓｊは異なる２つのラックに搭載されているが、それら２つのラックに搭載された各ラック内電源ユニットは、同じ部屋の同じ電源コンセントから電力を得ている。
もちろん、実施形態によっては、さらに別の定義が採用されてもよい。また、劣化評価値や時刻評価値に関しても、式（１２）〜（２８）の例とは異なる定義が採用されてもよい。
いずれにしろ、温度評価部３ａは、サーバ同士の物理的な位置関係についての定義に応じた適宜の手順により、温度評価値を算出する。そして、電圧評価部３ｂは、電源の共有に関する定義に応じた適宜の手順により、電圧評価値を算出する。
また、劣化評価部３ｄは、経年劣化にどのような要因が影響するかに応じた適宜の手順により、劣化評価値を算出する。そして、時刻評価部３ｅは、故障の発生のしやすさが時刻または時間帯に依存する度合に応じた適宜の手順により、時刻評価値を算出する。
よって、総合評価部３ｃは、実施形態に応じた適宜の定義にしたがって他の評価部が算出した複数の評価値を使って、適宜の総合評価値を算出することができる。複数のスタンバイサーバそれぞれに関する総合評価値を用いることで、現在のアクティブサーバが故障した場合のフェイルオーバ先のサーバとしての適切さ（または優先度）が、複数のスタンバイサーバ間で比較可能となる。
よって、上記の様々な実施形態のいずれにおいても、故障の発生しにくいサーバを新たなアクティブサーバとして選択することで、二次故障を防ぐ効果が得られる。二次故障が起きなければ、冗長化システム全体としての可用性も高まる。
１ 管理サーバ
２ 収集部
３ 算出部
３ａ 温度評価部
３ｂ 電圧評価部
３ｃ 総合評価部
３ｄ 劣化評価部
３ｅ 時刻評価部
４ フェイルオーバ制御部
５ 管理ＤＢ
６ クライアント
１０−１〜１０−３ ラック
１１−１〜１１−３ ラック管理装置
１２−１〜１２−３、２３−１〜２３−３ 電源ユニット
２０−１〜２０−２ シャーシ
２１−１〜２１−２ シャーシ管理装置
２２−１〜２２−２ ＬＡＮスイッチ
３０−１〜３０−７ サーバ
３１−１〜３１−７ サーバ管理装置
１００ コンピュータ
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ネットワークインタフェイス
１０４ 入力装置
１０５ 出力装置
１０６ 不揮発性記憶装置
１０７ 駆動装置
１０８ バス
１０９ 記憶媒体
１１０ ネットワーク
１１１ プログラム提供者
２０１ 係数
２０２ 重み
２０３ サーバテーブル
２０４ シャーシテーブル
２０５ａ〜２０５ｃ イベント管理テーブル
２０６ａ〜２０６ｅ 結果テーブル
３０１ 結果表示画面
３０２ ダイアログボックス

Claims (11)

  1. 冗長化システム中のアクティブな第１のコンピュータを含む、複数のコンピュータを管理する管理コンピュータに、
    前記複数のコンピュータのそれぞれから、故障の発生に関連する複数の種類の現象についての情報を含む故障予兆情報を収集し、
    前記冗長化システムにおいて前記第１のコンピュータと対応づけられている複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、当該第２のコンピュータに将来故障が生じる蓋然性を示す評価値を、当該第２のコンピュータから収集した前記故障予兆情報と、前記複数のコンピュータのうち当該第２のコンピュータ以外の所定の１台以上のコンピュータから収集した前記故障予兆情報とを用いて、算出する
    ことを含む処理を実行させるプログラム。
  2. 前記複数の種類の現象は、温度に関する現象と、電圧に関する現象を含み、
    前記評価値は、前記複数の種類の現象にそれぞれ関連する故障の当該第２のコンピュータにおける発生のしやすさを当該第２のコンピュータから収集された前記故障予兆情報に応じてそれぞれ示す複数の値に、依存する
    ことを特徴とする請求項１に記載のプログラム。
  3. ある第２のコンピュータについての前記評価値を算出するのに前記故障予兆情報が用いられる前記所定の１台以上のコンピュータとは、
    前記ある第２のコンピュータとの間で、シャーシ内の電源ユニットもしくはラック内の電源ユニットを共有するか、
    前記ある第２のコンピュータと隣接した位置に搭載されているか、
    前記ある第２のコンピュータと同じシャーシに搭載されているか、または
    前記ある第２のコンピュータと同じラックに搭載されている、
    １台以上のコンピュータである
    ことを特徴とする請求項１または２に記載のプログラム。
  4. 前記ある第２のコンピュータについての前記評価値は、前記所定の１台以上のコンピュータから収集された前記故障予兆情報よりも、前記ある第２のコンピュータから収集された前記故障予兆情報の方に重きをおいて、算出される
    ことを特徴とする請求項３に記載のプログラム。
  5. 前記複数の値のうち、前記温度に関する現象に対応する第１の値は、前記評価値を算出する対象の前記第２のコンピュータにおいて、過去に、温度に関する１つ以上の異常の各々が続いた時間の長さに基づき、
    前記複数の値のうち、前記電圧に関する現象に対応する第２の値は、前記評価値を算出する対象の前記第２のコンピュータにおいて、過去に、電圧に関する１つ以上の異常の各々が続いた時間の長さに基づく
    ことを特徴とする請求項２に記載のプログラム。
  6. 前記評価値は、さらに、
    前記評価値を算出する対象の前記第２のコンピュータにおいて、将来、経年劣化に起因して故障が生じる蓋然性を示す第１の部分評価値と、
    前記評価値を算出する対象の前記第２のコンピュータにおいて、将来、特定の時間帯に故障が生じる蓋然性を示す第２の部分評価値の、
    一方または双方にも依存することを特徴とする請求項２または５に記載のプログラム。
  7. 前記第１の部分評価値は、少なくとも、
    前記評価値を算出する対象の前記第２のコンピュータに、電源が入れられていた時間の長さ、電源が入れられていなかった時間の長さ、もしくは、電源が入れられていた時間と電源が入れられていなかった時間の合計の長さ、
    前記評価値を算出する対象の前記第２のコンピュータにおいて、過去に、温度もしくは電圧に関する１つ以上の異常の各々が続いた時間の長さ、
    前記評価値を算出する対象の前記第２のコンピュータに関して前記評価値の算出のために前記故障予兆情報が用いられる前記所定の１台以上のコンピュータにおいて、過去に、温度もしくは電圧に関する１つ以上の異常の各々が続いた時間の長さ、または、
    前記複数のコンピュータのうち、前記評価値を算出する対象の前記第２のコンピュータと同じモデルの１台以上のコンピュータにおいて、過去に、１つ以上の異常の各々が続いた時間の長さ
    のいずれかに基づくことを特徴とする請求項６に記載のプログラム。
  8. 前記第２の部分評価値は、前記評価値を算出する対象の前記第２のコンピュータにおいて、過去に１日の中の前記特定の時間帯に異常が発生していたか否かを示す履歴に基づく
    ことを特徴とする請求項６に記載のプログラム。
  9. 前記プログラムが前記管理コンピュータに実行させる前記処理は、決められた基準が示すある蓋然性以下の蓋然性を示す値が前記評価値として算出された１台の第２のコンピュータを、前記第１のコンピュータと交代する第２のコンピュータとして選択することをさらに含み、
    前記基準は、前記評価値に関する所定の閾値により決められているか、または、前記複数の第２のコンピュータの中での前記評価値の相対的順序に関して決められている
    ことを特徴とする請求項１から８のいずれかに記載のプログラム。
  10. 冗長化システム中のアクティブな第１のコンピュータを含む、複数のコンピュータを管理する情報処理装置であって、
    前記複数のコンピュータのそれぞれから、故障の発生に関連する複数の種類の現象についての情報を含む故障予兆情報を収集する収集手段と、
    前記収集手段が収集した前記故障予兆情報を格納する格納手段と、
    前記冗長化システムにおいて前記第１のコンピュータと対応づけられている複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、当該第２のコンピュータに将来故障が生じる蓋然性を示す評価値を、当該第２のコンピュータから前記収集手段により収集されて前記格納手段に格納されている前記故障予兆情報と、前記複数のコンピュータのうち当該第２のコンピュータ以外の所定の１台以上のコンピュータから前記収集手段により収集されて前記格納手段に格納されている前記故障予兆情報とを用いて、算出する算出手段
    を備える情報処理装置。
  11. 冗長化システムにおいて動作中の第１のコンピュータを含む、複数のコンピュータを管理する管理コンピュータが実行する方法であって、
    前記複数のコンピュータのそれぞれから、故障の発生に関連する複数の種類の現象についての情報を含む故障予兆情報を収集し、
    前記冗長化システムにおいて前記第１のコンピュータと対応づけられている複数の第２のコンピュータのうちの１台以上の第２のコンピュータのそれぞれについて、当該第２のコンピュータに将来故障が生じる蓋然性を示す評価値を、当該第２のコンピュータから収集した前記故障予兆情報と、前記複数のコンピュータのうち当該第２のコンピュータ以外の所定の１台以上のコンピュータから収集した前記故障予兆情報とを用いて、算出する
    ことを特徴とする方法。
JP2013549984A 2011-12-19 2011-12-19 プログラム、情報処理装置および方法 Expired - Fee Related JP5949780B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/079424 WO2013094006A1 (ja) 2011-12-19 2011-12-19 プログラム、情報処理装置および方法

Publications (2)

Publication Number Publication Date
JPWO2013094006A1 true JPWO2013094006A1 (ja) 2015-04-27
JP5949780B2 JP5949780B2 (ja) 2016-07-13

Family

ID=48667936

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013549984A Expired - Fee Related JP5949780B2 (ja) 2011-12-19 2011-12-19 プログラム、情報処理装置および方法

Country Status (3)

Country Link
US (1) US9317394B2 (ja)
JP (1) JP5949780B2 (ja)
WO (1) WO2013094006A1 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10085140B2 (en) * 2012-07-13 2018-09-25 International Business Machines Corporation Preventing mobile communication device data loss
US10084718B1 (en) 2013-03-15 2018-09-25 Google Llc Bi-Connected hierarchical data center network based on multi-ported network interface controllers (NICs)
JP6126891B2 (ja) * 2013-03-29 2017-05-10 富士通株式会社 検出方法、検出プログラム、および検出装置
JP5719040B1 (ja) * 2013-08-20 2015-05-13 株式会社小松製作所 建設機械用コントローラ
US9437057B2 (en) 2013-08-20 2016-09-06 Komatsu Ltd. Construction machine controller
JP6413537B2 (ja) * 2013-10-23 2018-10-31 富士通株式会社 障害予兆通報装置および予兆通報方法、予兆通報プログラム
US9705798B1 (en) * 2014-01-07 2017-07-11 Google Inc. Systems and methods for routing data through data centers using an indirect generalized hypercube network
US9450833B2 (en) * 2014-03-26 2016-09-20 International Business Machines Corporation Predicting hardware failures in a server
US20160092287A1 (en) * 2014-09-26 2016-03-31 Intel Corporation Evidence-based replacement of storage nodes
TWI529624B (zh) * 2015-03-19 2016-04-11 Univ Nat Central Method and system of fault tolerance for multiple servers
JP6322161B2 (ja) * 2015-06-22 2018-05-09 日本電信電話株式会社 ノード、データ救済方法およびプログラム
US10467075B1 (en) * 2015-11-19 2019-11-05 American Megatrends International, Llc Systems, devices and methods for predicting disk failure and minimizing data loss
US10078455B2 (en) 2016-01-20 2018-09-18 Microsoft Technology Licensing, Llc Predicting solid state drive reliability
US10025671B2 (en) * 2016-08-08 2018-07-17 International Business Machines Corporation Smart virtual machine snapshotting
GB201621627D0 (en) * 2016-12-19 2017-02-01 Palantir Technologies Inc Task allocation
US20180232673A1 (en) * 2017-02-14 2018-08-16 U.SA. as represented by the Administrator of the National Aeronautics and Space Administration Lab quality management system
JP6803788B2 (ja) * 2017-03-29 2020-12-23 三菱重工業株式会社 情報処理装置、情報処理方法およびプログラム
JP6867589B2 (ja) * 2017-05-30 2021-04-28 富士通株式会社 影響範囲特定プログラム、影響範囲特定方法、および影響範囲特定装置
US10613950B2 (en) * 2018-01-05 2020-04-07 Quanta Computer Inc. CMC failover for two-stick canisters in rack design
US10853222B2 (en) 2018-07-25 2020-12-01 Dell Products, L.P. Apparatus and method for detecting poor component life zones in a datacenter
US11200141B2 (en) 2018-07-25 2021-12-14 Dell Products L.P. Apparatus and method for troubleshooting poor part life zones in a datacenter
US10846161B2 (en) 2018-07-25 2020-11-24 Dell Products, L.P. Apparatus and method for managing part life in a datacenter
JP7082285B2 (ja) * 2018-08-23 2022-06-08 富士通株式会社 監視システム、監視方法および監視プログラム
EP4012515A1 (en) 2020-12-09 2022-06-15 ABB Schweiz AG Preventive controller switchover
US11928691B2 (en) * 2021-06-11 2024-03-12 Dell Products L.P. Method and system for managing warranty claims associated with information handling systems
US11809264B2 (en) * 2022-03-24 2023-11-07 Dell Products L.P. Exothermic failure prediction engine

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07248933A (ja) * 1994-03-11 1995-09-26 Nec Corp ホットスタンバイシステム切り替えシステム
JPH0836502A (ja) * 1994-07-25 1996-02-06 Fujitsu Ltd 情報処理システム
JP2004030363A (ja) * 2002-06-27 2004-01-29 Hitachi Ltd 論理計算機システム、論理計算機システムの構成制御方法および論理計算機システムの構成制御プログラム
JP2004334713A (ja) * 2003-05-09 2004-11-25 Toshiba Corp 計算機システム、サービス継続制御プログラム
JP2007257645A (ja) * 2007-03-26 2007-10-04 Fujitsu Ltd 資産情報の一元管理を行うコンピュータシステム
JP2010244524A (ja) * 2009-03-17 2010-10-28 Hitachi Ltd 仮想サーバの移動方法の決定方法及びその管理サーバ
WO2011074284A1 (ja) * 2009-12-18 2011-06-23 株式会社日立製作所 仮想計算機の移動方法、仮想計算機システム及びプログラムを格納した記憶媒体
WO2011142042A1 (ja) * 2010-05-14 2011-11-17 株式会社日立製作所 サーバの信頼性可視化方法、計算機システム及び管理サーバ
JP2011248735A (ja) * 2010-05-28 2011-12-08 Hitachi Ltd サーバ計算機の切替方法、管理計算機及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6249446A (ja) 1985-08-28 1987-03-04 Nec Corp 情報処理システム監視装置
JP3887130B2 (ja) 1999-07-30 2007-02-28 株式会社東芝 高可用性計算機システム及び同システムにおけるデータバックアップ方法
US20080126881A1 (en) * 2006-07-26 2008-05-29 Tilmann Bruckhaus Method and apparatus for using performance parameters to predict a computer system failure
WO2008041302A1 (en) 2006-09-29 2008-04-10 Fujitsu Limited Server disposing program and server disposing method
JP2008152594A (ja) 2006-12-19 2008-07-03 Hitachi Ltd マルチコアプロセッサ計算機の高信頼化方法
US8037364B2 (en) * 2009-01-09 2011-10-11 International Business Machines Corporation Forced management module failover by BMC impeachment consensus
US7934131B1 (en) * 2009-02-24 2011-04-26 Google Inc. Server farm diagnostic and status system
US8484510B2 (en) * 2009-12-15 2013-07-09 Symantec Corporation Enhanced cluster failover management
WO2015023201A2 (en) * 2013-06-19 2015-02-19 Continuware Corporation Method and system for determining hardware life expectancy and failure prevention

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07248933A (ja) * 1994-03-11 1995-09-26 Nec Corp ホットスタンバイシステム切り替えシステム
JPH0836502A (ja) * 1994-07-25 1996-02-06 Fujitsu Ltd 情報処理システム
JP2004030363A (ja) * 2002-06-27 2004-01-29 Hitachi Ltd 論理計算機システム、論理計算機システムの構成制御方法および論理計算機システムの構成制御プログラム
JP2004334713A (ja) * 2003-05-09 2004-11-25 Toshiba Corp 計算機システム、サービス継続制御プログラム
JP2007257645A (ja) * 2007-03-26 2007-10-04 Fujitsu Ltd 資産情報の一元管理を行うコンピュータシステム
JP2010244524A (ja) * 2009-03-17 2010-10-28 Hitachi Ltd 仮想サーバの移動方法の決定方法及びその管理サーバ
WO2011074284A1 (ja) * 2009-12-18 2011-06-23 株式会社日立製作所 仮想計算機の移動方法、仮想計算機システム及びプログラムを格納した記憶媒体
WO2011142042A1 (ja) * 2010-05-14 2011-11-17 株式会社日立製作所 サーバの信頼性可視化方法、計算機システム及び管理サーバ
JP2011248735A (ja) * 2010-05-28 2011-12-08 Hitachi Ltd サーバ計算機の切替方法、管理計算機及びプログラム

Also Published As

Publication number Publication date
US20140298113A1 (en) 2014-10-02
WO2013094006A1 (ja) 2013-06-27
US9317394B2 (en) 2016-04-19
JP5949780B2 (ja) 2016-07-13

Similar Documents

Publication Publication Date Title
JP5949780B2 (ja) プログラム、情報処理装置および方法
CN107925612B (zh) 网络监视系统、网络监视方法和计算机可读介质
EP2685380B1 (en) Operations management unit, operations management method, and program
US7539907B1 (en) Method and apparatus for determining a predicted failure rate
CN102473134B (zh) 虚拟硬盘的管理服务器及管理方法、管理程序
US20150205657A1 (en) Predicting failure of a storage device
JP4990018B2 (ja) 装置性能管理方法、装置性能管理システム、および管理プログラム
US20130305083A1 (en) Cloud service recovery time prediction system, method and program
WO2012060824A1 (en) Solid-state disk (ssd) management
JP5583052B2 (ja) 故障予測・対策方法及びクライアントサーバシステム
US20230342343A1 (en) Data center modeling for facility operations
CN111026618A (zh) 自动生成自动警报合并的数据中心网络映射的系统和方法
US20140351149A1 (en) Replacement candidate presentation method and information processing apparatus
JP2016051425A (ja) ストレージ制御装置およびストレージ制御プログラム
US10890959B2 (en) Voltage correlation calculation
CN105204923A (zh) 用于资源预配置的方法和装置
JP2007068321A (ja) 無停電電源システム
US20140361978A1 (en) Portable computer monitoring
US20230236590A1 (en) Method and system for providing maintenance service for recording medium included in electronic device
US20050283635A1 (en) System and method for promoting effective service to computer users
KR20230020052A (ko) 인공지능과 빅데이터 플랫폼에 의한 장애 예측을 이용한 멀티클라우드 서비스 방법 및 시스템
US10877539B2 (en) System and method to prevent power supply failures based on data center environmental behavior
JP5696492B2 (ja) 故障検出装置、故障検出方法、及び、故障検出プログラム
JP4478196B2 (ja) 監視装置、監視プログラム、および情報処理システム
US20190324872A1 (en) System and Method to Predict and Prevent Power Supply Failures based on Data Center Environmental Behavior

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150924

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151119

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160523

R150 Certificate of patent or registration of utility model

Ref document number: 5949780

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees