たまたまCloudera blogの内容が目に留まったので超ざっくり意訳してみました。
Hadoopクラスターのデータノードサイズの検討に役立つ記事でした。
https://blog.cloudera.com/disk-and-datanode-size-in-hdfs/
Hadoop運用してればわかることかと思いますが、bit-rotのところや、ブロックレポートがあるってところは勉強になりました。
ところどころ勝手な意訳が入ってます。
適切なディスクサイズと容量はどれくらいかって話です。
アクセスが少ないデータに対して容量の大きいストレージを割り当てるのはいいですが、
アクセスが多いデータに対して容量の大きいストレージを割り当てるのは要注意です。
というのも以下の二つが要注意
- 容量の大きいディスク - 総容量と同じことですが、より多くのディスクを使った方が高IO帯域になります。
- 高容量ノード - (1台あたりの)容量が大きくなると、障害復旧に時間がかかるようになります。
これらはHDFSに特異ってわけじゃなくて、耐障害性を高めるためにレプリケーションしてる分散ストレージサービスであればどれも当てはまるでしょう。
なので1データノードあたり100TBで8ディスク以上が推奨です。
1ディスク8～12TBで100TBが上限です。
HDFSで大容量ボリュームの時のインパクト
IO帯域が減る
データノードが96TBだとして、8TBx12本と16TBx6本を考えてみよう。
100MB/secのread/writeスループットと7200RPMのスピードと仮定する。
| 8TBx12本 | 16TBx6本 | 補足 | |
|---|---|---|---|
| Read/Writeスループット | 1200MB/sec | 600MB/sec | 100MB x ディスク数 |
| Random IOPS | 2880 | 1440 | ちょっとわからないんですが、(7200 / 60) x 2 x ディスク数かと思います。 |
bit-rot 検知に時間がかかる
bit-rotを検出するためにデータノードはブロックをスキャンしてます。
そのスキャンは通常3週間ごとに行われます。
アプリケーションが動いてたらそのスキャン作業とリソースの奪い合いになります。
設定は変えられるけど5MB/secとしましょう。
12TBのディスクだったら、12TB/5MBps≒28日くらい
ディスクサイズ増えたらもっと時間かかります。
※bit-rot:経年劣化により磁気ディスクが読み取れなくなってしまう障害
ブロックレポートが重くなる
容量が大きくなればブロックレポートのブロック数も増えます。
データノードごとにブロックレポート生成時間が増え、RPCペイロードも増え、ネームノードでのブロックレポート処理も重くなり
クラスターの性能が落ちることになります。
高容量ノードのインパクト
障害復旧に時間かかる
ストレージのノードが落ちたら、冗長性のためにデータブロックをレプリケートしなければなりません。
リカバリー時間はデータノードサイズに比例するし、データノード数に反比例します。
リカバリー時間= (c * s)/n とすると
cは定数、sは各ノードの使用容量、nはストレージノード数。
クラスターの容量が与えられてるとすると、ノード毎の容量が2倍になるとリカバリー時間は4倍になります。
各ノードの容量が2倍になってノード数が半分になると仮定すると、
リカバリー時間=(c * 2s)/(n/2) = (4 * c * s)/n
変数sとnは他のストレージソリューションでも同様に重要です。
高容量データノードはどんなクラスターでもリカバリー時間に同じようなインパクトがあるでしょう。
データノードのデコミッション時のインパクト
計画的なノードのデコミッション中でも、すべてのブロックは他ノードに再レプリケートされます。
高容量データノードのデコミッション時間の影響はデータノード障害のリカバリー時間とほぼ同じです。
クラスターの容量が与えられてるとすると、ノード毎の容量が2倍になるとリカバリー時間は4倍になります。
HDFS-14854でデコミッション時のパフォーマンス改善が実装されてます。
今後のCDPで有効になるでしょう。
1データノードあたりの容量が増えると障害が起きたり、デコミッション時のデータ復旧に時間がかかるのはほんんんと同意。
かといって容量減らしてサーバー増やすとか、サーバーラックもおいそれと倍にできるわけじゃないから悩ましいです。
あらためて小さい容量のサーバーがたくさんあるほうがいいことがわかります。
またブロックレポートというのも今回で初めて知りました。Hadoopクラスターは裏でいろいろと動いてるのも調べないとわからないですね。