Dynamometer は、Hadoop の HDFS NameNode のパフォーマンスをテストするためのツールです。その目的は、実世界の環境を提供することであり、本番のファイルシステムイメージに対して NameNode を初期化し、例えば NameNode の監査ログを介して収集された本番ワークロードを再生することです。これにより、本番環境で経験する特性と類似しているだけでなく、実際には同一のワークロードを再生できます。
Dynamometer は、単一の NameNode と構成可能な数の DataNode を起動する YARN アプリケーションを起動し、HDFS クラスター全体を単一のアプリケーションとしてシミュレートします。監査ログを入力として受け取り、そこに含まれる情報を使用して NameNode に一致するリクエストを送信し、サービスに負荷をかける追加のワークロードジョブが MapReduce ジョブとして実行されます。
Dynamometer は、異なる Hadoop バージョンまたは異なる構成に対してこの同じワークロードを実行できるため、実際の大規模クラスターにデプロイする必要なく、構成の微調整とコード変更を大規模にテストできます。
このドキュメント全体を通して、「Dyno-HDFS」、「Dyno-NN」、「Dyno-DN」は、Dynamometer アプリケーション内部で起動される HDFS クラスター、NameNode、および DataNode をそれぞれ指すために使用します。修飾なしで使用される HDFS、YARN、および NameNode などの用語は、Dynamometer が実行される既存のインフラストラクチャを指します。
Dynamometer の使用方法ではなく、その仕組みの詳細については、このページの最後にあるアーキテクチャセクションを参照してください。
Dynamometer は YARN アプリケーションに基づいて構築されているため、実行には既存の YARN クラスターが必要です。また、通信用の一時ファイルを保存するために、付随する HDFS インスタンスも必要です。
Dynamometer は、それぞれ独自のモジュールにある3つの主要なコンポーネントで構成されています
dynamometer-infra): これは、Dyno-HDFS クラスターを起動する YARN アプリケーションです。dynamometer-workload): これは、監査ログを再生する MapReduce ジョブです。dynamometer-blockgen): これは、各 Dyno-DN の入力ファイルを生成するために使用される MapReduce ジョブです。その実行は、インフラストラクチャアプリケーションを実行するための前提条件ステップです。これらのすべてのコンポーネントのコンパイル済みバージョンは、標準の Hadoop ディストリビューションに含まれます。パッケージ化されたディストリビューション内の share/hadoop/tools/dynamometer にあります。
Dynamometer アプリケーションを起動する前に、Dynamometer に使用する構成、使用するバージョン、読み込み時に使用する fsimage などを指示する、完了する必要のあるセットアップ手順が多数あります。これらの手順は、すべてを配置するために1回だけ実行でき、その後、変動を測定するためのマイナーな微調整を使用して、多くの Dynamometer 実行を実行できます。
以下で説明するスクリプトは、ディストリビューションの share/hadoop/tools/dynamometer/dynamometer-{infra,workload,blockgen}/bin ディレクトリにあります。対応する Java JAR ファイルは、share/hadoop/tools/lib/ ディレクトリにあります。以下の bin ファイルへの参照は、現在の作業ディレクトリが share/hadoop/tools/dynamometer であることを前提としています。
最初の Dyno-HDFS クラスターを起動する前に、いくつかの手順が必要です
NameNode から fsimage および関連ファイルを収集します。これには、NameNode がチェックポイントの一部として作成する fsimage_TXID ファイル、イメージの md5 ハッシュを含む fsimage_TXID.md5、いくつかのメタデータを含む VERSION ファイル、オフラインイメージビューアーを使用して fsimage から生成できる fsimage_TXID.xml ファイルが含まれます。
hdfs oiv -i fsimage_TXID -o fsimage_TXID.xml -p XML
アクティブな NameNode に追加の負荷をかけないように、セカンダリ/スタンバイ NameNode からこれらのファイルを収集することをお勧めします。
これらのファイルはすべて、さまざまなジョブがアクセスできる HDFS 上のどこかに配置する必要があります。それらはすべて、同じフォルダー (例: hdfs:///dyno/fsimage) にある必要があります。
これらの手順はすべて、upload-fsimage.sh スクリプトで自動化できます。例:
./dynamometer-infra/bin/upload-fsimage.sh 0001 hdfs:///dyno/fsimage
ここで、0001 は目的の fsimage のトランザクション ID です。詳細については、スクリプトの使用情報を参照してください。
Dyno-NN および -DN の起動に使用する Hadoop ディストリビューション tarball を収集します。たとえば、Hadoop 3.0.2 に対してテストする場合は、hadoop-3.0.2.tar.gz を使用します。このディストリビューションには、Dynamometer に不要なコンポーネント (例: YARN) がいくつか含まれているため、サイズを小さくするために、必要に応じて create-slim-hadoop-tar.sh スクリプトを使用できます。
./dynamometer-infra/bin/create-slim-hadoop-tar.sh hadoop-VERSION.tar.gz
Hadoop tar は、クライアントが実行される場所からローカルに、または HDFS 上に存在できます。そのパスは、-hadoop_binary_path 引数を介してクライアントに提供されます。
または、-hadoop_version 引数を使用する場合は、実行するバージョン (例: '3.0.2') を指定するだけで、クライアントは Apache ミラーから自動的にダウンロードしようとします。詳細については、クライアントの使用情報を参照してください。
構成ディレクトリを準備します。標準の Hadoop 構成レイアウト (例: etc/hadoop/*-site.xml を含む) を持つ構成ディレクトリを指定する必要があります。これにより、Dyno-NN および -DN が起動される構成が決まります。Dynamometer が正常に動作するように変更する必要がある構成 (例: fs.defaultFS または dfs.namenode.name.dir) は、実行時に上書きされます。これは、ローカルで利用可能な場合はディレクトリ、それ以外の場合はローカルまたはリモート (HDFS) ストレージ上のアーカイブファイルになります。
これは、fsimage_TXID.xml ファイルを使用して、各 Dyno-DN が Dyno-NN にアドバタイズする必要があるブロックのリストを生成します。これは MapReduce ジョブとして実行されます。
./dynamometer-blockgen/bin/generate-block-lists.sh
-fsimage_input_path hdfs:///dyno/fsimage/fsimage_TXID.xml
-block_image_output_dir hdfs:///dyno/blocks
-num_reducers R
-num_datanodes D
この例では、上記でアップロードした XML ファイルを使用して、hdfs:///dyno/blocks にブロックリストを生成します。ジョブには R リデューサーが使用され、D ブロックリストが生成されます。これにより、Dyno-HDFS クラスターで起動される Dyno-DN の数が決定されます。
この手順は、Dynamometer の監査トレース再生機能を使用する場合にのみ必要です。Dyno-HDFS クラスターを起動するだけでよい場合は、次のセクションに進むことができます。
監査トレース再生は、マッパーごとに1つの入力ファイルを受け入れ、現在、auditreplay.command-parser.class 構成を介して構成可能な2つの入力形式をサポートしています。起動時に指定された監査ログディレクトリ内のすべての監査ログファイルに対して、1つのマッパーが自動的に作成されます。
デフォルトは、直接形式の org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogDirectParser です。これは、標準構成の監査ロガーによって生成された形式のファイル (例: 次のような行) を受け入れます
1970-01-01 00:00:42,000 INFO FSNamesystem.audit: allowed=true ugi=hdfs ip=/127.0.0.1 cmd=open src=/tmp/foo dst=null perm=null proto=rpc
この形式を使用する場合は、監査トレースの開始時間 (Unix エポックからのミリ秒単位) である auditreplay.log-start-time.ms も指定する必要があります。これは、すべてのマッパーが単一の開始時間に同意するために必要です。たとえば、上記の行が最初の監査イベントである場合は、auditreplay.log-start-time.ms=42000 を指定します。ファイル内では、監査ログはタイムスタンプが昇順になっている必要があります。
サポートされているもう1つの形式は、org.apache.hadoop.tools.dynamometer.workloadgenerator.audit.AuditLogHiveTableParser です。これは、出力フィールドを持つ Hive クエリによって生成された形式のファイルを受け入れます (順番に)
relativeTimestamp: トレースの開始からのミリ秒単位でのイベント時間オフセットugi: 送信ユーザーのユーザー情報command: コマンドの名前 (例: 'open')source: ソースパスdest: 宛先パスsourceIP: イベントのソース IP監査ログが Hive で利用可能であると仮定すると、これは次のような Hive クエリによって生成できます
INSERT OVERWRITE DIRECTORY '${outputPath}'
SELECT (timestamp - ${startTimestamp} AS relativeTimestamp, ugi, command, source, dest, sourceIP
FROM '${auditLogTableLocation}'
WHERE timestamp >= ${startTimestamp} AND timestamp < ${endTimestamp}
DISTRIBUTE BY src
SORT BY relativeTimestamp ASC;
上記の Hive クエリでは、DISTRIBUTE BY src 句があることに気づくかもしれません。これは、出力ファイルが呼び出し元のソース IP でパーティション分割されるべきであることを示しています。これは、単一のクライアントから発信されたリクエストの順序をより密接に維持しようとするために行われます。Dynamometer は、パーティション内であっても操作の厳密な順序を保証しませんが、通常、順序はパーティション間よりもパーティション内でより密接に維持されます。
Hive を使用する場合でも、生の監査ログを使用する場合でも、ワークロード再生を実行するために必要な同時クライアント数に基づいて監査ログをパーティション分割する必要があります。ソース IP をパーティションキーとして使用することは、上記で説明した潜在的な利点があるアプローチの1つですが、どのパーティションスキームでも適切に機能するはずです。
上記の設定手順が完了したら、Dyno-HDFS クラスターを起動し、それに対してワークロードを再生する準備ができました。
Dyno-HDFS YARN アプリケーションを起動するクライアントは、Dyno-HDFS クラスターが完全に起動したら、ワークロード再生ジョブをオプションで起動できます。これにより、各再生がクライアントの単一実行になり、さまざまな構成のテストが容易になります。また、より詳細な制御を行うために、2つを個別に起動することもできます。同様に、Dynamometer/YARN によって制御されていない外部の NameNode 用に Dyno-DN を起動することも可能です。これは、まだサポートされていない NameNode 構成（例：HA NameNode）をテストする場合に役立ちます。これを行うには、外部 NameNode のサービス RPC アドレスを指す値を指定して、-namenode_servicerpc_addr 引数をインフラストラクチャアプリケーションに渡します。
まず、インフラストラクチャアプリケーションを起動して、内部 HDFS クラスターの起動を開始します。例：
./dynamometer-infra/bin/start-dynamometer-cluster.sh
-hadoop_binary_path hadoop-3.0.2.tar.gz
-conf_path my-hadoop-conf
-fs_image_dir hdfs:///fsimage
-block_list_path hdfs:///dyno/blocks
これは、必要な引数を示しています。-help フラグを指定して実行すると、さらに詳しい使用情報が表示されます。
クライアントは、Dyno-NN の起動の進行状況と、ライブとみなされる Dyno-DN の数を追跡します。Dyno-NN がセーフモードを終了し、使用可能になったときに、ログを通じて通知します。
この時点で、ワークロードジョブ（マップのみの MapReduce ジョブ）を起動できます。例：
./dynamometer-workload/bin/start-workload.sh
-Dauditreplay.input-path=hdfs:///dyno/audit_logs/
-Dauditreplay.output-path=hdfs:///dyno/results/
-Dauditreplay.num-threads=50
-nn_uri hdfs://namenode_address:port/
-start_time_offset 5m
-mapper_class_name AuditReplayMapper
ワークロード生成のタイプは構成可能です。AuditReplayMapper は、以前に説明したように監査ログトレースを再生します。AuditReplayMapper は、構成によって設定されます。監査ログファイルの入力パス、結果の出力パス、およびマップタスクごとのスレッド数を指定するために、auditreplay.input-path、auditreplay.output-path、auditreplay.num-threads が必要です。input-path 内のファイル数に等しい数のマップタスクが起動されます。各タスクは、これらの入力ファイルの1つを読み取り、そのファイルに含まれるイベントを再生するために num-threads スレッドを使用します。監査ログイベントを、元の発生ペースと同じペースで忠実に再生するために最善を尽くします（オプションで、これは再生速度に対する乗法係数である auditreplay.rate-factor を指定することで調整できます。たとえば、イベントを元の速度の2倍で再生するには2.0を使用します）。
AuditReplayMapper は、ベンチマーク結果を CSV 形式で出力ディレクトリ内のファイル part-r-00000 に出力します。各行の形式は user,type,operation,numops,cumulativelatency です。例：hdfs,WRITE,MKDIRS,2,150。
インフラストラクチャアプリケーションクライアントにワークロードを自動的に起動させるには、ワークロードジョブのパラメータをインフラストラクチャスクリプトに渡します。現時点では、AuditReplayMapper のみがこの方法でサポートされています。上記で使用したパラメータと同じパラメータを使用して統合アプリケーションを起動するには、以下を使用できます。
./dynamometer-infra/bin/start-dynamometer-cluster.sh
-hadoop_binary hadoop-3.0.2.tar.gz
-conf_path my-hadoop-conf
-fs_image_dir hdfs:///fsimage
-block_list_path hdfs:///dyno/blocks
-workload_replay_enable
-workload_input_path hdfs:///dyno/audit_logs/
-workload_output_path hdfs:///dyno/results/
-workload_threads_per_mapper 50
-workload_start_delay 5m
この方法で実行すると、クライアントはワークロードが完了すると、自動的に Dyno-HDFS クラスターをシャットダウンします。サポートされているパラメータの完全なリストを表示するには、-help フラグを指定してこれを実行します。
Dynamometer は、YARN 上のアプリケーションとして実装されています。Dynamometer アプリケーションには、主に3つのアクターがあります。
ドライバーにカプセル化されたロジックにより、ユーザーは単一のコマンドで Dynamometer の完全なテスト実行を実行できるため、さまざまなパラメータをスイープして最適な構成を見つけることができます。
インフラストラクチャアプリケーションは、単一の NameNode と多数の DataNode が起動され、相互に接続されて完全にシミュレートされた HDFS クラスターを作成するネイティブ YARN アプリケーションとして記述されています。Dynamometer が非常に現実的なシナリオを提供するためには、NameNode の観点から、本番クラスターと同じ情報を含むクラスターが必要です。これが、上記で説明したセットアップ手順で、最初に本番 NameNode から FsImage ファイルを収集し、ホスト HDFS クラスターに配置することが必要になる理由です。クラスター全体のブロックをコピーする必要を回避するために、Dynamometer はブロックに格納された実際のデータが NameNode には関係なく、ブロックメタデータのみを認識しているという事実を利用します。Dynamometer の blockgen ジョブは、まずオフラインイメージビューアを使用して FsImage を XML に変換し、次にこれを解析して各ブロックのメタデータを抽出し、この情報をパーティション分割してから、シミュレートされた DataNode が消費するために HDFS に配置します。SimulatedFSDataset は、DataNode ストレージレイヤーをバイパスし、前の手順で抽出された情報からロードされたブロックメタデータのみを格納するために使用されます。このスキームにより、メタデータのサイズがデータ自体よりも数桁小さいので、Dynamometer は各物理ノードに多数のシミュレートされた DataNode を配置できます。
本番環境に一致するストレステストを作成するには、Dynamometer は本番ワークロードに関する情報を収集する方法が必要です。このために、NameNode に対するすべてのクライアント側の操作の忠実な記録を含む HDFS 監査ログが使用されます。この監査ログを再生してクライアント負荷を再作成し、シミュレートされた DataNode を実行してクラスター管理負荷を再作成することにより、Dynamometer は本番 NameNode の状態を現実的にシミュレーションすることができます。
負荷の高い NameNode は、1秒あたり数万件の操作を処理できます。このような負荷を誘発するには、Dynamometer は多数のクライアントがリクエストを送信する必要があります。各リクエストが元の送信と同じ効果とパフォーマンス上の意味を持つようにするために、Dynamometer は、関連するリクエスト（たとえば、ディレクトリ作成とそのディレクトリのリスト）を、元の順序を維持する方法で行うことを試みます。監査ログファイルがソース IP アドレスでパーティション分割されることが推奨されるのはこのためであり、同じホストから発信されたリクエストは、異なるホストから発信されたリクエストよりも密接な因果関係を持っているという仮定を使用します。単純化のために、ストレステストジョブはマップのみの MapReduce ジョブとして記述されており、各マッパーはパーティション分割された監査ログファイルを消費し、その中に含まれるコマンドをシミュレートされた NameNode に対して再生します。実行中、さまざまなタイプのリクエストのレイテンシなど、再生に関する統計が収集されます。
Dynamometer の詳細については、最初のリリースを発表するブログ投稿またはこのプレゼンテーションをご覧ください。