JP2005534081A - 共有ストレージを備えたマルチノード環境のためのシステムおよび方法 - Google Patents

Abstract

【課題】
【解決手段】 マルチノード環境を提供するためのシステムおよび方法が開示される。システムおよび方法は、第１のオペレーティングシステム（３００a)と関連付けられた第１のノード(３０６ａ)と、第２のオペレーティングシステムと関連付けられた第２のノードとを備える。第２のオペレーティングシステムは、第１のオペレーティングシステムから独立している。システムおよび方法は、さらに、ストレージと、第２のノードをストレージと接続する相互接続（３０４）と、を備える。第１のノードは、ストレージに直接アクセスし、第２のノードは、ストレージに直接アクセスする。

Description

本発明は、概して、コンピュータシステムに関する。特に、本発明は、ストレージなどのリソースを共有するコンピュータシステムに関する。

サーバは、通例、大きなウェブのサービスや制作に伴って用いられるような大きなアプリケーションおよびワークロードに用いられる。しばしば、唯一のサーバが、必要なアプリケーションを実行するのに十分な能力を持たない場合がある。多量のトラフィックに対応するために、ストレージエリアネットワーク（ＳＡＮ）内のいくつかのストレージデバイスと共に、いくつかのサーバを用いることができる。システムが巨大化すると、アプリケーションは、しばしば、保守を実行するためにアクセスを遮断するのを回避するために重要である。

典型的なサーバ管理システムは、サーバおよび共有ストレージを管理する１つの管理制御ステーションを用いる。そのようなシステムに起こり得る問題は、保守を実行するためにストレージエリアネットワーク全体の停止を引き起こし得るシングルポイント障害が生じ得ることである。もう一つの問題は、通例、そのシステムへの変更が生じた場合に、サーバ間の動的な協調がないことである。

そのようなシステムは、通例、大きなメインフレームを用いる。メインフレームの問題は、非常に高価なことである。あるいは、システムは、比較的小型のコンピュータを用いてもよいが、この解決法では、通例、コンピュータ間に１つのオペレーティングシステムを備えた１つの大型のマシンであるかのように機能するよう、コンピュータを協調させるカスタマイズ・オペレーティングシステムとカスタマイズ・ハードウェアとが必要になる。カスタマイズ・ハードウェアを入手して維持するには、非常にコストが掛かる。

したがって、共有ストレージを備えたマルチノード環境のためのシステムおよび方法を低価格で提供することが必要である。本発明は、そのような要求に応えるものである。

本発明は、処理、装置、システム、コンピュータ読み取り可能なストレージ媒体などのコンピュータ読み取り可能な媒体、またはプログラム命令が光または電子通信回線を介して送信されるコンピュータネットワークを含む種々の態様で実施できることを理解されたい。開示された処理の工程の順序は、本発明の範囲内で変更してよいことに注意されたい。

以下では、本発明の原理を例示する添付の図面に沿って、本発明の１以上の好ましい実施形態の詳細な説明を行う。本発明は、それら実施形態に関連して説明されているが、どの実施形態にも限定されないことを理解されたい。逆に、本発明の範囲は、添付の請求項によってのみ限定され、本発明は、数多くの代替物、変形例、および均等物を含んでいる。本発明の十分な理解を促すよう、以下では、例として数多くの具体的な内容が説明されている。本発明は、それら具体的な内容の一部またはすべてがなくとも請求項に従って実施することができる。明確にするために、本発明に関連する技術分野において周知である技術事項については、本発明を不必要に不明瞭としないよう、詳細な説明を省略した。

図１は、従来のサーバシステムを示すブロック図である。この例では、コンピュータ１００Ａ−１００Ｄが、ネットワーク１０２によってネットワーク接続されている。コンピュータ１００Ａ−１００Ｄの各々は、ローカル接続された専用のストレージ１０４Ａ−１０４Ｄを有する。ビジネスコンピューティングでは、通例、常に情報を共有することが求められるが、この種のシステムは、共有情報へのアクセスが遅いことがあり、また、非常に高価なカスタマイズ・ハードウェアを必要とする場合もある。

図２は、別の従来のシステムを示すブロック図である。この例では、種々のサーバ２００Ａ−２００Ｄのすべてが、サーバ２００Ａ−２００Ｄのすべてを網羅する単一のオペレーティングシステムを用いる。この種のシステムは、通例、カスタマイズ・ハードウェアを必要とするため、非常に高価なものになり得る。この種のシステムに関するもう一つの問題は、１つのコンピュータ２００Ａ−２００Ｄに障害が生じた場合に、マルチサーバシステム全体を停止させる必要が生じ得ることである。したがって、各コンピュータは、標準的なコンピュータよりも信頼性の高い必要があり、さらにコストが上昇する。

したがって、カスタマイズ・ハードウェア要素を必要としないマルチノード環境のためのシステムおよび方法が求められている。本発明は、そのような要求に応えるものである。

図３は、本発明の一実施形態に従って、マルチノード環境のためのシステムを示すブロック図である。この例では、サーバ３００Ａ−３００Ｄが、ネットワーク相互接続３０２を介して接続されている。ネットワーク相互接続３０２は、イーサネット（商標）、インフィニバンド（商標）ネットワーク、またはファイバチャネルネットワークなど、ホスト間通信が可能な任意のネットワークインフラストラクチャであってよい。サーバ３００Ａ−３００Ｄは、さらに、データストレージ相互接続３０４に接続されている。データストレージ相互接続３０４は、共有ストレージ３０６Ａ−３０６Ｄに接続されている。データストレージ相互接続３０４は、サーバ３００Ａ−３００Ｄによる共有ストレージ３０６Ａ−３０６Ｄへのアクセスを実現可能な任意の相互接続であってよい。データストレージ相互接続３０４の例としては、ブロケード３２００ファイバチャネルスイッチなどのファイバチャネルスイッチが挙げられる。あるいは、データストレージネットワークは、ｉＳＣＳＩまたはその他のＩＰストレージネットワーク、インフィニバンド（商標）ネットワーク、または他の種類のホスト・ストレージ間ネットワークであってもよい。さらに、ネットワーク相互接続３０２およびデータストレージ相互接続３０４は、単一の相互接続で実現されてもよい。

サーバ３００Ａ−３００Ｄは、任意のコンピュータであってよく、市販のコンピュータ、サーバ、または、それらの任意の均等物であることが好ましい。サーバ３００Ａ−３００Ｄは、互いに独立したオペレーティングシステムをそれぞれ実行することができる。したがって、各サーバ３００Ａ−３００Ｄは、異なるオペレーティングシステムを実行できるが、実行しなくてもよい。例えば、サーバ３００ＡがＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓを実行し、サーバ３００ＢがＬｉｎｕｘを実行し、同時に、サーバ３００ＣがＵｎｉｘオペレーティングシステムを実行してもよい。サーバ３００Ａ−３００Ｄが独立したオペレーティングシステムを実行することの利点は、マルチノードシステム全体が動的になることができる点である。例えば、サーバ３００Ａ−３００Ｄの１つに障害が起きても、他のサーバ３００Ａ−３００Ｄは動作し続ける。

共有ストレージ３０６Ａ−３０６Ｄは、ハードディスク、コンパクトディスク、テープ、およびランダムアクセスメモリなど、任意のストレージデバイスでよい。ファイルシステムは、共有ストレージ上に構築された論理エンティティである。共有ストレージ３０６Ａ−３０６Ｄは、通例、物理デバイスと考えられ、ファイルシステムは、通例、ストレージの一部にオーバーレイされた論理構造と考えられるが、ファイルシステムは、本明細書においては簡単のため、共有ストレージと呼ぶこともある。例えば、共有ストレージに障害があった場合には、ファイルシステムの一部や、１以上のファイルシステム、ファイルシステムのオーバーレイされた物理ストレージデバイスなどに障害があり得る。したがって、本明細書において、共有ストレージは、物理ストレージデバイスや、ファイルシステムの一部、ファイルシステム、複数のファイルシステム、それらの任意の組み合わせなどを意味する。

図４は、本発明の一実施形態に従って、別のシステムを示すブロック図である。この例では、システムは、シングルポイント障害を有していないことが好ましい。したがって、サーバ３００Ａ’−３００Ｄ’は、複数のネットワーク相互接続３０２Ａ−３０２Ｄと接続されている。図示するように、サーバ３００Ａ’−３００Ｄ’は、さらに、複数のストレージ相互接続３０４Ａ−３０４Ｂと接続されている。ストレージ相互接続３０４Ａ−３０４Ｂは、複数のデータストレージ３０６Ａ’−３０６Ｄ’にそれぞれ接続されている。

このように、システム内に冗長性が存在することで、複数の要素または接続のいずれかに障害が起きた場合でも、システム全体は動作を継続できる。

図３，図４に示す例において、サーバ３００Ａ’−３００Ｄ’の数、ストレージ相互接続３０４Ａ−３０４Ｂの数、およびデータストレージ３０６Ａ’−３０６Ｄ’の数は、顧客が必要とする数で構成可能であり、システムによって物理的に制限されることはない。同様に、サーバ３００Ａ’−３００Ｄ’によって用いられるオペレーティングシステムについても、顧客が必要とする数の独立したオペレーティングシステムとして構成することができる。

図５は、本発明の一実施形態に従って、サーバ３００のソフトウェア要素を示すブロック図である。本発明の一実施形態では、図３の各サーバ３００Ａ−３００Ｄは、これらのソフトウェア要素を備えている。

本実施例では、以下の要素が図示されている。

分散ロックマネージャ（ＤＬＭ）５００は、クラッシュ回復中のロック状態の管理を含めて、ファイルシステムイメージ３０６ａ−３０６ｄに対するマトリクス規模（matrix-wide）のロックを管理する。マトリクスファイルシステム５０４は、ＤＬＭ５００が管理するロックを用いて、マトリクス規模の相互排他とマトリクス規模のファイルシステム３０６ａ−３０６ｄのメタデータおよびデータキャッシュの一貫性とを実現する。ＤＬＭ５００は、分散対称ロックマネージャである。マトリクス内のすべてのサーバ上にＤＬＭ５００のインスタンスが存在することが好ましい。すべてのインスタンスは、他のすべてのインスタンスと対等であり、インスタンス間には、マスタ／スレーブの関係はない。

ロックキャッシング層（ＬＣＬ）５０２は、マトリクスファイルシステム５０４とアプリケーションレベルのＤＬＭ５００とのインタフェースとなるオペレーティングシステムカーネル内の要素である。ＬＣＬ５０２の目的は、以下の通りである。

１．分散ロックを取得する必要があるカーネル常駐クライアントからＤＬＭ５００の詳細を隠す。

２．ＤＬＭ５００のロックをキャッシュに格納する（すなわち、クライアントがＤＬＭ５００のロックへの参照すべてを解除した後に、ＤＬＭ５００のロックを保持することができる）。時に、カーネルの要素がマトリクス規模のロックを取得するためにアプリケーションレベルの処理（ＤＬＭ５００）と通信する必要性をなくす。

３．処理およびサーバの範囲の両方においてロックを取得する機能を提供する（処理のロックは、対応するＤＬＭ（５００）のロックが保持されることを保証し、競合するモードでロックを取得しようとするローカル処理を除外するが、サーバのロックは、ＤＬＭ（５００）のロックが保持されることを保証するだけで、他のローカル処理を除外することはない）。

４．ロックに関連する特定のイベント（特にＤＬＭ５００レベルのロックの取得および放棄）が発生した際に、クライアントが様々な種類のロックに対するコールアウトを定義することを可能にする。この機能は、キャッシュコヒーレンシ（一貫性）のために必要であり、コールアウトに従って、対応するＤＬＭ５００の書き込みロックが格下げまたは解除された際に、変更されたキャッシュデータを永続ストレージにフラッシュしたり、ＤＬＭ５００の読み取りロックが解除された際に、キャッシュデータをパージしたりする。

ＬＣＬ５０２は、ユーザレベルのＤＬＭ５００からロック要求を行う唯一のカーネル要素である。ＬＣＬ５０２は、カーネルクライアント間でＤＬＭ５００のロックを分配し（partition）、この結果、１つのＤＬＭ５００のロックは、各ノードすなわちＬＣＬ５０２自体に、最大で１つのカーネルクライアントを有する。各ＤＬＭ５００ロックは、ＬＣＬ５０２の要求の結果であって、クライアントによるＬＣＬ５０２ロックの要求によって誘起されたものであり、各ＬＣＬ５０２ロックは、ＤＬＭ５００ロックによって支援される。

マトリクスファイルシステム５０４は、マトリクスサーバの共有ファイルシステム要素である。マトリクスファイルシステム５０４は、複数のサーバが、読み取り／書き込みモードにおいて、物理的に共有されたストレージデバイス３０６ａ−３０６ｄに存在するファイルシステムに同時にマウントすることを可能にする。マトリクスファイルシステム５０４は、分散対称マトリクスファイルシステムである。すなわち、ファイルシステム活動を実行するために、ファイルシステム活動が通過しなければならないサーバは１つも存在しない。マトリクスファイルシステム５０４は、標準のローカルファイルシステムセマンティクスおよびインタフェースを、ファイルシステムのクライアントに提供する。

ＳＡＮ（ストレージエリアネットワーク）メンバーシップサービス５０６は、グループメンバーシップサービスのインフラストラクチャを、マトリクスファイルシステム５０４に提供する。グループメンバーシップサービスのインフラストラクチャは、共有ファイルシステム３０６ａ−３０６ｄのファイルシステムメンバーシップの管理、正常性の監視、マウントおよびアンマウントの調整、クラッシュ回復の調整を含む。

マトリクスメンバーシップサービス５０８は、仮想ホスト管理、サービス監視、通知サービス、データ複製などを含む、ローカルなマトリクス型のマトリクスメンバーシップサポートを提供する。マトリクスファイルシステム５０４は、ＭＭＳ５０８と直接的にインタフェース接続することはないが、ＳＡＮメンバーシップサービス５０６とインタフェース接続し、ＳＡＮメンバーシップサービス５０６がＭＭＳ５０８とインタフェース接続することで、ファイルシステム５０４にマトリクスグループサービスのインフラストラクチャが提供される。

共有ディスク監視プローブ５１０は、マトリクス内の様々な共有ストレージデバイスのメンバーシップを維持および監視する。また、マトリクス内の様々な共有ストレージデバイスに関するリースを、不正なサーバ（rogue server）の「スプリットブレイン」状態に対する保護として、取得および維持する。さらに、ＳＭＳ５０６と通信して、デバイスメンバーシップの遷移の発生時に回復活動を調整する。

ファイルシステムモニタ５１２は、マトリクスサーバのユーザインタフェースによって準備されるマトリクス構成に従って、マトリクスファイルシステム５０４のマウントおよびアンマウントを開始するために、ＳＡＮメンバーシップサービス５０８によって用いられる。

サービスモニタ５１４は、マトリクス内の各サーバにおける様々なサービスの状態（正常性および利用可能性）を追跡し、この結果、マトリクスサーバは、監視されているサービスの状態の遷移時に自動的な改善措置をとることができる。監視されるサービスは、ＨＴＴＰ、ＦＴＰ、Ｔｅｌｎｅｔ、ＳＭＴＰなどを含む。改善措置は、同一サーバでのサービスの再始動や、他のサーバでのサービスのフェイルオーバおよび再始動を含む。

デバイスモニタ５１６は、マトリクス内の種々のストレージ関連デバイスの状態（正常性および利用可能性）を追跡し、この結果、マトリクスサーバは、監視されているデバイスの状態の遷移時に自動的な改善措置をとることができる。監視されるデバイスは、データストレージデバイス３０６ａ−３０６ｄ（ストレージデバイスドライブ、半導体ストレージデバイス、ＲＡＭストレージデバイス、ＪＯＢＤ、ＲＡＩＤ配列など）と、ストレージネットワークデバイス３０４’（ファイバチャネルスイッチ、インフィニバンドスイッチ、ｉＳＣＳＩスイッチなど）と、を含んでよい。改善措置は、マトリクスファイルシステム５０４の回復の開始、ストレージネットワークパスのフェイルオーバ、デバイスのリセットを含む。

アプリケーションモニタ５１８は、マトリクス内の各サーバにおける様々なアプリケーションの状態（正常性および利用可能性）を追跡し、この結果、マトリクスサーバは、監視されているアプリケーションの状態の遷移時に自動的な改善措置をとることができる。監視されるアプリケーションは、データベース、メールルータ、ＣＲＭアプリケーションなどを含んでよい。改善措置は、同一サーバでのアプリケーションの再始動や、他のサーバでのアプリケーションのフェイルオーバおよび再始動を含む。

通知エージェント５２０は、マトリクス内で特定のオブジェクトと関連するイベントとを追跡し、追跡されたイベントの発生時に、提供されたコマンドのスクリプトを実行する。

複製エージェント５２２は、すべてのファイルシステムのサブツリーの内容を監視し、複製元ツリーから複製先ツリーへの複製が済んでいないデータを定期的に複製する。複製は、共有ストレージに配置されていないサブツリーに用いられることが好ましい。

マトリクス通信サービス５２４は、ＤＬＭ５００と、マトリクスメンバーシップサービス５０８と、ＳＡＮメンバーシップサービス５０６とに、ネットワーク通信のインフラストラクチャを提供する。マトリクスファイルシステム５０４は、ＭＣＳ５２４を直接的に用いるのではなく、これらの他の要素を介して間接的に用いる。

ストレージ制御層（ＳＣＬ）５２６は、マウント時にマトリクスファイルシステム５０４を識別するために用いられるマトリクス規模のデバイス識別を提供する。ＳＣＬ５２６は、さらに、ストレージ構造の構成と、マトリクスファイルシステム５０４を含む共有ストレージデバイス３０６ａ−３０６ｄから不正なサーバを隔離する低レベル入出力デバイス隔離と、を管理する。ＳＣＬ５２６は、さらに、マトリクスの他のサーバとの通信が途絶えた場合に、通常のデバイス操作中に自発的に仲裁して自らを隔離する機能を、マトリクス内のサーバに提供する。

ストレージ制御層５２６は、共有ストレージデバイス３０６ａ−３０６ｄの管理を担うマトリクスサーバのモジュールである。ここでの管理は、２つの主要な機能から成る。１つ目は、１組の共有ストレージデバイス３０６ａ−３０６ｄへのホストアクセスを使用可能／使用不可能とすることにより、ハードウェアＳＡＮレベルで入出力の隔離を実行する機能である。２つ目は、すべてのマトリクスストレージデバイス３０６ａ−３０６ｄに対して、グローバルな（マトリクス規模の）固有のデバイス名（すなわち「ラベル」）を生成し、マトリクス内のすべてのホストがそれらのグローバルなデバイス名にアクセスできることを保証する機能である。ＳＣＬモジュールは、さらに、ＵＩにデバイス情報を提供するために必要なユーティリティとライブラリルーチンとを備える。

擬似ストレージドライバ（ＰＳＤ）５２８は、下層のターゲットデバイスへのすべての参照がＰＳＤ階層化ドライバを通過しなければならないように、ターゲットストレージデバイス３０６ａ−３０６ｄを「隠す」階層化ドライバである。したがって、ＰＳＤは、デバイスを「隔離する」機能を提供し、再び隔離解除されるまで、ホストサーバから、下層のターゲットデバイスへのすべての入出力を遮断する。ＰＳＤは、さらに、アプリケーションレベルのインタフェースを提供して、マトリクス全体に渡ってストレージパーティションをロックする。また、ＰＳＤは、マトリクスサーバ内の共有ストレージにアクセスするすべてのサーバが、ある特定の共有デバイスにアクセスするために同じパスを用いることができるように、共通のマトリクス規模の「ハンドル」すなわちパスを提供する機能を有する。

図６は、本発明の一実施形態に従って、マルチノード環境のための方法を示すフローチャートである。この例では、第１のオペレーティングシステムが準備され（６００）、さらに、第２のオペレーティングシステムが準備される（６０２）。第２のオペレーティングシステムは、第１のオペレーティングシステムから独立していることが好ましい。これらのオペレーティングシステムは、Ｌｉｎｕｘやその他のオペレーティングシステム、または、バージョンの異なるＷｉｎｄｏｗｓ（商標）、Ｕｎｉｘ（商標）、Ｌｉｎｕｘなど、同じオペレーティングシステムであってよいが、それぞれ、共用のＯＳではなく、別個のＯＳが実行される。さらに、ストレージが準備される（６０４）。次いで、第１のオペレーティングシステムとストレージとを結合すると共に、第２のオペレーティングシステムとストレージとを結合する相互接続が準備される（６０６）。次に、ストレージは、第１のオペレーティングシステムによって直接アクセスされ（６０８）、さらに、第２のオペレーティングシステムによって直接アクセスされる（６１０）。

図７Ａ〜図７Ｃは、本発明の一実施形態に従って、マルチノード環境のための方法を示す他のフローチャートである。ここでは、以下の用語が用いられる。

ここでは、通信グループを形成する協調した１組の処理（プログラム）を、グループメンバーシップと呼ぶ。例えば、グループメンバーシップは、サーバ間で形成することができる。ここでは、ストレージエリアのメンバーシップを、ＳＡＮメンバーシップと呼ぶ。ＳＡＮメンバーシップは、ディスクやスイッチなど、ストレージエリアネットワークのリソースへの読み取り／書き込みを許可されて通信を行っているサーバのグループのことである。ここでは、ＳＡＮに配置された単一のファイルシステムを積極的に用いる１組のサーバを、共有ストレージグループメンバーシップと呼ぶ。一例としては、ファイルシステムがユーザプログラムによってアクセス可能となるよう、ファイルシステムを「マウント」した１組のサーバが挙げられる。ファイルシステムおよびネットワークリソースを論理的な全体として積極的に共有する単一のクラスタを形成する１組のサーバを、クラスタメンバーシップと呼ぶ。

この例では、サーバのクラスタのメンバーシップが決定される（７００）。前述したように、一例としてサーバを用いているが、任意のノード、コンピュータまたはプロセッサを用いてよい。ここで用いられているように、クラスタは、メンバーシップと関連付けられた任意の２以上のサーバ、コンピュータ、プロセッサ、または、それらの任意の組み合わせであってよい。

次いで、クラスタのメンバーシップが変更されたか否かが判断される（７０２）。時間０においては、メンバーシップの履歴がないため、メンバーシップへの変更はない。その後、ある時点で、メンバーシップは、例えば、サーバが接続を切られたり、新しいサーバが追加されたりした場合に変更される。利用されているサーバの数の変更に加えて、メンバーシップが変更されたか否かを判断する工程は、サーバに障害が生じた場合、サーバが追加された場合、クラスタから削除された場合にも対応できる。

クラスタメンバーシップが変更されていない場合（７０２）、各サーバは、他のサーバにメッセージを送信し、それらのメッセージを監視して、他のサーバがアクティブであるか否かを確認する（７０４）。次いで、すべてのサーバが応答するか否かが判断される（７０６）。クラスタ内のすべての他のサーバがメッセージに応答すると、ストレージエリアネットワーク（ＳＡＮ）メンバーシップサービス（ＳＭＳ）は、クラスタ内のアクティブなメンバを通知される（７０８）。しかしながら、クラスタ内のすべてのサーバが応答しない場合（７０６）には、メッセージ活動は遮断される（７１６）。メッセージ活動の遮断によって、メンバーシップ変更の合間における失効メッセージが回避される。メッセージ活動が遮断されると、クラスタのメンバーシップが、再び決定される（７００）。

クラスタメンバーシップが変更された場合（７０２）、もはや新しいロックは許可されない（７１０）。次いで、このクラスタ内にアドミニストレータ（ＡＤＭ）が存在するか否かが判断される（７１２）。このクラスタ内にアドミニストレータが存在しない場合には、クラスタのメンバの１つが、アドミニストレータとして選択される（７１４）。図５の例では、ＳＡＮメンバーシップサービス（ＳＭＳ）５０６が、アドミニストレータとして利用可能である。

図７Ｂにおいて、アドミニストレータは、このクラスタ内の他のサーバがストレージエリアメンバーシップの一部であることを確認する（７２０）。工程７２０は、すべてのサーバがクラスタの一部である場合と、クラスタ外のサーバが存在する場合の両方に対応する。

意図的であっても非意図的であっても、ストレージエリアネットワーク内で動作する別個のクラスタが存在してもよい。いずれの場合でも、サーバがソフトウェアの設定を間違うと、サーバは、有効なクラスタの知識なしに、共有ストレージに接続してアクセスを試みることがある。ノードがクラスタの外部に存在すると、アドミニストレータは、それらのサーバを除外（隔離）して、共有ストレージ上のデータの破壊を防止する。サーバは、ネットワーククラスタへのメンバーシップの取得に成功すると、共有ストレージへのアクセスを許可され、ＳＡＮメンバーシップの一部となる。

次いで、クラスタの非メンバはすべて除外され、クラスタのメンバはすべて共有ストレージグループに対する許可を与えられる（７２２）。したがって、クラスタメンバーシップ外のサーバは、図５のディスク３０６Ａ−３０６Ｄへのアクセスから除外される。

次いで、共有ストレージが１に設定される（７２４）。この共有ストレージグループのメンバに対して回復が必要か否かが、ＡＤＭによって判断される（７２６）。

この共有ストレージグループのメンバに対して回復が必要ない場合、最後の共有ストレージであるか否かが判別される（７３２）。最後の共有ストレージでない場合、その共有ストレージは、共有ストレージ＋１に設定され（７３０）、次の共有ストレージは、その共有ストレージのメンバに対して回復が必要であるか否かをアドミニストレータに判断させることによって評価される（７２６）。しかしながら、この共有ストレージが、最後の共有ストレージである場合には、新しいロックの許可が、アクセス可能な共有ストレージに対して再開される（７３４）。

アドミニストレータが、この共有ストレージのメンバに対して回復が必要であると判断した場合（７２６）、この共有ストレージのどのメンバが回復を必要とするかが判断される（７２８）。例えば、各サーバのＳＡＮメンバーシップサービス（ＳＭＳ）は、そのサーバが回復を必要とするか否かを分散ロックマネージャ（ＤＬＭ）に通知することができる。

回復を必要とするサーバが分析される。この例では、回復を必要とするメンバのＤＬＭは、１に設定される（７５０）。次いで、マトリクスファイルシステム（ＭＦＳ）およびロックキャッシング層（ＬＣＬ）によって共有ストレージにおけるジャーナル回復を始動させることのできるロックが回復される（７５２）。

次いで、回復が成功したか否かが判断される（７５４）。回復が成功した場合、このサーバが、回復を必要とする最後のサーバであるか否かが判断される（７６２）。このサーバが、回復を必要とする最後のサーバではなかった場合、ＤＬＭをＤＬＭ＋１に設定することにより（７６４）、回復を必要とする次のサーバが分析される。そして、次のサーバに対してロックが回復される（７５２）。しかしながら、このサーバが、回復を必要とする最後のサーバであった場合には（７６２）、この共有ストレージが、分析を必要とする最後の共有ストレージであるか否かが判断される（図７Ｂの７３２）。

ロックの回復が成功しなかった場合には（図７Ｃの７５４）、障害のある共有ストレージは、エラーとしてマークされ（７５６）、人間のシステムオペレータに警報が送信される（７５８）。

そして、障害のある共有ストレージは隔離され、その共有ストレージへのアクセスが遮断される（７６０）。次いで、この共有ストレージが、分析を必要とする最後の共有ストレージであるか否かが判断される（図７Ｂの７３２）。

図８は、本発明の一実施形態に従って、共有ストレージからファイルを読み取るための方法を示すフローチャートである。クラスタ内のサーバのオペレーティングシステムが、ファイルの一部を読み取ることを要求する（８００）。

共有ロック要求が提供される（８０２）。例えば、図５のマトリクスファイルシステム（ＭＦＳ）５０４が、図５のロックキャッシング層（ＬＣＬ）５０２に共有ロックを要求する。次いで、その要求が許可されるか否かが判断される（８０４）。共有ロック要求が許可されない場合には、共有ストレージの障害があるか否かが判断される（８０６）。

共有ストレージの障害がある場合、その共有ストレージは、必要に応じて隔離される（８０８）。しかしながら、共有ストレージの障害がない場合には、ＭＦＳが、ＬＣＬに共有ロックを要求する（８０２）。次いで、その共有ロック要求が許可されるか否かが判断される（８０４）。

共有ロック要求が許可されると（８０４）、サーバが、共有ストレージからオペレーティングシステムのバッファキャッシュに、要求されたファイルの断片を読み取ることができるか否かが判断される（８１０）。サーバが、ファイルをＯＳのバッファキャッシュに読み取ることができる場合、処理は終了する。しかしながら、サーバが、ＯＳのバッファキャッシュへの読み取りを実行できない場合には、共有ロックは解除され、オペレーティングシステムまたはアプリケーションにエラーが返される（８１２）。そのようなエラーは、例えば、ディスクの障害や接続の障害が生じている場合に起こり得る。

図９Ａ，図９Ｂは、本発明の一実施形態に従って、共有ストレージ内のファイルへ書き込むための方法を示すフローチャートである。

この例では、サーバのオペレーティングシステムが、ファイルの一部への書き込みを要求する（９００）。図５のマトリクスファイルシステム（ＭＦＳ）５０４が、ロックキャッシング層（ＬＣＬ）に排他ロックを要求する（９０２）。次いで、その排他ロックの要求が許可されるか否かが判断される（９０４）。排他ロックの要求が許可されない場合、共有ストレージに障害があるか否かが判断される（９２０）。共有ストレージの障害がある場合、その共有ストレージは、必要に応じて隔離される（９２２）。しかしながら、共有ストレージの障害がない場合には（９２０）、再び、排他ロックの要求がなされる（９０２）。

排他ロックの要求が許可された場合には（９０４）、ローカルキャッシュ内に、そのファイルの要求された部分の安定したコピーが存在するか否かが判断される（９０６）。キャッシュ内に安定したコピーが存在する場合、そのファイル断片がローカルキャッシュ内で修正される（図９Ｂの９３４）。しかしながら、ローカルキャッシュ内に安定したコピーが存在しない場合には（９０６）、要求されたファイルの断片を、共有ストレージからオペレーティングシステムのローカルキャッシュに読み込み可能か否か判断される（９３０）。サーバが、ローカルキャッシュへのファイルの読み取りを実行できない場合、オペレーティングシステムまたはアプリケーションにエラーが返される（９３２）。しかしながら、ローカルキャッシュへのファイルの読み込みが成功した場合には、そのファイル断片は、ローカルキャッシュ内で修正される（９３４）。

次いで、この特定のファイルに対するロック要求が受信されたか否かが判断される（９３６）。このファイルに対するロック要求が受信され、そのファイルが修正済みである場合、修正済みのデータが、共有ストレージに書き込まれる（９４０）。次いで、サーバは、このファイルに関する排他ロックを解除する（９３８）。

このファイルに対するロック要求が受信されていない場合には（９３６）、オペレーティングシステムが、ローカルキャッシュのクリーニングを行っているか否かが判断される（９４２）。キャッシュがクリーニングされている場合、修正済みのデータは共有ストレージに書き込まれ（９４０）、他のサーバからの未処理の要求が存在しない限りは、すべてのロックが維持される。キャッシュがクリーニングされていない場合には、修正済みのファイルは、ローカルキャッシュ内に保持される（９４４）。他のサーバによって必要とされるまで、修正済みのファイルをローカルキャッシュに保持することにより、そのファイルを自身のローカルキャッシュに保持するサーバにとっては、そのファイルへのアクセスが速くなる。

図１０Ａ，図１０Ｂは、本発明の一実施形態に従って、ディスクなどのストレージを共有するサーバのクラスタにノードを追加するための方法を示すフローチャートである。

この例では、クラスタ内にアドミニストレータ（ＡＤＭ）が存在するか否かが判別される（１４００）。クラスタは、共有ストレージなどの共有リソースを共有するよう協調する１組のサーバを含む。クラスタ内のサーバの内の１つは、クラスタを管理するためのアドミニストレータとして機能する。このクラスタ内にアドミニストレータが存在しない場合には、このサーバがアドミニストレータになることができるか否かが判断される（１４０８）。このサーバが、アドミニストレータになることができる場合には、データベースからデバイス情報を読み込み、新しいアドミニストレータとなる（１４１０）。

クラスタ内にアドミニストレータが存在する場合（１４００）、または、このサーバが新しいアドミニストレータになることができない場合（１４０８）、そのサーバは、既存のアドミニストレータがクラスタにインポートされるよう要求する（１４０２）。このサーバがアドミニストレータになれない（１４０８）のは、例えば、このサーバが、アドミニストレータの存在しないことを確定して、アドミニストレータになろうとする間に、他のサーバがアドミニストレータになった場合である。

次いで、このサーバがクラスタにインポートされることが許可されるか否かが判断される（１４０４）。許可されない場合には、このサーバをクラスタに追加する処理は失敗となる（１４１２）。サーバの追加が失敗するのは、例えば、このサーバが正常ではない、または、このサーバのストレージエリアネットワーク世代番号がアドミニストレータの用いる世代番号と整合しないといった理由からである。

このサーバは、インポート可能である場合には（１４０４）、アドミニストレータからデバイス名を受信する（１４０６）。デバイス名としては、例えば、共有ストレージの名前などが挙げられる。

アドミニストレータは、物理ストレージエリアネットワークへのアクセスを、このサーバに対して許可する（図１０Ｂの１４１０）。次いで、アドミニストレータは、ストレージエリアネットワーク（ＳＡＮ）へのアクセスを、このサーバに許可するよう、物理ハードウェアに命令する（１４１２）。この時点で、このサーバは、ＳＡＮへのアクセス権を得る（１４１４）。

図１１Ａ〜図１１Ｃは、本発明の一実施形態に従って、サーバの障害に対処するための方法を示すフローチャートである。この例では、サーバまたはサーバとの通信に障害が生じたと判断される（１７００）。次いで、アドミニストレータがまだ存在しているか否かが判断される（１７０２）。例えば、障害を起こしたサーバが、アドミニストレータであった可能性もある。アドミニストレータがまだ存在している場合、障害サーバは物理的に隔離される（１７０８）。障害サーバを物理的に隔離するには、例えば、障害サーバと関連するポートを使用不可にする。

次いで、ストレージエリアネットワーク世代番号が更新されてデータベースに格納される（１７１０）。その後、通常の動作が継続する（１７１２）。

もはやアドミニストレータが存在しない場合には（１７０２）、新しいアドミニストレータになるサーバが選定される（１７０４）。新しいアドミニストレータになるサーバを選択するには、いくつかの方法がある。一例としては、サーバの１つをランダムに選択する方法が挙げられる。次いで、選択されたサーバは、新しいアドミニストレータになるよう通知される（１７０６）。新しいアドミニストレータになるようサーバが選択されて通知されるためには、例えば、グループコーディネータが用いられる。

一実施形態では、グループコーディネータは、アルゴリズムを用いて、処理通信グループの形成中に選択される。該アルゴリズムは、グループのメンバーシップへの同意が必要とされることを除いて、サーバまたはノードのいずれとも通信せずにグループのコーディネータを一意的に識別することができる。例えば、メンバの内で最も低い番号のインターネットプロトコル（ＩＰ）アドレスを有するサーバが選択されてよい。次いで、コーディネータは、可能なアドミニストレータの選択など、サーバのグループに対してグローバルな決定を行うことができる。アドミニストレータとして選択されるサーバは、実際にアドミニストレータになることができる可能性の高いことが好ましい。グループコーディネータは、ＳＡＮハードウェアを接続し得ると共にＳＡＮアドミニストレータになる試行を最近失敗していないノードを、アドミニストレータに設定するよう試みる。

次いで、選択されたサーバは、ストレージエリアネットワークのロックを取得するよう試みる（１７２０）。サーバがＳＡＮのロックを取得できない場合、アドミニストレータになる試行は失敗となる（１７２４）。ＳＡＮロックの取得に成功した場合には（１７２０）、サーバは、メンバーシップデータベースからＳＡＮ世代番号を読み取るよう試みる（１７２２）。データベースは、共有ストレージ上のメンバーシップパーティションの１つに保持されてもよいし、ＳＡＮロックと共存していてもよい。

サーバは、データベースからのＳＡＮ世代番号の読み取りに失敗した場合には（１７２２）、ＳＡＮロックを解除し（１７２６）、アドミニストレータになる試行は失敗となる（１７２４）。そのサーバがアドミニストレータになることを失敗すると（１７２４）、グループコーディネータは、あるサーバに、新しいアドミニストレータになるよう通知する（図１１Ａの１７０６）。

サーバは、データベースからＳＡＮ世代番号を読み取ることができた場合には、ＳＡＮ世代番号をインクリメントして、再びデータベースに格納する（１７２８）。そのサーバは、さらに、自身がアドミニストレータであることをグループコーディネータに通知する（１７３０）。グループコーディネータは、そのアドミニストレータ更新を受信する（１７３２）。次いで、このサーバが新しいアドミニストレータとなることが許可されるか否かが判断される（１７５０）。許可されない場合には、そのアドミニストレータ状況を取り消す旨のメッセージが、アドミニストレータになるよう試みている現行サーバに送信される（１７５２）。その後、グループコーディネータは、新しいアドミニストレータになるよう、他のサーバに通知する（図１１Ａの１７０６）。

このサーバが新しいアドミニストレータとして許可される場合には、そのアドミニストレータは、コミットするよう通知されて（１７５４）、コミットされる（１７５６）。次いで、コーディネータは、新しいアドミニストレータに関して、クラスタ内の他のサーバに通知する（１７５８）。

図１２は、本発明の一実施形態に従って、共有ストレージの追加または削除を行うための方法を示すフローチャートである。この例では、ディスクなどの共有ストレージを追加または削除する旨の要求が、サーバからアドミニストレータに送信される（１６００）。次いで、そのディスクは、命名データベースに追加または削除される（１６０２）。命名データベースは、すべてのサーバがアクセス可能な共有ストレージ上に保持されることが可能であり、すべてのサーバは、クラスタに加わる前に、命名データベースを知ることが可能である。命名データベースの場所の知識を持たないサーバは、ＳＡＮアドミニストレータになる資格を持たないことが好ましい。

次いで、ＳＡＮ世代番号がインクリメントされる（１６０４）。次いで、クラスタ内の各サーバは、ＳＡＮ世代番号と、新しいディスクの追加または削除と、を通知される（１６０６）。クラスタ内のすべてのサーバが応答すると、新しいＳＡＮ世代番号は、データベースに書き込まれる（１６０８）。次いで、要求元のサーバは、ディスクの追加／削除が完了したことを通知される（１６１０）。

以上、理解しやすいように、ある程度詳細に本発明の説明を行ったが、添付の請求項の範囲内で、変更や変形を行ってよいことは明らかである。本発明の処理および装置を実施する多くの他の方法が存在することに注意されたい。 したがって、上記実施形態は、説明のためのものであって限定の意図はないと見なされ、本発明は、本明細書に記載された詳細に限定されず、添付の請求項の範囲および等価物の範囲内で変形可能である。

典型的なサーバシステムの一例を示すブロック図。 典型的なサーバシステムの別の例を示すブロック図。 本発明の一実施形態に従って、マルチノード環境のためのシステムを示すブロック図。 本発明の一実施形態に従って、別のシステムを示すブロック図。 本発明の一実施形態に従って、サーバ３００のソフトウェア要素を示すブロック図。 本発明の一実施形態に従って、マルチノード環境のための方法を示すフローチャート。 本発明の一実施形態に従って、マルチノード環境のための方法を示す他のフローチャート。 本発明の一実施形態に従って、マルチノード環境のための方法を示す他のフローチャート。 本発明の一実施形態に従って、マルチノード環境のための方法を示す他のフローチャート。 本発明の一実施形態に従って、ファイルを読み取るための方法を示すフローチャート。 本発明の一実施形態に従って、ファイルへ書き込むための方法を示すフローチャート。 本発明の一実施形態に従って、ファイルへ書き込むための方法を示すフローチャート。 本発明の一実施形態に従って、ディスクなどのストレージを共有するサーバのクラスタにノードを追加するための方法を示すフローチャート。 本発明の一実施形態に従って、ディスクなどのストレージを共有するサーバのクラスタにノードを追加するための方法を示すフローチャート。 本発明の一実施形態に従って、サーバの障害に対処するための方法を示すフローチャート。 本発明の一実施形態に従って、サーバの障害に対処するための方法を示すフローチャート。 本発明の一実施形態に従って、サーバの障害に対処するための方法を示すフローチャート。 本発明の一実施形態に従って、共有ストレージの追加または除去を行うための方法を示すフローチャート。

符号の説明

１００Ａ−１００Ｄ…コンピュータ
１０２…ネットワーク
１０４Ａ−１０４Ｄ…ストレージ
２００Ａ−２００Ｄ…サーバ
３００Ａ−３００Ｄ…サーバ
３００Ａ’−３００Ｄ’…サーバ
３０２…ネットワーク相互接続
３０２Ａ−３０２Ｄ…ネットワーク相互接続
３０４…データストレージ相互接続
３０４’…ストレージネットワークデバイス
３０４Ａ−３０４Ｂ…ストレージ相互接続
３０６Ａ−３０６Ｄ…共有ストレージ
３０６ａ−３０６ｄ…ストレージデバイス
３０６Ａ’−３０６Ｄ’…データストレージ
５００…分散ロックマネージャ
５０２…ロックキャッシング層
５０４…マトリクスファイルシステム
５０６…ＳＡＮメンバーシップサービス
５０８…マトリクスメンバーシップサービス
５１０…共有ディスク監視プローブ
５１２…ファイルシステムモニタ
５１４…サービスモニタ
５１６…デバイスモニタ
５１８…アプリケーションモニタ
５２０…通知エージェント
５２２…複製エージェント
５２４…マトリクス通信サービス
５２６…ストレージ制御層
５２８…擬似ストレージドライバ

Claims (19)

1. マルチノード環境のためのシステムであって、
   第１のオペレーティングシステムと関連付けられた第１のノードと、
   第２のオペレーティングシステムと関連付けられた第２のノードであって、前記第２のオペレーティングシステムは、前記第１のオペレーティングシステムから独立している、前記第２のノードと、
   ストレージと、
   前記第１のノードと前記ストレージとを結合すると共に、前記第２のノードと前記ストレージとを結合する相互接続と、
   を備え、
   前記第１のノードは、前記ストレージに直接アクセスし、前記第２のノードは、前記ストレージに直接アクセスする、システム。
2. 請求項１に記載のシステムであって、
   前記第１のオペレーティングシステムは、前記第２のオペレーティングシステムと異なるオペレーティングシステムである、システム。
3. 請求項１に記載のシステムであって、
   前記ストレージは、コヒーレントな共有ファイルストレージである、システム。
4. 請求項１に記載のシステムであって、
   前記相互接続は、共有ディスク相互接続である、システム。
5. 請求項１に記載のシステムであって、さらに、
   前記ストレージに直接アクセスするよう動的に追加される第３のノードを備える、システム。
6. 請求項１に記載のシステムであって、
   前記第２のノードは、動的に分離され、もはや前記ストレージに直接アクセスしない、システム。
7. 請求項１に記載のシステムであって、さらに、
   前記第１および第２のノードによって直接アクセス可能であるように動的に追加される第２のストレージを備える、システム。
8. 請求項１に記載のシステムであって、さらに、
   第２のストレージを備え、
   前記第２のストレージは、前記第１および第２のノードによって直接アクセス可能であり、前記第２のストレージは、前記第１および第２のノードによって直接アクセス不可能となるように、前記第１および第２のノードから動的に分離される、システム。
9. マルチノード環境のためのシステムであって、
   メンバーシップグループと関連付けられた第１のノードであって、第１のオペレーティングシステムと関連付けられた前記第１のノードと、
   前記メンバーシップグループと関連付けられた第２のノードであって、前記第２のノードは第２のオペレーティングシステムと関連付けられ、前記第２のオペレーティングシステムは前記第１のオペレーティングシステムから独立している、前記第２のノードと、
   前記第１および第２のノードと結合されたストレージであって、前記第１のノードおよび前記第２のノードによって直接アクセス可能である、前記ストレージと、
   を備え、
   前記第１のノードは、前記メンバーシップグループが変更されたか否かを判断するよう構成されている、システム。
10. 請求項９に記載のシステムであって、
    前記第１のノードは、前記メンバーシップグループの前記変更に動的に対応する、システム。
11. マルチノード環境を管理するための方法であって、
    第１のノードをメンバーシップグループと関連付ける工程であって、前記第１のノードは第１のオペレーティングシステムと関連付けられており、前記第１のノードはストレージに直接アクセスする、前記工程と、
    第２のノードを前記メンバーシップグループ関連付ける工程であって、前記第２のノードは第２のオペレーティングシステムと関連付けられており、前記第２のオペレーティングシステムは前記第１のオペレーティングシステムから独立しており、前記第２のノードは前記ストレージに直接アクセスする、前記工程と、
    前記メンバーシップグループが変更されたか否かを判断する工程と、
    前記メンバーシップグループの前記変更に動的に対応する工程と、
    を備える、方法。
12. 請求項１１に記載の方法であって、
    前記第１のオペレーティングシステムは、前記第２のオペレーティングシステムと異なるオペレーティングシステムである、方法。
13. 請求項１１に記載の方法であって、
    前記メンバーシップグループは、前記メンバーシップグループに第３のノードが追加されることによって変更される、方法。
14. 請求項１１に記載の方法であって、
    第３のノードは、前記メンバーシップグループに関連付けられており、
    前記メンバーシップグループは、前記メンバーシップグループから前記第３のノードが削除されることによって変更される、方法。
15. 請求項１１に記載の方法であって、さらに、
    前記メンバーシップグループが変更された場合に、回復を実行する必要があるか否かを判断する工程を備える、方法。
16. 請求項１１に記載の方法であって、さらに、
    前記メンバーシップグループが変更された場合に回復が必要であれば、ロックを回復する工程を備える、方法。
17. 請求項１１に記載の方法であって、さらに、
    前記メンバーシップグループが変更された場合に、新しいロックの許可を停止する工程を備える、方法。
18. マルチノード環境と関連付けられるよう構成された第１のノードのためのシステムであって、
    第１のオペレーティングシステムと関連付けられるよう構成されたプロセッサであって、前記第１のオペレーティングシステムは、第２のノードの第２のオペレーティングシステムから独立しており、前記プロセッサは、さらに、メンバーシップグループが変更されたか否かを判断可能なよう構成されており、前記メンバーシップグループは、前記第１のノードおよび前記第２のノードと関連付けられており、前記プロセッサは、さらに、前記メンバーシップグループの前記変更に動的に対応可能なよう構成されている、前記プロセッサと、
    前記プロセッサに結合されたストレージであって、前記プロセッサによって直接アクセスされるよう構成されると共に、前記第２のノードによって直接アクセスされるよう構成されている前記ストレージと、
    を備える、システム。
19. マルチノード環境と関連付けられるよう構成された第１のノードのためのコンピュータプログラム製品であって、コンピュータ読み取り可能な媒体において実現される前記コンピュータプログラム製品は、
    メンバーシップグループが変更されたか否かを判断するためのコンピュータ命令であって、前記メンバーシップグループは前記第１のノードおよび第２のノードと関連付けられており、前記第１のノードは第１のオペレーティングシステムと関連付けられ、前記第２のノードは第２のオペレーティングシステムと関連付けられており、前記第１のオペレーティングシステムは前記第２のオペレーティングシステムから独立している、前記コンピュータ命令と、
    前記メンバーシップグループの前記変更に動的に対応するためのコンピュータ命令と、
    ストレージに直接アクセスするためのコンピュータ命令であって、前記ストレージはさらに前記第２のノードによって直接アクセス可能である、前記コンピュータ命令と、
    を備える、コンピュータプログラム製品。

Images