Transcript The Chubby lock service

The Chubby lock service
for loosely-coupled distributed
systems
Chubby の概要
• 高信頼ストレージから構成される
疎結合型分散システム
• 荒い粒度 (coarse-grained) の
ロッキングを提供する
• 設計上の課題はパフォーマンスを
阻害する有効性と信頼度
ロック・サービスの目的
• クライアントのアクティビティを同期し
環境に関わる情報を一致させる
Chubby の目標
• 多くのクライアントに信頼性を有効性を
提供する
• 分かり易いセマンティックスに基づく
• スループットと記憶容量は２次的な目標
Chubby のインターフェース
•
•
•
•
ファイルシステム・インタフェースと似ている
ファイル全体に対するリード・ライト
アドバイザリ・ロック
イベント通知（ファイル更新時など）
Chubby の用途
• システム間での粒度の粗い同期処理
• 特に複数の等価なサーバーの中から
リーダーを選択する問題の解決
• 実際には…
–
–
–
–
GFS はマスター・サーバーを予約するために Chubby のロックを使用する
Bigtable ではマスターの選択、マスターによる制御可能なサーバーの探索、
クライアントによるマスターの探索などに Chubby を使用する
GFS や Bigtable では少量のメタ・データを格納する周知された格納場所として
Chubby を使用している
→ 分散データ構造のルートとして効果的に活用
– 複数のサーバーの間での（粒度の粗い）分割作業のためにロックを活用する
様々なサービスもある
Chubby による改善
• アドホックなプライマリ選択（容易に複製が可能な場
合）
→ 処理効率を少し改善した
• オペレータによる介入（正確性が求められる場合）
→ 障害発生時にもオペレータによる介入を必要としない
Chubby における技術的課題
• 分散環境で複数ピアからプライマリーを選択する問題は…
– 分散合意問題の実例
– 非同期型コミュニケーションを使った解決策が必要
• 分散合意問題を非同期的に解決するのは Paxos プロトコル
＃ Paxos protocol
○ 設計
・Paxos プロトコル・ライブ
ラリ vs ロック・サービス
•
→ ロック・サービスには幾つかの点
で優位性がある
• - サービス開発者は利用可能性を考慮
しないことが多い
–
→ Paxos プロトコルのために既存コー
ドを改変するよりも
–
ロック・サービスを利用するほうが容
易
•
- ロック・サービスは結果を告知する
・Chubby を設計する上での
選択
•
- ライブラリや合意サービスではなく
ロック・サービスを選択する
• - 選択されたプライマリにそれ自身と
そのパラメータの告知を許すために
•
別のサービスを構築・維持するので
はなく小さなファイルを提供する
• - 想定する使用条件に基づく選択は…
–
–
- 可能な限り少数のサーバーで
数 千 の ク ラ イ ア ン ト に あ る Chubby
・システム構造
•
- Chubby の コ ン ポ ー ネ ン ト は サ ー
バーとライブラリから構成される
- Chubby cell
•
- 複数のサーバー（通常は５台）で
Chubby Cell を形成する
•
- Chubby cell を構成するサーバーは
レプリカと呼ばれる
- マスターとレプリカ
•
•
•
•
•
- レプリカは合意プロトコルを使用し
てマスターを選択する
- マスターは過半数のレプリカからの
投票を獲得する必要がある
- マスターはマスター・リースの間、
マスターであり続けることを約束す
る必要がある
- 次の投票でも同じマスターが過半数
を獲得すれば、
- データベース
•
- 全てのレプリカがシンプルなデータ
ベースを維持している
•
- マスタだけがデータベースのリー
ド・ライトを起動する
•
- それ以外のレプリカはマスターから
合意プロトコルで送られる更新をコ
ピーする
- クライアントとマスターの
間の通信
•
•
•
•
•
- クライアントは DNS にリストされ
ている
レプリカにマスター探索リクエスト
を送ってマスターを探索する
- マスターでないレプリカがマスター
探索リクエストを受け取った場合には、
マスターの識別子を返す
- マスターがマスター探索リクエスト
を受け取った場合には、
- マスターとレプリカの間の
通信
•
- ライト・リクエストは合意プロトコ
ルを介して全てのレプリカに伝播され、
•
セル内の過半数のレプリカに到達し
た場合のみリクエストは認められる。
•
- リード・リクエストはマスターのみ
で解決される
- 障害発生時の動作
•
•
•
•
•
•
- マスターに障害が発生した場合、
他のレプリカにより選択プロトコル
が実行される
- レプリカに障害が発生し数時間以内
に回復しない場合、
置換システムがフリープールから新
たなマシンを選び
ロック・サーバーを起動する
- ロック・サーバーを起動した後
・Chubbyのインターフェース
•
- Chubby は Unix を更に単純にした
ファイルシステム・インターフェース
を備える
• - アプリケーションは Chubby の専用
ＡＰＩだけでなく、
•
他のファイルシステムを経由して
Chubby にアクセスすることができる
• - 分散化を容易にするため Chubby の
ファイルシステムは以下の点で Unix と
・ノード
•
- 名前空間にはファイル、ディレクト
リのいずれかしか存在しない
–
- ハード・リンクやシンボリック・リン
クはサポートされない
– - ファイルとディレクトリを会わせて
ノードと呼ぶ
•
- 永続的 (permanent) なノードと暫定
的 (ephemeral) なノードが存在する
–
- いずれも明示的な削除が可能
・メタデータ
•
- ３種類のアクセス制御リストの名前
–
–
–
–
•
- リード・アクセス用
- ライト・アクセス用
- ＡＣＬ変更用
- Chubby の ア ク セ ス 制 御 リ ス ト は
Plan9 のグループと似ている
- ４種類の単調増加する６４ビットの
番号
–
- インスタンス番号 -- 同名の以前の
・ハンドル
• - Chubby ではファイルアクセスのため
の抽象化キーとしてハンドルを使う
•
- Unix のファイル・ディスクリプタ
に相当する
•
- ハンドルは次のような情報を保持し
ている
–
–
- チェック番号:
ハンドルの作成や推測からクライアン
・ロック
•
•
•
•
•
- Chubby ノード（ファイル and ディ
レクトリ）はロックをサポートする
- 排他ロック（ライト・モード）と共
有ロック（リード・モード）
- ア ド バ イ ザ リ ・ ロ ッ ク (advisory
lock)
- いずれのモードのロックを獲得する
にもライト・パーミションが必要
- ロックの実装には仮想同期 (virtual
＃
仮 想 同 期
synchrony)
(virtual
・シーケンサー
•
•
•
•
•
-ロック獲得直後の状態を表す解析不
能のバイト列
- 独立したサーバーが Chubby を利
用して
ロックをサポートする場合に使用
される
- シーケンサーは次のような情報を
保持している
- ロック名
・ロック・ディレイ
•
- ロック可能状態に回復するための遅
延時間
•
- ロック保持者の障害により対象
ノードのロックが解放された場合に使
用される
•
- ロック解放後、ロック・ディレイ
の期間はロック獲得はできない
•
- ロック・ディレイは Chubby が設
定する上限の範囲で任意に設定できる
・イベント
•
- ハンドルを介してイベントを購読す
ることができる
• - イベントはクライアントへ非同期的
に送られる
• - 次のようなイベントが含まれる
–
–
–
–
- file contents modified
- child node added, remove, modified
- chubby master failed over
- a handle (and its lock) has become
・ハンドルの生成
•
•
- Open でハンドルが生成される
- ハンドルの名前はディレクトリ・ハ
ンドル相対で指定される
• - ハンドル生成時には次のオプション
が指定できる
–
- ハンドルの用途（リード、ライト、
ロック、ＡＣＬ変更）
– - 配送されるべきイベント
– - ロック・ディレイ
・ＡＰＩ
•
- Chubby API はクライアントのハンド
ルに対する操作を規定している
• - 以下のエントリがサポートされる
–
–
–
–
- Open -- ハンドルを生成する
- Close -- ハンドルを破壊する
- Poison -- ハンドルを無効化する
- GetContentsAndStat -- ファイルのコン
テンツとメタデータを取得する
– - GetStat -- ファイルのメタデータを取
・ＡＰＩの利用例
•
- クライアントはこのＡＰＩを使って
次のような手順で
•
他のサービス・サーバーのプライマ
リ選択を実行することができる
–
- 全てのプライマリの候補は（同一の）
ロック・ファイルに対し
–
ロック獲得を試みる
– - その結果、１つの候補だけがプライマ
リになり、
・キャッシング
•
•
•
•
•
- Chubby クライアントはキャッシン
グを行う
- ファイル・データとノードのメタ・
データがキャッシュされる
- キャッシュはコンシステント・ライ
トスルー・キャッシュである
- キャッシュはリース・メカニズムに
よって管理される
- マスターから送られる失効通知によ
・ファイル・データやメタ・
データが変更された場合…
•
•
•
•
•
- マスターはキャッシュしている可能
性のある
全てのクライアントに失効を通知す
る
- マスターが失効通知を行っている間
は変更はブロックされる
- このメカニズムは KeepAlive に実装
される
- 失効通知を受け取ったクライアント
・キャッシュ・データを無効
化する理由は…
•
- キャッシングを行っているクライア
ントへの不要な更新を回避できる
•
- 全てのメッセージにシーケンス番号
を必要とするメカニズムは不適当
・ハンドルのキャッシング
•
- Chubby はオープン中のハンドルの
キャッシングも行う
–
→ クライアントが既にオープンされて
いるファイルを
–
何度もオープンする場合は１回目だ
け RPC を行う
•
- クライアントのセマンティックスを
制限するため以下の制限がある
–
- アプリケーションが短命ファイルを
クローズした場合
・ロックのキャッシング
•
•
•
•
•
- クライアントが何度もロック獲得を
すること想定して
必要とするよりも長くロックを保持
することができる
- イベントにより他のクライアントが
ロックの
獲得要求を行ったことを知ることが
できるので、
他で必要になった時のみロックを解