[Linux] Tracing NFS: Beyond tcpdump

原文はこちら。
https://blogs.oracle.com/linuxkernel/tracing-nfs%3a-beyond-tcpdump

---

このブログエントリはLinuxカーネル開発者のChuck Leverによるものです。歴史的に、tcpdumpとrpcdebugはNFSクライアントのトラブルシューティングで使われてきましたが、さすがに古くなってきました。Oracleでは、既存のツールをチェックし、タイミングに影響を与えたり、キャプチャ情報の損失を招くことなく、高負荷のワークロードや高性能ネットワーク・ファブリック上でNFSクライアントの動作を監視できる新しいツールを提供したいと考えています。

Historical NFS and RPC Debugging Facilities

ネットワークトラフィックが暗号化されていない限り、NFSの操作はNFSクライアントとNFSサーバーの間でネットワークをスヌーピングするすべての人から見えてしまいます。NFSの操作は、tcpdump、wireshark、またはsnoopなどを使い、クライアントまたはサーバーのいずれかで利用できるスヌーピングツールで取得できます。これらのツールには、ネットワークキャプチャやpcapファイルに含まれるNFSの操作を解析し、後で解析するためにファイルに保存したり、人間が読める解析形式で表示する機能があります。

これはNFS開発者が使用できる最も貴重なツールの1つですが、いくつかの欠点があります。

• 最も有用なデータをキャプチャするためには、問題が発生したときに、ツールが実行されている必要があります。問題が発生した後にキャプチャされたデータは、一般に役に立ちません。
• キャプチャツールは膨大な量のデータを非常に迅速に生成できます。パケット・フィルタリングとパケット・キャプチャを旨く使ってファイルに束ねることで、解析対象のデータを軽減できます。
• データレートが高いため、このツールではキャプチャ実行中のシステムに大きなオーバーヘッドが発生する可能性がありますが、問題の再現を避けるため、タイミングを変更できます。そうしない場合、システムが追いつくのに十分なパフォーマンスがないために、重要なパケットがキャプチャされない可能性があります。
• ユーザーデータもこのツールでキャプチャされるため、結果として得られるキャプチャファイルのサイズが大きくなり、機密データの保存にNFSを使用している場合にはプライバシーの問題が発生します。

正確なキャプチャ構成の権利を取得し、適切な環境で根本的な問題をきれいにキャプチャできるようになるまで、キャプチャを繰り返し実行する必要があります。

Linuxには、NFSクライアントとRPCクライアントとサーバースタックに組み込まれた内部トレースメカニズムがあります。これは "rpcdebug"ファシリティとして知られています。これを有効にすると、NFS READの送信やRPCの各実行ステップなどの特定のイベントに対するメッセージをカーネルログ（通常は/var/log/messages）に追加します。

このメカニズムは、ネットワークキャプチャと同様の欠点を抱えています。より批判的に言えば、ユーザファイルではなくカーネルログやシステムコンソールに書き込むため、以下のような重大な欠点があります。

• システムコンソールは、実際のシリアルポートであることことが多々あるため、デバッグメッセージの生成速度が制限され、NFS操作が遅くます。大量のNFSワークロードを実行している本番システムでrpcdebugを使用することは適切ではありません。
• 最近のLinuxディストリビューションでは、カーネルログにレート制限が組み込まれているため、短期間に数百のデバッグメッセージが表示された後、レートリミッタによって新しいメッセージが送信されます。問題の再現時には、問題が再現される前にレート制限が頻繁に発生します。

さらに、デバッグレベルの細かさももちろん関係します。たとえば、各NFS GETATTR操作を確認するには、すべてのNFS操作でデバッグメッセージを有効にする必要があり、結果として大量のデータが生成されます。

Introducing static trace points

大規模なワークロードや、NFSの同時ユーザーが多いシステム、またはますます高速なネットワークでNFSを頻繁に使用する場合、従来のデバッグ・メカニズムはもはや実行可能ではなく、代わりに、低いオーバヘッドと柔軟なイベント・フィルタリングを持つメカニズムが必要です。Linux NFSコミュニティは、この目的のために静的トレースポイントを採用しています。

これらのトレースポイントは、開発者がソースコードの固定部分に追加した、重要な情報（RPC XID、ユーザーID、I/Oのサイズ、エラーコードなど）を取得できるポイントです。トレースポイントは常に使用可能であり、有効にしてもオーバーヘッドは低いままです。さらに、必要に応じて個々のトレースポイントのオン/オフを切り替えることができます。トレース・データはユーザー・ファイルに送られ、コンパクトな形式で保管されます。ユーザーデータはトレースポイントで公開されないので、キャプチャデータのサイズはずっと小さくなります。

LinuxカーネルのNFSクライアントには、すでに複数のNFSトレースポイントがあり、NFSクライアントおよびRPC層の操作のさまざまな運用時の情報を取得します。しかし、Oracleは最近、特にNFS I/O操作をキャプチャする一連のトレース・ポイントを提供しました。新しいトレースポイントは、v4.14 LinuxカーネルのNFSクライアントで初めて登場しました。

これには、すべてのNFS READ、WRITE、COMMIT操作の開始と操作の引数（データペイロードを除く）、終了、そしてそれぞれの操作で発生したエラーが含まれます。これらの6つのトレースポイントのそれぞれを個別に有効にすることも、一度に有効にすることもできます。生成される各イベントには、タイムスタンプ情報と、操作を要求したCPUコアおよびプロセスに関する情報が含まれます。

これらのトレースポイントを以下のような洗練された方法で使用できます。

• 一連の個々のNFS READ操作を記録し、記録されたタイムスタンプを使用して外れ値分析を生成する
• 本番ワークロードで、特定のエラー状態のNFS WRITE結果を監視する
• 負荷の大きいワークロードでも、サーバーの再起動時にNFS COMMITが正しく動作することを確認する
• NFSv4の状態回復がNFS I / O操作に与える影響を調べる

NFSトレースポイントは、カーネルの他の静的トレースポイントと同様に、trace-cmdツールを使用して制御します。以下のコマンド

trace-cmd list | grep nfs:

を使用して、カーネルNFSクライアントに関連するトレースポイントを検出します。v4.14のNFSクライアントに導入されたトレースポイントには以下のものが含まれます。

• nfs:nfs_initiate_read
• nfs:nfs_readpage_done
• nfs:nfs_initiate_write
• nfs:nfs_writeback_done
• nfs:nfs_initiate_commit
• nfs:nfs_commit_done

Oracleは、NFS導入を担当するシステム管理者にとって、優れたトラブルシューティングおよび監視ツールがどれほど重要であるかを認識しています。私たちは、通常の操作を妨げずに深い可視性を提供するLinuxに機能を引き続き提供することを意図しています。