More Related Content
Similar to 生物データベース論（分散ファイルシステム概論）
Similar to 生物データベース論（分散ファイルシステム概論） (20)
生物データベース論（分散ファイルシステム概論）
- 1. 平成２３年度生命情報科学科 生物データベース論 分散ファイルシステム概論 (9/13) 笠原 雅弘 mkasa＠cb.k.u-tokyo.ac.jp 東京大学 大学院新領域創成科学研究科 情報生命科学専攻
- 2. 公開版作成にあたって • 以下の事項は仕様です。 – 音声はありません。 – 授業中に判明した typo 等は修正しました。 – 字が細かいのは、この資料単独で自習できるように 授業中はスライドに書かず喋った部分などを追加し ているからです。 – アニメーションを解除するために、パラパラ漫画的な 冗長なスライドが増えています。 • 間違い・提案・コメントなどがありましたらメール やコメント欄で連絡を下さい。歓迎です。
- 3. （非分散）ファイルシステムが 満たして欲しい耐障害性 • たとえ書き込み中に停電でサーバーの電源が切れても ファイルシステム全体が壊れてはいけない。 • 書き込んだか、書き込んでないか、かならずどちらかの 状態になること。ゴミは残さない。 ファイルサーバー ファイル A ファイルサーバー 停 電 追記されなかった。 ファイル A で ファイル A への追記 ク どちらかに ファイルサーバー 書き込み中 ラ なって欲しい ッ ファイル A シ ファイル A 追記された。 ュ への追記 ！
- 4. 古いファイルシステムの場合 ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー ファイル A ファイル A ファイル A ファイル A ファイル A ファイル A ゴミ への追記分 への追記分 ファイルサイズを 追記分を実際に ファイルの更新日 追記分だけ増やす 書き込む やサイズを更新 クラッシュ クラッシュ ファイルサーバー ファイルサーバー ファイル A ファイル A ファイル A ゴミ への追記分 ゴミが残ってしまう ファイルの更新日 がもとのまま。
- 5. MS-DOS(FAT)の場合 もう少し詳しく ファイル¥Aに追記するときに書き込まなければならない 領域はどこ？ このへんは空きエリアとしよう M F FAT root B SI FAT A R S 複製 dir FATが壊れたときに手動で復元 できるように複製をとってある。 M F FAT root A B SI FAT A R S 複製 dir 追加 どこの空きエリアをファイルA 追加したデータも当然書き込み 用に使ったか記録する ファイルサイズと更新日を更新しなきゃ
- 6. MS-DOS(FAT)の場合 もう少し詳しく ファイル¥Aに追記するときに書き込まなければならない 領域はどこ？ このへんは空きエリアとしよう M F FAT root B SI FAT A R S 複製 dir FATが壊れたときに手動で復元 できるように複製をとってある。 M F FAT root A B R 何をどういう順番で書き込んでも SI S FAT 複製 dir A 追加 書き込み中に電源が切れたら ファイルサイズを更新しなきゃ どこの空きエリアをファイルA どこかで不整合出ます。 用に使ったか記録する 追加したデータも当然書き込み ファイルサイズと更新日を更新しなきゃ
- 7. ファイルシステムが 満たして欲しい耐障害性（再） • たとえ書き込み中に停電でサーバーの電源が切れても ファイルシステム全体が壊れてはいけない。 • 書き込んだか、書き込んでないか、かならずどちらかの 状態になること。 ファイルサーバー ファイル A ファイルサーバー 停 日付もサイズ も元のまま。 電 追記されなかった。 ファイル A で ファイル A への追記 ク どちらかに ファイルサーバー 書き込み中 ラ なって欲しい ッ ファイル A シ ファイル A 追記された。 ュ への追記 ！ 日付もサイズ もばっちり。
- 8. ジャーナリング • ジャーナリング＝データベースの技術を用いて ファイルシステムに故障耐性を持たせる • ファイルに変更を加える場合には Write Ahead Log (WL) に「ログ」を書き、実際の変更を加える。 ファイルサーバー ファイルサーバー ファイルサーバー ファイル A ファイル A ファイル A ファイル A への追記 Write Ahead Log Write Ahead Log Write Ahead Log HDDへの書き込みは 最初にログ書き。 WALに書き終わり、 追記作業が終わったら セクタ単位でアトミッ 途中で電源が 直後に電源が切 WAL は消しても良い。 クと見なせる。万一 切れたらファイル れたら次回起動時 （実際には消さずに次 途中で書き込み終了 は書き込まれてい にWALに書かれた のWAL用領域として使 してもECC/CRCエラー。 変更を加える。 われる。） ない状態になる。
- 9. メタデータジャーナリングと データジャーナリング • メタデータジャーナリング 普通に使われている。 – 「ファイル名・ファイルサイズ・更新日・ファイルの 内容をディスクのどこに保存しているか」など、 ファイルの内容以外（メタデータ）の変更を ジャーナリングで保護。 • データジャーナリング スピード半分になるのでデフォルトOFF でオプションになっているのが普通。 – メタデータに加えてファイルの内容について 変更を全てジャーナリングで保護。 ※ちょっと脱線： xfs のような、ログを外部SSDに書き込める ファイルシステムはログをSSDに設定すると快適です。
- 10. 分散ファイルシステムが どうして難しいのか？ 「あるファイルA」の整合性を維持するために 異なるマシン上のデータの整合性を維持しなくてはならない。 サーバー数が増えるので故障率が桁違い。 ファイルサーバー （データ） ファイルサーバー ファイル A （メタデータ） Aのメタデータ ファイルAに追記するに は少なくとも２カ所を 同時に書き換えなくて はならない。 実際にはレプリケーションした 「ファイルAの複製」や、性能向上の ための「Aのメタデータのキャッシュ」 がいろいろなマシンに散らばって いるので２カ所どころではない。
- 11. ディスクの故障頻度を見積もろう • 2TB のプチ高級 SATA HDD を買ってきました。 – カタログスペックでは１０年に１度の故障頻度。 • 1000台繋げて分散ファイルシステム作成。 – 10年/回 × 1000 = 3.7日/回 なので １週間に２台は壊れる計算。 （実際にはカタログスペック以上に壊れる。） • １年に１回ハングアップするサーバーを 100台で分散ファイルシステムを作ると、 – 3.56日/回で不具合発生？
- 12. レプリケーションの例４（再） • Google File System, Gfarm, GlusterFS, Amazon S3 のような ファイルシステムでは、ファイルをレプリケーションすること でスループットの向上や耐故障性向上を狙っている。 ファイルサーバー1 ファイルサーバー2 ファイルサーバー3 ファイルサーバー4 ファイルサーバー5 ファイルA ファイルA ファイルA ファイルA ファイルB ファイルB ファイルB ファイルB ファイルC ファイルC ファイルC ファイルD ファイルD ファイルD ファイルD 故障 レプリカ数が足りなくなったら ファイルを複製してファイルの数を 一定に保つ。
- 13. Google File System この２台はメモリ大容量＋高信頼性 サーバーを使い、滅多に壊れない ことを仮定する。 ファイルサーバー ファイルサーバー ファイルAはどこ (メタデータ) (メタデータのログ＋待機) にあるの？ クライアント ファイルAに 書き込み完了 追記終わった。 追記よろしく！ ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー (データ) (データ) (データ) (データ) (データ) ファイルAに ファイルAに 追記よろしく！ 追記よろしく！ 主レプリカ 副レプリカ 副レプリカ 詳しくは [Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung, The Google File System, 19th ACM Symposium on Operating Systems Principles, Lake George, NY, October, 2003.] を読もう。
- 14. Google File System この２台はメモリ大容量＋高信頼性 サーバーを使い、滅多に壊れない ことを仮定する。 ファイルサーバー ファイルサーバー ファイルAはどこ (メタデータ) (メタデータのログ＋待機) にあるの？ クライアント ファイルAに 時間内に終わらなかっ たので追記失敗！ 追記よろしく！ ファイルサーバー ファイルサーバー ファイルサーバー 故障 ファイルサーバー ファイルサーバー (データ) (データ) (データ) (データ) (データ) ファイルAに ファイルAに 追記よろしく！ 追記よろしく！ CAP定理を思い出せ。 レプリカの位置を 主レプリカ 副レプリカ 副レプリカ 変更すれば障害は 解消されるが、 時間が必要。
- 15. Google File System ログを再生してこちらを 万一メタデータサーバーが壊れた場合は？ メインのサーバーにする。 （時間はかかるが復旧自体はできる。） （DNS切り替え） ファイルサーバー ファイルサーバー ファイルAはどこ (メタデータ) (メタデータのログ＋待機) にあるの？ クライアント 故障 ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー (データ) (データ) (データ) (データ) (データ)
- 16. Google File System 複数クライアントが同時に追記 「主レプリカ」に最初に書き込む ルールなので、追記したデータ クライアントY の順番がレプリカ間でも保たれる。 クライアントX 完了 完了 Append Append Write Write ファイルサーバー ファイルサーバー ファイルサーバー (データ) (データ) (データ) クライアントXが一瞬早かった ファイルAに ファイルAに からX をYより先に書き込み 追記よろしく！ 追記よろしく！ 主レプリカ 副レプリカ 副レプリカ どのレプリカにも追記できるとすると 一貫性が犠牲に。
- 17. GlusterFS ファイルサーバー（データ）のリストはあらかじめ全ての クライアントに持たせておく。メタデータサーバーは無い。 ファイル名（パス名）のハッシュ値からどのファイルサー バーに書き込むかを一意に決定するため、メタデータサー バーが無くてもファイルの分散配置が可能。 （レプリケーション無しの場合） クライアント ファイルAの（ファイル名の）ハッシュ値 から求めた ここのサーバーに書き込む！ クライアント ファイルサーバー ファイルサーバー ファイルサーバー ファイルサーバー (データ) (データ) (データ) (データ)
- 18. 現状の分散ファイルシステムで 達成できていること • 耐故障性 – レプリケーションと WAL でなんとかなっている。 – 「レプリカが全部同時に壊れる」 「メタデータサーバーとログを持っている バックアップサーバーが同時に壊れる」などの 悲惨な（確率の低い）パターン以外は復旧できる。 • スケーラビリティ – メタデータサーバー以外は台数をどんどん増やせる。 – レプリケーションすれば読み書きの帯域もどんどん 増やせる。
- 19. 現状の分散ファイルシステムで きちんと達成していないこと • 一貫性とパフォーマンスの両立。 – Consistency: 複数のクライアントから同じファイル が見えること。 – Performance: 非分散ファイルシステムと比べて極 端に遅くないこと。 ＋小さなファイルをたくさん高速に扱うこと。
- 20. Consistency（再） 全てのクライアントから同じものが見えること レプリケーション データA データA データAを クライアント クライアント データBに Aを貰った Aを貰った クライアント クライアント 更新 Aを貰った Aを貰った データB データB Consistency クライアント クライアント データの更新があっても全 Bを貰った てのクライアントが同じ Bを貰った データを見ることができる クライアント クライアント こと。 Bを貰った Bを貰った
- 21. 現実でありがちなこと レプリケーション データA データA データBを書き込む！ データAを クライアント データBに 更新 コピー中 データB データA クライアント クライアント Bを貰った Aを貰った クライアント クライアント Bを貰った Aを貰った Consistency が ない。
- 22. 複数のマシンで一貫性を保つには レプリケーション データA データA データBを書き込む！ クライアント 解決１）コピー中はずっとAを見せておく 解決２）コピー中は読み込み不可にする データB データB データB データB データA データA コピーが完了したら一気に切り替える 今コピー中 データくれ！ だから データB データB 終わるまで ちょっと待って。 クライアント
- 23. 複数のマシンで一貫性を保つには レプリケーション データA データA データBを書き込む！ クライアント 解決１）コピー中はずっとAを見せておく 解決２）コピー中は読み込み不可にする データB データB データB データB データA データA コピーが完了したら一気に切り替える 今コピー中 データくれ！ だから データB データB 終わるまで ちょっと待って。 クライアント 故障の可能性を考えるとコピー完了を伝えるのが難しい。
- 24. 二人の将軍問題 (Two Generals’ Problem) • 山に陣取る２人の将軍が居る。両者の軍が同時に 挟み撃ちで都市を攻めれば勝てるが、まだ突撃時刻を 取り決めていない。メッセージを送るには人が手紙を 運ぶしかないが、途中で捕らえられる可能性がある。 将 将 一人で戦ったら 軍 都市 軍 反対側は遠すぎて 都市倒せないアルね！ 見えないでござる 各個撃破してやる！
- 25. 二人の将軍問題 (Two Generals’ Problem) • 山に陣取る２人の将軍が居る。両者の軍が同時に挟み撃ちで都市を攻めれば勝てるが、 まだ突撃時刻を取り決めていない。メッセージを送るには人が手紙を運ぶしかないが、 途中で捕らえられる可能性がある。 将軍達にとって理想のケース がってん 将 都市 将 明日の朝９時に 軍 軍 攻撃すると伝えてくれ。 明日の朝９時に 将 都市 将 攻撃か。了解した。 軍 軍 将 将 朝９時だ。突撃 軍 都市 軍 朝９時だ。突撃 ぎゃー。
- 26. 二人の将軍問題 (Two Generals’ Problem) • 山に陣取る２人の将軍が居る。両者の軍が同時に挟み撃ちで都市を攻めれば勝てるが、 まだ突撃時刻を取り決めていない。メッセージを送るには人が手紙を運ぶしかないが、 途中で捕らえられる可能性がある。 ありがちなケース がってん 将 都市 将 明日の朝９時に 軍 軍 攻撃すると伝えてくれ。 ぎゃー、捕まった。 将 都市 将 軍 軍 将 将 突撃はいつにしよう。 軍 都市 軍 朝９時だ。突撃 返り討ちにしてくれるわ！
- 27. 生まれ変わった来世の将軍 がってん 将 都市 将 明日の朝９時に 軍 軍 攻撃すると伝えてくれ。 ワシはもう学習した。 都市 同じ轍は踏まない。 明日の朝９時に 将 将 使者が捕まっていたら大変。 攻撃か。了解した。 軍 軍 使者が戻ってきたら突撃しよう。 将 将 使者が戻ってきた！ 突撃準備♪ 軍 都市 軍 皆のもの、突撃準備だ。 将 将 朝９時だ。突撃 軍 都市 軍 朝９時だ。突撃 ぎゃー。
- 28. もっともっとありがちなケース がってん 将 都市 将 明日の朝９時に 軍 軍 攻撃すると伝えてくれ。 ワシはもう学習した。 都市 同じ轍は踏まない。 明日の朝９時に 将 将 使者が捕まっていたら大変。 攻撃か。了解した。 軍 軍 使者が戻ってきたら突撃しよう。 将 将 使者が戻ってこないな。 突撃準備♪ 軍 都市 軍 突撃はとりやめじゃ。 ぎゃー、捕まった。 将 将 朝９時だ。突撃 軍 都市 軍 次の使者を送ろう。 返り討ちにしてくれるわ！
- 29. 疑心暗鬼なケース がってん 将 都市 将 明日の朝９時に攻撃する。ただし、 こちらに使者が戻ってきたらそちらに 軍 軍 「使者が戻ってきた」ともう一度連絡す るからそれまで待って欲しい。 明日の朝９時了解。 将 都市 将 使者はもう一度来るの了解。 軍 軍 突撃準備はするけど、 本当に突撃するかは 将 将 おー。相手には伝わったか。で は「伝わったことがこちらに伝 まだ決まってない。 軍 都市 軍 わった」と伝えてきてくれ。 がってん ９時になったら 使者こないな。 将 将 突撃だぞー。 軍 都市 軍 みんな準備だ。 突撃やめるか。 ぎゃー、捕まった。
- 30. 確実に２人の将軍が突撃する時刻について 同時に了解するまで動けないとすると 実際には何もできない。 明日の朝９時に攻撃する。ただし、 こちらに使者が戻ってきたらそちらに 「使者が戻ってきた」ともう一度連絡し、 将 都市 将 その使者が戻ってきたら 「使者が２回目に戻ってきた」 軍 軍 とそちらにもう一度連絡し、 その使者が戻ってきたら 「使者が３回目に戻ってきた」 とそちらにもう一度連絡し、 その使者が戻ってきたら ・・・ アホか！ っていうかそれ、 ボクがいつか捕まる だけじゃん！
- 31. 複数のマシンで一貫性を保つには（再） レプリケーション データA データA データBを書き込む！ クライアント 解決１）コピー中はずっとAを見せておく 解決２）コピー中は読み込み不可にする データB データB データB データB データA データA コピーが完了したら一気に切り替える データくれ！ データB 一気 データB 今ロック中 だから待って。 に？！ クライアント
- 32. 二人の将軍問題と レプリケーションデータの書き換え問題 データB データB データA データA 切り替えるよー 片方で切り替えたら データB データB 通信がこないので 切り替えメッセージを データA 切り替えられない 送ると 通信 故障 切り替えたよー 相手から切り替えた データB データB 返事がこないので メッセージを貰って データA 通信 切り替えられない から切り替えると 故障 完璧を目指すのは Consistency を諦めるか ムリなので、どこかで Availability を諦める 多少妥協するしかない。 しかない。
- 33. 2 Phase Commit (2PC) 短期間では故障・非故障状態が変化しないことを仮定して分散システム上で 参加者全員が同時にコミット・非コミットを選択するプロトコル。 データをAからBに 書き換えるよ－。 準備できたら返事して。 コミット要求 調整者 フェーズ 参加者 参加者 参加者 (Coordinator) OK OK OK 全員OKらしいので 決行して～ コミット 調整者 フェーズ 参加者 参加者 参加者 (Coordinator) （コミット）
- 34. 2 Phase Commit (2PC) データをAからBに 書き換えるよ－。 準備できたら返事して。 通信路故障 コミット要求 調整者 フェーズ 参加者 参加者 参加者 (Coordinator) OK OK あるいは ノード故障 返事来ない人いるから 通信路故障 やっぱさっきの無しで。 コミット フェーズ 調整者 参加者 参加者 参加者 （アボート） (Coordinator) このプロトコルでだいたいは一貫性が保たれる。 ノンブロッキングの 故障すると困るのはどのタイミング？ 3 Phase Commit もある。
- 35. 多数決による合意 • 2PC は１台死んでいるマシンが居ると何も コミットできない。 • N台のマシンがあるとき、過半数のマシンに コミットできれば多数決で間違えることはない。 – → Paxos: 過半数のマシン（と通信路）が生きてい れば合意できるアルゴリズム • Google の Chabby などで使われている。 Chabby は Google 社内システムで分散ロックが 必要なありとあらゆる場面で使用されている。
- 36. トランザクションと 分散メタデータ • ファイル名・サイズ・更新日時など （メタデータ）を一貫性を保つ分散形式で 持つとパフォーマンス（スピード）を出しにくい。 • 選択肢は – メタデータは並列にしない。 • NFS(実は一貫性もない), Lustre など – 一貫性を保つが動作が劇重い。 • HSFS? (日立) ※資料が無いので確たることは言えないがメタデータがキャッシュも含めて非分散なら stat １回で平気で1分待たされたりするあの遅さはちょっとあり得ない。 – メタデータサーバー無し。（完全な）一貫性はない。 • GlusterFS など
- 37. キャッシュと ファイルシステムの一貫性 • ネットワークを使ったファイルシステムには９割がた メタデータやデータのキャッシュが付いている。 – キャッシュ一切なしだとスピードが上がらない。 良くてもスピード半分、悪いと 1/20 以下だと思うべし。 – キャッシュはメタデータとデータどちらのタイプもある。 ファイルサーバー データA １読み込み ２書き込み（AをBに上書き） 計算ノード 計算ノード データA のキャッシュ データB ３データを読み込むと ２のタイミングで データAが読み込まれる キャッシュを無効化したい。
- 38. キャッシュの無効化（Invalidate）法 • NFS ver 3 ※Cacheのon/offは制御可能 – 一定期間（e.g., 30秒）で無効になる。 – 一定期間は一貫性が崩れる。 • NFS ver 4, Lustre – マスターサーバーがキャッシュを持っているサーバーを 覚えておいて、変更があったら通知する。 – 同じ（メタ）データを複数の計算ノードから変更すると キャッシュが無いシステムより処理が重くなる。 – NFS v4 は(POSIXで要求する)一貫性を保持していない。 • Google File System – 基本的にキャッシュしない。メタデータは全部サーバー上 でオンメモリなので、CPUとネットワークの性能を高くして 頑張って負荷に耐える発想。 （細かいファイルがたくさんあるとアウト）