JP5486038B2 - サーバ切り替え方法、およびサーバシステム - Google Patents

Description

本発明は、フェイルオーバーの高速切り替え技術、特にディスクイメージ配信方式フェイルオーバーの高速切り替え技術に関する。

ＳＡＮ（Ｓｔｏｒａｇｅ Ａｔｔａｃｈｅｄ Ｎｅｔｗｏｒｋ）に接続された計算機システムでは、ＳＡＮに接続されたストレージサブシステム内のＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）と計算機に内蔵されるＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）のセキュリティ設定を切り替えることで、ある特定のＬＵへアクセス可能な計算機を交替することが可能である。これを利用して、計算機に障害が発生した際に、ＬＵは変えず計算機を切り替えるフェイルオーバー方式が実現されている。また、セキュリティ設定は変えず、ＨＢＡが持つＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）を書き換えることで、同様の効果を得るフェイルオーバー方式も実現されている。両フェイルオーバー方式は高速なフェイルオーバーを提供可能な反面、高価なストレージ装置を前提とする。

そのため、より安価なフェイルオーバー方式に対するニーズは高い。上述のフェイルオーバー方式に対し、安価なフェイルオーバー方式として、障害が発生した計算機のディスクイメージを、予備の計算機へ配信する方式が存在する（特許文献１参照）。このディスクイメージ配信方式では、高価なストレージ装置は必要ないため、安価に高可用なシステムを構築することが可能である。しかし、障害が発生してから配信を開始するため、フェイルオーバーが完了するまでに時間がかかるという問題点があった。

特開２００６−１１７８１号公報

特許文献１には高速なフェイルオーバーを実現する方法が開示されているが、障害発生後に予備の計算機へＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）とアプリケーションを高速にインストールする方式であり、インストールする時間が必ず発生するため、十分な高速化を図ることには限界がある。
本発明の課題は、フェイルオーバーの高速切替方法、およびそのシステムを提供することにある。

本発明では、予め予備サーバへディスクイメージを配信しておくことで、インストールする時間をなくし、また予め配信しておいたディスクイメージが障害発生サーバと異なる場合も、固有情報設定の再設定や追加インストールを実施することで、再配信するよりも高速にフェイルオーバーする方法、およびそうの装置を提供する。

即ち、本発明においては、現用サーバが提供する業務のいずれかのディスクイメージを予め予備サーバへ配信しておき、現用サーバと予備サーバを管理する管理サーバが、現用サーバの障害を受け付けたときに、障害を受け付けた現用サーバの業務を予備サーバで実行可能か判定し、実行可能であれば現用サーバの業務を予備サーバで実行させる。障害を受け付けた現用サーバの業務を予備サーバで実行可能でない場合、管理サーバは、予備サーバで現用サーバの業務を実行するためのディスクイメージを予備サーバへ送付する。

言い換えるなら、上記の課題を達成するため、本発明においては、それぞれストレージ装置と処理部を有する、業務を実行する現用サーバと、少なくとも１台の予備サーバと、管理サーバとがネットワークを介して接続されるサーバシステムのサーバ切り替え方法であって、管理サーバは、予備サーバに現用サーバのディスクイメージを予め配信し、管理サーバのストレージ装置に業務提供管理サーバ情報を保持しており、管理サーバが現用サーバの障害を受け付けたとき、管理サーバのストレージ装置に保持する前記業務提供管理サーバ情報に基づいて、障害を受け付けた前記現用サーバの業務を前記予備サーバで実行可能か判定し、実行可能であれば、前記現用サーバの業務を前記予備サーバで実行するよう制御するサーバ切り替え方法を構成する。

本発明の構成により、高速フェイルオーバーが可能なサーバ切り替え方法、ならびにサーバシステムの提供が可能となる。

本発明の実施例１のシステムの全体構成図である。 実施例１のシステムにおけるディスクイメージを説明するための図である。 実施例１におけるフェイルオーバー手順を示す図である。 実施例１における管理サーバを示す図である。 実施例１における現用サーバを示す図である。 実施例１における予備サーバを示す図である。 実施例１におけるサーバのハードウェア情報管理テーブルを示す図である。 実施例１におけるディスクイメージに格納されているソフトウェアに関するテーブルを示す図である。 実施例１におけるディスクイメージが内包するハードウェアに関する情報テーブルを示す図である。 実施例１における業務提供サーバ管理テーブル（障害発生前）を示す図である。 実施例１における業務提供サーバ管理テーブル（障害発生後、切り替え中）を示す図である。 実施例１における業務提供サーバ管理テーブル（切り替え完了）を示す図である。 実施例１における業務とネットワークに関するテーブルを示す図である。 実施例１における業務の優先順位に関するテーブルを示す図である。 実施例１における障害通知管理テーブルを示す図である。 実施例１における制御プログラムの処理フローを示す図である。 実施例１における障害通知受信プログラムの処理フローを示す。 実施例１におけるネットワーク設定変更プログラムの処理フローを示す図である。 実施例１における配信指示プログラムの処理フローを示す図である。 実施例１における配信指示プログラムの処理フローを示す図である。 実施例１における配信実行プログラムの処理フローを示す図である。 実施例１におけるテスト実行プログラムの処理フローを示す図である。 実施例２のシステムの全体構成図を示す図である。 実施例２における管理サーバを示す図である。 実施例２における管理対象サーバを示す図である。 実施例２におけるストレージサブシステムのセキュリティ設定テーブルを示す図である。 実施例２におけるストレージのセキュリティ設定を示す図である。 実施例３の内蔵ディスクとＳＡＮ接続ストレージによるシステムの全体構成図を示す図である。 実施例３のＳＡＮ接続ストレージのみのシステムの全体構成図を示す図である。 図２６に示す実施例３における仮想サーバを示す図である。 図２７に示す実施例３の仮想サーバを示す図である。 実施例３における差分データ管理テーブルを示す図である。 各実施例におけるライセンス管理テーブルを示す図である。

以下、本発明の最良の形態を図面を用いて説明する。なお、本明細書において、サーバとは通信機能を有する通常の計算機である。

図１Ａは、本発明における実施例１のサーバシステムの全体図を示している。管理サーバ１０１は、NW-SW１０４を介して、現用サーバ１０２および予備サーバ１０３と接続されている。現用サーバ１０２は業務サービスを提供しており、予備サーバ１０３は現用サーバ１０２において障害が発生した際に、代わって業務サービスを提供するためのサーバである。管理サーバ１０１は、現用サーバ１０２と予備サーバ１０３を監視する。特に本実施例のサーバシステムは、現用サーバ１０２において発生する障害通知を監視し、現用サーバにおいて障害が発生したと確認した際に、予備サーバ１０３において業務サービスを提供することで、ビジネス継続性を高めることを主目的とする。

現用サーバ１０２はストレージ装置１２２を内蔵し、予備サーバ１０３はストレージ装置１３２を内蔵しており、夫々のストレージ装置１２２および１３２には、ＯＳや業務サービスを提供するためのミドルウェアやアプリケーションがインストールされている。管理サーバ１０１はストレージ装置１１２を内蔵している。ストレージ装置１１２には、業務サービスを提供する上で必要なソフトウェアがインストールされたディスクイメージ１２１が格納されている。

ディスクイメージ１２１の内容は、後で図面を用いて説明するが、業務サービスを提供する個々の現用サーバのディスクイメージ、または個々のサーバの固有情報が抜けたディスクイメージ、または共通に利用するソフトウェアのみがインストールされているだけのディスクイメージ、などがある。

現用サーバ１０２において、障害が発生した際には、障害が発生した現用サーバ１０２が提供する業務サービスと同様のディスクイメージ１２１を予備サーバ１０３へ配信することで、業務サービスを継続することが可能になる。ディスクイメージ１２１を配信する際、障害が発生した現用サーバ１０２と全く同じディスクイメージ１２１を配信することで、配信作業のみを行うことで業務サービスの継続を図ることが出来る。ただし、現用サーバの台数分だけディスクイメージ１２１を準備する必要があり、ストレージ容量も膨大になる。

それに対し、固有情報が抜けたディスクイメージを利用することで、配信後に固有情報を設定する作業が増えるものの、ディスクイメージ１２１を業務サービスごとに共通化することが出来る。これにより、ディスクイメージ１２１を保存するために必要なストレージ容量も削減することが可能になる。更に、共通に利用するソフトウェアのみがインストールされているだけのディスクイメージ１２１を利用することで、システム内でディスクイメージ１２１を共有することが可能になる。ただし、ディスクイメージを配信した後に、必要なソフトウェアをインストールしたり、ＯＳやソフトウェアごとの固有情報を設定する作業が増えるため、若干フェイルオーバーの高速性が低下するが、従来のようになにもインストールされていないサーバへインストール作業を実施するよりも遥かに作業量や作業時間の面で優位である。

特に、本実施例では、予め予備サーバ１０３へディスクイメージを配信しておくことで、フェイルオーバー完了までの時間を短縮するため、再インストールは出来るだけ回避すべきである。そのため、共通分のみがインストールされているディスクイメージ１２１を予備サーバへ予め配信しておくことで、再インストールを回避し、より高速にフェイルオーバーを実現することが可能である。上記のような高速フェイルオーバーを実現するためのプログラム群が制御プログラム１１０である。また、管理テーブル群１１１には、現用サーバ１０２や予備サーバ１０３に関する情報テーブルやディスクイメージ１２１に関する情報テーブル、また業務サービスに関する情報テーブルが格納されている。これら制御プログラム１１０、管理テーブル１１１は後に詳述される。

図１Ｂはディスクイメージの一例を模式的に示した図である。同図におけるディスクイメージ１４０には、アプリケーション・ミドルウェアであるP.P. （Ｐｒｏｇｒａｍ Ｐｒｏｄｕｃｔ）１４２、OS１４３、ハードウェア（アーキテクチャ）情報１４４が含まれている。また、P.P.１４２、OS１４３内には、固有情報１４１として設定値１４５、１４６が含まれている。このディスクイメージとは、一般的にサーバに接続されたストレージ装置に格納されたデータを採取したファイルである。このディスクイメージを元のサーバへリストアすることで、ディスクイメージを採取したときの状態へサーバを復旧することが出来る。また、同じハードウェア構成のサーバへリストアすることで、OSやP.P.がインストールおよび設定された状態で複製することが出来る。

ただし、図１Ｂに示すOS１４３やP.P.１４２は、各ハードウェアに固有な情報（MACアドレスなど）や、ソフトウェア固有の設定値（ライセンス、ホスト名、IPアドレスなど）を保持しているため、単純にディスクイメージを複製配信しただけでは、業務を提供するシステムへ組み込めないケースが存在する。そのため、サーバ毎に適切な設定を実施する必要がある。種々の実施例で利用されるディスクイメージは、OSやP.P.を内包する場合と、しない場合があり、また、ハードウェアやソフトウェアに関する設定値について、保持している場合と、しない場合があることは上述の通りである。

図２は、本実施例のシステムの高速フェイルオーバー方法について概略を図解したものである。なお、図２他における丸内数字の表示は、本明細書中にあっては、括弧内数字で表示している点に留意されたい。まず、業務サービスの優先順位や稼動実績などから予め予備サーバ１０３へディスクイメージ１２１を配信しておく。ただし、予め配信しておくことは必須ではない。ライセンス数の上限値を超える場合など、予め配信しておくことが困難なケースも存在するためである。現用サーバ１０２では、業務Ａ２０２が提供されている。(1)障害通知２１１を管理サーバ１０１が受け取る。(2)予備サーバ１０３へ配信されているディスクイメージを確認し、再配信または再設定が必要か否かを判定する。(3)-1（要の場合）予備サーバ１０３は配信済みのディスクイメージが業務Ｂ２０３などの別業務のディスクイメージだった場合には再配信が必要となるため、業務Ａ２０２のディスクイメージを配信する。(3)-2（否の場合）予備サーバには既に業務Ａ２０２のディスクイメージが配信されているため、すぐに電源Ｏｎをすることが可能な状態である。(4)前段階までに予備サーバ１０３には業務Ａ２０２のディスクイメージが配信されているため、予備サーバ１０３を本番業務ＬＡＮへ参加させ、業務サービスを継続させる。上の概略に示した通り、予め配信しておいたディスクイメージ１２１が目的のディスクイメージだった場合には、高速なフェイルオーバーを提供することが可能である。また、再配信とまではいかなくても、再設定のみで予備サーバの設定を完了することが出来れば、同様に高速なフェイルオーバーを提供することが可能である。本実施例では、再配信を回避し再設定にて目的のサーバを構築する方法について言及している。つまり、再設定にて当初の目的を達成できる許容範囲設定についても後述する。(2)のタイミングでは、残った予備サーバをどのような構成で保持するかを判定し、必要に応じて、予備サーバへ再配信または再設定を行う。

図３は、本実施例のシステムにおける管理サーバ１０１の一構成例を述示している。演算を処理する中央処理部（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、ＣＰＵ）３０１、ＣＰＵ３０１で演算するプログラムや処理を格納する記憶領域であるメモリ３０２、ＩＰネットワークを介して通信を行うためのＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）３０４、プログラムやデータを格納し保存する記憶領域であるストレージ装置１１２から構成されている。先に述べたように、サーバの構成は通常の計算機の構成である。

メモリ３０２には、制御プログラム群１１０および管理テーブル群１１１が格納されている。制御プログラム１１０（図１５参照）は、障害通知受信プログラム３１０（図１６参照）、ネットワーク設定変更プログラム３１１（図１７参照）、配信指示プログラム３１２（図１８参照）、配信実行プログラム３１３（図１９参照）、テスト実行プログラム３１４（図２０参照）から構成される。

管理テーブル群１１１は、サーバのハードウェア情報管理テーブル３２１（図６参照）、ディスクイメージに格納されているソフトウェアに関するテーブル３２２（図７参照）、ディスクイメージが内包するハードウェアに関する情報テーブル（図８参照）、業務提供サーバ管理テーブル３２４（図９、図１０、図１１参照）、業務とネットワークに関するテーブル３２５（図１２参照）、業務の優先順位に関するテーブル３２６（図１３参照）、ストレージサブシステムのセキュリティ設定テーブル３２７（図２４参照）、障害通知管理テーブル３２８（図１４参照）、差分データ管理テーブル３２９（図３０参照）、ライセンス管理テーブル３３０（図３１参照）から構成される。これらの詳細は、後で対応する図面を用いて説明される。管理サーバ１０１が受信する障害通知は、管理対象である現用サーバ１０２や予備サーバ１０３が持つハードウェアおよびソフトウェアによる監視機構によって実現される。

図４は、現用サーバ１０２の構成を述べている。現用サーバ１０２は、演算を処理するＣＰＵ４０１、ＣＰＵ４０１で演算するプログラムや処理を格納する記憶領域であるメモリ４０２、ＩＰネットワークを介して通信を行うためのＮＩＣ４０３、電源制御を管理サーバ１０１から実行するためのＢＭＣ（Ｂａｓｅｂｏａｒｄ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ）４０４から構成されている。現用サーバ１０２の電源ＯｎまたはＯｆｆについてＢＭＣ４０４を介して実行することが可能である。現用サーバ１０２と管理サーバ１０１は、ＮＷ−ＳＷ１０４を介して接続されている。ＮＩＣ４０３を介して、現用サーバ１０２で稼動する監視プログラム（記載しない）が管理サーバ１０１と通信を行い、障害を通知する。前述の監視プログラムによって、現用サーバ１０２の設定や負荷や障害などの状態を監視することが可能である。ＮＩＣ４０３は、管理用に設けられることもあり、業務で利用するためのＮＩＣは別途設置されることが一般的である。また、ＢＭＣ４０４を介しても管理サーバ１０１とネットワーク的に接続されており、ハードウェア的な障害を通知したり、電源Ｏｎや強制的な電源Ｏｆｆをハードウェア的に実施することが可能である。

図５は、予備サーバ１０３の構成を述べている。予備サーバ１０３は、演算を処理するＣＰＵ５０１、ＣＰＵ５０１で演算するプログラムや処理を格納する記憶領域であるメモリ５０２、ＩＰネットワークを介して通信を行うためのＮＩＣ５０３、電源制御を管理サーバ１０１から実行するためのＢＭＣ５０４から構成されている。予備サーバ１０３の電源ＯｎまたはＯｆｆについてＢＭＣ５０４を介して実行することが可能である。予備サーバ１０３と管理サーバ１０１は、ＮＷ−ＳＷ１０４を介して接続されている。ＮＩＣ５０３を介して、予備サーバ１０３で稼動する監視プログラム（記載しない）が管理サーバ１０１と通信を行い、障害を通知する。前述の監視プログラムによって、予備サーバ１０３の設定や負荷や障害などの状態を監視することが可能である。ＮＩＣ５０３は、管理用に設けられることもあり、業務で利用するためのＮＩＣは別途設置されることが一般的である。また、ＢＭＣ５０４を介しても管理サーバ１０１とネットワーク的に接続されており、ハードウェア的な障害を通知したり、電源Ｏｎや強制的な電源Ｏｆｆをハードウェア的に実施することが可能である。予め予備サーバ１０３へディスクイメージを配信しておくことで、定期的または不定期に予備サーバ１０３を起動して、動作確認プログラムを実行したり、パッチをあてるなどのメンテナンスを実施することが出来る。

図６は、管理サーバ１０１のメモリ３０２に記憶された管理テーブル１１１の一つである、サーバのハードウェア構成情報管理テーブル３２１を詳述している。本テーブルには、各サーバに内蔵または接続されているハードウェアに関する情報が集約されている。同図において、カラム６０１はサーバ識別子を格納しており、本識別子によって各サーバを一意に識別する。

カラム６０２にはＣＰＵアーキテクチャ、即ち処理部としてのＣＰＵの種別が格納されている。基本的に、ＣＰＵアーキテクチャ（種別）が異なるサーバとＯＳブート用のディスクイメージを共有することは困難である。そのため、ディスクイメージ配信を行う場合は、なんらかの方法でＣＰＵアーキテクチャを判別しなければ、異なるＣＰＵアーキテクチャ（処理部の種別）のディスクイメージを配信しかねないことになるため、これを回避するためにも重要なファクタである。

カラム６０３には、ＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ ＩＤｅｎｔｉｆｉｅｒ）が格納されている。ＵＵＩＤは、本来、全宇宙規模で識別子が重複しないように形式が規定されている。そのため、サーバ毎に保持した場合、確実なユニーク性を保証する識別子となりえる。そのため、カラム６０１に格納されているサーバ識別子の候補であり、広範囲に渡ったサーバ管理には非常に有効である。ただし、カラム６０１には、システム管理者がサーバを識別したい識別子を使用すれば良く、また管理する対象となるサーバ間で重複することがなければ問題ないため、ＵＵＩＤを使うことが望ましいものの必須とはならない。例えば、ホスト名やＩＰアドレス、ＭＡＣアドレス（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ アドレス）、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）などが候補として考えられる。

カラム６０４〜６０６は、ＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｏｒ）に関する情報を格納している。カラム６０４には、ＨＢＡの枚数を格納している。これにより、サーバに内蔵しているＨＢＡ枚数を把握することが可能になり、図８で詳述するディスクイメージが内包するハードウェアと照会し、組み込むべきデバイスドライバが必要十分か検証することが可能になる。

カラム６０５には、ＨＢＡの持つＷＷＮを格納している。ＷＷＮは、実施例２のＳＡＮ環境において図２４に示すストレージサブシステムのセキュリティ設定において、サーバ側を識別する識別子となる。そのため、ＳＡＮ環境が前提のシステムにおいては、サーバ識別子としての役割を担う場合もある。

カラム６０６には、ＨＢＡのデバイスドライバ種別を格納している。同時に、デバイスドライバのインストール場所も記載しておくことで、デバイスドライバ種別が異なるデバイスを内蔵する場合でも、必要なデバイスドライバをどこへインストールすれば良いかが明らかになり、自動的にデバイスドライバを組み込むことが可能になる。実施例２にて詳述するが、ＨＢＡに関するカラム群は、ＳＡＮ環境において重要な役割を担う。

カラム６０７〜６０９は、ＮＩＣに関する情報を格納している。カラム６０７は、ＮＩＣの枚数を格納している。カラム６０４と同様に、組み込むべきデバイスドライバが必要十分か検証することが可能になる。また、業務に必要なＩＰ情報（ＩＰアドレス、サブネットマスク、デフォルトゲートウェイなど）を割り当てる際に、ＮＩＣ枚数が十分か検証することが可能となる。足りない場合は、同一ＮＩＣに複数のＩＰ情報を割り当てることになるが、運用や性能の面で問題になる場合、回避する必要があるため、判断材料として活用することが出来る。

カラム６０８には、ＮＩＣの持つＭＡＣアドレスを格納している。ＭＡＣアドレスは、一般的に一意の識別子であるため、サーバ識別子としての役割を担う場合もある。

カラム６０９には、ＮＩＣのデバイスドライバ種別を格納している。同時に、デバイスドライバのインストール場所も記載しておくことで、デバイスドライバ種別が異なるデバイスを内蔵する場合でも、必要なデバイスドライバをどこへインストールすれば良いかが明らかになり、自動的にデバイスドライバを組み込むことが可能になる。

カラム６１０からカラム６１２は、ストレージに関する情報を格納している。ディスクイメージ配信を行う場合、ストレージ環境の整合性が取れていることが非常に重要である。

カラム６１０には、サーバとストレージ装置の接続Ｉ／Ｆ（インタフェース）が格納されている。接続インターフェースが異なる場合、デバイスドライバの入れ替えが必須となるため、ディスクイメージ配信を実施する際に、配信したディスクイメージが正しく動作するために必要な作業が行われているかを検証することが可能になる。

カラム６１１には、ストレージ装置のストレージ容量が格納されている。もし配信するディスクイメージの容量が、カラム６１１に格納されている値を上回る場合、ディスクイメージが入りきらず、正しく動作することが出来ない。逆に、ディスクイメージの容量が小さい場合、動作させることは可能であることが多いため、管理ポリシーによっては問題視しない運用も有り得る。

カラム６１２は、ＯＳをｂｏｏｔ（ＯＳ起動、ＯＳブート）するストレージ装置か、データを格納するためのストレージ装置か、を格納している。データ用ストレージ装置をＳＡＮ環境などの外付けストレージ装置へ置くことは一般的であり、フェイルオーバー時にＳＡＮ環境に存在するデータディスクを引き継ぐ必要がある場合もある。なお、ＳＡＮ環境に接続するケースについては、実施例２にて詳述する。

本テーブルは、上述のようにＳＡＮ構成へも適用可能である。また、本テーブルは、記載しないがメモリ容量を追記し、業務に必要な性能を満たすサーバを検索し選択することに利用することも出来る。これにより、用途に合致した性能を持つサーバをフェイルオーバー時に選択することが可能になる。本テーブルの情報は、サーバから自動収集することも可能であるが、管理者によって入力される場合もある。ただし、カラム６１２については、初期設定値をｂｏｏｔに設定し変更しない運用も考えられるが、一般的には管理者によって手入力される。また、カラム６０１については、本テーブルで使用される各カラムのいずれか、または複数カラムを組み合わせたものを指定することで入力を省略することが出来る。また、昇順などで自動的に割り振っても良い。

次に、図７は、管理サーバ１０１中の管理テーブル１１１中の、ディスクイメージに格納されているソフトウェアに関するテーブル３２２の一構成例を示している。本テーブルには、ディスクイメージに格納（インストール）されているソフトウェアや固有設定情報、および既インストールシステムに対して追加インストールすることが許容されるＰ．Ｐ．およびバージョンに関する情報が集められている。

カラム７０１には、業務識別子が格納されている。業務Ａの第１サーバ、第２サーバといった個々をサーバレベルまで特定する記述方法（７５１から７５４）、業務Ａで共通化されたソフトウェアのインストールを示し、業務レベルまでを特定する記述方法（７５５、７５６）、システムで共通化されたソフトウェアのインストールを示し、共通環境レベルを特定する記述方法（７５７、７５８）などが考えられる。

カラム７０２には、ディスクイメージ名が格納されている。ディスクイメージ名は、各ディスクイメージを特定するための識別子である。ここでディスクイメージの内容について言及する。業務識別子７０１にて述べた通り、目的に応じて格納する内容や種類を変えることが望ましい。例として、以下に三通りのディスクイメージについて述べる。(1)ＯＳ＋ミドルウェアやアプリケーション＋固有情報、(2)ＯＳ＋ミドルウェアやアプリケーション（固有情報は抜かれた状態）、(3)ＯＳ（ミドルウェアやアプリケーションは未インストール、固有情報は抜かれた状態）。(1)の長所は、配信のみで業務を開始できることである。

また、予備サーバへ配信されたディスクイメージが故障した現用サーバと(1)のレベルで全く同一であれば起動だけでフェイルオーバーを実現することが出来るため、非常に高速である。(2)の長所は、配信後、固有情報の設定のみで業務を開始できることである。(1)と比較すると、固有情報を設定する時間がかかるため、サーバ起動のみでフェイルオーバーを実現できる(1)よりも、やや時間がかかる。ただし、ソフトウェアライセンスという観点から優位な場合が多い。 現在のソフトウェアのライセンス体系を鑑みると、(1)の方法ではライセンスが必要なケースが多い。しかし、(2)のケースではバックアップしたディスクイメージ扱いとなり、ライセンス料が課せられるケースの方が稀だと考えられる。(3)の長所は、配信後に、必要なＰ．Ｐ．のインストールや固有情報の設定が必要になるため、(1)や(2)に比べて高速なフェイルオーバーは実現できない。ただし、なにもインストールされていないサーバへインストールするよりも遥かに高速なフェイルオーバーを実現可能である。また、(2)で言及したライセンス料の問題について、(3)は最も優位である。インストールすらしていないＰ．Ｐ．については、ライセンス数がオーバーすることもない。予備用のライセンスを、本番サーバ数で頭割りしている計算になり、安価に高可用システムを構築することが出来る。例えば、ライセンス管理は、後で説明するライセンス管理テーブル３３０（図３１参照）によって実現する。ディスクイメージの管理という観点からみると、(3)は共通部分が最も多いためディスクイメージの総数が少なくて済む。それに対し、(2)は固有部分が増えるため、個別化が進みディスクイメージの総数は増える。更に、(1)は各サーバで固有のディスクイメージとなるため(2)よりもディスクイメージの総数は増える。

カラム７０３には、ＯＳ種別を格納している。ＳＰ（サービスパック）やパッチ情報を含めることで、追加インストールするＰ．Ｐ．の前提条件に合致しているかを検証することが容易になる。また、セキュリティの観点からも、サーバのメンテナンスが簡単になるというメリットがある。テーブル内には特定のＯＳを記載しているが、その他のＯＳについても同様に記述することが可能であり、また実施例の効果を得ることが出来る。

カラム７０４には、ＯＳが対応するＣＰＵアーキテクチャが格納されている。ＣＰＵアーキテクチャが異なるディスクイメージを配信しても、正常にＯＳは起動することは出来ず、業務も提供することは不可能である。ＣＰＵアーキテクチャなどのハードウェア構成が異なるディスクイメージをサーバへ配信することを抑止することに利用することが可能である。テーブル内に記載している特定のＣＰＵアーキテクチャ以外についても同様に記述することが可能であり、また本実施例の効果を得ることが出来る。

カラム７０５には、ホスト名を格納している。アプリケーションによっては、ホスト名でサーバを識別することがあるため、一般的に管理者がホスト名を付与する。ただし、管理者が与える付与規則に従って自動付与しても構わない。
カラム７０６には、ＯＳのパスワードが格納されている。

カラム７０７には、ＩＰ情報が格納されている。ＩＰ情報には、ＩＰアドレス、サブネットマスク、デフォルトゲートウェイなどがある。ＩＰアドレスについては、範囲を指定することで、その時点で使用されていないＩＰアドレスを利用することで、ＩＰアドレス資源の有効活用を図ることが可能である。しかし、ＩＰアドレスは、管理者やアプリケーションによっては、サーバを識別する識別子となる可能性がある。よって、管理者によって明示的に指定される場合がある。

カラム７０８には、Ｐ．Ｐ．名が格納されている。業務を提供するために必要なミドルウェアやアプリケーション、夫々のバージョン情報などが格納されている。このカラムを参照することで、各業務において必要となるＰ．Ｐ．について情報を得ることが出来る。

カラム７０９には、Ｐ．Ｐ．の固有情報が格納されている。各Ｐ．Ｐ．で使用するＩＰアドレス（論理ＩＰアドレス）やポート番号などである。ポート番号は、重複するとソフトウェアが起動しなかったり、起動しても正常に動作できない場合があるため、重複を避けるためにも各Ｐ．Ｐ．で使用する値を記載しておくことで、トラブルを回避することが出来る。また、追加インストールに必要なコストを記載しておくことで、追加インストールと固有情報設定で対応するか、ディスクイメージの再配信で対応するかを判定することが可能になる。Ｐ．Ｐ．のインストール場所や環境変数を記載することで、必要な設定の確実な実施や他のＰ．Ｐ．が期待するインストール場所へ的確にＰ．Ｐ．をインストールすることが可能になる。

カラム７１０には、他のＰ．Ｐ．と共存する条件を格納している。同一サーバにおいて、共存可能なＰ．Ｐ．やバージョンを記載したり、ＪＲＥ（Ｊａｖａ（登録商標） Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ）といった動作環境に関する制限事項を記載する。これにより、別の業務がインストールされている予備サーバであったとしても、追記インストールと固有情報設定によって再配信なしでフェイルオーバーするか、再配信してフェイルオーバーするかを選択することが可能になる。

カラム７１１には、配信コストを格納している。本実施例は、高速フェイルオーバーを意図している。そのため、フェイルオーバー先を、いかに高速に準備出来るかが重要である。そのため、再配信に要する時間をディスクイメージ（業務）ごとに認識し、Ｐ．Ｐ．追加インストールにかかる時間（カラム７０９に格納）とを併せて鑑みることで、低コストな方法を選択する必要がある。

本テーブルは、ディスクイメージに内包されるソフトウェア情報を記載していることから、ＣＰＵアーキテクチャなどのハードウェア構成が異なるサーバへディスクイメージを配信することを抑止したり、既に配信されているディスクイメージと配信したい業務との差分を追加インストールや設定変更などで吸収したりするために利用される。

本テーブルは、カラム７０３、カラム７０４、カラム７０５、カラム７０７は、ディスクイメージを採取するサーバからエージェントプログラムやＯＳの情報取得コマンドなどから収集可能である。管理者が入力することも可能である。他のカラムについては、管理者が入力するか、ディスクイメージ採取やＰ．Ｐ．インストールのタイミングで同時収集することで入力される。カラム７１０については、管理者が入力することが多いと考えられるが、インターネットまたはイントラネットのサーバからＰ．Ｐ．ごとの情報を収集し、その情報を元に記載しても構わない。

図８は、図３のディスクイメージが内包するハードウェアに関する情報テーブル３２３を詳述している。ディスクイメージを採取したときのサーバのハードウェア構成であり、ディスクイメージが正常動作するために必要なハードウェア構成とも言い換えることが出来る。具体的には、図６と比較することで、ディスクイメージが適用可能なハードウェア構成と配信先サーバのハードウェア構成が合致または許容範囲内にあるか判定することが可能になる。

カラム８０１には、ディスクイメージ名が格納されている。カラム８０２には、ＣＰＵアーキテクチャが格納されている。

カラム８０３には、ＵＵＩＤが格納されている。ＵＵＩＤが異なることで、ディスクイメージ配信後にＯＳやソフトウェアが正常動作しないことは少ないが、中にはハードウェア識別子によって動作するプラットフォームを特定しているケースがあるため、その場合は、サーバ仮想化技術を使用するなどして、ＵＵＩＤを仮想的に一致させる必要がある。

カラム８０４からカラム８０９には、図６のカラム６０４からカラム６０９と同様に、ＨＢＡやＮＩＣといったＩ／Ｏデバイスに関するハードウェア情報が格納されている。

カラム８１０からカラム８１１は、図６のカラム６１０からカラム６１１と同様に、ストレージ装置に関するハードウェア情報が格納されている。
特に、カラム８１１に格納されているストレージ容量には注意する必要がある。図６カラム６１１の値が少ない（ストレージ容量がディスクイメージ容量よりも少ない）場合には、ディスクイメージを格納出来ないため、正常にフェイルオーバーすることが出来ない。
本テーブルは、エージェントプログラムまたはＯＳの情報取得コマンドなどから採取可能であり、自動生成することが可能である。

図９は、図３の業務提供サーバ管理テーブル３２４を詳述している。特に、現用サーバに障害が発生する前の状態を示している。本テーブルには、サーバの種別（現用または予備）や提供している業務、配信されているディスクイメージ、配信に関するステータス、障害に関するステータス、業務ステータス、フェイルオーバー時に予備サーバが満たすべき条件、データディスクの有無と識別子が格納されている。これにより、サーバの状態を把握し、障害が発生した場合に対処が可能になる。

カラム９０１には、サーバ識別子が格納されている。カラム９０２には、サーバの種別（現用サーバまたは予備サーバであること）が格納されている。

カラム９０３には、業務の識別子が格納されている。現用サーバであれば現在提供している業務、予備サーバであれば予め配信されている業務の識別子が格納されている。障害発生時には、現用サーバの本カラム９０３を参照し、必要な業務を確認し、予備サーバの本カラム９０３を参照し、必要な業務が配信されているか否かを判定する。

カラム９０４には、ディスクイメージ名が格納されている。カラム９０５には、配信ステータスが格納されている。配信ステータスとは、ディスクイメージが配信されているか否か、また固有情報が設定されているか否かを格納している。

カラム９０６には、障害ステータスが格納されている。現用サーバの障害情報が格納されている。記載はしないが、スタンバイ状態の予備サーバを監視し、予備サーバの障害ステータスを格納することで、予備サーバ障害への対応が可能になる。例えば、予備サーバにて、定期または不定期にチェックプログラムを実行し、障害がないかを確認し、障害発生時には予備サーバの優先順位や稼動状態などによって、予備サーバへのディスクイメージの配信構成を再構成することが可能になり、可用性を向上することが出来る。

カラム９０７には、業務ステータスが格納されている。現用サーバについては業務提供中か否か（ダウン）、予備サーバについてはどのようなスタンバイ状態（ホットスタンバイ、コールドスタンバイなど）なのかやフェイルオーバー発生中などを格納する。予備サーバがホットスタンバイで待機している場合、予備サーバの配信構成を再構成する際には、シャットダウンしてから再配信または再設定することが望ましい。コールドスタンバイで待機している場合、すぐに再配信が可能であり、再設定する場合は電源をＯｎする必要がある。予備サーバのディスクイメージの配信構成について、再構成を可能性にする情報である。

カラム９０８には、フェイルオーバー時に一致している必要のある範囲を格納している。例えば、カラム９５１やカラム９５２ではＰ．Ｐ．やＯＳ、アーキテクチャが一致している必要があると指定しているため、もし予備サーバに予め配信されているディスクイメージが固有情報の異なるディスクイメージであっても固有情報を再設定することで対応可能となり、再配信するよりも低コストでフェイルオーバーを実現することが可能である。カラム９５３のように、ディスクイメージ名を指定されている場合、予め同ディスクイメージが予備サーバへ配信されていなければ、再配信となる。本テーブルは、管理者が運用ポリシーに基づき、入力して作成する必要がある。

この一致範囲（カラム９０８）の自由度について、詳述する。
ディスクイメージ ：同一業務を持つディスクイメージからの固有情報設定変更さえも許さないため、自由度はない。確実に動作が保証出来るディスクイメージおよび設定を使用することで、可用性は向上する。
Ｐ．Ｐ． ：異なるディスクイメージではあるが、固有情報を設定変更することで対応可能なため、自由度は高い。設定変更のみでフェイルオーバー用のサーバを準備出来るため、高速フェイルオーバーのニーズにも向いている。
ＯＳ ：異なるディスクイメージで、かつ異なるＰ．Ｐ．がインストールされていても、ディスクイメージに格納されているソフトウェアに関するテーブルの他Ｐ．Ｐ．共存条件（図７カラム７１０参照）で許容されるＰ．Ｐ．であれば、必要なＰ．Ｐ．を追加インストールし設定することで使用することが可能なため、更に自由度は高い。Ｐ．Ｐ．固有設定に格納されているコストを評価すると、再配信の方が高速にフェイルオーバー先を準備出来る可能性があるため、準備コストの評価が重要になる（図７参照）。
アーキテクチャ ：業務を提供するためには、Ｐ．Ｐ．を含めて特定する必要があるため、アーキテクチャ単体で許容という指定は意味がない。ただし、アーキテクチャやＯＳが異なっていても、特定のＰ．Ｐ．さえインストールされていれば、提供可能な業務も存在する。つまり、アーキテクチャやＯＳを指定せず、Ｐ．Ｐ．のみが指定されている場合には、フェイルオーバー先の候補を広げた指定が出来るため、資源の有効活用が可能となる。

図１０は、図３の業務提供サーバ管理テーブル３２４を詳述している。特に、現用サーバに障害が発生し、切り替えが発生している状態を示している。テーブルの構成は、図９と同じであるため、各カラムについては図９を参照されたい。具体的には、カラム９＊とカラム１０＊が対応づいている。カラム１０５３に格納されているサーバ３に障害が発生したケースについて述べる。シナリオは、サーバ３で障害が発生し、予備サーバであるサーバ４へフェイルオーバーをする、というものである。太枠にて囲んだ領域１０５５が、変更対象である。

カラム１００６に格納されている障害ステータスが、カラム１０５３について障害発生と変更されている。また、同カラムのカラム１０５４についてＢ−１切り替え発生と変更されており、業務Ｂ−１にて障害が発生していることを示している。

カラム１００５に格納されている配信ステータスが、カラム１０５４について配信中に変更されている。これは、障害が発生した業務において、カラム１００８の条件がディスクイメージ一致を示しているにも関らず、図９カラム９０３を参照すると配信されていたディスクイメージが異なる業務であったため、再配信が必要であったことに起因する。

カラム１００７に格納される業務ステータスが、カラム１０５３についてダウンと変更されている。これは、業務が提供されていないことを示している。また、カラム１０５４についてフェイルオーバー中と変更されており、切り替え準備が進行していることを示している。

図１１は、図３の業務提供サーバ管理テーブル３２４を詳述している。特に、切り替えが完了した状態を示している。テーブルの構成は、図９と同じであるため、各カラムについては図９を参照されたい。先と同様、具体的には、カラム９＊とカラム１１＊が対応づいている。

カラム１１０３に格納されている業務のカラム１１５４については、障害が発生した現用サーバで提供していた業務を引き継いでいる。配信ステータスを格納しているカラム１１０５のカラム１１５３については、情報がリセットされている。復帰させるためには、サーバの交換と再インストール（配信）が必要である。カラム１１５４については、配信と固有情報設定が完了したことが記載されている。業務ステータスを格納するカラム１１０７のカラム１１５４については、業務提供中が格納されており、業務を提供していることを示している。

以上説明した図９、図１０、図１１については、図１５以降のフローチャートを用いた説明の際にも詳述する。

図１２は、図３の業務とネットワークに関するテーブル３２５を詳述している。本テーブルは、業務を提供しているサーバが属しているネットワークに関する設定を管理するテーブルである。

カラム１２０１には、業務識別子が格納されている。カラム１２０２には、ＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）識別子が格納されている。カラム１２０３には、業務を提供するサーバの持つＭＡＣアドレスが格納されている。カラム１２０４には、業務が使用する通信プロトコルが格納されている。

カラム１２０５には、ＮＷ−ＳＷごとに一意な識別子であるブリッジ識別子が格納されている。カラム１２０６には、ＮＷ−ＳＷ内のポートごとに一意な識別子であるポート識別子が格納されている。カラム１２０７には、ＩＰ情報が格納されている。

本テーブルによって、カラム１２５１から１２５３では、業務を提供するサーバとＮＷ−ＳＷおよびネットワークに関する設定が管理されている。
カラム１２５５から１２５６では、各業務とＮＷ−ＳＷおよびネットワークに関する設定が管理されている。ＩＰ情報が格納されているカラム１２０６やカラム１２０７に関して、業務ごとに使用するポート識別子やＩＰ情報の範囲を指定することで、ポートやＩＰアドレスなどが既に埋まっている場合、空いているものを使用することが可能になる。これにより、フェイルオーバー時により柔軟に設定値を変更できるだけでなく、ディスクイメージ指定で配信した場合（既に固有情報も設定済み）に設定情報が重複すると業務を継続提供することが出来ない危険性があるが、これを回避することが出来る。

カラム１２５７には、業務に属さない予備サーバが属するネットワークグループに関する設定が管理されている。ディスクイメージを配信したり、設定を変更する際に、業務ネットワークに接続して実施することは、セキュリティや業務ネットワークの帯域保証の都合上許されないため、このようなプール状態のサーバが属するネットワークグループを確保する必要がある。

図１３は、図３の業務の優先順位に関するテーブル３２６を詳述している。業務に優先順位をつけることで、予備サーバへ予め配信してくディスクイメージを決定することが出来る。また、優先順位が低い業務をフェイルオーバーさせていたが、更に優先順位が高い業務に障害が発生した場合に、後から障害が発生した高優先順位の業務を救いたいことがある。このような運用ポリシーを可能にするテーブルである。

カラム１３０１には、業務識別子を格納している。カラム１３０２には、優先順位の初期値を格納している。これにより、優先順位が動的に変更された場合にも、管理者の望むタイミングで元へ戻すことが可能である。

カラム１３０３には、現在の優先順位が格納されている。これは、既に予備サーバへ切り替わったサーバが存在する場合、そのサーバは障害再発生確率は低いと考え、他のサーバの切り替え優先順位を上げたいというニーズに対応するためである。より障害発生リスクの高いサーバのディスクイメージを予備サーバへ配信しておくことで、高速なフェイルオーバーを高確率で実現することが可能になる。

図１４は、図３の障害通知管理テーブル３２８を詳述している。障害通知ごとに、対応を変えたい場合や業務の優先順位と組み合わせるなど、運用形態に自由度を持たせることが可能になる。

カラム１４０１には、通知識別子が格納されている。カラム１４０２には、障害情報および障害を示す閾値や障害と見なす値の範囲が格納されている。カラム１４０３には、優先順位やフェイルオーバーを発生させる閾値（障害通知回数など）が格納されている。

これにより、障害通知の中にも至急フェイルオーバーにて対応すべきものと、様子を見つつ、頻発するようであれば、フェイルオーバーで対応するといった対応の自由度を高めることが可能になる。また、通知には性能障害を加えることで、性能障害が発生した場合に、より性能の高いサーバを調達し、切り替えるといった運用が可能になる。例えば、データセンタなどの様々な性能のサーバを保持し提供する環境では、性能障害が発生した場合に、スタンバイするサーバをアップグレードし、より高性能なサーバへ切り替えを実施する運用やサービスが想定される。その場合、予めデータセンタとの契約が必要になると想定されるが、オンデマンドで必要な性能を持ったサーバを調達することで出来るため、利用者はシステムコストを削減することが可能になる。

図１５は、本実施例におけるディスクイメージ配信方式のフェイルオーバーを実現する管理サーバ３０２の制御プログラム１１０の処理フローを示している。

ステップ１５０１で、障害通知受信プログラム３１０が障害通知を受信し、障害通知の発生原因であるサーバを切り離すか否か判定する。切り離す場合、ステップ１５０２へ進む。ステップ１５０２で、ネットワーク設定変更プログラム３１１を起動し、障害が発生した現用サーバ１０２を業務ネットワークから切り離す。

ステップ１５０３で、配信指示プログラム３１２を起動し、再配信または再設定の要否を判定した後、必要に応じて配信実行プログラム３１２などを起動し、再配信および再設定を実行する。

ステップ１５０４で、テスト実行プログラム３１４を起動し、設定確認や動作確認を実施し、正しく再配信または再設定が実施されているか否かを判定する。正しいと判定した場合、次のステップへ進む。誤っていると判定した場合、ステップ１５０３へ戻り、再配信または再設定を実行する。本ステップは、運用上必要ないと管理者が判断する場合や、予めテスト済みのディスクイメージを配信した場合など、割愛可能な場合もある。

ステップ１５０５で、ネットワーク設定変更プログラム３１１を起動し、予備サーバを業務ネットワークへ参加させる。その後、管理テーブル群１１１を更新する。

図１６は、図３の障害通知受信プログラム３１０の処理フローを示している。障害通知受信プログラムは、フェイルオーバーするか否かを判定する機構も持つ。

ステップ１６０１で、障害通知を受信する。この通知には、障害が発生した現用サーバ１０２を識別するサーバ識別子となる値が格納されている。また、障害内容と障害状態を表す値が含まれている。通知は、1度で行うことが望ましいが、ネットワーク負荷などを考慮して、複数回に分けても構わない。また、障害が発生したサーバが予備サーバ１０３でスタンバイ継続が困難な場合は、業務提供サーバ管理テーブル３２４（図９から図１１参照）へ障害発生の旨を記載し、フェイルオーバー先として選択しない。

ステップ１６０２で、障害通知管理テーブル３２８を参照する。

ステップ１６０３で、障害発生の現用サーバをフェイルオーバーするか否かを判定する。フェイルオーバーしない場合は、ステップ１６０４へ進む。フェイルオーバーする場合は、ステップ１６０５へ進む。

ステップ１６０４で、障害通知管理テーブル３２８を更新し、障害通知を待つ最初のステップへ戻る。

ステップ１６０５で、業務提供サーバ管理テーブル３２４の中の障害ステータスを更新し、処理を完了する。

図１７は、図３のネットワーク設定変更プログラム３１１の処理フローを示している。

ステップ１７０１で、現用サーバ１０２を業務ネットワーク構成から切り離す、または予備サーバ１０３を業務ネットワーク構成へ追加するかを判定する。切り離す場合はステップ１７０２へ、追加する場合はステップ１７０３へ進む。
ステップ１７０２で、障害が発生した現用サーバを業務ネットワーク構成から切り離す。切り離す場合、予備のネットワークグループへ追加することになる（図１２カラム１２５７参照）。

ステップ１７０３で予備サーバ１０３を業務ネットワーク構成へ追加する。追加する場合、予備のネットワークグループから障害が発生した現用サーバ１０２が属していた業務ネットワークグループへ追加される（図１２参照）。

図１８Ａは、図３の配信指示プログラム３１２の処理フローを示している。入力情報として、障害が発生した現用サーバが通知される。

ステップ１８０１で、業務提供サーバ管理テーブル３２４を参照する（図９参照）。まず、カラム９０７を参照し、スタンバイ状態の予備サーバの有無を確認し、存在しない場合は、スタンバイ状態の予備サーバがない旨を通知し、全体の処理を終了する。スタンバイ状態の予備サーバ１０３が存在する場合、業務（カラム９０３）を参照し、障害が発生した現用サーバ１０２と同一のディスクイメージが配信されている、または同じ業務のディスクイメージが配信されている、または同じ共通基盤のディスクイメージが配信されている予備サーバの有無を確認する。

同一ディスクイメージが配信されている場合は、ステップ１８０５からステップ１８０７へ進む。同じ業務または同じ共通基盤のディスクイメージが配信されている場合は、ステップ１８０３へ進み、必要な固有情報設定や必要なＰ．Ｐ．に関する情報を収集し、ステップ１８０５からステップ１８０６へ進む。なお、ステップ１８０５での判定の詳細は、後で図１８Ｂを用いて詳述する。

その他の場合は、再配信またはＰ．Ｐ．の追加インストールと固有情報設定が必要なケースである。カラム９０８を参照し、一致条件を参照する。また、予備サーバについて、サーバ識別子（カラム９０１）を参照する。一致条件に従い、続くステップにて必要な情報を収集する。

ステップ１８０２で、ディスクイメージが内包するハードウェアに関する情報テーブル３２３を参照する（図８参照）。障害が発生した現用サーバ１０２のディスクイメージが内包するハードウェア情報（CPUアーキテクチャ（カラム８０２）、HBA枚数（カラム８０４）、NIC枚数（カラム８０８）、ストレージ容量（カラム８１１））を参照し、次に予備サーバに関してハードウェア情報を参照する。CPUアーキテクチャを問わず、特定のサービスを提供さえすれば良い場合には、CPUアーキテクチャ（カラム８０２）が一致しなくても良い。動作実績を重視し、同一のディスクイメージ利用またはＣＰＵアーキテクチャ利用を運用ポリシーとする場合、目的のCPUアーキテクチャを持った予備サーバが存在しないときには、その旨を通知し全体の処理を終了する。また、HBA枚数（カラム８０４）やNIC枚数（カラム８０８）、ストレージ容量（カラム６１１）については、予備サーバ１０３が現用サーバ１０２と同数またはそれ以上を保持していれば問題ない。問題ないことを判定するステップは、ステップ１８０５だが、必要な情報としてステップ１８０３にて、サーバのハードウェア情報管理テーブル３２１（図６参照）から、予備サーバ１０３に関するハードウェア情報を参照する。

ＣＰＵアーキテクチャが一致しなくても、業務サービスレベルで一致すれば良い場合は、業務提供サーバ管理テーブル３２４（図９参照）の一致範囲（カラム９０８）にて、その旨を指定する。この場合、ディスクイメージに格納されているソフトウェアに関するテーブル３２２（図７参照）に指定されているホスト名（カラム７０５）やＩＰ情報（カラム７０７）、Ｐ．Ｐ．固有設定（カラム７０９）を参照し、予備サーバ１０３へ再設定する。再設定はステップ１８０６にて実施する。

ステップ１８０４で、ディスクイメージに格納されているソフトウェアに関するテーブル３２２（図７参照）を参照し、障害が発生した現用サーバ１０２の保持するソフトウェア情報を参照する。予備サーバ１０３に配信されているディスクイメージが業務レベルで一致する場合は、ホスト名（カラム７０５）やＯＳパスワード（カラム７０６）、ＩＰ情報（カラム７０７）、Ｐ．Ｐ．固有情報（カラム７０９）を参照し、ステップ１８０６にて再設定を実施する。共通基盤レベルでディスクイメージが一致する場合は、上記に加えて必要Ｐ．Ｐ．のインストールを実施した上で、Ｐ．Ｐ．固有情報（カラム７０９）を設定する。予備サーバ１０３が、障害が発生した現用サーバ１０２の業務を引き継げる状態にセットアップが完了した時点で、ステップ１８０７へ進む。

ステップ１８０７で、予備サーバの電源をＯｎし、ステップ１８０８へ進む。
ステップ１８０８で、業務の優先順位に関するテーブル３２６を参照する（図１３参照）。

ステップ１８０９で、優先順位の高い業務が予備サーバへ配信された状態を維持できているか否かを判定し、出来ている場合はステップ１８１３へ進み、出来ていない場合はステップ１８１０へ進む。

ステップ１８１０で、配信実行プログラム３１３を起動し、必要な再配信または再設定を実施し予備サーバ１０３を再構成する。

ステップ１８１１で、再構成した予備サーバ１０３の電源をＯｎする。
ステップ１８１２で、テスト実行プログラム３１４を起動し、設定内容の確認や動作確認を実施し、正しく配信または設定が実行されたか否かを判定する。正しく実行された場合は、ステップ１８１３へ進み、誤っている場合はステップ１８１０へ戻り、誤り具合によって再配信または再設定する。

ステップ１８１３にて、業務の優先順位に関するテーブル３２６を更新し、処理を終了する。

予め配信しておくディスクイメージの選定方法について詳述する。
管理者が設定した業務の優先順位に応じて、優先順位の高い業務を配信しておく。
稼動実績に応じて、障害が発生しやすい業務を配信しておく。
稼動実績に応じて、障害が発生しやすいハードウェア特徴（アーキテクチャ、パーツ、ベンダなど）を持つサーバで稼動している業務を配信しておく。
ライセンスが足りない場合、異なるディスクイメージを配信する。ライセンスが足りないソフトウェアを含むディスクイメージは優先順位を下げる。
ライセンスが足りない場合、共通的なディスクイメージを配信する。ライセンスが足りないソフトウェア以外で構成されるディスクイメージを配信する。
過去の負荷変動や障害履歴から、ハードユースされている業務を配信しておく。
障害が発生したサーバと同種のハードウェアで稼動する業務を配信しておく。
障害が発生してフェイルオーバーし、予備サーバで稼動中のサーバの障害再発生確率は、周りの現用サーバよりも低いと考え、フェイルオーバーしたサーバと同一のディスクイメージは配信する優先順位を下げる。
メモリエラーやハードディスクのエラー通知など、すぐには障害ではないものの障害予兆が検出されているサーバまたは業務のディスクイメージを優先的に配信する。
予備サーバに電力消費量が少ないサーバを用意し、電力消費量が多いサーバがもしくは閾値を超える、または超えることが予期されるサーバで稼動している業務のディスクイメージを配信しておく。
などが挙げられる。

予め配信しておくディスクイメージを更新する頻度について詳述する。
定期的な見直し
繁忙期は頻繁に見直す
などが挙げられる。

予め配信しておくディスクイメージを更新する契機について詳述する。
フェイルオーバーが発生し予備サーバが使用された場合
動作テストなどで予備サーバにハードウェアおよびソフトウェア上の不具合が発見された場合
稼働時間などの使用量閾値通知
負荷変動による閾値通知
システムが更新された場合
などが挙げられる。

続いて、先のステップ１８０５における、障害発生時の現用サーバをすぐ引き継げる予備サーバが存在するか否かの判定処理（判定部）について図１８Ｂを用いて詳述する。

まず、ステップ１８２１で、障害が発生した現用サーバ１０２へ配信されているディスクイメージ名と予備サーバ１０３へ配信されているディスクイメージ名が一致するか否かを判定する。一致する場合は、ステップ１８３６へ進み、「変更不要」として処理を完了する。一致しない場合はステップ１８２２へ進む。

ステップ１８２２で、予備サーバ１０３へ配信及び格納されているＰ．Ｐ．と、障害が発生した現用サーバ１０２で提供していた業務が担っていたＰ．Ｐ．と一致するか否かを判定する。一致する場合は、ステップ１８２７に進む。一致しない場合は、ステップ１８３３へ進む。

ステップ１８２７で、ハードウェアやOSが許容設定の範囲内か否かを判定する。範囲内である場合は、ステップ１８２８へ進み、「設定値を再設定」を設定し終了する。範囲内でない場合は、ステップ１８３７へ進む。

ステップ１８３７で、ハードウェアが許容設定の範囲内であるか否かを判定する。範囲内である場合は、ステップ１８２４へ進む。範囲内でない場合は、ステップ１８２６へ進み、「処理を中止」を設定する。「処理を中止」を設定される場合は、フェイルオーバーが不可である条件であることを指している。つまり、要件を満たす予備サーバ１０３が準備されていないことになる。この場合、管理サーバ１０１はGUIへの表示やメール通知、ポケベル通知などで利用者へフェイルオーバーが出来ない旨を理由とともに知らせる機能があれば、ユーザは必要なハードウェアやソフトウェア（ライセンスを含む）を準備することが出きるため、復旧作業を迅速に実施することが出来る。

ステップ１８３３で、予備サーバ１０３へ配信されているP.P.が許容設定の範囲内であるか否かを判定する。範囲内である場合は、ステップ１８３４へ進む。範囲内でない場合は、ステップ１８２３へ進む。

ステップ１８３４で、予備サーバ１０３へ配信されているP.P.やOSに設定されている設定値が、障害が発生した現用サーバ１０２と一致するか否かを判定する。このとき、設定値とはホスト名やIPアドレス、ライセンスのキーなどを指す。一致する場合は、ステップ１８３６へ進み、「変更不要」を設定し処理を終了する。一致しない場合は、ステップ１８３５へ進み、「設定値を再設定」を設定し処理を終了する。

ステップ１８２３で、予備サーバ１０３へ配信されているOSが障害が発生した現用サーバ１０２へ配信されているOSと一致するか否かを判定する。
一致する場合は、ステップ１８２９へ進む。一致しない場合は、ステップ１８２４へ進む。

ステップ１８２９で、コストを評価する。コストとは、OS設定値の再設定や必要P.P.のインストールや設定に必要な時間や手間を指しており、本実施例では特に時間について詳述する。OS設定値を再設定する時間や追加インストールやP.P.設定に必要な時間については、図７のカラム７０９に格納されている。必要なコストを算出し、カラム７１１に格納されている「ディスクイメージ全体を再配信するために必要なコスト」と比較する。本発明が目的とする、高速なフェイルオーバーを実現するためには、このコストが低い方を選択することが重要である。

追加インストールの方が低コストである場合は、ステップ１８３０へ進み、「追加インストールと再設定」を設定し、処理を終了する。追加インストールの方が低コストでない場合は、ステップ１８２４へ進む。

ステップ１８２４で、予備サーバ１０３と障害が発生した現用サーバ１０２のハードウェア情報が一致するか否かを判定する。CPUアーキテクチャやメモリ搭載量だけでなく、Ｉ／Ｏデバイスの数や種類も比較する。一致する場合は、ステップ１８３１へ進み、「合致するディスクイメージを再配信」を設定し、処理を終了する。一致しない場合は、ステップ１８２５へ進む。

ステップ１８２５で、予備サーバ１０２のハードウェア構成が許容設定の範囲内であるか否かを判定する。

範囲内である場合、ステップ１８３２へ進み、「同一業務を提供するディスクイメージを再配信」を設定し、処理を終了する。ステップ１８３１で設定する値との違いは、ステップ１８３１で設定された値によって再配信するディスクイメージは、障害が発生した現用サーバ１０２で使用されているディスクイメージと同じディスクイメージである。それに対し、ステップ１８３２で設定される値によって再配信されるディスクイメージは、ハードウェア構成が異なっていることからCPUアーキテクチャが異なるものの同一業務を提供できるディスクイメージであったり、接続デバイスの性能が異なるものの同一業務を提供できるディスクイメージであったりする。

図１９は、図３の配信実行プログラム３１３の処理フローを示している。
本プログラムは、配信または設定を実行するプログラムであり、実行の要否は前段プログラムによって決定されている。入力は、再配信または再設定の指定、対象となるサーバと業務またはディスクイメージの指定である。

ステップ１９０１で、ディスクイメージに格納されているソフトウェアに関するテーブル３２２を参照（図７参照）し、配信や設定時に必要な値を取得する。

ステップ１９０２で、再配信か否かを判断し、再配信の場合はステップ１９０３へ進み、再配信でない（再設定）場合はステップ１９０４へ進む。

ステップ１９０３で、指定された業務のディスクイメージを予備サーバ１０３へ配信し、ステップ１９０４へ進む。

ステップ１９０４で、再設定か否かを判断し、再設定の場合はステップ１９０５へ進み、再設定でない場合は処理を完了する。ステップ１９０５で、固有情報を再設定する。Ｐ．Ｐ．の追加インストールが必要な場合、インストール後に固有情報を設定する。本ステップ完了後、処理を終了する。

図２０は、図３のテスト実行プログラム３１４の処理フローを示している。

本プログラムは、固有設定が設定すべき値になっているか検査したり、動作が正しいことを検査することを目的としている。本実施例では、設定値が正しいことを検査するプログラムについて詳述する。

ステップ２００１で、サーバおよびＰ．Ｐ．の固有情報設定値を取得する。情報取得方法は、エージェントプログラムをサーバのＯＳ上で稼動させて取得する方法やＣＩＭ（Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）を利用した情報取得方法などがあるが、いかなる方法でも構わない。

ステップ２００２で、ディスクイメージに格納されているソフトウェアに関するテーブル３２２を参照（図７参照）する。

ステップ２００３で、ステップ２００１とステップ２００２で取得または参照した値を比較した後、正誤を判定し処理を終了する。
動作を検証するテストプログラムの場合、業務に即した入力を与え、正常に処理を行った後、正しい結果を出力できるか、処理ログや出力結果を評価する、といった流れになる。

業務参加前、または配信や設定が完了した時点で、テストプログラムを用いて検証を行うことで、予備サーバへフェイルオーバーしたものの、正しく動作せず、ビジネス継続に悪影響を及ぼすことを回避することが出来る。

本実施例の利点として、コールドスタンバイだけでなく、ホットスタンバイで待機することで、従来のように障害発生時にディスクイメージ配信を開始する方式に比べて、更に高速なフェイルオーバーを実現することが可能な点が挙げられる。予め配信しておくこと、そして、予備サーバの構成を状況に応じて再構成する柔軟さによって、実現される。

なお、以上詳述した本実施例において、固有情報である設定値が格納されていないディスクイメージを使う場合は、共通化できるサーバがn台存在する場合に、ディスクイメージを保存するために必要なストレージ容量をほぼ1/nにすることが出来る。増えるデータは、設定情報である。n台分の設定情報は、非常に小さなストレージ容量しか必要としない（数バイトから数キロバイト）ため、設定情報が増えたとしても、ディスクイメージ（数ギガバイトから数十ギガバイト）を共通化する効果は大きい。具体的には、１００台の同一業務提供サーバが現用サーバとして稼動していた場合、１台あたり１０ギガバイトのディスクイメージを擁していたとすると、設定値を固定で持った場合には１０００ギガバイト（１テラバイト）のストレージ容量が必要である。共通化した場合、１０ギガバイトだけでよくなり、９９％のストレージ容量削減が可能である。

また、予備サーバへ、共通化したディスクイメージを配信しておいた場合、多くの現用サーバがフェイルオーバー先として選択することが出来る。設定値を予め設定した場合は、なにも変更をしない状態では1台の現用サーバのフェイルオーバー先にしか成り得ない。しかし、固有情報である設定値を障害発生時に設定または変更することで、複数の現用サーバのフェイルオーバー先となることが可能である。例えば、優先順位の高い現用サーバの設定値を、予備サーバへ設定しておく。障害が他のサーバ（ただし、同一業務）で障害が発生した場合、再配信をすると数十分かかるところを、数十秒の設定変更でフェイルオーバーを実施することが可能になる。再配信にかかる時間を３０分、再設定にかかる時間を６０秒とすれば、９６．７％の高速化を図ることが可能である。

さて、現用サーバが複数存在し、障害が予備サーバ台数を上回って発生する場合、優先順位に基づき、救済する現用サーバおよび業務を選択することができる。同様に、予備サーバが複数ある場合、適切な予備サーバを選択する必要がある。障害発生の現用サーバに格納されているディスクイメージと同じディスクイメージを持つ予備サーバが存在する場合は、同じディスクイメージを格納する予備サーバを選択する。

特に、上記条件を満たす予備サーバが複数台、存在する場合は、現用サーバで提供している業務が優先するパラメータを記載した優先順位テーブルに基づき、予備サーバを選択する。予備サーバの性能に関して範囲指定することで、必要以上の性能を要求することを防止することが出来る。これにより、後から高い性能を必要とする現用サーバで障害が発生したとしても、必要な性能を備えた予備サーバが余っている可能性を高めることが出来る。また、性能の高い予備サーバを譲るために必要な再配信も防ぐことが出来るため、他のサーバを停止させて再配信するような事態も防止出来る効果がある。また、予備サーバ選択の優先順位は、予備サーバ側の状況を反映しても良い。例えば、稼動実績に基づいて選択することで「連続稼動させない」という稼動ポリシーを適用することができ、また逆に「連続稼動＝信頼性が高い」と考えて「稼動を集中させる」という稼動ポリシーを適用することも可能である。また、「隣り合う予備サーバは出来るだけ稼動させない＝離れた予備サーバから稼動させる」稼動ポリシーによって発熱を分散させたり、電力消費の局所化を防止し電力供給量の上限までで稼動させるといった運用が可能になる。優先順位を評価した結果、評価が同一の場合は、どれを選択しても良い。例えば、シリアル番号が最若番のものを選択する方法もある。また、前記のように配置や電力、発熱などに注目した制御も可能である。

上記条件を満たす予備サーバが存在しない場合は、満たす要件を探っていく。例えば、全ての予備サーバのコストを算出したあと、最もコストの低い予備サーバを抽出する。つまり、再配信が必要か否かの判定と同じ動作をしながら、予備サーバを準備するコストが最低の予備サーバを選択する。場合によっては、フェイルオーバーを中止し、ユーザへその旨を通知またはログへ記録するなどのユーザ通知処理を実施する。

図２１は、実施例２のシステムの全体図を示している。実施例１のシステムとの違いは、ストレージ装置が内蔵ハードディスク型からＳＡＮに接続されたストレージサブシステム２１０６に変更されている。ストレージサブシステム２１０６と各サーバ（２１０１、２１０２、２１０３）は、ＮＷ−ＳＷ２１０５によって接続されている。また、ストレージサブシステムを制御するストレージサブシステム管理機構２１２１と管理サーバ２１０１がＮＷ−ＳＷ２１０４を介して接続されている。

管理サーバ２１０１は、ＮＷ−ＳＷ２１０４を介して、現用サーバ２１０２および予備サーバ２１０３と接続されている。現用サーバ２１０２は業務サービスを提供しており、予備サーバ２１０３は現用サーバ２１０２において障害が発生した際に、代わって業務サービスを提供するためのサーバである。管理サーバ２１０１は、現用サーバ２１０２と予備サーバ２１０３を監視する。特に本実施例においては、現用サーバ２１０２において発生する障害通知を監視し、現用サーバにおいて障害が発生したと確認した際に、予備サーバ２１０３において業務サービスを提供することで、ビジネス継続性を高めることを主目的とする。

現用サーバ２１０２および予備サーバ２１０３の起動ディスクは、ストレージサブシステム２１０６内のＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）２１２２であり、ＬＵ２１２２にＯＳや業務サービスを提供するためのミドルウェアやアプリケーションがインストールされている。管理サーバ２１０１はストレージサブシステム２１０６へ接続されており、ＬＵ２１３２内に業務サービスを提供する上で必要なソフトウェアがインストールされたディスクイメージ２１４１が格納されている。特に、ＬＵ群２１３１には、ディスクイメージ２１４１が格納されたＬＵ２１３２の集合とする。

ディスクイメージ２１４１の内容は、先の実施例同様、業務サービスを提供する個々の現用サーバのディスクイメージ、または個々のサーバの固有情報（設定値）が抜けたディスクイメージ、または共通に利用するソフトウェアのみがインストールされているだけのディスクイメージ、などである。現用サーバ２１０２において、障害が発生した際には、障害が発生した現用サーバ２１０２が提供する業務サービスと同様のディスクイメージ２１４１を予備サーバ２１０３へ配信することで、業務サービスを継続することが可能になる。ディスクイメージ２１４１を配信する際、障害が発生した現用サーバ２１０２と全く同じディスクイメージ２１４１を配信することで、配信作業のみを行うことで業務サービスの継続を図ることが出来る。ただし、現用サーバの台数分だけディスクイメージ２１４１を準備する必要があり、ストレージ容量も膨大になる。

それに対し、固有情報が抜けたディスクイメージを利用することで、配信後に固有情報を設定する作業が増えるものの、ディスクイメージ２１４１を業務サービスごとに共通化することが出来る。これにより、ディスクイメージ２１４１を保存するために必要なストレージ容量も削減することが可能になる。更に、共通に利用するソフトウェアのみがインストールされているだけのディスクイメージ２１４１を利用することで、システム内でディスクイメージ２１４１を共有することが可能になる。ただし、ディスクイメージを配信した後に、必要なソフトウェアをインストールしたり、ＯＳやソフトウェアごとの固有情報を設定する作業が増えるため、フェイルオーバーの完全な高速化を図ることはできないが、なにもインストールされていないサーバへインストール作業を実施するよりも遥かに作業量や作業時間の面で優位である。特に、本実施例では、予め予備サーバ２１０３へディスクイメージを配信しておくことで、フェイルオーバー完了までの時間を短縮することを目的としているため、再インストールは出来るだけ回避すべきである。そのため、共通分のみがインストールされているディスクイメージ２１４１を予備サーバへ予め配信しておくことで、再インストールを回避し、より高速にフェイルオーバーを実現することが可能である。

上記のような高速フェイルオーバーを実現するためのプログラム群が制御プログラム１１０である。また、管理テーブル群１１１には、現用サーバ２１０２や予備サーバ２１０３に関する情報テーブルやディスクイメージ２１４１に関する情報テーブル、また業務サービスに関する情報テーブルが格納されている。ここで、ディスクイメージを配信する方法は特定しないため、ＩＰネットワーク経由で実施しても良いし、ストレージネットワークを経由しても良いし、ストレージサブシステム２１０６内のＬＵ間ディスクコピーを利用しても良い。また、管理サーバ２１０１が内蔵ディスクを保持し、内蔵ディスク内にディスクイメージ２１４１を格納する場合も、本実施例の変形例の範囲内である。よって、管理サーバ２１０１とストレージサブシステム２１０６がＮＷ−ＳＷ２１０５を介して接続されていないケースも存在し、内蔵ディスクとＳＡＮ接続が混在するケースも存在する。

図２２は、本実施例の管理サーバ２１０１の一構成例を示している。演算を処理するＣＰＵ２２０１、ＣＰＵ２２０１で演算するプログラムや処理を格納する記憶領域であるメモリ２２０２、ＩＰネットワークを介して通信を行うためのＮＩＣ２２０３、ストレージサブシステム２１０６と通信を行うためのＨＢＡ２２０４、プログラムやデータを格納し保存する記憶領域であるＬＵ２１２２（ストレージサブシステム２１０６内に存在し、ＨＢＡを経由してＮＷ−ＳＷ２１０５を介して管理サーバ２１０１と接続）から構成されている。メモリ２２０２には、図３の構成同様、制御プログラム群１１０および管理テーブル群１１１が格納されている。

制御プログラム１１０（図１５参照）は、先の実施例同様、障害通知受信プログラム３１０（図１６参照）、ネットワーク設定変更プログラム３１１（図１７参照）、配信指示プログラム３１２（図１８参照）、配信実行プログラム３１３（図１９参照）、テスト実行プログラム３１４（図２０参照）から構成される。

管理テーブル群１１１は、先の実施例同様、サーバのハードウェア情報管理テーブル３２１（図６参照）、ディスクイメージに格納されているソフトウェアに関するテーブル３２２（図７参照）、ディスクイメージが内包するハードウェアに関する情報テーブル（図８参照）、業務提供サーバ管理テーブル３２４（図９、図１０、図１１参照）、業務とネットワークに関するテーブル３２５（図１２参照）、業務の優先順位に関するテーブル３２６（図１３参照）、ストレージサブシステムのセキュリティ設定テーブル３２７（図２４参照）、障害通知管理テーブル３２８（図１４参照）などから構成される。

管理サーバ２１０１が受信する障害通知は、管理対象である現用サーバ２１０２や予備サーバ２１０３が持つハードウェアおよびソフトウェアによる監視機構によって実現される。管理サーバ２１０１が内蔵ディスクを保持し、内蔵ディスク内にディスクイメージ２１４１を格納する場合も、本実施例でカバーする範囲である。よって、管理サーバ２１０１とストレージサブシステム２１０６がＮＷ−ＳＷ２１０５を介して接続されていないケースも存在し、内蔵ディスクとＳＡＮ接続が混在するケースも存在する。

図２３は、現用サーバ２１０２および予備サーバ２１０３の構成を述べている。現用サーバ２１０２および予備サーバ２１０３は、演算を処理するＣＰＵ２３０１、ＣＰＵ２３０１で演算するプログラムや処理を格納する記憶領域であるメモリ２３０２、ＩＰネットワークを介して通信を行うためのＮＩＣ２３０３、電源制御を管理サーバ２１０１から実行するためのＢＭＣ２３０４、ストレージサブシステムと通信を行うためのＨＢＡ２３０５から構成されている。現用サーバ２１０２および予備サーバ２１０３の電源ＯｎまたはＯｆｆについてＢＭＣ２３０４を介して実行することが可能である。

現用サーバ２１０２および予備サーバ２１０３と管理サーバ２１０１は、ＮＷ−ＳＷ２１０４を介して接続されている。ＮＩＣ２３０３を介して、現用サーバ２１０２および予備サーバ２１０３で稼動する監視プログラム（記載しない）が管理サーバ２１０１と通信を行い、障害を通知する。前述の監視プログラムによって、現用サーバ２１０２および予備サーバ２１０３の設定や負荷や障害などの状態を監視することが可能である。ＮＩＣ２３０３は、管理用に設けられることもあり、業務で利用するためのＮＩＣは別途設置されることが一般的である。また、ＢＭＣ２３０４を介しても管理サーバ２１０１とネットワーク的に接続されており、ハードウェア的な障害を通知したり、電源Ｏｎや強制的な電源Ｏｆｆをハードウェア的に実施することが可能である。

図２４は、ストレージサブシステムのセキュリティ設定テーブル３２７を詳述している。

カラム２４０１に、ホストグループ名が格納されている。カラム２４０２に、ＷＷＮが格納されている。カラム２４０３に、論理ＬＵが格納されている。カラム２４０４に、カラム２４０３に対応する物理ＬＵが格納されている。カラム２４０５には、ストレージサブシステム２１０５のポート番号が格納されている。

ホストグループに登録されているＷＷＮは、同じグループに登録されているＬＵへのアクセスのみを許可される。つまり、特定サーバ以外は、ＬＵへアクセスすることが禁止されている。

図２５は、管理サーバ２１０１や現用サーバ２１０２および予備サーバ２１０３とＬＵ２１２２との対応付けを行う機能を有するセキュリティ機能の動作を図示している。サーバ１（２５０１）はＨＢＡ１（２５０２）を有し、ＨＢＡ１（２５０２）にはＷＷＮ１（２５０３）が記録されている。サーバ２（２５１１）はＨＢＡ２（２５１２）を有し、ＨＢＡ２（２５１２）にはＷＷＮ２（２５１３）が記録されている。サーバ１（２５０１）とサーバ２（２５１１）はＮＷ−ＳＷ（ネットワークスイッチ）２１０５に接続され、ＮＷ−ＳＷ２１０５からはストレージサブシステム２１０６に接続されている。

セキュリティ機能２５２０によりサーバ１（２５０１）には、物理ディスクＬＵ１０（２５３３）、ＬＵ１１（２５３４）に対応した仮想ディスクＬＵ０（２５３１）、ＬＵ１（２５３２）へアクセスすることができる。一方、サーバ２（２５１１）には、物理ディスクＬＵ２１（２５４３）、ＬＵ２２（２５４４）に対応した仮想ディスクＬＵ０（２５４１）、ＬＵ１（２５４２）へアクセスすることができる。サーバ１（２５０１）から、物理ディスクＬＵ２１（２５４３）やＬＵ２２（２５４４）にアクセスすることはできない。

図２６は、実施例３のシステムの全体図を示している。実施例１との違いは、現用サーバや予備サーバが、仮想化機構２６３１を用いた仮想サーバ２６２２となっている点と、仮想化機構２６３１が持つＩ／Ｏ振分プログラム２６４１によって、差分をストレージサブシステム２６０５内のＬＵ２６５２へ保存することが出来るようになっている点である。これにより、現用サーバで障害が発生した場合、予備サーバで引き継ぐ業務は最新のデータで再開することが可能になる。

管理サーバ２６０１は、ＮＷ−ＳＷ２６０４を介してストレージサブシステム２６０５を管理するストレージサブシステム管理機構２６５１と接続されており、同様にＮＷ−ＳＷ２６０４を介してサーバ２６０３と接続されている。

サーバ２６０３は、演算を処理するＣＰＵ２６２１、ＣＰＵ２６２１で演算するプログラムや処理を格納する記憶領域であるメモリ２６２２、ＩＰネットワークを介して通信を行うためのＮＩＣ２６２５、ストレージサブシステムと通信を行うためのＨＢＡ２６２６、電源制御を管理サーバ２６０１から実行するためのＢＭＣ２６２４、プログラムやデータを格納し保存する記憶領域であるＬＵ２６５２（ストレージサブシステム２６０５内に存在し、ＨＢＡ２６２６を経由してＮＷ−ＳＷ２６０２を介してサーバ２６０３と接続）から構成されている。また、記憶領域としてはストレージ装置２６２３が接続されている。

メモリ２６２２上には、サーバ２６０３の資源（ＣＰＵ、メモリ、Ｉ／Ｏデバイスなど）を共有して使用するためのサーバ仮想化を実現する仮想化機構２６３１が稼動している。仮想化機構２６３１が、サーバ２６０３の資源を分割し、仮想サーバ２６３２へ資源を割り付けている。仮想化機構２６３１内のＩ／Ｏ振分プログラム２６４１は、仮想サーバ２６３２のＩ／Ｏ要求を振り分け、仮想サーバ２６３２が起動したときに使用するディスクと、起動した後の変化分を記憶する差分データディスクに書き込む。起動用のディスクは、ストレージ装置２６２３に格納されていても良いし、ストレージサブシステム２６０５内のＬＵ２６５２に格納されていても良い。ただし、差分データディスクは、ストレージサブシステム２６０５内のＬＵ２６５２に格納されている必要があり、サーバ２６０３以外のサーバや仮想サーバからアクセスが可能（共有可能）であることで、サーバ２６０３や仮想サーバ２６３２に障害が発生し、ディスクイメージ配信型のフェイルオーバーをする際でも、最新のデータで業務を再開することが可能になる。図２６では、内蔵ディスクとＳＡＮに接続されたストレージサブシステムが混在する環境における実施例を示している。

図２７は、図２６におけるストレージ装置２６２３が存在せず、起動用ディスクがストレージサブシステム２７０５内のＬＵ２７５３へ格納されている、実施例３の変形構成例を示している。その他の対応関係は、図２６と図２７の構成が、２６０＊が２７０＊へと対応づくことで示されている。このケースでは、起動ディスクも引き継ぐことが出来るが、ＯＳやソフトウェア障害の場合には、ディスクイメージを配信して復旧する必要がある。

図２８に、図２６の仮想サーバ２６３２の構成を詳述している。演算を処理する仮想ＣＰＵ２８０１、ＣＰＵ２８０１で演算するプログラムや処理を格納する記憶領域である仮想メモリ２８０２、ＩＰネットワークを介して通信を行うための仮想ＮＩＣ２８０３、電源制御を管理サーバ２６０１から実行するための仮想ＢＭＣ２８０４、仮想ストレージ装置２８０５から構成されている。

図２９に、図２７の仮想サーバ２７３２の構成を詳述している。図２８との差は、ストレージとの接続デバイスである。仮想ストレージ装置２８０５に代わり、ストレージサブシステム２７０５と接続するための仮想ＨＢＡ２９０５が接続されている。

演算を処理する仮想ＣＰＵ２９０１、ＣＰＵ２９０１で演算するプログラムや処理を格納する記憶領域である仮想メモリ２９０２、ＩＰネットワークを介して通信を行うための仮想ＮＩＣ２９０３、ストレージサブシステムと通信を行うためのＨＢＡ２９０５、電源制御を管理サーバ２６０１から実行するための仮想ＢＭＣ２９０４から構成されている。

図３０は、本実施例における差分データ管理テーブルを詳述している。

カラム３００１に、サーバ識別子が格納されている。カラム３００２に、仮想サーバ識別子が格納されている。

カラム３００３に、オリジナルボリュームが格納されている。オリジナルボリュームは、ＯＳ起動用のディスクであることもあるし、データが格納されたディスクである場合もある。起動用ディスクかデータ用ディスクかは、カラム３００５へ種別として格納されている。

カラム３００４へは、差分ボリュームが格納されている。本実施例の構成にあっては、フェイルオーバー発生時には、この差分ボリュームを引き継ぐことで、最新の状態で業務を再開することが可能になる。

図３１は、図３に示したライセンス管理テーブル３３０を詳述している。

カラム３１０１には、ライセンス品目が格納されている。カラム３１０２には、ライセンス残数が格納されている。

ライセンス残数を管理することにより、ライセンス数が０になったソフトウェアを含むディスクイメージを予備サーバへ予め配布することは出来ない可能性が高い（ライセンス契約に依存）。そのため、業務の優先順位に関するテーブル３２６内の優先順位（カラム１３０３）を更新する必要が発生する。

以上、種々の実施例に基づき詳述した本発明は、ＳＡＮ接続されているストレージサブシステムの接続方法は、ｉＳＣＳＩであっても同様に適用することが可能である。

１０１…管理サーバ、
１０２…現用サーバ、
１０３…予備サーバ、
１１０…制御プログラム、
１１１…管理テーブル、
１２１、１４０…ディスクイメージ、
１２２、１３２…ストレージ装置、
２０２…業務Ａ、
２０３…業務Ｂ、
２１１…障害通知、
２１２…再配信要否判定、
２１３…電源Ｏｎ、
２１４…業務ネットワークへ追加、
３０１…ＣＰＵ、
３０２…メモリ、
３０４…ＮＩＣ、
３１０…障害通知受信プログラム、
３１１…ネットワーク設定変更プログラム、
３１２…配信指示プログラム、
３１３…配信実行プログラム、
３１４…テスト実行プログラム。

Claims (10)

1. それぞれストレージ装置と処理部を有する、現用サーバと、少なくとも一台の予備サーバと、管理サーバとがネットワークを介して接続されるサーバシステムのサーバ切り替え方法であって、
   前記管理サーバは、
   前記予備サーバに前記現用サーバのディスクイメージを予め配信し、
   前記管理サーバの前記ストレージ装置に、予備サーバに関する情報と、前記ディスクイメージ内のソフトウェア管理情報を保持しており、
   前記管理サーバは、前記現用サーバの障害を受け付けた場合に、障害を受け付けた前記現用サーバの業務を前記予備サーバで実行可能かを判定するときに、
   前記予備サーバに関する情報と前記ソフトウェア管理情報に基づいて、前記現用サーバと前記予備サーバのソフトウェアが持つ設定値が異なるか否かを判定し、前記設定値が異なる場合に、前記予備サーバのソフトウェアの設定値を変更することで、前記現用サーバの業務を前記予備サーバで実行するよう制御する
   サーバ切り替え方法。
2. 請求項１記載のサーバ切り替え方法であって、
   前記管理サーバは、前記予備サーバに前記現用サーバのディスクイメージを予め配信するディスクイメージとして、共通分を事前配信するよう制御する
   サーバ切り替え方法。
3. 請求項１記載のサーバ切り替え方法であって、
   前記管理サーバは、前記予備サーバに前記現用サーバのディスクイメージを予め配信した前記配信後に、前記予備サーバに追加インストールを行うよう制御する
   サーバ切り替え方法。
4. 請求項１記載のサーバ切り替え方法であって、
   前記管理サーバは、障害予兆を検出したら、障害予兆が検出された前記現用サーバもしくは業務のディスクイメージを前記予備サーバに配信するよう制御する
   サーバ切り替え方法。
5. 請求項１記載のサーバ切り替え方法であって、
   前記管理サーバは、障害を受け付けた前記現用サーバをネットワークから切り離し、前記予備サーバに再配信もしくは再設定を行い、再配信もしくは再設定が正しいかを判定し、正しい場合に、前記予備サーバをネットワークに参加させるよう制御する
   サーバ切り替え方法。
6. サーバシステムであって、
   現用サーバと、
   少なくとも１台の予備サーバと、
   管理サーバとがネットワークを介して、前記現用サーバと前記予備サーバに接続される管理サーバとを含み、
   前記現用サーバ、前記予備サーバ、及び前記管理サーバは、それぞれ処理部とストレージ装置を備えており、
   前記管理サーバの前記処理部は、前記現用サーバのディスクイメージを前記予備サーバの前記ストレージ装置に予め配信し、前記管理サーバの前記ストレージ装置に予備サーバに関する情報と、前記ディスクイメージ内のソフトウェア管理情報を保持し、
   前記管理サーバは、前記現用サーバの障害を受け付けたときに、障害を受け付けた前記現用サーバの業務を前記予備サーバで実行可能か判定するとき、前記予備サーバに関する情報と前記ソフトウェア管理情報に基づいて、前記現用サーバと前記予備サーバのソフトウェアが持つ設定値が異なるか否かを判定し、前記設定値が異なる場合に、前記予備サーバのソフトウェアの設定値を変更することで、前記現用サーバの業務を前記予備サーバで実行するよう制御する
   サーバシステム。
7. 請求項６記載のサーバシステムであって、
   前記管理サーバは、前記予備サーバに前記現用サーバのディスクイメージを予め配信するディスクイメージとして、共通分を事前配信するよう制御する
   サーバシステム。
8. 請求項６記載のサーバシステムであって、
   前記管理サーバは、前記予備サーバに前記現用サーバのディスクイメージを予め配信した前記配信後に、前記予備サーバに追加インストールを行うよう制御する
   サーバシステム。
9. 請求項６記載のサーバシステムであって、
   前記管理サーバは、障害予兆を検出したら、障害予兆が検出された前記現用サーバもしくは業務のディスクイメージを前記予備サーバに配信するよう制御する
   サーバシステム。
10. 請求項６記載のサーバシステムであって、
    前記管理サーバは、障害を受け付けた前記現用サーバをネットワークから切り離し、前記予備サーバに再配信もしくは再設定を行い、再配信もしくは再設定が正しいかを判定し、正しい場合に、前記予備サーバをネットワークに参加させるよう制御する
    サーバシステム。

Images