コネクションを再開することを促進するためにファイルシステム状態情報を捕捉する、コンピューターによって実装される方法であって、サーバー上に格納されたリモートリソースへのアクセス要求をクライアントから受信するステップと、前記要求に関連したクライアントセッションを特定する識別子を決定するステップと、前記クライアントによって要求された動作によって作成された状態情報と前記引き出された識別子とを関連付ける、前記引き出された識別子によって検索可能なレジュームレコードを作成するステップと、前記サーバーを通じてアクセス可能なファイルに対してアクセスを要求をするファイル動作を前記クライアントから受信するステップと、前記クライアントが前記サーバーとのそのコネクションを失った場合、前記受信されたファイル動作を再開するための情報を提供するレジューム状態情報を、前記作成されたレジュームレコードに格納するステップと、前記要求されたファイル動作を実行するステップと、前記実行されたファイル動作の結果に基づいて、前記作成されたレジュームレコードにおける前記格納されたレジューム状態情報を更新するステップと、前記要求されたファイル動作の前記結果を示す応答をクライアントに対して送信するステップとを備え、上記ステップは少なくとも一つのプロセッサによって実行されることを特徴とする方法。請求項1に記載の方法であって、前記アクセス要求は、コネクションが障害を起こした場合、複数の潜在的なコネクションにわたって前記クライアントセッションを特定するレジュームキーを含む一つまたは複数のパラメータを含み、および前記レジュームキーは少なくとも前記決定された識別子の一部であることを特徴とする方法。請求項1に記載の方法であって、前記クライアントが前記サーバーから切断されると、複数のクライアントコネクション間のサーバーによって管理される相互に関連している状態情報によって、コネクション障害の後に前記フェイルオーバーサーバーが前記クライアントにより速く応答するのに役立たせるために、前記サーバーは前記元のアクセス要求と相互に関連することができる新しいアクセス要求をフェイルオーバーサーバーで受信するステップをさらに備えたことを特徴とする方法。請求項1に記載の方法であって、ネットワークファイルシステムNFSサーバーは、前記クライアントからレジュームキーを受信することなく前記識別子を自動的に決定することを特徴とする方法。請求項1に記載の方法であって、前記引き出された識別子は、前記クライアントが、切断されたセッションを再開することを可能とする永続的なハンドルのために提供する、サーバーメッセージブロックSMBレジュームキーであることを特徴とする方法。請求項1に記載の方法であって、前記レジュームレコードを作成するステップは、前記サーバーが障害を起こした場合、別のサーバーが前記クライアントからの何れの動作を再開するために前記記録を読み取りおよび元のサーバーの代わりに作動することができるように、前記レジュームレコードを前記現在のアクセス要求をハンドリングするサーバーの外部の位置で格納するステップを備えたことを特徴とする方法。請求項1に記載の方法であって、前記ファイル動作を受信するステップは、ファイルを開く、ファイルを閉じる、ファイルを読み取る、ファイルを書き込む、ファイル上のリースを得る、およびファイル上のロックを得る、から成り立つグループから選択された動作を実行することの要求を備えたことを特徴とする方法。請求項1に記載の方法であって、前記クライアントが前記サーバーから切断されると、前記クライアントが前記フェイルオーバーサーバーに接続しおよび何れの以前の動作を継続することができるようにフェイルオーバーサーバーに前記格納されたレジュームレコードをロードするステップをさらに備えたことを特徴とする方法。請求項1に記載の方法であって、前記要求されたファイル動作を実行するステップは、前記サーバーによって格納された状態を修正し、および前記格納されたレジューム状態情報を更新するステップは、前記修正された状態を捕捉することを特徴とする方法。請求項1に記載の方法であって、前記格納されたレジューム状態情報を更新するステップは、前記クライアントが前記状態情報の少なくとも一部を再度確立することを要求することなく、別なサーバーが前記状態を再度確立しおよびクライアントの要求を前記元のサーバーの代わりにハンドルすることを可能とする、前記レジュームレコードにおける前記サーバー状態の最新のビューを保つステップを備えたことを特徴とする方法。ファイルシステムにおける透過的なフェイルオーバーをクライアントに提供するコンピューターシステムであって、各々のファイルハンドルのための状態記録を作成しおよび前記ファイルハンドルを使用してクライアント要求動作としての状態情報を収集する状態収集コンポーネントと、前記クライアントによって提供されるセッション識別子に関連して収集される状態情報を格納する状態格納コンポーネントと、再開するサーバーが、障害中のサーバーによって格納された状態情報を再度作成するために使用する、ファイルシステム状態情報を持続的に格納する状態データストアと、障害中のサーバーが利用不可能となる条件を検知し、および再開するサーバーに対して障害中のサーバーの代わりに作動するように通知するレジューム検知コンポーネントと、前記再開するサーバーに対してアクセス可能な位置から格納された状態情報を取り出す状態取り出しコンポーネントであって、前記状態情報は、前記再開するサーバーが、何れの以前に要求され、前記検知された障害条件によって中断されたファイルシステム動作を再開することを可能とすることと、前記取り出された状態情報を前記再開するサーバーにロードし、前記再開するサーバーが前記クライアントによって以前に要求された動作を継続することができる状態リストアコンポーネントとにより、具現化されるソフトウェア命令を実行するように構成されたプロセッサおよびメモリとを備えたことを特徴とするシステム。請求項11に記載のシステムであって、前記状態収集コンポーネントはさらに、サーバーで動作しおよび前記サーバーの外部に前記状態情報を格納することができ、故に前記サーバーが利用不可能な場合でも前記状態情報はアクセスされることができるように構成されたことを特徴とするシステム。請求項11に記載のシステムであって、前記状態収集コンポーネントはさらに、前記クライアントが前記サーバーに対して接続する時に、前記クライアントからレジュームキーを受信することができ、そして収集された前記状態情報と前記状態データストアにおける前記レジュームキーとを関連付けるように構成されたことを特徴とするシステム。請求項11に記載のシステムであって、前記状態データストアは、前記クライアントに対して異なるコネクションを使用する前記障害中のサーバーと同じサーバーである、再開するサーバーのための情報を格納および提供することを特徴とするシステム。請求項11に記載のシステムであって、前記状態データストアは、前記障害中のサーバーが動作を実行していると、前記状態情報を受信し、そして、障害が発生すると、状態を再開しおよび完了しなかった何れの動作を実行することを継続するために、前記再開するサーバーに対して、前記以前に受信した状態情報へのアクセスを提供することを特徴とするシステム。本明細書で説明されるコネクション状態システムは、レジュームキーに関連したクライアントの状態情報をリモートに格納することによって、クライアントがサーバーまたは異なる代替サーバーとのコネクションを再開することを可能とする。当該システムは、サーバーで動作し変わりやすいサーバー状態情報の格納を促進するレジュームキーフィルタを提供する。当該状態情報はオポチュニスティックロック、クライアントに対して保証されたリース、およびファイルハンドル上のインフライト動作等を含むことができる。レジュームキーフィルタドライバはファイルシステム上に存在するが、レジュームキーフィルタドライバによって複数ファイルアクセスプロトコルが当該フィルタを使用することを可能し、並びに当該フィルタがこの機能性を複数ファイルシステムにわたって提供することを可能とする。システムは、実際のプロトコルとは別個にプロトコルに対する状態情報を提供する。サーバーがダウンするかまたはクライアントとの接続を失う等のフェイルオーバーイベントが発生すると、システムは別のサーバーまたは同じサーバーを割り当てることができ例として、冗長化されたイーサネット登録商標コネクション等の異なるコネクションを介して、そして様々なクライアントによって保持されるファイルハンドルのためにレジュームキーフィルタを使用して状態を再度確立する。当該フィルタは、動作中のファイル状態が一貫してリストアされることができ、およびその他のクライアントがその間にファイルにアクセスするために介在しないことを保証するフェイルオーバーの後で、動作中のファイル上にブラックアウトウインドウを強制的に出力する。再開フェーズにおいては、レジュームキーは、既存のフェイルオーバー以前のファイルハンドルを、レジュームキーフィルタによって格納されたフェイルオーバー後に保存されたファイル状態へマッピングするために使用される。このように、コネクション状態システムによって、同じまたは別のサーバーがフェイルオーバーイベント後クライアントに対して可能な限り中断することなく、クライアントとの以前のセッション状態を再開することができる。システムは、サーバーがクライアントに対する自身のコネクションを失った後で、透過的なフェイルオーバーのために使用されることができるレジュームキーフィルタを提供する。レジュームキーフィルタはファイルシステムの最上位に存在し、および従ってファイルシステムに対してアクセスするために使用されるプロトコルとは独立している。レジュームキーフィルタは動作中のファイル状態を記録し、そして次いでフェイルオーバー後に動作中のファイル状態をリストアする。レジュームキーフィルタは様々な状態情報を捕捉することができる。例えば、当該フィルタはオープンハンドルレジュームキーによって静的に参照された、確定していないファイル状態クローズ時の削除、保留中の削除およびロック状態等、ならびにある特定のインフライト/中断されたファイル動作を備える動作中のファイルシステム状態を記録する。当該フィルタは、フェイルオーバー後に動作中のファイルシステム状態をリストアして、オープンハンドルが再開され、フェイルオーバー以前のオープンハンドルに整合させ、そしてインフライト動作は一貫して再び行われることができる。フェイルオーバー以前のオープンハンドルに整合させるために、オープンハンドルが再開されるようにフェイルオーバー後に動作中のファイルシステム状態をリストアし、そしてインフライト動作は一貫して再び行われることができる。当該フィルタは複数のリモートファイルシステムRFSのための手段を提供し、レジュームキーを通じて参照されるオープンファイルハンドルに関連付けられたプライベートな不透明データを格納しおよび取り出す。当該フィルタは、動作中のファイル状態が一貫してリストアされることができ、およびその他のクライアントがその間にファイルにアクセスするために介在しないことを保証する、フェイルオーバーの後で、動作中のファイルの上にブラックアウトウインドウを強制的に出力する。また、当該フィルタによって、現在動作中のファイルが一時停止され、そして次いでノードがフェイルオーバーするクラスタシナリオにおいてSMBをサポートするためにフェイルオーバーなしで再開される。リモートファイルシステムRFSは、作成中の剰余のパラメータとして全てのファイル作成動作についてレジュームキーを提供する。当該キーはRFSに対して固有のものである。レジュームキーフィルタは、レジュームキーおよびRFS識別キーをファイルハンドルのためにGUIDとして一緒に使用する。再開フェーズにおいては、レジュームキーは、既存のフェイルオーバー以前のファイルハンドルを、レジュームキーフィルタによって格納されたフェイルオーバー後に保存されたファイル状態へマッピングするために使用される。このように、コネクション状態システムによって、同じまたは別のサーバーがフェイルオーバーイベント後クライアントに対して可能な限り中断することなく、クライアントとの以前のセッション状態を再開することができる。図1は本発明の一実施形態にかかる、コネクション状態システムのコンポーネントを図示するブロック構成図である。システム100は状態収集コンポーネント110、状態格納コンポーネント120、状態データストア130、レジューム検知コンポーネント140、状態取り出しコンポーネント150、状態リストアコンポーネント160、ブラックアウト施行コンポーネント170、およびリソースサスペンションコンポーネント180を含む。これらのコンポーネント各々は、本明細書においてさらに詳細に説明される。状態収集コンポーネント110は、各々のファイルハンドルのための状態記録を作成しおよびファイルハンドルを使用するクライアント要求動作としての状態情報を収集する。コンポーネント110は、サーバーで動作しおよびサーバーの外部に状態情報を格納することができ、故にサーバーが利用不可能な場合でも状態情報はアクセスされることができる。例えば、コンポーネント110は、本明細書においてさらに説明される状態データストア130に状態情報を格納することができる。状態収集コンポーネント110は、クライアントがサーバーに対して接続する時に、クライアントからレジュームキーを受信することができ、そして当該コンポーネント110は収集された状態情報と状態データストア130におけるレジュームキーとを関連付ける。クライアントがフェイルオーバーイベント後に再度接続をしている場合、当該クライアントは最初のコネクションを開くために使用されたものと同じレジュームキーを提供し、ならびに現在のサーバーは以前のサーバーによって格納された状態情報を見つけおよび状態情報からサーバー状態を再度作成することができる。状態格納コンポーネント120は、収集される状態情報をクライアントによって提供されるレジュームキーに関連して格納する。コンポーネント120は、状態情報を状態データストア130に格納し、およびフェイルオーバーイベントの場合にはリストアされるであろうレジュームキーに関連する動作の記録を保管する。状態情報は、オープンファイルハンドル、オポチュニスティックロック保証、リースおよびリース情報、進行中のファイル動作、バイト範囲のロック、ならびにクライアントが以前の状態の全てを再度確立することなく、別のサーバーがクライアントの要求を実行するために使用するであろう、その他何れの情報を含むことができる。状態データストア130は、再開するサーバーが、障害中のサーバーによって格納された状態情報を再度作成するために使用する、ファイルシステム状態情報を持続的に格納する。ある場合において、再開するサーバーおよび障害中のサーバーは、クライアントに対して異なるコネクションを使用しまたは短時間の停止の後に復帰する同じサーバーであることができる。その他の場合において、再開するサーバーおよび障害中のサーバーは、異なるサーバーであり、および状態データストア130は状態情報を共有するために双方のサーバーに対してアクセス可能な位置に提供される。状態データストア130は、一つまたは複数のファイル、ファイルシステム、ハードドライブ、データベース、ストレージエリアネットワークSAN、クラウドベースのストレージサービス、またはデータを持続的に格納しならびに情報を交換するために、障害中および再開するサーバー双方に対してアクセス可能とするその他ストレージ機能を含むことができる。障害中のサーバーが動作を実行していると、動作の進行についての状態情報を状態データストア130に格納する。障害が発生すると、障害中のサーバーは中断され、そして再開するサーバーは、当該状態情報にアクセスして、状態を再開しおよび完了しなかった何れの動作を実行することを継続する。レジューム検知コンポーネント140は、障害中のサーバーが利用不可能となる条件を検知し、および再開するサーバーに対して障害中のサーバーの代わりに作動するように通知する。当該検知をクライアント駆動型とすることができ、クライアントがシステムに再度接続しおよび以前に使用されたレジュームキーを提供するまでは、システムは何れの再開するステップを実行しないようにする。システムはキーおよび当該キーに関連して格納された何れの状態情報を特定し、ならびにコネクションの設定の一部としてその状態情報をリストアする。再開するサーバーは、同じまたは障害中のサーバーとは異なるサーバーであることができ、およびレジューム検知コンポーネント140は、クライアントの要求をハンドルするために再開するサーバーが動作中となることを確実に行う。その他の実施形態において、当該検知は、サーバー駆動型であることができ、および障害中のサーバーがダウンしたことを検知するとシステムは率先して再開するサーバーを起動することができる。システムはまた、クライアントがサーバーに対してコネクションを要求する前であっても、格納された状態情報に再開するサーバーを予め指定することができる。状態取り出しコンポーネント150は、再開するサーバーに対してアクセス可能な位置から格納された状態情報を取り出すが、当該状態情報によって、再開するサーバーは、検知された障害条件によって中断された、以前に要求された何れのファイルシステム動作を再開することができる。状態取り出しコンポーネント150は、状態情報を状態データストア130から取り出し、および状態リストアコンポーネント160を呼び出し、再開するサーバーに情報をロードすることにより、再開するサーバーがクライアントによって要求された動作を継続することができる。状態リストアコンポーネント160は、取り出された状態情報を再開するサーバーにロードし、再開するサーバーがクライアントによって以前に要求された動作を継続することができる。当該リストアはまた、何れのオプロックおよび/またはクライアントによって保持されたリースを最新の情報に更新することを含むことができ、その他のクライアントが以前に要求されたアクセスレベルおよび/またはクライアントに対して認められた排他性を遵守することを確実に行うことができる。状態リストアコンポーネント160によって、新たなサーバーまたはノードは、クライアントへの重い負荷をかけることなく、障害中のサーバーまたはノードに代わって、過去の動作を繰り返すことによって状態情報をリストアすることができる。SMB2.0のようなプロトコルを使用しているクライアントは、同じサーバーに対してコネクションをリストアするためのレジュームキーの使用方法を既に備えており、およびコネクション状態システムによって代替サーバーはクライアントに対して透過的に障害中のサーバーに代わることができる。レジュームキーはまた、NFSと共に使用されることができる。NFSの場合において、レジュームキーの概念は、クライアントに対して完全に不透明である。クライアントは、レジュームキー生成、管理、および関連付けに明示的に参照または参加をしない。むしろ、レジュームキーはサーバー側の概念である。ブラックアウト施行コンポーネント170は、一つまたは複数のファイルあるいはその他のリソースに対するアクセス時に、二番目のクライアントが、再開するサーバーに対してコネクションを再開する最初のクライアントと競合するであろう方法でリソースへ干渉することを防止するブラックアウト期間を施行する。コンポーネント170は、大多数の競合動作を避けるのに充分な長さ例として、15または30秒ではあるが、最初のクライアントがコネクションを再開しない場合はその他のクライアントがリソースへアクセスをすることを防止する程の長さではないと認められる期間を、自動的に選択することができる。最初のクライアントが選ぶ場合、当該期間によって、最初のクライアントがコネクションを再開するための時間を持つことができる。ある実施形態において、システムによって、管理者またはユーザがブラックアウト期間の存続期間を構成し、アプリケーション特有の目的のためにシステムを調整することができる。また、システムによって、個々のクライアントが、作成/オープン要求に対するパラメータまたはその他APIとしてのブラックアウト期間を要求することができる。ブラックアウトされたリソースへのアクセス試行に応答して、コンポーネント170は特定の期間の後に再試行する指示を提供することができ、または単純に要求を失敗とすることができる。ブラックアウト期間の後に、コネクションを再開したクライアントが無い場合、ブラックアウトが終了し、そしてリソースへのアクセス要求は通常通りに成功する。リソースサスペンションコンポーネント180により、現在動作中のリソースがフェイルオーバーイベントなしで一時停止および再開され、クラスタが計画された態様において別のノードへフェイルオーバーすることができる。一例は負荷分散処理である。一時停止することにより、新しいノードに移行されつつある状態のサブセットのシナリオを可能とする。例えば、クラスタにおける一つのノードがオーバーロードの場合、管理者は当該ノードの半分のクライアントを、新しいノードに移行したいかもしれない。一時停止することにより、移行されつつあるオープン状態を捕捉することを可能とし、および同じオープンの継続として、クライアントが新しいノードに接続することを可能とする例として、サーバー状態を再度確立することなく。別の例として、SMBは、一般的なノードがクラスタ化され、および交互にクライアント要求へのサービスを行うために使用されることができる、クラスタリングシナリオをサポートする。時々、メンテナンス目的のように、特定のノードをダウンさせる理由があるが、および現在のノードが正常に一時停止し、新しいノードが作動し、古いノードを作動停止し、そして次いで作動停止されたノード上で、何れのメンテナンス動作を実行するのが望ましい。これはクライアントに望ましくない影響を有する可能性があるが、本明細書において説明される技術を使用して、システム100は組織化された態様においてノードを一時停止することができ、およびクライアントが新しいノードとの動作を効率的に再開することができる。コネクション状態システムが実装されるコンピューティング装置は、CPU、メモリ、入力装置例として、キーボードおよびポインティング装置、出力装置例として、ディスプレイ装置、およびストレージ装置例、ディスクドライブまたはその他不揮発性ストレージ媒体を含むことができる。メモリおよびストレージ装置は、システムを実装または作動させるコンピューターが実行可能な命令例として、ソフトウェアとしてエンコード可能な、コンピューターが読み取り可能なストレージ媒体である。加えて、データ構造およびメッセージ構造は、通信リンクの信号のようにデータ送信媒体を経由して格納されまたは送信され得る。通信リンクは、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、ポイントトゥーポイントダイアルアップコネクション、携帯電話ネットワーク等のように様々な通信リンクを使用することができる。システムの実施形態は、様々な動作環境において実装することができる。当該動作環境は、パーソナルコンピューター、サーバーコンピューター、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な家電、デジタルカメラ、ネットワークPC、マイクロコンピューター、メインフレームコンピューター、上記システムあるいは装置、セットトップボックス、SOC等々の、何れを含む分散コンピューティング環境を含む。コンピューターシステムは携帯電話、PDA、スマートフォン、パーソナルコンピューター、プログラム可能な家電製品、デジタルカメラ、等々であることができる。システムは、一つまたは複数のコンピューターあるいはその他の装置によって実行されるプログラムモジュール等の、コンピューターが実行可能な命令の一般的なコンテキストで説明されることができる。一般的に、プログラムモジュールは、特定のタスクを実行または特定の抽象的なデータタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等々を含む。典型的に、プログラムモジュールの機能は、様々な実施形態において所望の態様で集約されまたは分散されることができる。図2は本発明の一実施形態にかかる、ファイルシステム状態情報を捕捉するためのコネクション状態システムの処理を図示するフローチャートである。まずブロック210において、システムはサーバー上に格納されたリモートリソースに対するアクセス要求を受信する。アクセス要求は一つまたは複数のパラメータを含むことができるが、当該パラメータはコネクションが失敗した場合に、複数の潜在的なコネクションの中からセッションを特定するために使用されるレジュームキーを含んでいる。リソースアクセス要求は、クライアントから送信された一連のアクセス要求における最初となることができ、およびクライアントがサーバーからこれまでに切断された場合、クライアントは、続いて発生するオープン要求において、同じまたは新しいサーバーに対して同じレジュームキーを提供して、コネクションを再開することができる。レジュームキーは、サーバーによってまたはサーバー間にわたって、管理される状態情報を、独立したクライアントコネクションとして見える別なものと、相互に関連させることにより、サーバーがクライアントに対してより速く応答することに役立つ。続いてブロック220において、システムは要求に関連したクライアントセッションを特定する識別子を決定する。ある場合における識別子は、クライアントが様々な理由により切断されたセッションを再開することを可能とする、永続的なハンドルのために提供するレジュームキーである。アクセス要求は、プロトコルにおけるはっきりと定義された位置で一つまたは複数のパラメータを含むことができ、故にシステムは要求における適切な位置を読み取ることにより当該キーを引き出すことができる。あるいはまたもしくはそのうえ、サーバーは、クライアントによって明白に提供された情報を含まない、識別子を決定するための自動化された処理を含むことができる。例えば、サーバーは、IPアドレス、またはクライアントコネクションが以前のセッションと相互に関連することを、サーバーに対して示すその他推測されるデータによって、クライアントを特定することができる。続いてブロック230において、システムは、クライアントによって要求された動作によって作成された状態情報と、引き出された識別子とを関連付ける、引き出された識別子によって検索可能なレジュームレコードを作成する。レジュームレコードは、現在のアクセスする要求をハンドリングしているサーバーの外部の位置で格納されることができ、サーバーが障害を起こした場合、別のサーバーが動作を再開するための記録を読み取りおよび元のサーバーの代わりに作動することができる。レジュームレコードはファイル、データベースレコード、またはその他ストレージの形式を含むことができる。当該レコードは、オープンファイルハンドルのリスト、クライアントによって得られるオプロック、リース、またはその他ファイルシステム状態情報を包含することができる。続いてブロック240において、システムは、サーバーを通じてアクセス可能なファイルに対するアクセスを要求する、クライアントからファイル操作を受信する。当該ファイル操作は、ファイルを開き、ファイルを閉じ、ファイルを読み取り、ファイルに書き込み、共有プリンタへの印刷すること、またはその他ファイルシステム操作の要求であることができる。受信された操作は、サーバー上で作成されているある特定の量の状態情報を含むことができる。例えば、クライアントがファイルに対するハンドルを開いた場合、サーバーはファイルに関連したその他クライアントの要求を管理するため、ならびに存続期間および/または当該ハンドルのためのクリーンアッププロセスを管理するためのハンドルを追跡する。続いてブロック250において、システムは、クライアントがサーバーとのそのコネクションを失った場合、受信されるファイル動作を再開するための情報を提供するレジューム状態情報を、作成されたレジュームレコードに格納する。クライアントコネクションが障害を起こした場合、再びリモートリソースを開くことによって、および同じレジュームキーまたはその他セッション識別子を指定することによって、クライアントはコネクションを再開することを試行する。上記により、サーバーまたは別のサーバーが、格納されたレジュームレコードにアクセスし、および以前の状態情報を再度確立することを可能とする。続いてブロック260において、システムは要求されたファイル動作を実行する。当該動作は、ファイルを開き、ファイルのコンテンツを読み取り、ファイルに対してデータを書き込み、ファイルに対するアクセス権限を変更することができ、またはその他何れのファイルシステム動作であることができる。当該動作の結果は、サーバーによって格納される状態を変更することができる。例えば、クライアントがハンドルを閉じることを試行し、およびサーバーがうまくハンドルを閉じる場合、サーバー状態を更新して、サーバーによって追跡されるハンドルのリストからハンドルを削除する。続いてブロック270において、システムは、作成されたレジュームレコードにおける格納されたレジューム状態情報を、実行されたファイル動作の結果に基づいて更新する。システムは、いつフェイルオーバーを引き起こす障害が発生するか事前に知り得ず、そのため、システムはサーバーができるだけ以前のサーバーの状態に忠実に状態を再度確立することを可能とする、レジュームレコードにおけるサーバー状態の最新のビューを保つ。完了しなかった動作は、当該動作を完了するために再び行われることができ、一方で、完了した動作は繰り返される必要がないしかし、サーバーは結果をクライアントに対して再度送信するかもしれない。このように、システムは、サーバー状態情報を変更する様々なファイルシステム動作の間におよび動作の後に必要とされるように、状態を更新する。続いてブロック280において、システムは、要求されるファイル動作の結果を示す応答を、クライアントに対して送信する。クライアントとサーバーが依然として接続されている場合、クライアントによって要求されるように動作が継続し、およびサーバーは、更新された状態情報を追跡することを継続する。コネクションが失われた場合はいつでも、別のサーバーが割り当てられまたは既存のサーバーが修理されることができ、そして状態情報は状態ストアからロードされ、以前のサーバー状態を再度確立することができる。クライアントからセッションを再開するための新しい要求を受信すると、クライアントは、フェイルオーバーが発生したことおよびクライアントが潜在的に元のものとは異なるサーバーと対話していることを、クライアントは認識する必要がない。ブロック280の後に、これらステップは完結する。図3は一実施形態にかかる、フェイルオーバー後にコネクションを再開するためのコネクション状態システムの処理を図示するフローチャートである。まずブロック310において、システムはクライアントからサーバー上に格納されたリモートリソースを開くための要求を受信する。アクセス要求は、コネクションが障害を起こした場合に複数の潜在的なコネクションにわたるセッションを特定するために使用されるレジュームキーを含む、一つまたは複数のパラメータを含むことができる。図2を参照して検討されたリソースアクセス要求とは異なり、当該要求は以前に接続されたセッションに対して再度接続するための要求である。クライアントは、もともと提供されたものと同じレジュームキーを提供し、故にサーバーは現在のセッション要求と以前のセッションとを相互に関連させることができる。続いてブロック320において、システムは要求に関連したクライアントのセッションを特定するセッション識別子を決定する。ある場合における識別子は、クライアントが様々な理由のために切断されたセッションを再開することを可能とする、永続的なハンドルのために提供するSMB2レジュームキーである。アクセス要求は、プロトコルにおけるはっきりと定義された位置で一つまたは複数のパラメータを含むことができ、故にシステムは要求における適切な位置を読み取ることにより当該キーを引き出すことができる。その他の場合において、サーバーはクライアントについての情報に基づいて自動的に識別子を決定することができる。続いてブロック330において、システムは状態ストアにおいて受信されたセッション識別子を検索し、セッション識別子に関連付けられたレジュームレコードを特定する。再開可能なセッションを使用し、クライアントとの対話をする何れの以前のサーバーは、クライアントとの対話を通じて状態情報を継続的に格納する。クライアントがコネクションを再度確立することを試行するとき、状態情報は元のサーバーの代わりとなるフェイルオーバーサーバーに対して利用可能である。状態情報は、元のサーバーの外部に格納され、当該情報が元のサーバーの障害後にアクセス可能になる。続いてブロック340において、システムは状態ストアからレジュームレコードに関連付けられた以前の状態情報を受信する。状態情報は、オープンファイルハンドル、得られたリース、得られたオプロック、等々のような、静的状態、並びに完了していないかもしれないインフライト動作のような動的状態を特定する。格納された状態情報により、フェイルオーバーサーバーが、クライアントよって特定の処理をすることなく元のサーバーの代わりとなることができる。クライアントは、再開可能なハンドルおよびコネクションを再開可能にするステップの実行を理解するが、どのサーバーが何れの特定の時間でコネクションハンドリングを終了することを認識することができない。クライアントは、フェイルオーバーサーバーを含む幾つかのサーバーのうち、何れかひとつのアドレスを解決することができる、ドメインネームまたはネットワークファイル共有を介してサーバーにアクセスすることができる。続いてブロック350において、システムは、ファイルシステム状態を追跡するファイルシステムコンポーネント内に情報をロードすることによって、受信された以前の状態情報をリストアする。当該状態をロードした後に、フェイルーバサーバーのローカル状態は、もし以前の動作の全てがフェイルオーバーサーバー上で発生していた場合に、当該状態が見えていたであろう態様と同じである。このように、フェイルオーバーサーバーは、元のサーバーが障害を起こしていないコネクションを有していたであろうと同じように、クライアントが一連の動作を継続するために有用である。続いてブロック360において、システムは、サーバーがレジュームレコードを見つけたことを示すクライアントアクセス要求、および以前のセッションに関連するクライアント動作を受信する準備ができているという応答を行う。サーバーの応答に基づいて、セッションは再開されたか、またはクライアントは以前の動作を繰り返すステップを取る必要があるかを決定することができる。セッションがうまく再開された場合、クライアントは以前の動作が完了したことを継続して知ることができ、またはサーバーが再開された後に再び行われ、完了する。ある場合において、システムは、クライアントにフェイルオーバー以前のファイルハンドルと同じ状態を有する新しいファイルハンドルを渡すことができる。ブロック360の後に、これらステップは完結する。図4は一実施形態にかかる、コネクション状態システムの動作環境を図示するブロック構成図である。当該環境は、ファイルシステムと対話をする一つまたは複数のオペレーティングシステムサービスまたはアプリケーション含む。例えば、MICROSOFT登録商標WINDOWS登録商標は、SRVとして知られるサーバーサービス420、およびNFSとして知られるネットワークファイルシステムサービス410を含む。ネットワークファイルシステムサービス410およびサーバーサービス420は、コンピューターシステム間の、ファイルおよびプリンタ等の共有されるリソースへのアクセスを提供する。サーバーサービス420は、WINDOWS登録商標ネットワークに対して一般的なSMBプロトコルを使用し、一方でネットワークファイルシステムサービス410は、より一般的にNFSを使用するUNIX登録商標ベースのシステムに対してアクセスを提供する。プロトコルにかかわらず、レジュームキーフィルタ430は、リモートデータストアにおける動作を再び行うための、ファイル動作および状態情報の格納を捕捉する。動作は、ファイルシステムレベル440例として、NTFSまたはその他ファイルシステムを通過して、および一つまたは複数のユーザデータファイル450に作用する。この間、レジュームキーフィルタ430は、状態情報をログファイル460またはその他データストアに対して書き込み、これにより別のサーバーが状態情報を取り出しおよびクライアントに対するコネクションを再開することが出来る。システムは、特定のプロトコルまたは関係するファイルシステムと独立して動作することができ、および様々なコンポーネントは更新され、それらの独自の特定の状態情報を状態データストアにおいて保存することができる。ある実施形態において、コネクション状態システムは、ファイルシステムコンポーネントの代わりにデータの不透明ブロブを格納し、システムが、コンポーネントが特定するナレッジなしにコネクションを再開することを可能とする。例えば、本明細書において説明されるレジュームキーフィルタは、サーバーサービスがその現在の状態を再度作成するために必要とするであろう何れのデータのためのサービスを、サーバーに問い合わせることができる。フィルタは、次いで何れの受信されたデータを不透明ブロブすなわち、フィルタはブロブ内に何があるかまたはそのセマンティックな意味を知る必要はないとして状態ストアに格納することができる。フェイルオーバー条件が発生すると、新しいサーバー上で動作しているレジュームキーフィルタは、格納された状態情報にアクセスし、格納されたブロブを取り出し、そしてサーバーサービスに対して当該ブロブを提供することができ、故にサーバーサービスはその独自の状態をリストアすることができる。このように、当該システムは、サーバーの各々のプロトコルを実装するコンポーネントの内部動作に関する特定のナレッジなしに、多くのタイプのプロトコルで動作することができる。ある実施形態において、コネクション状態システムは、その他のクライアントが一定の時間の間にすなわち、ブラックアウト期間再開可能なハンドルに関連したファイルまたはその他のリソースにアクセスすることをブロックする。ブラックアウト期間中に元のクライアントが再度接続した場合、元のクライアントは以前の状態のすべてがある状態でそのコネクションを取り戻し、そして動作を再開することができる。別のクライアントが接続を試行した場合、サーバーは、一定時間待つことおよびリトライをすることを指示するメッセージを提供することができる。レジュームを認識したクライアントは、この情報を使用して、ブラックアウト期間の後までリトライを送らせることができる一方で、古いクライアントは単にコネクションに失敗しおよびユーザの要求で手作業によるリトライをするかもしれない。元のクライアントがブラックアウト期間内に応答しない場合、サーバーはレジューム状態情報をクリーンアップし、および新しいクライアントが通常通りにリソースにアクセスすることを可能にする。ある実施形態において、コネクション状態システムは様々なストレージ装置またはレジュームの速度を向上させるための方法を使用することができる。例えば、システムはレジューム状態情報を格納するために、高速の、不揮発性のストレージ装置例として、SSDを使用することができ、これによりレジュームがデータに対してより高速にアクセスし、何れの更なる障害によって既に中断された動作を遅らせることを避ける。別な例として、システムは各々のサーバーによって作成される全ての変化を、サーバーのグループに対してブロードキャストすることができ、これにより各々のサーバーは状態情報の独自のコピーを管理することができ、および元のサーバーの障害が発生した場合にはフェイルオーバーサーバーに選択されることができる。前述より、コネクション状態システムの特定の実施形態は、図示の目的のために本明細書に記載されたものであるが、本発明の技術思想および技術範囲から逸脱することなく様々な修正がなされることは理解されるであろう。従って、本発明は添付された特許請求の範囲によって以外は限定されない。