JP5828348B2 - 試験サーバ、情報処理システム、試験プログラムおよび試験方法 - Google Patents

試験サーバ、情報処理システム、試験プログラムおよび試験方法 Download PDF

Info

Publication number
JP5828348B2
JP5828348B2 JP2013550022A JP2013550022A JP5828348B2 JP 5828348 B2 JP5828348 B2 JP 5828348B2 JP 2013550022 A JP2013550022 A JP 2013550022A JP 2013550022 A JP2013550022 A JP 2013550022A JP 5828348 B2 JP5828348 B2 JP 5828348B2
Authority
JP
Japan
Prior art keywords
server
test
unit
failover
servers
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.)
Active
Application number
JP2013550022A
Other languages
English (en)
Other versions
JPWO2013094048A1 (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 JPWO2013094048A1 publication Critical patent/JPWO2013094048A1/ja
Application granted granted Critical
Publication of JP5828348B2 publication Critical patent/JP5828348B2/ja
Active 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/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/2002—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 interconnections or communication control functionality are redundant
    • G06F11/2007—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 interconnections or communication control functionality are redundant using redundant communication media
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/2215—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test error correction or detection circuits

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Description

本発明は、試験サーバ、情報処理システム、試験プログラムおよび試験方法に関する。
従来、複数のサーバを有する情報処理システムには、いずれかのサーバが故障すると、故障したサーバが実行する業務を他のサーバが引き継ぐことで、サービスの停止を防ぐフェールオーバ機能が実装されている。
以下、図１８Ａ〜１８Ｄを用いて、フェールオーバ機能の例について説明する。図１８Ａは、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ型のフェールオーバ機能を説明するための図である。例えば、図１８Ａに示す例では、情報処理システムは、サービスＡおよびサービスＢを提供する運用系のサーバ＃１と、サービスを提供していない待機系のサーバ＃２とを有する。このような情報処理システムは、サーバ＃１に障害が発生した場合には、サーバ＃２がサービスＡおよびサービスＢの提供を引き継ぐことで、各サービスの提供を継続する。
図１８Ｂは、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ型のフェールオーバ機能を説明するための図である。図１８Ｂに示す例では、情報処理システムは、サービスＡを提供するサーバ＃１と、サービスＢを提供するサーバ＃２とを有する。このような情報処理システムは、サーバ＃１に障害が発生した場合には、サーバ＃２がサービスＡの提供を引き継ぐことで、各サービスの提供を継続する。
図１８Ｃは、Ｎ対１型のフェールオーバ機能を説明するための図である。図１８Ｃに示す例では、情報処理システムは、サービスＡを提供するサーバ＃１と、サービスＢを提供するサーバ＃２と、サービスＣを提供するサーバ＃３と、待機系のサーバ＃４とを有する。このような情報処理システムは、サーバ＃１に障害が発生した場合には、待機系のサーバ＃４がサービスＡの提供を引き継ぐことで、各サービスの提供を継続する。
図１８Ｄは、リング型のフェールオーバ機能を説明するための図である。図１８Ｃに示す例では、情報処理システムは、サービスＡを提供するサーバ＃１と、サービスＢを提供するサーバ＃２と、サービスＣを提供するサーバ＃３と、サービスＤを提供するサーバ＃４とを有する。このような情報処理システムは、いずれかのサーバ＃１〜＃４に障害が発生した場合には、障害が発生したサーバが提供するサービスを、リング状に設定した他のサーバが引き継ぐことで、各サービスの提供を継続する。例えば、情報処理システムは、サーバ＃１に障害が発生した場合には、サーバ＃２がサービスＡの提供を引き継ぐことで、各サービスの提供を継続する。
一方、情報処理システムに適用されたフェールオーバ機能が正常に動作するかを試験するため、情報処理システムが有するサーバに擬似的な故障を注入する技術が知られている。例えば、クリップ等の治具や擬似故障を発生させるためのソフトウェアなどを用いて、情報処理システムが有するサーバに擬似的な故障を発生させ、フェールオーバ機能が正常に動作するかを試験する技術が知られている。
以下、図１９を用いて、フェールオーバ機能が正常に動作するかを試験する技術の一例について説明する。図１９は、クラスタフェールオーバ試験の手順を示すフローチャートの一例である。なお、図１９に示す例では、複数のフェールオーバ機能が正常に動作するかをユーザが試験する例について説明する。
例えば、ユーザは、テスト対象となるサーバのクラスタを設計する（ステップＳ１）。次に、ユーザは、設計したクラスタを構築するためのサーバを準備し（ステップＳ２）、各サーバにＯＳ（Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）をインストールする（ステップＳ３）。
次に、ユーザは、各サーバに実行させるフェールオーバ機能やサービスの設定を行う（ステップＳ４）。そして、ユーザは、治具やソフトウェアなどを用いて、擬似的な故障をサーバに注入し、障害を発生させる（ステップＳ５）。その後、ユーザは、設定したフェールオーバ機能が正常に動作しているかを確認する（ステップＳ６）。
次に、ユーザは、情報処理システムの状態を障害発生前の状態に戻すフェールバック処理を行う（ステップＳ７）。また、ユーザは、全てのフェールオーバ機能について試験したか否かを判別し（ステップＳ８）、全てのフェールオーバ機能について試験した場合には（ステップＳ８肯定）、フェールオーバ機能の試験を終了する。
ここで、注入した故障の内容によっては、サーバが有するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）に記憶されたデータが破損し、ＯＳが正常に動作しなくなる結果、フェールバック処理を行えない場合がある。このため、ユーザは、全てのフェールオーバ機能を試験していない場合は（ステップＳ８否定）、各サーバのＨＤＤに記憶されたデータが破損しているか否かを判別する（ステップＳ９）。
そして、ユーザは、いずれかのサーバのＨＤＤに記憶されたデータが破損している場合は（ステップＳ９肯定）、ステップＳ３に戻り、ＯＳを再度インストールする（ステップＳ３）。また、ユーザは、各サーバのＨＤＤに記憶されたデータが破損していない場合は（ステップＳ９否定）、ステップＳ５に戻り、擬似的な故障をサーバに注入して障害を発生させる（ステップＳ５）。
特開２０００−０５７１０８号公報 特開昭５６−０２１２５３号公報 特開平０７−２６２１０１号公報
しかしながら、治具やソフトウェア等を用いて故障を注入する技術では、いずれかのサーバのＨＤＤが記憶するデータが破損した場合は、再度ＯＳのインストールを行うので、フェールオーバ機能を連続して試験することができないという問題がある。
例えば、サーバが有するＨＤＤにデータを書込み中に、サーバの電源を強制的に落とした場合や、ＨＤＤに訂正不能データを注入した場合等には、ＯＳのデータが破損する場合がある。このような場合には、ユーザは、フェールバック処理を正常に行えないため、再度ＯＳのインストールを行う。この結果、ユーザは、フェールオーバ機能を連続して試験することができない。
１つの側面では、本願に開示の技術は、情報処理システムのフェールオーバ機能を連続して試験することを目的とする。
１つの側面では、いずれかのサーバに故障が発生するとフェールオーバを実行する複数のサーバがフェールオーバを正常に実行するかを試験する試験サーバである。このような試験サーバは、試験対象となるサーバに実行させるＯＳのイメージファイルを生成する。そして、試験サーバは、生成したイメージファイルを試験対象となるサーバに送信する。また、試験サーバは、イメージファイルを送信したサーバに対して、擬似的な故障を注入し、イメージファイルを送信したサーバがフェールオーバを正常に実行したか否かを試験する。また、試験サーバは、試験を実行する度に、試験対象となるサーバの状態をフェールオーバ前の状態に復帰させる。また、試験サーバは、試験対象となるサーバの状態を正常に復帰させたか否かを判別し、試験対象となるサーバの状態を正常に復帰させなかったと判別した場合には、試験対象となるサーバの電源を落とし、その後再投入する。そして、試験サーバは、電源を再投入したサーバに対して、イメージファイルの送信と、試験とを繰り返し実行する。
１つの側面では、情報処理システムのフェールオーバ機能を連続して試験できる。
図１は、実施例１に係る情報処理システムを説明するための図である。 図２は、実施例１に係る管理サーバＯＳの機能構成を説明するための図である。 図３は、試験内容選択画面の一例を示す図である。 図４は、実施例１に係るフェールオーバ診断システムが生成するリスト１の一例を説明するための図である。 図５は、実施例１に係るフェールオーバ診断システムが生成するリスト２の一例を説明するための図である。 図６は、実施例１に係るフェールオーバ診断システムが生成するリスト３の一例を説明するための図である。 図７は、実施例１に係るフェールオーバ診断システムが生成するリスト４の一例を説明するための図である。 図８は、実施例１に係る管理サーバが収集する情報の一例を示す図である。 図９は、実施例１に係る管理サーバが実行する試験の一例を説明するための図である。 図１０は、実施例１に係る管理サーバが生成する表の一例を説明するための図である。 図１１は、実施例１に係る管理サーバが各サーバに実行させるテストの一例を説明するための図である。 図１２は、実施例１に係る管理サーバが利用者に提示する試験結果の一例を説明するための図である。 図１３は、実施例１に係る管理サーバが実行する処理の流れを説明するための第１のフローチャートである。 図１４は、実施例１に係る管理サーバが実行する処理の流れを説明するための第２のフローチャートである。 図１５は、実施例１に係る管理サーバが実行する処理の流れを説明するための第３のフローチャートである。 図１６は、実施例１に係る管理サーバが試験内容を示すリストを作成する処理の流れの一例を説明するためのフローチャートである。 図１７は、実施例２に係る管理サーバが仮想サーバのフェールオーバ試験を実行する処理の一例を説明するための図である。 図１８Ａは、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ型のフェールオーバ機能を説明するための図である。 図１８Ｂは、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ型のフェールオーバ機能を説明するための図である。 図１８Ｃは、Ｎ対１型のフェールオーバ機能を説明するための図である。 図１８Ｄは、リング型のフェールオーバ機能を説明するための図である。 図１９は、クラスタフェールオーバ試験の手順を示すフローチャートの一例である。
以下に添付図面を参照して本願に係る試験サーバ、情報処理システム、試験プログラムおよび試験方法について説明する。
以下の実施例１では、図１を用いて、フェールーオーバ機能を有する複数のサーバと、各サーバがフェールオーバ機能を正常に実行するかを試験する管理サーバとを有する情報処理システムの一例を説明する。図１は、実施例１に係る情報処理システムを説明するための図である。
図１に示すように、情報処理システム１は、管理サーバ１０、複数のサーバ２０〜２２、共有ドライブ２３、複数のユーザＰＣ（Personal Computer）３０〜３１を有する。管理サーバ１０は、ＣＰＵ（Central Processing Unit）１１、メモリ１２、ＨＤＤ（Hard Disk Drive）１３、ＬＡＮカード（Local Area Network Card）１７を有する。また、ＨＤＤ１３は、管理サーバが実行するＯＳ（Operation System）である管理サーバＯＳ１４を記憶する。管理サーバＯＳ１４は、フェールオーバ診断システム１５とサーバ配信ＯＳ１６とを有する。
サーバ２０は、ＬＡＮカード２０ａ、ＣＰＵ２０ｂ、メモリ２０ｃ、ＨＤＤ２０ｄを有する。なお、同様に、サーバ２１、および、サーバ２２は、ＬＡＮカード２１ａ、２２ａ、ＣＰＵ２１ｂ、２２ｂ、メモリ２１ｃ、２２ｃ、ＨＤＤ２１ｄ、２２ｄを有する。
なお、共有ドライブ２３は、ＬＡＮカード２３ａと、ＬＡＮを介して各サーバ２０〜２２によって共有されるＨＤＤ２３ｂ〜２３ｄを有する共有ドライブである。また、ユーザＰＣ３０、３１は、ＬＡＮカード３０ａ、３１ａ、ＣＰＵ３０ｂ、３１ｂ、メモリ３０ｃ、３１ｃ、ＨＤＤ３０ｄ、３１ｄを有し、ＬＡＮを介して、各サーバ２０〜２２からサービスの提供を受ける情報処理装置である。
このような情報処理システム１において、管理サーバ１０は、各サーバ２０〜２２が正常にフェールオーバを実行するかを試験する。具体的には、管理サーバ１０は、各サーバ２０〜２２のうち、フェールオーバを試験する対象となるサーバに実行させるＯＳのイメージファイルを生成する。そして、管理サーバ１０は、試験対象となるサーバに対して、生成したイメージファイルを送信する。
ここで、各サーバ２０〜２２は、管理サーバ１０が生成したイメージファイルを用いて、ネットワークブートを実行する機能を有する。このため、各サーバ２０〜２２は、管理サーバ１０が送信したイメージファイルを取得した場合には、取得したイメージファイルをメモリ２０ｃ〜２２ｃに格納し、ネットワークブートを実行する。
その後、管理サーバ１０は、各サーバ２０〜２２のうち、いずれかのサーバに対して、擬似故障を注入し、フェールオーバを実行させる。そして、管理サーバ１０は、各サーバ２０〜２２がフェールオーバを正常に実行したか否かを判別する。
このため、管理サーバ１０は、各サーバ２０〜２２がフェールオーバを正常に実行したか否かを連続して試験することができる。例えば、管理サーバ１０は、サーバ２０に擬似故障を注入し、フェールオーバが正常に実行されたか判別する。また、管理サーバ１０は、連続して試験を行う場合には、試験対象となったサーバにフェールバックを実行させ、正常にフェールバックできなかった場合には、試験対象となったサーバにＯＳのイメージファイルを再度送信し、ネットワークブートを実行させる。
このため、管理サーバ１０は、フェールオーバ試験を実行した結果、各サーバ２０〜２２のＨＤＤ２０ｄ〜２２ｄが記憶するデータが欠損し、正常にフェールバックできなかった場合にも、各サーバ２０〜２２にＯＳをインストールする必要がない。この結果、管理サーバ１０は、フェールオーバ試験を連続して実行することができる。
次に、図２を用いて、管理サーバ１０が実行する管理サーバＯＳ１４について説明する。図２は、実施例１に係る管理サーバＯＳの機能構成を説明するための図である。図２に示す例では、管理サーバＯＳ１４は、フェールオーバ診断システム１５とサーバ配信ＯＳ１６とを有する。
フェールオーバ診断システム１５は、マスタ制御部１８、ＯＳイメージ作成部１８ａ、サーバ電源制御部１８ｂ、ＯＳ配信部１８ｃ、サーバ監視部１８ｄ、試験項目抽出部１８ｅ、試験可否判定部１８ｆ、試験順序決定部１８ｇを有する。また、フェールオーバ診断システム１５は、擬似故障注入タイミング制御部１８ｈ、擬似故障注入実行制御部１８ｉ、結果判定部１８ｊを有する。また、サーバ配信ＯＳ１６は、サーバ制御部１９、構成情報収集部１９ａ、ハード診断部１９ｂ、擬似故障注入部１９ｃ、構成情報通知部１９ｄを有する。
まず、フェールオーバ診断システム１５が有する各部１８〜１８ｊが実行する処理について説明する。マスタ制御部１８は、各部１８ａ〜１８ｊを制御し、以下の処理を実行する。すなわち、マスタ制御部１８は、各サーバ２０〜２２に送信するサーバ配信ＯＳ１６を生成する。また、マスタ制御部１８は、ユーザからの指定に基づいて、試験内容を生成するとともに、試験対象となるサーバを選択する。そして、マスタ制御部１８は、生成したサーバ配信ＯＳ１６を選択したサーバに送信し、ネットワークブートを実行させる。
その後、マスタ制御部１８は、生成した試験内容を全て実行したか否かを判別し、まだ実行していない試験内容が存在する場合には、以下の処理を実行する。すなわち、マスタ制御部１８は、新たな試験を実行するためのサーバ配信ＯＳ１６を生成する。また、マスタ制御部１８は、各サーバ２０〜２２にフェールバックを実行させる。また、マスタ制御部１８は、フェールバックが正常に行えなかった場合には、試験対象となるサーバの電源を落とし、再投入する。その後、マスタ制御部１８は、新たなサーバ配信ＯＳ１６を、試験対象となるサーバに送信する。
以下、マスタ制御部１８が各部１８ａ〜１８ｊを用いて実行する処理を具体的に説明する。まず、各部１８ａ〜１８ｊが実行する処理について説明する。ＯＳイメージ作成部１８ａは、サーバ配信ＯＳ１６のイメージファイルを生成する。具体的には、ＯＳイメージ作成部１８ａは、サーバが有するハードウェア情報を収集する機能と、各ハードウェアが正常に動作するか否かの診断を実行する機能とを有するサーバ配信ＯＳ１６を生成する。
また、ＯＳイメージ作成部１８ａは、収集した情報と診断結果とを管理サーバ１０に送信する機能と、擬似故障をサーバに注入する機能とを有するサーバ配信ＯＳ１６を生成する。なお、ＯＳイメージ作成部１８ａは、フェールオーバを実行する機能を有するサーバ配信ＯＳ１６を生成する。また、ＯＳイメージ作成部１８ａは、管理サーバ１０の指示によりサーバの状態をフェールオーバ前の状態に戻すフェールバックを実行する機能を有するサーバ配信ＯＳ１６を生成する。そして、ＯＳイメージ作成部１８ａは、生成したサーバ配信ＯＳ１６のイメージファイルを生成する。
サーバ電源制御部１８ｂは、各サーバ２０〜２２の電源をリモートで制御する。例えば、サーバ電源制御部１８ｂは、Ｗａｋｅ ｏｎ ＬＡＮやＩＰＭＩ（Intelligent Platform Management Interface）の手法を用いて、試験対象となるサーバの電源を投入する。また、サーバ電源制御部１８ｂは、試験後のフェールバック処理が正常に実行されなかった場合には、試験対象となったサーバの電源を落とし、その後、再投入することで再起動させる。
ＯＳ配信部１８ｃは、サーバ配信ＯＳ１６のイメージファイルを用いてネットワークブートを実行するサーバ２０〜２２に対して、サーバ配信ＯＳ１６のイメージファイルを送信する。以下、ＯＳ配信部１８ｃがサーバ配信ＯＳ１６のイメージファイルを送信する処理の一例について説明する。なお、以下の説明では、各サーバ２０〜２２は、ＰＸＥ(Preboot Execution Environment)ブートの手法を用いて、ネットワークブートを実行するものとする。また、以下の説明では、管理サーバ１０が実行する管理サーバＯＳ１４は、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバとして動作する機能を有するものとする。
例えば、各サーバ２０〜２２のうち、試験対象となるサーバ、すなわち、サーバ電源制御部１８ｂにより電源が投入されたサーバは、以下の処理を実行する。すなわち、サーバは、ＤＨＣＰ（Dynamic Host Configuration Protocol）として動作する管理サーバ１０にＩＰ（Internet Protocol）アドレスの付与を要求する。このような場合には、管理サーバ１０は、要求元のサーバ、すなわち、試験対象となるサーバに対して、ＩＰアドレスを付与する。
また、ＯＳ配信部１８ｃは、サーバ電源制御部１８ｂによって電源が投入されたサーバにＮＢＰ（Network Bootstrap Program）を送信する。このような場合には、ＮＢＰを取得したサーバは、ＴＦＴＰ（Trivial File Transfer Protocol）を用いて、サーバ配信ＯＳ１６の取得を要求する。このような場合には、ＯＳ配信部１８ｃは、サーバ配信ＯＳ１６のイメージファイルを要求元のサーバへ送信する。この結果、各サーバ２０〜２２は、サーバ配信ＯＳ１６をネットワークブートして実行することとなる。
サーバ監視部１８ｄは、サーバ配信ＯＳ１６を配信したサーバの状態を監視する。例えば、サーバ監視部１８ｄは、後述するようにサーバ配信用ＯＳ１６の構成情報収集部１９ａが収集した情報、および、ハード診断部１９ｂによるハードウェアの診断結果を収集する。そして、サーバ監視部１８ｄは、収集した情報や診断結果に基づいて、サーバ配信用ＯＳ１６が有する各ハードウェアの状態、提供中のサービス、サーバ側による監視結果等の情報を識別する。
試験項目抽出部１８ｅは、サーバ監視部１８ｄによって収集された情報と、利用者から指定された試験内容とに応じて、実行する試験項目と、指定された項目の試験を実行させるサーバとを選択する。以下、図３を用いて、試験項目抽出部１８ｅが試験項目とサーバとを選択する処理の一例について説明する。図３は、試験内容選択画面の一例を示す図である。
例えば、試験項目抽出部１８ｅは、図３に例示する画面を用いて、利用者が試験内容を指定した場合には、利用者が指定した試験内容を識別する。図３に示す例では、管理サーバ１０の利用者は、図３中の「＊」で、試験対象となるサーバと、実行させるフェールオーバの種別と、注入する擬似故障と、試験対象となるサーバと、試験内容とを選択する。
例えば、図３中「Ｔｅｓｔ Ｕｓｉｎｇ Ｓｅｒｖｅｒ Ｓｅｌｅｃｔ：」とは、試験対象となるサーバを指定するための範囲である。図３に示す例では、利用者は、全てのサーバを試験対象とする旨を示す「ＡＬＬ」を選択する。ここで、Ｓｅｒｖｅｒ＃１とは、サーバ２０を示し、Ｓｅｒｖｅｒ＃２とは、サーバ２１を示し、Ｓｅｒｖｅｒ＃Ｎとは、サーバ２２を示す。
また、図３中「ＦａｉｌＯｖｅｒＴｙｐｅ＆ＥｒｒｏｒＴａｒｇｅｔ」とは、試験対象となるサーバに実行させるフェールオーバの種別と、試験対象となるサーバに注入する擬似故障の種別を指定するための画面である。図３に示す例では、全ての種別のフェールオーバを試験対象となるサーバに実行させる「ＡＬＬ」が選択されている。
なお、「２Ｓｅｒｖｅｒ Ｃｏｎｆｉｇｒａｔｉｏｎ」とは、２つのサーバによって実行されるフェールオーバの種別を示し、「ＬａｒｇｅＳｅｒｖｅｒＣｏｎｆｉｇｒａｔｉｏｎ」とは、３つ以上のサーバによって実行されるフェールオーバの種別を示す。また、「Ａｃｔｉｖｅ Ｓｅｒｖｉｃｅ：」とは、試験対象となるサーバに実行させるサービスの内容を指定するための範囲である。図３に示す例では、試験対象となるサーバにｈｔｔｐ（Hyper Text Transfer Protocol）とｆｔｐ（File Transfer Protocol）のサービスを提供させるよう選択されている。
また、「Ｅｒｒｏｒ Ｓｅｔｔｉｎｇ：」とは、試験対象となるサーバに注入する擬似故障の種別を指定するための範囲である。ここで、「Ｅｒｒｏｒ Ｓｅｔｔｉｎｇ」の「Ｓｅｒｖｉｃｅ」とは、サーバが提供するサービスに対するエラー、すなわち、サーバが実行するソフトウェアに対して注入する擬似的なエラーを指定するための画面である。
また、「Ｈａｒｄ」とは、サーバが有するハードウェアに対して注入する擬似的なエラーを指定するための画面である。図３に示す例では、サービスに対するエラーとして、ｈｔｔｐサービスについて擬似的なエラーを挿入するよう選択され、ハードウェアに対するエラーとしてメモリに擬似的なエラーを挿入するよう選択されている。
試験項目抽出部１８ｅは、利用者が指定した、試験対象となるフェールオーバの種別、試験対象となるサーバ、提供させるサービスの種別、挿入する擬似的なエラーの種別を抽出する。そして、試験項目抽出部１８ｅは、抽出したフェールオーバの種別に基づいて、試験対象とする運用系のサーバと待機系のサーバの数とを示すリスト１を作成する。
すなわち、試験対象となるフェールオーバの種別によって、試験に必要な運用系のサーバと待機系のサーバの数は変化する。例えば、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ形式のフェールオーバを試験する場合には、運用系のサーバと、待機系のサーバとは、それぞれ１つ以上必要となる。また、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ形式のフェールオーバを試験する場合には、運用系のサーバが２台以上必要となる。また、Ｎ対１形式のフェールオーバを試験する場合には、運用系のサーバが提供サービスの数だけ必要となり、待機系のサーバが１台必要となる。
そこで、試験項目抽出部１８ｅは、試験対象となるフェールオーバの種別に基づいて、図４に例示するリスト１を作成する。図４は、実施例１に係るフェールオーバ診断システムが生成するリスト１の一例を説明するための図である。図４に示すように、リスト１には、試験するフェールオーバの種別と、試験対象となるサーバの数とが対応付けられる。
例えば、図４に示す例では、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ形式のフェールオーバを試験する際に、１台の運用系サーバと１台の待機系サーバを試験対象とする旨を示すリスト１を作成する。また、図４に示す例では、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ形式のフェールオーバを試験する際に、２台の運用系サーバを試験対象とする旨を示すリスト１を作成する。
また、図４に示す例では、試験項目抽出部１８ｅは、Ｎ対１形式のフェールオーバを試験する際に、２台の運用系サーバと１台の待機系サーバを試験対象とする旨、および、３台の運用系サーバと１台の待機系サーバを試験対象とする旨を示すリスト１を作成する。
次に、試験項目抽出部１８ｅは、試験対象となるサーバに、利用者が指定したサービスを網羅的に割り振ったリスト２を作成する。具体的には、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ形式の試験を行う場合には、１つの運用系のサーバに対して全てのサービスを割り振る。
また、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ形式の試験を行う場合には、全ての運用系のサーバに対して全てのサービスを割り振る。また、試験項目抽出部１８ｅは、Ｎ対１形式のフェールオーバを試験する場合には、各運用系のサーバにサービスを分散させる。なお、Ｎ＋１形式のフェールオーバを試験する場合には、全ての運用系のサーバが何らかのサービスを提供するように割り振る。
図５は、実施例１に係るフェールオーバ診断システムが生成するリスト２の一例を説明するための図である。なお、図５に示す例では、リスト２は、図４に例示したリスト１に試験対象となる運用系のサーバに割り振るサービスと待機サーバとを対応付けたリストである。また、図５に示す「Ｓｅｒｖｅｒ＃３」、「Ｓｅｒｖｅｒ＃４」は、図１において表示を省略したサーバとなる。また、図５に示す例では、試験項目抽出部１８ｅは、各運用系のサーバに対して、３つのサービスＡ〜Ｃを割り振るものとする。
すなわち、図５に示す例では、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ形式のフェールオーバを試験する場合には、Ｓｅｒｖｅｒ＃１にサービスＡ〜Ｃを割り振り、Ｓｅｒｖｅｒ＃４を待機系のサーバとする。この際、試験項目抽出部１８ｅは、Ｓｅｒｖｅｒ＃２、Ｓｅｒｖｅｒ＃３を未使用のサーバとする。また、試験項目抽出部１８ｅは、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ形式のフェールオーバを試験する場合には、Ｓｅｒｖｅｒ＃１とＳｅｒｖｅｒ＃２にサービスＡ〜Ｃを割り振り、Ｓｅｒｖｅｒ＃３とＳｅｒｖｅｒ＃４とを未使用とする。
また、試験項目抽出部１８ｅは、運用系のサーバ２台と待機系のサーバ１台とにＮ対１形式のフェールオーバを試験する場合には、Ｓｅｒｖｅｒ＃１にサービスＡおよびサービスＢを割り振り、Ｓｅｒｖｅｒ＃２にサービスＣを割り振る。または、試験項目抽出部１８ｅは、Ｓｅｒｖｅｒ＃１にサービスＡを提供させ、Ｓｅｒｖｅｒ＃２にサービスＢおよびサービスＣを割り振る。なお、試験項目抽出部１８ｅは、運用系のサーバ２台と待機系のサーバ１台とにＮ対１形式のフェールオーバを試験する場合には、Ｓｅｒｖｅｒ＃４を待機系のサーバとする。
また、試験項目抽出部１８ｅは、運用系のサーバ３台と待機系のサーバ１台とにＮ対１形式のフェールオーバを試験する場合には、Ｓｅｒｖｅｒ＃１にサービスＡを割り振り、Ｓｅｒｖｅｒ＃２にサービスＢを割り振り、Ｓｅｒｖｅｒ＃３にサービスＣを割り振る。また、試験項目抽出部１８ｅは、Ｓｅｒｖｅｒ＃４を待機系のサーバとする。
次に、試験項目抽出部１８ｅは、リスト２の各項目に対して、利用者から指定された擬似的なエラーを注入するサーバを網羅的に示したリストを作成する。詳細には、試験項目抽出部１８ｅは、擬似的なエラーの注入先となる各サーバのハードウェアを網羅的に示したリスト３と、擬似的なエラーの注入先となる各サーバが提供するサービスを網羅的に示したリスト４とを生成する。
図６は、実施例１に係るフェールオーバ診断システムが生成するリスト３の一例を説明するための図である。図６に示す例では、リスト３は、図５に例示したリスト２に対して、擬似故障を注入するハードウェアを網羅的に対応付けたリストである。図６に示す例では、試験項目抽出部１８ｅは、各種別のフェールオーバを試験する際に使用するサーバのＣＰＵおよびＤＩＭＭ（Dual Inline Memory Module）、すなわちメモリを、擬似的な故障の注入先として網羅的に割り振ったリスト３を生成する。
図７は、実施例１に係るフェールオーバ診断システムが生成するリスト４の一例を説明するための図である。図７に示す例では、リスト４は、図５に例示したリスト２に対して、擬似故障を注入するサービスを網羅的に対応付けたリストである。図７に示す例では、試験項目抽出部１８ｅは、各種別のフェールオーバを試験する際に使用するサーバが実行するサービスを、擬似的な故障の注入先として網羅的に割り振ったリスト４を生成する。なお、図７に示す例では、試験項目抽出部１８ｅは、各サーバが実行するサービスＡ〜Ｃをハングアップさせるエラーを注入する旨を示すリスト４を作成する。
なお、試験項目抽出部１８ｅは、複数エラーの同時注入や、擬似的なエラーを挿入するタイミング、サーバに加える負荷状態等を調節した試験を実施する場合には、以下の処理を実行する。すなわち、試験項目抽出部１８ｅは、利用者の指定に基づいて、リスト３およびリスト４に対して、複数エラーの同時注入や、擬似的なエラーを挿入するタイミング、サーバに加える負荷状態等を網羅的に対応付けたリストを作成する。
図２に戻って、試験可否判定部１８ｆは、試験項目抽出部１８ｅから試験項目と試験対象となるサーバとの通知を取得した場合は、通知された試験項目を実行できるか否かを判別する。例えば、試験可否判定部１８ｆは、サーバ監視部１８ｄが収集したハードウェア情報と、診断結果とに基づいて、ハード故障の有無やサーバ間で同一デバイスを実装しているか等、試験対象として適さない装置構成のサーバが存在するか否かを判別する。そして、試験可否判定部１８ｆは、試験対象として適さない装置構成のサーバが存在する場合には、利用者に通知を行う。
また、試験可否判定部１８ｆは、試験項目抽出部１８ｅが作成したリスト３およびリスト４を参照する。そして、試験可否判定部１８ｆは、サーバ監視部１８ｄが収集した各サーバ２０〜２２のハードウェアを示す情報、および、ハードウェアの診断情報に基づいてリスト３およびリスト４が示す各試験を実行できるか否かを判別する。
試験順序決定部１８ｇは、各試験を実行できると試験可否判定部１８ｆが判定した場合には、通知された試験項目を効率的に進めるため、以下の処理を実行する。すなわち、試験順序決定部１８ｇは、試験項目を効率的に実行するための順序を判別する。
また、試験順序決定部１８ｇは、試験対象のサーバを複数の組に分割し、通知された項目の試験を分割した各組ごとに並列して実行できるか否かを判別する。そして、試験順序決定部１８ｇは、通知された項目の試験を分割した各組ごとに並列して実行できると判別した場合には、各組に含まれるサーバと、各組が実行する試験の順序とを擬似故障注入タイミング制御部１８ｈに通知する。
擬似故障注入タイミング制御部１８ｈは、サーバ監視部１８ｄが収集した情報に基づいて、試験対象となるサーバに擬似故障を注入するタイミングであるか否かを判別する。そして、擬似故障注入タイミング制御部１８ｈは、擬似故障を注入するタイミングであると判別した場合には、擬似故障を注入するよう擬似故障注入実行制御部１８ｉに指示する。
具体的には、擬似故障注入タイミング制御部１８ｈは、試験項目抽出部１８ｅが作成したリストを参照し、利用者によって指定された擬似故障を注入するタイミングを識別する。また、擬似故障注入タイミング制御部１８ｈは、サーバ監視部１８ｄが収集した情報に基づいて、試験対象となるサーバの状態を識別する。そして、擬似故障注入タイミング制御部１８ｈは、試験対象となるサーバの状態が、利用者によって指定された擬似故障を注入するタイミングとなった場合には、擬似故障を注入するよう擬似故障注入実行制御部１８ｉに指示する。
擬似故障注入実行制御部１８ｉは、擬似故障を注入するサーバの状態が擬似故障を注入するタイミングとなった場合には、擬似故障をサーバに注入する。具体的には、擬似故障注入実行制御部１８ｉは、擬似故障を発生させるサーバが実行するサーバ配信ＯＳ１６に対して、擬似故障を注入するよう指示する。
結果判定部１８ｊは、各サーバ２０〜２２がフェールオーバ試験を正常に実行したか否かを試験する。例えば、結果判定部１８ｊは、サーバ監視部１８ｄが収集した各サーバ２０〜２２の情報を用いて、擬似故障注入前に各サーバ２０〜２２が提供していたサービスと、擬似故障注入後に各サーバ２０〜２２が提供していたサービスとを比較する。そして、結果判定部１８ｊは、比較結果と、実行する試験項目とに応じて、フェールオーバが正常に実行されたか否かを判別する。
次に、サーバ配信ＯＳ１６が有する各部１９〜１９ｄが実行する処理について説明する。サーバ制御部１９は、各サーバ２０〜２２がサーバ配信ＯＳ１６をネットワークブートすることにより実行され、各部１９ａ〜１９ｄを制御し、以下の処理を実行する。すなわち、サーバ制御部１９は、サーバ２０〜２２が有するハードウェア情報を収集する。また、サーバ制御部１９は、サーバ２０〜２２が有するハードウェアの状態を診断する。
そして、サーバ制御部１９は、収集したハードウェア情報と、診断したハードウェアの状態とを、管理サーバ１０に対して送信する。また、管理サーバ１０から擬似的な故障を注入するよう指示された場合には、サーバ２０〜２２に対して、擬似的な故障を注入する。なお、サーバ制御部１９は、フェールオーバ、および、フェールバックを実行するための機能を有する。
構成情報収集部１９ａは、サーバ配信ＯＳ１６を実行するサーバが有するハードウェア情報を収集する。そして、構成情報収集部１９ａは、収集した情報をハード診断部１９ｂと、構成情報通知部１９ｄとに通知する。
例えば、構成情報収集部１９ａは、サーバ２０がＬＡＮカード２０ａ、ＣＰＵ２０ｂ、メモリ２０ｃ、ＨＤＤ２０ｄを有する旨を示すハードウェア情報をハード診断部１９ｂと、構成情報通知部１９ｄとに通知する。また、構成情報収集部１９ａは、ＣＰＵ２０ｂが有するコアの数、メモリ２０ｃの種別および容量、ＨＤＤ２０ｄの容量、ＬＡＮカード２０ａによる通信速度等を構成情報通知部１９ｄに通知する。
ハード診断部１９ｂは、サーバ配信ＯＳ１６を実行するサーバが有するハードウェアの状態を診断する。具体的には、ハード診断部１９ｂは、構成情報収集部１９ａが収集した情報に基づいて、サーバ配信ＯＳ１６を実行するサーバが有するハードウェアを識別する。次に、ハード診断部１９ｂは、識別したハードウェアが正常に動作するか否かを診断する。そして、ハード診断部１９ｂは、診断結果を構成情報通知部１９ｄに通知する。
擬似故障注入部１９ｃは、管理サーバ１０から擬似的な故障を注入する旨の指示を取得した場合は、サーバ配信ＯＳ１６を実行するサーバに擬似的な故障を注入する。例えば、サーバ２０が実行するサーバ配信ＯＳ１６の擬似故障注入部１９ｃは、管理サーバ１０からＣＰＵに擬似的な故障を注入する旨の指示を取得した場合には、以下の処理を実行する。
例えば、擬似故障注入部１９ｃは、ＣＰＵ２０ｂのレジスタに格納されたビットを反転する等の処理を実行することで、ＣＰＵ２０ｂに擬似的なエラーを注入する。また、例えば、擬似故障注入部１９ｃは、管理サーバ１０からｔｅｌｎｅｔ（Telecommunication network）に擬似的な故障を注入する旨の指示を取得した場合には、ｔｅｌｎｅｔのサービスを停止する。
構成情報通知部１９ｄは、サーバ配信ＯＳ１６を実行するサーバの構成情報を管理サーバ１０に送信する。例えば、サーバ２０が実行するサーバ配信ＯＳ１６の構成情報通知部１９ｄは、構成情報収集部１９ａからＬＡＮカード２０ａ、ＣＰＵ２０ｂ、メモリ２０ｃ、ＨＤＤ２０ｄの情報を取得する。また、構成情報通知部１９ｄは、ハード診断部１９ｂからＬＡＮカード２０ａ、ＣＰＵ２０ｂ、メモリ２０ｃ、ＨＤＤ２０ｄが正常に動作するか否かの診断結果を取得する。
そして、構成情報通知部１９ｄは、取得したハードウェア情報と診断結果とを、管理サーバ１０に送信する。なお、構成情報通知部１９ｄが管理サーバ１０に送信したハードウェア情報と診断結果とは、フェールオーバ診断システム１５が有するサーバ監視部１８ｄによって収集される。
次に、上述したフェールオーバ診断システム１５を実行する管理サーバ１０が、サーバ２０〜２２が正常にフェールオーバを実行するか否かを試験する処理の一例について説明する。例えば、管理サーバ１０は、ＯＳイメージ作成部１８ａを用いて、サーバ制御部１９、構成情報収集部１９ａ、ハード診断部１９ｂ、擬似故障注入部１９ｃ、構成情報通知部１９ｄを有するサーバ配信用ＯＳ１６を生成する。そして、管理サーバ１０は、生成したサーバ配信用ＯＳ１６のイメージファイルを生成し、生成したイメージファイルをＨＤＤ１３に格納する。
次に、管理サーバ１０は、サーバ電源制御部１８ｂを用いて、各サーバ２０〜２２の電源をリモートＯＮし、その後、ＯＳ配信部１８ｃを用いて、各サーバ２０〜２２に対して、サーバ配信ＯＳ１６のイメージファイルを送信する。なお、各サーバ２０〜２２は、管理サーバ１０から送信されたイメージファイルを取得し、取得したイメージファイルをメモリに格納し、ネットワークブートを実行する。
すると、各サーバ２０〜２２は、構成情報収集部１９ａが収集したハードウェア情報と、ハード診断部１９ｂによる診断結果とを管理サーバ１０に送信する。このような場合には、管理サーバ１０は、ハードウェア情報と診断結果とを取得し、各サーバ２０〜２２の電源を落とす。
次に、管理サーバ１０は、試験項目抽出部１８ｅを用いて、以下の処理を実行する。すなわち、管理サーバ１０は、利用者が指定した試験内容を取得する。そして、管理サーバ１０は、取得した試験内容から試験項目を抽出し、試験項目を示すリスト３およびリスト４を作成する。また、管理サーバ１０は、試験可否判定部１８ｆを用いて、リスト３およびリスト４が示す試験を実行できるか否かを判別する。
また、管理サーバ１０は、リスト３およびリスト４が示す試験を実行できると判別すると、以下の処理を実行する。すなわち、管理サーバ１０は、試験順序決定部１８ｇを用いて、リスト３およびリスト４が示す試験を効率的に実行する順序を識別するとともに、試験対象となるサーバを複数の組に分割し、各組ごとに試験を並列して実行できるか否かを判別する。
次に、管理サーバ１０は、ＯＳイメージ作成部１８ａを用いて、リスト３およびリスト４が示す試験の対象となるサーバごとにサーバ配信ＯＳ１６を生成する。この際、管理サーバ１０は、サーバの状態を試験後の状態に戻すフェールバック処理を実行する機能を有するサーバ配信ＯＳ１６を生成する。そして、管理サーバ１０は、サーバ電源制御部１８ｂを用いて試験対象となるサーバの電源を投入するとともに、新たに作成したサーバ配信ＯＳ１６のイメージファイルを試験対象となるサーバに配信する。
また、管理サーバ１０は、擬似故障注入タイミング制御部１８ｈを用いて、擬似故障を注入するタイミングを識別する。そして、管理サーバ１０は、擬似故障を注入するタイミングとなった場合には、擬似故障注入実行制御部１８ｉを用いて、故障を発生させるサーバのＯＳに擬似故障を注入するよう指示する。なお、管理サーバ１０は、試験対象となるサーバを複数の組に分割し、各組ごとに試験を並列して実行できると判別した場合には、各組ごとに故障を発生させるサーバのＯＳに対して、擬似故障を注入するよう指示する。
そして、管理サーバ１０は、擬似故障注入後、サーバ監視部１８ｄが収集した情報を用いて、各サーバが提供するサービスを識別する。そして、管理サーバ１０は、結果判定部１８ｊを用いて、以下の処理を実行する。すなわち、管理サーバ１０は、各サーバが提供するサービスに基づいて、試験対象となるフェールオーバが正常に実行されたか否かを判別し、判別結果をＨＤＤ１３に保存する。
次に、管理サーバ１０は、試験対象のサーバに対してフェールバックを実行するよう指示する。このような場合には、試験対象となるサーバはフェールバックを実行することとなる。その後、管理サーバ１０は、サーバ監視部１８ｄを用いて、各サーバの状態を収集し、試験対象となるサーバが正常にフェールバックを実行したか否かを判別する。そして、管理サーバ１０は、試験対象となるサーバが正常にフェールバックを実行したと判別した場合には、リスト３およびリスト４が示す新たな試験を実行する。
一方、管理サーバ１０は、試験対象となるサーバが正常にフェールバックを実行しなかったと判別した場合には、以下の処理を実行する。すなわち、管理サーバ１０は、サーバ電源制御部１８ｂを用いて、試験対象のサーバの電源を落とす。そして、管理サーバ１０は、試験対象のサーバの電源を再度投入し、サーバ配信ＯＳ１６のイメージファイルを送信する。つまり、管理サーバ１０は、正常にフェールバックできなかったサーバを再起動し、再度ネットワークブートさせる。その後、管理サーバ１０は、リスト３およびリスト４が示す新たな試験を実行する。
なお、管理サーバ１０は、再起動させたサーバのハードウェアが故障した場合には、試験によるサーバ内のハード故障の有無を確認し、結果をＨＤＤ１３に保存する。また、管理サーバ１０は、再起動させたサーバのハードウェアが故障した場合には、試験項目抽出部１８ｅ、試験可否判定部１８ｆ、試験順序決定部１８ｇを用いて、各試験で利用するサーバ及び試験順序を再決定し、全試験が完了するまで試験を実施する。
次に、管理サーバ１０が実行する処理の具体例について説明する。以下の説明では、利用者により、Ｓｅｒｖｅｒ＃１〜＃８の８つのサーバが指定されたものとする。また、以下の説明では、利用者により、フェールオーバの種別として、Ａｃｔｉｖｅ−ｐａｓｓｉｖｅ形式のフェールオーバと、Ａｃｔｉｖｅ−Ａｃｔｉｖｅ形式のフェールオーバと、Ｎ対１形式のフェールオーバとの試験が指定されたものとする。
また、利用者により、試験対象となるサーバが実行するサービスの種別として、ｔｅｌｎｅｔを用いたサービスとｈｔｔｐを用いたサービスとが指定されたものとする。また、利用者により、擬似故障の種別として、試験対象となるサーバが有するＣＰＵに注入する擬似故障と、ＦＴＰサービスを停止する擬似故障とが指定されたものとする。
このような場合には、管理サーバ１０は、構成情報収集部１９ａとハード診断部１９ｂとを有するサーバ配信ＯＳ１６のイメージファイルを生成する。そして、管理サーバ１０は、各サーバ２０〜２２の電源を投入し、生成したサーバ配信ＯＳ１６のイメージファイルを送信する。このような場合には、各サーバ２０〜２２は、取得したサーバ配信ＯＳ１６のイメージファイルをネットワークブートする。
すると、各サーバ２０〜２２は、自身のハードウェア構成と、各ハードウェアの診断結果とを管理サーバ１０へと送信する。この結果、管理サーバ１０は、図８に例示するように、各サーバのハードウェア構成と、各ハードウェアの診断結果とを取得する。図８は、実施例１に係る管理サーバが収集する情報の一例を示す図である。
なお、図８に示すＳｅｒｖｅｒ＃３〜Ｓｅｒｖｅｒ＃８は、図１において省略したサーバであり、サーバ２０〜２２と同様の機能を有するものとする。また、各Ｓｅｒｖｅｒ＃１〜＃８は、メモリとしてＤＩＭＭを有するものとする。また、図８中のＤＩＭＭとは、各Ｓｅｒｖｅｒ＃１〜＃８が有するメモリの容量を示し、ＬＡＮとは、各Ｓｅｒｖｅｒ＃１〜＃８が有するＬＡＮの帯域を示す。
図８に示す例では、管理サーバ１０は、Ｓｅｒｖｅｒ＃１〜＃５、＃７が１２８ギガバイトのＨＤＤを２つ有し、１つのＣＰＵを有し、２ギガバイトのＤＩＭＭを２つ有し、１Ｇｂｐｓ（Bit per second）の帯域を有するＬＡＮを２系統有する旨の情報を取得する。また、管理サーバ１０は、Ｓｅｒｖｅｒ＃６がＨＤＤを有さないＤＩＳＫレスのサーバであり、ＣＰＵ、ＤＩＭＭ、ＬＡＮの帯域に関しては、Ｓｅｒｖｅｒ＃１〜＃５、＃７と同様である旨の情報を取得する。また、管理サーバ１０は、Ｓｅｒｖｅｒ＃８が有するＬＡＮの帯域が１０Ｇｂｐｓを２系統有し、ＨＤＤ、ＣＰＵ、ＤＩＭＭについては、Ｓｅｒｖｅｒ＃１〜＃５、＃７と同様である旨の情報を取得する。
また、図８に示す例では、管理サーバ１０は、Ｓｅｒｖｅｒ＃７のＨＤＤが故障している旨の診断結果を取得し、Ｓｅｒｖｅｒ＃８のＤＩＭＭが故障している旨の診断結果を取得する。この結果、管理サーバ１０は、Ｓｅｒｖｅｒ＃８がＤＩＭＭ不良のため、試験対象のサーバとすることができないと判別し、利用者に通知する。
次に、管理サーバ１０は、図９に示すように、試験するフェールオーバの種別、各サーバが実行するサービス、エラーを注入するサーバと注入するエラーの種別とを網羅的に対応付けた表を生成する。
図９は、実施例１に係る管理サーバが実行する試験の一例を説明するための図である。なお、図９に示す表は、上述したリスト３およびリスト４に対応する表である。また、図９中の対象サーバ＃１〜＃３とは、試験対象となるサーバを示し、Ｓｅｒｖｅｒ＃１〜＃７が網羅的に適用されることとなる。
すなわち、管理サーバ１０は、図９に示すように、試験するフェールオーバの形式と、各対象サーバ＃１〜＃３が提供するサービスの種別と、エラーを注入するサーバと、注入するエラーの種別とを網羅的に対応付けた表を作成する。次に、管理サーバ１０は、各試験を効率よく実行するために、Ｓｅｒｖｅｒ＃１〜＃７を複数の組に分割し、分割した各組毎に並列して試験を実行するための試験の順序を示す表を作成する。
また、管理サーバ１０は、指定された試験内容、試験対象となるサーバ、各サーバに実行させるサービス、注入する擬似故障の種別とに基づいて、各試験を実行するために必要なハードウェアの条件を示す表を作成する。例えば、管理サーバ１０は、図１０に示す表を作成する。
図１０は、実施例１に係る管理サーバが生成する表の一例を説明するための図である。なお、図１０に示す各試験の番号は、図９に示す各試験の番号と対応する。また、図１０に示す必須ハードウェア＃１とは、試験を実行するために図９に示す対象サーバ＃１が要するハードウェアであり、必須ハードウェア＃２とは、試験を実行するために図９に示す対象サーバ＃２が要するハードウェアである。
また、必須ハードウェア＃３とは、試験を実行するための図９に示す対象サーバ＃３が要するハードウェアである。また、図１０中の各ＨＤＤの欄に記入された数値は、試験を実行するために必要なＨＤＤの空き容量であり、単位はギガバイトである。各ＣＰＵの欄に記入された数値は、試験を実行するために必要なＣＰＵの数である。また、図１０の各ＤＩＭＭの欄に記入された数値は、試験を実行するための必要なメモリ容量であり、単位はギガバイトである。また、図１０の各ＬＡＮの欄に記入された数値は、試験を実行するために必要なＬＡＮの帯域であり、単位はＧｂｐｓである。
すなわち、図１０に示す例では、管理サーバ１０は、各試験に対して、対象サーバ＃１に必要なＣＰＵが１つであり、メモリ容量が１ギガバイトであり、ＬＡＮの帯域が１Ｇｂｐｓである旨を示す表を作成する。また、管理サーバ１０は、各試験に対して、対象サーバ＃２に必要なＣＰＵが１つであり、メモリ容量が１ギガバイトであり、ＬＡＮの帯域が１Ｇｂｐｓである旨を示す表を作成する。
また、管理サーバ１０は、１番から６番までの試験に２つのサーバが必要であり、７番から１０番までの試験に３つのサーバが必要である旨を示す表を作成する。また、管理サーバ１０は、７番から１０番までの試験について、対象サーバ＃３に必要なＣＰＵが１つであり、メモリ容量が１ギガバイトであり、ＬＡＮの帯域が１Ｇｂｐｓである旨を示す表を作成する。
次に、管理サーバ１０は、図１０に示す表を満たし、かつ、試験対象のサーバの稼働率が最も高くなるように、組み合わせアルゴリズムを用いて、並列に実行する試験の順序を決定する。例えば、管理サーバ１０は、図１１に示すように、各Ｓｅｒｖｅｒ＃１〜＃７に実行させるテストを決定する。図１１は、実施例１に係る管理サーバが各サーバに実行させるテストの一例を説明するための図である。
図１１に示す例では、管理サーバ１０は、１回目の試験時に、Ｓｅｒｖｅｒ＃１〜＃３に対して、図９中の試験番号７で示す試験を実行させ、Ｓｅｒｖｅｒ＃４、＃５に対して、図９中の試験番号１で示す試験を実行する旨を示す表を作成する。また、管理サーバ１０は、１回目の試験時に、Ｓｅｒｖｅｒ＃６、＃７に対して、図９中の試験番号２で示す試験を実行する旨を示す表を作成する。
また、管理サーバ１０は、２回目の試験時に、Ｓｅｒｖｅｒ＃１〜＃３に対して、図９中の試験番号８で示す試験を実行させ、Ｓｅｒｖｅｒ＃４、＃５に対して、図９中の試験番号３で示す試験を実行する旨を示す表を作成する。また、管理サーバ１０は、２回目の試験時に、Ｓｅｒｖｅｒ＃６、＃７に対して、図９中の試験番号４で示す試験を実行する旨を示す表を作成する。
また、管理サーバ１０は、３回目の試験時に、Ｓｅｒｖｅｒ＃１〜＃３に対して、図９中の試験番号９で示す試験を実行させ、Ｓｅｒｖｅｒ＃４、＃５に対して、図９中の試験番号５で示す試験を実行する旨を示す表を作成する。また、管理サーバ１０は、２回目の試験時に、Ｓｅｒｖｅｒ＃６、＃７に対して、図９中の試験番号６で示す試験を実行する旨を示す表を作成する。
また、管理サーバ１０は、４回目の試験時に、Ｓｅｒｖｅｒ＃１〜＃３に対して、図９中の試験番号１０で示す試験を実行する旨を示す表を作成する。なお、管理サーバ１０は、４回目の試験時には、Ｓｅｒｖｅｒ＃４〜＃７に対しては、試験を行わない。
また、管理サーバ１０は、図９、図１１に示す表を作った場合には、以下の処理を実行する。すなわち、管理サーバ１０は、試験番号１、２、７の実行に必要な機能を有するサーバ配信ＯＳ１６を生成する。そして、管理サーバ１０は、生成したサーバ配信ＯＳ１６のイメージファイルを各Ｓｅｒｖｅｒ＃１〜＃７に送信する。
次に、管理サーバ１０は、Ｓｅｖｅｒ＃１、Ｓｅｒｖｅｒ＃４に対してＣＰＵの擬似エラーを注入し、Ｓｅｒｖｅｒ＃６に対して、ｔｅｌｎｅｔサービスを停止させる擬似故障を注入する。そして、管理サーバ１０は、各Ｓｅｒｖｅｒ＃１〜＃７が正常にフェールオーバを実行したか否かを判別し、判別結果を記憶する。
次に、管理サーバ１０は、各Ｓｅｒｖｅｒ＃１〜＃７にフェールバックを指示する。そして、管理サーバ１０は、各Ｓｅｒｖｅｒ＃１〜＃７が正常にフェールバックを実行したか否かを判別する。ここで、管理サーバ１０は、各Ｓｅｒｖｅｒ＃１〜＃７が実行するＯＳに欠損が生じる等して、正常にフェールバックを実行できなかった場合には、以下の処理を実行する。
まず、管理サーバ１０は、試験前の各Ｓｅｒｖｅｒ＃１〜＃７の状態と、フェールバック後の各Ｓｅｒｖｅｒ＃１〜＃７の状態との差異をエラーとして記録するとともに、利用者にエラーを通知する。また、管理サーバ１０は、故障していないサーバを識別し、故障していないサーバで残りの試験を継続実施できるか否かを判別する。
そして、管理サーバ１０は、継続実施できると判別した場合には、残りの試験を継続して実施する。一方、管理サーバ１０は、継続実施できないと判別した場合には、各Ｓｅｒｖｅｒ＃１〜＃７の電源を落とし、その後再度投入する。その後、管理サーバ１０は、各Ｓｅｒｖｅｒ＃１〜＃７に対して、残りの試験の実行に必要な機能を有するサーバ配信ＯＳ１６を生成し、生成したサーバ配信ＯＳ１６のイメージファイルを各Ｓｅｒｖｅｒ＃１〜＃７に送信する。
そして、管理サーバ１０は、各Ｓｅｖｅｒ＃１〜＃７に対する処理とフェールバックとを４回繰り返す。その後、管理サーバ１０は、試験結果を利用者に提示する。例えば、管理サーバ１０は、図１２に示すような試験結果を利用者に提示する。図１２は、実施例１に係る管理サーバが利用者に提示する試験結果の一例を説明するための図である。
図１２に示す例では、管理サーバ１０は、１０個の試験を実行し、１つの試験についてフェールオーバが正常に実行できなかった旨を表示する。また、管理サーバ１０は、フェールオーバが正常に実行できなかった試験が試験番号９番で示される試験であり、試験番号９番の内容と、エラーの発生要因を示す試験結果を表示する。なお、テスト結果の詳細として、テスト実施中の各Ｓｅｒｖｅｒ＃１〜＃７の情報やテスト時に管理サーバ１０の制御トレース情報、試験結果の詳細情報等も表示してもよい。また、管理サーバ１０は、試験結果を表示するだけではなく、例えば、ＨＤＤ１３に記憶させ、その後、利用者が読出して参照する方式を適用することとしてもよい。
このように、管理サーバ１０は、試験対象となるサーバが実行するサーバ配信ＯＳ１６を生成し、生成したサーバ配信ＯＳ１６のイメージファイルを生成する。そして、管理サーバ１０は、生成したイメージファイルを試験対象となるサーバに送信する。その後、管理サーバ１０は、イメージファイルを送信したサーバに擬似故障を注入し、フェールオーバを正常に実行するか試験する。
このため、管理サーバ１０は、フェールオーバ機能を連続して試験できる。すなわち、試験対象となるサーバは、ＨＤＤ等のＩＯ（Input Output）記録媒体上のデータが壊れる等でサーバのＯＳが起動できず、正常にフェールバックできない場合がある。しかし、管理サーバ１０は、試験対象となるサーバにサーバ配信ＯＳ１６のイメージファイルを送信し、ネットワークブートさせる。この結果、管理サーバ１０は、試験対象となるサーバが正常にフェールバックできない場合にも、ＯＳのインストールを不要とし、フェールオーバ機能を連続して試験できる。
また、フェールオーバを網羅的に試験する場合には、フェールオーバの種別、擬似故障の種別、提供するサービスの内容、擬似故障を注入するタイミング、サーバの数等の組み合わせについて網羅的に試験することとなる。しかし、フェールオーバの種別は技術の進歩とともに増加しており、また、擬似故障を注入する箇所も多数存在する。このため、治具等を用いて、人手でフェールオーバの試験を網羅的に実施することは困難である。
しかし、管理サーバ１０は、試験するフェールオーバの種別、注入する擬似故障の種別、提供するサービスの種類、試験対象とするサーバ等を網羅的に組み合わせ、自動的に試験を実行する。このため、管理サーバ１０は、容易にフェールオーバ試験を実行することができる。
また、治具等を用いて、所定のタイミングでフェールオーバの試験を網羅的に実施することは困難である。すなわち、擬似故障を注入するサーバの状態は、常に安定しているとは限らない。また、フェールオーバの試験は、運用を想定してあらゆるケースの試験を行うため、例えば、フェールオーバ中にさらなる擬似故障を注入する場合がある。しかし、フェールオーバは一瞬(数ミリ秒〜数秒程度)で終わってしまうので、フェールオーバ中に新たな擬似故障を人手で注入するのは困難である。
しかし、管理サーバ１０は、試験対象となるサーバの状態を示す情報を管理サーバ１０に送信する機能を有するサーバ配信ＯＳ１６を生成し、生成したサーバ配信ＯＳ１６のイメージファイルを試験対象となるサーバに送信する。そして、管理サーバ１０は、各サーバから収集した情報を用いて、試験対象となるサーバの状態を監視し、擬似故障を注入するタイミングであると判別した場合には、擬似故障を注入する。このため、管理サーバ１０は、任意のタイミングで擬似故障を注入することができる。
次に、図１３〜１５を用いて、管理サーバ１０が実行する処理の流れを説明する。図１３は、実施例１に係る管理サーバが実行する処理の流れを説明するための第１のフローチャートである。また、図１４は、実施例１に係る管理サーバが実行する処理の流れを説明するための第２のフローチャートである。また、図１５は、実施例１に係る管理サーバが実行する処理の流れを説明するための第３のフローチャートである。
例えば、図１３に示す例では、管理サーバ１０は、情報処理システム１の全てのサーバ２０〜２２に対して、構成情報収集部１９ａ、ハード診断部１９ｂ、構成情報通知部１９ｄを有するサーバ配信ＯＳ１６のイメージファイルを送信する（ステップＳ１０１）。そして、各サーバ２０〜２２から、診断結果とハードウェア情報とを受信する（ステップＳ１０２）。次に、管理サーバ１０は、試験対象に適さないサーバが存在するか否かを判別し（ステップＳ１０３）、存在すると判別した場合には（ステップＳ１０３肯定）、試験対象に適さないサーバをエラーとしてユーザに通知する（ステップＳ１０４）。なお、管理サーバ１０は、試験対象に適さないサーバが存在しないと判別した場合は（ステップＳ１０３否定）、ステップＳ１０４の処理をスキップする。
次に、管理サーバ１０は、利用者からの指示に基づいて、試験対象サーバと、提供させるサービスと、注入する擬似故障の種別と、試験するフェールオーバの種別とを選択する（ステップＳ１０５）。次に、管理サーバ１０は、選択した全ての種別のフェールオーバの試験が可能か否かを判別する（ステップＳ１０６）。そして、管理サーバ１０は、いずれかのフェールオーバの試験ができないと判別した場合には（ステップＳ１０６否定）、実行できない試験をユーザに通知する（ステップＳ１０７）。なお、管理サーバ１０は、選択した全ての種別のフェールオーバの試験が可能である場合は（ステップＳ１０６肯定）、ステップＳ１０７の処理をスキップする。
次に、管理サーバ１０は、実行可能な試験のうち、サーバを複数の組に分割して並列した試験を実行できるか否かを判定し、実行できる場合には、並列実行する試験の組合せと順序とを決定する（ステップＳ１０８）。その後、管理サーバ１０は、図１４に示す処理を実行し、処理を終了する。
続けて、図１４を用いて管理サーバ１０が実行する処理の流れを説明する。管理サーバ１０は、図１３に示すステップＳ１０８の処理を実行すると、試験対象となるサーバに必要な機能を有するサーバ配信ＯＳ１６のイメージファイルを新たに作成し、イメージファイルを試験対象となるサーバに送信する（ステップＳ２０１）。次に、管理サーバ１０は、試験対象となるサーバで動作する各サービス及び各サーバの状態を監視する（ステップＳ２０２）。
次に、管理サーバ１０は、故障を発生させるサーバに擬似故障を注入する（ステップＳ２０３）。そして、管理サーバ１０は、各サービスおよび各サーバの状態の監視結果に基づいて、フェールオーバが正常に動作したか否かを判別して、試験結果を記録する（ステップＳ２０４）。
次に、管理サーバ１０は、図１５に示す処理を実行した後に、未実施の試験が存在するか否かを判別する（ステップＳ２０５）。そして、管理サーバ１０は、未実施の試験が存在すると判別した場合には（ステップＳ２０５肯定）、次に実行する試験の対象となるサーバの構成と現試験の対象となるサーバの構成とが異なるか否かを判別する（ステップＳ２０６）。そして、管理サーバ１０は、サーバの構成が同じであると判別した場合には（ステップＳ２０６否定）、フェールバックが正常に実施されたか否かを判別する（ステップＳ２０７）。
また、管理サーバ１０は、フェールバックが正常に実施されなかったと判別した場合には（ステップＳ２０７否定）、試験対象のサーバの電源を落として再起動させ（ステップＳ２０８）、再度ステップＳ２０１の処理を実行する。また、管理サーバ１０は、フェールバックが正常に実施されたと判別した場合には、試験対象のサーバの電源を落とすことなく、再度ステップＳ２０１の処理を実行する。なお、管理サーバ１０は、サーバの構成が異なると判別した場合は（ステップＳ２０６肯定）、各サーバの電源を落として再起動させる（ステップＳ２０８）。また、管理サーバ１０は、未実施の試験が存在しないと判別した場合は（ステップＳ２０５否定）、処理を終了する。
続けて、図１５を用いて、管理サーバ１０が実行する処理の流れを説明する。例えば、管理サーバ１０は、図１４中ステップＳ２０４の処理を実行した場合には、試験対象のサーバにフェールバックを指示する（ステップＳ３０１）。そして、管理サーバ１０は、フェールバックが正常に実行されたか否かを判別し（ステップＳ３０２）、正常に実行されたと判別した場合には（ステップＳ３０２肯定）、以下の処理を実行する。
すなわち、管理サーバ１０は、試験対象のサーバからハードウェア情報と診断結果を取得する（ステップＳ３０３）。一方、管理サーバ１０は、フェールバックが正常に実行されなかったと判別した場合には（ステップＳ３０２否定）、試験対象のサーバの電源を落として再起動させる（ステップＳ３０４）。そして、管理サーバ１０は、試験対象のサーバに対してサーバ配信ＯＳ１６を送信し、ネットワークブートさせる（ステップＳ３０５）。
次に、管理サーバ１０は、各サーバの状態を識別し、試験対象のサーバに問題があるか否かを判別する（ステップＳ３０６）。詳細には、管理サーバ１０は、試験による故障等が発生しておらず、更にハードウェアや装置構成がテスト前と違っていないか否かを判別する。そして、管理サーバ１０は、試験対象のサーバに問題が有ると判別した場合には（ステップＳ３０６肯定）、試験結果を記録し（ステップＳ３０７）、試験対象のサーバに発生した問題が、試験の継続に影響するか否かを判別する（ステップＳ３０８）。
そして、管理サーバ１０は、試験対象のサーバに発生した問題が、試験の継続に影響すると判別した場合には（ステップＳ３０８肯定）、実施できない試験をユーザに通知する（ステップＳ３０９）。その後、管理サーバ１０は、実行していない試験の中で、試験対象となるサーバを複数の組に分割して実行可能かを判定し、実行可能である場合には、並列して実行する処理の内容と順序とを決定する（ステップＳ３１０）。
その後管理サーバ１０は、処理を終了する。また、管理サーバ１０は、試験対象のサーバに問題が無いと判別した場合には（ステップＳ３０８否定）、図１４に示すステップＳ２０５を実行する。また、管理サーバ１０は、サーバに問題がないと判別した場合は（ステップＳ３０６否定）、図１４に示すステップＳ２０５を実行する。
次に、図１６を用いて、管理サーバ１０が試験内容を示すリストを作成する処理の流れの一例について説明する。図１６は、実施例１に係る管理サーバが試験内容を示すリストを作成する処理の流れの一例を説明するためのフローチャートである。なお、管理サーバ１０は、図１３に示すステップＳ１０５にて、図１６に示す処理を実行し、試験対象となるサーバと、サービスと、注入する擬似故障の種別と、試験するフェールオーバの種別とを示すリストを生成する。
例えば、図１６に示す例では、管理サーバ１０は、利用者によって選択されたフェールオーバの種別から、試験対象となる運用系サーバの数と待機系サーバの数とを示すリスト１を生成する（ステップＳ４０１）。次に、管理サーバ１０は、リスト１の項目毎に、利用者によって選択された提供サービスを、各運用系サーバへ網羅的に割り振ったリスト２を生成する（ステップＳ４０２）。
次に、管理サーバ１０は、利用者によって選択されたハードウェアに注入する擬似故障の注入先を、リスト２の全項目に対して網羅的に割り振ったリスト３を生成する（ステップＳ４０３）。また、管理サーバ１０は、利用者によって選択されたサービスに注入する擬似故障の注入先を、リスト２の全項目に対して網羅的に割り振ったリスト４を生成し（ステップＳ４０４）、処理を終了する。
［管理サーバ１０の効果］
上述したように、管理サーバ１０は、試験対象となるサーバが実行するサーバ配信ＯＳ１６を生成し、生成したサーバ配信ＯＳ１６のイメージファイルを生成する。そして、管理サーバ１０は、生成したイメージファイルを試験対象となるサーバに送信する。また、管理サーバ１０は、イメージファイルを送信したサーバに擬似故障を注入し、フェールオーバを正常に実行するか試験する。また、管理サーバ１０は、試験を実行する度に、試験対象となるサーバのフェールバックを実行させ、フェールバック処理が正常に実行されたか否かを判別する。そして、管理サーバ１０は、フェールバック処理が正常に実行されなかった場合は、試験対象となるサーバの電源を落とし、その後、再投入することで、試験対象となるサーバを再起動させる。その後、管理サーバ１０は、サーバ配信ＯＳ１６のイメージファイルを再度送信し、フェールオーバ試験を繰り返し実行する。
このため、管理サーバ１０は、擬似故障の注入により、試験対象となるサーバのＯＳ等が破損し、フェールバックを正常に行えない場合にも、ＯＳの再インストールを行わずとも、新たな試験を実行できる。このため、管理サーバ１０は、フェールオーバ機能を連続して試験することができる。また、管理サーバ１０は、フェールバックが正常に実行されなかった場合にのみ、試験対象となるサーバにネットワークブートを実行させる。この結果、管理サーバ１０は、必要のないネットワークブートの実行を防止し、効率的に試験を実行することができる。
また、管理サーバ１０は、試験対象となるサーバのハードウェア情報を収集し、収集した情報に基づいて、試験対象となるサーバを選択する。そして、管理サーバ１０は、選択したサーバにサーバ配信ＯＳ１６のイメージファイルを送信する。このため、管理サーバ１０は、試験を行うことができないサーバを試験対象から除外することができるので、さらに効率的に試験を実行することができる。
また、管理サーバ１０は、利用者から注入する擬似故障の種別と、試験を行うフェールオーバの種別との指定を受け付ける。そして、管理サーバ１０は、試験対象となるサーバのハードウェア情報から、指定された種類の擬似故障を注入可能なサーバを含む複数のサーバであって、指定された種別のフェールオーバを実行可能な複数のサーバを選択する。このため、管理サーバ１０は、利用者から指定された内容の試験を、自動的に実行することができる。
また、管理サーバ１０は、試験対象として選択したサーバを複数の組に分割し、各組ごとにフェールオーバ試験を並列して実行できるか否かを判別する。そして、管理サーバ１０は、各組ごとにフェールオーバ試験を並列して実行できると判別した場合には、各組ごとに、擬似故障を注入して、フェールオーバが正常に実行させるか否かを試験する。このため、管理サーバ１０は、複数の試験を並列して実行するので、試験に要する時間を短縮することができる。
また、管理サーバ１０は、試験対象となるサーバのハードウェア情報に基づいて、試験対象となるサーバにフェールオーバを効率的に実行させる順序を識別する。そして、管理サーバ１０は、識別した順序でフェールオーバを実行するように、擬似故障を注入する。このため、管理サーバ１０は、多くの試験を実行しなければならない場合にも、効率的に試験を実行する結果、試験に要する時間を短縮することができる。
また、管理サーバ１０は、試験対象となる各サーバから、実行するサービスの内容や、ハードウェア情報を収集し、収集したサービスの内容やハードウェア情報から各サーバの状態を監視する。そして、管理サーバ１０は、監視した状態に基づいて、各サーバに擬似故障を注入するタイミングを識別し、識別したタイミングで擬似故障を注入する。このため、管理サーバ１０は、擬似故障を注入するタイミングが短く、試験を実行することが困難な場合にも、フェールオーバが正常に実行されるかを試験することができる。
また、管理サーバ１０は、サーバ配信ＯＳ１６のイメージファイルを試験対象となるサーバのメモリ、すなわち、ＲＡＭに送信する。すなわち、管理サーバ１０は、試験対象となるサーバにサーバ配信ＯＳ１６のイメージファイルをネットワークブートさせる。このため、管理サーバ１０は、試験対象となるサーバにＯＳを再インストールする処理を不要とするので、試験を連続して実行することができる。
これまで本発明の実施例について説明したが実施例は、上述した実施例以外にも様々な異なる形態にて実施されてよいものである。そこで、以下では実施例２として本発明に含まれる他の実施例を説明する。
（１）ネットワークブートについて
上述した管理サーバ１０は、ＰＸＥブートの手法を用いて、各サーバ２０〜２２にサーバ配信ＯＳ１６をネットワークブートさせた。しかし、実施例は、これに限定されるものではない。例えば、管理サーバ１０は、ＤＭＡ(Direct Memory Access）の技術を用いて、各サーバ２０〜２２のＤＩＭＭ２０Ｃ〜２２Ｃに直接サーバ配信ＯＳ１６のイメージファイルを格納してもよい。また、管理サーバ１０は、各サーバ２０〜２２にサーバ配信ＯＳ１６をネットワークブートさせるのであれば、任意の手法を用いることができる。
（２）試験内容について
上述した説明において、管理サーバ１０が試験対象としたフェールオーバの種別、提供させるサービス、注入する擬似故障の種別は、あくまで一例であり、管理サーバ１０は、任意のフェールオーバの種別を試験対象とすることができる。また、管理サーバ１０は、任意のサービスを試験対象となるサーバに提供させることができる。また、管理サーバ１０は、任意の種別の擬似故障を注入することができる。
例えば、フェールオーバの種別としては、上述した種別のほかに、他のサーバに対してランダムにサービスを割当てる手法でもよい。また、ハードウェアに対する擬似故障の例としては、共有ドライブ２３に対するアクセスの切断や、電源の切断、リブート、試験対象となるサーバの組であるクラスタ管理からの逸脱等でもよい。また、ソフトウェアに対する擬似故障の例としては、サーバに負荷を掛け、サービスの提供速度をスローダウンさせる等の手法であってもよい。また、サーバに提供させるサービスは、ＳＳＨ（Secure Shell）の提供等であってもよい。
なお、管理サーバ１０が擬似故障を注入するタイミングとしては、フェールオーバ実行時、フェールバック実行時、サービスに高付加がかかっているとき、ファンクション動作時、安定運用時等である。また、管理サーバ１０ａは、各仮想サーバ２０ｅ〜２２ｅがライブマイグレーションを実行している際に擬似故障を注入することとしてもよい。
（３）試験対象となるサーバについて
上述した管理サーバ１０は、情報処理システム１が有する物理的なサーバ２０〜２２がフェールオーバを正常に実行するか否かを試験した。しかし、実施例はこれに限定されるものではなく、例えば、管理サーバ１０は、仮想化されたサーバがフェールオーバを正常に実行するか否かを判別することとしてもよい。
図１７は、実施例２に係る管理サーバが仮想サーバのフェールオーバ試験を実行する処理の一例を説明するための図である。図１７に示す例では、管理サーバ１０ａは、ＣＰＵ１１ａ、メモリ１２ａを有する。なお、管理サーバ１０ａが有するＨＤＤ１３、管理サーバＯＳ１４、フェールオーバ診断システム１５、サーバ配信ＯＳ１６は、管理サーバ１０が有する各部１３〜１６と同様の機能を有するものとして、説明を省略する。
メモリ１２ａは、仮想ＬＡＮ１７ｂ、仮想化サーバ２０ｅ〜２２ｅ、仮想共有ドライブ２３ｅを有する。なお、各仮想化サーバ２０ｅ〜２２ｅは、実施例１に係るサーバ２０〜２２と同様の機能を有する仮想化されたサーバである。ＣＰＵ１１ａは、仮想ＬＡＮ１７ｂ、各仮想化サーバ２０ｅ〜２２ｅ、仮想共有ドライブ２３ｅを有する仮想化されたネットワークを実行する。
このような管理サーバ１０ａは、各仮想化サーバ２０ｅ〜２２ｅがフェールオーバを正常に実行するかを試験する場合には、各仮想化サーバ２０ｅ〜２２ｅに、サーバ配信ＯＳ１６のイメージファイルを送信し、ネットワークブートさせる。そして、管理サーバ１０ａは、各仮想化サーバ２０ｅ〜２２ｅが正常にフェールオーバを実行するかを試験する。このため、管理サーバ１０ａは、各仮想化サーバ２０ｅ〜２２ｅが正常にフェールバックできない場合にも、再度各仮想化サーバ２０ｅ〜２２ｅの生成やＯＳの再インストールを行わずとも、連続して試験を実行することができる。
（４）リストについて
上述した管理サーバ１０は、利用者から指定された試験の内容や、各サーバ２０〜２２の状態に応じて、リスト１〜４を生成した。しかし、実施例はこれに限定されるものではない。すなわち、管理サーバ１０は、利用者から指定された試験の内容や、各サーバ２０〜２２の状態に応じ、組み合わせアルゴリズムを用いて、リスト３、４を生成してもよい。また、管理サーバ１０は、各リスト１〜４を生成せずとも、利用者から指定された試験の内容や、各サーバ２０〜２２の状態に応じ、組み合わせアルゴリズムを用いて試験内容を判別し、判別した内容の試験を実行してもよい。
１ 情報処理システム
１０、１０ａ 管理サーバ
１１、１１ａ、２０ｂ、２１ｂ、２２ｂ、３０ｂ、３１ｂ ＣＰＵ
１２、１２ａ、２０ｃ、２１ｃ、２２ｃ、３０ｃ、３１ｃ メモリ
１３、２０ｄ、２１ｄ、２２ｄ、２３ｂ、２３ｃ、２３ｄ、３０ｄ、３１ｄ ＨＤＤ
１４ 管理サーバＯＳ
１５ フェールオーバ診断システム
１６ サーバ配信ＯＳ
１７、２０ａ、２１ａ、２２ａ、２３ａ、３０ａ、３１ａ ＬＡＮカード
１７ｂ 仮想ＬＡＮ
１８ マスタ制御部
１８ａ ＯＳイメージ作成部
１８ｂ サーバ電源制御部
１８ｃ ＯＳ配信部
１８ｄ サーバ監視部
１８ｅ 試験項目抽出部
１８ｆ 試験可否判定部
１８ｇ 試験順序決定分
１８ｈ 擬似故障注入タイミング制御部
１８ｉ 擬似故障注入実行制御部
１８ｊ 結果判定部
１９ サーバ制御部
１９ａ 構成情報収集部
１９ｂ ハード診断部
１９ｃ 擬似故障注入部
１９ｄ 構成情報通知部
２０〜２２ サーバ
２０ｅ〜２２ｅ 仮想サーバ
２３ 共有ドライブ
２３ｅ 仮想共有ドライブ
３０、３１ ユーザＰＣ

Claims (10)

  1. 複数のサーバがフェールオーバを正常に実行するかを試験する試験サーバにおいて、
    試験対象となるサーバに実行させるＯＳのイメージファイルを生成する生成部と、
    試験対象となるサーバに前記生成部が生成したイメージファイルを送信する送信部と、
    前記送信部が前記イメージファイルを送信したサーバのうち、故障させるサーバに擬似的な故障を注入して、試験対象となるサーバがフェールオーバを正常に実行するか否かを試験する試験部と、
    前記試験部が試験を実行する度に、試験対象となるサーバの状態をフェールオーバ前の状態に復帰させる復帰部と、
    前記復帰部が試験対象となるサーバの状態を正常に復帰させたか否かを判別する判別部と、
    試験対象となるサーバの状態を正常に復帰させなかったと前記判別部が判別した場合は、試験対象となるサーバの電源を落とし、その後再投入する電源制御部と
    を有し、
    前記電源制御部が電源を再投入したサーバに対して、前記送信部によるイメージファイルの送信と、前記試験部による試験とを繰り返し実行する
    ことを特徴とする試験サーバ。
  2. 各サーバが有する装置の内容を示す情報を収集する収集部と、
    前記収集部が収集した情報に基づいて、試験対象となるサーバを選択する選択部と
    を有し、
    前記送信部は、前記選択部が試験対象として選択したサーバに対して、前記イメージファイルを送信することを特徴とする請求項１に記載の試験サーバ。
  3. 利用者から、前記サーバに注入する擬似的な故障の種類と、前記サーバが実行するフェールオーバの種別との指定を受付ける受付部を有し、
    前記選択部は、前記収集部が収集した情報に基づいて、前記受付部が受付けた種類の擬似的な故障を注入可能なサーバを含む複数のサーバであって、前記受付部が受付けた種類のフェールオーバを実行可能な複数のサーバを選択することを特徴とする請求項２に記載の試験サーバ。
  4. 前記選択部が選択した複数のサーバを複数の組に分割し、前記受付部が受付けた種類のフェールオーバを各組ごとに並列して実行可能であるか否かを判定する判定部を有し、
    前記試験部は、前記受付部が受付けた種類のフェールオーバを各組ごとに並列して実行可能であると前記判定部が判定した場合には、各組ごとに、前記受付部が受付けた種類の擬似的な故障を注入して、フェールオーバを正常に実行するか否かを試験することを特徴とする請求項３に記載の試験サーバ。
  5. 前記試験部は、前記収集部が収集した各サーバが有する装置の内容を示す情報に基づいて、前記選択部が選択したサーバに前記受付部が受付けた全ての種類のフェールオーバを効率的に実行させる順序を識別し、当該識別した順序でフェールオーバを実行するように、前記故障させるサーバに対して擬似的な故障を注入することを特徴とする請求項４に記載の試験サーバ。
  6. 前記送信部がイメージファイルを送信したサーバの状態を監視する監視部と、
    前記監視部が監視した各サーバの状態に基づいて、前記サーバに対して擬似的な故障を注入するタイミングを識別する識別部と
    を有し、
    前記試験部は、前記識別部が識別したタイミングで、当該サーバに擬似的な故障を注入し、フェールオーバを正常に実行するか否かを試験することを特徴とする請求項１〜５のいずれか１つに記載の試験サーバ。
  7. 前記送信部は、前記生成部が生成したイメージファイルを前記サーバが有するＲＡＭに送信することを特徴とする請求項１〜５のいずれか１つに記載の試験サーバ。
  8. いずれかのサーバに故障が発生するとフェールオーバを実行する複数のサーバと、各サーバがフェールオーバを正常に実行するかを試験する試験サーバとを有する情報処理システムにおいて、
    前記試験サーバは、
    試験対象となるサーバに実行させるＯＳのイメージファイルを生成する生成部と、
    試験対象となるサーバに前記生成部が生成したイメージファイルを送信する送信部と、
    前記送信部が前記イメージファイルを送信したサーバのうち、故障させるサーバに擬似的な故障を注入して、試験対象となるサーバがフェールオーバを正常に実行するか否かを試験する試験部と
    前記試験部が試験を実行する度に、試験対象となるサーバの状態をフェールオーバ前の状態に復帰させる復帰部と、
    前記復帰部が試験対象となるサーバの状態を正常に復帰させたか否かを判別する判別部と、
    試験対象となるサーバの状態を正常に復帰させなかったと前記判別部が判別した場合は、試験対象となるサーバの電源を落とし、その後再投入する電源制御部と
    を有し、
    前記電源制御部が電源を再投入したサーバに対して、前記送信部によるイメージファイルの送信と、前記試験部による試験とを繰り返し実行し、
    前記サーバは、前記イメージファイルをネットワークブートすることを特徴とする情報処理システム。
  9. いずれかのサーバに故障が発生するとフェールオーバを実行する複数のサーバがフェールオーバを正常に実行するかを試験する試験サーバが実行する試験プログラムにおいて、
    試験対象となるサーバに実行させるＯＳのイメージファイルを生成し、
    生成したイメージファイルを試験対象となるサーバに送信し、
    前記イメージファイルを送信したサーバのうち、故障させるサーバに擬似的な故障を注入して、試験対象となるサーバがフェールオーバを正常に実行するか否かを試験し、
    試験を実行する度に、試験対象となるサーバの状態をフェールオーバ前の状態に復帰させ、
    試験対象となるサーバの状態を正常に復帰させたか否かを判別し、
    試験対象となるサーバの状態を正常に復帰させなかったと判別した場合には、試験対象となるサーバの電源を落とし、その後再投入し、
    電源を再投入したサーバに対して、前記イメージファイルの送信と、前記試験とを繰り返し実行する
    処理を前記試験サーバに実行させることを特徴とする試験プログラム。
  10. いずれかのサーバに故障が発生するとフェールオーバを実行する複数のサーバがフェールオーバを正常に実行するかを試験する試験サーバが実行する試験方法において、
    試験対象となるサーバに実行させるＯＳのイメージファイルを生成し、
    生成したイメージファイルを試験対象となるサーバに送信し、
    前記イメージファイルを送信したサーバのうち、故障させるサーバに擬似的な故障を注入して、試験対象となるサーバがフェールオーバを正常に実行するか否かを試験し、
    試験を実行する度に、試験対象となるサーバの状態をフェールオーバ前の状態に復帰させ、
    試験対象となるサーバの状態を正常に復帰させたか否かを判別し、
    試験対象となるサーバの状態を正常に復帰させなかったと判別した場合には、試験対象となるサーバの電源を落とし、その後再投入し、
    電源を再投入したサーバに対して、前記イメージファイルの送信と、前記試験とを繰り返し実行する
    処理を実行することを特徴とする試験方法。
JP2013550022A 2011-12-21 2011-12-21 試験サーバ、情報処理システム、試験プログラムおよび試験方法 Active JP5828348B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/079742 WO2013094048A1 (ja) 2011-12-21 2011-12-21 試験サーバ、情報処理システム、試験プログラムおよび試験方法

Publications (2)

Publication Number Publication Date
JPWO2013094048A1 JPWO2013094048A1 (ja) 2015-04-27
JP5828348B2 true JP5828348B2 (ja) 2015-12-02

Family

ID=48667972

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013550022A Active JP5828348B2 (ja) 2011-12-21 2011-12-21 試験サーバ、情報処理システム、試験プログラムおよび試験方法

Country Status (3)

Country Link
US (1) US9026858B2 (ja)
JP (1) JP5828348B2 (ja)
WO (1) WO2013094048A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102033489B1 (ko) * 2018-11-05 2019-10-17 주식회사 엘지씨엔에스 서버 클러스터 관리 방법 및 서버

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9483383B2 (en) * 2013-12-05 2016-11-01 International Business Machines Corporation Injecting faults at select execution points of distributed applications
WO2015107650A1 (ja) * 2014-01-16 2015-07-23 株式会社日立製作所 複数のサーバを有するサーバシステムの管理システム
CN109101416B (zh) * 2014-09-28 2022-01-14 华为技术有限公司 一种内核故障注入方法及电子设备
JP6377537B2 (ja) * 2015-01-15 2018-08-22 株式会社東芝 電力系統監視装置、電力系統監視方法及び電力系統監視プログラム
US10061664B2 (en) * 2015-01-15 2018-08-28 Cisco Technology, Inc. High availability and failover
US9690681B1 (en) * 2015-09-03 2017-06-27 Cadence Design Systems, Inc. Method and system for automatically generating executable system-level tests
US9424525B1 (en) 2015-11-18 2016-08-23 International Business Machines Corporation Forecasting future states of a multi-active cloud system
US20170171021A1 (en) * 2015-12-09 2017-06-15 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Automatic deployment of a new server in a peer-to-peer network of servers
US10007579B2 (en) * 2016-03-11 2018-06-26 Microsoft Technology Licensing, Llc Memory backup management in computing systems
JP6809006B2 (ja) * 2016-07-07 2021-01-06 富士通株式会社 情報処理装置の試験装置及び情報処理装置の試験方法
JP6812787B2 (ja) * 2016-12-27 2021-01-13 富士通株式会社 情報処理装置、フェールオーバ時間測定方法及びフェールオーバ時間測定プログラム
US11087042B1 (en) * 2017-06-30 2021-08-10 Wells Fargo Bank, N.A. Generation of a simulation plan and performance of a simulation based on the plan
JP6897473B2 (ja) * 2017-10-06 2021-06-30 富士通株式会社 テストプログラム、テスト方法、およびテスト装置
KR101961861B1 (ko) * 2017-10-17 2019-03-25 (주)유미테크 서버 검증 및 관리 시스템
CN110471799B (zh) * 2018-05-11 2023-06-06 佛山市顺德区顺达电脑厂有限公司 服务器测试方法
CN109634792B (zh) * 2018-12-06 2023-10-03 中电太极(集团)有限公司 一种基于云计算的服务器硬件测试平台系统
US11023341B2 (en) * 2019-02-15 2021-06-01 International Business Machines Corporation Injection of simulated hardware failure(s) in a file system for establishing file system tolerance-to-storage-failure(s)
CN113300913B (zh) * 2021-06-21 2023-01-06 北京飞讯数码科技有限公司 一种设备测试方法、装置、测试设备及存储介质
US12009990B1 (en) * 2022-03-31 2024-06-11 Amazon Technologies, Inc. Hardware-based fault injection service
CN116107913B (zh) * 2023-04-06 2023-11-14 阿里云计算有限公司 单节点服务器的测试控制方法、装置及系统
CN117472696B (zh) * 2023-12-26 2024-03-22 苏州元脑智能科技有限公司 转接卡装配位置检测方法、装置、设备、介质及服务器

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5621253A (en) * 1979-07-28 1981-02-27 Fujitsu Ltd Virtual failure generating system
JPH03253945A (ja) * 1990-03-05 1991-11-13 Fujitsu Ltd データ処理システムの異常回復処理機能確認方式
JPH07262101A (ja) 1994-03-17 1995-10-13 Hitachi Ltd 光チャネル制御装置の診断方法
JP2000057108A (ja) * 1998-08-12 2000-02-25 Fujitsu Ltd 二重化コンピュ−タシステムの切替試験方法ならびにそのための監視装置およびコンピュ−タ読み取り可能な記録媒体
US6484276B1 (en) * 1999-10-25 2002-11-19 Lucent Technologies Inc. Method and apparatus for providing extensible object-oriented fault injection
US7370101B1 (en) * 2003-12-19 2008-05-06 Sun Microsystems, Inc. Automated testing of cluster data services
JP4923990B2 (ja) 2006-12-04 2012-04-25 株式会社日立製作所 フェイルオーバ方法、およびその計算機システム。

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102033489B1 (ko) * 2018-11-05 2019-10-17 주식회사 엘지씨엔에스 서버 클러스터 관리 방법 및 서버

Also Published As

Publication number Publication date
WO2013094048A1 (ja) 2013-06-27
US9026858B2 (en) 2015-05-05
US20140298082A1 (en) 2014-10-02
JPWO2013094048A1 (ja) 2015-04-27

Similar Documents

Publication Publication Date Title
JP5828348B2 (ja) 試験サーバ、情報処理システム、試験プログラムおよび試験方法
US9489274B2 (en) System and method for performing efficient failover and virtual machine (VM) migration in virtual desktop infrastructure (VDI)
US9912535B2 (en) System and method of performing high availability configuration and validation of virtual desktop infrastructure (VDI)
US7779297B2 (en) Fail-over method, computer system, management server, and backup server setting method
US8910172B2 (en) Application resource switchover systems and methods
US8135985B2 (en) High availability support for virtual machines
JP5851503B2 (ja) 高可用性仮想機械環境におけるアプリケーションの高可用性の提供
US7213246B1 (en) Failing over a virtual machine
US7930371B2 (en) Deployment method and system
US7953830B2 (en) Automatic network reconfiguration upon changes in DHCP IP addresses
US9092395B2 (en) Provide an appliance like test vehicle for IT disaster recovery
US9304849B2 (en) Implementing enhanced error handling of a shared adapter in a virtualized system
US20150277856A1 (en) Entropy Generation for a Distributed Computing System
US8219851B2 (en) System RAS protection for UMA style memory
US6571360B1 (en) Cage for dynamic attach testing of I/O boards
JP2005500622A (ja) データ転送ルーティングメカニズムを用いるコンピュータシステムパーティショニング
JP2009140194A (ja) 障害回復環境の設定方法
US8990608B1 (en) Failover of applications between isolated user space instances on a single instance of an operating system
JP2007133544A (ja) 障害情報解析方法及びその実施装置
US8015432B1 (en) Method and apparatus for providing computer failover to a virtualized environment
CN114600088A (zh) 使用基板管理控制器的服务器状态监测系统和方法
US20030093510A1 (en) Method and apparatus for enumeration of a multi-node computer system
US20120047395A1 (en) Control method for information processing system, information processing system, and program
JP5716830B2 (ja) 情報処理装置及び方法、プログラム
US7930372B2 (en) Staged integration of distributed system and publishing of remote services

Legal Events

Date Code Title Description
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: 20150924

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20151007

R150 Certificate of patent or registration of utility model

Ref document number: 5828348

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150