(57)【要約】【課題】サーバ等の処理装置に障害が発生した場合の復旧時間の長期化をより確実に抑えられるようにする技術を提供する。【解決手段】管理サーバは、障害が発生した運用サーバの電源をオフさせ（Ｓ１１）、その運用サーバに割り当てられた複数の予備サーバの電源をオンさせる（Ｓ１２）。その後、マネージメントブレードを介して、電源のオンを指示した予備サーバのＢＩＯＳの起動完了を監視する（Ｓ１３、Ｓ１４）。マネージメントブレード３は、複数の予備サーバに電源のオンを指示（Ｓ２２）した後、予備サーバのＢＩＯＳの起動完了を監視することにより（Ｓ２３、Ｓ２４）、最速でＢＩＯＳを起動完了した予備サーバを管理サーバに通知し（Ｓ２５）、その予備サーバにはＯＳの起動を指示する（Ｓ２６）。他の予備サーバには電源のオフを指示する（Ｓ２７）。【選択図】図４
2013164762.tif 000002
【特許請求の範囲】
【請求項１】
第１の処理装置、及び該第１の処理装置の予備とする第２の処理装置を備えた処理システムにおいて、
前記第１の処理装置に発生する障害を検出する監視手段と、
前記第１の処理装置に発生した障害を前記監視手段が検出した場合に、複数の第２の処理装置を起動させる起動手段と、
前記起動手段により起動させる前記第２の処理装置のなかから１台の第２の処理装置を選択し、該選択した第２の処理装置を前記障害が発生した前記第１の処理装置の代替とする選択手段と、
を具備することを特徴とする処理システム。
【請求項２】
前記選択手段は、前記起動手段により起動させる複数の第２の処理装置のなかから、ＢＩＯＳ（Basic Input/Output System）の起動完了が最も早い第２の処理装置を選択する、
ことを特徴とする請求項１に記載の処理システム。
【請求項３】
コンピュータの制御により、処理装置に障害が発生した場合に、予備の処理装置を用いて復旧するための復旧方法において、
前記コンピュータに、
前記処理装置に障害が発生した場合に、該処理装置の代替候補となる予備の処理装置を複数、起動させ、
前記複数の予備の処理装置のなかで起動を完了した予備の処理装置のなかから、前記処理装置と代替させる予備の処理装置を選択させる、
ことを特徴とする復旧方法。
【請求項４】
コンピュータに、
複数の処理装置を起動させる機能と、
前記起動させる機能により起動させた前記複数の処理装置のなかから１台の処理装置を選択し、該選択した処理装置以外の処理装置を終了させる機能と、
を実現させるためのプログラム。
【請求項５】
処理装置に、
ＢＩＯＳ（Basic Input/Output System）の起動が完了した場合に、外部装置からの指示を入力するための機能と、
前記入力するための機能により入力した前記外部装置からの指示に従って、オペレーティングシステムの起動、及び電源のオフのうちの何れかを行う機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、運用（動作）中の処理装置に発生する障害に対応するための技術に関する。
【背景技術】
【０００２】
近年、ネットワークの普及により、ネットワークに接続されたコンピュータであるサーバは、サービスの提供に広く用いられている。そのようなサーバでは、ネットワークを介して多くの人がタイムリにサービスを利用できるようにすることが要求される。このため、サーバには、サービスを提供できない時間（サービス停止時間）がより短くなるように、高い信頼性が求められている。
【０００３】
高い信頼性を有していても、障害の発生を完全に回避させることはできない。このことから、従来、予備のサーバを用意し、障害が発生したサーバの代替として予備のサーバ（以降「予備サーバ」）を用いることにより、サーバに発生した障害の復旧が行われている。そのような予備サーバを用いる復旧方法では、障害が発生したサーバを取り換えるような復旧方法と比較して、障害の発生によるサービス停止時間を抑えることができる。予備サーバに代替させるサーバは以降「運用サーバ」と表記する。
【０００４】
最近では、多くのサーバを同じ室内に配置することが広く行われるようになっている。それにより、予備サーバは、消費電力を抑えるために、通常は電源がオフの待機状態となっていることが多い。そのような予備サーバは、代替させる運用サーバが発生した場合に起動、つまり電源がオンされる。
【０００５】
従来の復旧方法では、管理用のコンピュータ（以降「管理サーバ」）により、運用サーバに障害が発生した場合に、登録されている予備サーバのなかの１台を選択させ起動させるようになっていた。それにより、この従来の復旧方法が適用されるサーバシステム（処理システム）は、１台以上の運用サーバ、１台以上の予備サーバ、及び管理サーバを備えた構成となっていた。
【０００６】
正常に動作することを確認した予備サーバを管理サーバに登録させていても、管理サーバに選択された予備サーバが実際に正常に動作するとは限らない。これは、障害が既に発生しているか、或いは障害が発生する予備サーバを完全には除外できないからである。
【０００７】
選択された予備サーバが正常に動作（起動）しない場合、管理サーバは、新たに予備サーバを選択し、選択した予備サーバを再度、起動させなければならない。そのような予備サーバの起動のリトライを行う場合、障害の発生が判明してから復旧するまでの時間（以降「復旧時間」）は非常に長くなる。障害が発生した運用サーバでのみサービスを提供していた場合、長い復旧時間はそのままサービス停止時間となる。同じサービスを提供する複数の運用サーバのうちの一つに障害が発生した場合、復旧時間内にサービスの質が低下する可能性がある。このようなことから、復旧時間の長期化はより確実に回避すべきと云える。これは、サーバ以外の用途に用いる処理装置でも云えることである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】ＷＯ２００７／０９４０４１
【特許文献２】特開２０１０−３３５０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本発明の１側面は、サーバ等の処理装置に障害が発生した場合の復旧時間の長期化をより確実に抑えられるようにする技術を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明を適用した１システムでは、第１の処理装置、及び該第１の処理装置の予備とする第２の処理装置を備えていることを前提とし、第１の処理装置に発生する障害を検出する監視手段と、第１の処理装置に発生した障害を監視手段が検出した場合に、複数の第２の処理装置を起動させる起動手段と、起動手段により起動させる第２の処理装置のなかから１台の第２の処理装置を選択し、該選択した第２の処理装置を障害が発生した第１の処理装置の代替とする選択手段と、を具備する。
【発明の効果】
【００１１】
本発明を適用した場合には、サーバ等の処理装置に障害が発生した場合の復旧時間の長期化をより確実に抑えることができる。
【図面の簡単な説明】
【００１２】
【図１】本実施形態による処理システムの構成例を説明する図である。
【図２】本実施形態による処理システムであるブレードサーバのより詳細な構成を説明する図である。
【図３】保守データの構成例を説明する図である。
【図４】障害が発生した場合に、管理サーバ、マネージメントブレード、障害が発生した運用サーバ、及びその運用サーバに割り当てられた複数の予備サーバによってそれぞれ実行される処理を表すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による処理システムの構成例を説明する図である。本実施形態では、処理システム１は、それぞれがサーバとして機能可能なサーバブレード２（２−１〜２−１０）を複数、搭載したブレードサーバとして実現されている。このブレードサーバ１は、ＬＡＮ（Local Area Network）等のネットワーク１０と接続され、複数のサーバブレード２の他に、マネージメントブレード３、及び複数の電源装置４（４−１〜４−３）を備えている。ネットワーク１０は、特には図示していないが、例えば作業員が使用する端末装置（コンソール）と接続されている。
【００１４】
図１には、１０個のサーバブレード２−１〜２−１０を表しているが、サーバブレード２の数は１０個に限定されない。図１に表すサーバブレードに付した「２−１」等の符号については、説明上、便宜的に、ハイフンに続く数字はサーバブレード２に識別情報（ＩＤ：IDentifier）として割り当てられた番号、及び、サーバブレード２が挿入されたスロットの番号を表していると想定する。サーバブレード２を特定すべきでない場合、或いは任意のサーバブレード２が対応するような場合、符号としては「２」を用いる。
【００１５】
図２は、本実施形態による処理システムであるブレードサーバのより詳細な構成を説明する図である。
図２に表すように、各電源装置４とマネージメントブレード３との間はバス５によって接続され、各サーバブレード２とマネージメントブレード３との間はバス６及びＬＡＮ７によって接続されている。ＬＡＮ７は、図１に表すＬＡＮ１０と同じものであっても良い。
【００１６】
マネージメントブレード３は、ブレードサーバ１全体を管理する。図２に表すように、マネージメントブレード３は、ＣＰＵ（Central Processing Unit））３１、メモリ３２、及びインターフェース（図中「Ｉ／Ｆ」と表記）３３を備えている。この構成は１例であり、マネージメントブレード３の構成として限定されるものではない。
【００１７】
インターフェース３３は、バス５、バス６及びＬＡＮ７を介した通信を可能にする。また、特には図示していないが、図１に表すネットワーク１０を介した通信もこのインターフェース３３によって実現される。メモリ３２は、不揮発性の記憶装置であり、ブレードサーバ１の管理を行うためのプログラム（以降「管理プログラム」と表記）が格納されている。ＣＰＵ３１は、メモリ３２に格納された管理プログラム３２ａを不図示の内部メモリに読み出して実行することにより、ブレードサーバ１全体の管理を行う。
【００１８】
各電源装置４は、自電源装置４の稼動／停止を行う制御装置４１を備え、バス５は制御装置４１と接続されている。各電源装置４の制御装置４１は、バス５を介したマネージメントブレード３の指示に従って、稼動、或いは停止を行う。
【００１９】
各サーバブレード２は、ＣＰＵ２１、ＦＷＨ（FirmWare Hub）２２、メモリ２３、インターフェース（図２中「Ｉ／Ｆ」と表記）２４、ハードディスク装置（図２中「ＨＤ」（Hard Disk）と表記」２５、コントローラ２６、及び制御装置２７を備えている。制御装置２７はバス６と接続され、インターフェース２４はＬＡＮ７と接続されている。このような構成は１例であり、サーバブレード２の構成として限定されるものではない。また、管理サーバ２とそれ以外とで、異なる構成であっても良い。
【００２０】
ＦＷＨ２２は、ＢＩＯＳ（Basic Input/Output System）２２ａを格納したメモリである。このＢＩＯＳ２２ａは、ＣＰＵ２１によってメモリ２３に読み出され実行される。ハードディスク装置２５には、ＯＳ（Operating System）、及び各種アプリケーション・プログラム（以降「アプリ」と略記）が格納されており、ＣＰＵ２１は、ＢＩＯＳ２２ａの起動が完了した後、コントローラ２６を介してハードディスク装置２５からＯＳを読み出して実行する。インターフェース２４を介した通信は、ＢＩＯＳ２２ａの起動完了によって可能となる。
【００２１】
制御装置２７は、自サーバブレード２の稼動／停止、つまり電源のオン／オフを制御する。それにより、各サーバブレード２は、マネージメントブレード３の指示に従った制御装置２７の制御により、電源のオン／オフを行うことができる。制御装置２７は、電源がオンされていた時間を計時し、計時した時間を稼動時間としてマネージメントブレード３に通知する。
【００２２】
上記のような構成のブレードサーバ１では、サーバブレード２のうちの１つが、他のサーバブレード２の動作状態を監視し、障害の発生に対処するサーバ（以降「管理サーバ」）として機能する。１つ以上のサーバブレード２は、ネットワーク１０を介して接続された端末装置のユーザへのサービスの提供に用いられ、残りは予備として用いられる。それにより、ブレードサーバ１は、サービス提供のために動作中のサーバブレード２に障害が発生した場合、予備のサーバブレード２を起動させ、起動させた予備のサーバブレード２を、障害が発生したサーバブレード２の代替とすることで、障害の復旧を行う。
【００２３】
以降、説明上、便宜的に、サービス提供のために動作中のサーバブレード２は「運用サーバ」、予備のサーバブレード２は「予備サーバ」とそれぞれ表記する。そのような区別をする必要がない場合、或いはそのような区別をすべきでない場合、サーバブレード２はそのまま表記する。そのようにサーバブレード２を管理サーバ２、運用サーバ２、及び予備サーバ２に分け、ブレードサーバ１の動作について詳細に説明する。ここでは、障害に係わる動作に着目する形で説明を行う。
【００２４】
ネットワーク１０には、管理者が操作する端末装置（コンソール）が接続されており、マネージメントブレード３は、その端末装置からの指示により、或いは設定により、管理サーバ２、更には運用サーバ２の電源を順次オンにさせる。これは、マネージメントブレード３のＣＰＵ３１が、インターフェース３３及びバス６を介して、管理サーバ２、及び運用サーバ２の各制御装置２７に電源のオンを指示することで行われる。
【００２５】
電源のオンが指示されたサーバブレード２は、制御装置２７の制御により、ＣＰＵ２１が動作を開始する。ＣＰＵ２１は、ＦＷＨ２２のＢＩＯＳ２２ａをメモリ２３に読み出して起動する。ＣＰＵ２１は、ＢＩＯＳ２２ａの起動を完了する間に、自サーバブレード２のＩＰアドレスの設定、設定したＩＰアドレスの通知、その通知を受信したサーバブレード２が返信するＩＰ（Internet Protocol）アドレスの登録、等を行う。そのようにして、ＢＩＯＳ２２ａの起動が完了した後のサーバブレード２は、ＬＡＮ７を介した通信が可能な状態となっている。
【００２６】
管理サーバ２として動作するサーバブレード２のＣＰＵ２１は、ＢＩＯＳ２２ａの起動を完了した後、コントローラ２６を介してハードディスク装置２５に格納されているＯＳ（Operating System）を読み出し、ＯＳの起動を行う。ＯＳの起動完了後、ＣＰＵ２１は、管理サーバ２として動作するためのアプリ（以降「管理アプリ」）を起動させる。それにより、管理サーバ２は、サーバブレード２のＣＰＵ２１が、この管理アプリを実行することで実現される。
【００２７】
図２では、２５ａは管理アプリを表している。その図２に合わせて、以降サーバブレード２−１が管理サーバとして動作すると想定する。
マネージメントブレード３は、ブレードサーバ１に搭載された各サーバブレード２に係わるデータ（以降「管理データ」）３２ｂをメモリ３２に格納している。管理アプリ２５ａの実行を開始したＣＰＵ２１は、マネージメントブレード３から、その管理データ３２ｂを取得し、例えばハードディスク装置２５に、障害の発生に対応するためのデータ（以降「保守データ」２５ｂとして格納する。
【００２８】
図３は、保守データの構成例を説明する図である。
図３に表すように、保守データは、管理サーバ２−１及びマネージメントブレード３を含むブレード毎に、ＩＤ、サーバ種類、予備サーバ、搭載場所、運用状態、ＩＰアドレス、スペック、起動時間、故障回数、及び稼働時間、の各種データを備えている。管理データ３２ｂは、図３において、管理サーバ２−１及びマネージメントブレード３を除く部分に相当する。以降、サーバブレード毎の保守データは「個別保守データ」と表記する。
【００２９】
ＩＤは、サーバブレード２に識別情報として割り当てられた番号である。サーバ種類は、ブレードの種類、或いは運用上、区別するための種類を表す情報である。図３に表記の「マネージメントブレード」はブレードの種類を表し、「管理サーバ」「運用サーバ」及び「予備サーバ」は、サーバブレード２の運用上、区別するための種類を表している。予備サーバは、障害の発生により代替とする予備サーバ２の割り当てを表す。図３中に「５」「６」「７」と表記したように、本実施形態では、予備サーバを表すデータとして、設定された予備サーバ２のＩＤを用いている。搭載場所はサーバブレード２が挿入されたスロットの番号である。運用状態は、サーバブレード２の現在の状態を表すデータである。「正常」は、正常に動作している状態を表し、「障害」は発生した障害が復旧していない状態を表している。「待機」は電源がオフの状態を表し、「起動中」は電源のオンにより起動を行っている状態を表している。
【００３０】
ＩＰアドレスは、ＬＡＮ７を介して通信を行うためのアドレスである。スペックはハードウェアに係わる構成データである。起動時間は、前回の起動に要した時間である。故障回数は障害の発生回数である。稼働時間は、電源がオンになっていた累算時間である。
【００３１】
上記個別保守データを構成する各データは全て、マネージメントブレード３によって更新が可能である。各サーバブレード２の制御装置２７は、自身が障害を検出するか、或いはＣＰＵ２１からの障害通知により、障害の発生をマネージメントブレード３に通知する。それにより、マネージメントブレード３のＣＰＵ３１は、サーバブレード２毎に、故障回数を計数し、運用状態（データ）を変更することにより、管理データ３２ｂを更新する。また、マネージメントブレード３のＣＰＵ３１は、サーバブレード２毎に、例えば電源のオンを指示してから電源のオフを指示するまでの時間を計時し、計時した時間をそれまでの稼働時間に加えることにより、稼働時間を随時、更新する。起動時間は、電源のオンを指示する毎に、その指示をしてから起動が完了するまでの時間を計時することで更新される。
【００３２】
管理サーバ２−１は、上記のような構成の保守データ２５ｂを参照し、運用サーバ２に発生した障害に対応する。
管理サーバ２−１は、例えばＬＡＮ７を介した通信により、サーバブレード２に発生した障害の検出を行う。管理サーバ２−１のＣＰＵ２１は、サーバブレード２のＣＰＵ２１から障害が通知されるか、或いはサーバブレード２のＣＰＵ２１との通信が行えなくなった場合に、障害が検出されたと見なし、その障害を復旧させるための制御を実行する。このとき管理サーバ２−１のＣＰＵ２１は、障害が検出されたサーバブレード２（運用サーバ２、或いは予備サーバ２）の運用状態を正常から障害に変更し、故障回数をインクリメントする。
【００３３】
管理サーバ２−１は、マネージメントブレード３に指示して、障害が検出された運用サーバ２の電源をオフさせる。また、管理サーバ２−１は、保守データ２５ｂを参照して、障害が検出された運用データ２に割り当てられている予備サーバ２を特定し、特定した予備サーバ２の電源のオンをマネージメントブレード３に指示する。
【００３４】
図３に表すように、各運用サーバ２には、複数の予備サーバ２が割り当てられている。本実施形態では、運用サーバ２に割り当てられた複数の予備サーバ２は、その運用サーバ２での障害の発生によって全て起動の対象となる。図３において、ＩＤが６、７の各予備サーバ２の運用状態が「起動中」となっているのは、ＩＤが４の運用サーバ２で障害が検出されたためである。
【００３５】
予備サーバ２は、直前に電源をオンさせた状況では正常に動作することが確認されているものである。そのような予備サーバ２が複数、正常に動作しない可能性は非常に低い。言い換えれば、障害の発生によって起動させる複数の予備サーバ２のうちの少なくとも１つは正常に動作する可能性は非常に高い。これは、起動させた予備サーバ２が正常に動作しないことによって別の予備サーバ２を起動させるリトライを行う可能性が非常に低いことを意味する。このことから、本実施形態では、１台の運用サーバ２の障害により、複数の予備サーバ２を起動させるようにして、リトライの発生による復旧時間の長期化をより確実に回避させるようにしている。
【００３６】
各予備サーバ２の性能は、ＣＰＵ２１、メモリ２３等のハードウェア資源の製造上の不均質、或いは劣化等により、スペックから適切に評価することは困難である。これは、同時に起動を開始させた複数の予備サーバ２のなかで実際に起動を最も早く完了させる予備サーバ２を必ずしも正確に予想できないことを意味する。予備サーバ２を運用サーバ２の代替とさせることで障害から復旧させる復旧方法では、復旧時間は、代替とする予備サーバ２の起動時間に大きく依存する。このことから、本実施形態では、復旧時間をより短くする意味からも、複数の予備サーバ２を起動させるようにしている。つまり、複数の予備サーバ２を起動させることにより、リトライの発生による復旧時間の長期化をより確実に回避しつつ、その復旧時間（起動時間）の最短化を行っている。
【００３７】
復旧時間をより短くするために、本実施形態では、予備サーバ２が複数、起動を完了した場合、起動完了が最も短い予備サーバ２を代替とする予備サーバ２として選択し、他の予備サーバ２は電源をオフさせる。そのようにして、必要のない予備サーバ２の電源をオンさせ続けることによる消費電力を抑えるようにしている。
【００３８】
代替とする予備サーバ２の選択は、ＢＩＯＳ２２ａの起動完了に着目して行われる。これは、ＢＩＯＳ２２ａの起動時間と、その後のＯＳの起動時間（或いはＢＩＯＳ２２ａの起動を開始してからサービスを提供可能になるのに要する時間）との間の関係はサーバブレード２によって大きく変化しないのが普通だからである。ＢＩＯＳ２２ａの起動時間が最短の予備サーバ２が、復旧時間が最短となる予備サーバ２となる可能性が最も高いからである。
【００３９】
ＢＩＯＳ２２ａの起動時間により予備サーバ２を選択することに合わせ、本実施形態では、ＢＩＯＳ２２ａの起動完了後のＯＳの起動は、外部（ここではマネージメントブレード３）からの指示に従って行わせるようにしている。そのために、ＢＩＯＳ２２ａには、起動完了後、外部からの指示を待つ待機状態に移行し、その指示に従って、ＯＳを起動させるか、或いはＢＩＯＳ２２ａを終了させる機能を搭載させている。そのような機能を搭載することにより、選択されない予備サーバ２の消費電力はより抑えることができる。なお、その機能は、ＢＩＯＳ２２ａの起動後に実行させる別のプログラム上に搭載させても良い。
【００４０】
代替とする予備サーバ２の選択は、復旧時間に着目する他に、信頼性、或いは各運用サーバに要求される性能の違い等に着目して行うことが考えられる。例えば代替させた予備サーバ２により長く障害が発生しないことを重視するならば、予備サーバ２としては、稼働時間がより短い、或いは単位時間当たりの故障回数がより少ないサーバブレード２を選択するのが望ましい。サービスの利用者数が多い程、サービスの提供に要する負荷が重い程、そのサービスを提供する運用サーバ２にはより高い性能が求められる傾向がある。このようなことから、代替とする予備サーバ２の選択方法は、重要視する点によって変更する必要がある。
【００４１】
図３では、ＩＤが３の運用サーバ２には、ＩＤが５、６のサーバブレード２が予備サーバ２として割り当てられ、ＩＤが４の運用サーバ２には、ＩＤが６、７のサーバブレード２が予備サーバ２として割り当てられている。これらの割り当て設定は、例えばネットワーク１０と接続されている端末装置（不図示）を用いたマネージメントブレード３の管理データ３２ｂの変更により行うことができる。しかし、障害の発生した運用サーバ２の代替に予備サーバ２を使用することにより、その予備サーバ２に代替用の予備サーバ２を割り当てなければならない。また、図３に表すような割り当て設定では、ＩＤが３の運用サーバ２に障害が発生し、代替とする予備サーバ２としてＩＤが６の予備サーバ２を選択した場合、ＩＤが４の運用サーバ２に割り当てられている予備サーバ２はＩＤが７の予備サーバ２の一つのみとなる。このようなことから、管理サーバ２−１は、障害が発生した場合、一つ以上の運用中のサーバブレード２に対する予備サーバ２の割り当てを変更する形での保守データ２５ｂの更新を行う。
【００４２】
図４は、障害が発生した場合に、管理サーバ、マネージメントブレード、障害が発生した運用サーバ、及びその運用サーバに割り当てられた複数の予備サーバによってそれぞれ実行される処理を表すフローチャートである。この図４では、障害の発生により、その障害を復旧するために管理サーバ２−１が実行する処理、その管理サーバ２−１の処理によってマネージメントブレード３、障害が発生した運用サーバ２、及びその運用サーバ２に割り当てられた２つの予備サーバ２−５、２−６がそれぞれ実行する処理を表している。次に図４を参照して、障害が発生した場合に、管理サーバ２−１、マネージメントブレード３、障害が発生した運用サーバ２、及びその運用サーバ２に割り当てられた２つの予備サーバ２−５、２−６がそれぞれ実行する処理について詳細に説明する。
【００４３】
管理サーバ２−１の処理は、ＣＰＵ２１が管理アプリ２５ａを実行することによって実現され、マネージメントブレード３の処理は、ＣＰＵ３１がメモリ３２上の管理プログラム３２ａを実行することで実現される。障害が発生した運用サーバ２の処理は、制御装置２７によって実現され、各予備サーバ２の処理は、ＣＰＵ２１がＦＷＨ２２のＢＩＯＳ２２ａを実行することで実現される。運用サーバ２に発生した障害は、管理サーバ２−１のＣＰＵ２１がＬＡＮ７を介した通信、或いはマネージメントブレード３からの通知等によって検出される。
【００４４】
管理サーバ２−１のＣＰＵ２１は、運用サーバ２上に発生した障害の検出により、例えばＬＡＮ７を介して、その運用サーバ２の電源のオフをマネージメントブレード３に指示する（Ｓ１１）。その運用サーバ２の保守データ２５ｂ中の個別保守データでは、運用状態は「正常」から「障害」に更新される。
【００４５】
マネージメントブレード３のＣＰＵ３１は、その指示に従い、バス６を介して、運用サーバ２の制御装置２７に電源のオフを指示する（Ｓ２１）。運用サーバ２の制御装置２７は、その指示に従い、電源のオフを行う（Ｓ３１）。それにより、障害が発生した運用サーバ２のＣＰＵ２１は動作を停止する。
【００４６】
管理サーバ２−１のＣＰＵ２１は、次に、保守データ２５ｂを参照し、障害が発生した運用サーバ２に割り当てられている予備サーバ２（ここでは予備サーバ２−５、２−６）を特定し、特定した予備サーバ２の電源のオンをマネージメントブレード３に指示する（Ｓ１２）。その後、管理サーバ２−１のＣＰＵ２１は、マネージメントブレード３から通知される、予備サーバ２の起動結果に対応するためにＳ１３及びＳ１４の処理ループを実行する。このＳ１３及びＳ１４についての詳細は後述する。
【００４７】
マネージメントブレード３のＣＰＵ３１は、電源のオンを指示された各予備サーバ２の制御装置２７に、電源のオンを指示する（Ｓ２２）。各予備サーバ２の制御装置２７は、その指示により、電源をオンさせる（Ｓ４１、Ｓ５１）。この結果、各予備サーバ２のＣＰＵ２１は、ＦＷＨ２２からＢＩＯＳ２２ａをメモリ２３に読み出して起動し、起動が完了するまでの間に、自予備サーバ２のＩＰアドレスの設定、設定したＩＰアドレスの通知等を行う（Ｓ４２、Ｓ５２）。
【００４８】
その起動完了後、各予備サーバ２のＣＰＵ２１は、マネージメントブレード３からの指示を受信したか否か判定する（Ｓ４３、Ｓ５３）。その指示とは、ＬＡＮ７を介して送信される、ＯＳの起動、及び電源のオフの何れかを表す指示である。その指示を受信していない場合、Ｓ４３及びＳ５３の判定はＮとなり、Ｓ４４及びＳ５４にそれぞれ移行して、その指示の受信に対応するための処理を実行する。その後はそれぞれ、再度Ｓ４３、及びＳ５３の判定処理を行う。
【００４９】
このようなことから、Ｓ４３及びＳ５３でのＹの判定は、直前に実行したＳ４４及びＳ５４でマネージメントブレード３からの指示を受信した場合に行われる。Ｓ４３及びＳ５３の判定はＹとなった場合、Ｓ４５及びＳ５５にそれぞれ移行し、各予備サーバ２のＣＰＵ２１は、受信した指示に従って、ＯＳの起動、或いは電源のオフを行う。
【００５０】
マネージメントブレード３は、予備サーバ２の一つのみにＯＳの起動を指示し、他の予備サーバ２には電源のオフを指示する。それにより、図４では、予備サーバ２−５が最速に起動すると想定し、そのＣＰＵ２１は、Ｓ４５でＯＳの起動を行い、予備サーバ２−６のＣＰＵ２１はＳ５５で電源のオフを行っている。各予備サーバ２のＣＰＵ２１は、Ｓ４５及びＳ５５の処理の実行により、障害発生による一連の処理が終了する。予備サーバ２−５は、その後、管理サーバ２−１が障害の発生を監視する対象となる。
【００５１】
マネージメントブレード３のＣＰＵ３１は、各予備サーバ２に電源のオンを指示した後、何れかの予備サーバ２でのＢＩＯＳ２２ａの起動が完了したか否か判定する（Ｓ２３）。何れの予備サーバ２でもＢＩＯＳ２２ａの起動完了が確認できない場合、Ｓ２３の判定はＮとなってＳ２４に移行する。何れかの予備サーバ２でのＢＩＯＳ２２ａの起動完了が確認できた場合、Ｓ２３の判定はＹとなってＳ２５に移行する。
【００５２】
Ｓ２４では、マネージメントブレード３のＣＰＵ３１は、例えば各予備サーバ２へのＬＡＮ７を介した問い合わせにより、ＢＩＯＳ２２ａが起動完了したか否か確認するための監視を行う。その後は上記Ｓ２３に戻る。
【００５３】
マネージメントブレード３のＣＰＵ３１は、その問い合わせに最初に返信した予備サーバ２を最速に起動した予備サーバ２と見なす。そのような予備サーバ２を確認した場合、次に実行するＳ２３の判定はＹとなり、Ｓ２５に移行することとなる。
【００５４】
Ｓ２５では、マネージメントブレード３のＣＰＵ３１は、最速でＢＩＯＳ２２ａを起動完了した予備サーバ２の情報を管理データ３２ｂに反映させる。その反映は、予備サーバ２で計時された起動時間を新たに格納し、その予備サーバ２の運用状態を「起動中」から「正常」に変更することで行われる。
【００５５】
次に、マネージメントブレード３のＣＰＵ３１は、最速でＢＩＯＳ２２ａを起動完了した予備サーバ２にＯＳの起動を指示する（Ｓ２６）。その後、マネージメントブレード３のＣＰＵ３１は、他の予備サーバ２毎に、ＢＩＯＳ２２ａの起動完了を待って、電源のオフを指示する（Ｓ２７）。他の予備サーバ２への電源のオフを全て指示した後、障害発生による一連の処理が終了する。
【００５６】
上記Ｓ１３では、管理サーバ２−１のＣＰＵ２１は、マネージメントブレード３からＢＩＯＳ２２ａを起動完了した予備サーバ２、つまり最速でＢＩＯＳ２２ａを起動完了した予備サーバ２が通知されたか否か判定する。そのような予備サーバ２が通知されていない場合、Ｓ１３の判定はＮとなってＳ１４に移行する。そのような予備サーバ２が通知された場合、Ｓ１４の判定はＹとなり、ここで障害発生に対応するための一連の処理が終了する。
【００５７】
Ｓ１４では、管理サーバ２−１のＣＰＵ２１は、例えばマネージメントブレード３へのＬＡＮ７を介した問い合わせにより、最速でＢＩＯＳ２２ａを起動完了した予備サーバ２を確認する。その後は上記Ｓ１３に戻る。この管理サーバ２−１でのＳ１４の処理への対応は、マネージメントブレード３でのＳ２５の処理で行われる。
【００５８】
管理サーバ２−１のＣＰＵ２１は、最速でＢＩＯＳ２２ａを起動完了した予備サーバ２を確認できた場合、マネージメントブレード３による管理データ３２ｂの更新と合わせた保守データ２５ｂの更新、更には確認された予備サーバ２への予備サーバ２の割り当て設定等を行う。次に実行するＳ１３の判定はＹとなる。
【００５９】
図４には特には図示していないが、Ｓ１３での判定は、マネージメントブレード３に予備サーバ２の電源のオンを指示してから所定時間が経過した場合もＹとなる。これは、全ての予備サーバ２がＢＩＯＳ２２ａを起動完了できない場合、つまり全ての予備サーバ２に障害が発生している場合を想定したものである。全ての予備サーバ２が所定時間内にＢＩＯＳ２２ａを起動できなかった場合、管理サーバ２−１のＣＰＵ２１は、マネージメントブレード３に指示して、全ての予備サーバ２の電源をオフさせ、新たに選択する複数の予備サーバ２の電源をオンさせる。そのようにして、管理サーバ２−１は、全ての予備サーバ２に障害が発生していた場合に対応する。
【００６０】
マネージメントブレード３は、通常、最速でＢＩＯＳ２２ａを起動完了した予備サーバ２以外の予備サーバ２には、ＢＩＯＳ２２ａの起動完了を待って電源のオフを指示する。しかし、マネージメントブレード３は、所定時間内にＢＩＯＳ２２ａを起動完了できなかった予備サーバ２に対し、バス６を介した制御装置２７への電源のオフを指示する。それにより、一つ以上ＢＩＯＳ２２ａを起動完了した予備サーバ２が存在する状況では、障害が発生していると見なす予備サーバ２の電源のオフはマネージメントブレード３の制御によって行われる。
【００６１】
なお、本実施形態による処理システムは、サーバブレード２を処理装置とするものであるが、処理システムは、ブレードサーバ、或いは異なるサーバを処理装置とするものであっても良い。処理装置は、データ処理ではなく、通信等の実現に用いられるものであっても良い。
【００６２】
本実施形態では、サーバブレード２の一つである管理サーバ２−１とマネージメントブレード３との連携により、予備サーバ２を用いて運用サーバ２に発生した障害を復旧させるようにしているが、１つの装置の制御により、障害を復旧させるようにしても良い。例えばマネージメントブレード３に管理サーバ２−１としての機能を搭載させ、マネージメントブレード３の制御により、障害を復旧させるようにしても良い。
【００６３】
以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
第１の処理装置、及び該第１の処理装置の予備とする第２の処理装置を備えた処理システムにおいて、
前記第１の処理装置に発生する障害を検出する監視手段と、
前記第１の処理装置に発生した障害を前記監視手段が検出した場合に、複数の第２の処理装置を起動させる起動手段と、
前記起動手段により起動させる前記第２の処理装置のなかから１台の第２の処理装置を選択し、該選択した第２の処理装置を前記障害が発生した前記第１の処理装置の代替とする選択手段と、
を具備することを特徴とする処理システム。
（付記２）
前記選択手段は、前記起動手段により起動させる複数の第２の処理装置のなかから、ＢＩＯＳ（Basic Input/Output System）の起動完了が最も早い第２の処理装置を選択する、
ことを特徴とする付記１に記載の処理システム。
（付記３）
各第２の処理装置は、前記ＢＩＯＳを起動させた後、前記選択手段による選択結果に従って、オペレーティングシステムの起動、及び電源のオフのうちの何れかを行う、
ことを特徴とする付記２に記載の処理システム。
（付記４）
コンピュータの制御により、処理装置に障害が発生した場合に、予備の処理装置を用いて復旧するための復旧方法において、
前記コンピュータに、
前記処理装置に障害が発生した場合に、該処理装置の代替候補となる予備の処理装置を複数、起動させ、
前記複数の予備の処理装置のなかで起動を完了した予備の処理装置のなかから、前記処理装置と代替させる予備の処理装置を選択させる、
ことを特徴とする復旧方法。
（付記５）
処理装置に障害が発生した場合に、予備の処理装置を用いて復旧を行うための管理装置であって、
前記処理装置に障害が発生した場合に、複数の予備の処理装置を起動させる起動手段と、
前記起動手段により起動させた前記複数の予備の処理装置のなかから１台の予備の処理装置を選択し、該選択した予備の処理装置を前記障害が発生した前記処理装置の代替とする選択手段と、
を具備することを特徴とする管理装置。
（付記６）
コンピュータに、
複数の処理装置を起動させる機能と、
前記起動させる機能により起動させた前記複数の処理装置のなかから１台の処理装置を選択し、該選択した処理装置以外の処理装置を終了させる機能と、
を実現させるためのプログラム。
（付記７）
処理装置に、
ＢＩＯＳ（Basic Input/Output System）の起動が完了した場合に、外部装置からの指示を入力するための機能と、
前記入力するための機能により入力した前記外部装置からの指示に従って、オペレーティングシステムの起動、及び電源のオフのうちの何れかを行う機能と、
を実現させるためのプログラム。
【符号の説明】
【００６４】
１    ブレードサーバ
２、２−１〜２−１０    サーバブレード
３    マネージメントブレード
４、４−１〜４−３    電源装置
５、６    バス
７    ＬＡＮ
２１、３１    ＣＰＵ
２２    ＦＷＨ
２３、３２    メモリ
２４、３３    インターフェース
２５    ハードディスク装置
２６    コントローラ
【図１】
2013164762.tif 000003
【図２】
2013164762.tif 000004
【図３】
2013164762.tif 000005
【図４】
2013164762.tif 000006