GFSについての箇条書きメモ

Google File System
Google独自の分散ファイルシステム
多数のマシンを組み合わせて巨大なストレージを作る
複数のマシンが動作する事で効率的なデータ転送
膨大なデータの通り道
扱われるファイルが巨大
新しいデータをどんどん書き加えるか、読み出し続けるか
GFS(データの読み出し)→アプリケーション(データ加工)→GFS(データ書き込み)
データ転送に特化される設計
GFS上では、ファイルは常にバックアップされた状態
大きなファイル(数百MB)を一気に流し込む
データを書き換えしない
ファイルロック(排他制御)を行なわない
- ファイルをキューとして用いる
ファイル操作のためのインタフェース
- Create (作成)
- Delete (削除)
- Open (オープン)
- Close (クローズ)
- Read (読み込み)
- Write (書き込み)
- Snapshot (スナップショット)
  - ファイルの複製
- Record Append (レコード追加)
  - ひとまとまりのデータを最後に追加
ファイルは自動的に複製される
マスタ(Master)、チャンクサーバ(Chunk Server)、クライアント(Client)の３つの要素で構成される
- Master・・・GFS全体の状態をコントロールする中央サーバ
- Chunk Server・・・ハードディスクへの入出力を担当
- Client・・・ファイルを読み書きするアプリケーション
ファイルはチャンク(64MB)の単位に分割される
チャンクは通常３つのチャンクサーバにコピーされる
マスタは、どのチャンクサーバにどのチャンクがあるのかを把握している
クライアントはまずマスタに問い合わせる
マスタは、チャンクサーバの情報をクライアントに送る
以後、クライアントとチャンクサーバ間で読み書きが行なわれる
読み込みは最寄りのサーバから
- IPアドレスが距離に応じて割り当てられている
- 負荷によっては、マスタはチャンクのコピーを増やす
書き込みは複数サーバへ
- マスタは、まとめ役のチャンクサーバを決定する(プライマリの決定)
- クライアントには、プライマリなチャンクサーバを伝えられる
- クライアントは、要求するチャンクをチャンクサーバに送る(プライマリに限らない)
- バケツリレーの様にチャンクサーバ間でチャンクをコピー
- データ送信終了後、クライアントはプライマリにデータ書き込みを要求
- プライマリは、手元のチャンクを書き込み、セカンダリに書き込み要求
- 書き込み終了後、クライアントに通知
様々なエラーへの対応
- チャンクサーバの故障
- ハードディスクの問題
プライマリが失敗したとき
- クライアントがはじめからやり直す
- マスタが新しいプライマリを決定する
セカンダリが失敗のとき
- プライマリとセカンダリでチャンク内容が異なる状況
- チャンクにつけたシリアルナンバーをマスタに通知
- 古いデータを読み込んでしまう様な、読み書きを同時に行なうアプリケーションは、「レコード追加」で対処
同時書き込みで不整合が起こる
レコード追加によるアトミックな書き込み
レコード追加は、中断されることなく一度に行なわれる(アトミック)
レコードは、ファイルの末尾に追加されていく
レコードは、一回以上書き込まれる事を保証している
書き込みに失敗した場合、もう一度ファイルの末尾に新しい領域を確保するところからやり直し
読み出し側で失敗した箇所を読み飛ばす
スナップショットはコピーオンライトで高速化
- ファイルの情報(チャンクの場所など)を持っているマスタの中で、ファイル情報をコピー
- チャンクの内容を書き換えるタイミングでチャンクがコピーされる(コピーライトオン)
マスタの持つ情報
- ファイル名とそれを構成するチャンクリスト
- チャンクサーバがどこにあり、今どのような状態か
- どのチャンクサーバがどのチャンクを持っているか
マスタはGFS全体を最適化する
チャンクの障害対策
- チャンクを保存する時、チェックサムを取る
マスタの障害対策として、オペレーションログを記録している
データ管理の基盤として動く