JP2006323526A - クラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタ - Google Patents

Abstract

【課題】無駄な待機系ノードを用いずにクラスタの運用管理を円滑に引き継ぐことにより可用性の向上を図ること。
【解決手段】管理ノードとして稼働しているノード１１１が故障すると、他ノード１１２〜１１５の中から管理ノード（ノード１１５）が決定される。ノード１１５ではノードコーディネータＮＣが起動され、第２のクラスタ情報１４００が生成される。第２のクラスタ情報１４００は、ノード１１５のノードデーモンＮＤに配布される。ノード１１５のノードコーディネータＮＣでは、障害ノード１１１を除いたあらたなＩＰ変換テーブル１５００を作成し、障害ノード１１１を除くノード１１２〜ノード１１５に配布される。ノード１１２〜ノード１１５の各ノードデーモンＮＤが有する第１のクラスタ情報から第２のクラスタ情報１４００に更新され、そのＩＰ変換テーブル１５００が各ＶＮＩＣに引き渡される。
【選択図】 図１４

Description

この発明は、複数の計算機ノード（以下、単に「ノード」）からなるクラスタを管理するクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタに関する。

近年、インターネットを利用したｅ−ビジネスでは、２４時間３６５日サービスを提供し続けることが成功のための重要なカギとなる。しかし、現実問題として、１台のマシンが故障や過負荷により停止しただけで、顧客へのサービスが全面的にストップしてしまうことがあり、莫大な損害を引き起こすことになる。こうした事態に備えるためにシステムのＭＴＢＦ（平均故障間隔）を改善し稼働率を向上させる高可用化の要求が高まりつつある。可用性を向上させ、システム停止時間を最小限にすることで、被る損害や危険を最小限に抑えることができる。

一般的にシステムの可用性を向上させるには、そのシステムを構成する部品を冗長化することが重要である。そのような高可用化システムとして、クラスタが利用されるケースが多い。クラスタにおいては、２台以上のノードを使用して冗長化し、一台を現用系として動作させ、残りを待機系とすることで、何らかの原因で現用系が動作不能になった場合に待機系がその処理を引き継ぐことができる。このようなクラスタはフェイルオーバ型クラスタと呼ばれている。

フェイルオーバ型のクラスタでは、一台のノードを現用系として動作させ、残りのノードを待機系とすることで、何らかの原因で現用系が動作不能になった場合に待機系がその処理を引き継ぐような構成をとっている。また、１台の管理ノード上で動作するプロセスがクラスタ全体を管理しており、管理ノード以外のノードに障害が発生したとしても、障害が発生したノードを切り放すことでシステムの処理を継続できる可用性を備えているシステムもある（たとえば、下記特許文献１を参照。）。

特開２００４−２６４９１１号公報

しかしながら、上述したクラスタでは、待機系のノードは現用系のノードに障害が発生するまでは稼働せずに待機し続けているため、余分な資源を用意しなければならないという問題があった。すなわち、たとえば、ノードとなる２台のサーバでフェイルオーバ型のクラスタを構築したとしても、１台分しか稼働していないことになる。

また、待機系のノードを用意せずに、クラスタ全体を一台のノード（管理ノード）で管理しているクラスタにおいては、管理ノードに障害が発生した場合には、クラスタ全体の運用を継続することができなくなってしまうという問題があった。これはいわゆる“Ｓｉｎｇｌｅ Ｐｏｉｎｔ ｏｆ Ｆａｉｌｕｒｅ”と言われている問題であり、クラスタの構成要素（ノード）を冗長化、すなわち、余分な待機系のノードを用意しなければならないという問題があった。

この発明は、上述した従来技術による問題点を解消するため、無駄な待機系ノードを用いずにクラスタの運用管理を円滑に引き継ぐことにより可用性の向上を図ることができるクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタを提供することを目的とする。

上述した課題を解決し、目的を達成するため、この発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、およびクラスタ管理方法は、複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理プログラム、該プログラムを記録した記録媒体、およびクラスタ管理方法であって、前記複数のノードのうち自ノードを除く他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出し、前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定し、前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動することを特徴とする。

この発明によれば、管理ノードに選ばれたノードに換わって、当該ノード以外のいずれかのノードがクラスタの管理処理を実行することができる。

また、上記発明において、前記管理ノードに選ばれたノードから配信された前記クラスタ内のノードの負荷情報を取得し、前記管理ノードに選ばれたノードの停止が検出された場合、取得された負荷情報に基づいて、前記自ノードを前記管理ノードに決定することとしてもよい。

この発明によれば、あらたに管理ノードとなり得る候補が複数ある場合であっても、ノードごとに管理ノードの決定処理をおこなうことができる。

また、上記発明において、さらに、前記他ノードから当該他ノードが前記管理ノードに決定されなかった旨の否決情報を取得し、さらに、取得された否決情報に基づいて、前記自ノードを前記管理ノードに決定することとしてもよい。

この発明によれば、管理ノードの決定処理において自ノードとの比較対象となる他ノード数を削減することができる。

また、上記発明において、前記自ノードが前記管理ノードに決定されなかった場合、前記他ノードに前記自ノードの否決情報を送信することとしてもよい。

この発明によれば、他ノードにおける管理ノードの決定処理において当該他ノードとの比較対象から自ノードを排除することができる。

また、上記発明において、停止の検出に先立って、前記管理ノードに選ばれたノードから前記クラスタの管理に関する第１のクラスタ情報を受信し、前記自ノードが前記管理ノードに決定された場合、受信された第１のクラスタ情報を用いて、停止が検出されたノードを除いたクラスタの管理に関する第２のクラスタ情報を生成し、生成された第２のクラスタ情報を、前記自ノードのメモリに格納し、生成された第２のクラスタ情報を、前記検出工程によって停止が検出されたノードを除く他ノードに配信することとしてもよい。

この発明によれば、自ノードが管理ノードに決定された場合、旧管理ノードからクラスタの管理処理を円滑に引き継ぐことができる。

また、上記発明において、前記自ノードが前記管理ノードに決定された場合、前記自ノードが提供しているサービスの起動要求を前記他ノードにおこなって、いずれかの前記他ノードからの前記サービスの起動応答を受け付けることとしてもよい。

この発明によれば、管理ノードに決定された自ノードにおいて提供されていたサービスを他ノードにマイグレートすることができる。

また、上記発明において、前記管理ノードの指定を受け付け、前記管理ノードに指定されなかった場合、前記他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出することとしてもよい。

この発明によれば、管理ノードに指定されなかったいずれのノードからも、管理ノードに選ばれたノードの停止（故障）を監視することができる。

また、上記発明において、前記管理ノードに指定された場合、前記自ノードによる前記管理処理を起動することとしてもよい。

この発明によれば、管理ノードに指定されることにより、いずれのノードも管理ノードとして稼働することができる。

また、この発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、およびクラスタ管理方法は、複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理プログラム、該プログラムを記録した記録媒体、およびクラスタ管理方法であって、前記管理ノードの指定を受け付け、前記管理ノードに指定された場合、自ノードによる前記管理処理を起動し、前記管理処理が起動された場合、前記クラスタの管理に関するクラスタ情報を生成し、生成されたクラスタ情報を自ノードのメモリに格納し、生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信することを特徴とする。

この発明によれば、管理ノードに指定されることにより、いずれのノードも管理ノードとして稼働することができる。また、全ノードにクラスタ情報を格納、配信しておくことにより、自ノードの管理処理または自ノード自体が停止した場合であっても、クラスタの管理処理を引き継ぐことができる。

また、上記発明において、前記自ノードによる前記管理処理が停止したか否かを検出し、格納されたクラスタ情報を用いて、停止が検出された管理処理を再起動することとしてもよい。

この発明によれば、他ノードに管理ノードの決定処理をさせることなく、自ノードみずから管理ノードに復帰して、クラスタの管理処理を再度実行することができる。

また、この発明にかかるノードは、複数のノードからなるクラスタ内のノードであって、前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードに選ばれたノードが、停止したか否かを検出し、前記管理ノードに選ばれたノードの停止が検出された場合、前記管理ノードに決定し、前記管理ノードに決定された場合、前記管理処理を起動することを特徴とする。

この発明によれば、管理ノードに選ばれたノードに換わってクラスタの管理処理を実行することができる。

また、この発明にかかるノードおよび複数のノードからなるクラスタは、前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードの指定を受け付け、前記管理ノードに指定された場合、前記管理処理を起動し、前記管理処理が起動された場合、前記クラスタ内の全ノードの管理に関するクラスタ情報を生成し、生成されたクラスタ情報をメモリに格納し、生成されたクラスタ情報を、前記複数のノードのうち自ノードを除く他ノードに配信することを特徴とする。

この発明によれば、管理ノードに指定されることにより、いずれのノードも管理ノードとして稼働することができる。また、全ノードにクラスタ情報を格納、配信しておくことにより、自ノードの管理処理または自ノード自体が停止した場合であっても、クラスタの管理処理を引き継ぐことができる。

本発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタによれば、無駄な待機系ノードを用いずにクラスタの運用管理を円滑に引き継ぐことにより可用性の向上を図ることができるという効果を奏する。

以下に添付図面を参照して、この発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタの好適な実施の形態を詳細に説明する。

（クラスタシステムのシステム構成）
まず、この発明の実施の形態にかかるクラスタシステムのシステム構成について説明する。図１は、この発明の実施の形態にかかるクラスタシステムのシステム構成図である。図１において、クラスタシステム１００は、クラスタ１０１とクライアント１０２とがインターネット、ＬＡＮ、ＷＡＮなどのネットワーク１０３を介して相互に交信可能に接続されている。クラスタ１０１は、複数のノード（図１では５台）１１１〜１１５によって構成されており、クライアント１０２に対して各種サービスを提供する。たとえば、各ノード１１１〜１１５は、ファイアウォールサーバ、メールサーバ、データベースサーバ、Ｗｅｂサーバ、アプリケーションサーバとして機能するコンピュータ装置である。

また、各ノード１１１〜１１５は、それぞれ上述した各種サービスを提供するほか、クラスタ１０１全体を管理する管理ノードとして稼働することができ、管理ノードに選ばれた場合には、管理ノードとして稼働する。また、各ノード１１１〜１１５は、自ノード以外の他ノードの中から管理ノードが選ばれた場合には、管理ノードとして稼働しているノードによって管理される。

（ノード１１１〜１１５およびクライアント１０２のハードウェア構成）
つぎに、この発明の実施の形態にかかるノード１１１〜１１５およびクライアント１０２（以下、「ノード１１１〜１１５等」という。）のハードウェア構成について説明する。図２は、この発明の実施の形態にかかるノード１１１〜１１５等のハードウェア構成を示すブロック図である。図２において、ノード１１１〜１１５等は、ＣＰＵ２０１と、ＲＯＭ２０２と、ＲＡＭ２０３と、ＨＤＤ（ハードディスクドライブ）２０４と、ＨＤ（ハードディスク）２０５と、ＦＤＤ（フレキシブルディスクドライブ）２０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）２０７と、ディスプレイ２０８と、Ｉ／Ｆ（インターフェース）２０９と、キーボード２１０と、マウス２１１と、スキャナ２１２と、プリンタ２１３と、を備えている。また、各構成部はバス２００によってそれぞれ接続されている。

ここで、ＣＰＵ２０１は、ノード１１１〜１１５等の全体の制御を司る。ＲＯＭ２０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。ＨＤＤ２０４は、ＣＰＵ２０１の制御にしたがってＨＤ２０５に対するデータのリード／ライトを制御する。ＨＤ２０５は、ＨＤＤ２０４の制御で書き込まれたデータを記憶する。

ＦＤＤ２０６は、ＣＰＵ２０１の制御にしたがってＦＤ２０７に対するデータのリード／ライトを制御する。ＦＤ２０７は、ＦＤＤ２０６の制御で書き込まれたデータを記憶したり、ＦＤ２０７に記憶されたデータをノード等に読み取らせたりする。

また、着脱可能な記録媒体として、ＦＤ２０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ２０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ２０８は、たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ２０９は、通信回線を通じてインターネットなどのネットワーク１０３に接続され、このネットワーク１０３を介して他の装置に接続される。そして、Ｉ／Ｆ２０９は、ネットワーク１０３と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ２０９には、たとえばモデムやＬＡＮアダプタなどを採用することができる。

キーボード２１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス２１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ２１２は、画像を光学的に読み取り、ノード１１１〜１１５等内に画像データを取り込む。なお、スキャナ２１２は、ＯＣＲ機能を持たせてもよい。また、プリンタ２１３は、画像データや文書データを印刷する。プリンタ２１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（ノードの機能的構成）
つぎに、この発明の実施の形態にかかるクラスタ１０１を構成するノード１１１〜１１５の機能的構成について説明する。図３は、この発明の実施の形態にかかるクラスタ１０１を構成する各ノード１１１〜１１５の機能的構成を示すブロック図である。図３において、各ノード１１１〜１１５は、検出部３０１と、取得部３０２と、決定部３０３と、起動部３０４と、送信部３０５と、受信部３０６と、生成部３０７と、格納部３０８と、メモリ３０９と、配信部３１０と、マイグレート部３１１と、指定部３１２と、から構成されている。

まず、検出部３０１は、複数のノード１１１〜１１５のうち自ノードを除く他ノードの中から管理ノードに選ばれたノードが停止したか否かを検出する。自ノードとは、複数のノード１１１〜１１５の中から任意に着目したノードであり、他ノードとは、複数のノード１１１〜１１５のうち自ノードを除いたノードである。また、管理ノードは、他ノードの中から選ばれたノードである。たとえば、自ノードが、図１に示したノード１１５である場合、他ノードはノード１１１〜１１４となる。また、管理ノードは、他ノード（ノード１１１〜１１４）の中から管理ノードに選ばれたノード１１１とすることができる。

検出部３０１による検出手法としては、たとえば、ｐｉｎｇツールを用いることができる。たとえば、自ノードから管理ノードに対してｐｉｎｇツールによるエコー要求を送信し、管理ノードからエコー要求に対するエコー応答がなかった場合、管理ノードに選ばれたノードが停止（ダウン）していることを検出することができる。

また、取得部３０２は、管理ノードに選ばれたノードから配信されたクラスタ１０１内のノード１１１〜１１５の動作状況に関する情報を取得する。ここで、負荷情報とは、自ノードを含むクラスタ１０１内のノードのＣＰＵ使用率やメモリ使用率などのリソース情報や、当該ノードのサービスの提供数など、ノードにかかっている負荷を示す情報である。

また、取得部３０２は、他ノードから当該他ノードが管理ノードに決定されなかった旨の否決情報を取得する。取得部３０２は、これらの情報を、他ノードからの定期的な配信によって取得したり、また、他ノードにおける所望のタイミングで送信された場合に取得することとしてもよい。さらに、取得部３０２からの要求に応じて他ノードから取得することとしてもよい。

また、決定部３０３は、自ノードを管理ノードに決定する。具体的には、たとえば、検出部３０１によって管理ノードに選ばれたノードの停止が検出された場合、自ノードを管理ノードに決定する。また、他ノードも同時に管理ノードに選ばれたノードを監視している場合には、当該他ノードも管理ノードに選ばれたノードの停止を検出することとなる。管理ノードは１台でよいため、管理ノードの候補となるノードが複数存在する場合には、優先順位によって決定する。

たとえば、取得部３０２によって取得された負荷情報を用いて、自ノードの負荷情報が所定のしきい値以下である場合、自ノードを管理ノードに決定することができる。また、他ノードの負荷情報と比較して、自ノードの負荷情報が他ノードの負荷情報よりも低い、すなわち、負荷が最も少ない場合に、自ノードを他ノードに優先して管理ノードに決定することができる。また、取得部３０２により他ノード内のノードからの否決情報が取得された場合、当該ノードの負荷情報を、自ノードの負荷情報との比較対象から除くこととしてもよい。

また、起動部３０４は、決定部３０３によって管理ノードに決定された場合、自ノードによる管理処理を起動する。具体的には、管理ノードに決定された場合、自ノードが有するクラスタ１０１の管理プロセス（後述するノードコーディネータ）を立ち上げる。

また、送信部３０５は、決定部３０３によって自ノードが管理ノードに決定されなかった場合、他ノードに自ノードの否決情報を送信する。他ノードにおいても、図３に示した機能的構成と同一構成を有しているため、送信部３０５から送信された自ノードの否決情報を、他ノードにおける取得部３０２が取得して、自ノードの場合と同様、他ノードにおける管理ノードの決定処理に用いることができる。

また、受信部３０６は、検出部３０１による停止の検出に先立って、管理ノードに選ばれたノードからクラスタ１０１の管理に関するクラスタ情報を受信する。クラスタ情報とは、クラスタ１０１の運用管理に必要な情報であれば何でも良く、後述するように、たとえば、各ノード１１１〜１１５のサービス内容を示すサービスリスト、各ノード１１１〜１１５のＩＰアドレス（実ＩＰアドレス）と仮想ＩＰアドレスとを対応させた変換テーブル、各ノード１１１〜１１５が現在行っているサービス内容と仮想ＩＰアドレスとを対応させたタスクリストなどが挙げられる。

管理ノードに選ばれたノードでは、上述したクラスタ１０１の管理プロセスが立ち上がっているため、当該管理プロセスによって生成されたクラスタ情報が、管理ノードに選ばれたノードからクラスタ１０１内の全ノード１１１〜１１５に配信され、受信部３０６は、配信されたクラスタ情報を受信する。これにより、管理ノードに選ばれたノードが故障などにより停止（ダウン）した場合であっても、管理ノードに選ばれたノードが管理ノードに決定された場合、受信されたクラスタ情報を用いて、クラスタ１０１の運用管理を引き継ぐことができる。

また、生成部３０７は、決定部３０３によって自ノードが管理ノードに決定された場合、受信部３０６によって受信されたクラスタ情報（以下、「第１のクラスタ情報」という。）を用いて、検出部３０１によって停止が検出されたノード（障害ノード）を除いたクラスタ１０１の管理に関する第２のクラスタ情報を生成する。管理ノードに選ばれたノードが停止しているため、第２のクラスタ情報による運用管理対象となるのは、停止が検出されたノードを除いたノードである。

たとえば、管理ノードに選ばれたノードがノード１１１であり、このノード１１１の停止が検出され、あらたに管理ノードに決定されたノードが自ノード１１５であるとすると、第２のクラスタ情報による管理対象となるノードは、ノード１１１を除いたノード１１２〜１１５である。

また、格納部３０８は、生成部３０７によって生成された第２のクラスタ情報を、自ノードのメモリ３０９に格納する。具体的には、たとえば、後述するように、自ノードのノードコーディネータから自ノードのノードデーモンに引き渡すことで、自ノードのメモリ３０９に格納する。

また、配信部３１０は、生成部３０７によって生成された第２のクラスタ情報を、検出部３０１によって停止が検出されたノードを除く他ノードに配信する。上述の例では、自ノード１１５は、停止が検出されたノード１１１を除く他ノード１１２〜１１４に配信する。

また、マイグレート部３１１は、決定部３０３によって自ノードが管理ノードに決定された場合、自ノードが提供しているサービスの起動要求を他ノードにおこなう。そして、いずれかの他ノードからのサービスの起動応答を受け付ける。これにより、管理ノードに決定されるまでにおこなっていたサービスを他ノードに移行することができる。また、他ノードからの起動応答を受けた場合、自ノードのサービスを削除することとしてもよい。これにより、管理ノードに決定された自ノードの管理プロセス（ノードコーディネータ）が起動したことによる過負荷を軽減することができる。

つぎに、自ノードが管理ノードに選ばれる場合について説明する。指定部３１２は、管理ノードの指定を受け付ける。具体的には、たとえば、オペレータが図２に示したキーボード２１０やマウス２１１を操作することにより、管理ノードの指定を受け付けることができる。この指定により、自ノードが管理ノードに選ばれることとなる。なお、指定部３１２によって管理ノードに指定されなかった場合、検出部３０１は、他ノードの中から管理ノードに選ばれたノードが停止したか否かを検出することとなる。

一方、指定部３１２によって管理ノードに指定された場合、起動部３０４は、自ノードによる管理処理、すなわち、クラスタ１０１の管理プロセス（ノードコーディネータ）を起動する。これにより自ノードが管理ノードとなる。そして、生成部３０７は、上述した場合と同様、起動部３０４によって管理処理が起動された場合、クラスタ１０１の管理に関する第１のクラスタ情報を生成する。

また、格納部３０８も、上述した場合と同様、生成部３０７によって生成された第１のクラスタ情報を自ノードのメモリ３０９に格納し、配信部３１０は、生成部３０７によって生成された第１のクラスタ情報を、複数のノード１１１〜１１５のうち自ノードを除く他ノードに配信する。

この状態において、自ノードは、他ノードの検出部３０１により自ノードの停止の有無が監視されることとなる一方、自ノード自身も、自ノードの検出部３０１が、自ノードの管理処理、具体的には、自ノードによるクラスタ１０１の管理プロセス（ノードコーディネータ）が停止したか否かを検出する。

この場合、起動部３０４は、格納部３０８によって格納されたクラスタ情報を用いて、検出部３０１によって停止が検出された管理処理、具体的には、自ノードによるクラスタ１０１の管理プロセス（ノードコーディネータ）を再起動する。具体的には、自ノードのノードデーモンからメモリ３０９に格納されたクラスタ情報を呼び出すことにより、管理処理を再起動することができる。

なお、上述した検出部３０１、取得部３０２、決定部３０３、起動部３０４、送信部３０５、受信部３０６、生成部３０７、格納部３０８、配信部３１０、マイグレート部３１１、および指定部３１２は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体に記録されたプログラムを、ＣＰＵ２０１が実行することによって、またはＩ／Ｆ２０９によって、その機能を実現する。また、メモリ３０９は、具体的には、たとえば、図２に示したＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０５などの記録媒体によって、その機能を実現する。

つぎに、上述したクラスタ１０１の具体的な構成例について説明する。図４は、クラスタ１０１の具体的な構成例を示す説明図である。図４において、クラスタ１０１を、自律機能による効率的な運用を実現する自律運用システムとして説明する。

このクラスタ１０１は、サービスを運用中の全ノード１１１〜１１５が管理ノードになり得るため、余分な資源であるアイドル状態の待機系ノードを用意すること無く、可用性を向上させることが可能となる。

このクラスタ１０１では、クラスタ１０１内のノード１１１〜１１５を仮想化し、全ての通信を仮想化されたＩＰアドレス（仮想ＩＰ、Ｖｉｒｔｕａｌ ＩＰ、以下、「ＶＩＰ」という。）によっておこなう。これにより、実際のノード（実ノード）１１１〜１１５とクライアント１０２のアプリケーションが操作する仮想ノードとを切り放し、クライアント１０２のアプリケーションからノード１１１〜１１５の構成の変化や故障などを隠蔽することができる。また、クライアント１０２のアプリケーションに割り当てるノード数を自律的に制御することによって、柔軟かつ効率的なリソース管理を実現することができる。

なお、実ノードとは、物理的なノード１１１〜１１５であり、各（実）ノード１１１〜１１５には実際のＩＰアドレス（実ＩＰ、Ｒｅａｌ ＩＰ、以下「ＲＩＰ」という。）が割り当てられている。管理ノードも実ノードの一つである。また、仮想ノードとは、管理ノード上に生成された仮想的なノードで、クライアント１０２のユーザアプリケーションに見せるＶＩＰを提供する。また、管理ノードは、クラスタ１０１外のクライアント１０２（図１を参照）からのＶＩＰ（仮想ノード）宛のリクエストを受け取るノードである。図４では現在の管理ノードをノード１１１とする。以下、仮想ノードと区別するため、ノード１１１〜１１５を実ノード１１１〜１１５と記述することもある。

これにより、たとえば、ノード１１３は、クラスタ１０１内における実際のＩＰアドレス（ＲＩＰ）が「ＲＩＰ３」である実ノードであるが、クライアント１０２から見ると、仮想的なＩＰアドレス（ＶＩＰ）が「ＶＩＰ３」である仮想ノードとなる。

また、図４中、ＮＣはノードコーディネータであり、仮想ノードと実ノード１１１〜１１５のマッピングを管理するデーモンプロセスである。ノードコーディネータＮＣは管理ノード上で動作するプロセスであり、ＩＰ変換テーブル５００を含むクラスタ情報４００を生成・管理している。ここで、ＩＰ変換テーブル５００について説明する。図５は、ＩＰ変換テーブル５００を示す説明図である。

図５において、ＩＰ変換テーブル５００は、実ノードごとに、ＲＩＰとＶＩＰとが対応付けられている。ＩＰ変換テーブル５００は、ＶＩＰからＲＩＰを検索するためのテーブルである。仮想ノードと実ノードのマッピングを変更することができるため、ユーザは実ノードの構成や台数を知ることなく、クライアント１０２からアプリケーションを動作させることができる。

また、仮想ノードに実ノードをマッピングする場合には、一つの仮想ノードに対して複数の実ノードをマッピングすることができる。つまり、仮想ノードへのリクエストを複数の実ノードに分散することによってロードバランシング型のクラスタ１０１を構成することができる。複数の仮想ノードをユーザのクライアント１０２に対して提供することによって、複数のノード１１１〜１１５からなるクラスタ１０１として見せることができる。そのためユーザはＨＰＣ型のアプリケーションを動作させることが可能となる。

また、図４において、ノードコーディネータＮＣはＩＰ変換テーブル５００のマスタテーブルを操作できる唯一のプロセスである。管理ノード（ノード１１１）のオペレータはノードコーディネータＮＣに対して実ノードの割り当てを要求する。ノードコーディネータＮＣはＩＰ変換テーブル５００のエントリを変更し、全ての実ノード１１１〜１１５に対してＩＰ変換テーブル５００のコピーを配信する。これによってＩＰ変換テーブル５００のコンシステンシを保つことができる。また、ノードコーディネータＮＣは実ノード１１１〜１１５の状態を監視して、仮想ノードが割り当てられた実ノード１１１〜１１５の負荷が増大すると、負荷を分散させるために新たな実ノード１１１〜１１５を割り当てる機能を持っている。反対に負荷が減少した場合には、割り当てていた実ノードを解放する。

また、ノードコーディネータＮＣは、サービスリストの登録とタスクリストの作成をおこなう。図６は、サービスリストの一例を示す説明図である。サービスリスト６００は、サービスＩＤとサービス内容とを対応させたリストである。図７は、タスクリストの一例を示す説明図である。タスクリスト７００は、各ノード１１１〜１１５が現在行っているサービス内容のサービスＩＤと仮想ＩＰアドレス（ＶＩＰ）とを対応させたリストである。

図５〜図７に示したように、サービス内容と、ＶＩＰと、ＲＩＰとを関連付けることにより、どの実ノードがどの仮想ノードとしてどのようなサービスを提供しているかを、ノードコーディネータＮＣは把握することができる。なお、図５〜図７に示したＩＰ変換テーブル５００、サービスリスト６００、およびタスクリスト７００がクラスタ情報４００となる。

また、図４中、ＮＤは、ノードデーモン（Ｎｏｄｅ Ｄａｅｍｏｎ）であり、ノードコーディネータＮＣからの指示にしたがってＶＮＩＣを設定するデーモンプロセスである。ノードデーモンＮＤは、各実ノード１１１〜１１５に常駐し、ノードコーディネータＮＣによって配信されたＩＰ変換テーブル５００のコピーを受信する。ノードデーモンＮＤは受信したＩＰ変換テーブル５００をＶＮＩＣに引き渡す。また、ノードデーモンＮＤはその自ノードがサービスに割り当てられた場合に、ＶＮＩＣによって転送されてきたＶＩＰ宛のパケットを受け取るためのトンネルデバイスを設定する。自ノードがサービスから削除された場合は、トンネルデバイスの削除処理をおこなう。

また、図４中、各ノード１１１〜１１５に備えられているＶＮＩＣは、バーチャルネットワークインターフェースカード（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）であり、ＩＰ変換テーブル５００にしたがって、ＶＩＰ（仮想ノード）宛のパケットをＲＩＰ（実ノード）宛に書き換えるカーネルモジュールである。ＶＮＩＣは管理ノードを含む全ての実ノード１１１〜１１５に備えられている。

ＶＮＩＣにより、仮想ノード間の通信に関して実ノード１１１〜１１５間のインターコネクトを利用することが可能となる。ＶＮＩＣは大きく分けて２つの処理からなる。一方はクラスタ１０１外部のクライアント１０２からのパケットをクラスタ１０１内部のノード１１１〜１１５に転送する処理である。これはＷｅｂサーバなどの前段に設置されるロードバランサと同様の働きをする。他方は任意のノードからのパケットを当該ノード以外のノードに転送する処理である。これによって、クラスタ１０１内のノード間通信を行うことができる。

すなわち、ＶＮＩＣを用いることにより、クラスタ１０１外のクライアント１０２からのＶＩＰ宛のパケットはそのＶＩＰを提供する管理ノード（に選ばれたノード１１１）が受け取る。パケットを受け取ったノード１１１は，パケットの宛先アドレスとポート番号をキーとしてＩＰ変換テーブル５００を検索する。検索にヒットするとエントリに登録されているＲＩＰに対してパケットを送出する。ヒットしなければ通常のパケットとして受理する。このように、一つのＶＩＰに対して複数のＲＩＰを登録することによって、ロードバランサとして機能させることができる。

また、ＶＮＩＣを用いることにより、クラスタ１０１内部のノード間通信を実現することもできる。クラスタ１０１内の実ノード１１１〜１１５はユーザアプリケーションが動作している。ユーザアプリケーションがノード間通信を行う時にはＶＩＰによってノードを識別する。ＶＮＩＣはこのＶＩＰが割り当てられている実ノード１１１〜１１５にパケットを転送する。

各ノード１１１〜１１５内で生成されたＶＩＰ宛のパケットは、ＶＩＰとポート番号をキーとしてＩＰ変換テーブル５００を検索し、パケットの宛先ＲＩＰを得ることができる。この場合にも複数のＲＩＰを登録することによってノード間通信にもロードバランシングを適用することができる。つまり、各ノード１１１〜１１５は独立してロードバランサとしての機能を提供することができる。

また、図４において、クラスタ１０１は、ユーザアプリケーションがクラスタ１０１内の実ノード１１１〜１１５を直接操作することを禁止している。これはクライアント１０２のユーザアプリケーションには仮想ノードだけを提供し、実ノード１１１〜１１５を隠蔽するためである。仮想ノードは適切な実ノード１１１〜１１５にマッピングされ、ユーザアプリケーションは実ノード１１１〜１１５上で実行される。マッピングはＩＰアドレスとポート番号の組によって管理する。このマッピングにより仮想ノードへのアクセスは実ノード１１１〜１１５へのアクセスに変換され、ユーザアプリケーションにはあたかも仮想ノード上で動作しているように見せている。

また、図４において、全ての実ノード１１１〜１１５でコンシステンシを保つため、ノードコーディネータＮＣにおいてクラスタ情報４００が更新された場合、あらたなクラスタ情報４１０を各実ノード１１１〜１１５に配布する。更新されたクラスタ情報４１０は、その種類を示す更新リクエストと共に配布される。具体的な更新リクエストと配布タイミングの一覧を表１に示す。

クラスタ情報４１０の配布方式には、たとえば、ブロードキャストによる方式と各ノードデーモンＮＤに対してＴＣＰコネクションを張ってpoint-to-pointで行う方式の２通りが考えられる。前者は各ノードデーモンＮＤがブロードキャストを受け取って各ＶＮＩＣ内のＩＰ変換テーブル５００を更新する処理を並列に行うことができる。そのためには、全ての実ノード１１１〜１１５がノードコーディネータＮＣと同じセグメント内に存在している必要がある。

一方、後者は異なるセグメントに存在する実ノード１１１〜１１５にも確実にＩＰ変換テーブル５００のコピーを送ることができる。更新リクエストを受け取った各ノードデーモンＮＤは、更新リクエストの内容を解析して自らが保持しているクラスタ情報４００から、更新されたクラスタ情報４１０を反映する。クラスタ情報４１０が反映されると、ＩＰ変換テーブル５００は、カーネルモジュールであるＶＮＩＣに通知される。

（クラスタ管理処理手順）
つぎに、この発明の実施の形態にかかるクラスタ管理処理手順について説明する。図８は、この発明の実施の形態にかかるクラスタ管理処理手順を示すフローチャートである。図８のフローチャートでは、クラスタ１０１内の任意のノードを自ノードとして、当該自ノードによるクラスタ管理処理手順を示している。

まず、指定部３１２により管理ノードに指定されたか否かを判断する（ステップＳ８０１）。管理ノードに指定された場合（ステップＳ８０１：Ｙｅｓ）、自ノードのノードコーディネータＮＣを起動して（ステップＳ８０２）、サービス登録処理（ステップＳ８０３）およびノード割り当て処理（ステップＳ８０４）を実行する。サービス登録処理およびノード割り当て処理は、具体的には、図３に示した生成部３０７、より具体的には、自ノードのノードコーディネータＮＣによって実行する。そのあと、サービスの起動リクエストが送られ、ノードコーディネータＮＣはノードスケジューリングを実行する（ステップＳ８０５）。ノードスケジューリングについては後述する。

一方、管理ノードに指定されなかった場合（ステップＳ８０１：Ｎｏ）、他ノードの中から管理ノードが選ばれ、自ノードは管理ノード決定処理を実行する（ステップＳ８０６）。そして、管理ノード決定処理により管理ノードに決定されると、自ノードのノードコーディネータＮＣを起動し（ステップＳ８０７）、クラスタ情報４００の再構築処理を実行する（ステップＳ８０８）。ここで、管理ノード決定処理は、図３に示した指定部３１２、取得部３０２、決定部３０３および配信部３１０によって実行する。また、再構築処理は、起動部３０４、生成部３０７、配信部３１０およびマイグレート部３１１によって実行する。

そのあと、自ノードが停止したか否かを自ノードみずから判断する（ステップＳ８０９）。そして、自ノードが停止した場合（ステップＳ８０９：Ｙｅｓ）、一連の処理を終了する。具体的には、たとえば、故障により自ノードがダウンした場合や、オペレータの操作により自ノードの起動を終了した場合が該当する。この場合、他ノードの検出部３０１により、管理ノードである自ノードの停止が検出され、他ノードにおいてステップＳ８０６〜Ｓ８０８の処理が実行されることとなる。

また、ステップＳ８０９において、自ノードが停止していない場合（ステップＳ８０９：Ｎｏ）、ノードコーディネータＮＣが停止したか否かを判断する（ステップＳ８１０）。ノードコーディネータＮＣが停止していなければ（ステップＳ８１０：Ｎｏ）、ステップＳ８０５に移行する。

また、ステップＳ８１０において、自ノードのノードコーディネータＮＣが停止した場合（ステップＳ８１０：Ｙｅｓ）、起動部３０４によりノードコーディネータＮＣを再起動する（ステップＳ８１１）。そして、ノードデーモンＮＤ、具体的にはメモリ３０９からクラスタ情報４００を抽出し（ステップＳ８１２）、ステップＳ８０５に移行する。

つぎに、図８で示したサービス登録処理（ステップＳ８０３）について説明する。図９は、図８で示したサービス登録処理（ステップＳ８０３）を示すＵＭＬのシーケンス図である。図９において、オペレータからのサービスの登録要求を受け取る（ステップＳ９０１）と、ノードコーディネータＮＣは、サービスにＶＩＰを割り当てて，サービスリスト６００としてメモリ３０９上に蓄えることにより、サービス登録をおこなう（ステップＳ９０２）。サービス登録にはサービス記述ファイルと呼ばれるＸＭＬ文書を指定する。

図１０は、サービス記述ファイルの一例を示す説明図である。図１０に示したサービス記述ファイル１０００において、左端の番号は行番号である。このサービス記述ファイル１０００の３行目と４行目には、“web”という名称のサービスがＴＣＰの“80”番ポートを監視していることが記述されている。また、５行目には、サービスを起動／停止するためのスクリプトが記述されている。また、６行目には、リソースの競合が発生した場合の優先順位を決定するための優先度が記述されている。

また、７行目からの“svc:SLA”は、自律制御の動作を指定するための記述であり、データ種別とそのしきい値を条件式の形で表したものである。ここでは、ノード数とＣＰＵ使用率がデータ種別として示されている。それぞれの条件式はレベル付けされており、レベルが低い方から順に評価していく。評価結果が“偽”となった場合は、その直前のレベルをサービスレベルとする。複数のアプリケーションが登録されている場合には、全てのアプリケーションで“真”となるサービスレベルが決定される。ノードコーディネータＮＣはサービスレベルが最大となるように、サービスに割り当てる実ノード数を制御する。

また、図９において、サービス登録（ステップＳ９０２）が完了した場合、作成されたサービスリスト６００を自ノードのノードデーモンＮＤに配布する（ステップＳ９０３）。具体的には、自ノードのメモリ３０９にサービスリスト６００を格納するとともに、他ノードのノードデーモンＮＤにサービスリスト６００を配信する。ノードコーディネータＮＣは各ノードデーモンＮＤから配布完了の通知を受け取る（ステップＳ９０４）と、オペレータに対し登録完了を通知する（ステップＳ９０５）。これにより、サービス登録処理（ステップＳ８０３）が完了する。

つぎに、図８で示したノード割り当て処理（ステップＳ８０４）について説明する。図１１は、図８で示したノード割り当て処理（ステップＳ８０４）を示すＵＭＬのシーケンス図である。図１１において、オペレータは、ノードコーディネータＮＣに対して実ノードの割り当てを要求する（ステップＳ１１０１）。そして、サービス名と割り当てて欲しい実ノード数を選択する（ステップＳ１１０２）。

ノードコーディネータＮＣは、割り当て可能な実ノードから、要求された数分の実ノードをＩＰ変換テーブル５００に記録することにより、ＩＰ変換テーブル５００を更新し、ＩＰ変換テーブル５００をノードデーモンＮＤに配布する（ステップＳ１１０３）。具体的には、サービスリスト６００と同様、自ノードのメモリ３０９にＩＰ変換テーブル５００を格納するとともに、他ノードのノードデーモンＮＤにＩＰ変換テーブル５００を配信する。

そのあと、自ノードを含む各ノードのノードデーモンＮＤは、それぞれＶＮＩＣに対し、受け取ったＩＰ変換テーブル５００の設定をおこなうとともに（ステップＳ１１０４）、各ＶＮＩＣに対しトンネルデバイスの設定をおこなう（ステップＳ１１０５）。各ノード１１１〜１１５のＶＮＩＣにおいてトンネルデバイスの設定が完了した場合、各ノードデーモンＮＤは、管理ノードである自ノードのノードコーディネータＮＣにＩＰ変換テーブル５００の配布完了を通知し（ステップＳ１１０６）、オペレータにノード割り当ての登録完了を通知する（ステップＳ１１０７）。これにより、実ノード割り当て処理（ステップＳ８０４）が完了する。

つぎに、図８に示したノードスケジューリング（ステップＳ８０５）について具体的に説明する。ノードスケジューリングでは、ノードコーディネータＮＣは、サービスの起動要求を受け取ると割り当てられた実ノード１１１〜１１５上でサービスを起動してサービス提供状態に入る。サービス提供状態に入ると、ノードコーディネータＮＣは全ての実ノード１１１〜１１５と仮想ノードの状態を監視して、与えられたＳＬＡの条件式にしたがってノードの割り当てを行う。これがノードスケジューリング（機能）である。

ノード１１１〜１１５の負荷が変化した場合には、ノードスケジューリング機能によって実ノード数の割り当てを自律的に変更して、クラスタ１０１全体で最適な状態を保つように動作する。Ｗｅｂサーバのようなスケールアウト型アプリケーションではノードスケジューリング機能を利用することができる。

また、ノードスケジューリング機能は、ＩＰ変換テーブル５００に登録されたＲＩＰの数を変更することで実現される。ＲＩＰを増加させる時には、ノード割り当て可能な実ノード１１１〜１１５を選択してＩＰ変換テーブル５００に割り当てるＲＩＰを追加する。この時、ＶＩＰの実ノードを増やす場合には、そのノード上でサービスを起動する。反対に実ノードを削除する場合には、その実ノード上のサービスを停止した後でＩＰ変換テーブル５００に登録されているＲＩＰを削除する。このノードスケジューリング機能により、図７に示したタスクリスト７００を作成するとともに、タスクリスト７００を動的に変更することができる。このようにしてノードスケジューリング（ステップＳ８０５）が実現される。

つぎに、図８に示した管理ノード決定処理について説明する。図１２は、管理ノード決定処理を示すフローチャートである。図８において、自ノードが管理ノードでない場合、検出部３０１により、管理ノードの停止が検出されるまで管理ノードの監視をおこない（ステップＳ１２０１：Ｎｏ）、取得部３０２により、管理ノードの停止が検出された場合（ステップＳ１２０１：Ｙｅｓ）、他ノードから負荷情報または否決情報を取得する（ステップＳ１２０２）。

このあと、決定部３０３により、ステップＳ１２０２で取得した情報を用いて、管理ノードの決定処理を実行する（ステップＳ１２０３）。管理ノードに決定された場合（ステップＳ１２０４：Ｙｅｓ）、ステップＳ８０７に移行して、自ノードのノードコーディネータＮＣを起動する。一方、管理ノードに決定されなかった場合（ステップＳ１２０４：Ｎｏ）、配信部３１０により、否決情報を他ノードに配信して（ステップＳ１２０５）、一連の処理を終了する。なお、配信された否決情報は他ノードにおける管理ノード決定処理に用いられる。

つぎに、図８に示したクラスタ情報４００の再構築処理について説明する。図１３は、図８に示したクラスタ情報４００の再構築処理を示すＵＭＬのシーケンス図である。自ノードがあらたに管理ノードに決定されると、元の管理ノードによって生成されたクラスタ情報４００を自ノード（管理ノード）において再構築する必要がある。

図１３において、クラスタ情報４００の再構築処理では、管理ノードである自ノード上でノードコーディネータＮＣが起動された場合（ステップＳ８０７）、自ノードのノードデーモンＮＤに対してクラスタ情報４００を要求する（ステップＳ１３０１）。ノードデーモンＮＤは、クラスタ情報４００の問い合わせ専用のポートを開いており、ノードコーディネータＮＣからの要求を待ち受けている。ノードコーディネータＮＣがこのポートに接続すると、ノードデーモンＮＤは、自ノードのメモリ３０９に格納されているクラスタ情報４００（第１のクラスタ情報４００）を、サービスリスト６００、ＩＰ変換テーブル５００、タスクリスト７００の順にノードコーディネータＮＣに送信する（ステップＳ１３０２）。

ノードコーディネータＮＣは、受け取ったクラスタ情報４００から新たなクラスタ情報（第２のクラスタ情報）を生成され、再構築されたこととなる。再構築処理が完了すると、マイグレート処理をおこなう。すなわち、自ノードで動作しているサービスの起動要求を他ノードのノードデーモンＮＤにおこなう（ステップＳ１３０３）。そして、他ノードのノードデーモンＮＤから起動完了の通知を受けると（ステップＳ１３０４）、ノードコーディネータＮＣは、自ノードのノードデーモンＮＤにサービスの停止を要求して（ステップＳ１３０５）、ＩＰ変換テーブル５００から自ノードのＲＩＰを削除する。

そして、自ノードからの停止完了の通知を受ける（ステップＳ１３０６）。この時、自ノードに再びサービスが割り当てられないように設定を変更する。このあと、ノードコーディネータＮＣは、トンネルデバイスの削除と外部からのパケットを受け取るためのＶＩＰの作成（ＩＰエイリアス）などのノード情報の設定をおこなう（ステップＳ１３０７）。

このあと、ノードコーディネータＮＣは、再構築された第２のクラスタ情報を自ノードのノードデーモンＮＤに配布して（ステップＳ１３０８）、この配布されたクラスタ情報に含まれているＩＰ変換テーブル５００を自ノードのＶＮＩＣに配布することによりＩＰ変換テーブル５００を更新する（ステップＳ１３０９）。このあと、ノードコーディネータＮＣは自ノードのノードデーモンＮＤから第２のクラスタ情報の配布完了の通知を受ける（ステップＳ１３１０）。

また、ノードコーディネータＮＣは、障害ノードを除いた他ノードのノードデーモンＮＤに再構築された第２のクラスタ情報４００を配布する（ステップＳ１３１１）。これにより、他ノードのノードデーモンＮＤは、それぞれＶＮＩＣが有するＩＰ変換テーブル５００を、配布されたクラスタ情報４００に含まれているＩＰ変換テーブル５００に更新する（ステップＳ１３１２）。このあと、ノードコーディネータＮＣは、他ノードのノードデーモンＮＤから配布完了の通知を受ける（ステップＳ１３１３）。

これにより、実ノードを管理ノードに切り替えることによって、サービスを提供している実ノード数が減少してクラスタ１０１全体の性能は一時的に低下するものの、サービスの提供を継続することが可能となる。低下した性能は、あらたに管理ノードに決定されたノードのノードコーディネータＮＣの自律機能によって最適化される。管理ノードに決定されたノードがサービスを提供している場合であっても、そのサービスを停止する前に、当該サービスを他ノードに割り当ててサービスの起動要求（ステップＳ１３０３）を送る。これによって、サービスをマイグレートすることができ、サービスの提供を継続することができる。

また、サービスを停止する場合に、毎回サービスマイグレーションを実行するとノードコーディネータＮＣの起動時間が延びてしまうことが懸念される。そこで、同一のサービスを提供している実ノード数によってサービスマイグレーションを実行するかどうかの判定をおこなうこととしてもよい。すなわち、同一サービスを提供するノード数が所定数以上ある場合には、マイグレーションをおこなう必要がない。

つぎに、上述した管理ノード決定処理およびクラスタ情報４００の再構築処理を、図４に示したクラスタ１０１の構成例を用いて説明する。図１４は、クラスタ１０１の構成例を示す説明図である。図４において、管理ノードであるノード１１１に故障が発生した場合、他ノードの中から管理ノードが決定される。ここでは、ノード１１５が決定されたこととする。そして、図１４において、管理ノードに決定されたノード１１５では、ノードコーディネータＮＣが起動され、クラスタ情報４００の再構築処理により第２のクラスタ情報１４００が生成される。

この第２のクラスタ情報１４００は、ノード１１５のノードデーモンＮＤに配布されて、ノード１１５のＶＮＩＣに転送される。また、第２のクラスタ情報１４００は、第１のクラスタ情報４００のＩＰ変換テーブル５００を引き継いでいるため、ノード１１５のノードコーディネータＮＣでは、このＩＰ変換テーブル５００から障害ノード１１１を除いたあらたなＩＰ変換テーブル１５００を作成する。

このあらたなＩＰ変換テーブル１５００は、障害ノード１１１を除く他ノード１１２〜１１４およびノード１１５に配布される。他ノード１１２〜１１４およびノード１１５では、他ノード１１２〜１１４およびノード１１５の各ノードデーモンＮＤが有する第１のクラスタ情報４００（図４を参照）が、管理ノードであるノード１１５から配布された第２のクラスタ情報１４００に更新され、その第２のクラスタ情報１４００に含まれているＩＰ変換テーブル１５００が各ＶＮＩＣに引き渡される。

このように、クラスタ１０１内のノードがすべて現用系である場合、別のサービスを提供していた実ノードを、当該実ノードのノードコーディネータＮＣによって管理ノードに切り替えることができ、管理ノードに障害が発生した場合であっても、クラスタ１０１の運用管理を無駄な待機系のノードを用いずに継続することができる。

また、あらたに管理ノードに決定されたノードで提供していたサービスを停止して、他の実ノードにサービスを移動させること、すなわち、サービスマイグレーションを実行することにより、管理ノードに決定されたノードの過負荷状態を回避することができる。これにより、クラスタ１０１の運用管理の効率化と高可用化を両立することができる。

以上説明したように、本発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタによれば、無駄な待機系ノードを用いずにクラスタの運用管理を円滑に引き継ぐことにより可用性の向上を図ることができるという効果を奏する。

なお、本実施の形態で説明したクラスタ管理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

（付記１）複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行させるクラスタ管理プログラムであって、
前記複数のノードのうち自ノードを除く他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出させる検出工程と、
前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定させる決定工程と、
前記決定工程によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動させる起動工程と、
を前記自ノードのコンピュータに実行させることを特徴とするクラスタ管理プログラム。

（付記２）前記管理ノードに選ばれたノードから配信された前記クラスタ内のノードの負荷情報を取得させる取得工程を前記自ノードのコンピュータに実行させ、
前記決定工程は、
前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記取得工程によって取得された情報に基づいて、前記自ノードを前記管理ノードに決定させることを特徴とする付記１に記載のクラスタ管理プログラム。

（付記３）前記取得工程は、
さらに、前記他ノードから当該他ノードが前記管理ノードに決定されなかった旨の否決情報を取得させ、
前記決定工程は、
さらに、前記取得工程によって取得された否決情報に基づいて、前記自ノードを前記管理ノードに決定させることを特徴とする付記２に記載のクラスタ管理プログラム。

（付記４）前記決定工程によって前記自ノードが前記管理ノードに決定されなかった場合、前記他ノードに前記自ノードの否決情報を送信させる送信工程を、前記自ノードのコンピュータに実行させることを特徴とする付記１〜３のいずれか一つに記載のクラスタ管理プログラム。

（付記５）前記検出工程による停止の検出に先立って、前記管理ノードに選ばれたノードから前記クラスタの管理に関する第１のクラスタ情報を受信させる受信工程と、
前記決定工程によって前記自ノードが前記管理ノードに決定された場合、前記受信工程によって受信された第１のクラスタ情報を用いて、前記検出工程によって停止が検出されたノードを除いたクラスタの管理に関する第２のクラスタ情報を生成させる生成工程と、
前記生成工程によって生成された第２のクラスタ情報を、前記自ノードのメモリに格納させる格納工程と、
前記生成工程によって生成された第２のクラスタ情報を、前記検出工程によって停止が検出されたノードを除く他ノードに配信させる配信工程と、
を前記自ノードのコンピュータに実行させることを特徴とする付記１〜３のいずれか一つに記載のクラスタ管理プログラム。

（付記６）前記決定工程によって前記自ノードが前記管理ノードに決定された場合、前記自ノードが提供しているサービスの起動要求を前記他ノードにおこなって、いずれかの前記他ノードからの前記サービスの起動応答を受け付けさせるマイグレート工程を、前記自ノードのコンピュータに実行させることを特徴とする付記５に記載のクラスタ管理プログラム。

（付記７）前記管理ノードの指定を受け付けさせる指定工程を前記自ノードのコンピュータに実行させ、
前記検出工程は、
前記指定工程によって前記管理ノードに指定されなかった場合、前記他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出させることを特徴とする付記１に記載のクラスタ管理プログラム。

（付記８）前記起動工程は、
前記指定工程によって前記管理ノードに指定された場合、前記自ノードによる前記管理処理を起動させることを特徴とする付記７に記載のクラスタ管理プログラム。

（付記９）複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行させるクラスタ管理プログラムであって、
前記管理ノードの指定を受け付けさせる指定工程と、
前記指定工程によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動させる起動工程と、
前記起動工程によって前記管理処理が起動された場合、前記クラスタの管理に関するクラスタ情報を生成させる生成工程と、
前記生成工程によって生成されたクラスタ情報を自ノードのメモリに格納させる格納工程と、
前記生成工程によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信させる配信工程と、
を前記自ノードのコンピュータに実行させることを特徴とするクラスタ管理プログラム。

（付記１０）前記自ノードによる前記管理処理が停止したか否かを検出させる検出工程と、
前記格納工程によって格納されたクラスタ情報を用いて、前記検出工程によって停止が検出された管理処理を再起動させる再起動工程と、
を前記自ノードのコンピュータに実行させることを特徴とする付記９に記載のクラスタ管理プログラム。

（付記１１）付記１〜１０のいずれか一つに記載のクラスタ管理プログラムを記録したコンピュータに読み取り可能な記録媒体。

（付記１２）複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理方法であって、
前記複数のノードのうち自ノードを除く他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出する検出工程と、
前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定する決定工程と、
前記決定工程によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動する起動工程と、
を含んだことを特徴とするクラスタ管理方法。

（付記１３）複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理方法であって、
前記管理ノードの指定を受け付ける指定工程と、
前記指定工程によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動する起動工程と、
前記起動工程によって前記管理処理が起動された場合、前記クラスタの管理に関するクラスタ情報を生成する生成工程と、
前記生成工程によって生成されたクラスタ情報を自ノードのメモリに格納する格納工程と、
前記生成工程によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信する配信工程と、
を含んだことを特徴とするクラスタ管理方法。

（付記１４）複数のノードからなるクラスタ内のノードであって、
前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードに選ばれたノードが、停止したか否かを検出する検出手段と、
前記検出手段によって前記管理ノードに選ばれたノードの停止が検出された場合、前記管理ノードに決定する決定手段と、
前記決定手段によって前記管理ノードに決定された場合、前記管理処理を起動する起動手段と、
を備えることを特徴とするノード。

（付記１５）複数のノードからなるクラスタ内のノードであって、
前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードの指定を受け付ける指定手段と、
前記指定手段によって前記管理ノードに指定された場合、前記管理処理を起動する起動手段と、
前記起動手段によって前記管理処理が起動された場合、前記クラスタ内の全ノードの管理に関するクラスタ情報を生成する生成手段と、
前記生成手段によって生成されたクラスタ情報をメモリに格納する格納手段と、
前記生成手段によって生成されたクラスタ情報を、前記複数のノードのうち自ノードを除く他ノードに配信する配信手段と、
を備えることを特徴とするノード。

（付記１６）複数のノードからなるクラスタであって、
前記各ノードは、
前記複数のノードのうち自ノードを除く他ノードの中から前記クラスタの管理処理を実行する管理ノードに選ばれたノードが、停止したか否かを検出する検出手段と、
前記検出手段によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定する決定手段と、
前記決定手段によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動する起動手段と、
を備えることを特徴とするクラスタ。

（付記１７）複数のノードからなるクラスタであって、
前記各ノードは、
前記クラスタの管理処理を実行する管理ノードの指定を受け付ける指定手段と、
前記指定手段によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動する起動手段と、
前記起動手段によって前記管理処理が起動された場合、前記複数のノードの管理に関するクラスタ情報を生成する生成手段と、
前記生成手段によって生成されたクラスタ情報を自ノードのメモリに格納する格納手段と、
前記生成手段によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信する配信手段と、
を備えることを特徴とするクラスタ。

以上のように、本発明にかかるクラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタは、たとえば、自律運用システムに有用であり、特に、基幹業務のデータベースサーバやアプリケーションサーバ、ファイルサーバ、インターネット上のファイアウォール、メールサーバ、Ｗｅｂサーバに適している。

この発明の実施の形態にかかるクラスタシステムのシステム構成図である。 この発明の実施の形態にかかるノード等のハードウェア構成を示すブロック図である。 この発明の実施の形態にかかるクラスタを構成する各ノードの機能的構成を示すブロック図である。 クラスタの具体的な構成例を示す説明図である。 ＩＰ変換テーブルを示す説明図である。 サービスリストの一例を示す説明図である。 タスクリストの一例を示す説明図である。 この発明の実施の形態にかかるクラスタ管理処理手順を示すフローチャートである。 図８で示したサービス登録処理を示すＵＭＬのシーケンス図である。 サービス記述ファイルの一例を示す説明図である。 図８で示したノード割り当て処理を示すＵＭＬのシーケンス図である。 図８に示した管理ノード決定処理を示すフローチャートである。 図８に示したクラスタ情報の再構築処理を示すＵＭＬのシーケンス図である。 クラスタの構成例を示す説明図である。

符号の説明

１００ クラスタシステム
１０１ クラスタ
１０２ クライアント
１０３ ネットワーク
１１１〜１１５ （実）ノード
３０１ 検出部
３０２ 取得部
３０３ 決定部
３０４ 起動部
３０５ 送信部
３０６ 受信部
３０７ 生成部
３０８ 格納部
３０９ メモリ
３１０ 配信部
３１１ マイグレート部
３１２ 指定部
４００、４１０ 第１のクラスタ情報
５００、１５００ ＩＰ変換テーブル
６００ サービスリスト
７００ タスクリスト
１０００ サービス記述ファイル
１４００ 第２のクラスタ情報
ＮＣ ノードコーディネータ
ＮＤ ノードデーモン
ＶＮＩＣ バーチャルネットワークインターフェースカード

Claims (10)

1. 複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行させるクラスタ管理プログラムであって、
   前記複数のノードのうち自ノードを除く他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出させる検出工程と、
   前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定させる決定工程と、
   前記決定工程によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動させる起動工程と、
   を前記自ノードのコンピュータに実行させることを特徴とするクラスタ管理プログラム。
2. 前記管理ノードに選ばれたノードから配信された前記クラスタ内のノードの負荷情報を取得させる取得工程を前記自ノードのコンピュータに実行させ、
   前記決定工程は、
   前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記取得工程によって取得された情報に基づいて、前記自ノードを前記管理ノードに決定させることを特徴とする請求項１に記載のクラスタ管理プログラム。
3. 複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行させるクラスタ管理プログラムであって、
   前記管理ノードの指定を受け付けさせる指定工程と、
   前記指定工程によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動させる起動工程と、
   前記起動工程によって前記管理処理が起動された場合、前記クラスタの管理に関するクラスタ情報を生成させる生成工程と、
   前記生成工程によって生成されたクラスタ情報を自ノードのメモリに格納させる格納工程と、
   前記生成工程によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信させる配信工程と、
   を前記自ノードのコンピュータに実行させることを特徴とするクラスタ管理プログラム。
4. 請求項１〜３のいずれか一つに記載のクラスタ管理プログラムを記録したコンピュータに読み取り可能な記録媒体。
5. 複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理方法であって、
   前記複数のノードのうち自ノードを除く他ノードの中から前記管理ノードに選ばれたノードが停止したか否かを検出する検出工程と、
   前記検出工程によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定する決定工程と、
   前記決定工程によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動する起動工程と、
   を含んだことを特徴とするクラスタ管理方法。
6. 複数のノードからなるクラスタの管理処理を前記複数のノード内の管理ノードによって実行するクラスタ管理方法であって、
   前記管理ノードの指定を受け付ける指定工程と、
   前記指定工程によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動する起動工程と、
   前記起動工程によって前記管理処理が起動された場合、前記クラスタの管理に関するクラスタ情報を生成する生成工程と、
   前記生成工程によって生成されたクラスタ情報を自ノードのメモリに格納する格納工程と、
   前記生成工程によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信する配信工程と、
   を含んだことを特徴とするクラスタ管理方法。
7. 複数のノードからなるクラスタ内のノードであって、
   前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードに選ばれたノードが、停止したか否かを検出する検出手段と、
   前記検出手段によって前記管理ノードに選ばれたノードの停止が検出された場合、前記管理ノードに決定する決定手段と、
   前記決定手段によって前記管理ノードに決定された場合、前記管理処理を起動する起動手段と、
   を備えることを特徴とするノード。
8. 複数のノードからなるクラスタ内のノードであって、
   前記複数のノードの中から前記クラスタの管理処理を実行する管理ノードの指定を受け付ける指定手段と、
   前記指定手段によって前記管理ノードに指定された場合、前記管理処理を起動する起動手段と、
   前記起動手段によって前記管理処理が起動された場合、前記クラスタ内の全ノードの管理に関するクラスタ情報を生成する生成手段と、
   前記生成手段によって生成されたクラスタ情報をメモリに格納する格納手段と、
   前記生成手段によって生成されたクラスタ情報を、前記複数のノードのうち自ノードを除く他ノードに配信する配信手段と、
   を備えることを特徴とするノード。
9. 複数のノードからなるクラスタであって、
   前記各ノードは、
   前記複数のノードのうち自ノードを除く他ノードの中から前記クラスタの管理処理を実行する管理ノードに選ばれたノードが、停止したか否かを検出する検出手段と、
   前記検出手段によって前記管理ノードに選ばれたノードの停止が検出された場合、前記自ノードを前記管理ノードに決定する決定手段と、
   前記決定手段によって前記管理ノードに決定された場合、前記自ノードによる前記管理処理を起動する起動手段と、
   を備えることを特徴とするクラスタ。
10. 複数のノードからなるクラスタであって、
    前記各ノードは、
    前記クラスタの管理処理を実行する管理ノードの指定を受け付ける指定手段と、
    前記指定手段によって前記管理ノードに指定された場合、自ノードによる前記管理処理を起動する起動手段と、
    前記起動手段によって前記管理処理が起動された場合、前記複数のノードの管理に関するクラスタ情報を生成する生成手段と、
    前記生成手段によって生成されたクラスタ情報を自ノードのメモリに格納する格納手段と、
    前記生成手段によって生成されたクラスタ情報を、前記複数のノードのうち前記自ノードを除く他ノードに配信する配信手段と、
    を備えることを特徴とするクラスタ。
    

Images