JP5863942B2 - ウィットネスサービスの提供 - Google Patents

Description

本発明は、ウィットネスサービスの提供に関する。

[0001]サーバークラスタは、クライアントにフェイルオーバーおよび情報の高い可用性を提供するために一般に使用される。クラスタは、通常は、クラスタフェイルオーバーおよび負荷バランシングを管理するための機能を実行するクラスタサービスを有する。クラスタサービスは、通常は、速い故障検出を提供して最大のサービス可用性を提供する。しかし、クライアントの観点からは、多くの故障検出は、ネットワークタイムアウトを介して実行される。クライアントが、伝送制御プロトコル（ＴＣＰ）を使用し、ファイルアクセス要求またはデータベースアクセス要求などのクラスタへの要求を開始する場合、故障は、タイムアウトが達せられるまで検出されない。クライアントは、サーバーからの確認を所定の期間待つ、または、クライアントが動作を発行し、確認応答を受信した場合には、サーバーからの応答を所定の期間待つ。したがって、サーバー故障を検出するために必要とされる時間は、比較的速いものから３０秒以上まで様々であり得る。クライアントがより迅速に故障を検出するために、それは、アクティブに（すなわち、頻繁に要求を送ること）サーバーが故障したことを判定する必要がある。速い検出を確保するための１つの方法は、クライアントについては、キープアライブパケット（keep-alive-packets）を絶えず送信して、サーバーが故障した場合にネットワーク切断を遊休状態のクライアントが受信しないケースを防ぐのを助けることである。しかし、キープアライブパケットは、ネットワーク帯域を消費する。

[0002]これらのおよび他の検討事項に関して、実施形態は作成された。また、比較的具体的な問題が論じられるが、本実施形態は、背景技術で識別された特定の問題の解決に限定されるべきではないことを理解されたい。

ウィットネスサービスの提供を提供する。

[0003]本概要は、発明を実施するための形態で以下にさらに説明される、簡潔な形での概念の選択を紹介するために提供される。本概要は、特許請求されている対象の重要な特徴および本質的特徴を特定するものではなく、特許請求されている対象の範囲を判定する助けとして使用されるものでもない。

[0004]登録されたクライアントに資源状態の通知を送信するウィットネスサービス（WITNESS SERVICE）を提供するための実施形態が説明される。実施形態は、資源、たとえばクラスタまたはネットワーク内の資源、の状態に関する通知の登録および受信のための様々なメッセージを含むプロトコルを提供する。一実施形態で、プロトコルは、クラスタ内のノードにウィットネス情報を要求するためのクライアントのメッセージを含む。ウィットネス情報は、ウィットネスサービスを提供するクラスタ内のノードを識別する。プロトコルは、追加で、ネットワークまたはクラスタ資源の状態または状態の変化に関する通知のためのウィットネスサービスに登録するために使用されるメッセージを含む。一実施形態で、メッセージは、ノード故障の通知に登録するために使用される。プロトコルはまた、資源の状態情報を有する通知を送信するためのウィットネスサービスのメッセージを含む。実施形態はまた、ウィットネスサービスへの登録を取り消すためのメッセージも提供する。

[0005]実施形態は、コンピュータープロセス、コンピューティングシステム、または、コンピュータープログラム製品もしくはコンピューター可読媒体などの製造品として、実装することができる。コンピュータープログラム製品は、コンピューターシステムによって読取り可能な、および、コンピュータープロセスを実行するための命令のコンピュータープログラムをコード化する、コンピューター記憶媒体でもよい。コンピュータープログラム製品はまた、コンピューティングシステムによって読取り可能な、および、コンピュータープロセスを実行するための命令のコンピュータープログラムをコード化する、搬送波上の伝搬信号でもよい。

[0006]非限定的および非包括的実施形態が、以下の図面を参照して説明される。

[0007]実施形態を実装するために使用することができるシステムを示す図である。 [0008]いくつかの実施形態と一致するウィットネスプロトコルを使用してメッセージを交換するクライアントおよびノードクラスタのブロック図である。 [0009]いくつかの実施形態と一致するファイルアクセスプロトコルおよびウィットネスプロトコルを使用して通信するクライアントおよびファイルサーバークラスタのブロック図である。 [0010]図３に示す実施形態で交換することができるメッセージのシーケンスを示すシーケンス図である。 [0011]いくつかの実施形態と一致する資源状態情報の状態通知を受信および提供するための動作の流れを示す図である。 [0012]いくつかの実施形態と一致するクラスタ資源の状態通知を受信および提供するための動作の流れを示す図である。 [0013]実施形態を実装するのに適したコンピューティング環境のブロック図である。

[0014]様々な実施形態が、本明細書の一部を形成する、および具体的な例示的実施形態を示す、添付の図面を参照して、以下にさらに十分に説明される。しかし、実施形態は、多数の異なる形で実装することができ、本明細書に記載の実施形態に限定されるものとして解釈されるべきではなく、そうではなくて、これらの実施形態は、本開示が充分で完全なものとなるように、そして、当業者に本実施形態の範囲を十分に伝えることになるように、提供される。実施形態は、方法、システムまたはデバイスとして実行され得る。したがって、実施形態は、ハードウェア実装、完全なソフトウェア実装、または、ソフトウェアおよびハードウェア態様を組み合わせた実装の形を取ることができる。したがって、以下の詳細な説明は、限定的な意味で解釈されるものではない。

[0015]図１は、いくつかの実施形態を実装するために使用することができるシステム１００を示す。システム１００は、クライアント１０２および１０４と、サーバークラスタ１０６を含む。クライアント１０２および１０４は、ネットワーク１０８を介してサーバークラスタ１０６と通信する。サーバークラスタ１０６は、クライアント１０２および１０４上のアプリケーションによってアクセスされる情報を記憶する。クライアント１０２および１０４は、クラスタ１０６とのセッションを確立して、クラスタ１０６上の情報にアクセスする。図１では、クライアント１０２および１０４のみがクラスタ１０６と通信するものとして示されるが、他の実施形態では、サーバークラスタ１０６から情報にアクセスする３つ以上のクライアントが存在し得る。

[0016]図１に示すように、サーバークラスタ１０６は、クラスタ１０６に記憶された情報に高い可用性および冗長性の両方を提供する、サーバー１０６Ａ、１０６Ｂ、および１０６Ｃを含む。実施形態で、クラスタ１０６は、ファイルシステム、データベース、または、クライアント１０２および１０４によってアクセスされる他の情報を有し得る。図１には３つのサーバーが示されるが、他の実施形態で、クラスタ１０６は、４つ以上のサーバーまたは２つ以下のサーバーを含み得る。

[0017]一実施形態によれば、クライアント１０２および１０４によってアクセスされる情報の記憶に加えて、クラスタ１０６はまた、ウィットネスサービスも提供する。ウィットネスサービスは、クラスタ１０６によって監視される資源の状態に関する通知をクライアント１０２および１０４が受信できるようにする。資源は、クラスタ資源またはネットワーク資源でもよい。一実施形態で、サーバー１０６Ａ、１０６Ｂ、および１０６Ｃの各々は、ウィットネスサービスを提供する能力を有する。すなわち、クライアント１０２および１０４は、クライアントがクラスタ資源にアクセスするためにサーバーを使用しない限り、ウィットネスサービスのためにサーバー１０６Ａ、１０６Ｂ、または１０６Ｃのいずれかに登録することができる。他の実施形態では、ウィットネスサービスを提供するクラスタ１０６のサーバーの一部のみが存在し得る。たとえば、この実施形態では、サーバー１０６Ｂおよび１０６Ｃのみが、ウィットネスサービスを走らせていることになる。さらに別の実施形態で、クラスタ１０６は、ウィットネスサービスの提供専用のサーバーを含み得る。これらの実施形態について、図示しないが、クラスタ１０６は、ウィットネスサービスを走らせるように具体的に構成され、クライアント１０２および１０４へのアクセスを提供しないことになるサーバーを含み得る。

[0018]ウィットネスサービスを提供するクラスタ１０６からのサーバーは、クラスタ１０６内の資源からおよび／またはネットワーク資源から事象を受信する。サーバーは、これらの事象からの情報を処理および記憶して、これらの資源の状態を追跡する。これらの事象に応答して、サーバーはまた、ウィットネスサービスに登録したクライアントに通知を送信して、資源に関する状態情報を受信することになる。一例として、事象は、負荷バランシングおよび故障検出を提供するために、クラスタ１０６上で走るクラスタサービスによって生成され得る。

[0019]前述のように、クライアント１０２および１０４は、ウィットネスサービスに通知を要求するために、クラスタ１０６と通信する。実施形態で、ウィットネスサービスによって、そして、クライアント１０２および１０４によって使用される、ウィットネスプロトコルが、提供される。プロトコルは、クライアント１０２および１０４がクラスタ１０６内のサーバーにウィットネスサービスに関する情報を要求することを可能にするためのメッセージを含む。情報は、クラスタ１０６内のどのサーバーがウィットネスサービスを提供するかを識別することができる。プロトコルはまた、ウィットネスサービスからの通知に登録するためのメッセージを含む。資源の状態に関してウィットネスサービスによってクライアント１０２および１０４に送信されるメッセージはまた、ウィットネスプロトコルに従ってフォーマットされる。

[0020]一実施形態を説明するために、クライアント１０２が、クラスタ１０６のサーバーとのセッションを確立する。たとえば、クライアント１０２は、サーバー１０６Ａに格納されたデータベースにアクセスするために、サーバー１０６Ａとのセッションを確立することができる。クライアント１０２はサーバー１０６Ａからの情報にアクセスするので、クライアント１０２は、サーバー１０６Ａでの任意の故障を示す早期の表示を有したい場合がある。故障の早期の検出は、早期の回復を可能にすることになり、クライアント１０２のアプリケーションが待たなければならない可能性がある時間量を減らす。早期の検出および回復はまた、クライアント１０２の再接続のために確保された資源が他のクライアントに使用不可能である時間のウィンドウを低減する。

[0021]ウィットネスサービスに登録するために、クライアント１０２は、第１に、クラスタ１０６のどの１つまたは複数のサーバーがウィットネスサービスを走らせているかに関する情報のために、サーバー１０６Ａにウィットネスプロトコルに従ってフォーマットされたメッセージを送信する。サーバー１０６Ａは、ウィットネスサービスを走らせるものとしてのサーバー１０６Ｂおよび１０６Ｃの識別と、それらのサーバーの任意の１つに接続するために必要な任意の情報とを含む情報で応答する。この例では、サーバー１０６Ａから受信した情報に基づいて、クライアント１０２は、登録要求をサーバー１０６Ｂに送信して、サーバー１０６Ａの資源の状態または状態の変化の通知を受信する。クライアントは、いつサーバー１０６Ａの資源が故障したか、そしてその後いつサーバーが再接続のために使用可能かの通知を受けることになる。状態は、サーバー１０６Ａがオンラインかオフラインかのように単純でもよい。他の実施形態で、通知は、サーバー１０６Ａのディスクまたはネットワークアダプタが故障したまたはオフラインにされることになるかどうかなどのより微細な細分性を有し得る。

[0022]いくつかの実施形態で、クライアント１０２は、ウィットネスサービスに登録するために連絡を取るために特定のサーバーを選択するための所定の方法を有し得る。たとえば、クライアントは、ランダムに、ラウンドロビン方式で、または、それがクラスタから受信する情報に基づいて、サーバーを選択することができる。

[0023]クライアント１０２がサーバー１０６Ａの資源に関する通知のためにサーバー１０６Ｂに登録した後、サーバー１０６Ｂによって検出される資源の状態の変化は、通知が資源の状態の変化を表す情報とともにクライアント１０２に送信される結果をもたらす。たとえば、通知は、サーバー１０６Ａがオフラインであることを表すことができる。通知に応答して、クライアント１０２は、サーバー１０６Ａに情報の要求を送信することを停止し、クラスタ１０６内の別のサーバーに接続を試みることができる。別法として、クライアント１０２は、それがサーバー１０６Ａからの情報に再接続し再びアクセスすることができるように、サーバー１０６Ａがオンラインに戻ったという次の通知を待つことができる。

[0024]以下の説明は、単に、図１に示す実施形態がどのように動作し得るかの一例である。以下にさらに詳しく説明するように、実施形態は、異なるステップまたは動作を含み得る。これらは、任意の適切なソフトウェアまたはハードウェア構成要素またはモジュールを使用して実装され得る。

[0025]次に図２を見ると、クライアント２０２および２０４とノードクラスタ２０６を示すソフトウェア環境２００のブロック図が図２に示される。ウィットネスプロトコルを使用するクライアントおよびノードクラスタ交換メッセージは、いくつかの実施形態と一致する。図２は、ウィットネスプロトコルを使用するための環境の一般的な例を説明するために示される。図２の説明は、一般的であり、ノードクラスタ２０６に記憶されたファイルシステムにアクセスするクライアント２０２および２０４などの任意の数の状況に適用可能であるものとし、ノードクラスタ２０６は、分散ファイルシステムを有するサーバークラスタである。もう１つの例として、環境２００は、クライアント２０２および２０４がノードクラスタ２０６に記憶されたデータベースにアクセスする状況において使用され得る。

[0026]図２に示すように、クライアント２０２および２０４は、ノードクラスタ２０６によって提供される情報にアクセスする。ノードクラスタ２０６は、３つのノード、ノード１、ノード２、およびノード３、を含む。図２に示すように、ノード１、２、および３の各々は、クライアント２０２および２０４と通信する様々な構成要素を含む。たとえば、各ノードは、クライアント２０２および２０４と通信してノードクラスタに記憶された情報にクライアントがアクセスできるようにするためのセッションを確立するクライアントアクセスモジュールを含む。

[0027]図２に示す実施形態で、ノード１、２、および３はまた、ノードクラスタ２０６で提供されるウィットネスサービスの部分としてクライアント２０２および２０４と通信するウィットネス管理構成要素（witness management component）を含む。ウィットネス管理構成要素は、クライアント２０２および２０４がウィットネスサービスに登録することができるように、ノードクラスタ２０６内のどのノードがウィットネスサービスを走らせるかに関する情報を提供する。加えて、ウィットネス管理構成要素はまた、資源状態の通知のためのクライアントを登録し、そしてまた、ノードおよびネットワーク資源から事象を受信および処理する、図２に示す、監視構成要素と通信する。監視構成要素は、事象を処理し、そして、資源の状態または状態の変化の通知のために登録された任意のクライアントを順に通知することになるウィットネス管理構成要素に状態および状態の変化の情報を提供する。いくつかの実施形態で、監視構成要素は、クラスタサービスによって提供されるＡＰＩを使用して、クラスタにおける資源の状態を監視することができる。

[0028]図２に示す実施形態で、クライアント２０２は、ノード１とセッションを確立してあり、ノード１のクライアントアクセス構成要素にチャネル２０８を使用してアクセス要求を送信している。クライアント２０２はまた、どのサーバーがウィットネスサービスを提供するかなどのウィットネスサービスに関する情報を受信するために、ノード１との別個のチャネル（図示せず）を開始してある。ノード１と確立された別個のチャネルは、クライアント２０２によって送信されるアクセス要求を妨げることなくウィットネスサービスに関する情報をノード１が通信することを可能にする。

[0029]図２で、クライアント２０２は、ノード２のウィットネス管理構成要素によって提供されるウィットネスサービスに登録した。図２に示すように、ウィットネス管理構成要素との通信は、別個のチャネル２１０を介して生じる。したがって、状態通知を含むいずれのタイプのウィットネス情報も、チャネル２０８を介するアクセス要求を妨害しない。破線で示すチャネル２１６は、クライアント２０２がノード１の資源の故障が生じた場合にアクセス要求を送信するために確立する別個のチャネルを示す。いくつかの実施形態で、ウィットネス管理構成要素は、故障の場合にアクセス要求を送信するためのクライアント２０２の新しい資源、およびまた、新しい資源に接続するための１つのまたはいくつかの推奨されるネットワーク経路を表す情報を提供する。

[0030]同様に、クライアント２０４は、ノード２とのセッションを確立してあり、ノード２のクライアントアクセス構成要素にチャネル２１２を介してアクセス要求を送信している。クライアント２０４はまた、ウィットネスサービスに登録してあり、ノード３のウィットネス管理構成要素とチャネル２１４を使用して通信している。

[0031]一実施形態で、ウィットネス管理構成要素は、追加の機能を提供する。いくつかの実施形態で、構成要素は、負荷バランシング機能を提供する。すなわち、資源の状態に関する通知を送信することに加えて、ウィットネス管理構成要素はまた、クライアント２０２および２０４がノード２０６での負荷バランシングのためのアルゴリズムに基づき異なる資源に接続することを要求する通知を送信することができる。たとえば、図２に示すように、クライアント２０２は、ノード１のクライアントアクセス構成要素と通信する。加えて、クライアント２０２は、ノード１内の資源の故障などの資源のいかなる状態の変化の通知をクライアント２０２に提供するノード２のウィットネス管理構成要素と通信する。この実施形態で、ノード２のウィットネス管理構成要素は、ノード１によって供されるアクセス要求の量が多すぎるため、ノード１が不完全に実行している（たとえば、高遅延）と判定することができる。もう１つの例として、省力または保守などの他の理由でノード２がシャットダウンできるようにするために、ノード２からクライアントをオフロードするための判定が行われ得る。アルゴリズムに従って、ノード２は、十分使用することができていないことがあるノード３に任意の後のアクセス要求の送信をそれが開始すべきであることを表し、クライアント２０２に通知を送信することができる。クライアント２０２は、次いで、チャネル２１６として破線で示すようなセッションをノード３と確立して、後の要求を送信することになる。他の実施形態で、ウィットネス管理構成要素は、アクセス要求を送信するためのクライアント２０２の新しい資源だけではなく、１つのまたはいくつかの推奨されるネットワーク経路も表す情報を提供する。

[0032]図３は、図２で説明する環境２００と同様の環境３００を示す。しかし、環境３００は、サーバークラスタ３０６にあるファイルサーバーに読取り／書込みアクセスを要求するクライアント３０２および３０４を示す。サーバークラスタ３０６は、サーバー１、サーバー２、およびサーバー３を含み、各々のサーバーは、ファイルサーバー、ウィットネス管理構成要素、およびクラスタ監視構成要素を含む。図３に示す、本実施形態で、クライアント３０２および３０４は、アプリケーション、ウィットネス管理構成要素、およびリダイレクタを含む。図４は、実施形態に従って環境３００内で交換することができるメッセージの一例を示すシーケンス図である。

[0033]図３および４の以下の説明は、ファイルアクセスプロトコルとしてサーバーメッセージブロック（ＳＭＢ）プロトコルを使用して行われる。しかし、実施形態はそれに限定されない。ＳＭＢの異なるバージョンまたはネットワークファイルシステム（ＮＦＳ）を含む任意のファイルアクセスプロトコルが、ファイルアクセスプロトコルとして実施形態において使用され得る。ＳＭＢは、単に便宜上および説明を容易にするために本明細書で使用されている。

[0034]図４を参照すると、シーケンス図は、一実施形態に従ってクライアント３０２（図３）、ネットワークＤＮＳ４００、およびサーバークラスタ３０６（図３）の間で交換されるメッセージを示す。クライアント３０２は、第１に、ネットワークＤＮＳ４００に要求４０２を送信して、ＳＭＢの一バージョンを使用してアクセスすることができるファイルシステムを格納するサーバークラスタ３０６のＩＰアドレスを解決する。要求４０２に応答して、ネットワークＤＮＳ４００は、サーバークラスタ３０６のＩＰアドレスを含むメッセージ４０４で応答する。

[0035]応答メッセージ４０４を受信した後、クライアント３０２は、アクセス要求メッセージ４０６をサーバークラスタ３０６に送信する。アクセス要求は、クライアント３０２のリダイレクタによって送信することができる。図３および４に示すように、サーバー１は、クライアント３０２からの要求を処理する。図３に示すように、サーバー１は、クライアント３０２のリダイレクタと通信してファイルアクセスセッションを確立するファイルサーバー構成要素を含む。実施形態で、要求４０６は、ＳＭＢセッションを交渉するための第１の要求でもよい。たとえば、要求は、ＳＭＢ２交渉パケット（SMB2 negotiate packet）でもよい。図４に示すように、サーバー１が、クライアント３０２とセッションを確立するアクセス応答４０８を送信する。応答は、たとえば、ＳＭＢ２セッションセットアップ応答またはＳＭＢ２樹木連結応答（tree connect response）でもよい。

[0036]図４および関連説明は単一のアクセス要求４０６および単一のアクセス応答４０８を規定するが、実施形態で、これらは、単に、セッションを確立するために送信されるいくつかのメッセージのうちの２つのメッセージでもよいことに留意されたい。ＳＭＢ２プロトコルを使用してセッションを確立するために、いくつかのメッセージがクライアント３０２のリダイレクタとサーバー１のファイルサーバーの間で交換され得ることが理解されよう。メッセージは、ＳＭＢ２交渉メッセージ、ＳＭＢ２セッションセットアップメッセージ、および／またはＳＭＢ２樹木連結メッセージのうちの１つまたは複数を含み得る。セッションが確立された後、クライアント３０２は、確立されたチャネル３０８（図３）を介してクラスタ３０６のサーバー１にアクセス要求（図示せず）、たとえばファイルおよび／またはディレクトリ読取り／書込み、の送信を開始する。

[0037]クライアント３０２のウィットネス管理構成要素は、サーバー１がクラスタ３０６の部分であることを検出する。この検出は、応答メッセージ４０８の処理の部分としてまたはいくつかの他の範囲外の手段（out-of-bounds means）によって、実施形態において生じ得る。サーバー１がクラスタ３０６の部分であると判定した結果として、クライアント３０２のウィットネス管理構成要素は、実施形態において、クラスタ３０６によって提供されるウィットネスサービスに登録するように構成される。結果として、クライアント３０２のウィットネス管理構成要素は、新しいチャネル３１０（図３）を使用し、サーバー１にウィットネス情報の要求４１０を送信する。

[0038]実施形態で、要求は、ウィットネスサービスのために特に構成されたウィットネスプロトコルに従ってフォーマットされる。ウィットネスプロトコルは、ウィットネスサービスに関連するいくつかのメッセージを含み得る。たとえば、実施形態で、ウィットネスプロトコルは、少なくとも以下を含む：ウィットネス情報を要求するためのウィットネス要求メッセージ、クラスタ内の資源に関する通知に登録するためのウィットネス登録メッセージ、および、資源の状態の変化（たとえば、資源のオンラインまたはオフライン状況）をクライアントに通知するためのウィットネス資源変更メッセージ。これらは、単にいくつかの例であり、実施形態で、ウィットネスサービスは、他のメッセージを含み得る。一実施形態で、ウィットネスプロトコルは、移送機構として伝送制御プロトコル（ＴＣＰ）とリモートプロシージャコール（ＲＰＣ）を使用する。

[0039]再び図４を参照すると、サーバー１のウィットネス管理構成要素が、ウィットネス情報を含む応答４１２で要求４１０に応答する。応答４１２は、ウィットネスプロトコルに従ってフォーマットされ、ウィットネスサービスを提供するクラスタ３０６内の他のサーバーを識別する情報を含むことになる。実施形態で、応答４１２はまた、クラスタ３０６の他のサーバーのうちの１つでウィットネスサービスに接続するためにクライアント３０２に必要な他の情報も含む。この例では、応答４１２内のウィットネス情報は、ウィットネスサービスを提供するものとして少なくともサーバー２を識別する情報を含む。

[0040]いくつかの実施形態で、ウィットネス情報は、特定のフォーマットで構造化される。たとえば、ウィットネス情報は、ランク付けすることができる。すなわち、ウィットネスサービスを提供するサーバーが、特定の順番でリストに記載され得る。クライアント３０２は、この場合、リスト内の第１のサーバーから開始することができ、そして、サーバーがウィットネスサービスを提供するために使用不可能である場合、クライアントは、次いで、リスト上の次のサーバーを試すことができる。ランキングは、パラメータを考慮するいくつかの異なるアルゴリズムに基づくことができ、いくつかの非限定的な例は以下を含む：ウィットネスサービスに登録したクライアントの数、ウィットネスサービスを提供しているサーバー、ならびに、大量のクライアントを扱う能力を示し得る個々のサーバーおよびネットワーク接続のハードウェアおよびソフトウェア特性。

[0041]サーバー１から受信されたウィットネス情報に応答して、クライアント３０２は、チャネル３１０（図３）を使用して登録要求４１４をサーバー２に送信することになる。登録要求４１４はまた、ウィットネスプロトコルに従ってフォーマットされ、それに関してクライアント３０２が通知の受信を希望する資源を識別する情報を含む。一例では、クライアント３０２は、クライアント３０２がサーバー１の故障を示す早期の表示を有するように、いつサーバー１がオフラインであるのかを知りたいことがある。故障の検出は、早期の回復を可能にし、クライアント３０２のアプリケーションが動作（たとえば、読取り／書込み）を処理させるために待つ時間の量を減らす。この例では、クライアント３０２は、サーバー１のオンライン／オフライン状態に関する通知のためにサーバー２のウィットネス管理構成要素に登録する。サーバー２は、登録要求を確認する状況応答４１６を送信する。実施形態で、応答４１６はまた、それに関してクライアント３０２が通知を受信するために登録した資源の現在の状況も含むことになる。

[0042]いくつかの実施形態で、動作４１６の後、ウィットネスサーバー（サーバー２）は、故障、破線で示すサーバー故障４１７、を経験し得る。この場合、クライアント３０２は、いくつかの実施形態でメッセージ４１０と同様の別のメッセージを送信するステップおよびメッセージ４１２と同様の別のメッセージを受信する（サーバー１または異なるサーバーから）ステップを含む、代替サーバーを再選択する必要があることになる。クライアント３０２はまた、代替サーバーからウィットネスサービスに登録するために、要求４１４と同様のウィットネス登録要求を送信することになる。

[0043]他の実施形態で、クライアントは、複数のウィットネスサーバー接続を確立することができる。すなわち、クライアントは、ウィットネスサービスのためにクラスタ３０６内の複数のサーバーに登録することができる。複数接続は、たとえサーバーのうちの１つが故障しても、クライアントがウィットネスサービスへのアクセスを継続して有することを可能にすることになる。実施形態で、クライアントは、１次接続としてそれらの接続のうちの１つを指定し、万一１次接続が故障した場合、他の接続を単に二次的に使用することができる。

[0044]ある時点でサーバー１のサーバー故障４１８が存在する場合、サーバー２は故障を検出することになる。前述のように、サーバー２は、クラスタ３０６で走るクラスタサービスによって生成される事象を受信することによって、故障を検出することができる。サーバー２がサーバー故障４１８を検出した後は、サーバー２はクライアント３０２に故障の通知４２０を送信することになる。故障に応答して、クライアント３０２は、この実施形態で、任意のさらなるファイルアクセス要求を休止する４２２ように構成される。クライアント３０２が任意の追加のアクセス要求を送信しようとした場合、それらはサーバー１の故障が理由で処理されないことになることが、理解されよう。実施形態で、サーバー２のウィットネスサービスはまた、クライアント３０２からのアクセス要求を処理するためのサーバー３で使用可能な資源が存在することを表すクライアント３０２へのメッセージ４２４を送信するように構成される。メッセージ４２４の受信の後、クライアント３０２は、サーバー３にファイルアクセス要求の送信を再開する４２６ことになる。クライアント３０２のリダイレクタが、チャネル３１２（図３）を介してサーバー３のファイルサーバー構成要素にファイルアクセス要求４２６を送信する。

[0045]他の実施形態では、クライアント３０２は、サーバー１がオンラインに戻るまで、ファイルアクセス要求を休止するように構成される。サーバー２のウィットネスサービスは、サーバー１が使用可能になるとき、サーバー１がクライアント３０２からのアクセス要求を処理するために使用可能であることを表すクライアント３０２へのメッセージ４２４を送信するように構成されることになる。

[0046]図示しないが、いくつかの実施形態で、クライアント３０２がサーバー３にファイルアクセス要求の送信を開始するとき、クライアント３０２はまた、クライアント３０２がウィットネスサービスを受信するサーバーを変更することになる。たとえば、サーバー３にファイルアクセス要求を送信した後、クライアント３０２は、サーバー３にウィットネス情報の要求を送信するプロセスを開始することができる。サーバー３は、どのサーバーがウィットネスサービスを提供しているかに関する情報を含む、サーバー１によって送信される応答４１２と同様の情報で応答することができる。情報は異なってもよく、たとえば、それは異なるサーバーを識別してもよい。ウィットネスサービスを提供するものとして前に識別されたサーバーは、故障してもう使用できなくなった可能性があり、または他のサーバーがオンラインになった可能性がある。また、いくつかの実施形態で、ウィットネス管理構成要素は、ウィットネスサービスを提供するために使用可能なサーバーのランキングを有するウィットネス情報を提供するように構成される。したがって、サーバー３によって提供されるウィットネス情報は、サーバー２によって前に提供されたウィットネス情報とは異なり得る。サーバー３によって送信されるウィットネス情報に応答して、クライアント３０２は、異なるサーバーにウィットネスサービスへの登録を要求するかどうかを決定することができる。

[0047]図５および６は、実施形態による動作の流れ５００、５５０、６００、および６５０を示す。動作の流れ５００、５５０、６００、および６５０は、任意の適切なコンピューティング環境で実行することができる。たとえば、それらの動作の流れは、図１から３に示すものなどのシステムおよび環境によって実行することができる。したがって、動作の流れ５００、５５０、６００、および６５０の説明は、図１から３の構成要素のうちの少なくとも１つを参照し得る。しかし、図１から３の構成要素の任意のそのような参照は、説明のみを目的とし、図１から３の実装は動作の流れ５００、５５０、６００、および６５０の非限定的環境であることを理解されたい。

[0048]さらに、動作の流れ５００、５５０、６００、および６５０は特定の順番で順次に示され、説明されるが、他の実施形態で、それらの動作は、異なる順番で、複数回、および／または並行して、実行され得る。さらに、いくつかの実施形態では、１つまたは複数の動作が省略または結合され得る。

[0049]動作の流れ５００および５５０は図５にともに示されて、動作の流れ５００中のステップが動作の流れ５５０中の対応するステップを有し得ることを示す。動作の流れ５００は、資源の状態通知を受信するためのステップを示す。動作の流れ５５０は、資源の状態通知を提供するためのステップを示す。実施形態で、前述のクライアント１０２および１０４（図１）またはクライアント２０２および２０４（図２）などのクライアントは、動作の流れ５００を実装することができる。動作の流れ５００を実装するクライアントは、ラップトップコンピューター、デスクトップコンピューター、スマートフォンデバイス、またはタブレットコンピューターを含む、任意のタイプのクライアントでもよい。実施形態で、図２に示す、ノード１、ノード２、およびノード３などのノードは、動作の流れ５５０を実装する。ノードは、クラスタサービスを走らせるノードクラスタの部分でもよい。

[0050]流れ５００は、第１のノードに接続するための要求が送信される、動作５０２で開始する。第１のノードは、アクセスされる情報を記憶するノードクラスタの部分である。いくつかの実施形態で、動作５０２で送信される要求は、ノードクラスタに記憶された情報にアクセスするために、第１のノードとのセッションを確立するための要求である。動作５０２の後、流れ５００は、動作５０４に移り、そこで、応答が受信され、第１のノードとのセッションが確立されたことを表す。流れ５００には示さないが、実施形態で、動作５０４の後、アクセス要求が、第１のノードに記憶された情報にアクセスするために、第１のノードに送信される。

[0051]図５の実施形態に示すように、動作の流れは動作５０４から動作５０６に移り、そこで、第２の要求が、ウィットネス情報のために第１のノードに送信される。ウィットネス情報は、資源の通知を提供するために、登録することができるウィットネスサービスをクラスタ内のどのノードが提供するかを識別する。資源は、たとえば、ネットワーク資源またはクラスタ資源でもよい。

[0052]動作５０８で、ウィットネス情報が受信される。ウィットネス情報は、次いで、クラスタ内のどのノードがウィットネスサービスを提供するかを判定するために使用することができる。ウィットネス情報は、動作５１０で使用されて、資源に関する通知に登録するために、登録要求を送信する。一実施形態で、資源は、そこから情報がアクセスされる第１のノードでもよい。要求は、第１のノードの状態、または第１のノードの資源に関する通知を受信することでもよい。たとえば、通知は、第１のノードがオンラインまたはオフラインであるかどうかを表すことができる。

[0053]流れ５００は、動作５１０から動作５１２に移り、そこで、資源に関して通知が受信される。流れ５００は、次いで、動作５１４で終了する。いくつかの実施形態では、アクセス要求の休止、クラスタ内の別のノードへの再接続、および、クラスタ内の他のノードへのアクセス要求の再開など、ステップ５１２での通知の受信に応答して実行される追加のステップが存在し得る。

[0054]実施形態で、動作５１２で受信される通知は、状態通知ではなく、そうではなくて、負荷バランシング通知である。負荷バランシング通知は、今後のアクセス要求は異なるサーバーに送信すべきであることを表すことができる。いくつかの実施形態で、通知は、使用されるべき異なるネットワーク、ネットワーク資源、またはクラスタ資源を具体的に識別することができる。これらの実施形態では、動作５１２での通知の受信に応答して、いくつかの動作が実行されることになる。

[0055]流れ５５０は、流れ５００に関して前述したものに対応するステップを有する。前述のように、実施形態で、図２に示すノード１、ノード２、およびノード３は、流れ５５０を実装することができる。流れ５５０は、動作５５２で開始し、そこで、ノードクラスタ内のノードに接続するための要求が受信される。要求は、ノードクラスタに記憶された情報にアクセスするためのセッションを確立するための要求でもよい。流れは動作５５２から５５４に移り、そこで、セッションがノードクラスタ内の第１のノードに記憶された情報にアクセスすることを可能にするために確立されたことを表す応答が送信される。いくつかの実施形態で、動作５５４に、流れ５５０に図示されない追加のステップが続くことになる。たとえば、動作５５４で送信される応答で表されるようにセッションが確立された後は、ノードクラスタ内の第１のノードに記憶された情報にアクセスするために受信されるいくつかのアクセス要求が存在し得る。

[0056]動作５５４の後、ウィットネス情報の第２の要求が、動作５５６で受信される。ウィットネス情報は、ノードクラスタ内のどのノードがウィットネスサービスを提供するかを識別する情報を含み得る。流れ５５０は、動作５５８に移り、そこで、ウィットネス情報を含む応答が送信される。実施形態で、ウィットネス情報は、ウィットネスサービスを提供するノードクラスタ内のノードの表示を含むだけではなく、いくつかのノードの優先を表示するためにランク付けもされるように、構造化される。

[0057]動作５６０で、資源の状態通知に登録するための登録要求が、受信される。実施形態で、要求は、ネットワーク資源の状態通知についてである。他の実施形態で、要求は、クラスタ内のノードがオンラインまたはオフラインであるかどうかなどのクラスタ資源の状態通知についてである。実施形態で、動作５６０で受信される要求は、第１の要求（動作５５２）および第２の要求（動作５５６）を送信するクライアントとは異なるクライアントから受信されることを理解されたい。流れ５５０の間に受信される要求は、異なるクライアントによって送信され得るが、動作５５２から５６４は、実施形態で、単一のノードによって実行される。

[0058]動作５６０の後、流れは動作５６２に移り、そこで、資源が監視される。動作５６２は、クラスタ資源およびネットワーク資源を含むいくつかの資源の監視を含み得る。たとえ資源に関する通知を受信するための現在の要求が存在しなくても、資源は監視され得る。動作５６２は、ネットワーク資源からまたはクラスタサービスから事象を受信および処理するステップを含み得る。

[0059]動作５６２の後、流れは、動作５６４に移り、そこで、資源に関する通知が送信される。通知は、動作５６０で受信された登録要求で表示された資源の状態に関する情報を提供する。一実施形態で、通知は、第１のノードがオフラインであることを表し得る。動作５６４の後、流れは、動作５１４で終了する。実施形態で、流れ５５０は、動作５６４の後に実行される追加のステップを含み得る。一例として、前にオフラインであった資源が今オンラインであり、アクセスのために使用可能であること、または、別の資源が使用可能であることを表す、送信される追加のメッセージが存在し得る。

[0060]いくつかの実施形態で、動作５５２から５５８は１つの場所で実行され、動作５６０から５６４は別の場所で実行されることに留意されたい。たとえば、動作５５２から５５８は、ノードクラスタ内の異なるノードで、次いで、動作５６０から５６４を実行するノードで実行され得る。他の実施形態で、単一のノードが動作５５２から５６４のすべてを実行することができるが、動作５５２から５５８は第１のクライアントに関して実行可能であり、そして、動作５６０から５６４は第２のクライアントに関して実行可能である。言い換えれば、ノードは、第１のクライアントから情報にアクセスする、およびまた第２のクライアントにウィットネスサービスを提供するための要求を供し得る。

[0061]動作の流れ６００は、クライアントに分散ファイルシステムを提供するクラスタからクラスタ資源の状態通知を受信するためのステップを示す。動作の流れ６５０は、ファイルシステムを提供するクラスタのクラスタ資源の状態通知を提供するためのステップを示す。実施形態で、前述のクライアント１０２および１０４（図１）またはクライアント３０２および３０４（図３）などのクライアントは、動作の流れ６００を実装することができる。一実施形態で、図３に示す、サーバー１、サーバー２、およびサーバー３などのサーバークラスタ３０６のサーバーは、動作の流れ６５０を実装する。

[0062]流れ６００は、サーバークラスタ上のファイルシステムに接続するための要求が送信される動作６０２で開始する。サーバークラスタは、複数のサーバーを含み、クライアントによってアクセスされるファイル情報を記憶する。いくつかの実施形態で、動作６０２で送信される要求は、クラスタ上のファイルにアクセスするために、サーバークラスタ内のサーバーとセッションを確立するための要求である。実施形態で、セッションは、ＳＭＢまたはＮＦＳのバージョンなどのファイルアクセスプロトコルと確立される。動作６０２の後、流れは動作６０４に移り、そこで、クラスタ内のサーバーとのセッションが確立されたことを表す応答が受信される。動作６０２および６０４は、セッションを交渉するために実行される一連の動作中の２つのみの動作でもよい。すなわち、他の実施形態では、動作６０２および６０４の間で実行されるいくつかの動作が存在し得る。

[0063]動作６０４の後、アクセス要求が、サーバークラスタに格納されたファイルシステムから情報にアクセスするために、動作６０６でサーバーに送信される。アクセス要求は、たとえば、ＳＭＢの一バージョンまたはＮＦＳの一バージョンなどの特定のファイルシステムアクセスプロトコルに従ってフォーマットされた読取り／書込み要求を含み得る。

[0064]図６の実施形態に示すように、動作の流れは、動作６０６から動作６０８に移り、そこで、第２の要求が、ウィットネスサービス情報のためにサーバーに送信される。ウィットネスサービス情報は、特に、クラスタ内の何のサーバーが、クラスタ資源の通知を提供するために登録することができるウィットネスサービスを提供するかを識別する。動作６０８で送信される要求は、動作６０２から６０６で使用されるファイルアクセスプロトコルとは異なるウィットネスプロトコルに従ってフォーマットされ得る。

[0065]動作６１０で、ウィットネスサービス情報が受信される。ウィットネスサービス情報は、次いで、クラスタ内の何のサーバーがウィットネスサービスを提供するかを判定するために使用することができる。ウィットネスサービス情報は、動作６１２で使用されて、クラスタ資源に関する通知に登録するための登録要求を送信する。一実施形態で、資源は、それとのセッションが動作６０４で確立された、および、そこから動作６０６で送信された要求を使用して情報がアクセスされる、サーバーでもよい。登録要求は、クライアントがサーバーの状態に関する通知の受信を希望することを表すことができる。

[0066]流れ６００は、動作６１２から動作６１４に移り、そこで、資源に関して通知が受信される。いくつかの実施形態では、アクセス要求の休止、クラスタ内の別のサーバーへの再接続、および、クラスタ内の他のサーバーへのアクセス要求の再開など、ステップ６１４での通知の受信に応答して実行される追加のステップが存在し得る。動作６１４の後、登録を取り消すための要求が、動作６１６で送信される。流れ６００は、次いで、動作６１８で終了する。

[0067]流れ６５０は、流れ６００に関して前述したものに対応するステップを有する。流れ６５０は、サーバークラスタに接続するための要求が受信される動作６５２で開始する。要求は、実施形態では、サーバークラスタに記憶されたファイル情報にアクセスするためのセッションを確立するための要求である。動作は、サーバークラスタのファイルサーバー上で生じる。流れは、動作６５２から６５４に移り、そこで、サーバークラスタ内のファイルサーバーに記憶されたファイルにアクセスすることを可能にするために、セッションが確立されたことを表す応答が送信される。前述のように、動作６５２および動作６５４は、単に、セッションを確立するために実行される２つの動作でもよい。いくつかの実施形態では、セッションを確立するための動作６５２および動作６５４の間に実行されるいくつかの他の動作が存在し得る。

[0068]動作６５４の後には、ファイルアクセス要求が受信される動作６５６が続く。ファイルアクセス要求は、サーバーに記憶されたファイル情報を読み取るまたは書き出すための要求でもよい。実施形態で、動作６５２から６５６で送信および受信されるメッセージは、ＳＭＢの一バージョンまたはＮＦＳの一バージョンなどのファイルアクセスプロトコルに従ってフォーマットされる。

[0069]動作６５６の後、ウィットネス情報の要求が、動作６５８で受信される。要求は、サーバークラスタ内の何のサーバーがウィットネスサービスを提供するかに関するウィットネス情報についてである。流れ６５０は、動作６６０に移り、そこで、ウィットネスサービスを提供するサーバークラスタ内のサーバーの表示を有するウィットネス情報を含む、応答が送信される。動作６５８で受信される要求は、実施形態で、第１の要求（動作６５２）および第２の要求（動作６５８）を送信するクライアントとは異なるクライアントから受信される。流れ６５０の間に受信される要求は、異なるクライアントから送信されるが、動作６５２から６６８は、実施形態で、単一のノードによって実行される。

[0070]動作６６２で、クラスタ資源の状態通知に登録するための登録要求が受信される。実施形態で、要求は、ファイルアクセス要求を供している、およびそれとセッションが確立された、サーバーが、オンラインまたはオフラインであるかどうかなど、クラスタ資源の状態通知についてである。動作６６２の後、流れは、動作６６４に移り、そこで、資源が監視される。動作６６４は、クラスタ上で走るクラスタサービスによって提供されるＡＰＩの使用を含み得る。動作６６４は、クラスタサービスから受信される事象を受信および処理するステップを含み得る。

[0071]動作６６４の後、流れは動作６６６に移り、そこで、資源に関する通知が送信される。通知は、動作６６２で受信された登録要求で表された資源の状態に関する情報を提供する。一実施形態で、通知は、サーバーが今オフラインであることを表し得る。動作６６６の後、流れは動作６６８に移り、そこで、登録を取り消すための要求が受信される。動作６６８で受信される要求は、動作６６２で受信された登録要求などの前の登録が取り消されるべきであることを表す。流れ６５０は、動作６１８で終了する。

[0072]実施形態で、動作６５２から６５８は１つのサーバー上で実行され、動作６６０から６６４は異なるサーバー上で実行されることに留意されたい。たとえば、動作６５２から６５８は、サーバークラスタの第１のサーバー上で、動作６６０から６６４はサーバークラスタの第２のサーバー上で実行され得る。他の実施形態では、単一のサーバーが動作６５２から６６４のすべてを実行し得るが、動作６５２から６５８は第１のクライアントに関して実行することができ、そして、動作６６０から６６４は第２のクライアントに関して実行することができる。言い換えれば、サーバーは、第１のクライアントから情報にアクセスするための要求を供し、第２のクライアントにウィットネスサービスを提供することもできる。

[0073]図７は、本明細書に記載の実施形態を実装するために使用することができる一般的なコンピューターシステム７００を示す。コンピューターシステム７００は、コンピューティング環境の単に一例であり、コンピューターおよびネットワークアーキテクチャの使用または機能の範囲の限定を示唆するものではない。コンピューターシステム７００は、例示的コンピューターシステム７００内に示された構成要素のいずれか１つまたは組合せに関連する従属または要件を有するものとして解釈されるべきではない。実施形態で、システム７００は、図１に関して前述したクライアントおよび／またはサーバーとして使用され得る。

[0074]最も基本的な構成で、システム７００は、通常は、少なくとも１つの処理装置７０２およびメモリ７０４を含む。コンピューティングデバイスの正確な構成およびタイプに応じて、メモリ７０４は、揮発性（ＲＡＭなど）、非揮発性（ＲＯＭ、フラッシュメモリなど）、または、これら２つの何らかの組合せでもよい。この最も基本的な構成は、破線７０６で図７に示される。システムメモリ７０４は、システム７００で実行するアプリケーションを記憶する。たとえば、メモリ７０４は、監視されている資源に関する情報７２０を記憶することができる。メモリ７０４はまた、通知のためのクライアント登録７２２を含み得る。

[0075]本明細書では、コンピューター可読媒体という用語は、コンピューター記憶媒体を含み得る。コンピューター記憶媒体は、コンピューター可読命令、データ構造体、プログラムモジュール、または他のデータなど、情報の記憶のための任意の方法または技術で実装された、揮発性および非揮発性の、取外し可能なおよび取外しができない媒体を含み得る。システムメモリ７０４、取外し可能な記憶機構、および取外しができない記憶機構７０８は、すべてコンピューター記憶媒体の例（すなわち記憶装置）である。コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、電気的消去可能読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または、情報を記憶するために使用することができるおよびコンピューティングデバイス７００によってアクセスすることができる任意の他の媒体を含み得るが、これらに限定されない。任意のそのようなコンピューター記憶媒体は、デバイス７００の部分でもよい。コンピューティングデバイス７００はまた、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの１つまたは複数の入力デバイス７１４を有し得る。ディスプレイ、スピーカー、プリンターなどの１つまたは複数の出力デバイス７１６もまた、含まれ得る。前述のデバイスは例であり、他を使用することができる。

[0076]本明細書では、コンピューター可読媒体という用語はまた、通信媒体を含み得る。通信媒体は、コンピューター可読命令、データ構造体、プログラムモジュール、または、搬送波もしくは他の移送機構などの変調されたデータ信号で他のデータによって実施することができ、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、１つまたは複数の特性集合を有し、信号内で情報をコード化する方式などで変更した信号を示し得る。例として、そして限定ではなく、通信媒体は、ワイヤードネットワークまたは直接ワイヤード接続などのワイヤード媒体と、音響、無線周波数（ＲＦ）、赤外線、および他のワイヤレス媒体などワイヤレス媒体とを含み得る。

[0077]本明細書を通して、特定の記載された特徴、構造または特性が少なくとも１つの実施形態に含まれることを意味し、「１つの実施形態」または「一実施形態」が参照される。したがって、そのような語句の使用は、ただ１つより多い実施形態を参照し得る。さらに、記載された特徴、構造体、または特性は、１つまたは複数の実施形態において任意の適切な形で結合され得る。

[0078]しかし、実施形態は、具体的詳細のうちの１つまたは複数なしで、あるいは他の方法、資源、材料などで、実施され得ることが、当業者には理解され得る。他の例では、よく知られている構造、資源、または動作は、単に実施形態の態様を不明瞭にすることを避けるために、示されていないまたは詳細に記載されていない。

[0079]例示的実施形態およびアプリケーションが図示および記載されるが、実施形態は前述の正確な構成および資源に限定されないことを理解されたい。当業者に明らかな様々な修正、変更および変形が、特許請求されている実施形態の範囲を逸脱することなしに、本明細書で開示される方法およびシステムの構成、動作および詳細に行われ得る。

Claims (10)

1. クライアントに状態通知を提供するコンピューター実装された方法であって、
   第１のノードに接続して前記第１のノードの情報にアクセスするための要求を前記第１のノードで受信するステップであって、前記第１のノードがクラスタ内の複数のノードのうちの１つである、ステップと、
   応答を前記第１のノードから送信するステップであって、前記応答が前記第１のノードの情報にアクセスするためのセッションを確立する、ステップと、
   前記複数のノードに関するノード情報の第２の要求を受信するステップと、
   前記第２の要求に応答して、前記ノード情報を有する第２の応答を送信するステップであって、前記ノード情報が、資源を監視するためのウィットネスノードの機能を果たす前記複数のノードのうちの少なくとも２つのノードを識別し、さらに、前記少なくとも２つのノードの各々についてのランキングを識別する、ステップと、
   少なくとも１つの資源に関する通知に登録するために前記第１のノードで登録要求を受信するステップであって、前記第１のノードが、第１のウィットネスノードの機能を果たし、前記少なくとも１つの資源を監視するステップと、
   前記少なくとも１つの資源の状態を有する通知を前記第１のノードから送信するステップと
   を含む、方法。
2. 前記通知が前記少なくとも１つの資源の故障を表す、請求項１に記載の方法。
3. 前記第１のノードに接続するための前記要求、および、前記第１のノードの情報にアクセスするためのセッションを確立する前記応答が、ファイルアクセスプロトコルに従ってフォーマットされる、請求項１に記載の方法。
4. ノード情報の前記第２の要求、前記ノード情報を有する前記第２の応答、前記登録要求、および前記通知が、前記ファイルアクセスプロトコルとは異なるウィットネスプロトコルに従ってフォーマットされる、請求項３に記載の方法。
5. プロセッサによって実行されると、状態通知を受信する方法を実行する、コンピューター実行可能命令を備えるコンピューター記憶媒体であって、前記方法が、
   第１のファイルサーバーに接続するための要求を送信するステップであって、前記第１のファイルサーバーがクラスタ内の複数のファイルサーバーのうちの１つである、ステップと、
   前記第１のファイルサーバーに記憶されたファイル情報にアクセスするためのセッションの確立を表す前記第１のファイルサーバーからの応答を受信するステップと、
   前記第１のファイルサーバー上のファイルにアクセスするための第１の複数の要求を送信するステップと、
   ウィットネス情報について前記第１のファイルサーバーに第２の要求を送信するステップであって、前記ウィットネス情報が、前記クラスタ内の前記複数のファイルサーバーのうちの第２のファイルサーバーの識別情報を提供し、前記第２のファイルサーバーが、少なくとも１つの資源を監視するウィットネスサービスを提供する、ステップと、
   前記ウィットネス情報を有するメッセージを受信するステップであって、前記ウィットネス情報は、前記ウィットネスサービスを提供する少なくとも２つの追加のファイルサーバーを識別し、さらに、前記少なくとも２つの追加のファイルサーバーの各々についてのランキングを識別する、ステップと、
   前記ウィットネス情報に基づいて、前記少なくとも１つの資源の状態を有する通知に登録するために、前記少なくとも２つの追加のファイルサーバーのうちの少なくとも１つに要求を送信するステップと、
   前記少なくとも１つの資源の前記状態を有する通知を受信するステップと
   を含む、コンピューター記憶媒体。
6. 前記通知に応答して、
   前記第１のファイルサーバーへの任意の追加のファイルアクセス要求を休止するステップと、
   前記クラスタ内の前記複数のファイルサーバーのうちの第３のファイルサーバーの可用性を表すメッセージを受信するステップと、
   前記第３のファイルサーバーに第２の複数のファイルアクセス要求を送信するステップと
   をさらに含む、請求項５に記載のコンピューター記憶媒体。
7. 第１のファイルサーバーに接続するための前記第１の要求、セッションの前記確立を表す前記第１のファイルサーバーからの前記応答、および、ファイルにアクセスするための前記第１の複数の要求が、第１の通信チャネルを介して送信される、請求項５に記載のコンピューター記憶媒体。
8. クライアント通信サービスを提供するためのコンピューターシステムであって、
   クラスタ内の複数のサーバーであって、前記複数のサーバーの少なくとも一部が、
   前記サーバーに記憶されたファイル情報へのアクセスを提供するためのセッションを確立し、
   ウィットネスサービスを提供する前記複数のサーバーのうちの少なくとも２つの他のサーバーを識別するウィットネス情報を記憶し、
   前記ウィットネス情報を提供する前記複数のサーバーのうちの前記サーバーの各々のリストを提供し、
   少なくとも１つの資源に関する事象を監視し、
   前記少なくとも１つの資源に関する通知に登録するための登録要求を受信し、
   前記少なくとも１つの資源の状態を有する通知を送信する
   ように構成された、複数のサーバー
   を備えるシステム。
9. 前記資源がクラスタ資源であり、前記サーバーが前記クラスタ上で走るクラスタサービスから事象を受信する、請求項８に記載のシステム。
10. 前記通知が、前記少なくとも１つの資源の故障を表す、請求項９に記載のシステム。

Images