(57)【要約】  クライアントクラスタ化環境で動作するとき、要求元にリソースに対する継続したアクセスをもたらすために、アプリケーションインスタンス識別子が様々なシステムおよび方法とともに用いられる。第１のクライアント上に常駐する要求元は、リソースにアクセスしようと試みる。第１のクライアントは、リソースにアクセスすることを求める要求を送る。その要求は、要求元を識別するアプリケーションインスタンス識別子と関連付けることができる。ある時点で、第１のクライアントが失敗し、要求元は、フェイルオーバ機構を介して第２のクライアントと関連付けられる。第２のクライアントは、要求元の代わりにリソースにアクセスすることを求める第２の要求を送る。第２の要求は、要求元のアプリケーションインスタンス識別子と関連付けられる。そのアプリケーションインスタンス識別子は、第２の要求が第１の要求と同じ要求元に属するものとして識別するために使用され、それによって、コンフリクト状況を避けながら、リソースにアクセスすることを求める第２の要求を認める。
2014529141.tif 000002
【特許請求の範囲】
【請求項１】
リソースに対する継続したアクセスをもたらす方法であって、
要求元(requestor)からのリソースにアクセスすることを求める第１の要求を受け取るステップであって、前記要求は、第１のクライアントから受け取られる、ステップと、
第１のアプリケーションインスタンス(instance)識別子(identifier)を前記第１のリソースと関連付ける(associating)ステップと、
前記リソースに対する前記第１の要求のアクセスを可能にするステップと、
失敗(failure)から回復した(recovering)後、前記要求元からの前記リソースに関する第２の要求を受け取るステップであって、前記第２の要求は、前記第１のクライアントと異なる第２のクライアントから受け取られる、ステップと、
前記第２の要求と関連付けられる第２のアプリケーション識別子を受け取るステップと、
前記第１のアプリケーション識別子および前記第２のアプリケーション識別子が同じであるのかどうかを決定するステップと、
前記第１のアプリケーション識別子および前記第２のアプリケーション識別子が同じであるとき、
前記第１の要求を無効にする(invalidating)ステップ、および
前記リソースにアクセスすることを求める前記第２の要求を認める(granting)ステップ
を含むステップを実施するステップと
を含む、方法。
【請求項２】
前記第１のアプリケーション識別子は、オープン要求(open request)のアプリケーションインスタンスと関連付けられる、請求項１に記載の方法。
【請求項３】
前記第１のアプリケーション識別子は、プロセスと関連付けられる、請求項１に記載の方法。
【請求項４】
前記第１のアプリケーション識別子は、アプリケーションの少なくとも１つの子プロセス(child process)と関連付けられる、請求項１に記載の方法。
【請求項５】
前記第１のアプリケーションインスタンス識別子を関連付けるステップは、NETWORK_APP_INSTANCE_ECP_CONTEXT構造(structure)中の前記第１のアプリケーションインスタンス識別子(identifier)を受け取るステップを含む、請求項１に記載の方法。
【請求項６】
クラスタ化(clustered)クライアントのフェイルオーバ(failover)を提供するための方法であって、
第２のクライアントで(at)、要求元(requestor)に関するアプリケーションインスタンス識別子(identifier)を受け取るステップであって、前記要求元は、第１のクライアントを使用して、前にリソースにアクセスしている、ステップと、
前記第２のクライアントから、前記要求元の代わりに(on behalf of)前記リソースにアクセスすることを求める第２の要求を送るステップと、
前記第２のクライアントから、前記要求元に関する(for)前記アプリケーションインスタンス識別子を送るステップと、
サーバが前記第２の要求を認めた(granted)という指示(indication)を受け取るステップと、
前記第２のクライアントによって、前記クライアントの代わりに(on behalf of)前記リソースにアクセスするステップと
を含む、方法。
【請求項７】
前記第２の要求を認めた前記サーバは、以前に、前記要求元の代わりに、前記第１のクライアントからリソースにアクセスする第１の要求を認めている、請求項６に記載の方法。
【請求項８】
前記第２のクライアントは、クライアントのフェイルオーバに応答して、前記第２の要求を送る、請求項６に記載の方法。
【請求項９】
少なくとも１つのサーバを備えた、クラスタ化(clustered environment)環境中でクライアントのフェイルオーバを容易にするためのシステムであって、
前記少なくとも１つのサーバは、
コンピュータ実行可能命令を実行するように構成されている少なくとも１つのプロセッサと、
前記コンピュータ実行可能命令を格納する少なくとも１つのコンピュータ可読記憶媒体と
を備え、前記コンピュータ実行可能命令は、前記少なくとも１つのプロセッサによって実行されたとき、
要求元の代わりに第１のクライアントからのリソースにアクセスすることを求める第１の要求を受け取ること、
第１のアプリケーションインスタンス識別子を前記第１のリソースと関連付けること、
前記リソースに対する前記要求元のアクセスを可能にすること、
第２のクライアントからの前記リソースに関する第２の要求を受け取ることであって、前記第２のクライアントは、前記第１のクライアントと異なる、受け取ること、
前記第２の要求と関連付けられる第２のアプリケーション識別子を受け取ること、
前記第１のアプリケーション識別子と前記第２のアプリケーション識別子が同じであるのかどうかを決定すること、
前記第１のアプリケーション識別子と前記第２のアプリケーション識別子が同じであるとき、
前記第１の要求を無効にするステップ、および
前記リソースにアクセスすることを求める前記第２の要求を認めるステップ
を含むステップを実施すること
を行う、
システム。
【請求項１０】
前記第１のクライアントをさらに備え、前記第１のクライアントは、
コンピュータ実行可能命令を実行するように構成されている少なくとも１つのプロセッサと、
前記コンピュータ実行可能命令を格納する少なくとも１つのコンピュータ可読記憶媒体と
を備え、前記コンピュータ実行可能命令は、前記少なくとも１つのプロセッサによって実行されたとき、
前記第１の要求を送り、
前記アプリケーションインスタンス識別子を第２のクライアントに送る、
請求項１８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明の一実施例は、例えば、クラスタ化クライアントのフェイルオーバに関する。
【背景技術】
【０００２】
[0001]クラスタ化環境、たとえば仕事量が複数のマシンにわたって分配される環境は、フェイルオーバを行い、クライアントに高い情報の可用性を提供するのによく使用されている。クラスタ化環境では、クライアントが、その環境の一部である１つまたは複数のノードを介してリソースにアクセスすることが可能になる。クラスタ化環境は、クライアント、サーバまたはその両方として働くことができる。クライアントクラスタのサーバでは、アプリケーションが、クラスタを作り上げるノードのいずれもの上に常駐することができる。アプリケーションは、クライアントクラスタ内にローカルに格納される、または遠隔に格納されるリソースに関する要求を発することができる。エラーがノードで生じた場合、クライアントは、クラスタ中の異なるノードにフェイルオーバまたはマイグレートする。しかし、クライアントがエラー時に一緒に動作していたリソースに対してアクセスすることを、クライアントが再び要求をしたとき、リソースは、そのアプリケーションが常駐する先行するクライアントノードのためのサーバによって、囲われる、またはロックされる可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本願発明の一実施例は、例えば、クラスタ化クライアントのフェイルオーバに関する。
【課題を解決するための手段】
【０００４】
[0002]実施形態が構成されているのは、これらおよび他の考慮事項に関するものである。また、比較的具体的な問題が議論されているが、実施形態は、背景技術で識別された具体的な問題を解決することに限定すべきでないことを理解すべきである。
【０００５】
[0003]この概要は、「発明を実施するための形態」で以下にさらに述べる概念の選択されたものを簡単化した形で紹介するために設けている。この概要は、請求する主題のキーまたは絶対に必要な特徴を識別するようには意図していない、また、請求する主題の範囲を決定するための助けとして使用するようにも意図していない。
【０００６】
[0004]本明細書に、アプリケーションがクラスタ化クライアント環境中の新しいノードにマイグレートした後、リソースに対する継続したアクセスをアプリケーションまたはプロセスにもたらすシステムおよび方法を開示する。クライアントクラスタ中のノード上に常駐するアプリケーションまたはプロセスは、リソースにアクセスすることを求める要求をサーバに送る。実施形態では、一意アプリケーションインスタンス識別子は、リソースを要求しているアプリケーションを識別するために使用される。一意アプリケーション識別子は、要求とともに提供することができる。クライアントがリソースにアクセスしたとき、アプリケーションインスタンス識別子は、要求されるリソースと関連付けられる。
【０００７】
[0005]アプリケーションまたはプロセスが、リソースに対するその操作を完了するのに先立ち、クライアントがクラスタ化環境中でその上に常駐するノードがエラーを被る恐れがあり、それによって、ノードは、失敗する、またはそうでなければ、アプリケーションがそのリソースを適切に解放する前に、リソースに対するアクセスを失うことになる。そのような状況下では、リソースは、前のクライアントの要求によって、サーバ上で囲われた、またはロックされた状態のままに留まる恐れがある。クライアントクラスタ中の異なるノードにフェイルオーバしたとき、新しいクライアントノード上のアプリケーションは、リソースを管理するサーバとの接続を再構築し、アプリケーションがエラー時において前にアクセスしていたリソースに関する第２の要求を行うことができる。第２の要求は、第１の要求とともに送られたアプリケーションインスタンス識別子を含むことができる。リソースに関する第２の要求が、クラスタ化環境中の異なるノードから受け取られることがあるが、アプリケーションインスタンス識別子によって、要求を管理するサーバは、前にリソースをロックさせたのと同じアプリケーションまたはプロセスに第２の要求が属すると決定することを許可される。そうすることによって、サーバは、リソースの使用を無効にし、リソースにアクセスすることを求めるクライアントの第２の要求を認め、さらにコンフリクト状況が生じないことを保証することが可能になる。
【０００８】
[0006]実施形態は、コンピュータプロセス、計算システムとして、またはコンピュータプログラム製品またはコンピュータ可読媒体などの製造物品として実施することができる。コンピュータプログラム製品は、コンピュータシステムが可読な、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードするコンピュータ記憶媒体とすることができる。また、コンピュータプログラム製品は、コンピュータシステムが可読な、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする、搬送波上で伝搬する信号とすることができる。
【０００９】
[0007]次の図を参照して、限定するものでなく包括的なものでもない実施形態を述べる。
【図面の簡単な説明】
【００１０】
【図１】[0008]本明細書に述べる実施形態を実施するために使用することができるシステムを例示する図である。
【図２】[0009]本明細書に述べる実施形態を実施するために使用することができるソフトウェア環境を例示するブロック図である。
【図３】[0010]クラスタ化環境中でリソースに対する継続したアクセスを得るために、クライアントが実施することができる方法の一実施形態を示すフローチャートである。
【図４】[0011]リソースに対する継続したアクセスをもたらすために、クラスタ化環境中のノードによって実施される方法の一実施形態を示すフローチャートである。
【図５】[0012]実施形態を実施するのに適切な計算環境のブロック図である。
【発明を実施するための形態】
【００１１】
[0013]以下で添付図面を参照してより詳細に様々な実施形態を述べ、図面は、実施形態の一部をなし、具体的で例示的な実施形態を示す。しかし、実施形態は、多くの異なる形態で実施することができ、本明細書に述べる実施形態に限定するものとして解釈すべきでない、むしろ、これらの実施形態は、この開示が徹底的で完全なものなるように、および実施形態の範囲を当業者に十分伝達するように提示する。実施形態は、方法、システムまたは装置として実施することができる。それゆえ、実施形態は、ハードウェア実施態様、全体がソフトウェアによる実施態様またはソフトウェアおよびハードウェアの態様を組み合わせた実施態様の形態を取ることができる。したがって、次の詳細な記述は、限定する意味で理解すべきでない。
【００１２】
[0014]本開示の実施形態は、要求元が、フェイルオーバ事象の後、リソースに対するアクセスを再取得することを可能にする、クラスタ化クライアントのフェイルオーバ機構を提供することに関するものである。実施形態では、要求元は、プロセス、アプリケーション、またはアプリケーションの１つまたは複数の子プロセスとすることができる。リソースは、計算環境中のファイル、オブジェクト、データ、またはいずれもの他のタイプのリソースとすることができる。実施形態では、リソースは、独立型のサーバ上に常駐することができる、またはそれは、クラスタ化環境中に常駐することができる。本明細書に開示する実施形態では、クラスタ化環境は、１つまたは複数のノード（たとえば、クライアントおよび／またはサーバの装置）を含むことができる。
【００１３】
[0015]例の実施形態では、クラスタ化環境中のノード上に常駐するアプリケーションは、特定のリソースに対するアクセスを要求することができる。実施形態では、リソースは、ローカルに（たとえばクライアントノード上に）、遠隔装置中に（たとえば、遠隔サーバに、またはクライアントクラスタ化環境中の異なるノードに）、またはクライアントクラスタ化環境と異なるクラスタ化環境に（たとえば複数のノードを含む環境に）格納することができる。たとえば、実施形態では、クラスタ化環境が、クライアントまたはサーバのクラスタとすることができるが、しかし、当業者は、本明細書に開示するシステムおよび方法を、ただしこれらには限定されないが、仮想ネットワークなど、いずれもの他のタイプの環境中で用いることができることを理解するはずである。
【００１４】
[0016]そのような環境では、リソースは、クライアントとアプリケーションの間で共有することができる。アプリケーションがリソースにアクセスしたとき、リソースは、囲われている、またはロックされている場合があり、それによって、アクセスしているアプリケーションがそのリソースを解放するまで、他のアプリケーションがリソースにアクセスすることが妨げられる。リソースの囲み込み、またはロックは、コンフリクトから保護する、すなわちアクセスしているアプリケーションが、リソースに対するその操作を実施する前に、別のアプリケーションによってリソースが変更されないように保護するために用いることができる。しかし、クラスタ化クライアント環境中のノードが失敗した場合、リソースにアクセスしているアプリケーションは、リソースを囲われた、またはロックされた状態から適切に解放することができない。たとえば、アプリケーションの代わりにリソースにアクセスしているクライアントノードは、ネットワーク接続を失う恐れがあり、クラッシュする可能性があり、またはそうでなければ、アプリケーションがその操作を完了してリソースを適切に解放するのに先立ち、リソースに対するアクセスを失う恐れがある。それゆえ、リソースは、それが他のクライアントまたはアプリケーションには利用できない状態のままに留まる可能性がある。リソースを囲われた、またはロックされた状態から自動的に解放する機構を用いることができ、それによって、リソースが恒久的に締め出されないように防ぐ。しかし、そのような機構は、しばしば、ある期間を待ってから、囲われた、またはロックされたリソースを解放する。
【００１５】
[0017]いくつかの事例では、アプリケーションが、失敗したクライアントノードからクライアントクラスタ中の異なるクライアントノードにマイグレートするフェイルオーバを行ったとき、そのアプリケーションは、その前のサーバとの接続を再構築し、異なるクライアントノードを介してリソースに対するその操作（複数可）を再開しようと試みることができる。しかし、アプリケーションのためにリソースに前にアクセスし、エラーのために失敗したクライアントノードによって、リソースが適切に解放されていないので、そのリソースに前にアクセスしたアプリケーションは、サーバがリソースをその囲われた、またはロックされた状態から解放するまで、リソースに対するそのアクセスを取り戻すことができない可能性がある。しかし、ここで、異なるノードがアプリケーションのためにリソースにアクセスしようと試みているので、サーバは、リソースに対してロックを前に確立したのと同じアプリケーションとして、そのアプリケーションを識別することができない恐れがある。しかし、同じアプリケーションがリソースにアクセスしようと試みているので、コンフリクト状況は生じない。そのような状況では、サーバがリソースに対する前のロックを解放するのを待つことによって、アプリケーションには受け入れられない遅延が生じる可能性がある。
【００１６】
[0018]述べたように、アプリケーションがクラスタ化クライアント環境で動作しているので、アプリケーションが、２回目に、リソースにアクセスすることを要求したとき、リソースへのアクセスを求める要求は、異なるロケーション、たとえばクライアントクラスタ化環境中の異なるノードから行うことができる。それゆえ、第２の要求は、あるロケーションまたは異なるＩＰアドレスから来ることができる。要求は、異なるロケーションから行うことができるので、サーバは、リソースに再びアクセスしようと試みるクライアントまたはアプリケーションが、前にそのリソースにアクセスしたのと実際に同じクライアントであると保証するという困難を負う可能性がある。本明細書に開示するシステムおよび方法は、同じアプリケーションがリソースにアクセスしようと試みている状況を識別する機構を提供し、それによって、そのような遅延を防止し、リソースに対する継続したアクセスをアプリケーションにもたらすものである。
【００１７】
[0019]図１は、本明細書に開示する実施形態のいくつかを実施するために使用することができるシステム１００を例示する。システム１００は、クライアントクラスタ１０２およびサーバクラスタ１０６を含む。クライアントクラスタは、クライアント１０２Ａおよび１０２Ｂなど、複数のノードを含む。クライアント１０２Ａおよび１０２Ｂは、クライアントクラスタ中に常駐する装置またはアプリケーションとすることができる。クライアントクラスタ１０２は、ネットワーク１０８を通じてサーバクラスタ１０６と通信することができる。実施形態では、ネットワーク１０８は、インターネット、ＷＡＮ、ＬＡＮ、または当分野で知られているいずれもの他のタイプのネットワークとすることができる。サーバクラスタ１０６は、リソースを格納し、それは、クライアントクラスタ１０２上のアプリケーション（たとえばクライアント１０２Ａおよび１０２Ｂ上に常駐するアプリケーション）によってアクセスされる。実施形態では、クライアント（たとえばクライアント１０２Ａ）は、クライアント上に常駐するアプリケーションの代わりにクラスタ１０６上のリソースにアクセスするために、クラスタ１０６とのセッションを確立することができる。図１では、クライアントクラスタ１０２は、２つのクライアント（たとえば、クライアント１０２Ａおよび１０２Ｂ）だけを含んでいるが、当業者は、いずれもの数のクライアントをクライアントクラスタ１０２中に含めることができることを認識するはずである。
【００１８】
[0020]図１に示すように、サーバクラスタ１０６は、サーバ１０６Ａ、１０６Ｂおよび１０６Ｃを含み、それらは、クラスタ１０６上に格納される情報に対して高い可用性と冗長性の両方を提供する。実施形態では、クラスタ１０６は、ファイルシステム、データベース、またはクライアント１０２および１０４によってアクセスされる他の情報を有することができる。３つのサーバを図１に示しているが、他の実施形態では、クラスタ１０６は、４つ以上のサーバを含んでも、または２つ以下のサーバを含んでもよい。さらにまた、本明細書に述べる実施形態が、サーバクラスタの一部であるサーバと通信するクライアントに関するものであるが、当業者は、本明細書に開示する実施形態が、また、独立型のサーバを使用して実施することができることを認識するはずである。
【００１９】
[0021]実施形態では、クライアントクラスタ１０２は、第１のクライアントノード上にエラーまたは失敗が生じた場合に備えて、クライアントが第１のクライアントノードから第２のクライアントノードにマイグレートすることを可能にするフェイルオーバ機構を提供する。当業者は、いずれものタイプのフェイルオーバ機構も、本明細書に開示するシステムおよび方法とともに用いることができることを認識するはずである。本明細書に開示するシステムおよび方法は、アプリケーションが、もしもフェイルオーバの場合、１つのクライアントから別のクライアントに（たとえばクライアント１０２Ａからクライアント１０２Ｂに）マイグレートして、リソースに対するアクセスを再取得しようと試みたとき、不当な遅延を避けるために用いることができる。実施形態では、リソースにアクセスしているアプリケーションを識別するアプリケーションインスタンス識別子をリソースと関連付けることができる。アプリケーションインスタンス識別子は、グローバル一意識別子（ＧＵＩＤ：globally unique identifier）とすることができ、それは、アプリケーション、アプリケーションによって行われる動作、またはアプリケーションの子プロセスと関連付けられる。たとえば、一実施形態では、アプリケーションは、ＧＵＩＤであるアプリケーションインスタンス識別子と関連付けることができる。別の実施形態では、アプリケーションインスタンス識別子は、アプリケーションによって行われる具体的な操作または動作と関連付けることができる。たとえば、アプリケーションが、２つの異なるファイルに対して２つの異なるオープン要求を発行した場合、各オープン要求は、それ自体のアプリケーションインスタンス識別子を有することができる。また別の実施形態では、アプリケーションインスタンス識別子は、アプリケーションの１つまたは複数の子プロセスと関連付けることができる。本明細書に述べる実施形態から当業者に明らかになるように、アプリケーションのアプリケーションインスタンス識別子をその１つまたは複数の子プロセスと関連付けると、アプリケーションに属するリソースが、ロックされた、または囲われた状態に置かれた場合、子プロセスがリソースにアクセスすることが可能になるはずである。実施形態では、アプリケーションインスタンス識別子は、リソースに関する要求が送られたとき、またはその後で、クライアントによって送ることができる。
【００２０】
[0022]別の実施形態によれば、サーバクラスタ１０６は、クライアントクラスタ１０２の一部であるクライアントによってアクセスされる情報を格納することに加えて、また、もしもサーバノード失敗の場合、リソースの継続したアクセスを可能にするフェイルオーバ機構を提供する。やはり、当業者は、いずれものタイプのフェイルオーバ機構も本明細書に開示するシステムおよび方法とともに用いることができることを認識するはずである。
【００２１】
[0023]実施形態では、クライアントがアプリケーションの代わりにリソースへのアクセスを要求したとき、アプリケーションのアプリケーションインスタンス識別子は、その要求とともに送られる。要求を受け取ったサーバは、アプリケーションインスタンス識別子をリソースと関連付けることができる。たとえば、サーバクラスタは、アプリケーションインスタンス識別子がリソースと関連付けられるように、アプリケーションインスタンス識別子を、サーバクラスタ１０６中に配置された１つまたは複数のノード（たとえば、サーバ１０６Ａ、１０６Ｂおよび／または１０６Ｃなどのサーバ）上に配置されたテーブルまたはキャッシュ中に格納することができる。クライアントにはリソースが用済みになる前に、クライアントがエラーを被る可能性があり、それによって、クライアントはリソースとの接続を失うことを余儀なくされることになる。たとえば、アプリケーションを提供する、またはアプリケーションのために要求または操作を行うクライアントは、サーバクラスタへのそのネットワーク接続を失う恐れがあり、クライアントは、クラッシュする可能性がある、あるいはアプリケーションによるリソースの使用を妨げる、いずれもの他のタイプのエラーが生じる可能性がある。アプリケーションは、エラーを被ったとき、クライアントクラスタ１０２中の新しいクライアントノードにフェイルオーバすることができる。新しいクライアントノードは、サーバクラスタに再接続して、アプリケーションのためにリソースにアクセスすることを求める第２の要求を送ることができる。実施形態では、クライアントは、サーバクラスタ１０６中の同じノードに、または異なるノードに再接続することができる。リソースにアクセスすることを求める第２の要求は、アプリケーションのアプリケーションインスタンス識別子を含むことができる。サーバ（たとえばサーバクラスタ１０６のサーバ１０６Ａ）は、第２の要求を受け取ったとき、第２の要求のアプリケーションインスタンス識別子を、リソースと関連付けられるアプリケーションインスタンス識別子と比較する。２つのアプリケーションインスタンス識別子が一致した場合、サーバクラスタは、リソースの使用を無効にする。実施形態では、リソースの使用を無効にすることは、ファイルをクローズすること、リソースに対するロックを除去すること、またはそうでなければ、リソースを使用に供するために自由にするいずれもの動作を取ることを含むことができる。そのとき、サーバノードは、リソースにアクセスすることを求める、アプリケーションの第２の要求を認めることができる。第２のノードのアプリケーションインスタンス識別子が、リソースと関連付けられるアプリケーション識別子と一致しない場合、サーバは、リソースが自由になるまで、リソースへのアクセスを可能にしないことになる。
【００２２】
[0024]一実施形態を例示するために、クライアントクラスタ１０６中のクライアント１０２Ａ上の要求元（たとえば、プロセス、アプリケーションなど）は、クライアント１０２Ａがサーバクラスタ１０６のサーバとセッションを確立するように要求することができる。たとえば、クライアント１０２Ａは、格納された、サーバ１０６Ａ上にある、またはサーバクラスタ１０６の一部であるデータベースにアクセスするために、サーバ１０６Ａとのセッションを確立することができ、サーバ１０６Ａは、データベースにアクセスすることができる。そのとき、クライアント１０２Ａは、要求元の代わりにリソースに関する要求を送る。要求元を識別するアプリケーションインスタンス識別子は、要求と関連付けられる。実施形態では、要求は、アプリケーションインスタンス識別子を含むことができる、またはアプリケーションインスタンス識別子は、アプリケーションインスタンス識別子が要求と関連付けられていることを、サーバ１０６Ａが決定することができるようにして、別に送ることができる。また別の実施形態では、サーバ１０６Ａまたはサーバクラスタ１０６Ａは、アプリケーションインスタンス識別子を要求と関連付けるために必要な情報を既に持っていて、アプリケーションインスタンス識別子を要求とともに受け取る必要がない場合がある。次いで、サーバ１０６Ａは、要求元がリソースにアクセスすることを認め、それによって、要求元がリソースに対する操作を実施する、またはそうでなければリソースにアクセスすることが可能になる。要求元がリソースにアクセスすることを認めたとき、サーバ１０６Ａは、要求元が現在、リソースにアクセスしていることを示すように、アプリケーションインスタンス識別子をリソースと関連付ける。次いで、リソースは、クライアント１０２がその操作を完了するまで、他のクライアントまたはアプリケーションがリソースにアクセスする、またはそれを変更することができないように、囲う、またはロックすることができる。
【００２３】
[0025]要求元がリソースに対するその操作を完了する前、エラーが生じると、それによってクライアント１０２Ａが失敗する、またはそうでなければリソースへのその接続を失うことになる。クライアントの要求元がその操作を完了済みであるので、要求元は、リソースの制御を解放していない。それゆえ、リソースは、囲われた、またはロックされた状態のままに留まる恐れがある。要求元またはクライアントクラスタ１０２は、要求元をクライアント１０２Ａからクライアント１０２Ｂにマイグレートさせるために、フェイルオーバ機構を用いることができる。一度フェイルオーバ操作が完了すると、クライアント１０２Ｂは、要求元のためにサーバクラスタ１０６に再接続することができる。クライアント１０２Ｂは、サーバ１０６Ａに再接続する、またはサーバクラスタ１０６中のいずれもの他のサーバ（たとえば、サーバ１０６Ｂまたは１０６Ｃ）との新しい接続を確立することができる。一例の状況では、クライアント１０２Ｂは、サーバ１０６Ａに再接続する。再接続したとき、クライアント１０２Ｂは、要求元の代わりにリソースにアクセスすることを求める第２の要求を送ることができる。既に述べたように、要求元がリソースの制御を解放していないので、リソースは、依然としてロックされた、または囲われた状態にある可能性がある。リソースにアクセスするためには、サーバが、たとえばタイムアウト操作を通じてリソースの状態を自動的に変化させることを待つことをしないで、要求元は、そのアプリケーションインスタンス識別子に第２の要求を再び付加することができる。サーバ１０６Ａは、第２の要求を付加されたアプリケーションインスタンス識別子を、リソースと関連付けられるアプリケーションインスタンス識別子と比較する。たとえば、受け取った、またはそうでなければ、第２の要求と関連付けられるアプリケーションインスタンス識別子を、サーバ１０６Ａがリソースと関連付けたアプリケーションインスタンス識別子と比較することによって比較する。関連付けられるアプリケーションインスタンス識別子は、サーバ１０６Ａのローカルキャッシュまたはテーブル中に格納することができる、またはそれは、サーバクラスタ１０６中のどこかほかに格納することができる。キャッシュ中に格納されたアプリケーションインスタンス識別子が、リソースと関連付けられるアプリケーションインスタンス識別子と一致した場合、サーバ１０６Ａは、リソースの使用を無効にする、またはそうでなければそれを自由にし、リソースが何らかの他の機構によって（たとえば、囲われた、またはロックされた状態がタイムアウトすることによって）解放されるのを待つことなしに、クライアント１０２Ｂが要求元のためにリソースに再びアクセスすることを可能にする。アプリケーションインスタンス識別子が一致しない場合、クライアント１０２Ｂは、リソースにアクセスする前に、リソースが自由になるのを待つ必要があることになる。
【００２４】
[0026]上記の例では、クライアント１０２Ｂが同じサーバ１０６Ａに再接続したが、他の実施形態では、クライアントがサーバクラスタ１０６中の別のノードに接続することも可能である。たとえば、クライアント１０２Ｂは、サーバ１０６Ｂに再接続し、要求元の代わりにリソースに対するアクセスを再取得することを求める第２の要求を提出することができる。第２の要求は、要求元のアプリケーションインスタンス識別子と、たとえば、それを第２の要求中に含める、またはそうでなければ第２の要求と関連付けることによって、再び関連付けることができる。この例では、サーバ１０６Ｂは、ローカルキャッシュ中に格納されるリソースと関連付けられるアプリケーションインスタンス識別子を有していない可能性がある、というのはリソースへの元のアクセスがサーバ１０６Ａ上にあったからである。そのような状況では、サーバ１０６Ｂは、サーバクラスタ１０６中の他のサーバと連絡することができて、それらサーバがリソースと関連付けられるアプリケーション識別子を有するのかどうかを決定する。リソースと関連付けられるアプリケーション識別子がサーバクラスタ中の異なるノード（たとえばサーバ１０６Ａ）上に格納されている場合、サーバクラスタ中の他のノード上のアプリケーションインスタンス識別子は、第２の要求を付加されたアプリケーションインスタンス識別子と比較される。それらが一致した場合、サーバ１０６Ｂは、サーバ１０６Ａに、リソースの使用を無効にすることを求める要求を送ることができ、そのとき、サーバ１０６Ｂは、要求元（今はクライアント１０２Ｂ上にある）がリソースにアクセスすることを可能にすることができる。アプリケーションインスタンス識別子が一致しない場合、クライアント１０２Ｂは、リソースが自由になるのを待つ必要があることになる。
【００２５】
[0027]上記の例に基づき、当業者は、クライアントクラスタ１０２中のいずれものクライアントノードが、クライアントクラスタ１０２中の要求元のためにアクセスし、次いでそれにアクセスをもたらすように要求することができることを認識するはずである。さらにまた、サーバクラスタ中のいずれものサーバノード（たとえばサーバクラスタ１０６中のいずれものサーバ）は、要求元が前にリソースにアクセスしたのかどうかを、たとえそのアクセスがサーバクラスタ中の異なるサーバノード上で行われたとしても、決定することが可能である。当業者は、次の記述が、図１に示す実施形態がどのように動作することができるかに関する単に一例であり、他の実施形態が存在することを認識するはずである。たとえば、クライアントノードは、遠隔サーバまたはサーバクラスタ上のリソースにアクセスすることよりむしろ、クラスタ化環境中に（たとえば、クライアントクラスタを作り上げる同じ、または異なるクライアントクラスタノード上に）常駐するリソースに対する要求元（たとえば、アプリケーションまたはプロセス）の継続したアクセスをもたらすために、本明細書に述べる実施形態を実施することができる。以下でより詳細に述べるように、本明細書に述べる実施形態は、様々な異なるステップまたは操作を伴うことができる。さらにまた、本明細書に述べる実施形態は、いずれもの適切なソフトウェアまたはハードウェアの構成要素またはモジュールを使用して実施することができる。
【００２６】
[0028]ここで、図２を参照すると、この図は、複数のクライアントノード（たとえば、クライアント２０２および２０４）を有するクライアントノードクラスタ２０１と、複数のサーバノード（たとえば、ノード１  ２０８およびノード２  ２１６）を有するサーバノードクラスタ２０６とを示す、ソフトウェア環境２００のブロック図を例示する。実施形態では、クライアント２０２は、要求元の代わりにサーバクラスタ環境２０６中のリソース２２６などのリソースにアクセスすることを要求する。クライアントノードクラスタ２０１は、クライアントクラスタ１０２（図１）などのクライアントクラスタとすることができる。例示していないが、クライアントクラスタは、３つ以上のクライアントを含むことができる。サーバノードクラスタ２０６は、サーバクラスタ１０６（図１）などのサーバクラスタとすることができる、またはそれは、ただしこれらに限定されないが、仮想ネットワークなど、いずれもの他のタイプのクラスタ化環境とすることができる。リソース２２６は、クラスタ化環境の一部であるデータ記憶部２２８中に格納することができる。示していないが、代替実施形態では、データ記憶部２２８は、クラスタ化環境の一部としなくてもよいが、しかしネットワークを介してクラスタ化環境に接続することができる。そのようなネットワークの例は、ただしこれらに限定されないが、インターネット、ＷＡＮ、ＬＡＮ、または当分野で知られているいずれもの他のタイプのネットワークを含む。またさらなる実施形態では、データ記憶部は、クラスタ２０６の一部であるノード（たとえば装置）の一部とすることができる。
【００２７】
[0029]サーバノードクラスタ２０６は、ノード１  ２０８およびノード２  ２１６など、１つまたは複数のノードを含むことができる。２つだけのノードクラスタを図２に例示しているが、いずれもの数のノードクラスタをクラスタ化環境２０６中に含めることができる。実施形態では、ノードクラスタ２０８および２１６は、リソース２２６を求める要求を受け取り、それに対する操作を行う、および／またはそれへのアクセスを認めることが可能である。実施形態では、リソース２２６は、ファイル、オブジェクト、アプリケーション、データ、またはノードクラスタ２０６中のノードまたは独立型のサーバ上に格納される、あるいはそれらがアクセス可能ないずれもの他のタイプのリソースとすることができる。
【００２８】
[0030]実施形態では、クライアントは、初期要求２２２をクラスタ化環境２０６に送る。図２に例示するように、初期要求２２２は、クライアント２０２が送り、ノード１  ２０８が受け取ることができる。しかし、代替実施形態では、初期要求２２２は、クライアントまたはクライアントクラスタ２０１中のいずれもの他のクライアントノードが送り、ノード２  ２１６またはサーバクラスタ２０６中のいずれもの他のノードが受け取ることができる。例示的な要求は、ただしこれらに限定されないが、ファイルを作成する、それをオープンする、またはそうでなければ、それにアクセスすることを求める要求を含む。要求２２２は、クライアントからノードクラスタに、たとえば、ただしこれらに限定されないが、インターネット、ＷＡＮ、ＬＡＮ、または当分野で知られているいずれもの他のタイプのネットワークネットワークなどのネットワークを介して伝送することができる。初期要求２２２は、リソース２２６などのリソースにアクセスすることを求める要求を含むことができる。実施形態では、要求２２２は、また、クライアント２０２がそれの代わりに要求を行っている要求元を識別するアプリケーションインスタンス識別子を含むことができる。実施形態では、初期要求２２２は、１つまたは複数のメッセージから構成することができる。たとえば、要求２２２は、要求とアプリケーションインスタンス識別子の両方を含む単一メッセージとすることができる。別の実施形態では、要求２２２は、１つまたは複数の要求、さらにまた１つまたは複数のアプリケーションインスタンス識別子を含む複数のメッセージとすることができる。実施形態では、クライアント２０２は、要求２２２とともに伝送することができる、１つまたは複数のアプリケーションインスタンス識別子を格納する、および／またはそれを生成するために使用されるアプリインスタンスキャッシュ（App Instance Cache）２１４を含むことができる。
【００２９】
[0031]図２に示すように、ノード１  ２０８は、要求２２２およびアプリケーションインスタンス識別子をクライアント２０２から受け取ることができる。要求されたリソース２２６が利用できる場合、たとえば別のクライアントまたはアプリケーションによって囲われていない、またはロックされていない場合、ノード１は、クライアント上で実行している要求元の代わりにリソース２２６にアクセスすることを求める、クライアント（たとえばクライアント２０２）の要求を認めることができる。リソース２２６へのアクセスを認めたとき、フィルタドライバ２１０は、クライアント２０２とリソース２２６の間の関連付けを割り当てる、またはそうでなければ、それがクライアント２０２から受け取ったアプリケーションインスタンス識別子を格納することによって、関連付けを生成することができる。実施形態では、関連付けは、オブジェクトとして、ノード１の一部であるアプリインスタンスキャッシュ２１２中に格納することができる。例示する実施形態では、アプリインスタンスキャッシュ２１２をノード１  ２０８の一部として示しているが、実施形態では、アプリインスタンスキャッシュ２１２は、ノードクラスタ２０６の一部としてどこかほかに格納することができる。当業者は、ノードクラスタ２０６が、ノード２  ２１６上のアプリインスタンスキャッシュ２２０など、１つまたは複数のアプリインスタンスキャッシュを含むことができることを認識するはずである。実施形態では、２つ以上のアプリインスタンスキャッシュが存在するとき、複数のアプリインスタンスキャッシュ中に格納されるデータは、すべてのアプリインスタンスキャッシュにわたって複製することができる、または各アプリインスタンスキャッシュが、別々のデータを格納することができる。
【００３０】
[0032]一実施形態では、クライアントから受け取った、要求元（たとえば、アプリケーションまたはプロセス）を識別するアプリケーションインスタンス識別子は、_NETWORK_APP_INSTANCE_ECP_CONTEXT構造中に格納することができる。_NETWORK_APP_INSTANCE_ECP_CONTEXT構造は、次のように定義することができる。
【００３１】
typdefstruct_NETWORK_APP_INSTANCE_ECP_CONTEXT {
USHORT Size;
USHORT Reserved;
GUID AppInstcelD;
}_NETWORK_APP_INSTANCE_ECP_CONTEXT,
*PNETWORK_APP_INSTANCE_ECP_CONTEXT;
[0033]そのような実施形態では、変数sizeが、構造のサイズに関する情報を格納することができ、変数AppInstcelDは、フェイルオーバのクラスタクライアントアプリケーション、たとえばクライアント２０２上で実行している要求元に関する一意アプリケーションインスタンス識別子とすることができる。実施形態では、要求元のアプリケーションインスタンス識別子を含む_NETWORK_APP_INSTANCE_ECP_CONTEXT、あるいは別のオブジェクトまたは変数は、グローバル一意識別子（ＧＵＩＤ）キャッシュ２１４中に格納することができる。実施形態では、_NETWORK_APP_INSTANCE_ECP_CONTEXT構造は、リソースにアクセスすることを求める要求（たとえば、生成またはオープンの要求）と関連してクライアントからサーバに送ることができる。一実施形態では、要求元のアプリケーションインスタンス識別子は、要求元がクラスタ化クライアント環境２０１中においてその上で実行しているクライアントノードのＧＵＩＤキャッシュ中に格納することができる。別の実施形態では、図２には示していないが、クライアントノードクラスタ２０１は、アプリケーションインスタンス識別子を格納するセントラルレポジトリを有することができる。そのような実施形態では、クライアントノードクラスタ２０１中の複数のクライアントノードは、集中型のレポジトリにアクセスすることができる。また別の実施形態では、アプリケーションインスタンス識別子は、複数のＧＵＩＤキャッシュ（たとえば、ＧＵＩＤキャッシュ２１４およびＧＵＩＤキャッシュ２１６）にわたって格納することができる。そのような実施形態では、クライアントノードクラスタ２０１は、反復アルゴリズムを用いることができて、複数のＧＵＩＤキャッシュが同じアプリケーションインスタンス識別子を含むことを保証する。
【００３２】
[0034]既に述べたように、アプリケーションインスタンス識別子は、リソース２２６と関連付けることができ、さらにクライアント２０２は、要求元の代わりにリソース２２６にアクセスする。サーバノード２０６は、サーバノードクラスタ２０６の一部である１つまたは複数のアプリインスタンスキャッシュ、たとえばアプリインスタンスキャッシュ２１２および２２０中にそのような関連付けを格納することができる。一実施形態では、アプリケーションインスタンス識別子は、リソース２２６に関するエクストラクリエイトパラメータ（ＥＣＰ：Extra Create Parameter）リストにリソースを加えることによって、リソースと関連付けることができる。ＥＣＰリストは、サーバノードクラスタ２０６の一部であるアプリインスタンスキャッシュ、たとえばアプリインスタンスキャッシュ２１２および２２０中に格納することができる。実施形態では、ＥＣＰがサーバによって受け取られたとき、サーバは、ＥＣＰからアプリケーションインスタンス識別子を抽出し、それをキャッシュに加えてリソース、リソースハンドルなどと関連付ける。アプリケーションインスタンス識別子をクライアントクラスタ２０１中に格納することに関して述べたように、ノードと関連付けられるアプリケーションインスタンス識別子は、サーバノードクラスタ２０６中のノード上の個々のアプリインスタンスキャッシュ中に、サーバクラスタ２０６中のセントラルレポジトリ中に格納することができる、またはサーバノードクラスタ２０６中の複数のノード上の複数のアプリインスタンスキャッシュにわたって複製することができる。
【００３３】
[0035]実施形態では、リソース２２６が、囲われた、またはロックされ、さらにクライアント２０２上で実行している要求元が、リソース２２２へのアクセスを有しており、それによって、他のクライアントまたはアプリケーションがリソース２２６にアクセスしないように防止されて、いずれもの起こり得るコンフリクトを回避する。実施形態では、要求元がリソース２２６に対するその操作を完了する前に、クライアント２０２がエラーを被ると、それによってクライアント２０２が、リソースとの接続が失うことになる。たとえば、クライアントはクラッシュする、オフラインにされる、またはサーバノード２０８へのそのネットワーク接続を失う恐れがある。そのような事例では、リソース２２６は、依然として囲われた、またはロックされた状態にある可能性がある、というのは、要求元がリソースに対するロックを解放しておらず、それによって他のクライアントがリソース２２６にアクセスするのが阻まれるからである。
【００３４】
[0036]エラーがクライアント２０２に生じたとき、要求元は、クライアントクラスタ２０１中の新しいクライアントノード（たとえばクライアント２０４）にマイグレートするために、クライアントのフェイルオーバ機構２３２を利用することができる。当業者は、クライアントのフェイルオーバ２３２で、いずれものタイプのフェイルオーバ機構を用いることができることを認識するはずである。実施形態では、フェイルオーバ機構２３２は、また、今失敗したクライアント２０２上のＧＵＩＤキャッシュ２１４中に格納されている可能性がある要求元のアプリケーションインスタンス識別子のマイグレートを含むことができる。マイグレートが完了したとき、要求元は、リソース２０２へのアクセスを再取得しようと試みることができる。実施形態では、クライアント２１６は、要求元の代わりにリソース２２６に対するアクセスを要求する第２の要求２２４をノード１に送ることができる。しかし、継続したアクセスがない場合、本明細書に開示する実施形態では、ノード１  ２０８が、クライアント２０４（第２の要求２２４の送信者）の代わりにリソース２２６にアクセスすることを求める要求を受け取ったとき、それは、その要求を拒否する可能性がある、というのは、クライアント２０２がリソースの代わりに行った前のアクセスのために、リソース２２６は依然として囲われた、またはロックされた状態にあるからである。本明細書に開示する実施形態がない場合、ノード１  ２０８は、リソース２２６にアクセスすることを求める第２の要求が、異なるロケーション（たとえばクライアント２０４）からのものであると認識するはずである。ノード１  ２０８は、要求が、リソース２２６に対してロックを保持するのと同じ要求元のためのものであると決定することはできないはずであり、したがって、要求を認めると、コンフリクトをもたらすことになるはずと決定するはずである。しかし、同じ要求元が、リソース２２４にアクセスしようと試みる場合、コンフリクトの問題は生じず、クライアントに、リソースがシステムによって自由になるのを待たせて、不当な遅延がもたらされる恐れがある。
【００３５】
[0037]アプリケーションインスタンス識別子は、この問題を解決するために使用することができる。実施形態では、第２の要求２２４は、また、２３２で示すフェイルオーバの間、クライアント２０４にマイグレートした要求元を識別することから得られるアプリケーションインスタンス識別子を含むことができる。実施形態では、要求元のアプリケーションインスタンス識別子は、クライアントのフェイルオーバ２３２の間の要求元のマイグレートに先立ち、クライアント２０４のＧＵＩＤキャッシュ２２８中に存在する可能性がある。たとえば、反復機構は、クライアントクラスタ２０１中のノードにわたって要求元のアプリケーションインスタンス識別子を複製するために、用いられた可能性がある。別の実施形態では、要求元２０３は、そのアプリケーションインスタンス識別子を格納することができる。また別の実施形態では、要求元２０３のアプリケーションインスタンス識別子は、クライアントのフェイルオーバ２３２の間、マイグレートさせることができる。
【００３６】
[0038]要求２２２に関して述べたように、アプリケーションインスタンス識別子は、第２の要求２２４と同じメッセージで伝送することができる、または第２の要求２２４は、いくつかの異なるメッセージから構成することができる。第２の要求がノードクラスタ２０６またはクラスタ中の個々のノード、たとえばノード１  ２０８で受け取られ、受信サーバが、リソースが囲われている、またはロックされていると決定したとき、第２の要求２２４中のアプリケーションインスタンス識別子がリソース２２６と関連付けられるアプリケーションインスタンス識別子と同じであるのかどうかについて、決定がなされる。実施形態では、ノード２  ２１６は、第２の要求２２２とともに受け取られたアプリケーションインスタンス識別子を、リソース２２６と関連付けられるアプリケーションインスタンス識別子と比較することになる。リソース２２０と関連付けられるアプリケーション識別子は、ノード１  ２１２のアプリインスタンスキャッシュ２１２中に格納することができる。複数のアプリインスタンスキャッシュがノードクラスタ２０６中に存在する実施形態では、決定には、ノードクラスタ２０６中の２つ以上のアプリケーションインスタンスキャッシュをチェックすることができる。そのような実施形態では、一致するアプリケーションインスタンス識別子がアプリインスタンスキャッシュ２１２中で見つからない場合、ノード１  ２１６は、一致するアプリケーションインスタンス識別子がアプリインスタンスキャッシュ２２０中で見つかるかどうかを決定するように求める要求をノード２  ２１２に送ることができる。
【００３７】
[0039]一実施形態では、第２の要求２２４中で受け取られたアプリケーションインスタンス識別子が、リソース２２６と関連付けられるアプリケーションインスタンス識別子（それは、アプリケーションインスタンスキャッシュ２１２および／または２２０中に格納されている可能性がある）と一致しない場合、第２の要求２２４は、リソース２２６が自由になるまで、承認されない場合がある。しかし、一致していることが見つかると、受信サーバ（たとえばノード１  ２０８）および／またはサーバノードクラスタ２０６は、リソース２２６に対するアクセスを認める動作を行い、クライアント２０４および要求元２０３に不当な遅延を生じない。そのような事例では、ノードクラスタ２０６は、リソース２２６の使用を無効にすることができ、それによって、リソース２２６が囲われた、またはロックされた状態からマイグレートする。実施形態では、先行するアクセスを無効にすることは、囲われた、またはロックされた状態からリソースを引き出すいずれもの動作を含むことができる。１つの限定されない例は、オープンされたファイルをクローズする（たとえばリソース２２６がファイルである場合）ことである。一度先行するアクセスが無効にされると、リソース２２６にアクセスすることを求める第２の要求２２４は、承認することができ、それによって要求元２０３に継続したアクセスがもたらされる。
【００３８】
[0040]一実施形態では、第２の要求２２４を受け取るノード、たとえば図２のノード１  ２０８は、異なるノード（たとえばノード２  ２１６）がアクセスおよび／または先行するアクセスを無効にするための許可を有する場合、リソース２２６への先行するアクセスを無効にするために、必要な動作を取ることができる。しかし、いくつかの事例では、要求を受け取るノードは、アクセスまたは先行するアクセスを無効にする許可を有さないことがある。たとえば、元の要求２２２がノード２  ２１６に対してなされた場合、そのような事例が起きることがあり、その場合、ノード２  ２１６は、リソースに対する制御を有する場合がある。そのような事例では、第２の要求２２４を受け取るノードは、先行するアクセスを無効にするように求める要求を制御するノードに送ることができる。一度制御するノードが先行するアクセスを無効にすると、第２の要求２２４を受け取るノードは、第２の要求２２４を認めることができる。他の実施形態では、第２の要求２２４を受け取るノードは、クライアント２０４および／または要求元２０３（今は、クライアント２０４上に常駐する）にリソース２２６に対するアクセスを与えるように求める要求を異なるノードに送ることができる。
【００３９】
[0041]述べたプロセスによって、前にアクセスし、リソース２２６に対するロックをなお保持しているリソース２０３からリソース２２６にアクセスすることを求める第２の要求２２４を、アプリケーションインスタンス識別子の使用を通じて認める際に不当な遅延が回避される。さらにまた、アプリケーションインスタンス識別子によって、認められたいずれもの要求がリソース２２６に対してコンフリクトを生起しないことを保証するという利点がもたらされる。たとえば、異なるアプリケーションから要求が受け取られた場合、その要求は、リソースと関連付けられるアプリケーションインスタンス識別子と異なるアプリケーションインスタンス識別子を含むことになり、その要求は、拒否されることになるはずである。アプリケーションインスタンス識別子は、グローバル一意識別子であるので、異なるアプリケーションに関するアプリケーションインスタンス識別子は、同じものにならない。
【００４０】
[0042]図３は、要求元が、クライアントクラスタ化環境中のリソースに対する継続したアクセスを得るために、用いることができる方法３００の実施形態を示すフローチャートである。たとえば、要求元は、クライアント、たとえばクライアント２０２（図２）とすることができ、それは、方法３００を用いて、リソース（たとえばリソース２２６）にアクセスする。実施形態では、リソースは、遠隔マシン、たとえばサーバ上に常駐することができる。サーバは、独立型のサーバ、またはクラスタ化環境、たとえばサーバクラスタ２０６（図２）の一部とすることができる。フローは、操作３０２から始まり、そこでは、リソースに関する要求がサーバに送られる。実施形態では、要求は、リソースにアクセスすることとすることができる。実施形態では、リソースにアクセスするステップは、ファイルをオープンするステップ、ファイルを生成するステップ、またはそうでなければ、クライアントには遠隔である可能性があるリソースにアクセスする、またはそれに対して操作を実施するステップを含むことができる。実施形態では、要求元は、クライアントクラスタ化環境下で動作することができる。そのような実施形態では、操作３０２で送られた要求は、クライアントクラスタ化環境中で第１のクライアントから送ることができる。
【００４１】
[0043]フローは、操作３０４に続き、そこでは、アプリケーションインスタンス識別子が、たとえばサーバ（たとえば、独立型のサーバまたはクラスタ化環境中のノード）に送られる。一実施形態では、要求を送った第１のクライアントは、また、要求元の代わりにアプリケーションインスタンス識別子を送ることができる。前に述べたように、アプリケーションインスタンス識別子は、要求元（たとえば、リソースに対するアクセスを要求するアプリケーション、クライアント、またはアプリケーションの子プロセス）を識別するＧＵＩＤである。一実施形態では、アプリケーションインスタンス識別子は、ネットワークを介して伝送されるメッセージで送ることができる。アプリケーションインスタンス識別子は、操作３０２で要求を含む同じメッセージで伝送することができる、またはそれは、異なるメッセージで伝送することができる。そのような実施形態では、アプリケーションインスタンス識別子を含むオブジェクト、たとえば、ただしこれらに限定されないが、図２に関して述べた_NETWORK_APP_INSTANCE_ECP_CONTEXTを操作３０２で送ることができる。
【００４２】
[0044]一実施形態では、アプリケーションインスタンス識別子を操作３０４で送るために、インターフェースを使用することができる。インターフェースは、クライアント上に配置される、またはクライアントが利用できてクライアントクラスタ化環境中で動作するカーネルレベルのインターフェースとすることができる。実施形態では、カーネルレベルのインターフェースは、アプリケーションインスタンス識別子をサーバに送るために、要求元および／またはクライアントによって使用することができる。次の事項は、アプリケーションインスタンス識別子を送るために、操作３０４で用いることができるカーネルレベルのインターフェースの限定されない例である。
#if (NTDDI_VERSION >= NTDDI_WIN8)
//
//アプリケーションがそのインスタンスＩＤを提供するためのＥＣＰコンテキスト
//
typedef struct_NETWORK_APP_INSTANCE_ECP_CONTEXT {
//
//これは、この構造のサイズに設定しなければならない
//
USHORT Size;
//
//これは、ゼロに設定しなければならない
//
USHORT Reserved;
//
//発信者は、アプリケーションの単一インスタンスについて常に一意とすべき
//ＧＵＩＤを置く
//
GUID AppInstanceID;
} NETWORK_APP_INSTANCE_ECP_CONTEXT,
*PNETWORK_APP_INSTANCE_ECP_CONTEXT;
//
//APP_INSTANCE_ECP_CONTEXT構造について使用されるＧＵＩＤ
//
//{6AA6BC45-A7EF-4af7-9008-FA462E144D74}
//
DEFINE_GUID (GUID_ECP_NETWORK_APP_INSTANCE,0x6aa6bc45,0xa7ef,
0x4af7,0x90,0x8,0xfa,0x46,0x2e,0x14,0x4d,0x74);
#endif//NTDDI_Version >= NTDDI_WIN8
[0045]具体的なカーネルレベルのインターフェースを提示したが、当業者は、他のカーネルレベルのインターフェースを、アプリケーションインスタンス識別子を送るために、操作３０４で用いることができることを認識するはずである。
【００４３】
[0046]別の実施形態では、アプリケーションユーザインターフェース（ＡＰＩ：application user interface）を、アプリケーションインスタンス識別子を送るために、操作３０４で用いることができる。そのような実施形態では、要求元および／またはクライアントは、ＡＰＩをコールすることによって、アプリケーションインスタンス識別子を送ることができる。ＡＰＩは、操作３０４を実施するクライアント（たとえばサーバクラスタ中の第１のクライアント）上で提供することができる、またはＡＰＩは、別の装置上で提供することができ、要求元または別のアプリケーションまたはプロセスがそれにアクセスすることができる。次の事項は、アプリケーションインスタンス識別子を送るために、操作３０４で用いることができるＡＰＩの限定されない例である。
【００４４】
NTSTATUS RegisterAppInstance(
_in PGUID Applnstance
);
[0047]具体的なＡＰＩを提示したが、当業者は、他のＡＰＩを操作３０４で用いることができることを認識するはずである。さらにまた、操作３０４を明確に区別される操作として例示しているが、当業者は、アプリケーションインスタンス識別子を送るステップは、操作３０２で要求を送るステップと同時に実施することができることを認識するはずである。
【００４５】
[0048]要求されたリソースが、ロックされていないとき、操作３０２で送られる要求が認められて、フローは、操作３０６に続き、そこでは、リソースがアクセスされる。既に述べたように、リソースを制御するサーバまたは装置は、リソースを囲われた、またはロックされた状態に置くことができ、一方要求元は、操作３０６でリソースにアクセスする。リソースにアクセスしている間のある時点で、エラー、たとえば図２に関して述べたエラーが生じると、それによって、クライアントが失敗する、またはそうでなければ、リソースに対する接続を失うことになる。エラーによって、要求元がリソースのその使用を終える前に、クライアント（たとえばサーバクラスタ中の第１のクライアント）がリソースに対するアクセスを失うことになる可能性がある。そのような状況下では、リソースは、その囲われた、またはロックされた状態から解放されない恐れがある。
【００４６】
[0049]フローは、操作３０８に続き、そこでは、フェイルオーバ操作が実施される。実施形態では、フェイルオーバ操作は、クライアントノードクラスタ中の異なるクライアント（たとえば第２のクライアント）に要求元およびその状態をそっくりコピーするステップを含むことができる。実施形態では、要求元の状態は、第２のクライアント上にそっくりコピーすることができ、要求元は、第１のクライアントが失敗したところからその要求元が実行を再開することができるように、第２のクライアント上で実行することができる。別の実施形態では、要求元は、第１のクライアントのフェイルオーバの時点で、第１のクライアントと通信し合う状態（むしろ、その上で実行するより）にあることができる。そのような実施形態では、フェイルオーバ操作は、要求元がクライアントクラスタ中の第２のクライアントとの通信を確立するステップを含むことができる。
【００４７】
[0050]実施形態では、ただしこれらに限定されないが、要求元のアプリケーションインスタンス識別子を含む状態情報を、第１のクライアントから第２のクライアントに転送することができる。一実施形態では、第１のクライアントは、要求元のアプリケーションインスタンス識別子および／または要求元の状態情報を含むメッセージを送ることができる。アプリケーションインスタンス識別子および／または状態は、フェイルオーバプロセスの間に送ることができる、または実施形態では、第１のクライアントが失敗する前に、たとえばクライアントクラスタ化環境中のクライアントにわたって情報をそっくりコピーする反復プロセスの間に送ることができる。別の実施形態では、要求元のアプリケーションインスタンス識別子および／または状態情報は、クライアントクラスタ化されたネットワーク中のセントラルロケーションまたはレポジトリに格納することができる。そのような実施形態では、フェイルオーバプロセスは、第２のクライアントに要求元のアプリケーションインスタンス識別子および／または状態情報のロケーションを提供することができる。また別の実施形態では、要求元は、そのアプリケーションインスタンス識別子を維持することができる。そのような実施形態では、クライアントのフェイルオーバ操作は、移転する、または要求元と第２のクライアントの間の接続を確立するステップを含むことができる。
【００４８】
[0051]実施形態では、クライアントのフェイルオーバ操作の後、フローは、操作３１０に続く。操作３１０で、同じリソースに関する第２の要求が、クラスタ化環境に送られる。実施形態では、第２の要求は、要求元の代わりにクライアントクラスタ中の第２のクライアントによって送られる。第２の要求は、操作３０２で第１のリソースに関して述べたのと同じ方法を使用して送ることができる。リソースに対する継続したアクセスを維持し、不当な遅延を避けるためには、フローは、操作３１２に続き、そこでは、アプリケーションインスタンス識別子が、クラスタ化環境に再び送られる。アプリケーションインスタンス識別子は、操作３０８で、操作３０４に関して述べた実施形態の１つによって送ることができる。実施形態では、異なるクライアント（たとえば第２のクライアント）が第２の要求を送ることになり、要求を受け取るサーバは、第２の要求を、リソースに対してロックを保持する同じ要求元に属するものとして識別することができない可能性がある（たとえば、要求が異なるマシン、異なるアドレスなどからなされるからである）。しかし、操作３０４および３０８でアプリケーションインスタンス識別子を送ることによって、サーバは、要求を同じ要求元に属するものとして識別することができるようになり、図１および図２に関して既に述べたように、リソースへの継続したアクセスを認めることになる。フローは、操作３１４に続き、要求元は、リソースへのアクセスを取り戻す。実施形態では、第２のクライアントは、サーバが第２の要求を認めたことを示す、サーバからの第２の要求に対する応答を受け取ることができる。実施形態では、その指示を受け取ったとき、第２のクライアントは、要求元の代わりにリソースにアクセスすることができる。
【００４９】
[0052]図４は、リソースに対する継続したアクセスをもたらすために、サーバクラスタ化環境中のノードによって実施される方法４００の実施形態を示すフローチャートである。方法４００の実施形態は、ノード、たとえば、クラスタ化環境、たとえばノードクラスタ２０６（図２）中のノード１  ２０８（図２）によって実施することができる。実施形態では、方法４００は、ノードに対してアクセスを有するノードによって実施することができる。フローは、操作４０２で開始され、そこでは、ノードが、リソースに関する要求を受け取る。実施形態では、リソースは、ファイル、オブジェクト、方法、データ、または操作４００を実施するノードの制御下にある、および／またはそれがアクセスすることができる、いずれもの他のタイプのリソースとすることができる。アプリケーションインスタンス識別子は、操作４０２で、要求とともに受け取ることができる。
【００５０】
[0053]フローは、決定操作４０４に続き、そこでは、リソースが囲われた、またはロックされた状態にあるのかどうかについての決定がなされる。当業者は、リソースが囲われている、またはロックされているのかどうかを決定するいずれもの方法を操作４０４で用いることができることを認識するはずである。リソースが囲われていない、またはロックされていない状態にある場合、フローは、ＮＯで操作４１２に分岐し、そこでは、リソースに関する要求が認められる。実施形態では、要求を認めるステップは、リソースに対する要求元のアクセスを可能にするステップ、要求元の代わりにリソースに対する操作を実施するステップ、またはリソースに対するいずれもの種類のアクセスまたは変更を実施するステップを含むことができる。たとえば、操作４１２で要求を認めるステップは、ファイルをオープンするステップ、またはファイルを生成するステップを含むことができる。
【００５１】
[0054]リソースが囲われた、またはロックされた状態にある場合、フローは、ＹＥＳで操作４０４から決定操作４０６に分岐する。決定操作４０６で、操作４０２で要求とともに受け取られたアプリケーションインスタンス識別子は、リソースと関連付けられるアプリケーションインスタンス識別子と比較される。たとえば、図２に関して述べたように、ノードは、クライアントまたはアプリケーションがリソースにアクセスしたとき、アプリケーションインスタンス識別子をリソースと関連付けることができる。前に述べたように、リソースにアクセスしている要求元のアプリケーションインスタンス識別子の関連付けは、図２で議論した様々な実施形態で述べたように、ノード上に、たとえばアプリインスタンスキャッシュ中に格納することができる。実施形態では、リソースに関する要求とともに送られたＥＣＰ中で、たとえば_NETWORK_APP_INSTANCE_ECP_CONTEXT構造中で提供されるアプリケーションインスタンス識別子は、リソースと関連付けられるＥＣＰリストに加えることができる。
【００５２】
[0055]一実施形態では、アプリケーションインスタンスリソースの関連付けは、方法４００を実施するノード上でローカルに常駐することができる。そのような事例では、サーバ上に常駐するローカルのアプリインスタンスキャッシュで比較を行うことができる。しかし、図２に関して議論したように、クラスタ化環境は、異なるノードにわたって分散されるいくつかのアプリインスタンスキャッシュを含むことができる。さらにまた、異なるアプリケーションインスタンスキャッシュは、それぞれが別々の、および／または異なるデータを格納することができる。囲われた、またはロックされたリソースと関連付けられるアプリケーション識別子は、クラスタ化環境中の異なるノード上に格納することができる。そのような事例では、操作４０６は、操作４０６で比較を実施するために、要求を異なるノードに送るステップを含むことができる。要求は、操作４０２で受け取られたアプリケーションインスタンス識別子を含むことができる。
【００５３】
[0056]受け取られたアプリケーションインスタンス識別子が、リソースと関連付けられるアプリケーションインスタンス識別子と同じでない場合、フローは、ＮＯで操作４１０に分岐する。操作４１０で、操作４０２で受け取られたリソースにアクセスすることを求める要求が拒否される。実施形態では、要求は、リソースコンフリクトを避けるために、拒否することができる。受け取られたアプリケーション識別子が、関連付けられたアプリケーションインスタンス識別子と同じものでないので、操作４０２で受け取られたリソースにアクセスすることを求める要求は、異なる要求元またはアプリケーションからのものである。異なるクライアントまたはアプリケーションに対して要求を認めるステップは、この場合恐らくそうであるように、リソースに現在、アクセスしているアプリケーションを妨げることになるコンフリクト状況を生じる恐れがある。たとえば、異なるアプリケーションは、現在、リソースに対するロックを保持する要求元がリソースに対して実施している操作を変更する、またはそうでなければ、それを妨げるように、リソースを変更する可能性がある。
【００５４】
[0057]しかし、囲われた、またはロックされたリソースと関連付けられるアプリケーション識別子と同じものであるアプリケーション識別子を要求４０２とともに受け取るステップは、エラーが生じた可能性があり、そのエラーによって、リソースにアクセスしている要求元が、リソースを適切に解放せずに、リソースに対するそのアクセスを失うことになることを示す。たとえば、要求元は、クライアントノードクラスタ中で動作することがある。要求元がその上で動作している特定のクライアントは、サーバへの接続を失ってしまう、またはそうでなければ、要求元がリソースに対するその操作を完了する前に、失敗してしまう恐れがある。リソースに対する継続したアクセスをもたらすために、すなわち不当な、または受け入れられない遅延を被ることなく、要求元がリソースに対するアクセスを再取得するために、フローは、ＹＥＳで操作４０８に分岐する。
【００５５】
[0058]操作４０８で、リソースはその使用が無効にされる。前に本明細書で述べたように、リソースの使用を無効にするステップは、リソースの囲われた状態を変える、またはそうでなければ、リソースに対するロックを除去するステップを含むことができる。たとえば、リソースがファイルである場合、リソースの使用を無効にするステップは、ファイルをクローズするステップを含むことができる。当業者は、囲われた、またはロックされたリソースを解放するいずれもの方法を操作４０８で用いることができることを認識するはずである。
【００５６】
[0059]図２に戻って参照すると、実施形態では、リソースに対するアクセスは、操作４０２でリソースへのアクセスを求める要求を受け取るノードと異なる、クラスタ化環境中のノードの制御下にある可能性がある。たとえば、リソースに対するハンドルが、クラスタ化環境中の異なるノード上に常駐する可能性がある。そのような実施形態では、リソースの使用を無効にするステップは、リソースに対するアクセスを制御するノードに、リソースの使用を無効にするように求める要求を送るステップを含むことができる。要求を送るステップに応答して、遠隔ノードは、リソースの使用を無効にすることができる。
【００５７】
[0060]リソースの使用が無効にされた後、フローは、操作４１２に続き、そこでは、リソースにアクセスすることを求める要求が認められる。要求を認めるステップは、リソースに対する要求元のアクセスを可能にするステップ、要求元の代わりにリソースに対する操作を実施するステップ、またはリソースに対するいずれもの種類のアクセスまたは変更を許可するステップを含むことができる。たとえば、操作４１２で要求を認めるステップは、ファイルをオープンするステップまたはファイルを生成するステップを含むことができる。そのようなアクセスを認めるステップは、操作４０２で要求を受け取るノードによって、またはクラスタ化環境中の別のノードによって実施することができる。
【００５８】
[0061]方法３００および４００は、操作フローの単なるいくつかの例であり、それは、実施形態によって実施することができる。実施形態は、図３〜図６に関して上記に提示した具体的な記述に限定されず、実施形態は、追加の操作を含むことができる。さらに、描いた操作ステップは、他のステップ中に結合する、および／または再配置することができる。さらに、より少ない、または追加のステップを、図３〜図４で述べた方法とともに使用する、採用することができる。
【００５９】
[0062]図５は、汎用コンピュータシステム５００を例示し、それは、本明細書に述べた実施形態を実施するために使用することができる。コンピュータシステム５００は、計算環境の本の一例にすぎず、コンピュータおよびネットワークのアーキテクチャの使用または機能性の範囲に関するいかなる限定も示唆する意図はない。コンピュータシステム５００は、例示的なコンピュータシステム５００で例示した構成要素のいずれもの１つ、またはその組合せに対していずれもの依存性または要件を有するものとして解釈すべきでない。実施形態では、システム５００は、図１および図２に関して上記で述べたクライアントおよび／またはサーバとして使用することができる。
【００６０】
[0063]システム５００は、そのもっとも基本的な構成では、通常、少なくとも１つの処理ユニット５０２およびメモリ５０４を含む。計算装置の正確な構成およびタイプに依存して、メモリ５０４は、揮発性のもの（ＲＡＭなど）、不揮発性のもの（ＲＯＭ、フラッシュメモリなど）または何らかの組合せとすることができる。このもっとも基本的な構成は、図５に破線５０６によって例示する。システムメモリ５０４は、本明細書に開示した継続する可用性のための方法を実施する命令などの命令５２０および記憶装置５０８などの記憶装置を備えるファイル記憶システム中に格納することができるアプリケーションインスタンス識別子などのデータ５２２を格納する。
【００６１】
[0064]用語「コンピュータ可読媒体」は、本明細書で使用する際、コンピュータ記憶媒体を含むことができる。コンピュータ記憶媒体は、情報、たとえばコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを記憶するために、いずれもの方法または技術で実現される揮発性および不揮発性の、取外し可能な、および取外しができない媒体を含むことができる。システムメモリ５０４、取外し可能な記憶装置および取外しができない記憶装置５０８は、すべてコンピュータ記憶媒体の例である（たとえばメモリ記憶装置）。コンピュータ記憶媒体は、ただしこれらに限定されないが、ＲＡＭ、ＲＯＭ、電気的消去可能なリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは情報を格納するために使用することができ、計算装置５００がそれにアクセスすることができる、いずれもの他の媒体を含むことができる。いずれものそのようなコンピュータ記憶媒体は、装置５００の一部とすることができる。計算装置５００は、また、入力装置（複数可）５１４、たとえばキーボード、マウス、ペン、音声入力装置、タッチ入力装置などを有することができる。出力装置（複数可）５１６、たとえばディスプレイ、スピーカ、プリンタなどもまた、含めることができる。前述の装置は、例であり、他のものも使用することができる。
【００６２】
[0065]また、用語「コンピュータ可読媒体」は、本明細書で使用する際、通信媒体を含むことができる。通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波または他の転送機構など、変調されたデータ信号（modulated data signal）の形の他のデータによって具体化することができ、いずれもの情報配信媒体を含む。用語「変調されたデータ信号」は、１つまたは複数の特性が、その信号中で情報をエンコードするように設定される、または変化させられる信号を記述することができる。例としてだけで限定するものでなく、通信媒体は、ワイヤードネットワークまたは直接配線の接続などのワイヤード媒体、ならびに音響、無線周波（ＲＦ）、赤外線などのワイヤレス媒体、および他のワイヤレス媒体を含むことができる。
【００６３】
[0066]本発明の実施形態は、システムオンチップ（ＳＯＣ）を介して実施することができ、そこでは図５に例示した構成要素のそれぞれまたはその多くを、単一の集積回路上に集積することができる。そのようなＳＯＣ装置は、１つまたは複数の処理ユニット、グラフィックユニット、通信ユニット、システム仮想化ユニットおよび様々なアプリケーション機能性を含むことができ、そのすべては、チップ基板上に単一の集積回路として集積（または「焼き付ける（burned）」）される。ＳＯＣを介して動作するとき、リソースに対する継続したアクセスをもたらすことに関して本明細書に述べる機能性は、単一の集積回路（チップ）上の計算装置／システム５００の他の構成要素とともに集積されるアプリケーション特有のロジックを介して動作することができる。
【００６４】
[0067]本明細書の至るところで、具体的に述べる特徴、構造または特性が少なくとも一実施形態に含まれていることを意味する「一実施形態（one embodiment）」または「ある実施形態（an embodiment）」を参照してきた。それゆえ、そのような語句の使用法は、１つだけより多くの実施形態を言及していることがある。さらにまた、述べる特徴、構造または特性は、いずれもの適切な形で１つまたは複数の実施形態に結合することができる。
【００６５】
[0068]しかし、当業者は、具体的な細部の１つまたは複数が無くても、または他の方法、リソース、マテリアルなどを用いて実施形態を実施することができることを認められるはずである。他の事例では、よく知られた構造、リソース、または操作は、単に実施形態の態様を分かりにくくすることを避けるために、詳細に示していない、または述べていない。
【００６６】
[0069]例の実施形態およびアプリケーションを例示し述べてきたが、実施形態は、上記に述べた正確な構成およびリソースに限定されないことを理解すべきである。請求する実施形態の範囲から逸脱せずに、当業者に明らかな様々な修正、変更および変形は、本明細書に開示した方法およびシステムの構成、操作および細部において行うことができる。
【図１】
2014529141.tif 000003
【図２】
2014529141.tif 000004
【図３】
2014529141.tif 000005
【図４】
2014529141.tif 000006
【図５】
2014529141.tif 000007
【国際調査報告】
2014529141.tif 000008
2014529141.tif 000009