JP2008269462A - ノードの管理装置及び方法 - Google Patents

Abstract

【課題】クラスタシステムにおいて適切なノード切替を行えるようにする。
【解決手段】クラスタシステムを構成する三以上のノードの各々と通信可能に接続された装置が、三以上のノードの各々について、アプリケーションが利用するリソースに関する情報を示したリソース情報を保持する。その装置が、リソースに関する状況の変化を示すリソース状況情報を各ノードから受信し、受信したリソース状況情報に基づいて、リソース情報を更新し、更新後のリソース情報に基づいて、次の現用ノードを決定し、決定した次の現用ノードを、三以上のノードのうちの少なくとも一つのノードへ通知する。
【選択図】図１

Description

本発明は、クラスタシステムを構成するノードの切替に関する。

従来、ストレージ装置へのアクセスを制御するノードに関する技術として、特許文献１等が知られている。特許文献１では、ノードに発生した障害に対処するため、複数のノードが備えられ、それらによりクラスタシステムが構成される。クラスタシステムでは、複数のノードのうちの一つが現用系のノードとなってストレージ装置へのアクセスを制御する。そして、それ以外のノードが待機系のノードとなって、現用系のノードに障害が発生した場合に備えて待機する。これにより、現用系のノードに障害が発生した場合でも、待機系のノードのうちの一つが、障害が発生したノードの代わりに現用系のノードとなって、ストレージ装置へのアクセスを制御できるようになっている。

特開２００６−２６０３５７号公報

一般に、クラスタシステムにおいては、障害が発生した場合のノードの切替は、予め定義されたノードの順序に従って行われる。そのため、待機系のノードにも障害が発生していた場合には、ノードの切替が無駄に行われることがある。

例えば、クラスタシステムが四つのノード（ノード１、ノード２、ノード３、ノード４）で構成され、それらの順序がノード１→ノード２→ノード３→ノード４で定義されていた場合は、障害の発生していないときには、順番が最先のノード１が現用系のノードとなり、それ以外のノード２、ノード３及びノード４が待機系のノードとなる。そして、ノード１に障害が発生すると、待機系のノードのうち順番が最先であるノード２が、現用系のノードに切替えられる。ここで、ノード２にも障害が発生していたならば、更にノードの切替が行われ、ノード２の次に順番が先であるノード３が、現用系のノードに切替えられる。つまり、ノード１に障害が発生した時点で、ノード２にも障害が発生していた場合は、ノード１からノード２へ切替えは無駄となる。このような無駄な切替が行われると、正常にストレージ装置へアクセスできるようになるまでに、余計に時間がかかってしまう。

そこで、本発明は、クラスタシステムにおいて適切なノード切替を行えるようにすることを目的とする。

クラスタシステムを構成する三以上のノードの各々と通信可能に接続された装置が、三以上のノードの各々について、アプリケーションが利用するリソースに関する情報を示したリソース情報を保持する。その装置が、各ノードから、リソースに関する状況の変化を示すリソース状況情報を受信し、受信したリソース状況情報に基づいて、リソース情報を更新し、更新後のリソース情報に基づいて、次の現用ノードを決定する。その装置は、決定した次の現用ノードを、三以上のノードのうちの少なくとも一つのノードへ通知する。

一つの実施形態では、クラスタシステムを構成する三以上のノードの各々と通信可能に接続された装置（例えば計算機）に、受信部と、更新部と、決定部と、通知部とを備えることで、ノード管理装置が構成される。ノード管理装置内の記憶資源に、リソース情報が記憶される。リソース情報は、三以上のノードの各々について、アプリケーションが利用するリソースに関する情報を示した情報である。受信部は、各ノードから、リソースに関する状況の変化を示すリソース状況情報を受信する。更新部は、受信部が受信したリソース状況情報に基づいて、リソース情報を更新する。決定部は、更新部が更新したリソース情報に基づいて、次の現用ノードを決定する。通知部は、決定部が決定した次の現用ノードを示す情報を三以上のノードのうちの少なくとも一つのノードへ通知する。

クラスタシステムでは、クラスタシステムを構成する三以上のノードのうちの一つが現用ノードとなってストレージ装置へのアクセスを制御するが、現用ノードに障害が発生した場合には、現用ノードの切替が行われる。次の現用ノードとは、現用ノードの切替によって新たに現用ノードとなるノードを指す。通知部は、例えば、決定部が決定した次の現用ノードを示す情報を、全てのノードへ通知してもよいし、現用のノードにだけ通知してもよい。

一つの実施形態では、リソース情報は、ノードごとに、アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含む。受信部が受信するリソース状況情報は、パスに障害が発生し又は障害が回復したことを示す障害情報と、障害の発生又は回復を検出したノードを特定するノード情報とを含む。更新部は、障害情報及びノード情報に基づいて、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を更新する。決定部は、更新部が更新したリソース情報に基づいて、現用ノード以外のノードのうち有効パス数が多いノードを次の現用ノードと決定する。

一つの実施形態では、更新部は、障害情報がパスに障害が発生したことを示すときは、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を減少させ、障害情報がパスに障害が回復したことを示すときは、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を増加させる。

一つの実施形態では、受信部が受信する障害情報は、パスに障害が発生し又は障害が回復したことを示す情報と、障害が発生し又は回復したパスの数である障害パス数とを含む。更新部は、障害情報がパスに障害が発生したことを示すときは、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を障害パス数だけ減少させ、障害情報がパスに障害が回復したことを示すときは、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を障害パス数だけ増加させる。

一つの実施形態では、決定部は、更新部が更新したリソース情報に基づいて、次の現用ノードの順番及びそれ以降の現用ノードの順番を表すノードの切替順序を決定する。通知部は、決定部が決定したノードの切替順序を三以上のノードのうちの少なくとも一つのノードへ通知する。

通知部は、例えば、決定部が決定したノードの切替順序を、全てのノードへ通知してもよいし、現用のノードにだけ通知してもよい。また、決定されるノード切替順序、及び／又は、通知されるノード切替順序は、例えば、三以上のノードの各々の識別情報（例えばノード名）とその順番とで構成される。

一つの実施形態では、リソース情報は、ノードごとに、アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含む。受信部が受信するリソース状況情報は、パスに障害が発生し又は障害が回復したことを示す障害情報と、障害の発生又は回復を検出したノードを特定するノード情報とを含む。更新部は、障害情報及びノード情報に基づいて、リソース情報における、ノード情報によって特定されるノードに対応する有効パス数を更新する。決定部は、更新部が更新したリソース情報に基づいて、前記有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する。

一つの実施形態では、ノードの切替順序を示したノード切替順序情報と、決定部が決定した第一のノードの切替順序とノード切替順序情報に示される第二のノードの切替順序と比較し、第一のノードの切替順序と第二のノードの切替順序とが異なる場合に、ノード切替順序情報が示すノードの切替順序を第一の切替順序に更新する第二の更新部とを更に備える。通知部は、ノード切替順序情報が更新された場合に、第一の切替順序をノードへ通知する。

一つの実施形態では、決定部は、更新部によって更新された有効パス数が所定の閾値以下となった場合に、更新部が更新したリソース情報に基づいて、有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する。

一つの実施形態では、三以上のノードの各々は、複数のアプリケーションを有する。リソース情報は、アプリケーションとアプリケーションを稼働するノードとの組合わせごとに、有効パス数を含む。受信部が受信するリソース状況情報は、障害情報及びノード情報に加えて、アプリケーションを特定するアプリケーション情報を含む。更新部は、障害情報、ノード情報及びアプリケーション情報に基づいて、リソース情報における、ノード情報によって特定されるノードとアプリケーション情報によって特定されるアプリケーションとの組合わせに対応する有効パス数を更新する。決定部は、更新部が更新したリソース情報に基づいて、アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち有効パス数が多いノードを次の現用ノードと決定する。

一つの実施形態では、リソース情報は、アプリケーションとアプリケーションを稼働するノードとの組合わせごとに、有効パス数とアプリケーションの負荷を示す負荷情報とを含む。決定部は、更新部が更新したリソース情報に基づいて、アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち有効パス数が多く、かつ、アプリケーションに対応する負荷情報が示す負荷が少ないノードを次の現用ノードと決定する。

上述した複数の実施形態のうちの二以上の実施形態を組み合わせることが可能である。また、前述した各部（例えば、受信部、更新部、決定部、及び通知部）は、ハードウェア、コンピュータプログラム又はそれらの組み合わせ（例えば一部をコンピュータプログラムにより実現し残りをハードウェアで実現すること）により構築することができる。コンピュータプログラムは、所定のプロセッサに読み込まれて実行される。また、コンピュータプログラムがプロセッサに読み込まれて行われる情報処理の際、適宜に、メモリ等のハードウェア資源上に存在する記憶域が使用されてもよい。また、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体から計算機にインストールされてもよいし、通信ネットワークを介して計算機にダウンロードされてもよい。

以下、本発明の一実施形態について図面を参照して説明する。尚、以下の説明では、コンピュータプログラムが主語になる場合は、実際にはそのコンピュータプログラムを実行するプロセッサ（ＣＰＵ）によって処理が行われるものとする。

図１は、本実施形態に係る計算機システムの構成例を示した図である。

本実施形態に係る計算機システム（以下、「本システム」と呼ぶことがある）は、管理サーバ１００と、クライアント２００と、複数のノード４００と、ストレージ装置６００とを備える。管理サーバ１００、クライアント２００及び複数のノード４００は、第一の通信ネットワーク３００によって接続される。第一の通信ネットワーク３００としては、ＬＡＮ（Local Area Network）など、種々のネットワークを採用することができる。また、複数のノード４００及びストレージ装置６００は、第二の通信ネットワーク５００によって接続される。第二の通信ネットワーク５００としては、ＳＡＮ（Storage Area Network）など、種々のネットワークを採用することができる。第一の通信ネットワークと第二の通信ネットワークとは、同一の通信ネットワークとして構成されることもできる。尚、本システムが備えるノード４００の数は、三以上である。本実施形態では、四つのノード４００（ノード４００ａ、ノード４００ｂ、ノード４００ｃ及びノードｄ）が備えられているものとする。以下、ノード４００ａ、ノード４００ｂ、ノード４００ｃ、ノードｄをそれぞれ、ノード１、ノード２、ノード３、ノード４と呼ぶことがある。

ノード４００は、所定のアプリケーション（以下、「ＡＰ」）を実行し、クライアント２００からの要求に従って、ストレージ装置６００のＬＵ（Logical Unit）６３０に対して、Ｉ／Ｏ要求（書込み要求／読出し要求）を発行する計算機である。複数のノード４００（ここでは、ノード１、ノード２、ノード３及びノード４）は、クラスタシステムを構成する。即ち、複数のノード４００のうちのいずれか一つが、主ノードとなって、実際にＡＰを稼働してクライアント２００からの要求を処理する。そして、主ノード以外の他のノード４００は、待機ノードとなって、主ノードに障害が発生した場合に備えて待機する（待機中は、クライアント２００からの要求を処理しない）。主ノードに障害が発生した場合は、予め定められた系切替順序（後述する）に従って選択された一の待機ノードが、主ノードとなって、ＡＰを起動し、クライアント２００からの要求を処理する。

ノード４００は、例えば、プロセッサ（ＣＰＵ）４１０と、記憶資源（例えば、メモリ４２０）と、一又は複数のＨＢＡ（ホストバスアダプタ）４４０とを備える。

ＨＢＡ４４０は、ＳＡＮ５００に接続するために、ノード４００が持つハードウェアであり、例えば、ＦＣ（Fibre Channel）プロトコル、ＳＣＳＩプロトコルをサポートするインタフェース装置である。

記憶資源としては、メモリやハードディスクなど種々の記憶資源を採用可能であるが、本実施形態では、メモリ４２０とする。これは、管理サーバ１００についても同様である。メモリ４２０には、例えば、プロセッサ４１０によって実行されるコンピュータプログラムとして、ＡＰ４２１と、パス管理ドライバ４３０と、クラスタソフトウェア４２２と、ドライバＵＩＰＧ（プログラムの略）４２４と、ドライバ管理ＰＧ４２５とが記録される。ＡＰ４２１は、複数備えられてもよく、本実施形態では、全てのノード４００ａ、４００ｂ、４００ｃ、４００ｄには、二つのＡＰ（ＡＰ４２１ａ、ＡＰ４２１ｂ）が、それぞれ備えられているものとする。以下、ＡＰ４２１ａ、ＡＰ４２１ｂをそれぞれＡＰ１、ＡＰ２と呼ぶことがある。

ノード４００の図示しないオペレーティングシステム（ＯＳ）によってＬＵ６３０がマウントされることにより論理デバイス４３４が認識される。以下、認識された論理デバイス４３４を「ｄｅｖ４３４」と呼ぶことがある。ＡＰ４２１は、ｄｅｖ４３４に対してＩ／Ｏ要求を発行することができる。ｄｅｖ４３４に対して発行されたＩ／Ｏ要求は、ｄｅｖ４３４に対応したＬＵ６３０に対するＩ／Ｏ要求として、ノード４００からストレージ装置６００に送信される。本実施形態では、それぞれのノード４００ａ、４００ｂ、４００ｃ、４００ｄには、二つのｄｅｖ４３４（ｄｅｖ４３４ａ、ｄｅｖ４３４ｂ）が備えられるものとする。そして、ｄｅｖ４３４ａは、ＡＰ１によって利用され、ｄｅｖ４３４ｂは、ＡＰ２によって利用されるものとする。以下、ｄｅｖ４３４ａ、ｄｅｖ４３４ｂをそれぞれｄｅｖ１、ｄｅｖ２と呼ぶことがある。

パス管理ドライバ４３０は、ＡＰ４２１がＩ／Ｏ要求を発行するために利用する、ｄｅｖ４３４からそのｄｅｖ４３４に対応したＬＵ６３０までのアクセス経路（以下、「パス」）の管理を行う。パスは、どのｄｅｖ４３４からどのＨＢＡ４４０とどのＣＨＡ６１０とを経由してどのＬＵ６３０に繋がるかで定義される。つまり、パスは、ｄｅｖ４３４、ＨＢＡ４４０、ＣＨＡ６１０及びＬＵ６３０の組み合わせで定義される。通常、各ノード４００のｄｅｖ４３４ごとに、複数のパスが設けられる。パス管理ドライバ４３０は、例えば、サブプログラムとして、パス管理フィルタドライバ４３１と、パス選択ロジック４３２とを備える。また、パス管理ドライバ４３０は、パステーブル４３３を備える。

パス管理フィルタドライバ４３１は、パス選択ロジック４３２が選択したパスを利用して、ストレージ装置６００のＬＵ６３０に対してＩ／Ｏ要求を発行する。そして、パス管理フィルタドライバ４３１は、そのＩ／Ｏ要求に対する結果をＡＰ４２１に通知する。また、パス管理フィルタドライバ４３１は、Ｉ／Ｏ要求に対する結果から、パスの障害（パスを構成する機器（ＨＢＡ４４０やＣＨＡ６１０やケーブル等）における物理的な障害や、物理的な障害は発生していないが正常にリンクが確立できない等の論理的な障害のことをいい、以下、「パス障害」という）を検出することができる。

パス選択ロジック４３２は、パステーブル４３３を参照して、Ｉ／Ｏ要求の発行に利用するパスを選択する。また、パス選択ロジック４３２は、パス管理フィルタドライバ４３１がパス障害を検出した場合に、その障害のあるパスをパスの選択の候補から除外する。即ち、パス選択ロジック４３２は、パステーブル４３３において無効（Offline）となっているパスを選択しない。パステーブル４３３については、後述する。

クラスタソフトウェア４２２は、そのクラスタソフトウェア４２２を備えるノード４００がクラスタシステムを構成する一のノード４００として動作するように、当該ノード４００を制御するソフトウェアである。例えば、クラスタソフトウェア４２２は、そのクラスタソフトウェア４２２を備えるノード４００の動作を監視する。そして、クラスタソフトウェアは、主ノードであるノード４００の障害を検出した場合には、他のノード４００に備えられるクラスタソフトウェア４２２と連携して、後述する系切替順序に従って主ノードの切り替えを行う。クラスタソフトウェア４２２は、ＡＰ２４１ごとにＡＰ定義ファイル４２３を有する。本実施形態では、クラスタシステム上で、ＡＰ１とＡＰ２とが稼働されるので、クラスタソフトウェア４２２は、ＡＰ１に関するＡＰ定義ファイル４２３とＡＰ２に関するＡＰ定義ファイル４２３とを有することになる。ＡＰ定義ファイル４２３については、後述する。

ドライバ管理ＰＧ４２５は、パス管理ドライバ４３０を監視し、パス管理ドライバ４３０がパス障害又はパス障害の回復（以下、「パス回復」）を検出した場合に、そのパス障害又はパス回復に関する情報（以下、「パス障害／回復情報」）を管理サーバ１００へ通知するプログラムである。パス障害／回復情報には、例えば、パス障害かパス回復かを示す情報と、そのパス障害又はパス回復を検出したノード４００（つまり、自分自身）のＩＤと、障害が発生したパス又は回復したパスに対応するｄｅｖ４３４のＩＤとが含まれる。障害が発生したパス又は回復したパスに対応するｄｅｖ４３４のＩＤは、パステーブル４３３が参照されることにより取得される。パス障害／回復情報の通知には、例えば、ＳＮＭＰ（Simple Network Management Protocol）Ｔｒａｐが利用される。また、ドライバ管理ＰＧ４２５は、パス管理ドライバ４３０が管理するパスの状態が、有効となっているか無効となっているかを定期的又は不定期的に確認する。以下、この確認処理を「ヘルスチェック処理」と呼ぶことがある。ドライバ管理ＰＧ４２５は、ヘルスチェック処理によってパスの状態が変更されたこと（つまり、パス障害又はパス回復が発生したこと）を検出したときは、そのパス障害／回復情報を管理サーバ１００へ通知する。ドライバ管理ＰＧ４２５は、パス障害又はパス回復が検出されたときは、パス障害／回復情報に基づいて、パステーブル４３３における所定の情報を変更する。

ドライバＵＩ ＰＧ ４２４は、管理者がドライバ管理ＰＧ４２５が実行する処理に関する所定の設定を行うためのユーザインタフェース（ＵＩ）を提供するプログラムである。例えば、管理者は、ドライバＵＩＰＧ ４２４が提供するＵＩを利用して、ドライバ管理ＰＧ４２５がパス障害／パス回復情報の通知やヘルスチェック処理を行うか否かを、設定することができる。

管理サーバ１００は、複数のノード４００を管理するサーバマシンである。管理サーバ１００は、例えば、プロセッサ（ＣＰＵ）１１０や、メモリ１２０を備える。メモリ１２０には、プロセッサ１１０に読み込まれて実行されるコンピュータプログラムや、プロセッサ１１０に使用されるデータが記憶される。

コンピュータプログラムとしては、例えば、初期化ＰＧ１２１や、フェールオーバ更新ＰＧ１２２や、Ｔｒａｐ受信ＰＧ１２３がある。Ｔｒａｐ受信ＰＧ１２３は、パス障害／回復情報をノード４００から受信するためのプログラムである。Ｔｒａｐ受信ＰＧ１２３は、パス障害／回復情報を受信したときは、その情報をフェールオーバ更新ＰＧ１２２へ通知する。また、Ｔｒａｐ受信ＰＧ１２３は、パス障害／回復情報を受信したときは、その情報に基づいてパス管理テーブル４３３の所定の情報を変更することもできる。Ｔｒａｐ受信ＰＧ１２３以外のコンピュータプログラム１２１、１２２については、後述する。

データとしては、例えば、パス管理テーブル１２４や、リソーステーブル１２５や、系切替順序テーブル１２６がある。各種データ１２４、１２５、１２６については、後述する。

ストレージ装置６００は、例えば、アレイ状に配列された多数のディスクを備えるＲＡＩＤ（Redundant Array of Independent (or Inexpensive) Disks）システムとすることができる。但し、これに限らず、ストレージ装置６００を、通信ネットワークを構成するスイッチ、例えば、高機能化されたインテリジェント型のファイバチャネルスイッチとして構成することもできる。ストレージ装置６００は、一又は複数のチャネルアダプタ（以下、「ＣＨＡ」）６１０と、一又は複数のディスクアダプタ（以下、ＤＫＡ）６７０と、キャッシュメモリ（ＣＭ）６４０と、接続部６２０と、複数のメディアドライブ（例えばハードディスクドライブ或いはフラッシュメモリドライブ）６６０とを備える。複数のメディアドライブ６６０の記憶空間を基に複数の論理ユニット（ＬＵ）６３０が形成されている。

ＣＨＡ６１０は、ノード４００とデータ通信を行う回路基板である。ＤＫＡ６７０は、各メディアドライブ６６０とデータ通信を行う回路基板である。キャッシュメモリ６４０には、ノード４００からＬＵ６３０に書込まれるデータや、ＬＵ６３０から読み出されてノード４００に送信されるデータが一時的に記憶される。接続部６２０は、例えばクロスバスイッチであり、ＣＨＡ６１０、ＤＫＡ６７０及びキャッシュメモリ６４０を相互に接続させる。ＣＨＡ６１０、ＤＫＡ６７０、キャッシュメモリ６４０及び接続部６２０の組合せに代えて、ＣＰＵやメモリなどが搭載された一又は複数の回路基板がストレージ装置６００の制御部として機能しても良い。

ＣＨＡ６１０がノード４００からＬＵＮを指定した書込み要求を受信した場合、ＣＨＡ６１０が、該書込み要求に従うデータをキャッシュメモリ６４０に書込み、ＤＫＡ６７０が、そのＬＵＮに対応したＬＵ６３０に、キャッシュメモリ６４０に記憶されているデータを書込む。ＣＨＡ６１０がノード４００からＬＵＮを指定した読出し要求を受信した場合、ＤＫＡ６７０が、ＣＨＡ６１０からの指示に応答して、そのＬＵＮに対応したＬＵ６３０からデータを読み出してキャッシュメモリ６４０に書込み、ＣＨＡ６１０が、キャッシュメモリ６４０からそのデータを読み出してノード４００に送信する。

図２は、本実施形態に係るノード４００とストレージ装置６００との間のパスの構成例を示した図である。

同図に示されたように、本実施形態では、各ノード４００ごとに、２個のＨＢＡ４４０が備えられる。また、ストレージ装置６００には、８個のＣＨＡ６１０と、８個のＬＵ６３０とが、それぞれ備えられる。そして、ＳＡＮ５００は、スイッチ５１０により構成されている。このような構成において、各ノード４００は、利用するＨＢＡ４４０やＣＨＡ６１０を切替えることにより、ｄｅｖ４３４からＬＵ６３０までのパスとして、複数のパスを利用することができる。例えば、ノード１は、ｄｅｖ１からＬＵ１までのパスとして、ＨＢＡ１とＣＨＡ１とを経由するパスや、ＨＢＡ２とＣＨＡ２とを経由するパス等を利用することができる。このような各ノード４００が利用することができるパスに関する情報は、それぞれのノード４００が備えるパステーブル４３３に記録される。パステーブル４３３は、各ノード４００に固有の情報である。

図３は、パステーブル４３３の一例を示した図である。

同図（ａ）、（ｂ）、（ｃ）、（ｄ）は、それぞれノード１、ノード２、ノード３、ノード４のパステーブル４３３ａ、４３３ｂ、４３３ｃ、４３３ｄを示している。それぞれのパステーブル４３３の構成は同様なので、ノード１のパステーブル４３３ａを例にとって説明する。

パステーブル４３３ａには、ノード１が利用することができる、ｄｅｖ４３４からＬＵ６３０までのパスに関する情報が記録される。パステーブル４３３ａには、各パスごとに、パスＩＤ４３３１と、論理デバイスＩＤ４３３２と、ＨＢＡＩＤ ４３３３と、ＣＨＡ ＩＤ ４３３４と、ＬＵ ＩＤ ４３３５と、パス状態４３３６とが記録される。パスＩＤ４３３１は、ノード１において当該パスを一意に特定するための識別子である。従って、パスＩＤ４３３１は、ノード１においてユニークな値（名前や数値等）であればよい。論理デバイスＩＤ４３３２は、ｄｅｖを一意に特定するための識別子である。ＨＢＡＩＤ ４３３３は、ＨＢＡ４４０を一意に特定するための識別子である。ＣＨＡ ＩＤ ４３３４は、ＣＨＡ６１０を一意に特定するための識別子である。ＬＵ ＩＤ ４３３５は、ＬＵ６３０を一意に特定するための識別子である。当該パスの構成は、論理デバイスＩＤ４３３２、ＨＢＡＩＤ ４３３３、ＣＨＡ ＩＤ ４３３４及びＬＵ ＩＤ ４３３５の組み合わせによって示される。例えば、パステーブル４３３ａでは、パスＩＤ４３３１が「０００１」のパスは、ｄｅｖ１とＨＢＡ１とＣＨＡ１とＬＵ１とから構成されている。従って、パスＩＤ４３３１が「０００１」のパスは、ｄｅｖ１からＬＵ１までのパスであり、ＨＢＡ１とＣＨＡ１とを経由するパスであることがわかる。パス状態４３３６は、当該パスが有効（Online）か無効（Offline）かを表す情報である。例えば、ＣＨＡ３に障害が発生したとすると、ＣＨＡ３を経由するパス（パスＩＤが「０００７」のパス）は利用できなくなるので、そのパスのパス状態４３３６は、「Offline」に設定される。パス状態４３３６の設定は、例えば、ドライバ管理ＰＧ４２５によって行われることができる。ドライバ管理ＰＧ４２５は、パス障害を検出した際には、当該パスのパス状態４３３６を「Offline」に設定し、パス回復を検出した際には、当該パスのパス状態４３３６を「Online」に設定することができる。

図４は、ＡＰ定義ファイル４２３の一例を示した図である。

ＡＰ定義ファイル４２３は、ＡＰ４２１に関する情報が記載されたファイルであり、ＡＰ４２１ごとに用意される。同図では、符号４２３ａがＡＰ１のＡＰ定義ファイルを示しており、符号４２３ｂがＡＰ２のＡＰ定義ファイルを示している。ＡＰ定義ファイル４２３には、例えば、ＡＰ４２１が利用する論理デバイスの名称（論理デバイス名）と、系切替順序を示した情報とが記録される。本実施形態では、論理デバイス名として、論理デバイスＩＤが記録される。系切替順序は、ノードを切替えるためのノード４００の順序、即ち、主ノードを決定するためのノード４００の順序（優先順位の並び）である。ＡＰ４２３を稼働できる複数のノード４００のうち、系切替順序における順番が最先のノード４００が主ノードとされ、それ以外のノード４００が待機ノードとされる。主ノードに障害が発生した場合には、待機ノードの中で系切替順序における順番が最先のノード４００が選択され、その選択されたノード４００が主ノードとされる。系切替順序は、例えば、同図に示すように、ＡＰ４２３を稼働できるノード４００のノードＩＤを、上下に並べて記載することで定義される。このような定義方法の場合は、例えば、上に記載されたノード４００程、順番が先のノード４００又は順番が後のノード４００であると定義される。本実施形態では、上に記載されたノード４００程、順番が先のノード４００であるとする。

ＡＰ１のＡＰ定義ファイル４２３ａの場合は、論理デバイス名として「ｄｅｖ１」が記載されている。このことから、ＡＰ１は、ｄｅｖ１を利用することがわかる。また、切替順序を示す情報として、上から順番に、「ＮＤ１」、「ＮＤ２」、「ＮＤ３」、「ＮＤ４」が記載されている。ここで、ＮＤ１、ＮＤ２、ＮＤ３、ＮＤ４は、それぞれノード１、ノード２、ノード３、ノード４の識別子である。従って、ＡＰ１における系切替順序は、ノード１が最先のノードであり、ノード１→ノード２→ノード３→ノード４となることがわかる。そして、通常時（障害が発生していないとき）は、ノード１が主ノードとなる。

一方、ＡＰ２のＡＰ定義ファイル４２３ｂの場合は、論理デバイス名として「ｄｅｖ２」が記載されている。このことから、ＡＰ２は、ｄｅｖ２を利用することがわかる。また、切替順序を示す情報として、上から順番に、「ＮＤ２」、「ＮＤ３」、「ＮＤ４」、「ＮＤ１」が記載されている。従って、ＡＰ２における系切替順序は、ノード２が最先のノードであり、ノード２→ノード３→ノード４→ノード１となることがわかる。そして、通常時は、ノード２が主ノードとなる。

このように、系切替順序はＡＰ４２１ごとに定義されるので、系切替順序は、全てのＡＰ４２１において同一であってもよいし、ＡＰ４２１ごとに異なってもよい。従って、例えば、ＡＰ１とＡＰ２のそれぞれの主ノードが同一のノード４００である場合もあれば、ＡＰ１の待機ノードがＡＰ２の主ノードとして稼働する場合もある。

図５は、パス管理テーブル１２４の一例を示した図である。

パス管理テーブル１２４は、本システムを構成する全てのノード４００の各々が備えるパステーブル４３３を統合したものである。パス管理テーブル１２４は、例えば、後述の第二のリソーステーブル作成処理のために用意されるが、その処理を行わない場合には無くてもよい。パス管理テーブル１２４には、例えば、ノードＩＤ１２４１と、パスＩＤ１２４２と、論理デバイスＩＤ１２４３と、ＨＢＡＩＤ １２４４と、ＣＨＡ ＩＤ １２４５と、ＬＵ ＩＤ １２５６と、パス状態１２４７とが記録される。ノードＩＤ１２４１以外の情報（論理デバイスＩＤ１２４３、ＨＢＡＩＤ １２４４、ＣＨＡ ＩＤ １２４５、ＬＵ ＩＤ １２５６及びパス状態１２４７）は、パステーブル４２３と同じである。これらは、各ノード４００が備えるパステーブル４２３に記録された値がそのまま設定される。ノードＩＤ１２４１は、ノードＩＤ１２４１以外の情報がどのノード４００に関するものであるかを示す、ノードの識別子である。パス管理テーブル１２４は、例えば、初期化ＰＧ１２１によって作成される。また、Ｔｒａｐ受信ＰＧ１２３がパス障害／回復情報を受信したときには、Ｔｒａｐ受信ＰＧ１２３は、その情報に基づいてパス管理テーブル１２４の所定の情報（例えば、パス状態１２４７）を変更することができる。

図６は、リソーステーブル１２５の一例を示した図である。

リソーステーブル１２５は、本システムにおいて稼働されるＡＰ４２１について、そのＡＰ４２１を稼働するために必要とされるリソース（例えば、ノード４００や、ノード４００からストレージ装置６００までのパス等）に関する情報を管理するためのテーブルである。例えば、リソーステーブル１２５には、ＡＰ２４１ごとに、ＡＰ２４１を一意に特定するための識別子であるＡＰＩＤ １２５１と、当該ＡＰ２４１によって利用されるｄｅｖ４３４の識別子である論理デバイスＩＤ１２５２と、当該ＡＰ２４１を稼働する複数のノード４００のそれぞれの識別子である複数のノードＩＤ１２５３とが記録される。そして、ＡＰＩＤ １２５１と論理デバイスＩＤ１２５２とノードＩＤ１２５３との組み合わせごとに、オンラインパス数１２５４と、パス総数１２５５と、主ノード１２５６とが記録される。オンラインパス数１２５４は、ノードＩＤ１２５３で特定されるノード４００における、論理デバイスＩＤ１２５２で特定されるｄｅｖ４３４に関するパスのうち、有効なパスの数である。パス総数１２５５は、ノードＩＤ１２５３で特定されるノード４００における、論理デバイスＩＤ１２５２で特定されるｄｅｖ４３４に対応するパスの総数である。主ノード１２５６は、ノードＩＤ１２５３で特定されるノード４００が主ノードか否かを示す。例えば、当該ノード４００が主ノードである場合には、主ノード１２５６は「True」と設定され、当該ノード４００が待機ノードである場合には、主ノード１２５６は「False」と設定される。

リソーステーブル１２５は、初期化ＰＧ１２１によって作成され、所定のタイミングでフェールオーバ更新ＰＧ１２２によって一部の情報（例えば、オンラインパス数１２５４、主ノード１２５６）が更新される。尚、リソーステーブル１２５の一部の情報は、管理者による入力により設定されてもよい。

尚、リソーステーブル１２５の構成は、上述したものに限定されない。本テーブル１２５は、上述した情報要素のうちの一部で構成されてもよいし、他の新たな情報要素が追加された形で構成されてもよい。例えば、ＡＰＩＤ １２５１と論理デバイスＩＤ１２５２とノードＩＤ１２５３との組み合わせごとに、ＡＰ ＩＤ １２５１で特定されるＡＰ４２１の負荷の状況を示す負荷情報（プロセッサ４１０やメモリ４２０の使用率、稼働しているＡＰ４２１の数等）が更に記録されてもよい。また、パス総数１２５５、主ノード１２５６は、必ずしも記録されなくともよい。

図７は、系切替順序テーブル１２６の一例を示した図である。

系切替順序テーブル１２６には、本システムにおいて稼働されるＡＰ４２１ごとに、そのＡＰ４２１の系切替順序が記録される。即ち、本テーブル１２６は、ノード４００がＡＰ４２１ごとに備えるＡＰ定義ファイル４２３のそれぞれに記載される系切替順序を示す情報を統合したものである。系切替順序テーブル１２６には、例えば、ＡＰ４２１ごとにＡＰＩＤ １２６１と、系切替順序１２６２とが記録される。系切替順序１２６２には、例えば、同図に示すように、ノード４００のＩＤが順番に並べられて記録される。同図の場合は、左に記録されたノード４００程、順番が先のノード４００であることを示している。従って、ＡＰ１の系切替順序は、ノード１が最先のノードであり、ノード１→ノード２→ノード３→ノード４となることがわかる。また、ＡＰ２の系切替順序は、ノード２が最先のノードであり、ノード２→ノード３→ノード４→ノード１となることがわかる。

系切替順序テーブル１２６は、初期化ＰＧ１２１によって作成され、所定のタイミングでフェールオーバ更新ＰＧ１２２によって系切替順序１２６２が更新される。初期化ＰＧ１２１は、ノード４００がＡＰ４２１ごとに備えるＡＰ定義ファイル４２３に基づいて、系切替順序テーブル１２６を作成することができる。また、初期化ＰＧ１２１は、リソーステーブル１２５に基づいて、系切替順序テーブル１２６を作成することもできる。フェールオーバ更新ＰＧ１２２は、リソーステーブル１２５に基づいて、系切替順序１２６２を更新する。

系切替順序テーブル１２６における系切替順序１２６２が更新されると、その系切替順序１２６２は、対応するＡＰＩＤ １２６１によって特定されるＡＰ４２１を稼働するノード４００の全部又は一部に通知される。通知を受けたノード４００は、ＡＰ定義ファイル４２３に記載された系切替順序を示す情報を、通知された系切替順序１２６２に変更する。これによって、クラスタシステムにおける、対応するＡＰ４２１の系切替順序が変更されることになる。

以下、本システムを構成する管理サーバ１００の動作を説明する。

図８は、初期化ＰＧ１２１が実行する処理のフローチャートである。

まず、初期化ＰＧ１２１は、リソーステーブル１２５を作成する（Ｓ１０１）。リソーステーブル１２５を作成する処理（以下、「リソーステーブル作成処理」）については、後述する。

次に、初期化ＰＧ１２１は、系切替順序テーブル１２６を作成する（Ｓ１０２）。系切替順序テーブル１２６を作成する処理（以下、「系切替順序テーブル作成処理」）については、後述する。

以上が、初期化ＰＧ１２１が実行する処理のフローチャートの説明である。

リソーステーブル作成処理としては、例えば、以下の二つの処理が考えられる。以下、それぞれの処理を説明する。

図９は、第一のリソーステーブル作成処理のフローチャートである。

第一のリソーステーブル作成処理では、リソーステーブルに登録される全ての情報がノード４００から取得される。

まず、初期化ＰＧ１２１は、本システムを構成する全て又は一部のノード４００から、リソーステーブル１２５に登録される、ＡＰＩＤ １２５１、論理デバイスＩＤ１２５２及びノードＩＤ１２５３の組み合わせの情報と、ＡＰ４２１ごとの現時点での主ノードを示す情報とを取得する（Ｓ２０１）。尚、リソーステーブル１２５に主ノード１２５６を記録しない場合には、初期化ＰＧ１２１は、ＡＰ４２１ごとの現時点での主ノードを示す情報を取得しなくともよい。初期化ＰＧ１２１は、ノード４００におけるクラスタソフトウェア４２２と通信することで、クラスタソフトウェア４２２から、これらの情報を取得することができる。

クラスタソフトウェア４２２は、初期化ＰＧ１２１に通知する上記の組み合わせの情報を、例えば、自己が備えるＡＰ定義ファイル４２３から取得することができる。例えば、クラスタソフトウェア４２２が図４に示したような二つのＡＰ定義ファイル４２３ａ、４２３ｂを備えていれば、そのことから、本システムでは、二つのＡＰ４２１（ＡＰ１、ＡＰ２）が稼働されることがわかる。また、ＡＰ１に関しては、上述したように、ＡＰ定義ファイル４２３ａから、ＡＰ１がｄｅｖ１を利用し、また、ＡＰ１の系切替順序がノード１→ノード２→ノード３→ノード４であることがわかる。つまり、ＡＰ１を稼働することができるノード４００として、ノード１、ノード２、ノード３及びノード４が存在することがわかる。従って、この場合、ＡＰ１とｄｅｖ１とノード１の組み合わせ、ＡＰ１とｄｅｖ１とノード２との組み合わせ、ＡＰ１とｄｅｖ１とノード３の組み合わせ、ＡＰ１とｄｅｖ１とノード４の組み合わせの情報が、それぞれ初期化ＰＧ１２１に通知される。同様の方法で、ＡＰ２に関しても、リソーステーブル１２５に登録される組み合わせの情報が初期化ＰＧ１２１に通知される。

次に、初期化ＰＧ１２１は、Ｓ２０１で取得した情報に基づいて、リソーステーブル１２５に一部の情報、即ち、ＡＰＩＤ １２５１、論理デバイスＩＤ１２５２、ノードＩＤ１２５３及び主ノード１２５６を登録する（Ｓ２０２）。

次に、初期化ＰＧ１２１は、リソーステーブル１２５に登録された、ＡＰ４２１、ｄｅｖ４３４及びノード４００の組み合わせごとに、当該ノード４００から、当該ｄｅｖ４３４に関するパスの総数と、当該ｄｅｖ４３４に関するパスであって有効なパスの数とを取得する（Ｓ２０３）。初期化ＰＧ１２１は、ノード４００におけるパス管理ドライバ４３０と通信することで、パス管理ドライバ４３０から、これらの情報を取得することができる。

この取得要求を受けたパス管理ドライバ４３０は、自己が備えるパステーブル４３３から、パスの総数及び有効なパスの数を取得し、それらを管理サーバ１００へ通知する。例えば、ノード１がｄｅｖ１に関してこの取得要求を受けた場合は、ノード１のパステーブル４３３ａが図３に示されたものであれば、ｄｅｖ１に関するパスの総数及び有効なパスの数は、次のようにして取得される。即ち、パステーブル４３３ａに登録されているパスのうち、論理デバイスＩＤ４３３２が「ｄｅｖ１」であるパスの数が計算され、その数がパスの総数とされる。また、論理デバイスＩＤ４３３２がｄｅｖ１であるパスのうち、パス状態４３３が「Online」であるパスの数が計算され、その数が有効なパスの数とされる。

その後、初期化ＰＧ１２１は、Ｓ２０３において取得した情報を、リソーステーブル１２５に登録する（Ｓ２０４）。即ち、Ｓ２０３において情報の取得の対象とされたＡＰ４２１、ｄｅｖ４３４及びノード４００の組み合わせについて、その組み合わせに対応するオンラインパス数１２５４とパス総数１２５５とには、Ｓ２０３で取得された有効なパスの数とパスの総数とが、それぞれ登録される。

リソーステーブル１２５に登録された、ＡＰ４２１、ｄｅｖ４３４及びノード４００の組み合わせの全てについて、その組み合わせに対応するオンラインパス数１２５４とパス総数１２５５とが、全て登録されるまで、Ｓ２０３及びＳ２０４の処理が繰返される。

尚、この第一のリソーステーブル作成処理では、Ｓ２０２において登録される情報は、Ｓ２０１においてノード４００から自動的に取得された情報に代えて、管理サーバ１００が提供するＵＩ（図示しない）を介して管理者によって入力される情報であってもよい。

以上が、第一のリソーステーブル作成処理のフローチャートの説明である。

図１０は、第二のリソーステーブル作成処理のフローチャートである。

第二のリソーステーブル作成処理では、ノード４００から、全てのノード４００のパステーブル４３３と、全てのＡＰ４２１に関するＡＰ定義ファイル４２３とが取得される。そして、全てノード４００のパステーブル４３３から、それらを統合したパス管理テーブル１２４が作成される。リソーステーブルは、パス管理テーブル１２４とＡＰ定義ファイル４２３とを参照して作成される。

具体的には、まず、初期化ＰＧ１２１は、本システムを構成する全て又は一部のノード４００から、本システムにおいて稼働される全てのＡＰ４２１に関するＡＰ定義ファイル４２３と、ＡＰ４２１ごとの現時点での主ノードを示す情報とを取得する（Ｓ３０１）。尚、第一のリソーステーブル作成処理と同様に、リソーステーブル１２５に主ノード１２５６を記録しない場合には、初期化ＰＧ１２１は、ＡＰ４２１ごとの現時点での主ノードを示す情報を取得しなくともよい。初期化ＰＧ１２１は、各ノード４００と通信することで、クラスタソフトウェア４２２から、ＡＰ定義ファイル４２３を取得することができる。

次に、初期化ＰＧ１２１は、本システムを構成する全てのノード４００から、各々のノード４００が備えるパステーブル４３３を取得する（Ｓ３０２）。初期化ＰＧ１２１は、ノード４００におけるパス管理ドライバ４３０と通信することで、パス管理ドライバ４３０から、パステーブル４３３を取得することができる。

その後、初期化ＰＧ１２１は、Ｓ３０２において取得した全てのパステーブル４３３を統合して、パス管理テーブル１２４を作成する（Ｓ３０３）。

その後、初期化ＰＧ１２１は、Ｓ３０１で取得したＡＰ定義ファイル４２３及び主ノードを示す情報と、Ｓ３０３で作成されたパス管理テーブル１２４とを参照して、リソーステーブル１２５を作成する（Ｓ４０２）。ＡＰ定義ファイル４２３から、リソーステーブル１２５に登録される、ＡＰＩＤ １２５１、論理デバイスＩＤ１２５２及びノードＩＤ１２５３の組み合わせの情報を取得する方法は、上述したとおりである。また、パス管理テーブル１２４から、リソーステーブル１２５に登録されるオンラインパス数１２５４及びパス総数１２５５を取得する方法は、上述した、各ノード４００のパステーブル４２３から取得する方法と実質的に同じである。

以上が、第二のリソーステーブル作成処理のフローチャートである。

図１１は、系切替順序テーブル作成処理のフローチャートである。

まず、初期化ＰＧ１２１は、本システムを構成する全て又は一部のノード４００から、本システムにおいて稼働される全てのＡＰ４２１に関するＡＰ定義ファイル４２３を取得する（Ｓ４０１）。

次に、初期化ＰＧ１２１は、Ｓ４０１で取得したＡＰ定義ファイル４２３を参照して、系切替順序テーブル１２６を作成する（Ｓ４０２）。具体的には、初期化ＰＧ１２１は、系切替順序テーブル１２６における、各ＡＰ４２１の系切替順序１２６２が、当該ＡＰ４２１に関するＡＰ定義ファイル４２３に記載された系切替順序となるように、系切替順序テーブル１２６を作成する（Ｓ４０２）。

以上が、系切替順序テーブル作成処理のフローチャートである。

図１２は、フェールオーバ更新ＰＧ１２２が実行する処理のフローチャートである。

本処理は、フェールオーバ更新ＰＧ１２２が、Ｔｒａｐ受信ＰＧ１２３からパス障害／回復情報を通知されたときに、開始される。

まず、フェールオーバ更新ＰＧ１２２は、通知されたパス障害／回復情報から、パス障害かパス回復かを示す情報と、そのパス障害又はパス同復を検出したノード４００のＩＤと、障害が発生したパス又は回復したパスに対応するｄｅｖ４３４のＩＤとを取得する（Ｓ５０１）。

次に、フェールオーバ更新ＰＧ１２２は、Ｓ５０１で取得したノード４００のＩＤとｄｅｖ４３４のＩＤとをキーとして、それらの情報に対応するＡＰＩＤ １２５１を、リソーステーブル１２５から取得する（Ｓ５０２）。対応するＡＰ ＩＤ １２５１が複数個ある場合には、一つのＡＰ ＩＤ １２５１が取得される。

これ以降の処理（Ｓ５０３〜Ｓ５１２）は、Ｓ５０２で取得されたＡＰＩＤ １２５１によって特定されるＡＰ４２１ごとに行われる。

まずＳ５０３において、Ｓ５０１で取得した、パス障害かパス回復かを示す情報に基づいて、このパス障害／回復情報の通知が、パス障害の通知であるかパス回復の通知であるかが判断される。フェールオーバＰＧ１２２は、この判断結果に基づいて、リソーステーブル１２５を更新する。

即ち、パス障害の通知の場合は（Ｓ５０３：ＹＥＳ）、フェールオーバ更新ＰＧ１２２は、Ｓ５０１及びＳ５０２で取得したＡＰＩＤ １２５１とノード４００のＩＤとｄｅｖ４３４のＩＤとの組み合わせに対応するオンラインパス数１２５４を一つ減らす（Ｓ５０４）。一方、パス回復の通知の場合は（Ｓ５０３：ＮＯ）、フェールオーバ更新ＰＧ１２２は、Ｓ５０１及びＳ５０２で取得したＡＰＩＤ １２５１とノード４００のＩＤとｄｅｖ４３４のＩＤとの組み合わせに対応するオンラインパス数１２５４を一つ増やす（Ｓ５０５）。

次に、Ｓ５０４又はＳ５０５において変更されたオンラインパス数１２５４が、所定の閾値以下であるか否かが判断される（Ｓ５０６）。この閾値は、例えば、デフォルト値として所定の値（例えば、１）が設定されてもよいし、管理者により設定されてもよい。

当該オンラインパス数１２５４が、所定の閾値以下でない場合は（Ｓ５０６：ＮＯ）、当該ＡＰ２４１に関する処理は終了する。リソーステーブル１２５に他のＡＰ２４１が登録されていれば、そのＡＰ２４１に関する処理が行われる。

当該オンラインパス数１２５４が、所定の閾値以下である場合は（Ｓ５０６：ＹＥＳ）、当該ＡＰ２４１に関する系切替順序の見直しが行われる。即ち、フェールオーバ更新ＰＧ１２２は、当該ＡＰ２４１を示すＡＰＩＤ １２５１に対応する全てのノード４００の各々のオンラインパス数１２５４を比較し、オンラインパス数１２５４が降順になるように、ノード４００の順序を決定する（Ｓ５０７）。そして、フェールオーバ更新ＰＧ１２２は、Ｓ５０７で決定したノード４００の順序が、現在の系切替順序と異なるか否か、即ち、系切替順序テーブル１２６における、当該ＡＰを示すＡＰＩＤ １２６１に対応する系切替順序１２６２と異なるか否かを判断する（Ｓ５０８）。

現在の系切替順序と同一である場合は（Ｓ５０８：ＮＯ）、当該ＡＰ２４１に関する処理は終了する。リソーステーブル１２５に他のＡＰ２４１が登録されていれば、そのＡＰ２４１に関する処理が行われる。

現在の系切替順序と異なる場合は（Ｓ５０８：ＹＥＳ）、フェールオーバ更新ＰＧ１２２は、系切替順序テーブル１２６における、当該ＡＰを示すＡＰＩＤ １２６１に対応する系切替順序１２６２を、Ｓ５０７で決定したノード４００の順序に変更する（Ｓ５０９）。その後、フェールオーバ更新ＰＧ１２２は、変更された系切替順序１２６２を、当該ＡＰを稼働するノード４００の全部又は一部へ通知する（Ｓ５１０）。この通知は、ノード４００におけるクラスタソフトウェア４２２に対して行われる。クラスタソフトウェア４２２は、通知された系切替順序に基づいて、ＡＰ定義ファイル４２３に記載されている、系切替順序を示す情報を変更する。

リソーステーブル１２５に登録されている全てのＡＰ４２１について、Ｓ５０２からＳ５１０までの処理が行われる（Ｓ５１１）。

以上が、フェールオーバ更新ＰＧ１２２が実行する処理のフローチャートの説明である。

図１３Ａ及び１３Ｂは、それぞれ、変更前の系切替順序テーブル１２６及びＡＰ定義ファイル４２３の一例を示している。また、図１４Ａ及び図１４Ｂは、それぞれ、変更後の系切替順序テーブル１２６及びＡＰ定義ファイル４２３の一例を示している。

図１３Ａ、Ｂ及び図１４Ａ、Ｂに示されるように、管理サーバ１００における系切替順序テーブル１２６が更新されると、その更新に対応して、ノード４００のＡＰ定義ファイルに記載される系切替順序を示す情報が変更される。即ち、図１３Ａ及び図１４Ａのように、系切替順序テーブル１２６における、ＡＰ１の系切替順序１２６２が、ノード１→ノード２→ノード３→ノード４からノード１→ノード４→ノード３→ノード２に変更されている。これに伴って、図１３Ｂ及び図１４Ｂのように、ＡＰ定義ファイル４２３における系切替順序を示す情報が、ノード１→ノード２→ノード３→ノード４からノード１→ノード４→ノード３→ノード２に変更される。また、ＡＰ２に関しては、系切替順序テーブル１２６において更新されていないため、ＡＰ定義ファイル４２３においても、その系切替順序を示す情報は変更されない。

以上、上述した実施形態によれば、無駄なノード４００の切替を事前に防止することができ、適切なノード４００の切替が行えるようになる。

以上、本発明の幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、管理サーバ１００は、系切替順序テーブル１２６を利用せずに、系切替順序の変更を指示してもよい。即ち、管理サーバ１００は、系切替順序が変更されたか否かに関係なく、リソーステーブル１２５が更新されたときに、ノード４００へ系切替順序を通知することができる。この場合は、例えば、系切替順序の変更の通知を受けたクラスタソフトウェア４２２が、通知された系切替順序とＡＰ定義ファイル４２３に記載されている元々の系切替順序とを比較して、ＡＰ定義ファイル４２３を更新するか否かを決定することができる。

また、管理サーバ１００は、オンラインパス数１２５４に基づいて、系切替順序を決定したが、例えば、ＡＰ４２１の負荷の状況を示す負荷情報をも考慮して、系切替順序を決定することができる。この場合は、管理サーバ１００は、例えば、オンラインパス数１２５４が多く、かつ、ＡＰ４２１に対応する負荷情報が示す負荷が少ないノード程、順番が先になるように、切替順序を決定することができる。

また、管理サーバ１００は、系切替順序の代わりに、次の現用ノード（即ち、系切替順序における順番が最先のノード）を示す情報をノード４００へ通知してもよい。

本実施形態に係る計算機システムの構成例を示した図である。 本実施形態に係るノードとストレージ装置との間のパスの構成例を示した図である。 パステーブルの一例を示した図である。 ＡＰ定義ファイルの一例を示した図である。 パス管理テーブルの一例を示した図である。 リソーステーブルの一例を示した図である。 系切替順序テーブルの一例を示した図である。 初期化ＰＧが実行する処理のフローチャートである。 第一のリソーステーブル作成処理のフローチャートである。 第二のリソーステーブル作成処理のフローチャートである。 系切替順序テーブル作成処理のフローチャートである。 フェールオーバ更新ＰＧが実行する処理のフローチャートである。 図１３Ａは、変更前の系切替順序テーブルの一例である。図１３Ｂは、変更前のＡＰ定義ファイルの一例である。 図１４Ａは、変更後の系切替順序テーブルの一例である。図１４Ｂは、変更後のＡＰ定義ファイルの一例である。

符号の説明

１００…管理サーバ、２００…クライアント、３００…ＬＡＮ、４００…ノード、５００…ＳＡＮ、６００…ストレージ装置

Claims (20)

1. アプリケーションを稼働しストレージ装置にＩ／Ｏ要求を発行する三以上のノードの各々について、前記アプリケーションが利用するリソースに関する情報を示したリソース情報と、
   前記各ノードから前記リソースに関する状況の変化を示すリソース状況情報を受信する受信部と、
   前記受信部が受信した前記リソース状況情報に基づいて、前記リソース情報を更新する更新部と、
   前記更新部が更新した前記リソース情報に基づいて、次の現用ノードを決定する決定部と、
   前記決定部が決定した次の現用ノードを示す情報を前記三以上のノードのうちの少なくとも一つのノードへ通知する通知部と、
   を備えるノード管理装置。
2. 前記リソース情報は、前記ノードごとに、前記アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含み、
   前記受信部が受信するリソース状況情報は、前記パスに障害が発生し又は障害が回復したことを示す障害情報と、前記障害の発生又は回復を検出したノードを特定するノード情報とを含み、
   前記更新部は、前記障害情報及びノード情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を更新し、
   前記決定部は、前記更新部が更新した前記リソース情報に基づいて、現用ノード以外のノードのうち前記有効パス数が多いノードを次の現用ノードと決定する、
   請求項１記載のノード管理装置。
3. 前記更新部は、前記障害情報が前記パスに障害が発生したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を減少させ、前記障害情報が前記パスに障害が回復したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を増加させる、
   請求項２記載のノード管理装置。
4. 前記受信部が受信する障害情報は、前記パスに障害が発生し又は障害が回復したことを示す情報と、前記障害が発生し又は回復したパスの数である障害パス数とを含み、
   前記更新部は、前記障害情報が前記パスに障害が発生したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を前記障害パス数だけ減少させ、前記障害情報が前記パスに障害が回復したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を前記障害パス数だけ増加させる、
   請求項３記載のノード管理装置。
5. 前記決定部は、前記更新部が更新した前記リソース情報に基づいて、次の現用ノードの順番及びそれ以降の現用ノードの順番を表すノードの切替順序を決定し、
   前記通知部は、前記決定部が決定したノードの切替順序を前記三以上のノードのうちの少なくとも一つのノードへ通知する、
   請求項１記載のノード管理装置。
6. 前記リソース情報は、前記ノードごとに、前記アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含み、
   前記受信部が受信するリソース状況情報は、前記パスに障害が発生し又は障害が回復したことを示す障害情報と、前記障害の発生又は回復を検出したノードを特定するノード情報とを含み、
   前記更新部は、前記障害情報及びノード情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を更新し、
   前記決定部は、前記更新部が更新した前記リソース情報に基づいて、前記有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する、
   請求項５記載のノード管理装置。
7. ノードの切替順序を示したノード切替順序情報と、
   前記決定部が決定した第一のノードの切替順序と前記ノード切替順序情報に示される第二のノードの切替順序と比較し、前記第一のノードの切替順序と前記第二のノードの切替順序とが異なる場合に、前記ノード切替順序情報が示すノードの切替順序を前記第一の切替順序に更新する第二の更新部と、を更に備え、
   前記通知部は、前記ノード切替順序情報が更新された場合に、前記第一の切替順序を前記ノードへ通知する、
   請求項６記載のノード管理装置。
8. 前記決定部は、前記更新部によって更新された有効パス数が所定の閾値以下となった場合に、前記更新部が更新した前記リソース情報に基づいて、前記有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する、
   請求項６記載のノード管理装置。
9. 前記三以上のノードの各々は、複数のアプリケーションを有し、
   前記リソース情報は、前記アプリケーションと前記アプリケーションを稼働するノードとの組合わせごとに、前記有効パス数を含み、
   前記受信部が受信するリソース状況情報は、前記障害情報及びノード情報に加えて、前記アプリケーションを特定するアプリケーション情報を含み、
   前記更新部は、前記障害情報、ノード情報及びアプリケーション情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードと前記アプリケーション情報によって特定されるアプリケーションとの組合わせに対応する前記有効パス数を更新し、
   前記決定部は、前記更新部が更新した前記リソース情報に基づいて、前記アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち前記有効パス数が多いノードを次の現用ノードと決定する、
   請求項２記載のノード管理装置。
10. 前記リソース情報は、前記アプリケーションと前記アプリケーションを稼働するノードとの組合わせごとに、前記有効パス数と前記アプリケーションの負荷を示す負荷情報とを含み、
    前記決定部は、前記更新部が更新した前記リソース情報に基づいて、前記アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち前記有効パス数が多く、かつ、前記アプリケーションに対応する負荷情報が示す負荷が少ないノードを次の現用ノードと決定する、
    請求項９記載のノード管理装置。
11. アプリケーションを稼働しストレージ装置にＩ／Ｏ要求を発行する三以上のノードの各々のノードから、前記アプリケーションが利用するリソースに関する状況の変化を示すリソース状況情報を受信し、
    前記リソース状況情報に基づいて、前記三以上のノードの各々について前記アプリケーションが利用するリソースに関する情報を示したリソース情報を更新し、
    前記更新された前記リソース情報に基づいて、次の現用ノードを決定し、
    前記決定された次の現用ノードを示す情報を前記三以上のノードのうちの少なくとも一つのノードへ通知する、
    ノード管理方法。
12. 前記リソース情報は、前記ノードごとに、前記アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含み、
    前記リソース状況情報は、前記ノードから前記パスに障害が発生し又は障害が回復したことを示す障害情報と、前記障害の発生又は回復を検出したノードを特定するノード情報とを含み、
    前記リソース情報の更新では、前記障害情報及びノード情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を更新し、
    前記次の現用ノードの決定では、前記更新された前記リソース情報に基づいて、現用ノード以外のノードのうち前記有効パス数が多いノードを次の現用ノードと決定する、
    請求項１１記載のノード管理方法。
13. 前記リソース情報の更新では、前記障害情報が前記パスに障害が発生したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を減少させ、前記障害情報が前記パスに障害が回復したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を増加させる、
    請求項１２記載のノード管理方法。
14. 前記障害情報は、前記パスに障害が発生し又は障害が回復したことを示す情報と、前記障害が発生し又は回復したパスの数である障害パス数とを含み、
    前記リソース情報の更新では、前記障害情報が前記パスに障害が発生したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を前記障害パス数だけ減少させ、前記障害情報が前記パスに障害が回復したことを示すときは、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を前記障害パス数だけ増加させる、
    請求項１３記載のノード管理方法。
15. 前記次の現用ノードの決定では、前記更新された前記リソース情報に基づいて、次の現用ノードの順番及びそれ以降の現用ノードの順番を表すノードの切替順序を決定し、
    前記ノードへの通知では、前記決定されたノードの切替順序を前記三以上のノードのうちの少なくとも一つのノードへ通知する、
    請求項１１記載のノード管理方法。
16. 前記リソース情報は、前記ノードごとに、前記アプリケーションが利用する複数のパスのうち有効なパスの数である有効パス数を含み、
    前記リソース状況情報は、前記ノードから前記パスに障害が発生し又は障害が回復したことを示す障害情報と、前記障害の発生又は回復を検出したノードを特定するノード情報とを含み、
    前記リソース情報の更新では、前記障害情報及びノード情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードに対応する有効パス数を更新し、
    前記次の現用ノードの決定では、前記更新された前記リソース情報に基づいて、前記有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する、
    請求項１５記載のノード管理方法。
17. 前記更新された前記リソース情報に基づいて決定された第一のノードの切替順序とノードの切替順序を示したノード切替順序情報に示される第二のノードの切替順序と比較し、前記第一のノードの切替順序と前記第二のノードの切替順序とが異なる場合に、前記ノード切替順序情報が示すノードの切替順序を前記第一の切替順序に更新し、
    前記ノードへの通知では、前記ノード切替順序情報が更新された場合に、前記第一の切替順序を前記三以上のノードのうちの少なくとも一つのノードへ通知する、
    請求項１６記載のノード管理方法。
18. 前記次の現用ノードの決定では、前記更新された有効パス数が所定の閾値以下となった場合に、前記更新された前記リソース情報に基づいて、前記有効パス数が多いノード程順番が先になるように、ノードの切替順序を決定する、
    請求項１６記載のノード管理方法。
19. 前記三以上のノードの各々は、複数のアプリケーションを有し、
    前記リソース情報は、前記アプリケーションと前記アプリケーションを稼働するノードとの組合わせごとに、前記有効パス数を含み、
    前記リソース状況情報は、前記障害情報及びノード情報に加えて、前記アプリケーションを特定するアプリケーション情報を含み、
    前記リソース情報の更新では、前記障害情報、ノード情報及びアプリケーション情報に基づいて、前記リソース情報における、前記ノード情報によって特定されるノードと前記アプリケーション情報によって特定されるアプリケーションとの組合わせに対応する前記有効パス数を更新し、
    前記次の現用ノードの決定では、前記更新された前記リソース情報に基づいて、前記アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち前記有効パス数が多いノードを次の現用ノードと決定する、
    請求項１２記載のノード管理方法。
20. 前記リソース情報は、前記アプリケーションと前記アプリケーションを稼働するノードとの組合わせごとに、前記有効パス数と前記アプリケーションの負荷を示す負荷情報とを含み、
    前記次の現用ノードの決定では、前記更新された前記リソース情報に基づいて、前記アプリケーション情報によって特定されるアプリケーションを有する三以上のノードについて、現用ノード以外のノードのうち前記有効パス数が多く、かつ、前記アプリケーションに対応する負荷情報が示す負荷が少ないノードを次の現用ノードと決定する、
    請求項１９記載のノード管理方法。

Images