概論

いきなりだが、図1を見てほしい。 これは Application が nfs を使った場合の情報の流れの 全体図である。

図1. nfs request flow
nfs 全体図

Client 側で動いている Application がファイルへアクセスしようとすると、 そのリクエストは Client の OS が管理している Virtual File System 層へ まず送られる。 VFS 層はそのリクエストが File Cache で解決できないか調べる。 Cache に必要なデータがあれば、 そこで reply が生成される。 reply は経路を逆流して Application に戻される。

File Cache で問題が解決しない場合、 VFS は nfs の client プログラムにリクエストを渡す。 client はそれらを nfs のリクエストに分解する。 リクエストは TCP,UDP などを経由して通信層へ到達し、 ネットワークを経由してサーバー側に到着する。 サーバー上の TCP,UDP まで到着したリクエストは nfs の Server プログラムにリクエストを投げる。 nfs Server はリクエストを解釈し、 Server 側の VFS へと必要なリクエストを投げる。 VFS 層は Server 側の File Cache を調べる。 Cache に必要なデータがあれば、 そこで reply が生成される。 reply は経路を逆流して Application に戻される。

Server 側の File Cache で問題が解決しない場合、 リクエストはさらに Local File System へと転送され、 最終的に Storage へのアクセスが行われ、 reply が生成される。 reply は経路を逆流して Application に戻される。

この図には Authentication などの通信経路は含まれていないが、 それらも基本的にはこの図と同じ構造になる事は 理解していただけると思う。

この図だけからでも、 nfs のパフォーマンスを向上させるヒントはいくつか得られる。

Application からのリクエストに対する reply を生成する 個所は全部で 3個所ある。 これらの個所は直列に並んでいるので、 より Application に近い所で reply が生成できれば 当然全体の throughput 平均値は向上する。 最後の Storage 部分以外の2個所は File Cache なので、 File Cache のヒット率を向上させることが throughput を向上させることに直結することがわかる。 また、より client 側に近いポイントでの reply 生成は、 Application が request を出してから reply を受け取るまでの時間、 latency も短縮する。

Application ならびに各「reply 生成ポイント」間の 3つのパスの latency ならびに throughput を向上させることができれば、 全体の latency は短くなり、throughput は向上する。 ただし、各 File Cache のヒット率に依存して どのポイントまでをチューンするべきなのか、 は変わる。
極端な話、Client 側の File Cache のヒット率が 90% の場合、 Application から Client File Cache までの latency を 1msec 短くする事と、 Client File Cache から Server File Cache までの latency を 9msec 短くする事は、 平均 latency の観点から見ると等価になるのだ。 この場合、より効果を得やすい点をチューンする方が効率的だ。

しかし残念ながら、逆に言えばこのような概念的な事しかわからない。 各 File Cache ポイントでのキャッシュヒット率は、 使っている nfs のプロトコルの種類、 与えられたメモリリソースとそれを管理する OS の賢さに依存する。 プロトコルによってはキャッシュを作ることがままならない可能性さえある。 各 reply 発生ポイント間の通信速度は、 各種ハードウェア、OS、ソフトウェアの相互関連で決定し、 決して単純には決まらない。 何よりも Server 側の Storage の性能自体、 同じハードウェアを使っていても Local File System の性能で 大きく変化し、一意には定まらない。 そしてこれら全体は、 Client 側がどのようなパターンでアクセスをしてくるのか、 に強い影響を受けるだろう。

そこでまず、 本ドキュメントではなるべく汎用的な知識の提供に話を集中する。 個別のファイルシステム、OSなどに言及する場合は、 それが汎用的な知識の具体例として理解しやすい場合にとどめる。

その上で、話を3つのパーツに分ける。 第2章では Application から Client File Cache までについて、 第3章では Client File Cache から Server File Cache までについて、 第4章では Server File Cache から Storage までについて、 注目する。 各パーツは途中で引き換えすべきポイントの存在しない、 「往復」パスなので、 チューニングはこの単位で考えていくのが適切だろう。