JP2008052407A - クラスタシステム - Google Patents

Abstract

【課題】従来は、1つサービス障害が、他のサービスとクラスタマネージャに影響を与える。また、アプリケーションとクラスタマネージャのOSが対応する必要があり汎用性が乏しい。障害処理機構が割り込み種類からS/W障害を検知するものは検出できない障害もある。
【解決手段】複数の計算機夫々に仮想マシンと、ホストOSと、クラスタマネージャと、０個以上のゲストOSが設置され、各計算機からアクセス可能なOSイメージを持つ共有ディスクを備え、クラスタマネージャは、各ゲストOSの起動・停止、サービス状態監視、障害サービスの障害復旧機能と、ハートビート機能を持ち、他クラスタマネージャの障害検知により、共有ディスクのOSイメージを用い障害復旧のフェイルオーバ機能を有し、また、特定サービス専用にされた各ゲストOSを１つのサービスとみなして管理する。
【選択図】図１

Description

この発明は、仮想マシンを持つ計算機を複数用いて構成したクラスタシステムに係わり、その信頼性を向上させる技術に関する。

図８は従来のクラスタシステムを表す。計算機10Aではオペレーティングシステム15Aが動作し、その上でクラスタマネージャ20Aが動作し、計算機10Bではオペレーティングシステム15Bが動作し、クラスタマネージャ20Bが動作することで2ノードのクラスタシステムを構成する。クラスタマネージャは互いにハートビート90を利用して接続する。
オペレーティングシステム15Aでは、アプリケーション30A〜30Cが動作し、30A及び30Bがサービス31Aを提供、30Cがサービス31Bを提供する。計算機10A〜10B、クライアント40A〜40BはLAN91によって接続され、クライアント40A〜40Bはサービス31A〜31Bにアクセスする。

次に動作について説明する。
クラスタマネージャ20Aはサービス31A〜31B、クラスタマネージャ20Bを監視し、サービス31Aの障害を検知すると、アプリケーション30A及びアプリケーション30Bを停止、クラスタマネージャ20Bにアプリケーション30A〜30Bの起動を要求し、サービス31Aを計算機10Bで復旧する。
また、サービス31Aの障害がCPUを占有する等でOSの動作に支障を与えるような障害の場合、サービス31B、クラスタマネージャ20Aもその影響で動作が不安定になる。この場合、クラスタマネージャ20Bはクラスタマネージャ20Bの障害を検知し、計算機10Aを停止、サービス31A、31Bを計算機10Bで復旧する。
このように動作してシステムの信頼性を向上させる。

図９は、特開2003-330740号公報に記載される従来の論理計算機を用いたクラスタシステムに関する構成図である。物理計算機1A、1B上に計算機資源分割機構2A、2Bがあり、論理計算機3A〜3Dが動作する。計算機資源分割機構2A、2B内にクラスタマネージャ20A、20Bの機能を有し、論理計算機3A〜3Dを用いて例えば図９のような論理計算機3A、3Cを対、論理計算機3B、3Dを対としたホットスタンバイのクラスタシステムを構成する。また、図１０は従来方式を実現するためのクラスタマネージャの構成を示す。クラスタマネージャは論理計算機割当機構、障害処理機構、物理計算機構成情報テーブル、論理計算機構成情報テーブル、クラスタテーブルを有する。

次に動作について説明する。障害処理機構は障害発生により生じた割り込みを検知する。割り込みの種類により、ソフトウェア障害を検知すると、割り込みを起こした論理計算機を再起動する。ハードウェアの障害を検知すると障害を発生したプロセッサに割り当てられた論理計算機を別のプロセッサに割り当て再起動する。また、物理計算機1A全体が障害により停止すると、論理計算機3A、3Bの業務を物理計算機1Bの論理計算機3C、3Dが引き継ぎ、復旧する。
以上のように、物理計算機上のハードウェア障害や論理計算機上のソフトウェア障害に対して、論理計算機を適切に再起動し、システム全体の信頼性を向上させる仕組みが示されている。

特開2003-330740号公報

従来のクラスタシステムでは、以下のような問題が生じる。
(1)．従来技術では、各サービスを提供するアプリケーションとクラスタマネージャが同じOS上で動作するため、1つサービスの障害が、他のサービスにもクラスタマネージャにも影響を与える。計算機ごとにサービスを割り当てることで回避可能であるが、その場合、システムが複雑になり、管理コスト、導入コストが増大するという問題を持つ。
(2)．従来技術では、各サービスを提供するアプリケーションとクラスタマネージャが同じOS上で動作するため、アプリケーションとクラスタマネージャが使用するOSに対応している必要がある。そのため、アプリケーション、クラスタマネージャ、OSの選択肢が狭まり、システム構築コストを増大させる。
(3)．特開2003-330740号公報記載のものでは、計算機資源分割機構内にクラスタマネージャを実装するため、クラスタマネージャと計算機資源分割機構が密接に関係し、汎用性が損なわれる。そのため、機能拡張や保守コストが増大する。
(4)．特開2003-3307740公報記載のものでは、障害処理機構が割り込みの種類から論理計算機のソフトウェア障害を検知するため、アプリケーションが割り込みレベルでは正常に動作するが、サービスを提供できていない等の障害を検出することは出来ない。

この発明に係るクラスタシステムは、
複数の計算機と、この複数の計算機の夫々に設置された仮想マシンと、１個のホストOSと、ホストOSにのみ動作するクラスタマネージャと、
複数の計算機の少なくとも１つ以上に外部に提供するサービス用のアプリケーションを動作させるゲストOSと、
ゲストOSのOSイメージを持ち、各計算機からアクセス可能な共有ディスクとを備え、
クラスタマネージャは、仮想マシンの機能を利用し、各ゲストOSの起動、停止の制御、サービスの状態監視を行い、サービス障害を検知すると、予め設定されたフェイルオーバポリシーに従って該当サービスを障害から復旧する機能と、クラスタマネージャ同士が互いに状態監視を行うハートビート機能を持ち、他のクラスタマネージャの障害を検知すると、該当クラスタマネージャが管理するサービス全てを共有ディスクのOSイメージを用いて障害から復旧するフェイルオーバ機能を有し、
各ゲストOSはそれぞれが特定のサービス専用で、各サービスの復旧方法が指示されるフェイルオーバポリシーに関連付けられ、ゲストOSそのものを１つのサービスとみなして、クラスタマネージャに管理される構成にされる。

この発明のクラスタシステムによれば、クラスタマネージャがサービスまたは他のクラスタマネージャを監視することでソフトウェアまたはハードウェアの障害が生じても、それを検知しサービスを復旧できる。また、OSごとにサービスを割り当てることで、サービスの障害が他のサービスへ影響することを防ぐことが出来る。これによりシステムの信頼性を向上させることが出来る。
さらにOSを仮想マシン上のゲストOSとすることで計算機の不要な増加を防ぐことが出来る。

実施の形態１．
図１は、計算機10A〜10B、共有ディスク81で2ノードの共有ディスク型ホットスタンバイのクラスタシステムである。
計算機10Aでは、仮想マシン90Aが動作し、ゲストOS12AとゲストOS12B、ホストOS11Aが動作する。また、ストレージ（図示せず）を持ち、ゲストOS12A及びゲストOS12BのOSイメージ（図示せず）を持つ。ゲストOS12Aではアプリケーション30A〜30Bが動作し、サービス31Aを提供する。ゲストOS12Bでは、アプリケーション30Cが動作し、サービス31Bを提供する。ホストOS11Aではクラスタマネージャ20Aが動作し、仮想マシン制御I/F91Aを利用して仮想マシン90Aにアクセス可能である。また、クラスタマネージャ20Aはサービス31A〜31Bの復旧方法が記述されているフェイルオーバポリシー60Aを持つ。

計算機10Bでは、仮想マシン90Bが動作し、ホストOS11Bが動作する。また、ストレージ（図示せず）を持ち、ゲストOS12A及びゲストOS12BのOSイメージ（図示せず）を持つ。ホストOS11Bではクラスタマネージャ20Bが動作し、仮想マシン制御I/F91Bを利用して仮想マシン90Bにアクセス可能である。また、クラスタマネージャ20Bはサービス31A〜31Bの復旧方法が記述されているフェイルオーバポリシー60Bを持つ。

共有ディスク81は計算機10A〜10Bと接続され、ゲストOSのOSイメージ13A〜13Bを持つ。
計算機10A〜10Bはハートビート90によって接続され、クラスタマネージャ20A〜20Bはハートビート90を利用して互いに接続する。計算機10A〜10B、クライアント40A〜40BはLAN91によって接続され、クライアント40A〜40Bはサービス31A〜31B、ホストOS11A〜11Bと相互に接続する。

次に動作について説明する。
クラスタマネージャ20AはLAN91を利用して、サービス31A〜31Bに一定間隔でアクセスを行い障害の有無を監視する。
クラスタマネージャ20Aがサービス31Aの障害を検知すると、クラスタマネージャ20Aは仮想マシン制御I/F91Aを利用して、サービス31Aが動作するゲストOS12Aを停止する。ゲストOS12Aが停止すると、クラスタマネージャ20Aは、フェイルオーバポリシー60Aに従って計算機10Aもしくは計算機10BでゲストOS12Aの起動を行う。

フェイルオーバポリシー60Aにより計算機10AでゲストOS12Aを起動する場合は、クラスタマネージャ20Aが仮想マシン制御I/F91Aを利用して共有ディスク81のOSイメージ13AからゲストOS12Aの起動を行い、サービス31Aが復旧し、クライアント40A〜40Bへのサービスを再開する。
フェイルオーバポリシー60Aにより計算機10BでゲストOS12Aを起動する場合は、クラスタマネージャ20Aが、クラスタマネージャ20Bに対してゲストOS12Aを計算機10B上で起動するように要求を行う。
クラスタマネージャ20Bは、クラスタマネージャ20AからゲストOS12Aの起動要求を受けると、仮想マシン制御I/F91Bを利用して計算機10Bのストレージ内のOSイメージからゲストOS12Aの起動を行い、サービス31Aが復旧する。
クラスタマネージャ20A〜20Bはハートビート90を利用して、互いに一定間隔でアクセスを行い、障害の有無を監視する。

クラスタマネージャ20Bがクラスタマネージャ20Aの障害を検知すると、クラスタマネージャ20Bは計算機10Bを停止する。計算機10Bを停止した後、クラスタマネージャ20Bは仮想マシン制御I/F91Bを利用して共有ディスク81のOSイメージ13A〜13BからゲストOS12A〜12Bの起動を行い、クラスタマネージャ20Aが管理していたサービス31A〜31Bを計算機10Aで復旧し、クライアント40A〜40Bへのサービスを再開する。

以上のように、サービスまたはクラスタマネージャを監視することでソフトウェアまたはハードウェアの障害が生じても、それを検知し、サービスを復旧できる。また、OSごとにサービスを割り当てることで、サービスの障害が他のサービスへ影響することを防ぐことが出来る。これにより、システムの信頼性を向上させることが出来る。
さらにOSを仮想マシン上のゲストOSとすることで計算機の不要な増加を防いでいる。

実施の形態２．
実施の形態１では、共有ディスク81を用いてクラスタを構成したが、実施の形態２はローカルディスクを用いたデータレプリケーション型クラスタである。
図２は実施の形態２の構成を示している。計算機10A〜10Bはローカルディスク80A〜80Bを持ち、互いにゲストOS12A及びゲストOS12BのOSイメージ13A〜13Bを持つ。また、ホストOS11A〜ホストOS11Bは、レプリケータ70A〜70Bを持つ。レプリケータ70A〜70BはLAN91により接続する。

次に動作について説明する。
レプリケータ70A〜70BはLAN91を通じてローカルディスク80A〜80Bのファイルを同期させることが可能である。クラスタマネージャ20A〜20Bはレプリケータ70A〜70Bを管理し、ローカルディスク80A〜80B間でOSイメージ13A〜13Bを一定間隔で同期する。
サービス31Aの障害検知によりクラスタマネージャ20Bがクラスタマネージャ10AからゲストOS12Aの起動要求を受けると、クラスタマネージャ20Aが仮想マシン制御I/F91Aを利用してローカルディスク80BにあるOSイメージ13AからゲストOS12Aの起動を行う。
以上のように共有ディスクを用いなくとも実施の形態１の効果を得ることが出来る。また、高価な共有ディスクを使用せず、コスト削減が可能である。

実施の形態３．
実施の形態２では、ゲストOSを1つのOSイメージで扱っていた。実施の形態３では、図３のようにゲストOS12Aを構成するイメージをシステムイメージとデータイメージに分ける。システムイメージとはオペレーティングシステムやアプリケーションが格納されているパーティションである。データイメージはアプリケーションがデータを格納するパーティションである。
ゲストOSが起動される際には、システムイメージとデータイメージ両方を組み合わせてゲストOSを構成する。サービス稼動時、アプリケーションはデータイメージが提供するパーティションに重要なデータを格納し、システムイメージには書き込みを行わない。また、図４のようにレプリケータはデータイメージのみを同期する。

以上のように、OSイメージをシステムイメージ、データイメージに分離し、レプリケータでデータイメージのみ同期することで、同期されるデータ量を削減する。これにより、システムへの負荷を軽減、同期の間隔の短縮が可能となり、サービスの信頼性の向上、サービスレベルの向上が可能となる。

実施の形態４．
実施の形態１〜３では、クラスタマネージャ20A〜20BがゲストOS12A〜12Bを起動する場合、共有ディスクやローカルディスクにあるOSイメージから起動を行うが、実施の形態４ではOSイメージではなく、ゲストOSのスナップショットイメージから起動する場合について説明する。
クラスタシステムへサービス31Aを登録する際には、まずゲストOS12AのOSイメージ13Aを用意しディスクに格納、次にOSイメージ13Aからスナップショットイメージを作成する。
図５はスナップショットイメージの作成方法を説明している。まず、ホストOSが仮想マシン制御I/Fを利用してゲストOS21Aを起動する（S81）。サービス31Aへのアクセスを一定間隔で行う（S82）。サービス31Aから正しいレスポンスが返えるか否かを判定し（S83）、正しいレスポンスが返えることで、アプリケーション30A〜30Bが起動しサービス31Aの提供が開始されたことを検知する。仮想マシン制御I/F91Aにアプリケーションが起動した直後のスナップショットであるスナップショットイメージの作成を要求し（S84）、作成されたゲストOS12Aのスナップショットイメージをディスクに保存する（S85）。

クラスタマネージャ20Aがサービス31Aの障害を検知した等の理由で、ゲストOS12Aの起動をクラスタマネージャ20Bに要求すると、クラスタマネージャ20Bは仮想マシン制御I/F91Bを通してゲストOS12Aをスナップショットイメージから起動する。

以上のように、ゲストOSをサービス提供開始後のスナップショットイメージから起動することで、図６のようにOSイメージから起動するよりもOSやアプリケーションの起動過程を省略できるためフェイルオーバ時のサービスの復旧速度が向上し、サービスの信頼性の向上、サービスレベルの向上が可能になる。

実施の形態５．
実施の形態１〜４では、サービスの監視がLAN91を経由したクラスタマネージャのアクセスによってのみを行われる。実施の形態５では、クラスタマネージャがLAN91を経由したサービスの監視の外に、仮想マシン制御I/Fを利用してゲストOSの状態を取得し、その情報からもサービス監視を行う。
実施の形態5の動作について説明する。
クラスタマネージャ20Aは一定間隔でサービス31AにLAN91を経由してアクセスし監視を行うと共に、一定間隔で仮想マシン制御I/F91Aを利用してゲストOS12Aの状態を取得する。状態がクラッシュ等の障害状態であった場合、クラスタマネージャ20Aはサービス31Aの障害を検知し、サービス31Aの復旧を行う。

以上によりサービスの監視についてゲストOSの状態を含めることによって、ゲストOSの状態からも障害を検知することができ、サービスの信頼性の向上が可能になる。

実施の形態６．
実施の形態６では、ゲストOS12A〜12B、ホストOS11Aに異なる種類のオペレーティングシステム、またはオペレーティングシステムの構成やパラメータの異なるものとする。
例えば、図７ではホストOSにLinux1、ゲストOS12AではLinux1'、ゲストOS12BではWindows（登録商標）が動作する。ホストOSで動作するLinux1は、クラスタマネージャが動作し、その機能に必要なだけのモジュールやパッケージのみを持ち、カーネルパラメータ等の設定もクラスタマネージャの動作に最適化されたものである。ゲストOS12Aで動作するLinux1'はLinux1と同じOSであるが、アプリケーション30A〜31Aが動作するだけのモジュールやパッケージのみを持ち、カーネルパラメータ等の設定もアプリケーション30A〜30Bの動作に最適化されたものである。ゲストOS12Bではwindows（登録商標）が動作し、windows（登録商標）のみに対応するアプリケーション30Cが動作する。

以上のように、ゲストOSにサービス提供のみに特化したOSを適応することで、余分なモジュールの動作を抑制し、コンピュータリソースを有効に活用することが出来る。また、クラスタマネージャやアプリケーション間のOS対応を考慮する必要がない。さらには、アプリケーションやクラスタマネージャごとに最適なOSを選択することが出来る。そのため、システム構築を容易にし、サービスレベルの向上も可能となる。

実施の形態1〜６では、2つの計算機でホットスタンバイ型クラスタシステムを構築しているが、計算機数3つ以上でも良い。また、アクティブ・アクティブ型等の他のフェイルオーバ方式でも良い。
これにより、複数の計算機の障害に対応できる等、サービスの信頼性向上が可能となる。

この発明のクラスタシステムは、クラスタソフトウェア、仮想マシン技術を組み合わせて信頼性の向上が図れるサーバシステム等に適用可能である。

この発明の実施の形態１を示すクラスタシステムの構成図である。 実施の形態２を示すクラスタシステムの構成図である。 実施の形態３によるゲストOSの構成説明図である。 実施の形態３によるレプリケータの動作説明図である。 実施の形態４によるスナップショットイメージの作成方法のフロー図である。 ゲストOSのOSイメージから起動のフロー図と、スナップショットイメージからの起動のフロー図である。 ホストOSとゲストOSに異なる種類のオペレーティングシステムを用いる説明構成図である。 従来のクラスタシステムを表す構成図である。 論理計算機を用いた従来のクラスタシステムの構成図である。 従来のクラスタシステムを構成するクラスタマネージャの構成図である。

符号の説明

1A、1B：物理計算機、2A、2B：計算機資源分割機構、3A〜3D：論理計算機、10A、10B：計算機、11A、11B：ホストOS、12A、12B：ゲストOS、13A、13B：OSイメージ、15A、15B：オペレーティングシステム、20A、20B：クラスタマネージャ、30A、30B、30C：アプリケーション、31A、31B：サービス、40A、40B：クライアント、60A、60B：フェイルオーバポリシー、70A、70B：レプリケータ、80A、80B：ローカルディスク、81：共有ディスク、90：ハートビート、90A、90B：仮想マシン、91：LAN、91A、91B：仮想マシン制御I/F。

Claims (6)

1. 複数の計算機と、この複数の計算機の夫々に設置された仮想マシンと、１個のホストOSと、ホストOSにのみ動作するクラスタマネージャと、
   複数の計算機の少なくとも１つ以上に外部に提供するサービス用のアプリケーションを動作させるゲストOSと、
   ゲストOSのOSイメージを持ち、各計算機からアクセス可能な共有ディスクとを備え、
   クラスタマネージャは、仮想マシン機能を利用し、各ゲストOSの起動、停止制御と、サービスの状態監視を行い、サービス障害を検知すると、予め設定されたフェイルオーバポリシーに従って該当サービスを障害から復旧する機能と、クラスタマネージャ同士が互いに状態監視を行うハートビート機能を持ち、他のクラスタマネージャの障害を検知すると、該当クラスタマネージャが管理するサービス全てを共有ディスクのOSイメージを用いて障害から復旧するフェイルオーバ機能を有し、
   各ゲストOSはそれぞれが特定のサービス専用で、各サービスの復旧方法が指示されるフェイルオーバポリシーに関連付けられ、ゲストOSそのものを１つのサービスとみなして、クラスタマネージャに管理される構成にされたことを特徴とするクラスタシステム。
2. ゲストOSのOSイメージを持つ共有ディスクは各計算機が夫々備えるローカルディスクで形成され、
   各計算機に夫々設置された各ホストOSがレプリケータを持ち、各計算機内のローカルディスク内にあるOSイメージを各計算機間で同期する構成にされたことを特徴とする請求項１記載のクラスタシステム。
3. ゲストOSのOSイメージは、OSやアプリケーションが格納されるディスクパーティションのイメージであるシステムイメージと、アプリケーションがデータを格納するディスクパーティションのイメージであるデータイメージから構成されることを特徴とする請求項１又は２記載のクラスタシステム。
4. 共有ディスクは、ゲストOSのOSイメージの他に、ゲストOSが起動しアプリケーションが起動した直後のスナップショットであるスナップショットイメージを持ち、
   クラスタマネージャが運用時にゲストOSを起動する場合、スナップショットイメージから起動する構成されることを特徴とする請求項１乃至３の何れか一に記載のクラスタシステム。
5. クラスタマネージャはLANを経由したアクセスによるサービス監視と共に、仮想マシン制御I/Fを利用して、各ゲストOSの状態を取得し、その情報をサービスの監視情報として扱うことを特徴とする請求項１乃至４の何れか一に記載のクラスタシステム。
6. 計算機に設置されるゲストOSとホストOSは、オペレーティングシステムの種類が異なる、またはオペレーティングシステムの構成やパラメータが異なるものであることを特徴とする請求項１乃至５の何れか一に記載のクラスタシステム。

Images