NFSv3とNFSv4のファイル操作ベンチマーク比較：Validation Case Study

NFSバージョン4には運用上便利な機能が幾つか導入されているが、旧バージョンからの移行にあたって問題視されるパフォーマンスについて、ベンチマークを用いて検証してみた。

» 2008年07月18日 00時00分 公開
[Ben-Martin，Open Tech Press]
SourceForge.JP Magazine

　2003年4月に公開されたNFSバージョン4（NFSv4）には、クライアント／サーバ間のステートフルな（状態遷移型）インタラクションと“ファイルデリゲーション（権限委譲）”が導入された。これにより、クライアントはサーバ上のファイルに対して一時的な排他的アクセスが行える。NFSv4では、RPCSEC_GSS、複数操作のサーバへの一括送信、新たなファイル属性、レプリケーション、クライアント側のキャッシュ処理、ファイルロックの改良といったセキュリティ面での改善が施されている。以前のバージョンから進化した部分は数多くあるが、この記事ではその1つであるパフォーマンスに絞って調査を実施した。

　NFSv4への移行に伴う問題の1つが、エクスポートするすべてのファイルシステムを1つのエクスポート用ディレクトリの下に置かなければならないことだ。つまり、「/etc/exports」ファイルを変更した上、さらにLinuxのバインドマウントを使って、エクスポートしたいファイルシステムを1つのNFSv4エクスポート用ディレクトリの下にマウントする必要がある。NFSv4におけるこのファイルシステムのエクスポート方法ではシステム設定の大幅な変更が必要なため、NFSv3からのアップグレードを行っていない人も多いだろう。こうした管理上の作業については、ほかの記事で取り上げられている。ここでは、NFSv3とNFSv4のベンチマーク評価を実施し、NFSv4への移行によってネットワークファイルシステムのパフォーマンスが向上するのかどうかを確かめる。

　今回のパフォーマンステストには、8Gバイトのメモリを搭載したIntel Core 2 Quad Q6600ベースのサーバ、それにクライアントとしてメモリ2GバイトのAMD Athlon X2マシンを利用した。どちらのマシンもIntel製のギガビットPCIeネットワークカードEXPI9300PTを備え、両マシンをつなぐネットワーク上のほかのトラフィックはベンチマーク実施中、ほとんどゼロだった。以前の記事で紹介したように、このネットワークカードによってネットワークの遅延はかなり抑えられる。今回のテストでは、パフォーマンスの再現性確認のためにそれぞれのベンチマークを何度か実行した。なお、両マシンのメモリ容量の違いから、Bonnie++の実行ではデフォルトの条件を変更して、サーバ側では16Gバイトのファイルを、クライアント側では4Gバイトのファイルをそれぞれ使用した。両マシンともOSは64ビット版のFedora 9である。

　サーバからエクスポートするのは、3基のHDDからなるRAID5上に作成されたext3ファイルシステムで、サイズは60Gバイト。stripe_cache_sizeは16384としたが、これはハードディスク3基のRAIDアレイの場合、RAIDレベルでページのキャッシュに192Mバイトのメモリが使用されることを意味する。また、配信用キャッシュサイズのデフォルト値は同じRAIDアレイで3〜4Mバイトの範囲となる。キャッシュの増加はそのままRAIDの書き込みパフォーマンスの向上につながる。さらに、NFSで実現可能な理論上の最大パフォーマンスを把握するために、各ベンチマークはサーバ上でNFSを使わずにローカルでも実行した。

　前記のRAID5構成は妥当ではないという意見もあるだろう。確かに、こうした動作を行うのにハードディスクが3基だけでは標準的な構成といえない。しかし、今回の狙いはあくまでNFSv3 とNFSv4との相対的なパフォーマンス比較にある。ここでハードディスク3基のRAID5を用いたのは、ベンチマーク向けにファイルシステムの再生成が可能だったからだ。ファイルシステムの再生成により、パフォーマンスに悪影響を及ぼすファイルの断片化といった要因を排除できる。

　まず、NFSv3のテストをasyncオプションありとなしの両方の場合で行った。asyncオプションを有効にすると、NFSサーバはディスクへの書き込みが実際に行われる前に書き込み要求に応答できる。通常、NFSプロトコルでは、ストレージへのデータ書き込みを確認してからでないとサーバはクライアントに応答を返すことができない。ニーズによっては、一部のファイルシステムでパフォーマンス向上のためにasyncオプションを使ったマウントを行っている人もいるだろう。ただし、この非同期オプションがデータの整合性に与える影響、特にNFSサーバがクラッシュした場合には検出不可能なデータ損失が起こりうることを理解しておく必要がある。

　以下の表に、NFSv3とNFSv4でマウントされたさまざまなファイルシステムについてBonnie++ベンチマークによる入出力およびシーク時間、それにサーバ側で実施したベンチマーク結果を示す。予想どおり、読み取りのパフォーマンスはasyncオプションの有無にかかわらずほとんど同じである。asyncオプションを使うと“シーク”回数が5倍以上に跳ね上がっているが、これはおそらく最初のシークが完了しないうちに次のシークが起こるため、サーバによってその一部の実行が回避される場合があるからだろう。

　残念ながら、NFSv4のブロック単位のシーケンシャル出力にはNFSv3からの改善がまったく見られない。asyncオプションを使わない場合の出力は50Mbpsほどで、ローカルファイルシステムの91Mbpsとは大きな差がある。ただし、asyncオプションを使うことで、シーケンシャルブロック出力の数値はNFSマウント上のローカルディスクの場合にずっと近づく。

構成シーケンシャル出力シーケンシャル入力ランダム
キャラクタ単位ブロック書き換えキャラクタ単位ブロックシーク回数
K/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPU/sec% CPU
ローカルファイスシステム623409491939224553319430466910935632239.20
NFSv3 noatime,nfsvers=3501298647700635942852871961075161117044
NFSv3 noatime,nfsvers=3,async592879683729104888012528249510758210914730
NFSv4 noatime498648649548534046852990951080911016494

　以下の表は、Bonnie++ベンチマークによるファイルの作成、参照、削除の実行結果である。ファイルの作成と削除にはasyncオプションがかなり影響していることが分かる。

構成シーケンシャル作成ランダム作成
作成参照削除作成参照削除
/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU
NFSv3 noatime,nfsvers=31860612210182018606604101810
NFSv3 noatime,nfsvers=3,async30311087891130789292111112711330699
NFSv4 noatime98060051319309306520111920
NFSv4 noatime,async131487155135350121298875371250609

　日常使用におけるパフォーマンスをテストするために、Linuxカーネルソースの非圧縮tarball、linux-2.6.25.4.tarの展開と、展開されたソースの削除を行ってみた。非圧縮のtarballを用いたのは、クライアントのCPUに負荷が掛かって展開が遅くならないようにするためである。

構成 展開（分:秒） 削除（分:秒）
ローカルファイスシステム 0:01 0:03
NFSv3 noatime,nfsvers=3 9:44 2:36
NFSv3 noatime,nfsvers=3,async 0:31 0:10
NFSv4 noatime 9:52 2:27
NFSv4 noatime,async 0:40 0:08

まとめ

　以上のテストから、NFSv3からNFSv4に移行してもパフォーマンス面でのメリットはあまりないことが分かる。

　実際のところ、NFSv4はファイル作成ではNFSv3の倍近い時間がかかり、ファイル削除ではNFSv3よりも高速である。圧倒的な速度向上のためにはasyncオプションが有効だが、これを使うとNFSサーバのクラッシュまたはリブート時に問題が生じるおそれがある。

Ben Martinは10年以上もファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティングサービスを手掛けている。


Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ