E-MapReduce:FAQ

ステートフルクラスターの再起動とはどういう意味ですか？

ステートフルクラスターの再起動とは、ResourceManager の再起動とNodeManager の再起動を意味します。ResourceManager は、アプリケーションの基本情報とステータスを維持します。NodeManager は、実行中のコンテナーの情報とステータスを維持します。ResourceManager と NodeManager は、独自のステータスを ZooKeeper、LevelDB、Hadoop Distributed File System（HDFS）などの外部ストレージシステムに常に同期します。ResourceManager と NodeManager のステータスは、再起動後に自動的にリロードおよび復元できます。これにより、クラスターのアップグレードまたは再起動後に、アプリケーションとコンテナーのステータスを自動的に復元できます。ほとんどの場合、クラスターのアップグレードまたは再起動は、アプリケーションとコンテナーには認識されません。

ResourceManager 高可用性（HA）を有効にするにはどうすればよいですか？

ホットアップデートを設定するにはどうすればよいですか？

1. 主要なパラメーターを設定します。

   EMR コンソールのクラスターの YARN サービスページの [設定] タブで、ホットアップデートに関連するパラメーターを確認または設定できます。次の表に、パラメーターを示します。

   パラメーター	説明	推奨値
   yarn.scheduler.configuration.store.class	バッキングストアのタイプ。このパラメーターを fs に設定すると、ファイルシステムがバッキングストアとして使用されます。	fs
   yarn.scheduler.configuration.max.version	ファイルシステムに格納できる設定ファイルの最大数。設定ファイルの数がこのパラメーターの値を超えると、超過した設定ファイルは自動的に削除されます。	100
   yarn.scheduler.configuration.fs.path	capacity-scheduler.xml ファイルが格納されるパス。 このパラメーターを設定しない場合、ストレージパスが自動的に作成されます。プレフィックスが指定されていない場合、デフォルトのファイルシステムの相対パスがストレージパスとして使用されます。	/yarn/<クラスター名>/scheduler/conf 重要 <クラスター名> を特定のクラスター名に置き換えます。YARN サービスがデプロイされている複数のクラスターが、同じ分散ストレージを使用する場合があります。

2. capacity-scheduler.xml ファイルの設定を表示します。

   • 方法 1 （RESTful API）: http://<rm-address>/ws/v1/cluster/scheduler-conf 形式の URL にアクセスします。

   • 方法 2 （HDFS）: 設定パス ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp> にアクセスして、capacity-scheduler.xml ファイルの設定を表示します。<timestamp> は、capacity-scheduler.xml ファイルが生成された時刻を示します。タイムスタンプ値が最大の capacity-scheduler.xml ファイルが、最新の設定ファイルです。

3. 設定を更新します。

   たとえば、パラメーター yarn.scheduler.capacity.maximum-am-resource-percent を変更し、パラメーター yarn.scheduler.capacity.xxx を削除できます。パラメーターを削除するには、パラメーターの値フィールドを削除するだけです。

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

   // パラメーター yarn.scheduler.capacity.maximum-am-resource-percent を変更し、パラメーター yarn.scheduler.capacity.xxx を削除します。

キュー内のアプリケーション間でリソースの配分が不均一になる問題に対処するにはどうすればよいですか？

キューのリソース使用量を表示するにはどうすればよいですか？

YARN の Web UI で [使用済み容量] パラメーターの値を表示して、キューのリソース使用量を確認できます。[使用済み容量] パラメーターは、キューに割り当てられたすべてのリソースに対する、キューで使用されているリソースの割合を指定します。キューで使用されているメモリリソースの割合と、キューで使用されている vCore 数の割合は個別に計算されます。大きい方の値が、使用済み容量パラメーターの値として使用されます。キューのリソース使用量を表示するには、次の操作を実行します。

1. YARN の Web UI にアクセスします。詳細については、「オープンソースコンポーネントの Web UI にアクセスする」をご参照ください。

2. [すべてのアプリケーション] ページで、特定のジョブの ID をクリックします。

3. [キュー] 行で目的のキューをクリックします。

   [アプリケーションキュー] セクションで、キューのリソース使用量を表示します。

   

YARN サービスコンポーネントによって多数の .out ログファイルが生成され、自動的にクリアできません。なぜですか？

• 原因: Hadoop コンポーネントの特定の依存ライブラリが Java ロギング API を呼び出してログレコードを生成し、Log4j ベースのログローテーションをサポートしていません。デーモンコンポーネントの標準エラー（stderr）出力は、.out ログファイルにリダイレクトされます。自動クリーンアップメカニズムが提供されていないため、ログが長時間蓄積されると、データディスクストレージがいっぱいになる可能性があります。

• 解決策: ログに生成されたタイムスタンプ情報と組み合わせて head コマンドと tail コマンドを使用して、Java ロギング API によって生成されたログが大量のストレージ容量を占有しているかどうかを確認します。ほとんどの場合、依存ライブラリは INFO レベルのログを生成しますが、これはコンポーネントの使用には影響しません。データディスクのストレージ容量が占有されないようにするには、設定を変更して INFO レベルのログの生成を無効にすることができます。

  たとえば、次の手順を実行して、Timeline Server の Jersey 依存ライブラリのログ生成を無効にします。

  1. 次のコマンドを実行して、YARN のログストレージパスにある timelineserver- に関連する .out ログファイルを監視します。DataLake クラスターでは、パスは /var/log/emr/yarn/ です。Hadoop クラスターでは、パスは /mnt/disk1/log/hadoop-yarn です。

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     // YARN のログストレージパスにある timelineserver- に関連する .out ログファイルを監視します。

     出力には、com.sun.jersey パッケージによって生成されたレコードが含まれています。

     

  2. Timeline Server が実行されているノードで、ルートユーザーとして次のコマンドを実行して設定ファイルを作成および設定し、Timeline Server のログ生成を無効にします。これにより、Jersey 依存ライブラリによって生成された INFO レベルのログが .out ログファイルにエクスポートされなくなります。

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

     // 設定ファイルを作成および設定し、Timeline Server のログ生成を無効にします。

  3. EMR コンソールの YARN サービスページの [設定] タブで、YARN_TIMELINESERVER_OPTS パラメーター（Hadoop クラスターの yarn_timelineserver_opts パラメーターに対応）を見つけて、-Djava.util.logging.config.file=off-logging.properties をパラメーターの値に追加して、作成された設定ファイルの場所を指定します。

     

  4. 設定を保存し、Timeline Server を再起動して設定を有効にします。Timeline Server が正常に起動し、.out ログファイルに com.sun.jersey に関連するログ情報がなくなれば、Jersey 依存ライブラリのログ生成は無効になります。

ResourceManager サービスが正常かどうかを確認するにはどうすればよいですか？

アプリケーションのステータスを取得するにはどうすればよいですか？

アプリケーションのトラブルシューティングを行うにはどうすればよいですか？

1. アプリケーションのステータスを確認します。アプリケーションの詳細ページに移動するか、アプリケーションの RESTful API を呼び出して、アプリケーションのステータスを表示できます。アプリケーションは、次のいずれかの状態にあります。

   • アプリケーションの状態が不明です。考えられる原因:

     • アプリケーションが YARN に送信される前に、アプリケーションが失敗して終了します。この場合、アプリケーション送信ログを表示して、BRS や FlowAgent などのクライアントコンポーネントで問題が発生しているかどうかを確認します。

     • アプリケーションが ResourceManager に接続できません。この場合、ResourceManager のエンドポイントが正しいかどうか、およびネットワーク接続が正常かどうかを確認します。ネットワーク接続が異常な場合、クライアントで次のエラーが報告される可能性があります。 com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed。 // クライアントでエラーが報告される可能性があります。

   • NEW_SAVING: アプリケーションの情報が Zookeeper ステートストアに書き込まれています。アプリケーションが NEW_SAVING 状態になっている考えられる理由:

     • ZooKeeper でエラーが発生します。ZooKeeper サービスが正常かどうかを確認します。

     • ZooKeeper の読み取りまたは書き込み操作でエラーが発生します。解決策の詳細については、「ResourceManager がスタンバイ状態からアクティブ状態に自動的に切り替わらない場合はどうすればよいですか？」をご参照ください。

   • SUBMITTED: ほとんどの場合、アプリケーションはこの状態ではありません。Capacity Scheduler でノード更新リクエストの過剰によってロックの取得が発生し、Capacity Scheduler がブロックされている場合、アプリケーションは SUBMITTED 状態になる可能性があります。ほとんどの場合、Capacity Scheduler でのロックの取得と Capacity Scheduler のブロッキングは大規模クラスターで発生します。問題を解決するには、リクエスト処理手順を最適化する必要があります。詳細については、YARN-9618 をご参照ください。

   • ACCEPTED: アプリケーションがこの状態の場合、診断情報を確認します。表示されるエラーメッセージに基づいて解決策を選択できます。

     • エラーメッセージ: キューの AM リソース制限を超えました。

       • 考えられる原因: 使用済み ApplicationMaster（AM）リソースとリクエストされた AM リソースの合計が、キュー内の AM リソースの上限を超えています。AM リソースの使用量は、次の不等式を満たす必要があります。${使用済み Application Master リソース} + ${AM リソースリクエスト} < ${最大 Application Master リソース}。

       • 解決策: キュー内の AM リソースの上限を増やします。たとえば、yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent パラメーターを 0.5 に設定します。

     • エラーメッセージ: ユーザーの AM リソース制限を超えました。

       • 考えられる原因: 使用済み AM リソースとリクエストされた AM リソースの合計が、特定のユーザーのキュー内の AM リソースの上限を超えています。

       • 解決策: 特定のユーザーのキュー内の AM リソースの上限を増やします。たとえば、yarn.scheduler.capacity.<queue-path>.user-limit-factor パラメーターと yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent パラメーターを変更します。

     • エラーメッセージ: AM コンテナーが起動されました。AM コンテナーが RM に登録されるのを待機しています。

       • 考えられる原因: AM は起動されましたが、AM の初期化が完了していません。たとえば、ZooKeeper 接続がタイムアウトしました。

       • 解決策: AM ログに基づいて問題をさらにトラブルシューティングします。

     • エラーメッセージ: アプリケーションがアクティブ化されました。AM にリソースが割り当てられるのを待機しています。

       手順 3 を実行して、AM リソースが不足している原因を分析します。

   • RUNNING: アプリケーションがこの状態の場合、手順 2 を実行して、コンテナーリソースリクエストが完了しているかどうかを確認します。

   • FAILED: アプリケーションがこの状態の場合、診断情報を確認します。表示されるエラーメッセージに基づいて解決策を選択できます。

     • エラーメッセージ: システムアプリケーションの制限に達しました。アプリケーションの送信を受け入れることができません。

       • 考えられる原因: クラスターで実行されているアプリケーションの数が、yarn.scheduler.capacity.maximum-applications パラメーターで指定された上限を超えています。このパラメーターのデフォルト値は 10000 です。

       • 解決策: Java Management Extensions（JMX）メトリックを表示して、各キューで実行されているアプリケーションの数が想定どおりかどうかを確認します。繰り返し送信されるアプリケーションのトラブルシューティングを行います。すべてのアプリケーションが正常に実行されている場合は、クラスターの使用状況に基づいてパラメーターを大きい値に設定できます。

     • エラーメッセージ: ユーザー YYY によって送信されたアプリケーション XXX が不明なキュー: ZZZ に送信されました。

       • 考えられる原因: アプリケーションが、存在しないキューに送信されました。

       • 解決策: アプリケーションを既存のリーフキューに送信します。

     • エラーメッセージ: ユーザー YYY によって送信されたアプリケーション XXX が非リーフキュー: ZZZ に送信されました。

       • 考えられる原因: アプリケーションが親キューに送信されました。

       • 解決策: アプリケーションを既存のリーフキューに送信します。

     • エラーメッセージ: キュー XXX は停止されています。アプリケーション: YYY の送信を受け入れることができません。

       • 考えられる原因: アプリケーションが、STOPPED 状態または DRAINING 状態のキューに送信されました。

       • 解決策: アプリケーションを RUNNING 状態のキューに送信します。

     • エラーメッセージ: キュー XXX にはすでに YYY アプリケーションがあります。アプリケーション: ZZZ の送信を受け入れることができません。

       • 考えられる原因: キュー内のアプリケーションの数が上限に達しました。

       • 解決策:

         1. 多数のアプリケーションがキューに繰り返し送信されているかどうかを確認します。

         2. yarn.scheduler.capacity.<queue-path>.maximum-applications パラメーターを変更します。

     • エラーメッセージ: キュー XXX にはすでにユーザー ZZZ からの YYY アプリケーションがあります。アプリケーション: AAA の送信を受け入れることができません。

       • 考えられる原因: ユーザーのキュー内のアプリケーションの数が上限に達しました。

       • 解決策:

         1. ユーザーのために多数のアプリケーションがキューに繰り返し送信されているかどうかを確認します。

         2. yarn.scheduler.capacity.<queue-path>.maximum-applications パラメーター、yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent パラメーター、および yarn.scheduler.capacity.<queue-path>.user-limit-factor パラメーターを変更します。

2. YARN リソースの割り当てが完了していないことを確認します。

   1. アプリケーションのリストが表示されているページで、アプリケーションの ID をクリックして、アプリケーションの詳細ページに移動します。

   2. アプリケーションの詳細ページでアプリケーション試行の ID をクリックして、アプリケーション試行の詳細ページに移動します。

   3. [合計未処理リソースリクエスト] リストに、Pending 状態のリソースが存在するかどうかを確認します。保留中のリクエストをリクエストするために使用される RESTful API を呼び出して、Pending 状態のリソースをクエリすることもできます。

      • Pending 状態のリソースが存在しない場合、YARN リソースの割り当ては完了です。トラブルシューティング手順を終了し、AM リソースの割り当てを確認します。

      • Pending 状態のリソースが存在する場合、YARN リソースの割り当ては完了していません。次の手順に進みます。

3. リソースの制限を確認します。

   クラスターまたはキュー内のリソースを確認します。たとえば、[有効な最大リソース] パラメーターと [使用済みリソース] パラメーターの値を確認します。

   1. 次のリソースがすべて消費されているかどうかを確認します。クラスター内のリソース、キュー内のリソース、または親キュー内のリソース。

   2. リーフキュー内のディメンションのリソースが上限に近いか、上限に達しているかどうかを確認します。

   3. クラスターのリソース使用率が 100% に近い場合（85% 以上など）、アプリケーションにリソースが割り当てられる速度が低下する可能性があります。1 つの理由は、ほとんどのマシンにリソースがないことです。マシンに割り当てるリソースがない場合、マシンは予約されます。予約されたマシンの数が一定数に達すると、リソースが割り当てられる速度が低下する可能性があります。もう 1 つの考えられる理由は、メモリリソースと CPU リソースの比率が不均衡であることです。たとえば、アイドル状態のメモリリソースはあるがアイドル状態の CPU リソースがないマシンもあれば、アイドル状態の CPU リソースはあるがアイドル状態のメモリリソースがないマシンもあります。

4. リソースがコンテナーに正常に割り当てられているにもかかわらず、コンテナーが起動できないかどうかを確認します。YARN の Web UI の [アプリケーション試行] ページで、リソースが割り当てられているコンテナーの数と、短期間におけるコンテナーの数の変化を表示できます。コンテナーが起動できない場合は、NodeManager ログまたはコンテナーのログに基づいて障害のトラブルシューティングを行います。

5. ログレベルを動的に調整します。http://RM_IP:8088/logLevel にある YARN の Web UI の [ログレベル] ページで、org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity パラメーターのログレベルを DEBUG に変更します。パラメーターは、Capacity Scheduler のパッケージを示します。次の図に例を示します。

   重要

   問題を再現するときにログレベルを調整し、数十秒後にログレベルを INFO に戻すことができます。これは、短期間に多くのログが生成される可能性があるためです。

単一のタスクまたはコンテナーで使用可能なリソースの最大数を決定するパラメーターは何ですか？

YARN 設定の変更が有効にならない場合はどうすればよいですか？

• 考えられる原因:

  • 他の設定では、設定に関連付けられているコンポーネントが再起動されていません。

  • ホットアップデート設定では、設定を有効にするために必要な指定された操作が実行されていません。

• 解決策: 設定を有効にするために必要な後続の操作が正しく実行されていることを確認します。

  設定ファイル	カテゴリ	後続の操作
  capacity-scheduler.xml fair-scheduler.xml	スケジューラー設定	ResourceManager で refresh_queues 操作を実行します。設定はホットアップデート設定です。
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	YARN コンポーネントの設定	設定に関連付けられているコンポーネントを再起動します。例: yarn-env.sh ファイルの YARN_RESOURCEMANAGER_HEAPSIZE パラメーター、または yarn-site.xml ファイルの yarn.resourcemanager.nodes.exclude-path パラメーターを変更した後、ResourceManager を再起動します。 yarn-env.sh ファイルの YARN_NODEMANAGER_HEAPSIZE パラメーター、または yarn-site.xml ファイルの yarn.nodemanager.log-dirs パラメーターを変更した後、NodeManager を再起動します。 mapred-env.sh ファイルの MAPRED_HISTORYSERVER_OPTS パラメーター、または mapred-site.xml ファイルの mapreduce.jobhistory.http.policys パラメーターを変更した後、MRHistoryServer を再起動します。

例外がアプリケーションクライアントで発生した場合に次のエラーメッセージが報告された場合はどうすればよいですか？1 回のフェイルオーバー試行後に rm2 経由で ApplicationClientProtocolPBClientImpl クラスの getClusterNodes を呼び出す際の例外。すぐにフェイルオーバーしようとしましたか？

• 問題の説明: アクティブな ResourceManager にアクセスできません。ResourceManager ログには、次の例外情報が含まれています。WARN org.apache.hadoop.ipc.Server: 10.33.**.**:53144 からの不正なヘッダーまたはバージョンの不一致。バージョン 6 を取得しましたが、バージョン 9 が予期されていました。

• 原因: 古いバージョンの Hadoop が使用されています。アプリケーションクライアントで使用されているリモートプロシージャコール（RPC）のバージョンが、Hadoop のバージョンと互換性がありません。

• 解決策: RPC バージョンのアプリケーションクライアントと互換性のあるバージョンの Hadoop を使用します。

ResourceManager がスタンバイ状態からアクティブ状態に自動的に切り替わらない場合はどうすればよいですか？

ResourceManager で OOM 問題が発生した場合はどうすればよいですか？

ノードがジョブの実行を開始したときにローカライズが失敗するのはなぜですか？また、ジョブログを収集または削除できないのはなぜですか？

• 問題の説明: NodeManager ログには、次の例外情報が含まれています。java.io.IOException: プロキシプロバイダークラス org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider を作成できませんでした。

• 原因: HDFS 設定が正しくありません。

• 解決策:

  1. 例外情報はカプセル化されており、問題の根本原因ではありません。根本原因を特定するには、デバッグレベルのログを確認する必要があります。

     • Hadoop クライアントの CLI で、hadoop fs -ls / などのコマンドを実行して Hadoop にアクセスできます。次に、次のコマンドを実行してデバッグを有効にします。

       export HADOOP_LOGLEVEL=DEBUG

       // デバッグを有効にします。

     • Log4j 設定のあるランタイム環境では、log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG を Log4j 設定の末尾に追加します。 // Log4j 設定に追加します。

  2. 次の図の例は、問題の根本原因が、ユーザーが NameServices の設定を変更したためであることを示しています。ユーザーは emr-cluster を hadoop-emr-cluster に変更しました。ただし、スケールアウト後、新しいノードは NameServices の元の設定を使用しました。

  3. EMR コンソールのクラスターの HDFS サービスページの [設定] タブで、パラメーターが正しく設定されているかどうかを確認します。

リソースローカライズの例外を処理するにはどうすればよいですか？

• 問題の説明:

  • ジョブを処理するために使用される AM コンテナーが起動せず、次のエラーメッセージが報告されます。

    Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted. 例外情報は、失敗したジョブに関する診断情報です。
    

  • リソースローカライズのためにアプリケーションリソースパッケージがダウンロードされた後、解凍時にエラーが報告されます。次の NodeManager ログを確認できます。

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)
    

    // NodeManager ログを確認できます。

• 原因: アプリケーションリソースパッケージにソフトリンクが含まれているため、リソースローカライズの例外が発生します。

• 解決策: アプリケーションリソースパッケージに含まれているソフトリンクを削除します。

エラーメッセージ「デバイスに空き容量がありません」が表示され、コンテナーの起動または実行に失敗した場合はどうすればよいですか？

NodeManager で、またはジョブの実行中に、ドメイン名の解決に失敗します。どうすればよいですか？

• 問題の説明: 次のエラーメッセージが表示されます。java.net.UnknownHostException: 無効なホスト名: ローカルホストは: (不明) です。

• 考えられる原因と解決策:

  • ドメインネームシステム（DNS）サーバーが正しく設定されているかどうかを確認します。

    次のコマンドを実行して、DNS サーバーの設定を確認します。

    cat /etc/resolv.conf

    // DNS サーバーの設定を確認します。

  • ファイアウォールのポート 53 に必要なルールが設定されているかどうかを確認します。

    必要なルールが設定されている場合は、ファイアウォールを無効にします。

  • DNS サーバーでネームサービスキャッシュデーモン（NSCD）サービスが有効になっているかどうかを確認します。

    次のコマンドを実行して、NSCD サービスのステータスを確認します。

    systemctl status nscd

    // NSCD サービスのステータスを確認します。

    DNS サーバーで NSCD サービスが有効になっている場合は、次のコマンドを実行して NSCD サービスを無効にします。

    systemctl stop nscd

    // NSCD サービスを無効にします。

NodeManager で OOM 問題が発生した場合はどうすればよいですか？

ECS インスタンスの再起動後、cgroups ディレクトリがないため、NodeManager を起動できません。どうすればよいですか？

• エラーメッセージ: ResourceHandlerException: 予期しないエラー: yarn cgroup を作成できません。サブシステム:cpu マウントポイント:/proc/mounts ユーザー:hadoop パス:/sys/fs/cgroup/cpu/hadoop-yarn

• 原因: ECS インスタンスの異常な再起動は、インスタンスのカーネルの欠陥が原因である可能性があります。これは、バージョン 4.19.91-21.2.al7.x86_64 の既知の問題です。ECS インスタンスの再起動後、cgroups が無効になります。これは、再起動後にメモリ内の cgroups のデータが削除されるためです。

• 解決策: ノードグループのブートストラップスクリプトを変更します。クラスターに cgroups のディレクトリを作成し、ECS インスタンスが起動された場合は rc.local スクリプトを実行してディレクトリを作成します。次のコードに例を示します。

  # cgroups を有効にする
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn  // cgroups ディレクトリを作成します。
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn // 所有者を変更します。
  # 再起動後に cgroups を有効にする
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local // rc.local スクリプトに追加します。
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local // rc.local スクリプトに追加します。
  chmod +x /etc/rc.d/rc.local // rc.local スクリプトを実行可能にします。
  

  // ブートストラップスクリプトを変更します。

設定を保存して NodeManager を再起動した後、NodeManager のリソース設定が有効にならない場合はどうすればよいですか？

• 説明: yarn.nodemanager.resource.cpu-vcores パラメーターと yarn.nodemanager.resource.memory-mb パラメーターが変更および保存されます。ただし、NodeManager の再起動後、設定は有効になりません。

• 原因: ノードグループ内のインスタンスの CPU コア数とメモリサイズが異なる場合があります。設定を有効にするには、ノードグループの yarn.nodemanager.resource.cpu-vcores パラメーターと yarn.nodemanager.resource.memory-mb パラメーターを変更する必要があります。

• 解決策: E-MapReduce（EMR）コンソールにログインします。[YARN] サービスページの [設定] タブで、検索ボックスの右側のドロップダウンリストから [ノードグループ設定] を選択し、NodeManager が属するノードグループを選択します。次に、yarn.nodemanager.resource.cpu-vcores パラメーターと yarn.nodemanager.resource.memory-mb パラメーターを変更します。詳細については、「設定項目の管理」をご参照ください。

ノードが異常としてマークされている場合はどうすればよいですか？

• 原因:

  • ディスクヘルスチェック中に例外が検出されました: ノード上の正常なディレクトリの数の合計ディレクトリ数に対する比率が指定された比率よりも低い場合、ノードは異常としてマークされます。比率は、yarn-site.xml ファイルの yarn.nodemanager.disk-health-checker.min-healthy-disks パラメーターで指定されます。このパラメーターのデフォルト値は 0.25 です。NodeManager が存在するノードに 4 つのディスクなどの複数のディスクがデプロイされている場合、4 つのディスクすべてでディレクトリが異常な場合にのみ、ノードは異常としてマークされます。それ以外の場合、「local-dirs が不良です」または「log-dirs が不良です」というメッセージが NodeManager ステータスのレポートに記録されます。詳細については、「メッセージ「local-dirs が不良です」または「log-dirs が不良です」が報告された場合はどうすればよいですか？」をご参照ください。

  • NodeManager のヘルスチェックスクリプトによって例外が検出されました: デフォルトでは、スクリプトは無効になっています。ヘルスチェックスクリプトを有効にするには、yarn-site.xml ファイルの yarn.nodemanager.health-checker.script.path パラメーターを設定する必要があります。

• 解決策:

  • 問題がディスクの例外が原因で発生した場合は、「メッセージ「local-dirs が不良です」または「log-dirs が不良です」が報告された場合はどうすればよいですか？」セクションの解決策をご参照ください。

  • 問題がヘルスチェックスクリプトによって検出された場合は、カスタムスクリプトに基づいて問題を解決します。

メッセージ「local-dirs が不良です」または「log-dirs が不良です」が表示された場合はどうすればよいですか？

• 原因: ディスクヘルスチェックで例外が検出されました。デフォルトでは、ディスクヘルスチェック機能は有効になっています。この機能は、local-dirs と log-dirs が特定の条件を満たしているかどうかを定期的にチェックします。local-dirs はタスクのキャッシュディレクトリであり、タスクの実行に必要なファイルと中間データを格納します。log-dirs はタスクのログディレクトリであり、タスクのすべてのログを格納します。次のいずれかの条件が満たされていない場合、local-dirs または log-dirs は不良としてマークされます。

  • 読み取り可能。

  • 書き込み可能。

  • 実行可能。

  • ディスク使用率が、yarn-site.xml ファイルの yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage パラメーターで指定されたしきい値よりも低くなっています。このパラメーターのデフォルト値は 90% です。

    残りの使用可能なディスク容量が、yarn-site.xml ファイルの yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb パラメーターで指定された最小使用可能ディスク容量よりも大きくなっています。このパラメーターのデフォルト値は 0 です。

• 解決策:

  • ほとんどの場合、問題はディスク容量の不足が原因で発生します。次のいずれかの条件が満たされている場合は、ディスクをスケールアウトすることをお勧めします。

    • NodeManager が存在するノードの仕様が高く、ノードで多数のタスクが実行されています。

    • ディスク容量が不足しています。

    • タスクの実行に必要なデータまたはファイルのサイズが大きくなっています。

    • タスクの実行時に、大量の中間データが生成されます。

    • タスクログのサイズが大きく、タスクログがディスク容量のかなりの部分を占めています。

  • yarn-site.xml ファイルの yarn.nodemanager.localizer.cache.target-size-mb パラメーターを確認します。キャッシュサイズのディスクサイズに対する比率が大きすぎる場合、ほとんどのディスク容量がキャッシュされたタスクデータによって占有されます。これは、指定されたしきい値を超えた場合にのみキャッシュを自動的にクリアできるためです。

  • 破損したディスクを修復します。破損したディスクの修復方法の詳細については、「EMR クラスターの破損したローカルディスクを交換する」をご参照ください。

エラーメッセージ「ユーザー [dr.who] はアプリケーション *** のログを表示する権限がありません」が表示された場合はどうすればよいですか？

• 問題の説明: ログページを開くと、次の図の情報が表示されます。

• 原因: [NodeManager ログ] ページにアクセスすると、アクセス制御リスト（ACL）ルールがチェックされます。ACL ルールが有効になっており、リモートユーザーがアプリケーションのログを表示する場合、リモートユーザーは次のいずれかの条件を満たす必要があります。

  • リモートユーザーが管理ユーザーである。

  • リモートユーザーがアプリケーションの所有者である。

  • リモートユーザーが、アプリケーション用にカスタマイズされた ACL ルールを満たしている。

• 解決策: リモートユーザーが上記のいずれかの条件を満たしているかどうかを確認します。

エラーメッセージ「HTTP エラー 401 認証が必要です」または「HTTP エラー 403 認証されていないユーザーはこのページにアクセスできません」が表示された場合はどうすればよいですか？

• 問題の説明: Web UI にアクセスするか RESTful API を呼び出すと、エラー HTTP エラー 401 または HTTP エラー 403 が報告されます。HTTP エラー 401 の詳細は、次の図に示されています。

  

• 原因: YARN は単純な認証方法を使用しており、匿名アクセスを許可しません。詳細については、Apache Hadoop の公式ドキュメントの「Hadoop HTTP Web コンソールの認証」をご参照ください。

• 解決策:

  • 方法 1: リモートユーザーを指定する URL パラメーター（user.name=*** など）を設定します。

  • 方法 2：EMR コンソールのクラスターの HDFS サービスページの [構成] タブにある [構成フィルター] セクションで、hadoop.http.authentication.simple.anonymous.allowed パラメーターを検索し、パラメーターの値を true に変更して匿名アクセスを許可します。パラメーターの詳細については、Apache Hadoop の公式ドキュメントの Authentication for Hadoop HTTP web-consoles をご参照ください。次に、HDFS サービスを再起動します。詳細については、「サービスの再起動」をご参照ください。

TotalVcore の表示値が正しくないのはなぜですか？

YARN の Web UI の右上隅にあるクラスターまたはメトリック RESTful API セクションで、TotalVcore の表示値が正しくありません。これは、2.9.2 より前の Apache Hadoop バージョンにおける TotalVcore の計算ロジックの問題です。詳細については、Apache Hadoop の公式ドキュメントの「CapacityScheduler が一部のコンテナーを予約している場合、クラスターメトリックの合計 vCore 数が間違っています」をご参照ください。

この問題は、EMR V3.37.x、EMR V5.3.x、およびそれ以降のマイナーバージョンで修正されています。

Tez の Web UI に表示されるアプリケーションの情報が不完全な場合はどうすればよいですか？

Spark Thrift JDBC/ODBC サーバータスクが YARN の Web UI で実行されているのはなぜですか？？

クラスターの作成時に Spark を選択すると、デフォルトの Spark Thrift Server サービスが自動的に起動されます。サービスは、1 つの YARN ドライバーのリソースを占有します。デフォルトでは、Spark Thrift Server で実行されるタスクは、このドライバーを使用して YARN から必要なリソースを申請します。

yarn.timeline-service.leveldb-timeline-store.path パラメーターを OSS バケット URL に設定できますか？

いいえ、yarn.timeline-service.leveldb-timeline-store.path パラメーターを OSS バケット URL に設定することはできません。

作成するクラスターが Hadoop クラスターの場合、yarn.timeline-service.leveldb-timeline-store.path パラメーターのデフォルト値は、hadoop.tmp.dir パラメーターの値と同じです。yarn.timeline-service.leveldb-timeline-store.path パラメーターの設定に影響を与える hadoop.tmp.dir パラメーターは変更しないでください。

Timeline Server への接続がタイムアウトした場合、または CPU 負荷やメモリ使用量が非常に高い場合はどうすればよいですか？

多数の Tez ジョブの場合、Timeline Server にデータが書き込まれるときに、YARN の Timeline Server への接続がタイムアウトする可能性があります。これは、Timeline Server プロセスが大量の CPU リソースを占有し、Timeline Server が実行されているノードの CPU 負荷が上限に達するためです。その結果、ジョブ開発やレポート生成などの非コアサ サービスが影響を受けます。この場合、Timeline Server プロセスを一時的に停止して、ノードの CPU 負荷を軽減できます。問題を解決するには、次の設定項目を追加または変更できます。

EMR コンソールで Tez サービスと YARN サービスの設定を追加または変更します。詳細については、「設定項目の管理」をご参照ください。

1. EMRコンソールのTezサービスページの [構成] タブにある [tez-site.xml] タブに移動します。名前が [tez.yarn.ats.event.flush.timeout.millis] で、値が 60000 の構成項目を追加します。この構成項目は、Tezジョブの実行時にYARNのTimeline Serverにイベントを書き込むために許可されるタイムアウト期間を指定します。

2. EMRコンソールのYARNサービスページの [構成] タブにある [yarn-site.xml] タブに移動し、次の表に記載されている構成項目を追加または変更します。追加または変更操作が完了したら、YARNサービスページの [ステータス] タブで Timeline Server を再起動する必要があります。

   設定項目	値	説明
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	YARN Timeline Server のイベントストレージクラスを指定します。
   yarn.timeline-service.rolling-period	daily	YARN Timeline Server のイベントローリング期間を指定します。
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	YARN Timeline Server LevelDB ストアの読み取りキャッシュのサイズを指定します。
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	YARN Timeline Server LevelDB ストアの書き込みバッファーのサイズを指定します。
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	YARN Timeline Server LevelDB ストアで開くことができるファイルの最大数を指定します。