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