Scalability of the Hadoop Distributed File System _2
Yahoo! Developer Network Blog
May 5, 2010
http://developer.yahoo.net/blogs/hadoop/2010/05/scalability_of_the_hadoop_dist.html?
Storage Capacity vs. Namespace Size
With 100 million files, each having an average of 1.5 blocks, we will have 200 million blocks in the file system. If the maximal block size is 128 MB and every block is replicated 3 times, then the total disk space required to store these blocks is about 60 PB.
1億のファイルがそれぞれ、平均で1.5ブロックを持つ場合には、そのファイル･システム内で2億ブロックを持つことになる。 最大のブロック･サイズが 128MBであり、また、すべてのブロックが 3回複製されるなら、それらのブロックをストアするために必要な、全体的なディスク･スペースは約 60 PB になる。
100 million file namespace needs 60 PB of total storage capacity on the cluster
1 億ファイルの名前空間は、クラスタ上に合計で 60 PB のストレージ容量を必要とする。
As a rule of thumb, the correlation between the representation of the metadata in RAM and physical storage space required to store data referenced by this namespace is:
1 億ファイルの名前空間は、クラスタ上に合計で 60 PB のストレージ容量を必要とする。
大まかな指針として、RAM 上でのメタデータの表現と、名前空間により参照されるデータのストアに必要な、物理的なストレージ空間との相互関係は以下のとおりである：
1 GB metadata ≈ 1 PB physical storage
The rule should not be treated the same as, say, the Pythagorean Theorem, because the correlation depends on cluster parameters (the block to file ratio and the block size). But it can be used as a practical estimate for configuring cluster resources.
対象となる相互関係がクラスタ･パラメータ（ファイル･レシオのブロックとブロック･サイズ）に依存するため、たとえば Pythagorean 定理として、このルールを取り扱うべきではない。 ただし、クラスタ・リソースをコンフィグレーションするための、現実的な見積もりとして使用することができる。
Cluster Size and Node Configuration
Next we can estimate the number of data-nodes the cluster should have to accommodate the namespace of a certain size. On Yahoo’s clusters, data-nodes are usually equipped with four disk drives of size 0.75 – 1 TB, and configured to use 2.5 – 3.5 TB of that space per node. The remaining space is allocated for MapReduce transient data, system logs, and the OS.
続いて、Data-Node 数が推定できる。それは、クラスタが受け入れるべき名前空間のサイズとなる。 Yahoo のクラスタでは、一般的に 4台のディスク･ドライブ（0.75TB～1TB x 4）により Data-Node が配備され、また、ノードごとに 2.5TB～3.5TB を用いるようにコンフィグレーションされる。 残りのスペースは、MapReduce の一時データや、システム・ログ、そして OS に割り当てられる。
If we assume that an average data-node capacity is 3 TB, then we will need on the order of 20,000 nodes to store 60 PB of data. To keep it consistent with the target requirement of 10,000 nodes, each data-node should be configured with eight 1TB hard drives.
もし、平均的な Data-Node 容量が 3TB だと想定されるなら、60 PB のデータをストアするために、20,000 ノードが必要になる。 なお、10,000ノードをターゲットとする要件と矛盾しないようにするために、8台の 1TB ハードドライブを用いて、それぞれの Data-Node をコンフィグレーションすべきだ。
To accommodate data referenced by a 100 million file namespace, a HDFS cluster needs 10,000 nodes equipped with 8TB of total hard drive capacity per node
1億ファイルの名前空間により参照されるデータを受け入れるために、HDFS クラスタは、トータルで ８TB のハードドライブをノードごとに配備した、10,000 ノードを必要とする。
Note that these estimates are true under the assumption that the block per file ratio of 1.5 and the block size remain the same. If the ratio or the block size increases, a gigabyte of RAM will support more petabytes of physical storage and vice versa. Sadly, based on practical observations, the block to file ratio tends to decrease during the lifetime of a file system, meaning that the object count (and therefore the memory footprint) of a single namespace server grows faster than the physical data storage. That makes the object-count problem — which becomes file-count problem when the average file to block ratio is close to 1 — the real bottleneck for cluster scalability.
ファイルとブロックの比率が 1.5 であり、また、ブロック･サイズが変化しないという仮定において、これらの見積もりが正確になることに注意すべきだ。もし、この比率やブロック･サイズが増大するなら、1GB のRAM により、さらに多くの物理ストレージを、ペタバイト単位でサポートすることになる。 また、減少するのであれば、その逆も同様となる。 現実的な観察に基づくと、残念なことにファイルとブロックの比率は、ファイル・システムのライフサイクルにおいて減少する傾向にある。つまり、単一の名前空間サーバーにおけるオブジェクト･カウント（それによるメモリ･フットプリント）は、物理的なデータ・ストレージよりも速く成長することになる。 それにより、オブジェクト･カウントの問題が生じる。 そして、ファイルとブロックの平均的な比率が 1に近づくとき、それはファイル･カウントの問題に発展し、クラスタのスケーラビリティにおけるボトルネックとなる。
The Internal Load
Apart from the hierarchical namespace the name-node’s metadata includes a list of registered data-nodes, and a block to data-node mapping, which determines physical block locations.
階層的な名前空間は別として、Name-Node のメタデータには、登録された Data-Node のリストと、Data-Node マッピングのためのブロックが含まれ、それにより物理的なブロック配置が決定される。
A data-node identifies block replicas in its possession to the name-node by sending block reports. The first block report is sent at the startup. It reveals the block locations, which otherwise are not known to the name-node at startup time. Subsequently, block reports are sent periodically every 1 hour by default and serve as a sanity check providing that the name-node has an up-to-date view of block replica distribution on the cluster.
Data-Node はブロック･レポートを送信することで、Name-Node に対する所有権を用いて、ブロック･レプリカを識別する。 最初のブロック･レポートは、開始時に送信される。 それによりブロック配置が明らかにされるが、そうしなければ、開始時に Name-Node を識別することができない。 その後、デフォルトにおいて、ブロック･レポートは 1時間ごとに周期的に送信される。 そして、クラスタ上に配信されるブロック･レプリカについて、Name-Node が更新されたビューを持っている場合には、サニティ・チェックの役割を果たす。
During normal operation, data-nodes periodically send heartbeats to the name-node to indicate that the data-node is alive. The default heartbeat interval is 3 seconds. If the name-node does not receive a heartbeat from a data-node in 10 minutes, it pronounces the data-node dead and schedules its blocks for replication on other nodes.
正常なオペレーションが行われている間は、Data-Node から Name-Node へ周期的にハートビートが送信され、Data-Node が生きていることが確認される。 デフォルトのハートビート間隔は、3秒となっている。 Data-Node からのハートビートを、10分間にわたりName-Node が受信しない場合には、Data-Node が死んでいると判断され、他のノードへ向けたブロックをリプリケーションがスケジュールされる。
The block reports and heartbeats form the internal load of the cluster. If the internal load is too high, the cluster becomes dysfunctional, able to process only a few, if any, external client operations such as ls, read, or write. The internal load depends on the number of data-nodes. Assuming that the cluster is built of 10,000 data-nodes having 8 hard drives with 6 TB of effective storage capacity each, we estimate that the name-node will need to handle
ブロック･レポートとハートビートは、クラスタ内の負荷も構成する。 内部の負荷が大きすぎる場合には、クラスタは機能不全となり、外部クライアントによる Is／read／write などのオペレーションがあるにしても、その処理能力は劣化してしまう。 内部の付加は、Data-Node 数に依存する。 対象となるクラスタが、6TB の有効なストレージ容量を備えたる、8 台のハードドライブを有する 10,000 Data-Node で構成されると想定している。 それにより、Name-Node は、以下の処理を行う必要が出てくる：
● 3 block reports per second, each reporting 60,000 replicas
● 10,000 heartbeats per second
Using the standard HDFS benchmark called NNThroughputBenchmark, we measure the actual name-node performance with respect to the two internal operations. Table 2 summarizes the results. Note that the block report throughput is measured in the number of blocks processed by the name-node per second.
NNThroughputBenchmark と呼ばれる標準的な HDFS ベンチマークを用いて、2つの内部オペレーションについて、Name-Node の現実的なパフォーマンスを測定した。 その結果を、Table 2 に要約する。 ブロック・レポートのスループットが、Name-Node により毎秒処理されるブロック数で、測定されることに注意してほしい。
The implication of these results is:
これらの結果は、以下を示唆する：
The internal load for block reports and heartbeat processing on a 10,000 node HDFS cluster with the total storage capacity of 60 PB will consume 30% of the total name-node processing capacity.
60BP のトータル･ストレージ容量を用いて、10,000 ノードの HDFS クラスタを取り扱うブロック･レポートとハートビートの内部負荷は、全体的な Name-Node 処理能力の 30% を消費する。
The internal load is proportional to the number of nodes in the cluster and the average number of blocks on a node. Thus, if a node had only 30,000 blocks — half of the estimated amount — then the name-node will dedicate only 15% of its processing resources to the internal load. Vice versa, if the average number of blocks per node grows, then the internal load will grow proportionally. The latter means that the decrease in block to file ratio (more small files with the same file system size) increases the internal load and therefore negatively affects the performance of the system.
この内部負荷は、クラスタのノード数と、ノードにおける平均的なブロック数に比例する。 したがって、見積もられる総量の半分に相当する 30,000 ブロックをノードが保有するなら、内部負荷に関するリソース処理において、Name-Node は 15％ だけを占有するだろう。また、その逆も真であり、ノードごとの平均的なブロック数が増大するなら、内部負荷も相対的に増大する。 後者が示すのは、ブロックとファイルの比率の低下が（同じファイルシステム･サイズを用いて、より多くの小さなファイルに対応）、内部負荷を増大する状況である。 したがって、システムのパフォーマンスに悪影響を与えることになる。
＜関連＞
HDFS のスケーラビリティを考察する _1
HDFS のスケーラビリティを考察する _2
HDFS のスケーラビリティを考察する _3
ーーーーー
Hadoop DFS _ Introduction
NoSQL Ecosystem とは？ _1
