(57)【特許請求の範囲】
【請求項１】
制御モジュールと、
第1のストレージモジュールと、
第2のストレージモジュールと、
第3のストレージモジュールと、
バッファとを備える、データストレージデバイスであって、
前記第1のストレージモジュールは、複数のデータセットを記憶するように構成され、
前記制御モジュールは、前記第1のストレージモジュール内の前記複数のデータセットについて実行すべき動作のための要求を受け取り、前記受け取った要求を実行し、前記第1のストレージモジュール内の前記複数のデータセットを所定の時間に前記第2のストレージモジュールにコピーするように構成され、
前記制御モジュールは、動作のための前記受け取った要求を前記バッファに追加するように構成され、
前記制御モジュールは、前記バッファに前記第3のストレージモジュールとの直接相関を割り当てるように構成され、
前記データストレージデバイスは、前記第1のストレージモジュール内の前記複数のデータセットを前記第2のストレージモジュールから初期化し、回復シナリオにおいて前記第3のストレージモジュールからの前記要求に対応する動作を実行するように構成され、
前記データストレージデバイスは、前記第1のストレージモジュール内の動作がそれに対して実行された、前記第2のストレージモジュール内のそれらのデータセットだけを更新するように構成される、データストレージデバイス。
【請求項２】
前記第2のストレージモジュールは、前記第1のストレージモジュールから複数の所定時点において前記複数のデータセットの一貫性のある状態の持続的コピーを含むように構成される、請求項1に記載のデータストレージデバイス。
【請求項３】
前記制御モジュールは、前記第1のストレージモジュール内の前記複数のデータセットについて実行すべき動作のための要求を受け取り、前記受け取った要求を実行し、複数の後続の所定時点において前記第1のストレージモジュール内の前記複数のデータセットを前記第2のストレージモジュールにコピーするように構成される、請求項1または2に記載のデータストレージデバイス。
【請求項４】
前記バッファは、循環バッファである、請求項1から3のいずれか一項に記載のデータストレージデバイス。
【請求項５】
前記バッファは、前記第1のストレージモジュールについて実行すべき動作のための前記受け取った要求を追加するため、および前記第3のストレージモジュールを更新するために同じバッファセルを使用するように構成される、請求項1から4のいずれか一項に記載のデータストレージデバイス。
【請求項６】
前記制御モジュールは、前記第3のストレージモジュールを更新するために使用された前記第1のストレージモジュール内の前記データセットについて実行される動作のための前記要求にマークを付けるように構成される、請求項1から5のいずれか一項に記載のデータストレージデバイス。
【請求項７】
前記制御モジュールは、前記第2のストレージモジュール内の前記データセットを繰り返し更新するように構成される、請求項1から6のいずれか一項に記載のデータストレージデバイス。
【請求項８】
前記制御モジュールは、前記第2のストレージモジュール内の前記データセットの更新が成功したかどうかを検証し、前記更新が成功しなかった場合は、それぞれの前記要求に前記第2のストレージモジュール内で更新されたとのマークを付けないように構成される、請求項1から7のいずれか一項に記載のデータストレージデバイス。
【請求項９】
前記第1のストレージモジュールは、非持続的ストレージモジュールである、請求項1から8のいずれか一項に記載のデータストレージデバイス。
【請求項１０】
前記第3のストレージモジュールは、持続的ストレージモジュールである、請求項1から9のいずれか一項に記載のデータストレージデバイス。
【請求項１１】
前記第1のストレージモジュールは、前記複数のデータセットを複数のデータセット群に割り当てるように構成され、
前記データストレージデバイスは、複数のバッファを備え、
前記複数のバッファの各バッファは、1つのデータセット群に割り当てられる、請求項1から10のいずれか一項に記載のデータストレージデバイス。
【請求項１２】
前記データストレージデバイスは、前記第2のストレージモジュールの前記データセットおよび前記第3のストレージモジュール内に含まれる前記要求に基づいて前記第1のストレージモジュール内の前記複数のデータセットを復元するように構成される、請求項1から11のいずれか一項に記載のデータストレージデバイス。
【請求項１３】
前記第3のストレージモジュール内に含まれる前記要求のそれらだけが、前記第2のストレージモジュールに更新されなかった前記第1のストレージモジュール内の前記データセットに適用される、請求項12に記載のデータストレージデバイス。
【請求項１４】
データストレージのための方法であって、
第1のストレージモジュールに複数のデータセットを記憶するステップと、
前記第1のストレージモジュール内の前記複数のデータセットについて実行すべき動作のための要求を受信するステップと、
前記受信した要求を実行するステップと、
前記複数のデータセットを所定の時間に第2のストレージモジュールにコピーするステップと、
動作のための前記受信された要求をバッファに追加するステップと、
前記バッファに第3のストレージモジュールとの直接相関を割り当てるステップと、
前記第1のストレージモジュール内の前記複数のデータセットを前記第2のストレージモジュールから初期化するステップと、
回復シナリオにおいて前記第3のストレージモジュールからの前記要求に対応する動作を実行するステップと、
前記第1のストレージモジュール内の動作がそれに対して実行された、前記第2のストレージモジュール内のそれらのデータセットだけを更新するステップと、
を具備することを特徴とする方法。
【請求項１５】
前記第1のストレージモジュールから複数の所定時点において前記複数のデータセットの一貫性のある状態の持続的コピーを前記第2のストレージモジュールに格納するステップ
をさらに具備することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記第1のストレージモジュール内の前記複数のデータセットについて実行すべき動作のための要求を受信し、前記受信した要求を実行し、複数の後続の所定時点において前記第1のストレージモジュール内の前記複数のデータセットを前記第2のストレージモジュールにコピーするステップ
をさらに具備することを特徴とする請求項１４又は１５に記載の方法。
【請求項１７】
前記第1のストレージモジュールについて実行すべき動作のための前記受信した要求を追加するため、および前記第3のストレージモジュールを更新するために同じバッファセルを使用するステップ
をさらに具備することを特徴とする請求項１４から１６のいずれか一項に記載の方法。
【請求項１８】
前記第3のストレージモジュールを更新するために使用された前記第1のストレージモジュール内の前記データセットについて実行される動作のための前記要求にマークを付けるステップ
をさらに具備することを特徴とする請求項１４から１７のいずれか一項に記載の方法。
【請求項１９】
前記第2のストレージモジュール内の前記データセットの更新が成功したかどうかを検証するステップと、前記更新が成功しなかった場合は、それぞれの前記要求に前記第2のストレージモジュール内で更新されたとのマークを付けることを停止するステップと、
をさらに具備することを特徴とする請求項１４から１８のいずれか一項に記載の方法。
【請求項２０】
前記第2のストレージモジュールの前記データセットおよび前記第3のストレージモジュール内に含まれる前記要求に基づいて前記第1のストレージモジュール内の前記複数のデータセットを復元するステップ
をさらに具備することを特徴とする請求項１４から１９のいずれか一項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データストレージの技術分野に関し、詳細には、データストレージデバイス、例えば特に大量のデータを記憶し管理し、これらのデータを読み出しまたは書き込み動作のためにクライアントに提供するためのコンピュータデバイスに関する。
【背景技術】
【０００２】
大きなインメモリデータベースは、キーバリューストア、オンライントランザクション処理(OLTP)データベース、大規模ウェブアプリケーション、大量のオンラインマルチプレーヤゲーム、ソフトウェア定義ネットワーク(SDN)コントローラネットワークビュー、科学的シミュレーションなどの役割を果たすために、生産拠点において現在使用されている。これらのアプリケーションは、多重実行コンテキスト、例えば不均等メモリアクセス(NUMA)シェアードエブリシングアーキテクチャにおけるスレッドを使用して高いトランザクションレートを維持するために構築され、それによってデータセットは、論理的に区分され、各区分は、その区分についてのトランザクションを処理する責任がある実行コンテキストと関連付けられる。
【０００３】
チェックポインティングおよび論理的REDOログは、システム障害の場合にデータセットの回復を可能にするためにインメモリデータセットにおいて使用されることもある。更新トランザクションの耐久性は、一貫性のある瞬間状態を持続的ストレージにフラッシュする周期的チェックポインティングプロセス、および連続するチェックポイント間のすべての修正要求を記録する論理的REDOログによって提供される。システム障害の後、復元プロセスは、メモリ状態を初期化するために最後の持続的チェックポイントを使用し、障害時以前の時点におけるアプリケーション状態を再生成するためにREDOログを再現するための再現手順を使用する。
【０００４】
REDOロギングの設計は、データセット高い更新レートに直面して、データベース設計者にとって継続する課題のままである。REDOロギングは、チェックポインティングと密接に結合される。チェックポインティングプロセスは、高い更新レートを支援するために、低オーバヘッドかつ高効率でなければならず、復元時におけるREDOログサイズおよびその関連ログ再現継続時間を低減するために、高頻度のチェックポインティングでなければならない。チェックポイントは、繰り返し実行されるので、増分チェックポインティングが通常、利用されることがあり、それによって前のチェックポイント以後に変更されたオブジェクトだけが、検出され、残される。
【０００５】
論理的REDOロギングは通常、データセットへの修正要求を残すが、これらの修正は、インメモリデータセットにおいて実施される。持続的ストレージデバイスを更新するレートは通常、メモリを更新するよりもかなり低いので、これらのトランザクションのより完全なログを残すことを優先してトランザクション処理を遅くする間に緊張が生じることがある。
【０００６】
Tuan Cao他、「Fast Checkpoint Recovery Algorithms for Frequently Consistent Applications」、SIGMOD'11、2011年6月、アテネ、ギリシャは、全メモリ速度においてトランザクションのロギングを可能にすることを優先して専用ストレージデバイスを利用する手法を述べる。
【発明の概要】
【課題を解決するための手段】
【０００７】
データセットに関係するREDOロギング中にトランザクション処理について悩まされる侵入を低減するデータストレージデバイスを提供することが、本発明の目的である。
【０００８】
この目的は、独立クレームの主題によって解決される。さらなる実施形態は、従属クレームおよび下記の説明において述べられる。
【０００９】
本発明の一態様によると、制御モジュールと、第1のストレージモジュールと、第2のストレージモジュールと、第3のストレージモジュールと、バッファとを備える、データストレージデバイスが、提供される。第1のストレージモジュールは、複数のデータセットを記憶するように構成され、制御モジュールは、第1のストレージモジュール内の複数のデータセットについて実行すべき動作のための要求を受け取り、受け取った要求を実行し、第1のストレージモジュールに記憶されるまたは含まれる複数のデータセットを第2のストレージモジュールに所定の時間にコピーするように構成される。制御モジュールはさらに、動作のための受け取った要求をバッファに追加し、同期手段によってバッファを第3のストレージデバイスに残すように構成される。データストレージデバイスは、第1のストレージモジュール内の複数のデータセットを第2のストレージモジュールから初期化し、回復シナリオにおいて第3のストレージモジュールからの要求に対応する動作を実行するように構成される。
【００１０】
本明細書で言及される制御モジュールは、データストレージデバイスのプロセッサまたは中央プロセッサユニット、例えばデータセットサービスを複数の要求するデバイスまたはクライアントに提供するように適合される任意の種類のコンピュータであってもよい。第1のストレージモジュールは、非持続的メモリであってもよく、第2のストレージモジュールは、持続的メモリ、例えばハードディスクまたは任意の他の種類の持続的メモリユニットであってもよい。バッファは、要求入力およびREDOログのために使用されるすべてのリストを含む。データセットは、少なくとも1つのキーバリュー入力を備えるストライプに差し向けられて(referred to)もよい。
【００１１】
制御ユニットは、バッファと第3のストレージモジュールとの間に直接相関を割り当てるように構成されてもよい。例えば、バッファは、第3のストレージモジュールにマップされてもよく、例えば第3のストレージモジュールとのバッファのバイト対バイトの直接相関を割り当てる。バッファを第3のストレージモジュールにマップするために、データストレージデバイスのオペレーティングシステムの適切な関数、例えばユニックス(Unix)システムのmmap()関数が、使用されてもよい。マップされたまたはメモリマップされたセクションは特に、ポインタまたはファイル記述子を通じて直接参照されてもよいストレージモジュールのメモリセクションであってもよい。そのようなバイト対バイト相関は次いで、別の機能ユニット、例えばデータストレージデバイスのモジュールの任意の1つによって、あたかもそれが、それぞれのモジュールのメモリセクションであるかのように、使用されてもよい。バッファを第3のストレージモジュールに残すことは、例えばシステムコールによって行われてもよい。
【００１２】
回復シナリオでは、処理されないまたは実行されない、記憶された要求が、再現される。例えば、第1のストレージモジュールの障害および第2のストレージモジュールからの第1のストレージモジュールのその後の回復の場合は、第3のストレージモジュールに記憶された要求は、障害またはシステムクラッシュの時点においてデータを初期化するために第1のストレージモジュールについて実行される(=再現される)。
【００１３】
第2のストレージモジュールは、上で述べられたチェックポイントを含み、第3のストレージモジュールは、REDOログファイルを含む。バッファは、そのファイルにマップされたREDOログバッファを含む。ストレージモジュールおよびバッファは、1つのかつ同じ物理メモリデバイスのセクションであってもよい。
【００１４】
第2のストレージモジュールは、第1のストレージモジュールからの所定の時間における複数のデータセットの一貫性のある状態の持続的コピーを含むように構成されてもよい。制御モジュールは、第3のストレージモジュールとの直接相関をバッファに割り当てるように構成されてもよい。
【００１５】
そのようなデータストレージデバイスは、要求バッファが、第3のストレージモジュールのコンテンツを更新するために使用されるということを可能にする。特に、同じメモリセルは、REDOログが、別々のメモリセル書き込まれていないように、要求およびログの入力のために使用される。それ故に、別々のREDOログの書き込み動作は、もはや必要とされない。
【００１６】
本発明の一実施形態によると、第2のストレージモジュールは、第1のストレージモジュールから複数の所定の時点における複数のデータセットの一貫性のある状態の持続的コピーを含むように構成される。
【００１７】
持続的コピーは、間にある一定のまたは変化する時間ギャップに合わせて周期的に繰り返す時点において生成されてもよい。第2のストレージモジュールは、更新プロセスのたびに新しいコピーと置き換えられる1つのコピーだけを含んでもよく、またはそれは、最後のN回の更新プロセスから2つ以上のコピーを含んでもよく、ただしNは、一定とすることができ、もっとも古いコピーは、上書きされる。
【００１８】
本発明のさらなる実施形態によると、制御モジュールは、第1のストレージモジュール内の複数のデータセットについて実行すべき動作のための要求を受け取り、受け取った要求を実行し、第1のストレージモジュール内の複数のデータセットを第2のストレージモジュールに複数のその後の所定の時点においてコピーするように構成される。
【００１９】
第1のストレージモジュール内の複数のデータセットは、その後のコピーするプロセス間に一定のまたは変化する時間ギャップを有して第2のストレージモジュールに周期的にかつ繰り返しコピーされてもよい。
【００２０】
本発明のさらなる実施形態によると、バッファは、循環バッファである。
【００２１】
それ故に、要求入力は、任意のオフセットから始まるバッファに書き込まれ、バッファの始まりをラップアラウンドする(wrap around)。バッファのサイズは、所定の値に限定されてもよい。
【００２２】
本発明のさらなる実施形態によると、バッファは、第1のストレージモジュールについて実行すべき動作のための受け取った要求を追加するためおよび第3のストレージモジュールを更新するために同じバッファセルを使用するように構成される。
【００２３】
それ故に、バッファ内の同じセルが、要求入力およびログ入力のために使用されるので、バッファ内のコピーは、ログファイルを保持するために必要とされない。
【００２４】
本発明のさらなる実施形態によると、制御モジュールは、第3のストレージモジュールを更新するために使用された第1のストレージモジュール内のデータセットについて実行すべき動作のための要求にマークを付けるように構成される。
【００２５】
要求にマークを付けることは、要求を含むメモリセルまたは論理的メモリ位置へのポインタを使用することによって、またはディスクについて実行された1つの要求を識別するフラグを使用することによって生じてもよい。
【００２６】
それ故に、第3のストレージモジュールに書き込まれたまたは第3のストレージモジュールを更新するために使用された要求入力は、環状バッファ内に上書きされてもよい。マークを付けられない要求入力は、これらの入力が、第2のストレージモジュールを更新するために必要とされるので、上書きすることができない。
【００２７】
本発明のさらなる実施形態によると、制御モジュールは、第2のストレージモジュール内のデータセットを繰り返し更新するように構成される。
【００２８】
それ故に、連続更新プロセス間の周期は、バッファのサイズおよび第2のストレージモジュールを更新するために必要とされる時間が、最適化され、特に低減されてもよいように、適合されてもよい。さらに、第2のストレージモジュールの更新速度は、特に第2のストレージモジュールへの書き込み動作が、ディスクに類似の持続的メモリへの物理的書き込み動作に起因して時間がかかるときは、考慮されてもよい。
【００２９】
本発明のさらなる実施形態によると、制御モジュールは、第2のストレージモジュール内のデータセットの更新が、成功したかどうかを検証し、更新が成功していない場合は、それぞれの要求に第2のストレージモジュール内で更新されたとのマークを付けないように構成される。
【００３０】
言い換えれば、第2のストレージモジュールに更新されたそれらの要求入力だけが、更新されたとしてマークを付けられ、さもなければそれらの要求は、その後の更新ステップにおいて更新される。
【００３１】
本発明のさらなる実施形態によると、データストレージデバイスは、第1のストレージモジュール内の動作がそれについて対して実行された、第2のストレージモジュール内のそれらのデータセットだけを更新するように構成される。すなわち、第1のストレージモジュール内の動作に対するオブジェクトであった、第2のストレージモジュール内のそれらのデータセットだけが、更新される。
【００３２】
この実施形態は、増分更新に関係し、メモリ内の変更されたデータセットだけが、ディスク上で更新されるので、オーバヘッドを低減することができる。
【００３３】
本発明のさらなる実施形態によると、第1のストレージモジュールは、非持続的ストレージモジュールである。
【００３４】
第1のストレージモジュールは例えば、インメモリデータベースを記憶するために適合され、要求するデバイスにデータベースへのアクセスを提供するランダムアクセスメモリ、RAMであってもよい。
【００３５】
この実施形態では、非持続的ストレージモジュールである第1のストレージモジュールは、効率的な読み出し/書き込み動作を可能にし、それ故にシステム性能を高めることができる。
【００３６】
本発明のさらなる実施形態によると、第3のストレージモジュールは、持続的ストレージモジュール、例えばハードディスクもしくは固体ディスクまたは任意の他の種類の持続的ストレージデバイスである。
【００３７】
この実施形態では、第3のストレージデバイスは、第1のストレージデバイス内のデータセットへの修正とともに更新される。ディスクドライブについての動作のための継続時間は、RAMについてよりも高いので、そのようなシステムは、データ安全性および高効率の両方について最適化される。
【００３８】
本発明のさらなる実施形態によると、第1のストレージモジュールは、複数のデータセットを複数のデータセット群に割り当てるように構成され、データストレージデバイスは、複数のバッファを備え、複数のバッファの各バッファは、1つのデータセット群に割り当てられる。
【００３９】
言い換えれば、第1のストレージモジュールは、インメモリデータベースを含む。この実施形態では、各データセット群または区分は、要求、要求のロギングおよび更新が、複数のデータセット群のそれぞれについて個々に実行されてもよいように、1つのバッファを割り当てられている。
【００４０】
本発明のさらなる実施形態によると、データストレージデバイスは、第2のストレージモジュールのデータセットおよび第3のストレージモジュール内に含まれる要求に基づいて第1のストレージモジュール内の複数のデータセットを復元するように構成される。
【００４１】
それ故に、システム障害後の復元が、可能になる。
【００４２】
本発明のさらなる実施形態によると、第3のストレージモジュール内に含まれる要求のそれらだけが、第2のストレージモジュールに更新されなかった第1のストレージモジュール内のデータセットに適用される。
【００４３】
言い換えれば、本明細書で述べられるようなデータストレージデバイスは、REDOログ設計の技法を提案し、それによってトランザクション処理について悩まされる侵入が、より少なく、ファイルシステムから必要とされる支援が、より少なく、それ故により多くのREDOログ入力が、ディスク上に獲得される。トランザクション実行とログ処理との間の関連原理(concern principle)の分離を適用する、特別なスレッドモデルが、利用されてもよい。そうすることによって、かなりのREDOログ処理効率が、得られてもよい。
【００４４】
データストレージデバイスの一態様は、キーバリューストア内の要求を実行する稼働スレッドと、要求バッファを稼働スレッドに渡す通信スレッドとの間の分断を利用すると述べられてもよい。要求バッファは、要求仕様を含むために使用され、そのまさに仕様は、REDOログに保存される必要があるので、要求仕様を直接REDOログ入力に読み込み、次いで実行のために参照(reference)をその入力に渡す手法が、述べられる。その上、REDOログ入力を置くためのメモリマップされたファイルの使用によって、全処理経路に沿った真のゼロコピー設計が、達成される。
【００４５】
それ故に、この手法は、実行のための要求仕様、REDOログおよびファイル出力をコピーする必要を取り除く。それ故に、真のゼロコピー要求仕様設計が、用いられる。さらに、REDOログ処理によって稼働スレッドに課せられる侵入は、最小化されてもよく、多重REDOログ入力のためのREDOログページは、私有化され(privatize)、それによっていわゆるFreeListとの同期を最小限にする。FreeListは、次の通りの構成可能なサイズを有するリストであり、それは、システム障害の結果として失われることもあるREDO入力の最大数を規定し、それは、同期システムコールの頻度を規定する。
【００４６】
上で述べられた手法は、ファイルフラッシングのためにメモリマップされたファイルAPIを利用してもよく、従って最小のファイルシステムオーバヘッドだけを必要とし、障害忘却型の一貫性保証を提供するために障害-アトミック(failure-atomic)のmsync()支援を活用してもよい。
【００４７】
これらの特性を組み合わせると、述べられたREDOログ手法は特に、低オーバヘッドを有することができ、高効率とすることができ、それによってより短い時間内でより多くの要求を処理し、より完全なログを記憶することを可能にする。
【００４８】
本発明の実施形態は、次の図に関して述べられることになる。
【図面の簡単な説明】
【００４９】
【図１】複数の要求するデバイスに接続される、本発明の例示的実施形態によるデータストレージデバイスを概略的に示す図である。
【図２】本発明の例示的実施形態によるデータストレージデバイスのキーバリューストアのスレッドモデルを概略的に示す図である。
【図３】本発明の例示的実施形態によるデータストレージデバイスのREDOログファイルを概略的に示す図である。
【図４】本発明の例示的実施形態による、私有のREDOログをそれぞれ有する通信スレッドを概略的に示す図である。
【図５】本発明の例示的実施形態によるデータストレージデバイス内のロガーユニットの処理を概略的に示す図である。
【図６】本発明の例示的実施形態によるデータストレージデバイス内の通信ユニットの処理を概略的に示す図である。
【発明を実施するための形態】
【００５０】
図1は、制御モジュール100と、第1のストレージモジュール110と、第2のストレージモジュール120と、第3のストレージモジュール125と、バッファ130とを有するデータストレージデバイス10を示し、データストレージデバイス10は、クライアントと呼ばれることもある1つまたは複数の要求するデバイス20に通信可能に接続される。データストレージデバイスはまた、サーバーと呼ばれることもある。
【００５１】
制御モジュール100、ストレージモジュール110、120、125およびバッファは、上記および以下で述べられるような機能を実行するように構成される。
【００５２】
図2は、要求するデバイス20からのデータ要求を取り扱うため、およびストレージモジュールに記憶されたデータを管理するためにデータストレージデバイス10によって使用されてもよい、一般的なキーバリューストアのスレッドモデル200を示す。ストレージレイアウト抽象221は、ストライプ224の組を複数のデータ区分222に指定し、各ストライプは、キーバリューストア内で規定される、あるテーブルの行の集合体を表す。キーバリューストア動作処理は、フロントエンド(FE)210とバックエンド(BE)220との間で分けられる。一組の動作要求キューおよびその応答キューをそれぞれ備える、一組の稼働キュー218は、FE210とBE220との間の主インターフェースである。各キューは、BE稼働スレッドと関連付けられる。
【００５３】
FE210は、一組の通信スレッド212、およびデマルチプレクサ216を備える。デマルチプレクサ216は、要求をパースし、要求をエンキューするための特定のキューを決定するために使用される。好ましくは、FE210はさらに、レンジアレイ(Ranges-Array)217を備え、それは、各稼働キュー218のストライプの互いに素な(部分)集合を関連付けるように構成され、デマルチプレクシングのために使用される。通信スレッド212は、通信ソケット取得要求を読み出し、デマルチプレクサ216を使用して目標キューを決定し、その要求を要求キューにポストする。逆方向においては、通信スレッドは、応答キューを読み出し、その応答を関連するソケット214に引き渡す。
【００５４】
BE220は、一組の稼働スレッド、および各スレッドについて、区分222と呼ばれる、異なるテーブルからくることもある対応する組のストライプ224を備える。区分へのすべてのストライプの分配および区分へのスレッドの割り当ては、分割を決定する。
【００５５】
好ましくは、BE220は、ポリサー219を備え、それは、知覚される負荷により良く適合するために、要求をキューの間で再分配するためにレンジアレイを更新するように構成される。
【００５６】
稼働スレッドは、要求をその要求キューから取り出し、それをその区分内のストライプの1つについて実行し、応答をその応答キューにポストする。
【００５７】
通信スレッド212は、一組のネットワークソケット214を読み出し、トランザクション要求を受け取り、デマルチプレクサ216を使用して目標キューを決定し、その要求を要求キューにポストする。逆方向においては、通信スレッド212は、応答キューを読み出し、その応答を関連するソケット214に引き渡し、解放された(freed)要求/応答バッファをフリーリストに戻す。
【００５８】
通信スレッド212は、要求のデータおよび応答のデータをコピーすることを避けるために、作業キューと関連付けられる、事前割り当て要求/応答バッファのフリーリストを使用する。その考えはさらに、REDOロギングのために利用される。すなわち、要求バッファは、要求仕様を含むために使用され、そのまさに仕様は、REDOログに保存されるので、2つの目的のために仕様を再使用し、メモリマップされたファイルの使用によって真のゼロコピー設計を達成する方法が、考案される。
【００５９】
図3は、時間的なREDOログファイル300のコンテンツを例示する。垂直矢印302、304、306は、矢印のラベル上に指定された時間の間に、すなわち時間t0、t1、t2、t3のそれぞれ2つの後続時点の間に生じるすべての修正要求の記録を表す。
【００６０】
t0において、t0状態のスナップショットが、獲得され、REDOログが、開始される。t1において、t0の成功したチェックポイント、およびREDO t0-t1が、利用できる。t2において、t1のチェックポイントが、失敗し、それでREDOログは、t0-t1のすべての入力を含む必要がある。
【００６１】
t3において、t2のチェックポイントは、成功し、それでt3において、REDOログは、t2-t3からの入力だけを含むためにパージされる。
【００６２】
図3は、REDOロギングとチェックポインティングとの間の論理的関係を記述するために、多重連続チェックポイント間隔312、314、316、318にわたるチェックポインティングおよびREDOログ処理の例を示す。
【００６３】
一組のメモリ常駐オブジェクトを連続的に修正する一組のスレッドが、描写される(左から右へ隣同士に並べられ、垂直破線によって示される)。チェックポイント時間において、メモリコンテンツ320の一貫性のあるスナップショットが、取得され、変更セットと呼ばれる、最後に成功したチェックポイントに相対的に修正されるスナップショット内のオブジェクト322、324、326、328は、ディスクに、すなわち第2のストレージモジュール120にフラッシュされる。メモリコンテンツ320は、第1のストレージモジュール110に記憶される。
【００６４】
もし最後のチェックポイント(t[n-1])が、成功しなかったならば、現在のチェックポイント(tn)および最後のチェックポイント(t[n-1])のための変更セットは、統一される(組み合わされる)。異なる方法が、変更セットを検出しかつ管理するために使用されてもよい。
【００６５】
論理的REDOログは、チェックポインティングにおいて変更セット内に後で獲得されるデータセットについての修正動作要求の一貫性のある記録を提供する。従って、REDOログファイルは、開始され、最後の成功したチェックポイント間隔時間に対して相対的にパージされる。
【００６６】
データストレージデバイス10のゼロコピーREDOロギング手法は、最小のファイルシステムオーバヘッドを可能にする。この手法は、データストレージデバイス10の制御ユニット110の機能を実行するように構成され、下記の図を参照して説明されることになるロガースレッドおよび通信スレッドを管理するロガーユニットを規定する。
【００６７】
図4は、両方のスレッド間の相互作用および/または通信を示す。通信は、上で述べられたFreeList410を通じて生じる。ロガースレッドは、ページをFreeListに置き、通信スレッドは、ページをFreeListから読み出す。
【００６８】
メモリマップされたファイル420は、構成される数のチェックポイント障害を支援するのに十分な数の入力とともに、最大の必要とされるサイズのREDOログを保持するために使用される。ファイル内のログは、「循環的」であり、ログが、任意のオフセットから始まり、ファイルの始まりをラップアラウンドすることを意味する。第1の論理的入力のオフセットは、対応するチェックポイントファイルに保存される。異なるREDOログファイルは、異なるディスク上に置かれてもよい。
【００６９】
ファイルのアドレス空間は、REDOページに分けられ(REDOページは、多様なオペレーティングシステム、OS、ページであってもよい)、その空間は、SavedPagesおよびAvailablePagesのアドレス範囲に区分される。SavedPagesは、アクティブなREDOログ入力が保たれる範囲を表す。AvailablePagesは、次のREDO入力を記憶するために利用できるページである。AvailablePages内にマップされる、REDOページのFreeListは、通信スレッドが、割り当てかつ私有化することができるページを備える。FreeListのサイズは、システムクラッシュの場合に失われる状態にあるデータの量を決定する。FreeListが、空にされるとき、通信スレッドは、それが、補充されるまで、待機をループさせる。
【００７０】
REDOページのPendingList430は、ロガースレッドによって処理されるのを待っているページのリストを含む。もしPendingList内のページが、部分的にだけ満たされるならば、ロガースレッドは、それが実際に残すことになるより小さい数のページにすべてのREDOログ入力を組み合わせてもよい。ロガースレッドは、同期msync()システムコールを用いてPendingListにページを残す。msync()は、ページについて行われるが、そのアドレスは、SavedPagesに追加され、ロガーは、新しいページをAvailablePagesから取り出し、そのページをFreeListに置く。
【００７１】
更新トランザクションを受け取ると、通信スレッドは、私有のREDOページ(ロガーユニットのFreeListから割り当てられる)を使用し、ページ内の現在のオフセットにおおいてREDO入力をフォーマットし、トランザクションパラメータをネットワークソケットからREDO入力に読み込む。次いでそれは、REDO入力へのポインタを要求/応答バッファに記憶し、要求バッファを要求キュー上にプッシュする。
【００７２】
要求が、稼働スレッドに到着すると、スレッドは、REDO入力を読み出し、それを実行し、応答状況をREDO入力に記憶する。通信スレッドは、すべての可能な稼働スレッドを供給するので、異なるスレッドが、例えば区分への稼働スレッドの関連付けを再計算した後、同じ行を更新するシナリオがあってもよい。それ故に、同じ行についての更新は、異なるREDOログファイルに現れることもある。従って、稼働スレッドは、行のトランザクション番号の順序付けカウンタをREDOログ入力に挿入する。
【００７３】
ページが、いっぱいであるとき、または構成されるREDOログフラッシュ間隔Trの終了のとき、通信スレッドは、関連する稼働スレッドが、ページ内のそれらのREDOログ入力を処理したことを確認する。スレッドは、その完了状況についてページ内の関連する稼働スレッドの最後の入力を読み出すことができる。通信スレッドは次いで、そのページをPendingList430にエンキューし、新しいページをFreeList410から割り当てる。Tr間隔は、低い作業負荷更新レートのシナリオにおいて、通信スレッドがFreeList補充を待つ必要なしに、ロガースレッドが、時間通りにPendingListを残すように構成される。
【００７４】
通信およびロガースレッドは、チェックポイントプロセスの始めおよび終わりをポーリングしてもよい。チェックポイントの始めにおいて、通信スレッドは、新しいチェックポイントのためのREDOログ入力の前に特別なマーカーをページに追加する。このマーカーのオフセットは、対応するチェックポイントファイルに保存される。最後のチェックポイントの成功した完了を検出するロガースレッドは、最近のチェックポイントがカバーするREDOログ入力に対応するSavedPages内のページをAvailablePagesに移動させる。
【００７５】
システム障害の後、復元プロセスは、メモリ状態を初期化するために、最新の持続的チェックポイントを使用し、障害時以前の時点におけるアプリケーション状態を再生成するためのREDOログを再現するためにReplay手順を使用する。Replay手順は、チェックポイントファイルに保存されたオフセットからREDOログファイルを並行してスキャンし、REDO入力内で指定されるトランザクションをインメモリデータセット状態に適用する。
【００７６】
行REDO入力は、複数ファイルにわたって分散されることもあるので、Replay手順は、順序が狂って(out-of-order)遭遇する入力を吸収するために、行についてスレッド化バイナリツリーを維持してもよい。次の順序のREDO入力が、遭遇されるとき、それは、すぐに処理され、その後、そのツリー内のすべての次に来る入力が、処理される。
【００７７】
FreeList410およびメモリマップされたファイル420は特に、付加的REDOログコピーが、必要とされないように、同じ物理メモリアドレスを指し示す。
【００７８】
図5および図6は、動作可能なキーバリューストアにおけるREDOログ設計の実施を示す。これらの図において、PendingListは、REDOログページのリストであり、AvailablePagesおよびSavedPagesは、図4を参照して述べられるようなメモリマップされたファイルのアドレス空間である。
【００７９】
図5は、ロガースレッドの流れ図を示す。スレッドは、PendingList上で待ち、空でないときに、ページをリストから除去し、同期システムコール、例えばmsync()を用いてそれを残す。
【００８０】
ステップ510において、次のREDOページが、REDOページがある限りPendingListから取得され、分岐520によって示される。その後、REDOページは、ステップ530において同期化され、ステップ540においてSavedPagesに加えられる。ステップ550において、新しいページが、利用できるページから、さらなるページがステップ560において利用できなくなるまで割り当てられる。ステップ570において、新しいページが、FreeListに挿入され、ステップ580において最後のチェックポイントがなされたか否かに応じて、SavedPagesが、ステップ590においてAvailablePagesに戻されるか、または次のREDOページが、ステップ510においてPendingListから取得される。
【００８１】
図6は、通信スレッドの流れ図を示す。通信スレッドは、REDOログページをFreeListから私有化する。そのページは、頻繁なページ割り当てが、必要とされないように、十分なREDOログスペースを提供する。REDOログ入力内に必要とされるスペースを有すると、スレッドは、更新動作要求をページに読み込み、その入力を対応する稼働スレッドのための最後の入力として思い出す。スペースの消耗またはTrタイマー終了のとき、通信スレッドは、ページ内のすべての最後の入力が読み出されたことを確認する。その後、スレッドは、ページをPendingListに加え、ループの始めに進む。
【００８２】
言い換えれば、ステップ610において、ページが、FreeListから、すべてのページがステップ620において取得されるまで、取得される。ステップ630において、ソケットが、ページ内のREDOログ入力に読み込まれ、ポインタが、バッファを通される。さらに、ステップ630において、それぞれの入力が、作業スレッドのための最後の入力として思い出される。新しいチェックポイントの場合は、オフセットが、エクスポートされる。これは、ステップ640においてもはやスペースがページ内で利用できないまたはTrが終了するまで、繰り返される。ステップ650において、通信スレッドは、ページ内の最後の入力が読み出されたことを確認し、ステップ660において、そのページをPendingListに加える。
【符号の説明】
【００８３】
10  データストレージデバイス
20  要求するデバイス
100  制御モジュール
110  第1のストレージモジュール
120  第2のストレージモジュール
125  第3のストレージモジュール
130  バッファ
200  キーバリューストアのスレッドモデル
210  フロントエンド(FE)
212  通信スレッド
214  ソケット
216  デマルチプレクサ
217  レンジアレイ
218  稼働キュー
219  ポリサー
220  バックエンド(BE)
221  ストレージレイアウト抽象
222  データ区分
224  ストライプ
300  REDOログファイル
302  垂直矢印
304  垂直矢印
306  垂直矢印
312  チェックポイント間隔
314  チェックポイント間隔
316  チェックポイント間隔
318  チェックポイント間隔
320  メモリコンテンツ
322  オブジェクト
324  オブジェクト
326  オブジェクト
328  オブジェクト
410  FreeList
420  メモリマップされたファイル
430  PendingList
【図１】
0006432805.tif 000002
【図２】
0006432805.tif 000003
【図３】
0006432805.tif 000004
【図４】
0006432805.tif 000005
【図５】
0006432805.tif 000006
【図６】
0006432805.tif 000007