(57)【要約】      （修正有）【課題】仮想化されたサーバ環境であっても、低コストに高信頼化する事である。特に、高信頼化のための交代サーバの台数を少なくすると共に、交代サーバ上のソフトウェアのライセンスを削減する。【解決手段】複数の仮想サーバ２０７が稼働する複数の物理サーバ２０３と、単一の待機系サーバ２０２を具備し、起動中の仮想サーバ２０７を検出する手段と、仮想サーバ２０７を制御する仮想化機構の起動ディスク３１２と物理サーバの対応付けを切り替える手段を有し、物理サーバ障害時に仮想化機構の起動ディスクを交代サーバに接続し直すとともに、障害発生時に起動していた仮想サーバ２０７を自動的に起動する。【選択図】図２
2010211819.tif 000002
【特許請求の範囲】
【請求項１】
それぞれが、複数の仮想サーバを提供するサーバ仮想化機構を実行できる、複数の物理サーバと、前記複数の物理サーバを管理する管理サーバから構成されるサーバシステムの障害回復方法であって、
ここで、待機系の物理サーバでは前記サーバ仮想化機構が稼動しており、
前記管理サーバが、
前記それぞれの物理サーバと、当該それぞれの物理サーバ上で実行される前記サーバ仮想化機構と、当該サーバ仮想化機構上で稼動中の仮想サーバとの対応情報を有し、
前記サーバ仮想化機構の上で稼動中である仮想サーバのメモリイメージのスナップショットを取得してイメージ格納ディスクに格納し、
前記複数の物理サーバのいずれかに障害が発生した場合、当該障害が発生した物理サーバ上の前記サーバ仮想化機構上で稼動中の仮想サーバを、前記対応情報を使用して決定し、
前記決定した仮想サーバのメモリイメージ情報が格納されている前記イメージ格納ディスクを用いて、前記待機系の物理サーバ上で稼動中のサーバ仮想化機構の上に、前記障害が発生した物理サーバ上で稼動していた仮想サーバを起動することを特徴とするサーバシステムの障害回復方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想サーバ環境における障害回復に関する。
【背景技術】
【０００２】
企業の計算機システムやデータセンタにおいて、サーバの保有台数が増大した結果、運用管理コストも増大している。この問題を解決する一つの方法として、サーバの仮想化技術がある。サーバの仮想化技術は、単一の物理サーバ上で複数の仮想サーバを稼働することができる技術である。物理サーバには、プロセッサやメモリといったリソースがあり、サーバの仮想化技術はリソースを分割し、それぞれを異なる仮想的なサーバに割り当てることで単一の物理サーバ上で複数の仮想サーバを同時に実行する。プロセッサの性能向上とメモリなどのリソースが低コスト化したことで、サーバの仮想化技術に関するニーズが増大している。
【０００３】
一方で、システムの高信頼化に関するニーズもますます高くなっている。企業システムの計算機の依存度が大きくなったことで、システムの停止による損害も大きくなったためである。システムを高信頼化する方法として現用系サーバとは別に待機系サーバを用意しておき、現用系サーバに障害が発生した場合には、待機系サーバと交代する技術が一般的である。
【０００４】
サーバの仮想化と高信頼化の２つのニーズの流れから、仮想化されたサーバ環境でありながら高信頼を維持するという技術に対するニーズが生まれるのは自然であると考えられる。しかし、２つの技術はお互いに相反する特性を持っている。例えば、物理サーバ上に複数の仮想サーバを構築した場合、物理サーバに障害が発生するとその上で稼働している全ての仮想サーバが一度に停止してしまう。独立した複数のサーバでシステムが構築されていれば、単一の物理サーバの障害の影響範囲は小さいが、単一の物理サーバに複数のサーバを集約することができる仮想化技術は障害の影響範囲が大きくなってしまう。そのため、仮想化環境では信頼性が低下する傾向がある。また、信頼性の観点で技術を見ると、仮想化されたサーバを複数設け、単一のサーバ障害時に他のサーバに交代する方法が考えられるが、サーバの台数や交代サーバ上のソフトウェアのライセンスなどが必要となり、コストが増加する傾向がある。
【０００５】
特許文献１には、仮想計算機の一つをマスタシステムとして、また仮想計算機の他の一つをマスタシステムに対する待機システムとして用意し、両システム間でデータの同期を取得し、定期的に相互のシステムを切り替える技術が開示される。記載によれば、障害発生により切り替え処理をおこなっても迅速な対応が実現する。
【０００６】
特許文献２には、実計算機上で動作するホストＯＳのもとで構築される複数の仮想計算機の一つを待機系としてサスペンド状態に保持し、現用系障害時に仮想計算機のメモリイメージを待機系に転送することで待機系の仮想計算機の起動を高速化する技術が開示される。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００５−１７３７５１号公報
【特許文献２】特開２００１−２１６１７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が解決しようとする課題は、仮想化されたサーバ環境であっても、低コストに高信頼化する事である。より具体的には、高信頼化のための交代サーバの台数を少なくすると共に、交代サーバ上のソフトウェアのライセンスを削減する事である。また、サーバに障害が発生した際に交代サーバに切り替えるためには、稼働していた仮想サーバを正確に把握しておく必要がある。仮想サーバは、物理サーバと違い、物理サーバのプロセッサやメモリなどのリソースに余裕があれば比較的容易に増減することができる。つまり、物理サーバよりも構成が変更される頻度が高まるため、稼働中の仮想サーバを正確に把握しておかなければ、交代サーバに正しく引き継ぐことができない。
【課題を解決するための手段】
【０００９】
複数の仮想サーバが稼働する複数の物理サーバと、単一の待機系サーバを具備し、起動中の仮想サーバを検出する手段と、仮想サーバを制御する仮想化機構の起動ディスクと物理サーバの対応付けを切り替える手段を有し、物理サーバ障害時に仮想化機構の起動ディスクを交代サーバに接続し直すとともに、障害発生時に起動していた仮想サーバを自動的に起動する。
【発明の効果】
【００１０】
高信頼化のための交代サーバの台数を少なくすると共に、交代サーバ上のソフトウェアのライセンスを削減することができる利点がある。
【図面の簡単な説明】
【００１１】
【図１】本発明の全体構成図を示す。（実施例１）
【図２】実施例１の動作概要を示す。
【図３】サーバ仮想化機構の構成を示す。
【図４】サーバ仮想化機構の制御インターフェースを示す。
【図５】サーバ管理テーブルの構成を示す。
【図６】サーバ仮想化機構管理テーブルの構成を示す。
【図７】仮想サーバ情報取得機構のフローチャートを示す。
【図８】スナップショット取得機構のフローチャートを示す。
【図９】障害回復機構のフローチャートを示す。
【図１０】セキュリティ機構の構成を示す。
【図１１】セキュリティ機構の設定例を示す。
【図１２】仮想サーバ回復機構のフローチャートを示す。
【図１３】本発明の全体構成図を示す。（実施例２）
【図１４】実施例２の動作概要を示す。
【図１５】実施例２の障害回復機構のフローチャートを示す。
【図１６】実施例２の仮想サーバ回復機構のフローチャート示す。
【図１７】実施例３の動作概要を示す。
【図１８】実施例３の障害回復機構のフローチャートを示す。
【図１９】実施例３のサーバ仮想化機構管理テーブルを示す。
【発明を実施するための形態】
【００１２】
サーバの障害時に障害が発生したサーバが使用していたディスクを交代系に引き継ぐと共に、障害発生時に起動していた複数の仮想サーバを自動的に回復する。
【実施例１】
【００１３】
図１は、本発明における実施例の全体図を示している。本実施例で特徴的な制御は、管理サーバ１０１を中心に行われる。管理サーバ１０１は、障害回復機構１０２、スナップショット取得機構１０４、仮想サーバ情報取得機構１０５，仮想サーバ回復機構１０６、サーバ管理テーブル１０３、サーバ仮想化機構管理テーブル１０７から構成される。管理サーバ１０１の管理対象は、ネットワークスイッチ１０８、複数の物理サーバ２０３、ディスクアレイ装置３１０および各物理サーバに配備されたサーバ仮想化機構２０６である。ここで、サーバ仮想化機構２０６は、物理サーバ２０３を複数の仮想サーバに見せかける機能を有している。つまり、単一の物理サーバ２０３に複数のサーバを統合することができる。ディスクアレイ装置３１０は、ストレージスイッチ１１２を介して物理サーバ２０３に接続される。ディスクアレイ装置３１０には、セキュリティ機構３０８に加え、物理サーバ２０３で実行するプログラムが格納されたサーバ仮想化機構起動ディスク３１２や、仮想サーバ２０７で実行されるプログラムが格納された仮想サーバイメージ格納ディスク３１３がある。各物理サーバのサーバ仮想化機構１１０は、その物理サーバに対応するサーバ仮想化機構起動ディスク３１２により起動される。その後、仮想サーバ２０７が仮想サーバイメージ格納ディスク１１５から起動される。本発明における実施例では、物理サーバ２０３のいずれかに障害が発生した場合に、待機系の物理サーバに、障害が発生した物理サーバの上で稼動していた仮想サーバの稼動を切り替える処理が自動的に行われる。
【００１４】
図２は、本発明における実施例の動作を示している。物理サーバ２０３は、複数の物理サーバから構成される現用系サーバ群２０１と、待機系サーバ２０２にあらかじめ分けておく。現用系サーバ群２０１ののうちサーバ仮想化機構２０６が稼働している物理サーバ２０３−１に障害が発生した場合には、障害が発生した物理サーバ２０３−１が使用していたサーバ仮想化機構起動ディスク３１２を待機系の物理サーバ２０３−４に割当て、待機系で再起動する。さらに、サーバ仮想化機構２０６が障害発生前に生成していた仮想サーバ２０７について、仮想サーバイメージ格納ディスク３１３に保存された仮想サーバOSイメージ３１５を使用して仮想サーバのOS（Operating System）２０５の起動も連動して行うため、人手を要せずに仮想サーバの復旧が可能である。ディスクの切替を伴う起動ディスクやデータは、異なる物理サーバに引き継いでも参照・更新が必要であり、いずれの物理サーバからも共有できるディスクアレイ装置３１０に格納しておくことが望ましい。一方、サーバ仮想化機構が稼働せず、物理サーバ上でOS（Operating System）が直接稼働している物理サーバ２０３−３の障害時には、OS起動ディスク３０７を待機系の物理サーバ２０３−４に割当て直して、待機系での再起動を行う。このケースでは、仮想サーバは稼働していないため、仮想サーバに対する制御は行わない。これらの一連の処理を、図１の管理サーバ１０１が自動的に行う。
【００１５】
図３は、サーバ仮想化機構２０６が稼働している物理サーバ２０３の詳細な構成を示している。物理サーバ２０３は、メモリ２２０、プロセッサ２３０、ＦＣＡ（Ｆｉｂｒｅ Ｃｈａｎｎｅｌ Ａｄａｐｔｅｒ）２４０、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）２５０、ＢＭＣ（Ｂａｓｅｂｏａｒｄ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ）２６０から構成される。プロセッサ２３０は、メモリ２２０内に格納された各種プログラムを実行する。ＦＣＡ２４０はディスクアレイ装置３１０と接続される。ＮＩＣ２５０およびＢＭＣ２６０はネットワーク１０９に接続される。ＮＩＣ２５０は、主にメモリ２２０上の各種プログラムとの通信のために使用される。ＢＭＣ３１０は物理サーバの障害などを検知し、ネットワークスイッチ１０８を介して他のサーバと通信するために使用する。本実施例では、ＮＩＣ２５０とＢＭＣ２６０はは同一のネットワークに接続されているが、異なるネットワークに接続しても良い。また、図ではＦＣＡ２４０、ＮＩＣ２５０はそれぞれ一つずつであるが、複数存在しても良い。メモリ２２０上にサーバ仮想化機構２０６を配備して稼働させることで、複数の仮想サーバ２０７を構築することができる。仮想サーバ２０７は、それぞれ独立にＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）２０５を稼働させることができる。サーバ仮想化機構２０６は、物理サーバ起動時にサーバ仮想化機構起動ディスク３１２から読み込まれ、メモリ２２０上にロードされる。プロセッサ２３０によりサーバ仮想化機構２０６が実行されると、仮想サーバ２０７を構築することができる。仮想サーバ２０７は、あらかじめ設定された仮想サーバイメージ格納ディスク３１３内の所定の仮想サーバＯＳイメージ３１５を読み込むことで構築される。仮想サーバ毎に個別に仮想サーバＯＳイメージ３１５を設けておくことで、まったく異なるＯＳやアプリケーションを単一の物理サーバ上で稼働させることができる。制御Ｉ／Ｆ（Ｉｎｔｅｒｆａｃｅ）２２２は、ネットワーク１０９を介して外部からサーバ仮想化機構２０６を制御するためのインターフェースである。外部から制御I/F２２２を介して仮想サーバ２０７の作成や削除などを行うことができる。
【００１６】
図４は、制御Ｉ／Ｆ２２２の代表的な項目を示す。カラム４０１はサーバ仮想化機構２０６の制御Ｉ／Ｆの項目名を示しており、カラム４０２はそれぞれの項目の処理概要を示している。「仮想サーバ生成」では、対象となるサーバ仮想化機構で新規に仮想サーバを生成することができる。「仮想サーバ削除」では、対象となるサーバ仮想化機構の仮想サーバを削除することができる。「仮想サーバ起動」は、対象となるサーバ仮想化機構で、指定された仮想サーバを起動することができる。「仮想サーバ停止」では、対象となるサーバ仮想化機構で、稼働中の仮想サーバを停止することができる。ここで、仮想サーバの起動や停止は物理サーバにおいては、電源のＯＮ／ＯＦＦに相当する処理である。「スナップショット取得」では、対象となるサーバ仮想化機構で稼働中のスナップショットを取得することができる。スナップショットとは、仮想サーバの稼働中の状態をディスクに保存する処理を示し、仮想サーバ上で稼働しているＯＳやアプリケーションなどが動作中のままディスクに保存される。そのため、スナップショットから仮想サーバを起動することで、ＯＳの起動やアプリケーションの起動が必要なく、高速に起動することができる。「スナップショット起動」は、対象となるサーバ仮想化機構で、指定されたスナップショットを用いて、仮想サーバを高速に起動するインターフェースである。「ＶＬＡＮ設定」は、対象となるサーバ仮想化機構で、指定された仮想サーバのネットワークのＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）設定を設定する。これは、複数の仮想サーバが構築された環境において、仮想サーバ間のセキュリティを保つ目的で使用され、例えば仮想サーバ１と仮想サーバ２を異なるＶＬＡＮに属させることで、お互いがネットワーク通信できなくすることができる。「仮想サーバ設定変更」は、対象となるサーバ仮想化機構で、指定された仮想サーバの設定を変更する制御インターフェース項目である。物理サーバのメモリやネットワークやディスクを分割して割り当てることで複数の仮想サーバを構築することができるが、「仮想サーバ設定変更」は仮想サーバ生成後に割当を変更する際に使用される。例えば、仮想サーバの起動ディスクの変更や、ネットワークの追加などである。「仮想サーバ情報取得」は、サーバ仮想化機構で生成された仮想サーバに関する情報や、稼働中の仮想サーバなどの情報を取得することができる。
【００１７】
図５は、サーバ管理テーブル１０３の詳細を示している。サーバ管理テーブル１０３には、物理サーバに関する詳細な情報が格納される。カラム５０１には、物理サーバを特定するための物理サーバ識別子を格納する。カラム５０２は、物理サーバの起動ディスクの格納場所（論理ユニット番号）を格納する。カラム５０３は、ディスクアレイ装置と接続されるＦＣＡ２４０が有する固有の識別子を格納する。カラム５０４は、物理サーバの稼働状態を示すサーバモードである。当該物理サーバでサーバ仮想化機構が稼働しているか否かがカラム５０４で判別できる。カラム５０５には、物理サーバのプロセッサ情報やメモリ容量が格納される。カラム５０６は、物理サーバが有するＮＩＣを識別するためのネットワーク識別子が格納される。複数のＮＩＣが存在する場合は、複数の識別子が格納される。カラム５０６には、ＮＩＣが接続されているネットワークスイッチのポート番号が格納される。これは、物理サーバのネットワークセキュリティを保つ際にネットワークスイッチのＶＬＡＮを設定するために用いられる。カラム５０８には、当該物理サーバに割り当てたディスクの論理ユニット番号が格納される。例では、ＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）１０が複数の物理サーバに記載されているが、これはこれら複数の物理サーバがLUN10を共有することを示している。カラム５０９には、物理サーバ上でサーバ仮想化機構が稼働している場合に、そのサーバ仮想化機構を特定する仮想化機構識別子が格納される。この仮想化機構識別子５０９は、後で述べるサーバ仮想化機構管理テーブルと関連づけられている。カラム５１０は、物理サーバの状態や役割を示しており、例では現用系か待機系かを示す情報が格納されている。本発明における実施例では、現用系のいずれかに障害が発生した場合に待機系に交代する処理を行う際に使用される。
【００１８】
図６は、サーバ仮想化機構管理テーブル１０７の詳細を示している。サーバ仮想化機構管理テーブルは、サーバ仮想化機構に関する詳細な情報が格納される。カラム６０１には、管理サーバ１０１が管理している複数のサーバ仮想化機構を識別するための仮想化機構識別子が格納される。カラム６０２には、サーバ仮想化機構を外部から制御するためのアクセス情報となるネットワークアドレスが格納される。カラム６０３には、仮想サーバがどのＯＳイメージを使用して起動したか、ＯＳイメージの場所が格納されている。カラム６０４は、仮想サーバが現在稼働中かどうかの状態である。カラム６０５には、仮想サーバに割り当てられているプロセッサ量及びメモリ容量が格納される。カラム６０６には、仮想サーバのＮＩＣ識別子と、それに対応する物理サーバが有するＮＩＣとのネットワーク割当が格納される。カラム６０７は、仮想サーバのネットワークのＶＬＡＮ設定が格納される。カラム６０８には、仮想サーバに割り当てられたデータ格納用のイメージファイルの場所が格納される。カラム６０９には、仮想サーバのスナップショットを取得した場合の格納場所が格納される。カラム６０１の仮想化機構識別子は、先に述べたサーバ管理テーブルのカラム５０９の仮想化機構識別子と対応付けられている。そのため、特定の物理サーバに障害が発生した場合に、サーバ管理テーブルを検索することで、障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができるようになる。
【００１９】
図７は、仮想サーバ情報取得機構１０５のフローチャートを示す。仮想サーバ情報取得機構は、サーバ仮想化機構２０６から仮想サーバに関する情報を取得し、サーバ仮想化機構管理テーブル１０７に情報を格納する処理を行う。この処理は、定期的に実行され、常に最新の仮想サーバに関する情報を取得し、サーバ仮想化機構管理テーブル１０７に反映する。また、管理サーバ１０１が管理する全てのサーバ仮想化機構の全ての仮想サーバに関する情報を収集する。ステップ７０１は、サーバ仮想化機構１０７の制御Ｉ／Ｆ２２２の通信アドレスを取得する。ステップ７０２はサーバ仮想化機構管理テーブル１０７のカラム６０４の状態を取得し格納する。ステップ７０３はサーバ仮想化機構管理テーブル１０７のカラム６０５のプロセッサ／メモリに関する情報を取得し格納する。ステップ７０４はサーバ仮想化機構管理テーブル１０７のカラム６０６のネットワーク割当を取得し格納する。ステップ７０５はサーバ仮想化機構管理テーブル１０７のネットワーク設定に関する情報を取得し格納する。ステップ７０６はサーバ仮想化機構管理テーブル１０７のカラム６０８のVLAN設定を取得し格納する。ステップ７０７は、当該サーバ仮想化機構上で稼働する全ての仮想サーバに関する情報を取得したかどうかを判断する。ステップ７０８は、管理サーバ１０１が管理する全てのサーバ仮想化機構に関する情報を取得したかどうかを判断する。これらの処理を定期的に取得することで、現在稼働中の仮想サーバなどの情報を最新に保つことができる。また、本実施例では定期的に実行しているが、他の方法では情報が変更されるとイベントを発行する機能を設け、イベントを受けると仮想サーバ情報取得機構を実行するといった方法も考えられる。
【００２０】
図８は、スナップショット取得機構１０４のフローチャートを示している。スナップショット取得機構は、起動中の仮想サーバのスナップショットを定期的に取得する処理を行う。ステップ８０１はサーバ仮想化機構２０６の制御Ｉ／Ｆ２２２の通信アドレスを取得する。ステップ８０２では、サーバ仮想化機構管理テーブル１０７を検索し、仮想サーバが起動しているかどうかを判別し、起動中であればステップ８０３に移行する。ステップ８０３では、サーバ仮想化機構２０６の制御Ｉ／Ｆ２２２を用いて当該仮想サーバのスナップショットを取得する。取得したスナップショットはディスクアレイ装置３１０内の仮想サーバイメージ格納ディスク３１３内に格納される。ステップ８０４では、スナップショットの格納先をサーバ仮想化機構管理テーブル１０７に格納する。ステップ８０５では、当該サーバ仮想化機構上で稼働する全ての仮想サーバに関する処理を行ったかどうかを判断する。ステップ８０６は、管理サーバ１０１が管理する全てのサーバ仮想化機構に関する処理を行ったかどうかを判断する。これらの処理により、稼働中の仮想サーバのスナップショットを定期的に取得することができ、物理サーバに障害が発生した場合の交代時に最新のスナップショットから起動することができるようになる。
【００２１】
図９は、障害回復機構１０２のフローチャートを示す。前述の仮想サーバ情報取得機構１０５やスナップショット取得機構１０４は、現用系サーバが正常に稼働している時に動作するが、障害回復機構１０２は、物理サーバに障害が発生した場合に起動され、待機系サーバに処理を引き継ぐ制御を行う。ステップ９０１では、障害イベントを検出する。障害イベントは、図３におけるＢＭＣ２６０からネットワーク１０９を介して転送される。障害イベントの内容には、例えば、物理サーバの識別子や、障害の部位などが格納されている。ステップ９０２では、障害が発生した物理サーバ識別子をもとに、サーバ管理テーブル１０３を検索し、障害が発生した物理サーバのテーブルエントリを特定する。ステップ９０３では、障害が発生した物理サーバが使用していたＯＳ起動ディスクを、待機系の物理サーバに割り当てる処理を行う。本処理は、後に図１０、１１を用いて詳細を説明する。ステップ９０４では待機系の物理サーバの電源をＯＮにする。これにより、待機系の物理サーバから、障害が発生した物理サーバのＯＳやアプリケーションが起動される。この時、障害が発生した物理サーバにサーバ仮想化機構が稼働していた場合は、サーバ仮想化機構が自動的に起動される。ステップ９０６では、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、ステップ９０７を実行する。ステップ９０７は、仮想サーバ回復機構を実行する。この処理については後に詳細なフローを用いて説明する。
【００２２】
図１０、図１１は、障害回復機構のステップ９０３におけるＯＳ起動ディスクの交代を行う方法について述べている。ディスクアレイ装置３１０のセキュリティ機構３０８の中のディスクマッピング機構１００２は、物理サーバとディスクアレイ装置３１０内のディスクとのマッピングを制御する機構である。すなわち、ディスクアレイ装置３１０内の特定のディスクを指定された物理サーバからしか参照・更新できないように制御する。具体的には、セキュリティ機能１００１内にディスクマッピングテーブルを有し、この内容を制御することで、物理サーバに割り当てるディスクを制御することができる。ディスクマッピングテーブルのカラム１００３は、サーバ識別子である。サーバ識別子は、サーバ管理テーブル１０３のカラム５０３のサーバ識別子と対応しており、全ての物理サーバからユニークな識別子である。ディスクマッピングテーブルのカラム１００４は、仮想ディスク番号を示している。仮想ディスク番号は物理サーバに対するディスク番号を示している。ディスクマッピングテーブルのカラム１００５は、物理ディスク番号を示している。物理ディスク番号は、ディスクアレイ装置３１０内でユニークなディスク番号である。物理サーバによっては、特定のディスク番号はブートディスク専用といった特別な意味を持つ場合があり、仮想ディスク番号と物理ディスク番号の変換ができる方が管理の柔軟性を高めることができる。図１１は、ディスクの交代を図示している。サーバ１１０１はサーバ識別子ＷＷＮ１を有し、サーバ１１０２はＷＷＮ４を有していた場合、ディスクアレイ装置３１０のセキュリティ機構３０８において、ＷＷＮ１を全てＷＷＮ４に書き換えることでＬＵ０（１１０７）はサーバ１１０１からサーバ１１０２に切り替えることができる。この切替を、ＯＳブートディスクについて実施することで、ＯＳブートを制御することができるようになる。
【００２３】
図１２は、仮想サーバ回復機構１０６のフローチャートを示している。仮想サーバ回復機構１０６は、物理サーバに障害が発生した場合に、物理サーバ上で稼働していた仮想サーバを別の物理サーバ上に回復する処理を行う。ステップ１２０１では、待機系のサーバ仮想化機構が起動するまで待機する。サーバ仮想化機構が起動したかどうかは、サーバ仮想化機構管理テーブル１０７の制御Ｉ／Ｆ通信アドレスに対して、何らかのコマンドを発行し、正しい応答が得られたかどうかといった方法で判断することができる。ステップ１２０２では、障害が発生した物理サーバで稼働していた仮想サーバを求める。これは、サーバ管理テーブルを検索することで障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができる。ステップ１２０３では、ネットワークスイッチのＶＬＡＮを変更する。この処理は、仮想サーバとネットワークスイッチ１０８との連携を意味しており、障害が発生した物理サーバでＶＬＡＮ設定が行われていた場合に、交代した待機系のサーバも同じＶＬＡＮ環境に属するように制御することで、仮想サーバ環境だけでなく仮想サーバのネットワークといった周辺環境の設定も自動化することができる。なお、仮想サーバのＶＬＡＮ設定に関する情報は、サーバ仮想化機構管理テーブル１０７のカラム６０７に記載している。また、このＶＬＡＮに対する仮想サーバと物理サーバの対応もカラム６０６のネットワーク割当で知ることができる。さらに、サーバ管理テーブル１０７を検索することで、ネットワークスイッチ１０８のポートも知ることができるため、ＶＬＡＮの設定変更を自動化することができる。ステップ１２０４では、仮想サーバをスナップショットから起動する。この制御は、図４を用いて説明した制御Ｉ／Ｆの「スナップショット起動」を用いて行う。また、スナップショットは、サーバ仮想化機構管理テーブル１０６のカラム６０９には稼動させた仮想サーバに対応してその仮想サーバのスナップショットの格納場所が記載されており、これを参照することで、起動すべき仮想サーバと、それに対応するスナップショットを知ることができる。これらステップ１２０３、１２０４は、障害発生時に起動していた全ての仮想サーバに対して待機系サーバ上で仮想サーバを回復したことがステップ１２０５で確認されるまで繰り返す。これにより、障害が発生した物理サーバ上で稼働していた仮想サーバを自動的にかつ正確に起動することができるようになる。また、障害が発生した物理サーバ上で、サーバ仮想化機構が稼働していたかどうかを自動的に判別し、サーバ仮想化機構か稼働していた場合は仮想サーバも回復する処理を自動化することができる。また、待機系では、サーバ仮想化機構をあらかじめ用意しておく必要がないため、待機系のソフトウェアライセンスを削減することができる。
【実施例２】
【００２４】
本発明の実施例２の全体図を図１３に示す。実施例１との主な違いは、管理サーバ１５１の障害回復機構１３０１および仮想サーバ回復機構１３０２である。実施例１では、現用系の物理サーバ２０３のうち、いずれか一つの障害を待機系の物理サーバで交代する。実施例２では、サーバ仮想化機構がそれぞれ稼働する複数の物理サーバが障害を起こした場合にも、単一の待機系の物理サーバで回復することができる。
【００２５】
図１４は、動作概要を示している。現用系サーバ群２０１を構成する複数の物理サーバ２０３−１、２０３−２では、それぞれサーバ仮想化機構２０６−１、２０６−２が稼働している。その物理サーバ２０３−１と物理サーバ２０３−２に多重に障害が発生した場合、待機系２０２の物理サーバ２０３−５のサーバ仮想化機構２０６−５で、障害が発生した複数の物理サーバ２０３−１、２０３−２の上で稼働していた仮想サーバ２０７、２０８の全てを２１７、２１８に示すように起動する。その際、最初に障害が発生した物理サーバ２０３−１のサーバ仮想化起動ディスク３１２−１を待機系の物理サーバ２０３−５に割当てる。それ以降に物理サーバに障害が発生したときには、既に物理サーバ２０３−５の上で稼動しているサーバ仮想化機構２０６−５によって仮想サーバを起動する。この制御により、単一の物理サーバで複数の障害に対応することができるようになる。
【００２６】
図１５は、障害回復機構１３０１のフローチャートを示している。ステップ１５０１の障害イベント検出、及びステップ１５０２の障害が発生した物理サーバの検索は図５で説明した実施例１のステップ５０１およびステップ５０２とそれぞれ全く同様である。つぎのステップ１５０３では、物理サーバの多重障害を検出する。これは、例えば、サーバ管理テーブルの状態に障害状態を付加し、既に障害が発生していたかどうかを検知することで実現することができる。多重障害の場合は、ステップ１５０８を実行する。ステップ１５０８では、物理サーバのプロセッサやメモリなどのリソースが不足していないかどうか判断する。これは、多数の仮想サーバを生成した場合に、リソースの不足で仮想サーバの処理性能が低下したり、仮想サーバが生成できないといった事を避けるためである。リソースが不足している場合は、ステップ１５０９にて、新たな待機系を割り当てて、ステップ１５０４に進む。そうでなければ、ステップ１５０６に進む。ステップ１５０４では、障害が発生した物理サーバが使用していたＯＳ起動ディスクを、上記の新たな待機系の物理サーバに割り当てる処理を行う。ステップ１５０５では待機系の物理サーバの電源をＯＮにする。これにより、待機系の物理サーバ上に障害が発生した物理サーバのＯＳやアプリケーションが起動される。この時、障害が発生した物理サーバにサーバ仮想化機構が稼働していた場合は、サーバ仮想化機構が自動的に起動される。ステップ１５０６は、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、ステップ１５０７を実行する。ステップ１５０７では、仮想サーバ回復機構を実行する。この処理については後に詳細なフローを用いて説明する。 以上のフローにより、複数の物理サーバで多重に障害が起こった場合にも、すでに回復のために起動した物理サーバにリソース不足がない限り、障害に対する回復処理が単一の物理サーバにより行われる。
【００２７】
図１６は、仮想サーバ回復機構１３０２のフローチャートを示す。仮想サーバ回復機構は、物理サーバに障害が発生した場合に、物理サーバ上で稼働していた仮想サーバを回復する処理を行う。ステップ１６０１は、物理サーバの多重障害かどうかを検知する。方法は図１５におけるステップ１５０３と同じである。多重障害と検知した場合には、ステップ１６０７に移り、仮想サーバのネットワーク割り当てを変更する。これは、複数のサーバ仮想化機構で稼働する仮想サーバのネットワークセキュリティを確保する処理である。複数のサーバ仮想化機構を用いた場合、そこで稼働する仮想サーバは異なる業務を実行していることも考えられる。そういった場合、現用系の環境において、既に異なるＶＬＡＮに設定されているケースがある。複数の異なる環境を一つのサーバ仮想化機構に集約するため、サーバ仮想化機構の中で異なるＶＬＡＮに分離する必要がある。本ステップでは、現用系と同じネットワーク環境になるように設定を自動化する処理を行う。ステップ１６０２は、待機系のサーバ仮想化機構が起動するまで待機する。サーバ仮想化機構が起動したかどうかは、サーバ仮想化機構管理テーブルの制御Ｉ／Ｆ通信アドレスに対して、何らかのコマンドを発行し、正しい応答が得られたかどうかといった方法で判断することができる。ステップ１６０３は、障害が発生した物理サーバで稼働してた仮想サーバを求める。これは、サーバ管理テーブルを検索することで障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができる。ステップ１６０４は、ネットワークスイッチ１０８のＶＬＡＮを変更し、待機系のサーバが、障害が発生した物理サーバと同じＶＬＡＮ環境に属するようにする。次にステップ１６０５では、仮想サーバをスナップショットから起動する。これらのステップは図１２で説明した実施例１の仮想サーバ回復機構１０６の動作フロー中のステップ１２０４〜１２０５と全く同様である。障害発生時に起動していた全ての仮想サーバに対して待機系の物理サーバ上で仮想サーバを回復したことがステップ１６０５で確認されるまでステップ１６０４〜１６０５を繰り返すのも実施例１と同様である。これにより、障害が発生した物理サーバ上で稼働していた仮想サーバを自動的にかつ正確に起動することができるようになると共に、物理サーバの多重障害時にも単一の物理サーバで回復することができるようになり可用性が向上する。また、待機系では、サーバ仮想化機構をあらかじめ用意しておく必要がないため、待機系のソフトウェアライセンスを削減することができる。
【実施例３】
【００２８】
本発明の実施例３は、サーバ仮想化機構を有する物理サーバとサーバ仮想化機構を持たない物理サーバの障害に対し、いずれの障害が先であるかにかかわらずが、待機系の単一の物理サーバで回復を行うことができるシステムである。
実施例３の全体のシステム構成は図１に示す実施例１のシステム構成とどうようである。またその物理サーバ２０３の構成も図３に示すものと変わりがない。図１７は実施例３の動作概要を示すブロック構成図である。
【００２９】
待機系２０２の物理サーバ２０３−６には、あらかじめサーバ仮想化機構２０６−６を用意しておく。サーバ仮想化機構起動ディスク３１２−６はサーバ仮想化機構２０６−６をあらかじめ起動しておくために用いる。物理サーバ２０３−３の障害時にその物理サーバ２０３−３で稼働していたＯＳ２０４を、待機系の仮想サーバ２１９として起動する。またサーバ仮想化機構２０６−１を有する物理サーバ２０３−１の障害時には、仮想サーバイメージ格納ディスク３１３上の仮想サーバＯＳイメージを用い、物理サーバ２０３−１の上で稼動していた仮想サーバ２０７を回復する仮想サーバ２１７を起動する。これにより、物理サーバ１７０９でサーバ仮想化機構が起動しているかどうかに関係なく、かつ、多重障害時にも単一の物理サーバに交代することができる。
【００３０】
図１８は、実施例３の障害回復機構のフローチャートを示す。ステップ１８０１は、障害イベントを検出する。障害イベントは、ＢＭＣ２６０（図３を参照）からネットワークを介して転送される。障害イベントの内容には、例えば、物理サーバの識別子や、障害の部位などが格納されている。ステップ１８０２では、障害が発生した物理サーバ識別子をもとに、サーバ管理テーブルを検索し、障害が発生した物理サーバのテーブルエントリを特定する。ステップ１８０３では物理サーバの多重障害を検出する。これは、例えば、サーバ管理テーブルの状態に障害状態を付加し、既に障害が発生していたかどうかを検知することで実現することができる。多重障害の場合は、ステップ１８０７を実行する。ステップ１８０７では、物理サーバのプロセッサやメモリなどのリソースが不足していないかどうか判断する。これは、多数の仮想サーバを生成した場合に、リソースの不足で仮想サーバの処理性能が低下したり、仮想サーバが生成できないといった事を避けるためである。リソースが不足している場合は、ステップ１８０８にて、新たな待機系を割り当てて、ステップ１８０４に進む。そうでなければ、ステップ１８０５に進む。ステップ１８０４では、待機系の物理サーバ２０３−６の電源をＯＮにする。これにより、待機系のサーバ仮想化機構２０６−６が起動する。ステップ１８０５では、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。基本モードで起動中の物理サーバに障害が発生した場合はステップ１８０９にて、起動ディスクを仮想サーバＯＳイメージに変換し、仮想サーバイメージ格納ディスク３１３に格納する。この変換は、基本的にはＯＳが格納されたディスクを仮想サーバが読み込める形式に変換することである。場合によっては、ハードウェアに依存するＯＳのドライバ等を入れ替えることも行う。つぎにステップ１８０６に進む。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、上記ステップ１８０９を経ずに直接ステップ１８０６に進む。ステップ１８０９では、実施例１と同様に仮想サーバ回復機構１０６の動作によって仮想サーバを待機系物理サーバ２０３−６上に仮想サーバを起動する。その詳細は図１２を用いて説明したとおりでる。
【００３１】
図１９は、実施例３におけるサーバ仮想化機構管理テーブルを示す。実施例３のサーバ仮想化機構管理テーブルは、図６に示した実施例１のサーバ仮想化機構管理テーブル１０６と全く同じカラム構成を持つ。すなわち、カラム６０１にはサーバ仮想化機構を識別する仮想化機構識別子が、カラム６０２には制御Ｉ／Ｆのネットワークアドレスが、カラム６０３には仮想サーバＯＳイメージの格納場所が、カラム６０４には仮想サーバが現在稼働中かどうかを示す状態が、カラム６０５には仮想サーバに割り当てられているプロセッサ量やメモリ容量がそれぞれ格納される。カラム６０６には仮想サーバのＮＩＣ識別子と、それに対応する物理サーバが有するＮＩＣとの割当情報が格納され、カラム６０７には仮想サーバのネットワークのＶＬＡＮ設定に関する情報が格納される。カラム６０８には仮想サーバに割り当てられたデータ格納用のイメージファイルの場所が格納される。カラム６０９にはスナップショット格納先が格納される。実施例３では、待機系にあらかじめサーバ仮想化機構２０６−６を稼働させておく。そのため、サーバ仮想化機構管理テーブル１０７には、この２０６−６に対応した「サーバ仮想化機構３」の詳細情報が予め格納されたテーブルとなっている。
以上により、実施例３では物理サーバでサーバ仮想化機構が起動しているかどうかに関係なく、かつ、多重障害時にも単一の物理サーバに交代することができる。
【産業上の利用可能性】
【００３２】
システムを他の物理サーバに移行する手段としても使用することができる。
【符号の説明】
【００３３】
１０１ 管理サーバ
１０２ 障害回復機構
１０３ サーバ管理テーブル
１０４ スナップショット取得機構
１０５ 仮想サーバ情報取得機構
１０６ 仮想サーバ回復機構
１０７ サーバ仮想化機構管理テーブル
１０８ ネットワークスイッチ
１１２ ストレージスイッチ
２０３ 物理サーバ
２０６ サーバ仮想化機構
２０７ 仮想サーバ  
３０８ セキュリティ機構
３１０ ディスクアレイ装置
３１２ サーバ仮想化機構起動ディスク
３１３ 仮想サーバイメージ格納ディスク
【図１】
2010211819.tif 000003
【図２】
2010211819.tif 000004
【図３】
2010211819.tif 000005
【図４】
2010211819.tif 000006
【図５】
2010211819.tif 000007
【図６】
2010211819.tif 000008
【図７】
2010211819.tif 000009
【図８】
2010211819.tif 000010
【図９】
2010211819.tif 000011
【図１０】
2010211819.tif 000012
【図１１】
2010211819.tif 000013
【図１２】
2010211819.tif 000014
【図１３】
2010211819.tif 000015
【図１４】
2010211819.tif 000016
【図１５】
2010211819.tif 000017
【図１６】
2010211819.tif 000018
【図１７】
2010211819.tif 000019
【図１８】
2010211819.tif 000020
【図１９】
2010211819.tif 000021