(57)【特許請求の範囲】
【請求項１】
リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する管理システムであって、
複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、
様々なリソースプール同士を接続する相互接続ネットワークと、
対象の仮想マシンの故障を検知するために前記相互接続ネットワークの全てのトラヒックを詮索し故障が検知された時に対応する動作を誘発する高可用マネージャとを含む
ことを特徴とする管理システム。
【請求項２】
高可用マネージャは、
相互接続ネットワークの全てのトラヒックを詮索する詮索モジュールと、
詮索されたパケットを解析しヘッダおよびペイロードから情報を抽出するパケット解析モジュールと、
同一のコンピュータデバイスにおける仮想マシンに対する基本的な操作を提供する仮想マシンマネージャと、
局所の仮想マシンマネージャに所定のコマンドを送信する動作モジュールと、
全ての対象の仮想マシンの記録を保存する高可用データベースとを有し、
前記パケット解析モジュールは、
仮想マシンからのハートビートメッセージを時間通りに到達、遅延、または消失のいずれかに決定し、
仮想マシンからのI/Oトラヒックが存在するか否かを決定し、
仮想マシンの現在の状態が所定の通常パターンであるか否かを決定し、
前記仮想マシンマネージャは、
特定の仮想マシンの新たなインスタンスを開始し、
システムリソースの有用性およびシステムの能力である特定の仮想マシンの情報をさらに収集し、
前記動作モジュールは、
利用不可能であると確信されている対象の仮想マシンの新たなインスタンスを開始し、
前記対象の仮想マシンの情報をより収集するために診断コマンドを送信する
請求項１記載の管理システム。
【請求項３】
高可用データベースに保存されている記録には、少なくとも
CPUプールのIDであるNode_Idと、
仮想マシンのIDであるVM_Idと、
デバイスのIDであるDevice_Idと、
仮想マシンによって使用される画像のIDであるImage_Idと、
仮想マシンによって使用されるネットワークアドレスであるNW_Addressと、
仮想マシンによって使用されるネットワークのIDであるNW_Idと、
ハートビートメッセージの状態であるHeartbeat_stateと、
I/Oトラヒックの状態であるTraffic_stateと、
ハートビートのタイムアウトの既定値であるHeartbeat_timeoutと、
I/Oトラヒックのタイムアウトの既定値であるTraffic_timeoutとが含まれ、
前記NW_Addressは、ExpEtherが使用される時はMACアドレスであり、
前記Heartbeat_stateは、正常か遅延のいずれかであり、
前記Traffic_stateは、正常か遅延のいずれかである
請求項２記載の管理システム。
【請求項４】
パケット解析モジュールは、
ハートビートメッセージから対応する情報を抽出し、
通常のI/Oトラヒックのメッセージから対応する情報を抽出し、
システムリソースの有用性のメッセージから対応する情報を抽出する
請求項２または請求項３記載の管理システム。
【請求項５】
パケット解析モジュールは、
ハートビートがタイムアウトしているか否かを決定し、
I/Oトラヒックがタイムアウトしているか否かを決定する
請求項３記載の管理システム。
【請求項６】
動作モジュールは、
ハートビートのタイムアウトもI/Oトラヒックのタイムアウトも存在しない場合対応するタイマを単に更新し、
I/Oトラヒックがタイムアウトした時に更なる診断のためにシステムリソースの情報を要求し、
ハートビートとI/Oトラヒックの両方がタイムアウトした時に回復動作を誘発する
請求項５記載の管理システム。
【請求項７】
リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークとを含む仮想化システムに含まれているデバイスにおいて実行される管理方法であって、
対象の仮想マシンの故障を検知するために前記相互接続ネットワークの全てのトラヒックを詮索し、
故障が検知された時に対応する動作を誘発する
ことを特徴とする管理方法。
【請求項８】
リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークとを含む仮想化システムに含まれているコンピュータにおいて実行される管理プログラムであって、
前記コンピュータに、
対象の仮想マシンの故障を検知するために前記相互接続ネットワークの全てのトラヒックを詮索する詮索処理、および
故障が検知された時に対応する動作を誘発する誘発処理
を実行させるための管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高可用性(High Availability;HA)の技術分野における管理システム、管理方法および管理プログラムに関し、特に仮想システム環境における仮想マシン(Virtual Machine;VM)の高可用性を提供する管理システム、管理方法および管理プログラムに関する。
【背景技術】
【０００２】
電気通信ネットワークは、通常様々な専用のハードウェア機器で構成されている。新しいネットワークサービスを配置するためには、ネットワーク内の処理対象のハードウェア機器と、関連する他の多くのハードウェア機器との両方を考慮することが求められる。例えば、これらのハードウェア機器をどのように統合および配置すればよいかという考慮が求められる。さらに、技術革新が加速するにつれてハードウェアのライフサイクルはより短くなっており、その結果新しいサービスを配置することへの投資に対する見返りが減少し、電気通信ネットワーク分野における技術革新が抑圧されている。
【０００３】
非特許文献１に記載されているネットワーク機能の仮想化(Network Functions Virtualization;NFV)は、工業標準の高容量サーバ、スイッチおよび記憶装置に多くのネットワーク設備の種類を合併する標準IT仮想化技術を発展させることによって上記の課題に取り組むことを目的とする技術である。NFVは、工業標準のサーバハードウェアの範囲において実行可能なようにソフトウェアにおけるネットワーク機能を配備する。
【０００４】
電気通信ネットワークは、高度に修正された専用のレガシーハードウェア機器によって支援されている高可用性を有することが知られている。一方、NFVの環境では、ソフトウェアで実現される機器（仮想マシンとしても知られる）が、修正された専用のハードウェア機器の代わりに使用される。よって、NFVにおいてソフトウェアで実現される機器（仮想マシン）の高可用性をどのように強化するかは、注目の話題になっている。
【０００５】
仮想マシンのようなソフトウェアで実現される機器は、ホストコンピュータ装置のグループまたはホストコンピュータ装置のクラスタで実行され得る。現在のデータセンタの設計概念において、ホストコンピュータ装置は企業向けサーバである。一方、リソースを分散させるという設計概念の下で、ホストコンピュータ装置は、コンピュータのリソースプール（中央処理装置(Central Processing Unit;CPU)プールとしても知られる）に問い合わせている。
【０００６】
VMwareは、非特許文献４に記載されているように、vSphereの仮想マシンモニタ(Virtual Machine Monitor;VMM)層における仮想マシンの故障を検知し回復させるという特徴を有する。図１は、非特許文献４に記載されているVMM層における高可用性のシステムの設計概念を示す説明図である。
【０００７】
図１に示す設計概念によると、（企業向けサーバを参照する）各ノードにはHAエージェントが存在する。図１に示す複数のノードには、１つの選択された親ノードが存在し、残りのノードは全て子ノードである。親ノード内のHAエージェントは、各場所の仮想マシンの能力の監視を担当しており、子ノードの能力を確認するために他の子ノードのHAエージェントと連絡をとる。よって、高可用仮想マシンが機能しなくなると、他の利用可能なノードが選択され、選択されたノードで高可用仮想マシンが立ち上げられる。
【０００８】
非特許文献５に記載されている最大配置マニュアルによると、VMM層における高可用性の解決方法は拡張性に悩まされている。VMM層に設定可能なノードの最大値は３２である。高可用性のオプションが有効にされると、３２個のノードが配置された環境において、各ノードに最大で６４個の高可用仮想マシンが設定可能である。一方、高可用性のオプションが無効にされると、３２個のノードが配置された環境において、各ノードに最大で１００個の仮想マシンが設定可能である。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００８−１８１３８７号公報
【非特許文献】
【００１０】
【非特許文献１】Sangjin Han, Norbert Egi, Aurojit Panda, Sylvia Ratnasamy, Guangyu Shi, and Scott Shenker, "Network Support for Resource Disaggregation in Next-Generation Data Centers," ACM HotNets 2013, pp. 1-7.
【非特許文献２】"ExpEther (Express Ethernet) Consortium"、[online]、ExpEther Consortium、[平成26年 9月22日検索]、インターネット<http://www.expether.org/etechnology.html>
【非特許文献３】ETSI, "Network Functions Virtualization Technology Leaflet," 2014, pp. 1-2.
【非特許文献４】vmware, "vSphere Availability Guide, ESXi 5.5, vCenter Server 5.5," 2013, pp.1-56.
【非特許文献５】vmware, "Configuration Maximums, vSphere 5.5," 2013, pp.1-10.
【非特許文献６】"I/O Virtualization: SR-IOV"、[online]、PCI-SIG、[平成26年 9月22日検索]、インターネット<http://www.pcisig.com/specifications/iov>
【発明の概要】
【発明が解決しようとする課題】
【００１１】
存在する解決すべき課題は、以下の２点にまとめられる。
【００１２】
１．高可用性によるシステムのオーバヘッドを起因とする設定可能な仮想マシンの縮小
非特許文献５に記載されている最大配置マニュアルでは、高可用性の機能が有効にされると、３６％のオーバヘッドがクラスタシステム全体に導入されると結論付けられている。その理由は主に、VMMのシステムパフォーマンスがボトルネックとなるためである。各ノードのHAエージェントは監視対象の仮想マシンが稼働している同じノードで実行されるソフトウェアとして実装されているため、HAエージェントの稼働はノードのCPUリソースも消費させる。すなわち、高可用性のオプションが有効にされると、HAエージェントはノードのCPUリソースを消費するため、結果的に設定可能な仮想マシンの最大値が１００から６４に減少する。
【００１３】
２．拡張性の縮小
VMM層における高可用性の機能の実装は、設計概念における拡張性も縮小させる。ノードの数が増えると、HAエージェントがシステムパフォーマンスのボトルネックになる。さらに、HAエージェントが仮想マシンと同じノードで稼働しているため、HAエージェントと仮想マシンは同じCPUリソースを消費する。
【００１４】
特許文献１に記載されているI/Oバスシステムは、トラヒックモニタ部１４０がCPUおよびI/Oデバイスから独立しているため、上記の問題を解決できる。特許文献１に記載されているトラヒックモニタ部１４０は、CPUとI/Oデバイスの間のトラヒックを監視する。
【００１５】
しかし、特許文献１には回復、診断、または他の拡張された動作は記載されていない。特許文献１に記載されているI/Oバスシステムは、より正確にトラヒックを測定するためにグループ情報を抽出することに重点を置いているため、監視だけで十分とされている。また、特許文献１に記載されているトラヒックモニタ部１４０は、PCI-over-Ethernetパケットのヘッダのみを監視している。
【００１６】
そこで、本発明は、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発できる管理システム、管理方法および管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明による管理システムは、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する管理システムであって、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークと、対象の仮想マシンの故障を検知するために相互接続ネットワークの全てのトラヒックを詮索し故障が検知された時に対応する動作を誘発する高可用マネージャとを含むことを特徴とする。
【００１８】
本発明による管理方法は、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークとを含む仮想化システムに含まれているデバイスにおいて実行される管理方法であって、対象の仮想マシンの故障を検知するために相互接続ネットワークの全てのトラヒックを詮索し、故障が検知された時に対応する動作を誘発することを特徴とする。
【００１９】
本発明による管理プログラムは、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークとを含む仮想化システムに含まれているコンピュータにおいて実行される管理プログラムであって、コンピュータに、対象の仮想マシンの故障を検知するために相互接続ネットワークの全てのトラヒックを詮索する詮索処理、および故障が検知された時に対応する動作を誘発する誘発処理を実行させることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知でき、対応する動作を誘発できる。
【図面の簡単な説明】
【００２１】
【図１】非特許文献４に記載されているVMM層における高可用性のシステムの設計概念を示す説明図である。
【図２】本発明による仮想化システムの実施形態の構成例を示すブロック図である。
【図３】コンピュータデバイスにおいて稼働する高可用仮想マシンの構成例を示すブロック図である。
【図４】HAマネージャ４００の構成例を示すブロック図である。
【図５】仮想化システム１００による高可用仮想マシンの開始処理および登録処理の動作を示すフローチャートである。
【図６】仮想化システム１００によるパケット詮索処理およびハートビートタイムスタンプ更新処理の動作を示すフローチャートである。
【図７】ハートビートタイムアウトの調整方法とハートビートとI/Oトラヒックの監視中の状態遷移の過程の例を示す状態遷移図である。
【図８】３種類のパケットからの抽出を要する情報の例を示す説明図である。
【図９】仮想化システム１０００の使用例を示す説明図である。
【図１０】仮想化システム１１００の他の使用例を示す説明図である。
【図１１】本発明による管理システムの概要を示すブロック図である。
【発明を実施するための形態】
【００２２】
以下では、本発明が完全に理解されるために、説明する目的で多くの詳細な仕様が記載されている。以下、目的、特徴、および利点の例を説明するために、本発明の実施形態を図面を参照して詳細に説明する。
【００２３】
図２は、本発明による仮想化システムの実施形態の構成例を示すブロック図である。図２に示す仮想化システム１００は、CPUプール２００と、I/Oデバイスプール３００と、HAマネージャ４００と、相互接続ネットワーク５００とを含む。仮想化システム１００は、リソースが分散されたデータセンタとしての機能を有する。図２には、リソースを分散させるという設計概念において配置された構成要素であるHAマネージャ４００が示されている。
【００２４】
リソースを分散させるという設計概念に基づいたデータセンタは、CPUリソースプール、ストレージプール、様々なI/Oデバイスプール等の、様々なリソースプールで構成されている。構成要素の説明を明快にするために、図２にはCPUプール２００とI/Oデバイスプール３００のみが記載されている。CPUプール２００には、コンピュータデバイス２０１〜コンピュータデバイス２０２のように複数のコンピュータデバイスが存在する。コンピュータデバイス２０１、コンピュータデバイス２０２はそれぞれ、相互接続ネットワーク５００を介して対応するI/Oデバイス３０１、I/Oデバイス３０２と接続されている。
【００２５】
図２はリソースを分散させるという設計概念に基づいたデータセンタを示すが、VMMはハードウェア（CPUおよびRAM(Random Access Memory)）において稼働しており、複数の仮想マシンおよび仮想マシンのマネージャ(VM-mgr)はVMMにおいて稼働している。VM-mgrは、（少なくとも１つの）HAマネージャ４００から送信された制御コマンドによって誘発され得る事前に定義された仮想マシンの様々な動作を含む。事前に定義された動作は、仮想マシンの停止、起動、再起動等の動作である。なお、事前に定義された動作は上記の動作に限定されず、さらに拡張可能である。
【００２６】
HAマネージャ４００は２つの通信ネットワークと接続されている。１つは相互接続ネットワーク５００である。もう１つはVM-mgrと接続するための管理ネットワークである。図２に示す実線の矢印のように、相互接続ネットワーク５００を介して、HAマネージャ４００は全てのハートビートメッセージを詮索できる。また、HAマネージャ４００は、メッセージと、CPUとI/Oデバイスの間の全てのI/Oトラヒックを制御できる。トラヒックは、例えばコンピュータデバイス２０１とI/Oデバイス３０１の間のトラヒックである。さらに、VM-mgrと接続するための管理ネットワークを介して、HAマネージャ４００は、対応する事前に定義された動作が誘発されるように対象のVM-mgrに制御コマンドを送信できる。
【００２７】
なお、HAマネージャ４００はリソースが分散されたデータセンタから完全に独立しており、データセンタの能力を測定するために全てのトラヒックを詮索するため、仕事量と負荷が平衡するようにHAマネージャ４００を拡張することは妨げられない。例えば、HAマネージャは、仮想LAN(VLAN;Virtual Local Area Network)用に構成可能である。
【００２８】
図３は、コンピュータデバイスにおいて稼働する高可用仮想マシンの構成例を示すブロック図である。図３に示す典型的なコンピュータデバイスは、例えば図２に示すコンピュータデバイス２０１やコンピュータデバイス２０２、または対応するデバイスの組である。典型的なコンピュータデバイス６００のように、デバイスは通常仮想化されているので、１つの物理機能インタフェース(PF)と、複数の仮想機能インタフェース(VF)とを有する。例えば、非特許文献５に記載されているSR-IOVは、恐らく最もよく知られたI/O仮想化の実装である。
【００２９】
I/O仮想化は、ハードウェアデバイス層においてサポートされており、デバイスドライバにおいて構成され得る。特に、非特許文献３に記載されているNFVの環境において、電気通信サービスは仮想マシンの内部で稼働しており、仮想マシンサービスと呼ばれる。最良のパフォーマンスを達成するために、仮想マシンサービスは通常、I/OデバイスのVFインタフェースを直接使用するように構成される。例えば、図３に示すように、VM(1)は、直接VF(1)を使用するように構成されている。
【００３０】
図４は、HAマネージャ４００の構成例を示すブロック図である。図４に示すHAマネージャ４００は、パケット(Pkt)詮索モジュール４０２と、HAデータベース(DB)４０３と、VMマネージャ４０４と、ヘルスチェックモジュール４０５と、アクションモジュール４０６と、Pkt解析モジュール４０９と、Pkt分析モジュール４１０とを有する。
【００３１】
図４に示すように、HAマネージャ４００は、リソースを分散させるという設計概念に配置されている。少なくとも１つのHAマネージャは、リソースを分散させるという設計概念に配置される。参考技術の例として、ExpEtherは、相互接続の技術として使用され、ネットワークインタフェースカード(Network Interface Card;NIC)はI/Oデバイスの代表として選択される。
【００３２】
図４には、２種類のワークフローが示されている。点線のワークフローは、実行が検知される前の開始および登録の処理を表すが、詳細を以下に述べる。図４には、仮想マシンが起動される前に、VMマネージャ４０４が最初に関連情報をHAデータベース４０３に保存することが示されている。関連情報は、Node_Id（CPUプールのID）と、VM_Id（仮想マシンのID）と、Device_Id（デバイスプールのID）と、Image_Id（仮想マシンによって使用される画像のID）と、NW_Address（仮想マシンによって使用されるネットワークアドレス）と、NW_Id（仮想マシンによって使用されるネットワークのID）と、Heartbeat_Stateと、Heartbeat_Timeoutと、Timestamp_Valueとを含む。VMマネージャ４０４は、仮想マシンを起動させるためにVM-mgr２１１に制御コマンドを送信する。
【００３３】
実線のワークフローは、ランタイムパケットの詮索および誘発行動の処理を表すが、詳細を以下に述べる。実行時、Pkt詮索モジュール４０２は、全ての関係するトラヒックに対する詮索を継続して行う。例えば、トラヒックは、特定のVLANタグを伴う。トラヒックは、ハートビートメッセージでもよいし、他の制御メッセージでもよい。詮索対象のトラヒックには、CPUとI/Oデバイス間の全てのデータのトラヒックが該当する。図４に示す例では、ExpEtherが相互接続の技術の例として選択されている。その結果、全てのトラヒックは、PCI-over-Ethernetパケットになるはずである。
【００３４】
Pkt解析モジュール４０９は、ペイロード（ExpEther環境におけるPCI-over-Ethernetパケットのペイロード）から対応する情報を抽出する。Pkt分析モジュール４１０は、以下のように抽出された情報を処理する。１）もし情報がハートビートメッセージであれば、Pkt分析モジュール４１０は、heartbeat_timestampを更新する。２）もし情報が通常のI/Oトラヒックのデータであれば、Pkt分析モジュール４１０は、traffic_timestampを更新する。３）もし情報が診断トラヒックであれば、Pkt分析モジュール４１０は、対応する診断情報を処理する。２種類のタイムスタンプは全てHAデータベース４０３に保存されているが、それらのタイムスタンプは開始および登録の処理中に既に生成されている。
【００３５】
ヘルスチェックモジュール４０５は、２つのタイムスタンプを周期的に確認するという個別のタスクを担う。もしハートビートのタイムアウトかI/Oアクティビティのタイムアウトのいずれかが検知されたら、ヘルスチェックモジュール４０５は、アクションモジュール４０６に通知する。アクションモジュール４０６は、最終的にVM-mgr２１２に制御コマンドを送信する。
【００３６】
図７は、状態遷移図である。以下より詳細に、次のセクションにおいて、「使用事例１：故障の検出と再設定」と、「使用事例２：故障の検出と診断」の２つの使用事例を説明する。
【００３７】
なお、本実施形態のPkt詮索モジュール４０２、VMマネージャ４０４、ヘルスチェックモジュール４０５、アクションモジュール４０６、Pkt解析モジュール４０９、およびPkt分析モジュール４１０は、例えば、非一時的でコンピュータが読み取り可能な記録媒体に格納されているプログラムによる制御に従って処理を実行するCPUによって実現される。
【００３８】
以下、本実施形態の仮想化システム１００の動作を図５〜図６を参照して説明する。図５は、仮想化システム１００による高可用仮想マシンの開始処理および登録処理の動作を示すフローチャートである。
【００３９】
仮想マシンを起動させるコマンドが受信された後（ステップS101）、VMマネージャ４０４は、最初に仮想マシンの制御情報を解析する（ステップS102）。関連情報は、Node_Id（CPUプールのID）と、VM_Id（仮想マシンのID）と、Device_Id（デバイスプールのID）と、Image_Id（仮想マシンによって使用される画像のID）と、NW_Address（仮想マシンによって使用されるネットワークアドレス）と、NW_Id（仮想マシンによって使用されるネットワークのID）と、Heartbeat_Stateと、Heartbeat_Timeoutと、最新のTimestamp_Valueとを含む。次いで、VMマネージャ４０４は、上記の情報を基にHAデータベース４０３内を検索する（ステップS103）。
【００４０】
HAデータベース４０３から記録が発見された場合（ステップS103におけるYes）、VMマネージャ４０４は、対象のノードに制御コマンドを直接送信する（ステップS105）。HAデータベース４０３から記録が発見されなかった場合（ステップS103におけるNo）、VMマネージャ４０４は、HAデータベース４０３内に新しい項目を生成する（ステップS104）。次いで、VMマネージャ４０４は、仮想マシンを起動させるために対象のノードに制御コマンドを直接送信する（ステップS105）。送信した後、仮想化システム１００は、開始処理および登録処理を終了する。
【００４１】
図６は、仮想化システム１００によるパケット詮索処理およびハートビートタイムスタンプ更新処理の動作を示すフローチャートである。
【００４２】
Pkt詮索モジュール４０２がパケットを受信した後（ステップS201）、Pkt解析モジュール４０９は、最初にパケットを解析し、パケットがハートビートメッセージのパケットであるか、通常のデータトラヒックのパケットであるかを決定する（ステップS202）。パケットがハートビートメッセージのパケットである場合（ステップS202におけるYes）、Pkt解析モジュール４０９は、ハートビートメッセージを解析する（ステップS203）。パケットが通常のデータトラヒックのパケットである場合（ステップS202におけるNo）、Pkt解析モジュール４０９は、通常のデータトラヒックのパケットを解析する（ステップS204）。ステップS203およびステップS204の両方の処理において、Pkt分析モジュール４１０は、さらにVM_Idをパケットから抽出し、HAデータベース４０３内を検索する（ステップS205）。最終的に、Pkt分析モジュール４１０は、対応するタイムスタンプ（heartbeat_timestampかtraffic_timestamp）を更新する（ステップS206）。更新した後、仮想化システム１００は、パケット詮索処理およびハートビートタイムスタンプ更新処理を終了する。
【００４３】
図７は、ハートビートタイムアウトの調整方法とハートビートとI/Oトラヒックの監視中の状態遷移の過程の例を示す状態遷移図である。以下、処理全体の詳細を説明する。
【００４４】
図７に示すように、I/O traffic_timeoutの初期値はT1であり、heartbeat_timeoutの初期値はT2であり、復元時間の値はT3である。また、図７は、対象の仮想マシンの状態として、Ｈ（正常）、Ｄ（I/Oトラヒックが遅延）、Ｆ（故障）の３つの状態があることを示す。実行時、I/Oトラヒックのデータは詮索および解析され、関連情報がtraffic_timestampの更新のために抽出される。
【００４５】
状態Ｈの場合：もしI/Oトラヒックの遅延が何ら生じていなければ、仮想マシンの状態はＨ（正常）のままである。
【００４６】
状態Ｈから状態Ｄへ遷移する場合：一旦I/Oトラヒックが遅延すると、対象の仮想マシンの状態はＤ（I/Oトラヒックが遅延）へ遷移し、ハートビートおよび診断の設定が有効になる。状態Ｄ（I/Oトラヒックが遅延）は、I/Oトラヒックが遅延している（ハートビートメッセージは時間通りに到達しているかもしれないが）ことを意味しており、遅延はNFV環境における高い作業負荷が原因で生じている可能性がある。状態Ｄにおいて、診断作業の実行が対象のVM-mgrに通知される。例えば、VM-mgrに仮想マシンからシステムの状態を示す情報をより収集し、アクションモジュールに報告させるように通知される。
【００４７】
状態Ｄから状態Ｈへ遷移する場合：状態Ｄにおいて、I/OトラヒックがT3の時間間隔よりも長い間継続して時間通りに到達した場合、状態はＨ（正常）に戻り、かつハートビートおよび診断の設定も無効になる。
【００４８】
状態Ｄから状態Ｆへ遷移する場合：状態Ｄにおいて、ハートビートの遅延が生じた場合、状態はＦ（故障）へ遷移する。状態Ｆ（故障）は、ハートビートメッセージのタイマとI/Oトラヒックのタイマの両方が切れたことを意味しているため、対象の仮想マシンは利用不可能であると確信される。
【００４９】
状態Ｆの場合：状態Ｆにおいて、回復作業の実行が対象のVM-mgrに通知される。
【００５０】
特許文献１に記載されている先行特許において、CPUとI/Oデバイスの間のトラヒックを監視する同様の方法も提案されている。主な差異は、以下の２点である。
【００５１】
１．監視の面では、PCI-over-Ethernetパケットのヘッダを監視し、ヘッダからグループ管理情報を抽出する点に差異が存在する。本特許では、全てのトラヒックのパケットが詮索され、システムの能力やシステムリソースの有用性に関連する情報を抽出するためにパケットのペイロードが解析される。図８は、３種類のパケットからの抽出を要する情報の例を示す説明図である。図８は、３種類のパケットからの抽出を要する情報の詳細を示す。
【００５２】
ExpEtherがリソースを分散させるという設計概念に基づいたデータセンタにおける相互接続ネットワークの例として選択されているため、パケットのフォーマットは図８に示す通りである。パケットのフォーマットには多くのデータ領域が存在するが、Pkt解析モジュール４０９がパケットのペイロードをどのように解析するかを示すために関連する領域（図８に示す影付きのデータ領域）のみを説明する。なお、データ領域やExpEtherのパケットフォーマットのより詳細な情報は非特許文献２に記載されている。Pkt解析モジュール４０９によるパケット解析処理は以下のようにまとめられる。
【００５３】
（１）仮想マシン、VLAN、およびデバイスの識別情報の抽出
仮想マシンはMAC(Media Access Control)アドレスで識別されるため、Ethernetヘッダにおける送信元アドレス(Source Address;SA)や送信先アドレス(Destination Address;DA)のデータ領域のデータで識別される。VLANの情報はTPID(Tag Protocol Identifier)に提示されており、デバイスは図８に示すFLOWID_DAやFLOWID_SAで識別される。
【００５４】
（２）データフレームのフラグの確認
PCI-over-Ethernetパケットには多くの種類が存在する。EFE_SUB_TYPEは、ペイロード(TLP)がデータフレームであるか他の種類であるかを示す。
【００５５】
（３）ペイロードからの情報の抽出
データフレームに関して、タイプおよびデータのフォーマットは拡張される。データフレームのタイプはハートビート、診断、またはI/Oトラヒックのいずれかであるが、タイプの種類は限定されずどのような種類でもよい。また、ペイロードのレイアウトは、ペイロードのタイプに依存する。ペイロードのタイプがハートビートのタイプである場合、データはハートビートのタイムスタンプを参照する。また、ペイロードのタイプが診断のタイプである場合、システムリソースの有用性が提供される。例えば、CPUの有用性や、ネットワークインタフェースの有用性や、メモリの有用性が提供される。また、ペイロードのタイプがI/Oトラヒックのタイプである場合、データはTLPのデータおよびそのタイムスタンプを参照する。
【００５６】
２．動作の面では、回復／診断、または他の拡張可能な動作は特許文献１には記載されていない。先行特許はより正確にトラヒックを測定するためにグループ情報を抽出することに焦点を置いているため、監視だけで十分とされている。一方本特許では、検知およびその後の動作によりシステムの可用性を強化することを目的にしている。さらに、検知モジュールと動作モジュールの協力により、I/Oトラヒックが存在する時、仮想マシンのI/Oトラヒックを詮索することによってハートビートの負荷が減少する。なお、ある時間帯だけI/Oトラヒックが存在しない場合、ハートビートメッセージが対象の仮想マシンの可用性を検知するために使用される。
【００５７】
本実施形態の仮想化システムは、仮想マシンの故障を検知し、さらに対応する動作を誘発する方法を含む。特に、仮想化システムは、非特許文献１に記載されているようなリソースを分散させるという設計概念において（少なくとも１つの）監視モジュールと、（少なくとも１つの）動作モジュールとを含む。監視モジュールは、故障の検知を担当しており、動作モジュールは、個々の故障に対応する動作の実行を担当している。
【００５８】
リソースを分散させるという設計概念は、CPUリソースプール、ストレージリソースプール等の、個々のリソースプールで構成されており、これらのリソースプールは非特許文献２に記載されているようなExpEtherのような相互接続の技術を介して接続されている。慣習的なハートビートメッセージの代わりにCPUとI/Oデバイスの間の仮想マシンのI/Oトラヒックの監視に基づいて、仮想マシンの可用性の評価要因が見積もられる。仮想マシンの可用性の評価要因の結果に従って、対応する動作が誘発される。
【００５９】
例えば、I/Oトラヒックもハートビートメッセージも両方存在しない場合、取られる動作は、他の物理サーバの利用不可能な仮想マシンの再起動になる。また、もし特定の時間帯だけI/Oトラヒックが存在しない場合、取られる動作は、可用性を確認するための診断メッセージの仮想マシンへの送信であり、ハートビートメッセージを有効にすることである。なお、取られる動作は上記の２種類の動作に限定されず、他の動作でもよい。
【実施例１】
【００６０】
「使用事例１：故障の検出と再設定」
図９は、仮想化システム１０００の使用例を示す説明図である。図９は、対象の仮想マシンの故障が検知され、同じ仮想マシンの新たなインスタンスが他のノードで起動される時の使用事例を示す。
【００６１】
本特許は、仮想マシンの故障の検知を実行し、リソースを分散させるという設計概念に基づいたデータセンタにおける相互接続ネットワークのパケットを詮索することによって仮想マシンの可用性を解析することを提案している。システムの初期化処理中、システムの可用性を評価するためにハートビートメッセージの代わりにI/Oトラヒックを詮索するため、ハートビートメッセージに基づいた慣習的な高可用性の解決方法に比べて本特許が与える負荷は低い。なお、所定の時間間隔だけI/Oトラヒックが遅延している場合、ハートビートおよび診断が有効にされる。
【００６２】
図７は、システムの状態遷移図である。以下、図９を参照して実行時の振る舞いをより詳細に説明する。
【００６３】
１）システムの実行時、Pkt詮索モジュール４００２は、全ての関連するトラヒックの詮索を継続して行う。関連するトラヒックは、例えば特定のVLANタグを伴うトラヒックである。詮索されたトラヒックのパケットはPkt解析モジュール４００９で解析され、さらにPkt分析モジュール４０１０で分析される。
【００６４】
２）詮索されたパケットのペイロードはハートビート、通常のI/Oトラヒックデータ、および診断データのいずれかである。図７に示すように、システムの初期化時、ハートビートと診断は無効にされている。すなわち、通常のI/Oトラヒックデータのみ詮索される。I/Oトラヒックがタイムアウトになると、ハートビートと診断は有効にされ、３種類のトラヒックが全て詮索される。種類が異なるパケットのPkt分析モジュール４０１０による対応する分析処理は、それぞれ以下の通りである。
【００６５】
通常のI/Oトラヒックデータに関して、Pkt分析モジュール４０１０は、通常のI/Oトラヒックのタイムスタンプを抽出し、HAデータベース４００３内の対応する記録を検索し、記録のトラヒックのタイムスタンプ領域を更新する。
【００６６】
ハートビートメッセージに関して、Pkt分析モジュール４０１０は、ハートビートのタイムスタンプを抽出し、HAデータベース４００３内の対応する記録を検索し、記録のハートビートのタイムスタンプ領域を更新する。
【００６７】
診断データに関して、Pkt分析モジュール４０１０は、診断情報を抽出する。診断情報は、例えばシステムリソースの有用性（CPUの有用性、ネットワークの有用性、メモリの有用性）である。次いで、Pkt分析モジュール４０１０は、HAデータベース４００３内の対応する記録を検索し、記録の診断領域に診断情報を保存する。
【００６８】
３）ヘルスチェックモジュール４００５は、HAデータベース４００３内の２つのタイムスタンプを周期的に確認するという個別のタスクを行う。図７に示す状態遷移図に従って、ハートビートのタイムアウトとI/Oアクティビティのタイムアウトの両方が検知された場合、ヘルスチェックモジュール４００５は、新たなVM-mgr２０１２を選択し、アクション：リセットモジュール４００６に通知する。アクション：リセットモジュール４００６は、対象の仮想マシンの新たなインスタンスを起動させるために、最終的にVM-mgr２０１２にリセットコマンドを送信する。
【実施例２】
【００６９】
「使用事例２：故障の検出と診断」
図１０は、仮想化システム１１００の他の使用例を示す説明図である。図１０は、対象の仮想マシンのハートビートの遅延が検知され、ハートビートメッセージが有効にされている時と同様に情報をより収集するためにHAマネージャが診断行動を誘発する時の使用事例を示す。
【００７０】
図９に示す使用事例と比較すると、診断情報はデータセンタのオペレータや管理者にとって、パフォーマンスに不利な条件を理解することや、さらに問題を見つけるために役に立つ。さらに、システムの初期化後、システムの可用性を確認するためにハートビートメッセージの代わりにI/Oトラヒックを詮索するため、ハートビートメッセージに基づいた高可用性の解決方法に比べると本特許が与える負荷は低い。I/Oトラヒックが所定の時間間隔遅延する時、ハートビートと診断は有効にされる。もしI/Oトラヒックの遅延がある時間間隔において消滅した場合、ハートビートと診断は逆に無効にされる。
【００７１】
図７は、システムの状態遷移図である。以下、図１０を参照して実行時の振る舞いをより詳細に説明する。
【００７２】
１）システムの実行時、Pkt詮索モジュール４１０２は、全ての関連するトラヒックの詮索を継続して行う。関連するトラヒックは、例えば特定のVLANタグを伴うトラヒックである。詮索されたトラヒックのパケットはPkt解析モジュール４１０９で解析され、さらにPkt分析モジュール４１１０で分析される。
【００７３】
２）詮索されたパケットのペイロードはハートビート、通常のI/Oトラヒックデータ、および診断データのいずれかである。図７に示すように、システムの初期化時、ハートビートと診断は無効にされている。すなわち、通常のI/Oトラヒックデータのみ詮索される。I/Oトラヒックがタイムアウトになると、ハートビートと診断は有効にされ、３種類のトラヒックが全て詮索される。種類が異なるパケットのPkt分析モジュール４１１０による対応する分析処理は、それぞれ以下の通りである。
【００７４】
ハートビートメッセージに関して、Pkt分析モジュール４１１０は、ハートビートのタイムスタンプを抽出し、HAデータベース４１０３内の対応する記録を検索し、記録のハートビートのタイムスタンプ領域を更新する。
【００７５】
通常のI/Oトラヒックデータに関して、Pkt分析モジュール４１１０は、通常のI/Oトラヒックのタイムスタンプを抽出し、HAデータベース４１０３内の対応する記録を検索し、記録のトラヒックのタイムスタンプ領域を更新する。
【００７６】
診断データに関して、Pkt分析モジュール４１１０は、診断情報を抽出する。診断情報は、例えばシステムリソースの有用性（CPUの有用性、ネットワークの有用性、メモリの有用性）である。次いで、Pkt分析モジュール４１１０は、HAデータベース４１０３内の対応する記録を検索し、記録の診断領域に診断情報を保存する。
【００７７】
３）ヘルスチェックモジュール４１０５は、HAデータベース４１０３内の２つのタイムスタンプを周期的に確認するという個別のタスクを行う。図７に示す状態遷移図に従って、I/Oトラヒックのタイムアウトのみが検知された場合、ヘルスチェックモジュール４１０５は、アクション：診断モジュール４１０６に通知し、アクション：診断モジュール４１０６は、対象の仮想マシンの診断情報をより要求するために、VM-mgr２１１１に診断コマンドをさらに送信する。診断情報は、例えばシステムリソースの有用性であるが、これに限られない。さらに、アクション：診断モジュール４１０６は、対象の仮想マシンのハートビートメッセージを有効にする。
【００７８】
次に、本発明の概要を説明する。図１１は、本発明による管理システムの概要を示すブロック図である。本発明による管理システム１０は、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する管理システムであって、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプール１１１〜リソースプール１１４（例えば、CPUプール２００やI/Oデバイスプール３００）と、様々なリソースプール同士を接続する相互接続ネットワーク１２（例えば、相互接続ネットワーク５００）と、対象の仮想マシンの故障を検知するために相互接続ネットワーク１２の全てのトラヒックを詮索し故障が検知された時に対応する動作を誘発する高可用マネージャ１３（例えば、HAマネージャ４００）とを含む。
【００７９】
そのような構成により、管理システムは、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知でき、対応する動作を誘発できる。
【００８０】
また、高可用マネージャ１３は、相互接続ネットワーク１２の全てのトラヒックを詮索する詮索モジュール（例えば、Pkt詮索モジュール４０２）と、詮索されたパケットを解析しヘッダおよびペイロードから情報を抽出するパケット解析モジュール（例えば、Pkt解析モジュール４０９）と、同一のコンピュータデバイスにおける仮想マシンに対する基本的な操作を提供する仮想マシンマネージャ（例えば、VMマネージャ４０４）と、局所の仮想マシンマネージャに所定のコマンドを送信する動作モジュール（例えば、アクションモジュール４０６）と、全ての対象の仮想マシンの記録を保存する高可用データベース（例えば、HAデータベース４０３）とを有し、パケット解析モジュールは、仮想マシンからのハートビートメッセージを時間通りに到達、遅延、または消失のいずれかに決定し、仮想マシンからのI/Oトラヒックが存在するか否かを決定し、仮想マシンの現在の状態が所定の通常パターンであるか否かを決定し、仮想マシンマネージャは、特定の仮想マシンの新たなインスタンスを開始し、システムリソースの有用性等の特定の仮想マシンの情報をさらに収集し、動作モジュールは、利用不可能であると確信されている対象の仮想マシンの新たなインスタンスを開始し、対象の仮想マシンの情報をより収集するために診断コマンドを送信してもよい。
【００８１】
また、高可用データベースに保存されている記録には、少なくともNode_Id（CPUプールのID）と、VM_Id（仮想マシンのID）と、Device_Id（デバイスのID）と、Image_Id（仮想マシンによって使用される画像のID）と、NW_Address（仮想マシンによって使用されるネットワークアドレス）と、NW_Id（仮想マシンによって使用されるネットワークのID）と、Heartbeat_state（ハートビートメッセージの状態）と、Traffic_state（I/Oトラヒックの状態）と、Heartbeat_timeout（ハートビートのタイムアウトの既定値）と、Traffic_timeout（I/Oトラヒックのタイムアウトの既定値）とが含まれ、NW_Addressは、ExpEtherが使用される時はMACアドレスであり、Heartbeat_stateは、正常か遅延のいずれかであり、Traffic_stateは、正常か遅延のいずれかでもよい。
【００８２】
また、パケット解析モジュールは、ハートビートメッセージから対応する情報を抽出し、通常のI/Oトラヒックのメッセージから対応する情報を抽出し、システムリソースの有用性のメッセージから対応する情報を抽出してもよい。
【００８３】
また、パケット解析モジュールは、ハートビートがタイムアウトしているか否かを決定し、I/Oトラヒックがタイムアウトしているか否かを決定してもよい。
【００８４】
また、動作モジュールは、ハートビートのタイムアウトもI/Oトラヒックのタイムアウトも存在しない場合対応するタイマを単に更新し、I/Oトラヒックがタイムアウトした時に更なる診断のためにシステムリソースの情報を要求し、ハートビートとI/Oトラヒックの両方がタイムアウトした時に回復動作を誘発してもよい。
【００８５】
本発明による非一時的でコンピュータが読み取り可能な記録媒体に格納されている管理プログラムは、リソースを分散させるという設計概念に基づいたデータセンタにおいて故障が発見された時に仮想マシンの故障を検知し対応する動作を誘発する、複数の仮想マシンが稼働しているハードウェアの要素として動作するリソースプールと、様々なリソースプール同士を接続する相互接続ネットワークとを含む仮想化システムに含まれているコンピュータにおいて実行される管理プログラムであって、コンピュータに、対象の仮想マシンの故障を検知するために相互接続ネットワークの全てのトラヒックを詮索する詮索処理、および故障が検知された時に対応する動作を誘発する誘発処理を実行させることを特徴とする。
【００８６】
以上、実施形態（及び実施例）を参照して本願発明を説明したが、本願発明は上記実施形態（及び実施例）に限定されものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【００８７】
１０  管理システム
１１１〜１１４  リソースプール
１２、５００  相互接続ネットワーク
１３、４００、４０００、４１００  高可用（HA）マネージャ
１００、１０００、１１００  仮想化システム
２００  CPUプール
２０１、２０２、６００、２００１、２００２、２１０１、２１０２  コンピュータデバイス
２１１、２１２、２０１１、２０１２、２１１１、２１１２  VM-mgr
３００  I/Oデバイスプール
３０１、３０２、３００１、３００２、３１０１、３１０２  I/Oデバイス
４０２、４００２、４１０２  パケット（Pkt）詮索モジュール
４０３、４００３、４１０３  高可用（HA）データベース
４０４  仮想マシン（VM）マネージャ
４０５、４００５、４１０５  ヘルスチェックモジュール
４０６  アクションモジュール
４０９、４００９、４１０９  パケット（Pkt）解析モジュール
４１０、４０１０、４１１０  パケット（Pkt）分析モジュール
４００６  アクション：リセットモジュール
４１０６  アクション：診断モジュール
【図１】
0006354901.tif 000002
【図２】
0006354901.tif 000003
【図３】
0006354901.tif 000004
【図４】
0006354901.tif 000005
【図５】
0006354901.tif 000006
【図６】
0006354901.tif 000007
【図７】
0006354901.tif 000008
【図８】
0006354901.tif 000009
【図９】
0006354901.tif 000010
【図１０】
0006354901.tif 000011
【図１１】
0006354901.tif 000012