Pivotal Knowledge Base

フォローする

PHDのデフォルトキャパシティスケジューラにおけるデータローカリティ動作について

環境

  • PHD 2.x
  • PHD 1.x
  • YARN / HDFS ラックアウェアネスが設定されていること

PHDデフォルトキャパシティスケジューラ におけるデータローカリティ動作について

PHDインストール後、デフォルトで キャパシティスケジューラ はデータローカリティを無効にする。40ノード以上の大規模クラスタでは、ユーザは前提となるアプリケーションを実行するためのすべてのコンテナが2台か3台のノード上でしか実行されないことに気づく。  

データのローカリティが無効になっている場合、キャパシティスケジューラは次のコンテナをどのノードマネージャー が割り振るのかをどのように決めるのか? 

ノードマネージャー がハートビートで自分の状況を報告した後に、キャパシティスケジューラ は ノードマネージャーにリソースを割り当てる。ジョブがサブミットされた後、最後に受け取ったハートビートはコンテナの割当先だと見られる ノードマネージャー 由来のものとなる。情報報告した最後の ノードマネージャー に48GBのフリー領域があり、コンテナメモリ配分は2GBと設定されることを仮定する。そうすると、データローカリティが無効になっている場合、キャパシティスケジューラ は先行し、このシングルノードに24個のコンテナを振り当てる。 

データのローカリティが有効となっており、4ノードしかない小規模クラスタで、1つのアプリケーションを実行するのに2GBのサイズのコンテナ32個が必要となる場合はどうなるのか?

前提とする環境例

  • 4 個のノードマネージャー に各48GBのメモリ割り当て
  • Mapreduceアプリケーションに32個のmapコンテナ
  • 各mapコンテナに2GBのメモリ割当
  • 1つの ノードマネージャー は、2GBのメモリのmapコンテナ24個を受付可能

ノードマネージャー がハートビートで自分の状況を報告した後に、キャパシティースケジューラ は ノードマネージャーにリソースを割り当てる。ジョブがサブミットされた後、最後に受け取ったハートビートは、どの ノードマネージャー がコンテナの割当先だと見なされるか決定する。この例では、 ノードマネージャー は48GBの空き領域で、スケジューラは1つの ノードマネージャーに24個のコンテナを割り当てる。この ノードマネージャーのメモリ使用量がいっぱいになると キャパシティースケジューラは残りの8つのコンテナに次の ノードマネージャー を選び同じタスクを実行する。
もし4ノードのクラスタでレプリケーションファクターが3となっている場合、大多数のmapタスクのために選ばれたノードマネージャー にデータがある可能性が高い。 ノードマネージャー のメモリとCPUリソースが適切に設定されていれば、この動作が大きい影響を及ぼすことがない。それは スケジューラ が各ノードのリソースを100%消費するように設計されているからである。

データローカリティを有効・無効に 

デフォルトではデータローカリティは yarn.scheduler.capacity.node-locality-delay のデフォルト値”-1”により無効と設定されている。そしてこの値はクラスタのラック数と同じにすべきである。これは yarn hdfsが ラックアウェアネスと設定されることを仮定している。 rack awareness

/etc/gphd/hadoop/conf/capacity-scheduler.xml

<property>
<name>yarn.scheduler.capacity.node-locality-delay</name>
<value>-1</value>
<description>Number of missed scheduling opportunities after which the CapacityScheduler attempts to schedule rack-local containers.
Typically this should be set to number of racks in the cluster, this
feature is disabled by default, set to -1.
</description>
</property>

これらの変更の後、 リソースマネージャーを再起動する。 

コメント

Powered by Zendesk