分散ロックマネージャー

分散ロックマネージャ（DLM）は、クラスタ内のすべてのマシンで実行され、クラスタ全体のロックデータベースの同一のコピーを保持します。オペレーティングシステムは、ロックマネージャを使用してリソースへのアクセスを整理し、シリアル化します。このように、DLMは、クラスタ内の複数のマシンに分散されたソフトウェアアプリケーションに、共有リソースへのアクセスを同期する手段を提供します。

DLMは、クラスタ化されたファイルシステムの基盤として、いくつかの成功した事例で利用されてきました。これらのシステムでは、クラスタ内のマシンは統合されたファイルシステムを介して互いのストレージを利用できるため、パフォーマンスと可用性の面で大きなメリットが得られます。主なパフォーマンス上のメリットは、参加コンピュータ間のディスクキャッシュの一貫性の問題を解決することに起因します。DLMは、ファイルのロックだけでなく、すべてのディスクアクセスの調整にも使用されます。広く普及した最初のクラスタリングシステムであるVMSclusterは、まさにこの方法でOpenVMS DLMを活用していました。

リソース

DLMは、共有アクセスを制御する必要がある実体であるリソースという一般的な概念を使用します。これは、ファイル、レコード、共有メモリ領域など、アプリケーション設計者が選択した任意のものに関連付けることができます。リソースの階層を定義することで、複数のレベルのロックを実装できます。例えば、仮想的なデータベースでは、リソース階層を次のように定義できます。

  • データベース
  • テーブル
  • 記録
  • 分野

プロセスはデータベース全体に対するロックを取得し、その後データベースの特定の部分に対するロックを取得できます。従属リソースをロックするには、まず親リソースに対するロックを取得する必要があります。

ロックモード

VMSCluster内で実行されているプロセスは、リソースのロックを取得できます。ロックには6つのモードがあり、これらによって付与される排他性のレベルが決まります。ロックを上位または下位のロックモードに変更することも可能です。すべてのプロセスがリソースのロックを解除すると、そのリソースに関するシステムの情報は破棄されます。

  • Null (NL)。リソースへの関心を示しますが、他のプロセスによるロックを妨げるものではありません。NLの利点は、どのプロセスもリソースをロックしていない場合でも、リソースとそのロック値ブロックが保持されることです。
  • 同時読み取り（CR）。リソースの読み取り（更新は不可）を要求します。他のプロセスによるリソースの読み取りまたは更新は許可しますが、排他アクセスは許可しません。これは通常、上位レベルのリソースで使用され、下位レベルのリソースに対してより制限の厳しいロックを取得できるようにします。
  • 同時書き込み（CW）。リソースの読み取りと更新を行うことを示します。他のプロセスによるリソースの読み取りまたは更新は許可されますが、排他アクセスは許可されません。これは通常、上位レベルのリソースで使用され、下位レベルのリソースに対してより制限の厳しいロックを取得できるようにします。
  • 保護された読み取り（PR）。これは従来の共有ロックであり、リソースの読み取りを希望する一方で、他のユーザーによる更新を阻止します。ただし、他のユーザーもリソースを読み取ることは可能です。
  • 保護書き込み（PW）。これは従来の更新ロックであり、リソースの読み取りと更新を要求し、他のユーザーによる更新を阻止します。ただし、同時読み取りアクセス権を持つ他のユーザーは、リソースを読み取ることができます。
  • 排他ロック（EX）。これは、リソースへの読み取りと更新アクセスを許可し、他のユーザーによるアクセスを一切禁止する従来の排他ロックです。

次の真理値表は、各ロック モードと他のロック モードとの互換性を示しています。

モードオランダCRCW広報パスワード元
オランダはいはいはいはいはいはい
CRはいはいはいはいはいいいえ
CWはいはいはいいいえいいえいいえ
広報はいはいいいえはいいいえいいえ
パスワードはいはいいいえいいえいいえいいえ
元はいいいえいいえいいえいいえいいえ

ロックの取得

プロセスは、ロック要求をキューに登録することで、リソースのロックを取得できます。これは、I/Oを実行するために使用されるQIO技術に似ています。キューに登録されたロック要求は、同期的に完了するか、非同期的に完了するかのいずれかです。同期的に完了する場合、プロセスはロックが付与されるまで待機します。非同期的に完了する場合、ロックが取得された時点でASTが発生します。

ブロッキングASTを確立することも可能です。これは、あるプロセスがロックを取得し、別のプロセスによるリソースへのアクセスを妨げているときにトリガーされます。元のプロセスは、必要に応じて、他のプロセスによるアクセスを許可するためのアクション（例えば、ロックの降格や解放）を実行できます。

値ブロックをロックする

各リソースにはロック値ブロックが関連付けられています。このブロックは、リソースのロック（ヌルロックを除く）を取得したすべてのプロセスによって読み取ることができ、保護された更新ロックまたは排他ロックを取得したプロセスによって更新できます。

アプリケーション設計者が選択したリソースに関する任意の情報を保持するために使用できます。典型的な用途は、リソースのバージョン番号を保持することです。関連付けられたエンティティ（例：データベースレコード）が更新されるたびに、ロックの所有者はロック値ブロックをインクリメントします。別のプロセスがリソースを読み取りたい場合、適切なロックを取得し、現在のロック値と、プロセスが最後にリソースをロックした時の値を比較します。値が同じ場合、プロセスは関連付けられたエンティティが前回の読み取り以降更新されていないことを認識し、再度読み取る必要はありません。したがって、この手法は、データベースなどのアプリケーションで さまざまな種類のキャッシュを実装するために使用できます。

デッドロック検出

1つ以上のプロセスがリソースのロックを取得すると、各プロセスが他のプロセスによるロック取得を妨害し、いずれのプロセスも処理を続行できなくなる状況が発生する可能性があります。これはデッドロックと呼ばれます（EWダイクストラはこれを「デッドリー・エンブレム」と呼びました）。[1]

簡単な例として、プロセス1がリソースAの排他ロックを取得し、プロセス2がリソースBの排他ロックを取得した場合を考えてみましょう。プロセス1がリソースBのロックを取得しようとすると、プロセス2がロックを解除するまで待機する必要があります。しかし、プロセス2がリソースAのロックを取得しようとすると、両方のプロセスは互いに永久に待機することになります。

OpenVMS DLMは定期的にデッドロック状況をチェックします。上記の例では、あるプロセスによる2回目のロックエンキュー要求がデッドロック状態を返します。この場合、デッドロックを解決するためのアクション（この場合は、取得した最初のロックを解放すること）は、このプロセスが行うことになります。

Linuxクラスタリング

Red HatとOracle はどちらも、Linux用のクラスタリング ソフトウェアを開発しています。

OCFS2（Oracle Cluster File System）は、 2006年1月にバージョン2.6.16で公式Linuxカーネルに追加されました[2]。OCFS2のアルファ品質コード警告は2.6.19で削除されました。

Red Hatのクラスタソフトウェア（DLMとGFS2を含む）は、 2006年11月にバージョン2.6.19でLinuxカーネル[3]に正式に追加されました。

どちらのシステムも、由緒あるVMS DLMをモデルにしたDLMを使用しています。[4] OracleのDLMはよりシンプルなAPIを備えています。（コア関数にはdlmlock()8つのパラメータがありますが、VMSSYS$ENQサービスとRed HatのDLMはdlm_lockどちらも11個のパラメータがあります。）

その他の実装

その他の DLM 実装には次のものがあります。

  • Googleは、疎結合分散システム向けのロックサービスであるChubbyを開発しました。 [5]これは粗粒度のロック向けに設計されており、限定的ながらも信頼性の高い分散ファイルシステムも提供します。Google File System、Bigtable、MapReduceなど、Googleのインフラストラクチャの主要部分は、共有リソースへのアクセスを同期するためにChubbyを使用しています。Chubbyはロックサービスとして設計されましたが、現在ではGoogle社内でDNSに代わるネームサーバーとして広く利用されています。[5]
  • Yahooで開発されたApache ZooKeeperはオープンソースソフトウェアであり、分散ロック[6]にも使用できます。
  • Etcdはオープンソースソフトウェアであり、CoreOSでApacheライセンスの下で開発されています。[7] 分散ロックの実行にも使用できます。[8]
  • Redisはオープンソースで、Redis Source Available Licenseライセンスの高度なキーバリューキャッシュとストアです。[9] Redisは分散ロック管理のためのRedlockアルゴリズムを実装するために使用できます。[10]
  • HashiCorpによって作成されたHashiCorpのConsul [ 11]はオープンソースソフトウェアであり、分散ロックを実行するためにも使用できます。
  • Taooka分散ロックマネージャ[12]は、デッドロックを回避するために「try lock」方式を使用します。また、各ロックのTTLをナノ秒精度で指定することもできます。
  • DLM は、OpenSSIなどのより野心的な単一システム イメージ(SSI) プロジェクトの重要なコンポーネントでもあります。

参考文献

  1. ^ Gehani, Narain (1991). Ada: 並行プログラミング. Silicon Press. p. 105. ISBN 9780929306087。
  2. ^ kernel/git/torvalds/linux.git - Linuxカーネルソースツリー[ permanent dead link ] . Kernel.org. 2013年9月18日閲覧。
  3. ^ kernel/git/torvalds/linux.git - Linuxカーネルソースツリーarchive.todayに2012年7月18日にアーカイブ。Git.kernel.org (2006年12月7日). 2013年9月18日閲覧。
  4. ^ OCFS2ファイルシステム. Lwn.net (2005年5月24日). 2013年9月18日閲覧。
  5. ^ ab Google Research Publication: Chubby Distributed Lock Service. Research.google.com. 2013年9月18日閲覧。
  6. ^ [1]. Zookeeper.apache.org. 2013年9月18日閲覧。
  7. ^ "CoreOS". coreos.com .
  8. ^ etcd: 分散システムの最も重要なデータのための信頼性の高い分散キーバリューストア、CoreOS、2018年1月16日、 2016年9月20日取得
  9. ^ redis.io http://redis.io/ . 2015年4月14日閲覧。 {{cite web}}:欠落または空|title=(ヘルプ) [タイトルがありません]
  10. ^ 「Redisによる分散ロック – Redis」redis.io . 2015年4月14日閲覧。
  11. ^ Consulの概要。2015年2月19日閲覧。
  12. ^ Taooka の説明 Archived 2017-05-03 at the Wayback Machine 2017-05-04 に取得。
  • HP OpenVMS システムサービスリファレンスマニュアル – $ENQ
  • Officer - Rubyで書かれたシンプルな分散ロックマネージャー
  • FLoM - シェルコマンド、スクリプト、カスタム開発されたC、C++、Java、PHP、Pythonソフトウェアを同期するために使用できる無料のオープンソース分散ロックマネージャー
Retrieved from "https://en.wikipedia.org/w/index.php?title=Distributed_lock_manager&oldid=1305048094"