INDEX †
概要 †
GPFSは、RS/6000やLinuxクラスタ上でのパラレル共有ファイルシステムを提供する。GPFSは単一マシン上で動作しているPOSIXと同じ挙動を提供する。また、分散ファイルロックやリカバリについても見ていく
目的、問題 †
- 多数のノードからの同時アクセスを提供するファイルシステムが要求される。そのため、GPFSではファイルデータ、メタデータへパラレルにアクセスできる機能を提供する。
- 共有ディスクの実装(SAN, VSD)に依存せずに、スケーラブルな共有ファイルシステムを提供
- 高いスループットを提供するために、ストライピングを行う。
- 複数のノードからのディスクへの読み書きに対し同期を行う必要がある。GPFSでは、分散ロック(distributed locking)を用いて共有ディスクに対するアクセスの同期を行う。これにより、複数ノードからのアクセスに依存することなく、一貫性を保つ。
貢献 †
- データストライピングを行い、並列データアクセスが可能
- ファイルデータやメターデータの一貫性を保ったファイルシステム
- ノード、通信、ディスクの多方面からの耐障害ファイルシステムを提供
提案手法、アイディア、システム †
General Large File System Issues †
データストライピングとアロケーション、プリフェッチとWrite-behind †
- ストライピングをLVMではなく、GPFS上で実装する
- これにより、LVMのLUNによるサイズの制限がない(32-bitの論理アドレスを使用しているため)
- ファイルは分割して保存
- サイズの大きいファイルは等しいサイズに分割(typically 265K,しかし16K - 1Mに設定可能)しラウンド-ロビンで異なるディスクに保存する。
- サイズの小さいファイルやサイズの大きいファイルの最後の半端なブロックはサブブロックという1/32の大きさのブロックに格納する
- 読み込みでは、しかるべきディスクへリクエストを送信し、並列に読み込む。
- これによりネットワークのバンド幅を有効に活用する
- また、さまざまなストライピングパターンを認識、隠蔽しアプリケーションへのインタフェースを提供
- 均質なディスク(容量、性能)を用いたときパフォーマンスが最大
- 不均質な場合スループットと空き容量にトレードオフ。大容量のディスクを使えば、多くのファイルを保存できるが、その分I/Oリクエストが大きくなってしまう。
Large Directory サポート †
- ディレクトリエントリーの管理にextensible hashingと言うものを使用しているらしい。（理解するには他の論文を読む必要がある）
ログとリカバリ †
- 巨大なファイルシステムでは、逐次一貫性の検証をするのは不可能であるため、GPFSでは、一貫性に影響を与える全てのメタデータをjournalやwrite-ahead logへ記録する
- それぞれのノードはマウントされたそれぞれのファイルシステムごとに独立したログをもつ
- このログはリカバリの際、全てのノードから読むことが可能
- ディレクトリブロックとinodeを更新する前にログをディスクへ書き込むので、もしディレクトリブロックを更新しinodeを更新する前にクラッシュしてしまった場合、ログを見ることによってinodeの更新を再開できる。
クラスタ上での並列化とConsistency †
Distributed Locking VS Centralized Management †
- 同期には二つのアプローチがある
- Distributed Locking: 衝突の起こるファイル操作と同期を取るためにそれぞれのファイル操作はロックを取得する必要がある
- Centralized Management: 衝突の起こる全てのファイル操作を特定のノードへ転送し、そのノードがリクエストされた読み込みやアップデートを行う。
- GPFSではファイル操作にDistributed Lockingを採用
- 異なるノードが異なるファイルへ操作を行う際に、並列性が高いため。
- 異なるノードが同一のファイルへ操作を行う再は、ロックの衝突によるオーバーヘッドがCentralized Managementを超える場合もある。
- メタデータ操作ではCentralized Managementを採用
The GPFS Distributed Lock Manager †
- GPFS分散ロックマネージャーはグローバルロックマネージャーを使用し、ローカルロックマネージャーと連携してロックを管理する(きちんと理解するためには他の論文を読む必要がある)
- グローバルロックマネージャー: 1つのノード上で動作
- ローカルロックマネージャー: それぞれのノード上で動作
- グローバルロックマネージャーはlock tokensを使用して、ローカルロックマネージャー間のロックを管理する。
並列データアクセス †
- GPFSでは、byte-rangeロックを使用することにより、POSIXの読み書きのアトミック性を維持したまま、同一のファイルの異なる部分を並列に読み書きすることができる。
- 並列データアクセスの流れの例（node1が書き込み中にnode2が同じファイルに書き込むときの）
- 赤：解放するbyte-rangeトークン(node1は衝突が起こらない最大の大きさのbyte-rangeトークンを開放する)
- 青:node1が書き込む方向
- Ｏ1、Ｏ2はnode1、node2が書き込みを行うオフセット
メタデータアクセスの同期 †
- ファイルの属性やデータブロックのアドレスの保存の際、GPFSではiノードやindirect block使う。
- メタデータの更新にも同期が必要であるが、複数のノードから同時に書き込みが起こる場合、単純な排他制御では書き込みのたびにロックの衝突が発生してしまう。
- そのため、GPFSではiノードに対してshared write lockと呼ばれる方法を使う
- 同一のメタデータにアクセスしている複数のノードからmetanodeと呼ばれるノードを選ぶ。
- metanodeはトークンサーバーによって動的に割り当てられる。
- 一番初めにそのメタデータのアクセスしたノードがmetanodeとなり、その他のノードは、metanodeのIDを受け取る。
- metanodeのみがそのメタデータに対してに対して読み書きをすることができる。
- 他のノードはローカルにiノードの情報を保存し、定期的にそのiノードをmetanodeへ転送しiノード更新の依頼をする
- metanodeがロックを開放するときは、他のノードからiノードの情報をマージし、更新する。
- metanode自身からのアクセスがなくなったら、metanodeの権利を他のノードへ委託する
- このように、GPFSではメタデータの更新にはCentralized Managementを採用している。
Allocation Maps †
- Allocation Mapはファイルシステム内の全てのディスクブロックのAllocationステータス(free or in-use、0?1)を記録する。
- ディスクブロックは小さなファイルを保存するために32個のサブブロックに分けることができたので、Allocation Mapは１つのファイルブロックの管理に32bit使う。
- (詳しくはノートの図を参照)
その他のファイルシステムのメタデータについて †
- GPFSでは、その他のグローバルメタデータも保持する
Token Manager Scaling †
- Token Managerは全てのトークンの取得、開放の監視をする。
- トークンの取得、開放をするにはToken Managerへ依頼する必要がある。
- 大規模なクラスタ環境では、��Token Managerがボトルネックとなったり、�▲函璽�ンの状態のサイズがメモリを超える恐れがあるが、以下の方法でそれを回避する。
- � �Allocation Managerの利用
- トークンの衝突が主なボトルネックであり、Allocation Managerを使ってその衝突を軽減する
- �◆Д函璽�ンの状態情報が無限に増えないようにする
- ファイルサイズは無限に増える可能性があるので、byte-rangeトークンの状態情報も無限に増える可能性がある。そのためトークンの状態を複数のノードに分散させて管理する方法もあるが、単一のノードだけが一つのファイル全体のトークンをリクエストするときには、"アリに大砲"状態になる。
- 代わりに、Token Managerはメモリ使用状況を監視し、トークンの状態情報が増えすぎた場合、そのトークンを無効にする。
- � �Allocation Managerの利用
耐障害性 †
ノード障害 †
- ノードが障害を起こした場合
- まず、グループサービスレイヤーによって検知される(検知方法は他の論文を読む必要がある)
- GPFSでは、共有ディスク上にリカバリログを保存していて、生きてるノードの誰か一人からそのログを読み込み込むことによって、リカバリを実現する。
- リカバリが完了したら、Token Managerは全てのトークンを解放する
- これにより、障害を起こしたノードが障害を起こしたときに、ディスクに書き戻していないキャッシュ上のデータを自由に行進することができる
- したがって、障害を起こしたノードが更新を行っているメタデータへ他のノードはアクセスすることができない
- ディスクへの更新が終了したら、通常通り他のノードはどのメタデータのトークンも取得できる。
- 他のノードがメタデータの更新をMetanodeへ送信していたら、リカバリ後、新しいMetanodeへそのリクエストを再送信する。
- Token Managerが障害を起こした場合、他のノードがその責任を引き継ぐ
- 引き継いだノードは、現在取得しているトークンをみんな（他のノード）に聞いて回る
- 引き継いだノードがその後もToken Managerとなるか？それとも権利を返上するのか?は言及されていない。
- その他の特別なノード（Allocation Managerなど）も同様な方法で対処される。
通信障害 †
- ネットワークの障害により分離されたノード群がそれぞれ独立にファイルにアクセスしてしまったら、ファイルを破壊してしまう可能性がある。
- このため、分離されたノード、つまりノード群のメンバーでなくなってしまったノードを隔離し、ファイルにアクセスできないようにする。
ディスク障害 †
- デュアルRAIDコントローラを使用
- その他、ディスクのレプリカを自分以外のノード２人へコピーする。
- ディスクに障害が起こった場合は、どちらのノードのデータが最新かを判断する。
- ディスクが復帰したら、復帰の間更新された内容をアップデートする
- もし、障害がパーマネントならレプリカを別のノードへコピーする
Scalable Online System Utilities †
- ディスクが追加された場合、GPFSではデータを新しいディスクへ移動し、またディスクが取り替えられたり、取り除かれたりしたときもその中のデータを他のディスクへ移動する機能を持つ
Experiences †
- ノードレベルでの並列化より、ノード内部での並列化(マルチスレッド、マルチコア)のほうがパフォーマンス（バンド幅の効率的利用など）の面で重要
- Centralized Managementによって、パフォーマンスの低下の恐れがあるが、並列化によってカバーできる
提案したものの評価 †
- Read/Write Scaling
- Writing(▲と×)が下がってしまったのはスイッチアダプタのせいだと言っている
- 注目すべきところは、▲と×が同じ推移であること。byte-rangeトークンプロトコルがうまく作用し、並列に書き込んでいる証拠。
- Effect of Sharing Granularity on Write Throughput
- Sharing Granularity: ファイルのブロックの大きさ?
- BR(byte-range) locking: Distributed locking
- 左側が落ち込んでるのは、トークンの衝突が原因らしい。
- data shipping: Centralized management?
- BR token activity: BR lockingの測定したとき、トークンサーバー上で測定
- File Create Scaling
- ▲と×はFigure2と同じデータ
- WrintingはCreatingより、Allocation Mapの更新の量の関係で、スループットが高い
- ◆と□
- ◆と□の推移がほぼ同じであり、並列にファイルの作成が行われている...証拠?
- ◆と□の推移がほぼ同じであり、並列にファイルの作成が行われている...証拠?
- ▲と×はFigure2と同じデータ
その他 †
- 意味のわからないファイルシステムの用語が連発していて、かなり戸惑った。
- ファイルシステムとはコンシステンシー、同期、耐障害など多方面からの技術が合わさってできているんだなぁ、と改めて痛感した。
- 自分は、これらのどれかに焦点を当てた研究になるのだろうか....?
最新の20件
2007-04-28 2007-11-30 2007-12-02 2007-10-21 2007-12-03 2007-11-30 2008-02-29 2008-05-11 2008-03-09 2008-02-29 2008-01-21 2007-10-20 2008-05-17 2007-10-03 2007-06-26 2008-05-18 2007-10-26 2007-12-02 2008-05-17今日の3件
- GPFS A Shared-Disk File System for Large Computing Clusters(1)
- PHP(1)
- Valgrind(1)
- counter: 524
- today: 1
- yesterday: 0
- online: 1
