JP4780237B2 - 障害回復方法 - Google Patents

障害回復方法 Download PDF

Info

Publication number
JP4780237B2
JP4780237B2 JP2010100478A JP2010100478A JP4780237B2 JP 4780237 B2 JP4780237 B2 JP 4780237B2 JP 2010100478 A JP2010100478 A JP 2010100478A JP 2010100478 A JP2010100478 A JP 2010100478A JP 4780237 B2 JP4780237 B2 JP 4780237B2
Authority
JP
Japan
Prior art keywords
server
virtual
physical
virtualization mechanism
failure
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
JP2010100478A
Other languages
English (en)
Other versions
JP2010211819A (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2010100478A priority Critical patent/JP4780237B2/ja
Publication of JP2010211819A publication Critical patent/JP2010211819A/ja
Application granted granted Critical
Publication of JP4780237B2 publication Critical patent/JP4780237B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Hardware Redundancy (AREA)

Description

本発明は、仮想サーバ環境における障害回復に関する。
企業の計算機システムやデータセンタにおいて、サーバの保有台数が増大した結果、運用管理コストも増大している。この問題を解決する一つの方法として、サーバの仮想化技術がある。サーバの仮想化技術は、単一の物理サーバ上で複数の仮想サーバを稼働することができる技術である。物理サーバには、プロセッサやメモリといったリソースがあり、サーバの仮想化技術はリソースを分割し、それぞれを異なる仮想的なサーバに割り当てることで単一の物理サーバ上で複数の仮想サーバを同時に実行する。プロセッサの性能向上とメモリなどのリソースが低コスト化したことで、サーバの仮想化技術に関するニーズが増大している。
一方で、システムの高信頼化に関するニーズもますます高くなっている。企業システムの計算機の依存度が大きくなったことで、システムの停止による損害も大きくなったためである。システムを高信頼化する方法として現用系サーバとは別に待機系サーバを用意しておき、現用系サーバに障害が発生した場合には、待機系サーバと交代する技術が一般的である。
サーバの仮想化と高信頼化の2つのニーズの流れから、仮想化されたサーバ環境でありながら高信頼を維持するという技術に対するニーズが生まれるのは自然であると考えられる。しかし、2つの技術はお互いに相反する特性を持っている。例えば、物理サーバ上に複数の仮想サーバを構築した場合、物理サーバに障害が発生するとその上で稼働している全ての仮想サーバが一度に停止してしまう。独立した複数のサーバでシステムが構築されていれば、単一の物理サーバの障害の影響範囲は小さいが、単一の物理サーバに複数のサーバを集約することができる仮想化技術は障害の影響範囲が大きくなってしまう。そのため、仮想化環境では信頼性が低下する傾向がある。また、信頼性の観点で技術を見ると、仮想化されたサーバを複数設け、単一のサーバ障害時に他のサーバに交代する方法が考えられるが、サーバの台数や交代サーバ上のソフトウェアのライセンスなどが必要となり、コストが増加する傾向がある。
特許文献1には、仮想計算機の一つをマスタシステムとして、また仮想計算機の他の一つをマスタシステムに対する待機システムとして用意し、両システム間でデータの同期を取得し、定期的に相互のシステムを切り替える技術が開示される。記載によれば、障害発生により切り替え処理をおこなっても迅速な対応が実現する。
特許文献2には、実計算機上で動作するホストOSのもとで構築される複数の仮想計算機の一つを待機系としてサスペンド状態に保持し、現用系障害時に仮想計算機のメモリイメージを待機系に転送することで待機系の仮想計算機の起動を高速化する技術が開示される。
特開2005−173751号公報 特開2001−216171号公報
本発明が解決しようとする課題は、仮想化されたサーバ環境であっても、低コストに高信頼化する事である。より具体的には、高信頼化のための交代サーバの台数を少なくすると共に、交代サーバ上のソフトウェアのライセンスを削減する事である。また、サーバに障害が発生した際に交代サーバに切り替えるためには、稼働していた仮想サーバを正確に把握しておく必要がある。仮想サーバは、物理サーバと違い、物理サーバのプロセッサやメモリなどのリソースに余裕があれば比較的容易に増減することができる。つまり、物理サーバよりも構成が変更される頻度が高まるため、稼働中の仮想サーバを正確に把握しておかなければ、交代サーバに正しく引き継ぐことができない。
複数の仮想サーバが稼働する複数の物理サーバと、単一の待機系サーバを具備し、起動中の仮想サーバを検出する手段と、仮想サーバを制御する仮想化機構の起動ディスクと物理サーバの対応付けを切り替える手段を有し、物理サーバ障害時に仮想化機構の起動ディスクを交代サーバに接続し直すとともに、障害発生時に起動していた仮想サーバを自動的に起動する。
高信頼化のための交代サーバの台数を少なくすると共に、交代サーバ上のソフトウェアのライセンスを削減することができる利点がある。
本発明の全体構成図を示す。(実施例1) 実施例1の動作概要を示す。 サーバ仮想化機構の構成を示す。 サーバ仮想化機構の制御インターフェースを示す。 サーバ管理テーブルの構成を示す。 サーバ仮想化機構管理テーブルの構成を示す。 仮想サーバ情報取得機構のフローチャートを示す。 スナップショット取得機構のフローチャートを示す。 障害回復機構のフローチャートを示す。 セキュリティ機構の構成を示す。 セキュリティ機構の設定例を示す。 仮想サーバ回復機構のフローチャートを示す。 本発明の全体構成図を示す。(実施例2) 実施例2の動作概要を示す。 実施例2の障害回復機構のフローチャートを示す。 実施例2の仮想サーバ回復機構のフローチャート示す。 実施例3の動作概要を示す。 実施例3の障害回復機構のフローチャートを示す。 実施例3のサーバ仮想化機構管理テーブルを示す。
サーバの障害時に障害が発生したサーバが使用していたディスクを交代系に引き継ぐと共に、障害発生時に起動していた複数の仮想サーバを自動的に回復する。
図1は、本発明における実施例の全体図を示している。本実施例で特徴的な制御は、管理サーバ101を中心に行われる。管理サーバ101は、障害回復機構102、スナップショット取得機構104、仮想サーバ情報取得機構105,仮想サーバ回復機構106、サーバ管理テーブル103、サーバ仮想化機構管理テーブル107から構成される。管理サーバ101の管理対象は、ネットワークスイッチ108、複数の物理サーバ203、ディスクアレイ装置310および各物理サーバに配備されたサーバ仮想化機構206である。ここで、サーバ仮想化機構206は、物理サーバ203を複数の仮想サーバに見せかける機能を有している。つまり、単一の物理サーバ203に複数のサーバを統合することができる。ディスクアレイ装置310は、ストレージスイッチ112を介して物理サーバ203に接続される。ディスクアレイ装置310には、セキュリティ機構308に加え、物理サーバ203で実行するプログラムが格納されたサーバ仮想化機構起動ディスク312や、仮想サーバ207で実行されるプログラムが格納された仮想サーバイメージ格納ディスク313がある。各物理サーバのサーバ仮想化機構110は、その物理サーバに対応するサーバ仮想化機構起動ディスク312により起動される。その後、仮想サーバ207が仮想サーバイメージ格納ディスク115から起動される。本発明における実施例では、物理サーバ203のいずれかに障害が発生した場合に、待機系の物理サーバに、障害が発生した物理サーバの上で稼動していた仮想サーバの稼動を切り替える処理が自動的に行われる。
図2は、本発明における実施例の動作を示している。物理サーバ203は、複数の物理サーバから構成される現用系サーバ群201と、待機系サーバ202にあらかじめ分けておく。現用系サーバ群201ののうちサーバ仮想化機構206が稼働している物理サーバ203−1に障害が発生した場合には、障害が発生した物理サーバ203−1が使用していたサーバ仮想化機構起動ディスク312を待機系の物理サーバ203−4に割当て、待機系で再起動する。さらに、サーバ仮想化機構206が障害発生前に生成していた仮想サーバ207について、仮想サーバイメージ格納ディスク313に保存された仮想サーバOSイメージ315を使用して仮想サーバのOS(Operating System)205の起動も連動して行うため、人手を要せずに仮想サーバの復旧が可能である。ディスクの切替を伴う起動ディスクやデータは、異なる物理サーバに引き継いでも参照・更新が必要であり、いずれの物理サーバからも共有できるディスクアレイ装置310に格納しておくことが望ましい。一方、サーバ仮想化機構が稼働せず、物理サーバ上でOS(Operating System)が直接稼働している物理サーバ203−3の障害時には、OS起動ディスク307を待機系の物理サーバ203−4に割当て直して、待機系での再起動を行う。このケースでは、仮想サーバは稼働していないため、仮想サーバに対する制御は行わない。これらの一連の処理を、図1の管理サーバ101が自動的に行う。
図3は、サーバ仮想化機構206が稼働している物理サーバ203の詳細な構成を示している。物理サーバ203は、メモリ220、プロセッサ230、FCA(Fibre Channel Adapter)240、NIC(Network Interface Card)250、BMC(Baseboard Management Controller)260から構成される。プロセッサ230は、メモリ220内に格納された各種プログラムを実行する。FCA240はディスクアレイ装置310と接続される。NIC250およびBMC260はネットワーク109に接続される。NIC250は、主にメモリ220上の各種プログラムとの通信のために使用される。BMC310は物理サーバの障害などを検知し、ネットワークスイッチ108を介して他のサーバと通信するために使用する。本実施例では、NIC250とBMC260はは同一のネットワークに接続されているが、異なるネットワークに接続しても良い。また、図ではFCA240、NIC250はそれぞれ一つずつであるが、複数存在しても良い。メモリ220上にサーバ仮想化機構206を配備して稼働させることで、複数の仮想サーバ207を構築することができる。仮想サーバ207は、それぞれ独立にOS(Operating System)205を稼働させることができる。サーバ仮想化機構206は、物理サーバ起動時にサーバ仮想化機構起動ディスク312から読み込まれ、メモリ220上にロードされる。プロセッサ230によりサーバ仮想化機構206が実行されると、仮想サーバ207を構築することができる。仮想サーバ207は、あらかじめ設定された仮想サーバイメージ格納ディスク313内の所定の仮想サーバOSイメージ315を読み込むことで構築される。仮想サーバ毎に個別に仮想サーバOSイメージ315を設けておくことで、まったく異なるOSやアプリケーションを単一の物理サーバ上で稼働させることができる。制御I/F(Interface)222は、ネットワーク109を介して外部からサーバ仮想化機構206を制御するためのインターフェースである。外部から制御I/F222を介して仮想サーバ207の作成や削除などを行うことができる。
図4は、制御I/F222の代表的な項目を示す。カラム401はサーバ仮想化機構206の制御I/Fの項目名を示しており、カラム402はそれぞれの項目の処理概要を示している。「仮想サーバ生成」では、対象となるサーバ仮想化機構で新規に仮想サーバを生成することができる。「仮想サーバ削除」では、対象となるサーバ仮想化機構の仮想サーバを削除することができる。「仮想サーバ起動」は、対象となるサーバ仮想化機構で、指定された仮想サーバを起動することができる。「仮想サーバ停止」では、対象となるサーバ仮想化機構で、稼働中の仮想サーバを停止することができる。ここで、仮想サーバの起動や停止は物理サーバにおいては、電源のON/OFFに相当する処理である。「スナップショット取得」では、対象となるサーバ仮想化機構で稼働中のスナップショットを取得することができる。スナップショットとは、仮想サーバの稼働中の状態をディスクに保存する処理を示し、仮想サーバ上で稼働しているOSやアプリケーションなどが動作中のままディスクに保存される。そのため、スナップショットから仮想サーバを起動することで、OSの起動やアプリケーションの起動が必要なく、高速に起動することができる。「スナップショット起動」は、対象となるサーバ仮想化機構で、指定されたスナップショットを用いて、仮想サーバを高速に起動するインターフェースである。「VLAN設定」は、対象となるサーバ仮想化機構で、指定された仮想サーバのネットワークのVLAN(Virtual LAN)設定を設定する。これは、複数の仮想サーバが構築された環境において、仮想サーバ間のセキュリティを保つ目的で使用され、例えば仮想サーバ1と仮想サーバ2を異なるVLANに属させることで、お互いがネットワーク通信できなくすることができる。「仮想サーバ設定変更」は、対象となるサーバ仮想化機構で、指定された仮想サーバの設定を変更する制御インターフェース項目である。物理サーバのメモリやネットワークやディスクを分割して割り当てることで複数の仮想サーバを構築することができるが、「仮想サーバ設定変更」は仮想サーバ生成後に割当を変更する際に使用される。例えば、仮想サーバの起動ディスクの変更や、ネットワークの追加などである。「仮想サーバ情報取得」は、サーバ仮想化機構で生成された仮想サーバに関する情報や、稼働中の仮想サーバなどの情報を取得することができる。
図5は、サーバ管理テーブル103の詳細を示している。サーバ管理テーブル103には、物理サーバに関する詳細な情報が格納される。カラム501には、物理サーバを特定するための物理サーバ識別子を格納する。カラム502は、物理サーバの起動ディスクの格納場所(論理ユニット番号)を格納する。カラム503は、ディスクアレイ装置と接続されるFCA240が有する固有の識別子を格納する。カラム504は、物理サーバの稼働状態を示すサーバモードである。当該物理サーバでサーバ仮想化機構が稼働しているか否かがカラム504で判別できる。カラム505には、物理サーバのプロセッサ情報やメモリ容量が格納される。カラム506は、物理サーバが有するNICを識別するためのネットワーク識別子が格納される。複数のNICが存在する場合は、複数の識別子が格納される。カラム506には、NICが接続されているネットワークスイッチのポート番号が格納される。これは、物理サーバのネットワークセキュリティを保つ際にネットワークスイッチのVLANを設定するために用いられる。カラム508には、当該物理サーバに割り当てたディスクの論理ユニット番号が格納される。例では、LUN(Logical Unit Number)10が複数の物理サーバに記載されているが、これはこれら複数の物理サーバがLUN10を共有することを示している。カラム509には、物理サーバ上でサーバ仮想化機構が稼働している場合に、そのサーバ仮想化機構を特定する仮想化機構識別子が格納される。この仮想化機構識別子509は、後で述べるサーバ仮想化機構管理テーブルと関連づけられている。カラム510は、物理サーバの状態や役割を示しており、例では現用系か待機系かを示す情報が格納されている。本発明における実施例では、現用系のいずれかに障害が発生した場合に待機系に交代する処理を行う際に使用される。
図6は、サーバ仮想化機構管理テーブル107の詳細を示している。サーバ仮想化機構管理テーブルは、サーバ仮想化機構に関する詳細な情報が格納される。カラム601には、管理サーバ101が管理している複数のサーバ仮想化機構を識別するための仮想化機構識別子が格納される。カラム602には、サーバ仮想化機構を外部から制御するためのアクセス情報となるネットワークアドレスが格納される。カラム603には、仮想サーバがどのOSイメージを使用して起動したか、OSイメージの場所が格納されている。カラム604は、仮想サーバが現在稼働中かどうかの状態である。カラム605には、仮想サーバに割り当てられているプロセッサ量及びメモリ容量が格納される。カラム606には、仮想サーバのNIC識別子と、それに対応する物理サーバが有するNICとのネットワーク割当が格納される。カラム607は、仮想サーバのネットワークのVLAN設定が格納される。カラム608には、仮想サーバに割り当てられたデータ格納用のイメージファイルの場所が格納される。カラム609には、仮想サーバのスナップショットを取得した場合の格納場所が格納される。カラム601の仮想化機構識別子は、先に述べたサーバ管理テーブルのカラム509の仮想化機構識別子と対応付けられている。そのため、特定の物理サーバに障害が発生した場合に、サーバ管理テーブルを検索することで、障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができるようになる。
図7は、仮想サーバ情報取得機構105のフローチャートを示す。仮想サーバ情報取得機構は、サーバ仮想化機構206から仮想サーバに関する情報を取得し、サーバ仮想化機構管理テーブル107に情報を格納する処理を行う。この処理は、定期的に実行され、常に最新の仮想サーバに関する情報を取得し、サーバ仮想化機構管理テーブル107に反映する。また、管理サーバ101が管理する全てのサーバ仮想化機構の全ての仮想サーバに関する情報を収集する。ステップ701は、サーバ仮想化機構107の制御I/F222の通信アドレスを取得する。ステップ702はサーバ仮想化機構管理テーブル107のカラム604の状態を取得し格納する。ステップ703はサーバ仮想化機構管理テーブル107のカラム605のプロセッサ/メモリに関する情報を取得し格納する。ステップ704はサーバ仮想化機構管理テーブル107のカラム606のネットワーク割当を取得し格納する。ステップ705はサーバ仮想化機構管理テーブル107のネットワーク設定に関する情報を取得し格納する。ステップ706はサーバ仮想化機構管理テーブル107のカラム608のVLAN設定を取得し格納する。ステップ707は、当該サーバ仮想化機構上で稼働する全ての仮想サーバに関する情報を取得したかどうかを判断する。ステップ708は、管理サーバ101が管理する全てのサーバ仮想化機構に関する情報を取得したかどうかを判断する。これらの処理を定期的に取得することで、現在稼働中の仮想サーバなどの情報を最新に保つことができる。また、本実施例では定期的に実行しているが、他の方法では情報が変更されるとイベントを発行する機能を設け、イベントを受けると仮想サーバ情報取得機構を実行するといった方法も考えられる。
図8は、スナップショット取得機構104のフローチャートを示している。スナップショット取得機構は、起動中の仮想サーバのスナップショットを定期的に取得する処理を行う。ステップ801はサーバ仮想化機構206の制御I/F222の通信アドレスを取得する。ステップ802では、サーバ仮想化機構管理テーブル107を検索し、仮想サーバが起動しているかどうかを判別し、起動中であればステップ803に移行する。ステップ803では、サーバ仮想化機構206の制御I/F222を用いて当該仮想サーバのスナップショットを取得する。取得したスナップショットはディスクアレイ装置310内の仮想サーバイメージ格納ディスク313内に格納される。ステップ804では、スナップショットの格納先をサーバ仮想化機構管理テーブル107に格納する。ステップ805では、当該サーバ仮想化機構上で稼働する全ての仮想サーバに関する処理を行ったかどうかを判断する。ステップ806は、管理サーバ101が管理する全てのサーバ仮想化機構に関する処理を行ったかどうかを判断する。これらの処理により、稼働中の仮想サーバのスナップショットを定期的に取得することができ、物理サーバに障害が発生した場合の交代時に最新のスナップショットから起動することができるようになる。
図9は、障害回復機構102のフローチャートを示す。前述の仮想サーバ情報取得機構105やスナップショット取得機構104は、現用系サーバが正常に稼働している時に動作するが、障害回復機構102は、物理サーバに障害が発生した場合に起動され、待機系サーバに処理を引き継ぐ制御を行う。ステップ901では、障害イベントを検出する。障害イベントは、図3におけるBMC260からネットワーク109を介して転送される。障害イベントの内容には、例えば、物理サーバの識別子や、障害の部位などが格納されている。ステップ902では、障害が発生した物理サーバ識別子をもとに、サーバ管理テーブル103を検索し、障害が発生した物理サーバのテーブルエントリを特定する。ステップ903では、障害が発生した物理サーバが使用していたOS起動ディスクを、待機系の物理サーバに割り当てる処理を行う。本処理は、後に図10、11を用いて詳細を説明する。ステップ904では待機系の物理サーバの電源をONにする。これにより、待機系の物理サーバから、障害が発生した物理サーバのOSやアプリケーションが起動される。この時、障害が発生した物理サーバにサーバ仮想化機構が稼働していた場合は、サーバ仮想化機構が自動的に起動される。ステップ906では、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、ステップ907を実行する。ステップ907は、仮想サーバ回復機構を実行する。この処理については後に詳細なフローを用いて説明する。
図10、図11は、障害回復機構のステップ903におけるOS起動ディスクの交代を行う方法について述べている。ディスクアレイ装置310のセキュリティ機構308の中のディスクマッピング機構1002は、物理サーバとディスクアレイ装置310内のディスクとのマッピングを制御する機構である。すなわち、ディスクアレイ装置310内の特定のディスクを指定された物理サーバからしか参照・更新できないように制御する。具体的には、セキュリティ機能1001内にディスクマッピングテーブルを有し、この内容を制御することで、物理サーバに割り当てるディスクを制御することができる。ディスクマッピングテーブルのカラム1003は、サーバ識別子である。サーバ識別子は、サーバ管理テーブル103のカラム503のサーバ識別子と対応しており、全ての物理サーバからユニークな識別子である。ディスクマッピングテーブルのカラム1004は、仮想ディスク番号を示している。仮想ディスク番号は物理サーバに対するディスク番号を示している。ディスクマッピングテーブルのカラム1005は、物理ディスク番号を示している。物理ディスク番号は、ディスクアレイ装置310内でユニークなディスク番号である。物理サーバによっては、特定のディスク番号はブートディスク専用といった特別な意味を持つ場合があり、仮想ディスク番号と物理ディスク番号の変換ができる方が管理の柔軟性を高めることができる。図11は、ディスクの交代を図示している。サーバ1101はサーバ識別子WWN1を有し、サーバ1102はWWN4を有していた場合、ディスクアレイ装置310のセキュリティ機構308において、WWN1を全てWWN4に書き換えることでLU0(1107)はサーバ1101からサーバ1102に切り替えることができる。この切替を、OSブートディスクについて実施することで、OSブートを制御することができるようになる。
図12は、仮想サーバ回復機構106のフローチャートを示している。仮想サーバ回復機構106は、物理サーバに障害が発生した場合に、物理サーバ上で稼働していた仮想サーバを別の物理サーバ上に回復する処理を行う。ステップ1201では、待機系のサーバ仮想化機構が起動するまで待機する。サーバ仮想化機構が起動したかどうかは、サーバ仮想化機構管理テーブル107の制御I/F通信アドレスに対して、何らかのコマンドを発行し、正しい応答が得られたかどうかといった方法で判断することができる。ステップ1202では、障害が発生した物理サーバで稼働していた仮想サーバを求める。これは、サーバ管理テーブルを検索することで障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができる。ステップ1203では、ネットワークスイッチのVLANを変更する。この処理は、仮想サーバとネットワークスイッチ108との連携を意味しており、障害が発生した物理サーバでVLAN設定が行われていた場合に、交代した待機系のサーバも同じVLAN環境に属するように制御することで、仮想サーバ環境だけでなく仮想サーバのネットワークといった周辺環境の設定も自動化することができる。なお、仮想サーバのVLAN設定に関する情報は、サーバ仮想化機構管理テーブル107のカラム607に記載している。また、このVLANに対する仮想サーバと物理サーバの対応もカラム606のネットワーク割当で知ることができる。さらに、サーバ管理テーブル107を検索することで、ネットワークスイッチ108のポートも知ることができるため、VLANの設定変更を自動化することができる。ステップ1204では、仮想サーバをスナップショットから起動する。この制御は、図4を用いて説明した制御I/Fの「スナップショット起動」を用いて行う。また、スナップショットは、サーバ仮想化機構管理テーブル106のカラム609には稼動させた仮想サーバに対応してその仮想サーバのスナップショットの格納場所が記載されており、これを参照することで、起動すべき仮想サーバと、それに対応するスナップショットを知ることができる。これらステップ1203、1204は、障害発生時に起動していた全ての仮想サーバに対して待機系サーバ上で仮想サーバを回復したことがステップ1205で確認されるまで繰り返す。これにより、障害が発生した物理サーバ上で稼働していた仮想サーバを自動的にかつ正確に起動することができるようになる。また、障害が発生した物理サーバ上で、サーバ仮想化機構が稼働していたかどうかを自動的に判別し、サーバ仮想化機構か稼働していた場合は仮想サーバも回復する処理を自動化することができる。また、待機系では、サーバ仮想化機構をあらかじめ用意しておく必要がないため、待機系のソフトウェアライセンスを削減することができる。
本発明の実施例2の全体図を図13に示す。実施例1との主な違いは、管理サーバ151の障害回復機構1301および仮想サーバ回復機構1302である。実施例1では、現用系の物理サーバ203のうち、いずれか一つの障害を待機系の物理サーバで交代する。実施例2では、サーバ仮想化機構がそれぞれ稼働する複数の物理サーバが障害を起こした場合にも、単一の待機系の物理サーバで回復することができる。
図14は、動作概要を示している。現用系サーバ群201を構成する複数の物理サーバ203−1、203−2では、それぞれサーバ仮想化機構206−1、206−2が稼働している。その物理サーバ203−1と物理サーバ203−2に多重に障害が発生した場合、待機系202の物理サーバ203−5のサーバ仮想化機構206−5で、障害が発生した複数の物理サーバ203−1、203−2の上で稼働していた仮想サーバ207、208の全てを217、218に示すように起動する。その際、最初に障害が発生した物理サーバ203−1のサーバ仮想化起動ディスク312−1を待機系の物理サーバ203−5に割当てる。それ以降に物理サーバに障害が発生したときには、既に物理サーバ203−5の上で稼動しているサーバ仮想化機構206−5によって仮想サーバを起動する。この制御により、単一の物理サーバで複数の障害に対応することができるようになる。
図15は、障害回復機構1301のフローチャートを示している。ステップ1501の障害イベント検出、及びステップ1502の障害が発生した物理サーバの検索は図5で説明した実施例1のステップ501およびステップ502とそれぞれ全く同様である。つぎのステップ1503では、物理サーバの多重障害を検出する。これは、例えば、サーバ管理テーブルの状態に障害状態を付加し、既に障害が発生していたかどうかを検知することで実現することができる。多重障害の場合は、ステップ1508を実行する。ステップ1508では、物理サーバのプロセッサやメモリなどのリソースが不足していないかどうか判断する。これは、多数の仮想サーバを生成した場合に、リソースの不足で仮想サーバの処理性能が低下したり、仮想サーバが生成できないといった事を避けるためである。リソースが不足している場合は、ステップ1509にて、新たな待機系を割り当てて、ステップ1504に進む。そうでなければ、ステップ1506に進む。ステップ1504では、障害が発生した物理サーバが使用していたOS起動ディスクを、上記の新たな待機系の物理サーバに割り当てる処理を行う。ステップ1505では待機系の物理サーバの電源をONにする。これにより、待機系の物理サーバ上に障害が発生した物理サーバのOSやアプリケーションが起動される。この時、障害が発生した物理サーバにサーバ仮想化機構が稼働していた場合は、サーバ仮想化機構が自動的に起動される。ステップ1506は、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、ステップ1507を実行する。ステップ1507では、仮想サーバ回復機構を実行する。この処理については後に詳細なフローを用いて説明する。 以上のフローにより、複数の物理サーバで多重に障害が起こった場合にも、すでに回復のために起動した物理サーバにリソース不足がない限り、障害に対する回復処理が単一の物理サーバにより行われる。
図16は、仮想サーバ回復機構1302のフローチャートを示す。仮想サーバ回復機構は、物理サーバに障害が発生した場合に、物理サーバ上で稼働していた仮想サーバを回復する処理を行う。ステップ1601は、物理サーバの多重障害かどうかを検知する。方法は図15におけるステップ1503と同じである。多重障害と検知した場合には、ステップ1607に移り、仮想サーバのネットワーク割り当てを変更する。これは、複数のサーバ仮想化機構で稼働する仮想サーバのネットワークセキュリティを確保する処理である。複数のサーバ仮想化機構を用いた場合、そこで稼働する仮想サーバは異なる業務を実行していることも考えられる。そういった場合、現用系の環境において、既に異なるVLANに設定されているケースがある。複数の異なる環境を一つのサーバ仮想化機構に集約するため、サーバ仮想化機構の中で異なるVLANに分離する必要がある。本ステップでは、現用系と同じネットワーク環境になるように設定を自動化する処理を行う。ステップ1602は、待機系のサーバ仮想化機構が起動するまで待機する。サーバ仮想化機構が起動したかどうかは、サーバ仮想化機構管理テーブルの制御I/F通信アドレスに対して、何らかのコマンドを発行し、正しい応答が得られたかどうかといった方法で判断することができる。ステップ1603は、障害が発生した物理サーバで稼働してた仮想サーバを求める。これは、サーバ管理テーブルを検索することで障害が発生した物理サーバでサーバ仮想化機構が稼働していたかどうかを判別できるとともに、そこからポイントされるサーバ仮想化機構管理テーブルを検索することで、物理サーバ上で稼働していた仮想サーバに関する情報を取得することができる。ステップ1604は、ネットワークスイッチ108のVLANを変更し、待機系のサーバが、障害が発生した物理サーバと同じVLAN環境に属するようにする。次にステップ1605では、仮想サーバをスナップショットから起動する。これらのステップは図12で説明した実施例1の仮想サーバ回復機構106の動作フロー中のステップ1204〜1205と全く同様である。障害発生時に起動していた全ての仮想サーバに対して待機系の物理サーバ上で仮想サーバを回復したことがステップ1605で確認されるまでステップ1604〜1605を繰り返すのも実施例1と同様である。これにより、障害が発生した物理サーバ上で稼働していた仮想サーバを自動的にかつ正確に起動することができるようになると共に、物理サーバの多重障害時にも単一の物理サーバで回復することができるようになり可用性が向上する。また、待機系では、サーバ仮想化機構をあらかじめ用意しておく必要がないため、待機系のソフトウェアライセンスを削減することができる。
本発明の実施例3は、サーバ仮想化機構を有する物理サーバとサーバ仮想化機構を持たない物理サーバの障害に対し、いずれの障害が先であるかにかかわらずが、待機系の単一の物理サーバで回復を行うことができるシステムである。
実施例3の全体のシステム構成は図1に示す実施例1のシステム構成とどうようである。またその物理サーバ203の構成も図3に示すものと変わりがない。図17は実施例3の動作概要を示すブロック構成図である。
待機系202の物理サーバ203−6には、あらかじめサーバ仮想化機構206−6を用意しておく。サーバ仮想化機構起動ディスク312−6はサーバ仮想化機構206−6をあらかじめ起動しておくために用いる。物理サーバ203−3の障害時にその物理サーバ203−3で稼働していたOS204を、待機系の仮想サーバ219として起動する。またサーバ仮想化機構206−1を有する物理サーバ203−1の障害時には、仮想サーバイメージ格納ディスク313上の仮想サーバOSイメージを用い、物理サーバ203−1の上で稼動していた仮想サーバ207を回復する仮想サーバ217を起動する。これにより、物理サーバ1709でサーバ仮想化機構が起動しているかどうかに関係なく、かつ、多重障害時にも単一の物理サーバに交代することができる。
図18は、実施例3の障害回復機構のフローチャートを示す。ステップ1801は、障害イベントを検出する。障害イベントは、BMC260(図3を参照)からネットワークを介して転送される。障害イベントの内容には、例えば、物理サーバの識別子や、障害の部位などが格納されている。ステップ1802では、障害が発生した物理サーバ識別子をもとに、サーバ管理テーブルを検索し、障害が発生した物理サーバのテーブルエントリを特定する。ステップ1803では物理サーバの多重障害を検出する。これは、例えば、サーバ管理テーブルの状態に障害状態を付加し、既に障害が発生していたかどうかを検知することで実現することができる。多重障害の場合は、ステップ1807を実行する。ステップ1807では、物理サーバのプロセッサやメモリなどのリソースが不足していないかどうか判断する。これは、多数の仮想サーバを生成した場合に、リソースの不足で仮想サーバの処理性能が低下したり、仮想サーバが生成できないといった事を避けるためである。リソースが不足している場合は、ステップ1808にて、新たな待機系を割り当てて、ステップ1804に進む。そうでなければ、ステップ1805に進む。ステップ1804では、待機系の物理サーバ203−6の電源をONにする。これにより、待機系のサーバ仮想化機構206−6が起動する。ステップ1805では、サーバモードが基本モードかどうかを判別する。この判別には、サーバ管理テーブルを検索することで実現できる。基本モードとは、サーバ仮想化機構が稼働していないことを意味する。基本モードで起動中の物理サーバに障害が発生した場合はステップ1809にて、起動ディスクを仮想サーバOSイメージに変換し、仮想サーバイメージ格納ディスク313に格納する。この変換は、基本的にはOSが格納されたディスクを仮想サーバが読み込める形式に変換することである。場合によっては、ハードウェアに依存するOSのドライバ等を入れ替えることも行う。つぎにステップ1806に進む。障害が発生した物理サーバ上でサーバ仮想化機構が稼働していた場合は、上記ステップ1809を経ずに直接ステップ1806に進む。ステップ1809では、実施例1と同様に仮想サーバ回復機構106の動作によって仮想サーバを待機系物理サーバ203−6上に仮想サーバを起動する。その詳細は図12を用いて説明したとおりでる。
図19は、実施例3におけるサーバ仮想化機構管理テーブルを示す。実施例3のサーバ仮想化機構管理テーブルは、図6に示した実施例1のサーバ仮想化機構管理テーブル106と全く同じカラム構成を持つ。すなわち、カラム601にはサーバ仮想化機構を識別する仮想化機構識別子が、カラム602には制御I/Fのネットワークアドレスが、カラム603には仮想サーバOSイメージの格納場所が、カラム604には仮想サーバが現在稼働中かどうかを示す状態が、カラム605には仮想サーバに割り当てられているプロセッサ量やメモリ容量がそれぞれ格納される。カラム606には仮想サーバのNIC識別子と、それに対応する物理サーバが有するNICとの割当情報が格納され、カラム607には仮想サーバのネットワークのVLAN設定に関する情報が格納される。カラム608には仮想サーバに割り当てられたデータ格納用のイメージファイルの場所が格納される。カラム609にはスナップショット格納先が格納される。実施例3では、待機系にあらかじめサーバ仮想化機構206−6を稼働させておく。そのため、サーバ仮想化機構管理テーブル107には、この206−6に対応した「サーバ仮想化機構3」の詳細情報が予め格納されたテーブルとなっている。
以上により、実施例3では物理サーバでサーバ仮想化機構が起動しているかどうかに関係なく、かつ、多重障害時にも単一の物理サーバに交代することができる。
システムを他の物理サーバに移行する手段としても使用することができる。
101 管理サーバ
102 障害回復機構
103 サーバ管理テーブル
104 スナップショット取得機構
105 仮想サーバ情報取得機構
106 仮想サーバ回復機構
107 サーバ仮想化機構管理テーブル
108 ネットワークスイッチ
112 ストレージスイッチ
203 物理サーバ
206 サーバ仮想化機構
207 仮想サーバ
308 セキュリティ機構
310 ディスクアレイ装置
312 サーバ仮想化機構起動ディスク
313 仮想サーバイメージ格納ディスク

Claims (1)

  1. それぞれが、複数の仮想サーバを提供するサーバ仮想化機構を実行できる、複数の物理サーバと、前記複数の物理サーバを管理する管理サーバから構成されるサーバシステムの障害回復方法であって、
    ここで、待機系の物理サーバでは前記サーバ仮想化機構が稼動しており、
    前記管理サーバが、
    前記それぞれの物理サーバと、当該それぞれの物理サーバ上で実行される前記サーバ仮想化機構と、当該サーバ仮想化機構上に生成されている、稼動中および停止中の仮想サーバとの対応情報を有し、
    前記サーバ仮想化機構の上で稼動中である仮想サーバのメモリイメージのスナップショットを取得してイメージ格納ディスクに格納し、
    前記管理サーバは、定期的に前記サーバ仮想化機構から稼動中および停止中の仮想サーバの情報を取得して前記対応情報を更新し、
    前記複数の物理サーバのいずれかに障害が発生した場合、当該障害が発生した物理サーバ上の前記サーバ仮想化機構上で稼動中の仮想サーバを、前記対応情報を使用して決定し、
    前記決定した仮想サーバのメモリイメージ情報が格納されている前記イメージ格納ディスクを用いて、前記待機系の物理サーバ上で稼動中のサーバ仮想化機構の上に、前記障害が発生した物理サーバ上で稼動していた仮想サーバを起動することを特徴とするサーバシステムの障害回復方法。
JP2010100478A 2010-04-26 2010-04-26 障害回復方法 Active JP4780237B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010100478A JP4780237B2 (ja) 2010-04-26 2010-04-26 障害回復方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010100478A JP4780237B2 (ja) 2010-04-26 2010-04-26 障害回復方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2005343046A Division JP4544146B2 (ja) 2005-11-29 2005-11-29 障害回復方法

Publications (2)

Publication Number Publication Date
JP2010211819A JP2010211819A (ja) 2010-09-24
JP4780237B2 true JP4780237B2 (ja) 2011-09-28

Family

ID=42971833

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010100478A Active JP4780237B2 (ja) 2010-04-26 2010-04-26 障害回復方法

Country Status (1)

Country Link
JP (1) JP4780237B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101731422B1 (ko) * 2010-10-04 2017-04-28 삼성전자주식회사 가상화 환경에서의 장애 복구 장치 및 방법
JP5817308B2 (ja) * 2011-08-04 2015-11-18 富士通株式会社 サーバ、サーバシステムおよびサーバの冗長切り替え方法
WO2014128948A1 (ja) * 2013-02-25 2014-08-28 株式会社日立製作所 仮想サーバおよび非仮想サーバ混在環境におけるテナントネットワーク構成の管理方法
JP6191686B2 (ja) 2013-03-21 2017-09-06 富士通株式会社 情報処理装置、資源割当方法、及びプログラム
JP6773345B1 (ja) 2019-05-29 2020-10-21 Necプラットフォームズ株式会社 フォールトトレラントシステム、サーバ、及びそれらの運用方法
KR102491998B1 (ko) * 2020-12-04 2023-01-26 (주)글루버 가상화 서버, 이를 포함하는 서버 가상화 시스템의 동작 방법, 및 프로그램
CN117389781B (zh) * 2023-10-18 2024-06-04 上海合芯数字科技有限公司 服务器设备的异常侦测与恢复方法、***、服务器及介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS62172437A (ja) * 1986-01-24 1987-07-29 Fujitsu Ltd 高信頼性システム
JP2005250840A (ja) * 2004-03-04 2005-09-15 Nomura Research Institute Ltd 耐障害システムのための情報処理装置

Also Published As

Publication number Publication date
JP2010211819A (ja) 2010-09-24

Similar Documents

Publication Publication Date Title
JP4544146B2 (ja) 障害回復方法
JP5068056B2 (ja) 障害回復方法、計算機システム及び管理サーバ
US8521703B2 (en) Multiple node/virtual input/output (I/O) server (VIOS) failure recovery in clustered partition mobility
JP4780237B2 (ja) 障害回復方法
US9823881B2 (en) Ensuring storage availability for virtual machines
JP4923990B2 (ja) フェイルオーバ方法、およびその計算機システム。
US9582221B2 (en) Virtualization-aware data locality in distributed data processing
US8533164B2 (en) Method and tool to overcome VIOS configuration validation and restoration failure due to DRC name mismatch
US8676762B2 (en) Efficient backup and restore of a cluster aware virtual input/output server (VIOS) within a VIOS cluster
US8819190B2 (en) Management of file images in a virtual environment
US20110066879A1 (en) Virtual machine system, restarting method of virtual machine and system
US20160179635A1 (en) System and method for performing efficient failover and virtual machine (vm) migration in virtual desktop infrastructure (vdi)
US20120151095A1 (en) Enforcing logical unit (lu) persistent reservations upon a shared virtual storage device
WO2013157072A1 (ja) 計算機システム、リソース管理方法及び管理計算機
JP5316616B2 (ja) 業務引き継ぎ方法、計算機システム、及び管理サーバ
JP5266347B2 (ja) 引継方法、計算機システム及び管理サーバ
JP5131336B2 (ja) ブート構成変更方法
JP5321658B2 (ja) フェイルオーバ方法、およびその計算機システム。
US20240143415A1 (en) Automatic graphics processing unit selection
JP2013016194A (ja) ブート構成変更方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100921

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101118

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20101214

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110311

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110316

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: 20110607

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110620

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140715

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 4780237

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140715

Year of fee payment: 3