NodeManager

概要

NodeManagerは、ノード上でコンテナを起動および管理する役割を担います。コンテナは、AppMasterによって指定されたタスクを実行します。

ヘルスチェッカーサービス

NodeManagerは、実行中のノードのヘルス状態を判断するサービスを実行します。このサービスは、ディスクとユーザーが指定したテストの両方をチェックします。ヘルスチェックに失敗した場合、NodeManagerはノードを異常とマークし、このことをResourceManagerに伝えます。これにより、ResourceManagerはそのノードへのコンテナの割り当てを停止します。ノードステータスの通信は、NodeManagerとResourceManager間のハートビートの一部として行われます。ディスクチェッカーとヘルスモニター(後述)が実行される間隔は、ハートビート間隔には影響しません。ハートビートが行われると、両方のチェックのステータスを使用して、ノードのヘルス状態が判断されます。

ディスクチェッカー

ディスクチェッカーは、NodeManagerが使用するように構成されているディスク(local-dirsとlog-dirs。それぞれyarn.nodemanager.local-dirsとyarn.nodemanager.log-dirsを使用して構成)の状態をチェックします。チェックには、パーミッションと空きディスク容量が含まれます。また、ファイルシステムが読み取り専用状態ではないこともチェックします。チェックはデフォルトで2分間隔で実行されますが、ユーザーが希望する頻度で実行するように構成できます。ディスクがチェックに失敗した場合、NodeManagerはその特定のディスクの使用を停止しますが、ノードステータスは引き続き正常として報告します。ただし、多数のディスクがチェックに失敗した場合(この数は後述するように構成できます)、ノードは異常としてResourceManagerに報告され、新しいコンテナはノードに割り当てられなくなります。

次の構成パラメータを使用して、ディスクチェックを変更できます

構成名 許可される値 説明
yarn.nodemanager.disk-health-checker.enable true, false ディスクヘルスチェッカーサービスを有効または無効にします
yarn.nodemanager.disk-health-checker.interval-ms 正の整数 ディスクチェッカーを実行する間隔(ミリ秒単位)。デフォルト値は2分です
yarn.nodemanager.disk-health-checker.min-healthy-disks 0〜1の間の浮動小数点数 NodeManagerがノードを正常とマークするためにチェックに合格する必要があるディスクの最小割合。デフォルトは0.25です
yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 0〜100の間の浮動小数点数 ディスクチェッカーサービスによってディスクが異常とマークされる前に利用できるディスク容量の最大パーセンテージ。このチェックは、NodeManagerで使用されるすべてのディスクに対して実行されます。デフォルト値は90、つまりディスクの90%を使用できます。
yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb 整数 ディスクチェッカーサービスがディスクを正常とマークするためにディスクで使用可能である必要がある最小空き容量。このチェックは、NodeManagerで使用されるすべてのディスクに対して実行されます。デフォルト値は0、つまりディスク全体を使用できます。

外部ヘルススクリプト

ユーザーは、ヘルスチェッカーサービスによって呼び出される独自のヘルスチェッカースクリプトを指定できます。ユーザーは、スクリプトに渡すタイムアウトとオプションを指定できます。スクリプトがタイムアウトするか、例外がスローされるか、またはERRORという文字列で始まる行が出力された場合、ノードは異常とマークされます。注意してください

  • 終了コードが0以外の場合、構文エラーが原因である可能性があるため、失敗とはみなされません。したがって、ノードは異常とはマークされません。

  • パーミッションやパスの間違いなどが原因でスクリプトを実行できない場合は、失敗と見なされ、ノードは異常と報告されます。

  • ヘルスチェックスクリプトの指定は必須ではありません。スクリプトが指定されていない場合、ディスクチェッカーのステータスのみを使用してノードのヘルス状態が判断されます。

ユーザーは、yarn.nodemanager.health-checker.scripts構成を使用して、個別に実行する最大4つのスクリプトを指定できます。また、これらのオプションはすべてのスクリプト(グローバル構成)に対して構成できます。

構成名 許可される値 説明
yarn.nodemanager.health-checker.script 文字列 コンマで区切られたヘルスチェッカースクリプトのキーワード。デフォルトは「script」です。
yarn.nodemanager.health-checker.interval-ms 正の整数 ヘルスチェッカーサービスが実行される間隔(ミリ秒単位)。デフォルト値は10分です。
yarn.nodemanager.health-checker.timeout-ms 正の整数 実行されるヘルススクリプトのタイムアウト。デフォルト値は20分です。

次のオプションは、すべてのヘルスチェッカースクリプトに対して設定できます。yarn.nodemanager.health-checker.scriptで提供される各キーワードで%s記号が置換されます。

構成名 許可される値 説明
yarn.nodemanager.health-checker.%s.path 文字列 実行するヘルスチェックスクリプトへの絶対パス。各スクリプトの必須引数。
yarn.nodemanager.health-checker.%s.opts 文字列 スクリプトの実行時にスクリプトに渡される引数。各スクリプトの必須引数。
yarn.nodemanager.health-checker.%s.interval-ms 正の整数 ヘルスチェッカーサービスが実行される間隔(ミリ秒単位)。
yarn.nodemanager.health-checker.%s.timeout-ms 正の整数 実行されるヘルススクリプトのタイムアウト。

間隔とタイムアウトのオプションは指定する必要はありません。その場合は、グローバル構成が使用されます。

NodeManagerの再起動

はじめに

このドキュメントでは、NodeManager(NM)の再起動の概要について説明します。これは、ノード上で実行されているアクティブなコンテナを失うことなくNodeManagerを再起動できる機能です。大まかに言うと、NMはコンテナ管理要求を処理する際に必要な状態をローカル状態ストアに保存します。NMが再起動すると、まずさまざまなサブシステムの状態をロードし、次にロードされた状態を使用してこれらのサブシステムが復旧を実行することで復旧します。

NMの再起動の有効化

手順1. NM再起動機能を有効にするには、conf/yarn-site.xmlの次のプロパティをtrueに設定します。

プロパティ
yarn.nodemanager.recovery.enabled true(デフォルト値はfalseに設定されています)

手順2. NodeManagerが実行状態を保存できるローカルファイルシステムディレクトリへのパスを構成します。

プロパティ 説明
yarn.nodemanager.recovery.dir リカバリが有効になっている場合にノードマネージャーが状態を保存するローカルファイルシステムディレクトリ。デフォルト値は$hadoop.tmp.dir/yarn-nm-recoveryに設定されています。

手順3:NMが終了したときに実行中のコンテナがクリーンアップされないように、リカバリ中のNM監視を有効にします。

プロパティ 説明
yarn.nodemanager.recovery.supervised 有効にすると、NodeManagerの実行は、すぐに再起動してコンテナを回復することを前提として終了時にコンテナをクリーンアップしようとしません。デフォルト値は「false」に設定されています。

ステップ4. NodeManagerの有効なRPCアドレスを設定します。

プロパティ 説明
yarn.nodemanager.address エフェメラルポート(デフォルトのポート0)は、NodeManagerのRPCサーバーにyarn.nodemanager.addressを通じて指定することはできません。これは、NMが再起動の前後で異なるポートを使用する可能性があるためです。これにより、再起動前にNMと通信していた以前に実行中のクライアントが中断されます。yarn.nodemanager.addressを特定のポート番号を持つアドレス(例:0.0.0.0:45454)に明示的に設定することが、NMの再起動を有効にするための前提条件です。

ステップ5. 補助サービス。

  • YARNクラスター内のNodeManagerは、補助サービスを実行するように構成できます。完全に機能するNMの再起動のために、YARNは、構成された補助サービスがリカバリもサポートすることを前提としています。これには通常、(1)以前に実行していたクライアント(この場合は通常コンテナ)が再起動後に中断されないように、エフェメラルポートの使用を避けること、および(2)補助サービス自体が、NodeManagerの再起動時および補助サービスの再初期化時に以前の状態をリロードすることによって、リカバリ可能性をサポートすることが含まれます。

  • 上記の簡単な例としては、MapReduce(MR)用の補助サービスである「ShuffleHandler」があります。ShuffleHandlerは上記の2つの要件を既に満たしているため、ユーザー/管理者はNMの再起動をサポートするために何もする必要はありません。(1)構成プロパティmapreduce.shuffle.portは、NodeManagerホスト上のShuffleHandlerがバインドするポートを制御し、デフォルトでは非エフェメラルポートになります。(2) ShuffleHandlerサービスは、NM再起動後の以前の状態のリカバリも既にサポートしています。

  • 補助サービスを構成する方法は2つあります。マニフェストを使用するか、構成を使用するかです。補助サービスは、補助サービスマニフェストが有効になっていない場合にのみ、構成プロパティを使用する以前の方法でロードされます。マニフェストを使用する利点の1つは、NMがマニフェストの変更に基づいて補助サービスを動的に再ロードできることです。再ロードをサポートするには、AuxiliaryServiceの実装は、NMが補助サービスの新しいインスタンスを作成できるように、サービス停止フェーズ中に必要なクリーンアップを実行する必要があります。

補助サービスのクラスパス分離

はじめに

NodeManagerで補助サービスを起動するには、ユーザーはjarをNodeManagerのクラスパスに直接追加する必要があるため、システムクラスローダーに配置する必要があります。しかし、クラスパスにプラグインの複数のバージョンが存在する場合、実際にどのバージョンがロードされるかを制御できません。または、補助サービスによって導入された依存関係とNodeManager自体との間に競合がある場合、NodeManager、補助サービス、またはその両方が破損する可能性があります。この問題を解決するために、システムクラスローダーとは異なるクラスローダーを使用して補助サービスをインスタンス化できます。

マニフェスト

このセクションでは、aux-serviceクラスパス分離のための補助サービスマニフェストについて説明します。マニフェストを使用するには、yarn-site.xmlでプロパティyarn.nodemanager.aux-services.manifest.enabledをtrueに設定する必要があります。

ファイルシステムからマニフェストファイルをロードするには、yarn-site.xmlyarn.nodemanager.aux-services.manifestプロパティの下にファイルパスを設定します。NMは、yarn.nodemanager.aux-services.manifest.reload-msで指定された間隔で、このファイルに新しい変更がないかチェックします(デフォルトは0。間隔<= 0の設定は、自動的に再ロードされないことを意味します)。または、エンドポイントhttp://nm-http-address:port/ws/v1/node/auxiliaryservicesにPUT呼び出しを行うことで、REST APIを介してマニフェストファイルをNMに送信することもできます。これにより、1つのNMのマニフェストのみが更新されることに注意してください。新しいマニフェストを読み込むと、NMはマニフェストで見つかったサービス名とバージョンに基づいて、必要に応じて補助サービスを追加、削除、または再ロードします。

以下は、CustomAuxServiceのクラスパス分離を構成するマニフェストの例です。jarまたはアーカイブ形式をサポートする、サービスのクラスパスを構成するために1つ以上のファイルを指定できます。

{
  "services": [
    {
      "name": "mapreduce_shuffle",
      "version": "2",
      "configuration": {
        "properties": {
          "class.name": "org.apache.hadoop.mapred.ShuffleHandler",
          "mapreduce.shuffle.transfer.buffer.size": "102400",
          "mapreduce.shuffle.port": "13562"
        }
      }
    },
    {
      "name": "CustomAuxService",
      "version": "1",
      "configuration": {
        "properties": {
          "class.name": "org.aux.CustomAuxService"
        },
        "files": [
          {
            "src_file": "${remote-dir}/CustomAuxService.jar",
            "type": "STATIC"
          },
          {
            "src_file": "${remote-dir}/CustomAuxService.tgz",
            "type": "ARCHIVE"
          }
        ]
      }
    }
  ]
}

構成

このセクションでは、aux-serviceクラスパス分離の構成変数について説明します。補助サービスは、マニフェストファイルが指定されていない場合にのみ、構成からロードされます。

以下の設定をyarn-site.xmlに設定する必要があります。

構成名 説明
yarn.nodemanager.aux-services.%s.classpath 関連するjarファイルとすべての依存関係のjarファイルを含むローカルディレクトリを指定します。単一のjarファイルを指定することも、${local_dir_to_jar}/*を使用してdepディレクトリの下にあるすべてのjarをロードすることもできます。
yarn.nodemanager.aux-services.%s.remote-classpath jarファイルへのリモートの絶対パスまたは相対パスを指定します(zip、tar.gz、tgz、tar、gzファイルもサポートしています)。同じaux-serviceクラスの場合、yarn.nodemanager.aux-services.%s.classpathまたはyarn.nodemanager.aux-services.%s.remote-classpathのいずれか1つの構成のみを指定できます。YarnRuntimeExceptionがスローされます。また、jarファイルの所有者がNodeManagerユーザーと同じであり、permbitsが(permbits & 0022)==0(600など、グループまたは他のユーザーによる書き込みは許可されない)を満たしていることを確認してください。
yarn.nodemanager.aux-services.%s.system-classes 通常、この構成を設定する必要はありません。クラスがsystem-classesに属していない場合、カスタマイズされたクラスパスからロードされます。たとえば、デフォルトでは、パッケージorg.apache.hadoopはsystem-classesにあります。クラスCustomAuxServiceがパッケージorg.apache.hadoopにある場合、カスタマイズされたクラスパスからはロードされません。これを解決するには、CustomAuxServiceのパッケージを変更するか、org.apache.hadoopを除外する独自のsystem-classesを構成します。

構成例

<property>
	<name>yarn.nodemanager.aux-services</name>
	<value>mapreduce_shuffle,CustomAuxService</value>
</property>

<property>
	<name>yarn.nodemanager.aux-services.CustomAuxService.classpath</name>
	<value>${local_dir_to_jar}/CustomAuxService.jar</value>
</property>

<!--
<property>
	<name>yarn.nodemanager.aux-services.CustomAuxService.remote-classpath</name>
	<value>${remote-dir_to_jar}/CustomAuxService.jar</value>
</property>
-->

<property>
	<name>yarn.nodemanager.aux-services.CustomAuxService.class</name>
	<value>org.aux.CustomAuxService</value>
</property>

<property>
	<name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name>
	<value>org.apache.hadoop.mapred.ShuffleHandler</value>
</property>

コンテナログが大きくなりすぎるのを防ぐ

これにより、クラスター管理者は、コンテナログが構成されたサイズを超える場合、タスク試行が強制終了されるようにクラスターを構成できます。これは、ログがディスクをいっぱいにするのを防ぎ、巨大なログを集約する必要性を防ぐのに役立ちます。

構成

以下のパラメーターを使用して、コンテナログディレクトリのサイズを構成できます。

構成名 許可される値 説明
yarn.nodemanager.container-log-monitor.enable true, false コンテナログディレクトリのサイズ制限を強制するコンテナログモニターを有効にするフラグ。デフォルトはfalseです。
yarn.nodemanager.container-log-monitor.interval-ms 正の整数 コンテナのログディレクトリの使用状況をチェックする頻度(ミリ秒単位)。デフォルトは60000ミリ秒です。
yarn.nodemanager.container-log-monitor.dir-size-limit-bytes Long 単一のコンテナログディレクトリのディスクスペース制限(バイト単位)。デフォルトは1000000000です。
yarn.nodemanager.container-log-monitor.total-size-limit-bytes Long コンテナのすべてのログのディスクスペース制限(バイト単位)。デフォルトは10000000000です。

CPU使用率に基づいてハートビート間隔を調整する

これにより、クラスター管理者は、ノードのCPU使用率とクラスター全体のCPU使用率を比較して、リソースマネージャーと各ノードマネージャー間のハートビートを調整できるようにクラスターを構成できます。

構成

以下のパラメーターを使用して、ハートビート間隔と、それが調整されるかどうか、および調整方法を構成できます。

構成名 許可される値 説明
yarn.resourcemanager.nodemanagers.heartbeat-interval-ms Long クラスター内のすべてのNodeManagerのデフォルトのハートビート間隔をミリ秒単位で指定します。デフォルトは1000ミリ秒です。
yarn.resourcemanager.nodemanagers.heartbeat-interval-scaling-enable true, false ハートビート間隔のスケーリングを有効にします。trueの場合、NodeManagerのハートビート間隔は、ノードのCPU使用率とクラスター全体の平均CPU使用率の差に基づいて調整されます。デフォルトはfalseです。
yarn.resourcemanager.nodemanagers.heartbeat-interval-min-ms 正のLong ハートビート間隔のスケーリングが有効な場合、これは最小のハートビート間隔(ミリ秒単位)です。デフォルトは1000ミリ秒です。
yarn.resourcemanager.nodemanagers.heartbeat-interval-max-ms 正のLong ハートビート間隔のスケーリングが有効な場合、これは最大のハートビート間隔(ミリ秒単位)です。デフォルトは1000ミリ秒です。
yarn.resourcemanager.nodemanagers.heartbeat-interval-speedup-factor 正のFloat ハートビート間隔のスケーリングが有効な場合、これはハートビート間隔を高速化するときの調整の度合いを制御します。1.0の場合、平均クラスター全体のCPU使用率より20%少ない場合、ハートビート間隔が20%減少します。デフォルトは1.0です。
yarn.resourcemanager.nodemanagers.heartbeat-interval-slowdown-factor 正のFloat ハートビート間隔のスケーリングが有効な場合、これはハートビート間隔を遅くするときの調整の度合いを制御します。1.0の場合、平均クラスター全体のCPU使用率より20%大きい場合、ハートビート間隔が20%増加します。デフォルトは1.0です。