YARN サービス設定

このドキュメントでは、YARNにデプロイするサービスを設定する方法について説明します。

主に3種類の設定があります。

以下では、各設定タイプの詳細について説明します。

カスタムサービスの設定

以下は、設定オブジェクトの一般的な例です。

"configuration" : {
    "properties" : {
        "yarn.service.am-restart.max-attempts" : 10  // config for the service AM
    },
    "env" : {                 // The environment variables to be exported when container gets launched
        "env1" : "val1"
    },
    "files" : [               // The list of configuration files to be mounted for the container
        {
            "type": "HADOOP_XML", // The format of the config file into which the "properties" are dumped
            "dest_file": "/etc/hadoop/conf/core-site.xml", // The location where the config file is mounted inside the container
            "properties" : {             // The list of key/value pairs to be dumped into the config file
                "fs.defaultFS" : "hdfs://myhdfs" // This property will be written into core-site.xml
            }
        },
        {
            "type": "HADOOP_XML",    // The format of the config file.
            "src_file" : ""hdfs://mycluster/tmp/conf/yarn-site.xml""  // The location of the source config file to be downloaded
            "dest_file": "/etc/hadoop/conf/yarn-site.xml",            // The location where the config file will be mounted inside the container/
            "properties" : {
                "yarn.resourcemanager.webapp.address" : "${COMPONENT_INSTANCE_NAME}.${SERVICE_NAME}.${USER}.${DOMAIN}"  // Merge into (or override existing property in) yarn-site.xml
            }
        }
    ]
}
  • properties: サービスAMの設定。詳細は以下をご覧ください。
  • env: コンテナが起動されたときにエクスポートされる環境変数。
  • files: コンテナ内にマウントされる設定ファイルのリスト。
    • type: コンテナ内にマウントされる設定ファイル（`dest_file`）の形式。 `src_file` が指定されている場合、`src_file` と `dest_file` 両方の形式でもあります。
    • HADOOP_XML: Hadoop XML形式。 `src_file` が指定されている場合、ファイルの内容はHadoop XML形式で解析されて読み取られます。
    • XML: 標準XML形式
    • JSON: 標準JSON形式
    • YAML: YAML形式
    • PROPERTIES: Java PROPERTIES形式
    • TEMPLATE: プレーンテキスト形式。 `src_file` が指定されている場合、`src_file` の内容は定数の置換後 `dest_file` に書き込まれます。 `src_file` が指定されていない場合、`properties` フィールドのキーとして `content` を使用し、値は定数の置換後 `dest_file` に書き込まれる実際の内容になります。例：
      {
    "type": "TEMPLATE"
    "dest_file": "/etc/conf/hello"
    "properties" : {
         "content" : "Hello world"
    }
}

      文字列 `Hello world` は、コンテナ内の `/etc/conf/hello` にあるファイルに書き込まれます。

    • src_file: [オプション]、HDFSなどのネットワークアクセス可能な場所にある設定ファイルのソースの場所。
    • `src_file` と `dest_file` の両方の形式は、`type` によって定義されます。
    • 現在、`HADOOP_XML` および `TEMPLATE` タイプでのみ機能します。
    • `src_file` はYARN NodeManagerによってダウンロードされ、`dest_file` で指定された場所にあるコンテナ内にマウントされます。
    • `properties` フィールドで指定されたプロパティがある場合、それらは `src_file` に追加されます（または `src_file` の既存のプロパティを上書きします）。
    • `src_file` が指定されていない場合、`properties` フィールドのプロパティのみが `dest_file` ファイルに書き込まれます。
    • dest_file: 設定ファイルがコンテナ内にマウントされる場所。ファイル形式は `type` によって定義されます。 dest_fileは絶対パスまたは相対パスにすることができます。相対パスの場合、ファイルは `$PWD/conf` ディレクトリ（`$PWD` はYARNによって起動されたすべてのDockerコンテナにマウントされているコンテナローカルディレクトリ）にあります。
    • properties: `type` で定義された形式で `dest_file` に書き込まれるキー/値ペア設定のリスト。 `src_file` が指定されている場合、これらのプロパティは `src_file` に追加されます（または `src_file` の既存のプロパティを上書きします）。

YARNサービスAMの設定

このセクションでは、YARNサービスAMを設定するための設定について説明します。

システム全体の設定プロパティ

システム全体のサービスAMプロパティは、クラスタの `yarn-site.xml` ファイルでのみ設定できます。

システムレベル設定名 説明
yarn.service.framework.path サービスAM依存関係tarballのHDFSパス。この場所にファイルが存在しない場合、サービスが初めて開始または起動されたときにAMの依存関係がRMによってアップロードされます。RMユーザーがこの場所にファイルをアップロードする権限を持っていない場合、または場所がワールド読み取り可能でない場合、サービスが開始または起動されるたびにAM依存関係jarがアップロードされます。指定しない場合、値は/yarn-services/${hadoop.version}/service-dep.tar.gzと想定されます。
yarn.service.base.path サービスアーティファクトが格納されるHDFS親ディレクトリ（デフォルト ${user_home_dir}/.yarn/）。
yarn.service.client-am.retry.max-wait-ms サービスクライアントがサービスAMと通信するための最大再試行時間（ミリ秒）（デフォルト900000、つまり15分）。
yarn.service.client-am.retry-interval-ms サービスクライアントがサービスAMと通信するための再試行間隔（ミリ秒）（デフォルト2000、つまり2秒）。
yarn.service.queue サービスが送信されるデフォルトキュー（デフォルトでは `default` キューに送信されます）。キューは、サービスレベルの設定プロパティではなく、`queue` フィールドを介してサービスごとに指定できることに注意してください。

サービスレベルの設定プロパティ

サービスレベルのサービスAM設定プロパティは、クラスタの `yarn-site.xml` でグローバルレベルで指定するか（事実上、システム全体のデフォルト値をオーバーライドします）、または以下の例のように `Configuration` オブジェクトの `properties` フィールドでサービスごとに指定できます。

{
    "configuration" : {
        "properties" : {
            "yarn.service.am-restart.max-attempts" : 10
        }
    }
}

上記の設定では、サービスAMを最大10回再試行できます。

サービスレベル設定名 説明
yarn.service.am-restart.max-attempts サービスAMを開始する最大回数。この回数を超えると、サービスは強制終了されます（デフォルト20）。
yarn.service.am-resource.memory サービスAMのメモリサイズ（MB）（デフォルト1024）。
yarn.service.am.java.opts サービスAMの追加JVMオプション（デフォルト " -Xmx768m" は、-Xmxを指定しないJVMオプションに追加されます）。
yarn.service.container-recovery.timeout.ms 新しく開始されたサービスAMが、RMからまだリカバリされていない以前のAM試行のすべてのコンテナを解放するまでのタイムアウト（ミリ秒）（デフォルト120000、つまり2分）。
yarn.service.failure-count-reset.window コンポーネントごとの `yarn.service.container-failure-per-component.threshold` および `yarn.service.node-blacklist.threshold` の評価対象となるコンテナ障害カウントがリセットされる間隔（秒）（デフォルト21600、つまり6時間）。
yarn.service.readiness-check-interval.seconds 準備チェックの間隔（秒）（デフォルト30秒）。
yarn.service.log.include-pattern アプリケーションの完了後にログを集約するときに、名前でログファイルを含めるための正規表現（デフォルトではすべてのファイルを含みます）。
yarn.service.log.exclude-pattern アプリケーションの完了後にログを集約するときに、名前でログファイルを除外するための正規表現。ログファイル名がincludeパターンとexcludeパターンの両方に一致する場合、このファイルは除外されます（デフォルトではファイルを除外しません）。
yarn.service.rolling-log.include-pattern アプリの実行中にログを集約するときに、名前でログファイルを含めるための正規表現。
yarn.service.rolling-log.exclude-pattern アプリの実行中にログを集約するときに、名前でログファイルを除外するための正規表現。ログファイル名がincludeパターンとexcludeパターンの両方に一致する場合、このファイルは除外されます。
yarn.service.classpath yarnサービスAMのコンマ区切りの追加クラスパスパラメータ。これらのパス要素は、YARNサービスAMクラスパスの最後に追加されます。
yarn.service.am.client.port-range Yarn Service AMがバインド時に使用できるポートの範囲。すべてのポートを使用する場合は空白のままにします。例：50000-50050,50100-50200。

コンポーネントレベルの設定プロパティ

コンポーネントレベルのサービスAM設定プロパティは、クラスタのyarn-site.xmlでグローバルレベル（事実上、システム全体でデフォルト値をオーバーライド）で指定するか、Configurationオブジェクトのpropertiesフィールドでサービスごとに指定するか、コンポーネントのConfigurationオブジェクトのpropertiesフィールドでコンポーネントごとに指定できます。

コンポーネントレベルの設定名 説明
yarn.service.container-failure.retry.max コンテナが失敗した場合に自動的に再起動される最大試行回数（デフォルトは-1で、永久に再試行されます）。
yarn.service.container-failure.retry-interval-ms コンテナを再起動する再試行間隔（ミリ秒）（デフォルトは30000、つまり30秒）。
yarn.service.container-failure.validity-interval-ms 障害有効間隔（ミリ秒）。0より大きい値に設定すると、コンテナの再試行ポリシーは、この間隔外で発生した障害を障害カウントに含めません（デフォルトは-1で、これまでのすべての障害が障害カウントに含まれます）。
yarn.service.container-failure-per-component.threshold AMがサービスを停止する前に、特定のコンポーネントで許容されるコンテナ障害の最大絶対数（再試行は含まない）（デフォルトは10）。
yarn.service.node-blacklist.threshold ノードがAMによってブラックリストに登録される前に、ノードで許容されるコンテナ障害の最大数（再試行は含まない）（デフォルトは3）。
yarn.service.default-readiness-check.enabled デフォルトのレディネスチェックが有効かどうか（デフォルトはtrue）。
yarn.service.container-health-threshold.percent 特定のコンポーネント、またはすべてのコンポーネントに対してグローバルに明示的に設定されている場合、コンテナのヘルスしきい値の割合は、正常なコンテナの割合を定期的にチェックするヘルスチェックモニターをスケジュールします。コンテナは、READY状態であれば正常です。指定された/デフォルトのポーリング頻度でチェックを実行します。コンポーネントが指定された/デフォルトのウィンドウの間、ヘルスしきい値を下回ることを許可し、その後、サービスが異常であると見なし、サービスの停止をトリガーします。ヘルスしきい値の割合が有効になっている場合、yarn.service.container-failure-per-component.thresholdは無視されます。
yarn.service.container-health-threshold.poll-frequency-secs ヘルスチェックモニターのポーリング頻度。これは高度な設定であり、サービス所有者がその意味を理解しておらず、デフォルトを望まない場合を除いて、設定する必要はありません。デフォルトは10秒です。
yarn.service.container-health-threshold.window-secs ヘルスチェックモニターが、特定のコンポーネントがヘルスしきい値を下回ることを許容する時間の長さで、その後、サービスが異常であると見なします。デフォルトは600秒（10分）です。
yarn.service.container-health-threshold.init-delay-secs ヘルスチェックモニターが最初のチェックを開始する前に待機する初期時間の長さ。サービスコンテナが初めて起動するためのリードタイムを提供します。デフォルトは600秒（10分）です。
yarn.service.container-state-report-as-service-state このコンポーネントが終了した場合、サービスも終了することを示すブール値フラグ。デフォルトはfalseです。

yarn-site.xmlファイルでは、サービス仕様とは異なる方法で設定されるコンポーネントレベルの設定プロパティが1つあります。Dockerコンテナに使用されるDockerネットワークタイプを選択するには、サービスConfigurationのpropertiesまたはコンポーネントConfigurationのpropertiesでdocker.networkを設定できます。YARNサービスコンテナと他のすべてのアプリケーションコンテナの両方のDockerネットワークタイプのシステム全体のデフォルトは、yarn-site.xmlファイルのyarn.nodemanager.runtime.linux.docker.default-container-networkプロパティによって設定されます。

コンポーネントレベルのレディネスチェックプロパティ

AMは、Componentフィールドのreadiness_checkを介して、コンテナのレディネスチェックを実行するように構成できます。コンテナは、レディネスチェックが成功するまでREADY状態になりません。レディネスチェックが指定されていない場合、yarn.service.default-readiness-check.enabledコンポーネントレベルの設定プロパティによって無効にされない限り、デフォルトのレディネスチェックが実行されます。

デフォルトのレディネスチェックは、コンテナのIPが使用可能になると成功します。IPチェックに加えて、DNSチェックを構成するオプションのプロパティもあります。DNSチェックにより、コンテナがレディと見なされる前に、コンテナホスト名のDNSルックアップが成功することが保証されます。たとえば、デフォルトのレディネスチェックのDNSチェックは、次のように有効にできます。

      "readiness_check": {
        "type": "DEFAULT",
        "properties": {
          "dns.check.enabled": "true"
        }
      },

AMが実行できるレディネスチェックの構成可能なプロパティの完全なリストを以下に示します。

レディネスチェック 構成可能なプロパティ 説明
DEFAULT、HTTP、PORT dns.check.enabled DNSチェックを実行する必要がある場合はtrue（デフォルトはfalse）
DEFAULT、HTTP、PORT dns.address DNSチェックに使用するDNSサーバーのオプションのIP：ポートアドレス
HTTP url HTTPレスポンスチェックに必要なURL。例：http://${THIS_HOST}:8080
HTTP timeout 接続タイムアウト（デフォルトは1000）
HTTP min.success 成功と見なされる最小レスポンスコード（デフォルトは200）
HTTP max.success 成功と見なされる最大レスポンスコード（デフォルトは299）
PORT port ソケット接続に必要なポート
PORT timeout ソケット接続タイムアウト（デフォルトは1000）

HTTPレディネスチェックの例

      "readiness_check": {
        "type": "HTTP",
        "properties": {
          "url": "http://${THIS_HOST}:8080"
        }
      },

PORTレディネスチェックの例

      "readiness_check": {
        "type": "PORT",
        "properties": {
          "port": "8080"
        }
      },

Dockerコンテナのhostネットワークでレディネスチェックを構成する場合の警告

複数のコンテナを持つコンポーネントにhost Dockerネットワークが構成されており、コンテナが特定のポートにバインドされている場合、コンテナが同じホストに割り当てられるとポートの競合が発生します。この状況では、HTTPおよびPORTレディネスチェックは無効になります。特に、チェックが同じIP（ホストのIP）に対して実行されているため、両方のコンテナ（ポートへのバインドに成功したコンテナとそうでないコンテナ）でHTTPまたはPORTレディネスチェックが成功する可能性があります。このようなサービスの有効な構成では、アンチアフィニティ配置ポリシーを使用して、コンテナが異なるホストに割り当てられ、ポートの競合が発生しないようにすることができます。

カスタムサービスの定数変数

サービスフレームワークは、ユーザーがサービスを構成するための定数変数をいくつか提供します。これらの変数は、システムによって動的に生成されるか、ユーザーが定義したサービス名などの静的な変数です。ユーザーは、設定でこれらの定数を使用して、サービスAMによって動的に置換できます。例：

{
    "type" : "HADOOP_XML",
    "dest_file" : "/etc/hadoop/hbase-site.xml",
    "properties" : {
        "hbase.regionserver.hostname": "${COMPONENT_INSTANCE_NAME}.${SERVICE_NAME}.${USER}.${DOMAIN}"
    }
}

ここで、COMPONENT_INSTANCE_NAMEとSERVICE_NAMEは、システムによって置換される定数です。

COMPONENT_INSTANCE_NAMEがregionserver-0で、SERVICE_NAMEがユーザーによってhbaseとして定義され、ユーザー名がdevuserで、ドメイン名がdev.testであるとします。次に、設定はサービスAMによって置換され、コンテナ内の設定ファイル/etc/hadoop/hbase-site.xmlに次のように書き込まれます。

<property>
  <name>hbase.regionserver.hostname</name>
  <value>regionserver-0.hbase.devuser.dev.test</value>
</property>

ここで、regionserver-0は、システムによってこのコンテナに割り当てられた実際のコンポーネントインスタンス名です。

使用可能な定数

名前 説明
SERVICE_NAME ユーザーが定義したサービスの名前
USER サービスを送信したユーザー。「_」を含むユーザー名は、DNSホスト名RFC形式（「_」は許可されない）に準拠するために「-」を使用して変換され、すべての文字は小文字になります。例：「Bob_dev」は「bob-dev」に変換されます
DOMAIN クラスタのドメイン名
COMPONENT_NAME 特定のコンポーネントの名前
COMPONENT_INSTANCE_NAME 特定のコンポーネントインスタンス（つまり、コンテナ）の名前
COMPONENT_ID 特定のコンポーネントの単調増加整数
CONTAINER_ID 特定のコンテナのYARNコンテナID
${COMPONENT_INSTANCE_NAME}_HOST コンポーネントインスタンス（つまり、コンテナ）のホスト名。例：REGIONSERVER-0_HOSTは、コンポーネントインスタンスの実際のホスト名に置き換えられます。すべての文字は大文字である必要があります。
${COMPONENT_INSTANCE_NAME}_IP コンポーネントインスタンス（つまり、コンテナ）のIP。例：REGIONSERVER-0_IPは、コンポーネントインスタンスの実際のIPアドレスに置き換えられます。すべての文字は大文字である必要があります。
CLUSTER_FS_URI クラスタhdfsのURI