1. HDFSのスケーラビリティとマルチマスタへの取り組み 2010/05/26 三上俊輔

2. 背景 HDFSのNamenodeの限界が見え始めた 名前空間上のファイルやブロック数の限界 Namenodeのメインメモリ上にファイルやブロックの情報を載せる必要があり、メモリに載らなくなると極端に性能低下 Namenodeの要求処理性能の限界 ハートビート、ブロックレポートとクライアントからのメタデータへのアクセス これらのリクエストがある一定値を超えると飽和してしまい、線形的なスケールのボトルネックとなる

3. Targets for HDFS vs. actual deployed

4. Namespace Limitations 一つのfile,block（オブジェクト）に200byteほど必要 Yahooでは平均1fileは1.5blockで、1fileにつきNamenodeのRAMを600byte使用 1億ファイルには60GBのRAMが必要となる

5. Storage capacity 一億ファイルを達成するには60PBのストレージ容量が必要 10,000ノードで達成するにはノードあたり6TB必要 今のyahooクラスタはノードあたり1TBディスクが4つだが、8つまで増やす必要がある

6. The Internal Load 3 block reports per second, each reporting 60,000 replicas 10,000 heartbeats per second NNThroughputベンチマークの結果 Block reportsによって常にCPUの30%が消費されている

7. Reasonable Load Expectations HDFS read and write throughput Open and create throughput Internal loadがあるのでThroughputのうち70%のみ実際に使用可能 100,000クライアントで各クライアントが96MB書き込むとすると、2.4秒なので、41,667 create block / sec 3920 ops/sしか書き込めない

8. まとめ 100,000クライアントからのreadは処理できるが、writeではnamenodeがボトルネックとなる Readはメモリアクセスだけで済むが、Writeではディスクアクセスが必要なので遅い 性能向上のテクニックはいくつかあるが、結局一つのnamenodeではスケーラビリティがない 将来的には小さいファイルが増える傾向にあることも考慮し、分散メタデータサーバが望ましい

9. HDFS scalability with multiple namenodes https://issues.apache.org/jira/browse/HDFS-1052 複数のNameNodeだが、名前空間も複数 シンボリックリンクによってクライアント側は透過にアクセスできるようにすることは可能 フェイルオーバーはない

10. Related work Colossus Google file systemの次世代版 複数ネームサーバで単一名前空間を提供 詳細はまだ不明 Haceph:Scalable Metadata Management for Hadoop using Ceph http://users.soe.ucsc.edu/~carlosm/Papers/eestolan-nsdi10-abstract.pdf HDFSの代わりにcephを使う Cephはダイナミックパーティションツリーを使った分散メタデータサーバを持つ 実装は見当たらなかった