Tech Blog 〜ぞうの日記

HadoopやLinux関連の技術的な内容の紹介です

HDFSのヘテロジニアス(非均一)ストレージ構成

9日目です(すみません、土日に書くのは休むことにしました)

ご存知の通り、HDFSはマスターとスレーブ群から構成されます。スレーブノードを大量に用意することで、膨大なデータを蓄積することができます。 現状のHDFSでは、個々のデータノードが持っているストレージの種類や数、個々のストレージの容量などを、ネームノードが知る手段がありません。今後データノードでは、HDDやSSDなどのデバイスを組み合わせて利用したり、ノード毎に異なるハードウェア構成を取ることが増える可能性があります。

 

 

現在HDFS-2832で投票が行われているチケットは、HDFSでヘテロジニアス(非均一)な構成のストレージをうまく扱おうとしているものです。まだHadoop本体には取り込まれていませんが、個人的には興味を持って状況を追っています。HDFS-2832にはPDFのドキュメントがあるので、大雑把に概要をまとめてみます。興味のある方はJIRAの知恵ケットをご覧下さい。

動機

現状のHDFSはには以下のような特徴があります。

  • ネームノードはデータノードのストレージ構成を理解していない(ディスクの本数や構成など)
  • HDFSはストレージの種類を認識していない(HDD、SSD、RAM、RAID、、、)
  • アプリ(クライアントなど)はこれらの異なる特徴を持つストレージメディアを選択できない

このチケットでは、HDFSにストレージメディアの情報などを追加することで、ストレージのパフォーマンスや耐久性に基づいた選択ができるようにするというものです。

ユースケース

ユースケースとしては以下のようなものが想定されています。

  1. ストレージの種類に基づいてブロックの配置を行う
    1. 全てのレプリカを同一のストレージの種類に配置する
    2. 違う種類にレプリカを配置する(2つはHDD、1つはSSDなど)
    3. アプリから指示する
  2. アプリケーションはストレージメディアの種類を変更できる
    1. 全てのレプリカ
    2. レプリカのいくつかについて
    3. アプリから指定
  3. ストレージメディアの種類によるクォータ
  4. システムがアクセスパターンに基づきホットなデータを早いストレージに移動

のようなものが想定されているようです。 実際のところ、最初のパッチでは全て実装されているわけではないですが、将来的には4.のようなことも計画されているようですね。

アプローチ

技術的な変更点として、データノードではストレージの種類を設定するようになるようです。

  • ストレージ毎のIDと種類を設定
  • データノード(DN)からネームノード(NN)へのハートビートで、ストレージのID、ストレージの種類、使用量などを含む
  • DNからのNNへのブロックレポートで、ストレージメディアの種類、ストレージのIDを送付
  • ブロックのレプリカが作成された時に、ストレージの種類も渡される。これによりクォータのチェックもされるようになる

ネームノードは、ストレージの種類を識別して使用します。 クライアントもストレージの種類の情報を使用することができるようになります。

ストレージの種類

また、ストレージの種類として、データノードのストレージボリュム毎に、以下のようなオプションが渡せるように検討しているようです。

  • 論理(レイテンシ、スループット、コスト、耐久性、読み込み専用など)
  • 物理(HDD、SSD、RAM、RAID、テープ、NASなど)

まとめ

細かいところはドキュメントを参照していただくとして、なかなか興味深いですね。実際に取り込まれるかはわかりませんが、興味のある方はJIRAのチケットやメーリングリストなどをご覧になってみてはいかがでしょうか? ※間違いを発見した方はご指摘下さい m(__)m