An Updated Overview of NFSv4 NFSv4 の概要 更新版 NFSv4.0, NFSv4.1, pNFS, NFSv4.2 の機能 October 2015 An Updated Overview of NFSv4 目次 はじめに ............................................................................................................................... 4 NFSv4 の背景 ................................................................................................................... 4 NFSv4 の採用 ................................................................................................................... 5 NFSv3 にまつわる問題とは何か .......................................................................................... 6 NFSv4.1 と NFSv4.2 の利点 ................................................................................................ 6 疑似ファイルシステム ...................................................................................................... 7 TCP による送受信 ............................................................................................................ 8 ネットワークポート .......................................................................................................... 8 マウントとオートマウンター............................................................................................ 9 UTF-8 による国際化サポート........................................................................................... 9 複合 RPC .......................................................................................................................... 9 委譲 ................................................................................................................................. 10 移行、複製、および照会 ................................................................................................. 10 セッション ...................................................................................................................... 10 Parallel NFS（pNFS）とレイアウト ............................................................................ 10 トランキング................................................................................................................... 12 セキュリティ................................................................................................................... 12 アプリケーションデータホール ...................................................................................... 13 I/O アドバイス ................................................................................................................ 13 サーバサイドコピー ........................................................................................................ 13 保証された領域予約とホールパンチング ........................................................................ 14 サーバとクライアントの入手 ............................................................................................. 15 まとめ ................................................................................................................................. 15 図 図 1：NFS バージョン間の関係性 ............................................................................... 5 図 2：疑似ファイルシステム ........................................................................................ 7 図 3：pNFS のデータフローのコンセプト................................................................. 11 図 4：pNFSv4.1 における pNFS レイアウトの関係性 .............................................. 12 図 5：サーバサイドコピー ......................................................................................... 14 図 6：領域予約とホールパンチング ........................................................................... 15 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 2 An Updated Overview of NFSv4 表 表 1：SPECsfs2008 における NFSv3 オペレーションの比率 ...................................... 9 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 3 An Updated Overview of NFSv4 はじめに このホワイトペーパーの初版は、2012 年 6 月に”An Overview of NFSv4（邦題：NFSv4 の概要）”として 出版されている。このホワイトペーパーまでの間に、IETF NFS Workgroup は、新たな特徴や機能に取り 組み続けており、NFSv4.2 は最終承認の段階に近づいてきている。この更新版のホワイトペーパーには、 2012 年 6 月に出版した原文の内容の更新や、新しい内容を加えている。 この 2、3 年の間、NFSv4 は、多くのユーザにとって選択肢となる Network File System（NFS）のバー ジョンとなり、多くのユーザが NFSv3 から NFSv4 への移行を行っている。これは様々な理由からによる ものであり、NFSv3 との単純な対比によるものだけではない。また、最近になって、我々は、標準的な Linux クライアントだけでなく、VMware による仮想マシンのデータストア用として VSphere でサポートされて いる、NFSv4 サーバ向けの新たなクライアントを利用することもできるようになった。10 年にも上る NFSv4 の経験によって、皆がこの技術の安定性、信頼性を認め、そして問題なく動作すると感じるように なるであろう。 このホワイトペーパーでは、NFSv4 が従来の NFSv3 と比べて、さまざまなデータセンタや HPC におけ る使用にいかに適しているかを説明するとともに、v3 から v4 に移行した場合の利点を紹介する。また、 最も重要な論点は、新規プロジェクトを立ち上げる際には、少なくとも NFSv4 に対する評価と運用を行い、 理想的には既存の環境内で大規模に使用すべきだということである。 NFSv4 の背景 NFSv2（1984 年）および広く使われている後継版の NFSv3（1995 年。RFC-18131で規定されているが、 インターネット標準にはなっていない）は、1995 年に Sun によって初めて発表された。NFSv3 は 20 年間 使用され続けており、使いやすい堅牢なプロトコルとして実績がある。また、幅広く採用されたことで、 DFS や AFS などの競合するいくつかの UNIX ベースのファイルシステムプロトコルを短期間で圧倒した。 NFSv3 は、Sun の Solaris よりも多くのストレージベンダと OS メーカで採用され、IBM の AIX、HP の HP-UX、Linux、および FreeBSD を含むさまざまなシステム上で使用することができた。さらに、MacOS、 OpenVMS、Microsoft Windows、Novell NetWare、および IBM の AS/400 システムなどの非 UNIX システ ムでも NFSv3 が採用された。相互運用性と標準化の利点を認識した Sun は、将来の NFS 標準化作業を自 社の管理下に置くことをあきらめ、NFSv4 に至る作業は、Sun とインターネット協会（ISOC）の間で合 意されたように、Internet Engeneering Task Force（IETF）主導で実施されている。 2003 年 4 月、RFC-3530 で規定された Network File System（NFS）バージョン 4 プロトコル2がインタ ーネット標準として承認され、NFSv3 の後継となった。これが IETF から発行された最初のオープンファ イルシステムおよびネットワーキングプロトコルである。NFSv4 には、NFSv3 に含まれる一部のあまり望 ましくない機能を改善するために状態の概念が導入され、使いやすさ、管理、および性能を向上させるた めのその他の拡張が施されている。 しかし、RFC-3530 の発表後間もなく、Garth Gibson と Peter Corbett によって書かれたインターネット ドラフトで NFSv4 に伴ういくつかの問題が指摘された3。具体的には、NFSv3 と同様に NFSv4 はアクセ ス先をシングルサーバにする必要があるため、帯域幅とスケーラビリティが制限される。こうした制約を 1 NFSv3 仕様：http://tools.ietf.org/html/rfc1813 テキスト内で言及されているその他の IETF RFC は同サイトで入手できる。 2 非公式な会議では、NFSv4 の仕様は NFSv4.0 と呼ばれる。このホワイトペーパーでは、NFSv4 は、NFSv4.0 から NFSv4.2 までの マイナーバージョンすべてを総称するものとする。 3 The “pNFS Problem Statement”：http://tools.ietf.org/html/draft-gibson-pnfs-problem-statement-01 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 4 An Updated Overview of NFSv4 なくすために NFSv4.1（RFC-56614で規定、2010 年 1 月に承認）が開発され、これらの問題に対応するた めに parallel NFS（pNFS）などの新しい機能が標準化された。 さらに、RFC-3530 に規定されているオリジナルの NFSv4 の仕様による実経験を踏まえて、多くの問題 の解明と修正につなげ、それらをまとめた新しい仕様として、2015 年 3 月に RFC-75305が発行された。 6 現在、NFSv4.2 は承認に向けて動き始めている 。改訂のたびに開発と承認に膨大な時間がかかっていた 初期の IETF NFSv4 開発作業を変更するに当たって、開発に何年もかかる RFC-5661 のような大規模標準 化文書をなくし、毎年の作業プロセスを通じて標準への追加ができるようにワークグループ設立趣意書が 修正された。これらの標準化に至るプロセスの変更によって、今では、NFSv4.2 で承認される予定（2015 年）の機能が多くのベンダとサプライヤから入手できる。これらの関係を図 1 に示す。 FedFS（Federated File System）7は、現時点で未承認の標準化案であるが、NFSv4 クライアントを変更 せずにアクセスできる拡張可能な統合ファイルシステム名前空間の構築を可能にする一連のオープンなプ ロトコルを提供する。標準化作業は進行中であるが、やはり、FedFS で予定されている機能の一部がすで に入手できる。 図 1：NFS バージョン間の関係性 NFSv4 の採用 NFS に対して数々の改良や改善がなされたにもかかわらず、多数のユーザが NFSv3 を使用し続けてい る。2012 年 7 月においては、以下の声明は正しかった。 「NFSv4 は、従来の NFSv3 や NFSv2 よりもそれ自体に多くの利点がある成熟して安定したプロトコル であるが、普及は進んでいない。」 これは、もはや真実ではない。業界では、普及のペースが上がってきている。NFSv3 への批判は、2012 年よりも、今や、より妥当なものなってきている。NFSv3 は使い慣れた、よく理解されているプロトコル であり、用途によってはこれで十分であるが、データ量と計算量が飛躍的に増加してストレージに対する 要求が高まる中で、NFSv3 の導入と管理は困難の度合いを増してきている。 4 RFC-5661 Network File System (NFS) Version 4 Minor Version 1 Protocol is at https://tools.ietf.org/html/rfc5661 5 RFC-7530 Network File System (NFS) Version 4 Protocol is at https://tools.ietf.org/html/rfc7530 6 NFSv4.2 proposed specification: http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-38.txt ; the draft as of April 2015 7 An overview of FedFS: http://people.redhat.com/steved/Bakeathon-2010/fedfs_fast10_bof.pdf 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 5 An Updated Overview of NFSv4 NFSv3 にまつわる問題とは何か 本質的に、NFSv3はステートレス性に関連した問題を抱えている。ステートレス性（サーバの状態をト ランザクションと関連付けないこと）は、クライアント・サーバ間のトランザクションが別のトランザク ションに依存していなければ、アプリケーションの開発がかなり容易になるというメリットがあるため、 HTTPや他のRESTful API8でも採用されている。これに対し、NFSの場合はステートレス性が性能とロック 管理の問題を引き起こしてしまうというデメリットが存在する。 NFSv4.1とparallel NFS（pNFS）は、高帯域幅アクセスを獲得するために使用されるよく知られたNFSv3 の「対策」をすでに含んでいる。NFSv3オートマウンターマップを採用（多くの場合、非常に面倒な作業） し、それらを負荷分散の管理用に変更して使用しているユーザは、はるかに管理が容易なpNFSで同等の性 能が得られることに気付くはずである。 NFSv3では、WAN全体にNFSの使用を拡張するのは困難である。ファイアウォールの多くは既知のポー ト番号に基づいてトラフィックをフィルタリングするが、NFSv3クライアントがファイアウォールで保護 されたネットワークの内部に配置され、サーバがそのネットワークの外部に配置 されている場合は、ファ イアウォールでportmapper、mountd、およびnfsdの各サーバが要求を待ち受けているポートを認識する必 要がある。この一貫性のないポートの使用、「不確定要素」の多さ、およびファイアウォールにランダム に穴を開けなければならないというネットワーク管理者の立場としては当然の懸念があるため、NFSv3を WAN環境で使用するのは現実的ではない。対照的に、NFSv4はこれらの機能の多くを内蔵し、すべてのト ラフィック（現在はTCPのみ）が既知のポート2049のみを使用するように義務付けている。 最も厄介なNFSv3の「機能」の1つがロックの処理である。NFSv3はステートレスであるが、クライアン トの競合によるファイル破損を避けるために不可欠なロック管理（NLM）を追加すると、NFSv3アプリケ ーションのリカバリが大幅に遅くなる。古くなったロックを手動で解除する必要が頻繁にあり、ロック管 理はプロトコルの外で処理される。NFSv4に組み込まれたロック解除、ロックタイムアウト、およびリカ バリ時のクライアント／サーバネゴシエーションにより、管理が大幅に簡略化される。 NFSv3からの移行時には、これらのロック機能と委譲機能によってNFSv4がステートフルになる。しか し、クライアントやサーバの故障や、ネットワーク分割時の明確なリカバリセマンティクスにより、本来 の設計の単純さは維持される。これらは、近代的なデータセンタにおいてストレージを提供するプロトコ ルとして、またHPCやデータベース、高度に仮想化されたアプリケーションが使用するストレージとして、 NFSv4.1が望ましいとするメリットの一部にすぎない。 NFSv4.2の標準化は続いている。NFSv4.2のデザインの主要なゴールは、一般的なローカルファイルシ ステムの機能を持ち、それらをリモートで提供することであった。領域の予約、ホールパンチング、I/Oア ドバイスのような機能である。NFSv4.2は、NFSv3では成し遂げることができなかった価値ある機能を提 供するために、プロトコルが拡張されている。 NFSv4.1 と NFSv4.2 の利点 以下の章では、IETF標準の順に沿い、NFSv4.0、それに続くNFSv4.1、NFSv4.2の特徴について説明す る。クライアントやサーバはこれらのすべての機能を実装している必要はないことを覚えておいてほしい。 ただし、いくつかの機能（たとえば、TCPによる送受信やKerberosセキュリティ）はで必須であり、多く の機能（たとえば、pNFSやホールパンチング）はオプションである。 8 HTTP and RESTful APIs explained in overview: https://en.wikipedia.org/wiki/Representational_state_transfer 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 6 An Updated Overview of NFSv4 疑似ファイルシステム 図 2：疑似ファイルシステム ほとんどのオペレーティングシステムの場合、名前空間に一連の使用可能なファイル名が階層的に並べ られて記述されている。システムがファイルを共有するためのサーバとして機能している場合は、ローカ ル管理ディレクトリと一時ディレクトリを除く、名前空間の一部しかエクスポート（または「共有」）さ れないのが普通である。以下のディレクトリをエクスポートするファイルサーバを考える。 /vol/vol0 /vol/vol1 /backup/archive 図2に示すように、サーバはクライアントにエクスポートされたファイルシステムの単一ビューを提供す る。 NFSv4では、サーバの共有名前空間が単一階層になっている。図2に示す例では、エクスポートリストと サーバ階層が分離され、関連付けられていない。サーバは、その名前空間の分離部分のエクスポートを選 択するときに、エクスポートされない名前空間の部分をブリッジしてクライアントが唯一の共通ルートか らエクスポートポイントに到達できるようにするための疑似ファイルシステム（グレーで示されたエリア） を作成する。疑似ファイルシステムは、ディレクトリのみを含む構造で、サーバによって作成され、エク スポートされたファイルシステムの階層をクライアントから参照できるようにする一意のファイルシステ ムID（fsid）を持っている。 サーバによって提供される疑似ファイルシステムの柔軟性は、クライアントに見せる名前空間の部分を 制限するために使用でき、大きなメリットとして利用可能な強力な機能である。たとえば、NFSv3とNFSv4 の名前空間の違いを対比するために、図2のルートファイルシステム / のマウントについて考える。NFSv3 上での / のマウントでは、/ と /vol/vol2 のfsidが同じであるため、クライアントで /vol/vol2 の内容を列 挙できる。NFSv4上での / のNFSv4マウントでは疑似fsidが生成される。 /vol/vol2 はエクスポートされな いうえ、疑似ファイルシステムに保存されないため、確認できなくなる。vol/vol2 の明示的なマウントが 必要になる。 また、疑似ファイルシステムの柔軟性によって、サーバのディレクトリ階層とレイアウトをあまり意識 せずに、NFSv3ディレクトリ構造をNFSv4へ容易に移行できる。ただし、ファイルシステム構造を横断す るアプリケーションや、ファイルシステム全体が見えることを前提としているアプリケーションが存在す る場合は、NFSv4に移行する前、特に、/ のNFSv3マウントをNFSv4に変換するときに、疑似ファイルシ ステムに与える影響を慎重に分析する必要がある。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 7 An Updated Overview of NFSv4 TCP による送受信 NFSv3はTCPとUDPの両方をサポートしているが、UDPはTCPよりも軽量で高速であるとされているた め、それをサポートするアプリケーションに使用されている。UDPの欠点は信頼性の低いプロトコルだと いうことである。データグラムが指定された順序で宛先ホストに配信される保証はなく、そもそも配信さ れるかどうかさえ保証されていないため、アプリケーションは、消失した データ、重複したデータ、また は間違った順序のデータを処理するように特別に設計する必要がある。UDPは善良なネットワーク市民で もない。輻輳制御やフロー制御といった概念がないばかりか、サービス品質（QoS）基準を適用する能力 もない。 NFSv4.0仕様では、使用されるすべての転送で輻輳制御を提供する必要がある。これを実現する最も簡 単な方法はTCPの使用である。TCPを使用することにより、NFSv4クライアントとサーバがインターネッ ト上で頻繁に見られる信頼性の急激な低下に対応できる。再送はアプリケーション層ではなく、トランス ポート層で管理されるため、アプリケーションと共有ネットワーク上でのそれらの管理が大幅に簡素化さ れる。 NFSv4.0にはTCPによる再送に関する厳密なルールも導入されているが、NFSv3の場合はTCP経由の再 送に関するルールが完全に欠如している。そのため、NFSv3クライアントのタイムアウトが短すぎると、 NFSv3サーバで要求がドロップされることがある。NFSv4.0はコネクション指向の送受信に組み込まれた タイマーに依存している。 ネットワークポート NFSサーバにアクセスするために、NFSv3クライアントはサーバのportmapperに問い合わせて サーバの mountdのポートを見つける必要がある。その後、mountdに問い合わせて初期ファイルハンドルを取得し、 再度ポートマッパーに問い合わせて、サーバのnfsdのポートを取得する。これにより、クライアントがNFS サーバにアクセスできる。 この方法では、ファイアウォール経由でNFSを使用している場合に問題が発生する。これは、通常、フ ァイアウォールが既知のポート番号に基づいてトラフィックをフィルタリングするためである。クライア ントがファイアウォールで保護されたネットワークの内側に配置され、サーバがネットワークの外側に配 置されている場合は、ファイアウォールがportmapper、mountd、およびnfsdがリッスンしているポートを 認識する必要がある。mountdはどのポート上 でもリッスンできるため、ファイアウォールにどのポート を許可するかを通知するのは実用的ではない。大抵の場合、nfsdは2049番ポートでリッスンするが、そう でない場合もある。portmapperは常に同じポート（111）上でリッスンするが、ファイアウォール管理者 が慎重なあまり、ファイアウォールで保護されたネットワークの内側からネットワークの外側にあるサー バへの111番ポートへの要求をブロックしていることが多い。結果的に、NFSv3はファイアウォールを通し た使用に向いていない。 NFSv4では、サーバに2049番ポートのリッスンを強制することにより、単一のポート番号が使用される。 マウント用プロトコルとロック用プロトコルがNFSv4プロトコルに組み込まれたため、statd、lockd、 mountdなどの「補助的な」プロトコルが不要になった。これは、NFSv4クライアントがportmapperへの問 い合わせも、フローティングポート上のサービスへのアクセスも必要としないことを意味する。 NFSv4では明確に定義されたTCPポートを介した単一のTCP接続が使用されるため、ファイアウォール とネットワークアドレス変換（NAT）デバイスを簡単に通過させることで、ファイアウォール構成をHTTP 用の構成と同等に単純化できる。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 8 An Updated Overview of NFSv4 マウントとオートマウンター UNIXとLinuxのさまざまなフレーバー上のオートマウンターデーモンとユーティリティは、さまざまな NFSバージョンを識別できる。ただし、オートマウンターを使用するには、サーバとクライアント間のフ ァイアウォールの通過を少なくともポート111に許可する必要がある。これは、オートマウンターがポート マッパーを使用するためである。従来のNFSv3環境を越えてNFSv4の使用を拡張している場合はこの方法 が望ましくないため、代わりに、広く利用されている「ミラーマウント」機能を使用できる。この機能は、 ディレクトリのfsidがその親のfsidと異なっていることを検出した場合はいつでも新しいマウントポイント を作成してNFSv4クライアントの動作を拡張し、NFSv4 サーバでファイルシステムが検出されると自動的 にそれらをマウントする9。 この拡張では、オートマウンターを使用する必要がないため、オートマウンターマップの内容または伝 播、mountdなどのNFSv3サービスの可用性、またはNFSv4に必須の単一ポート2049の向こう側で開いてい るファイアウォールポートに依存しない。 UTF-8 による国際化サポート ASCII文字セットでは、より多くの文字を含むアルファベットを使用する言語や多数の非Romanグリフ を使用する言語に必要な記述性を提供できないという認識から、NFSv4では、ファイル名、ディレクトリ、 シンボリックリンク、ユーザ識別子、およびグループ識別子にUTF-8が使用されている。UTF-8は、7ビッ トでエンコードされたASCIIと下位互換性があるため、7ビットASCIIからなる名前は引き続き機能する。 複合 RPC WAN上の遅延は長年の問題であり、多くの場合、その遅延は、10分の1秒単位あるいは秒単位の長さと なっている。NFSでは、サーバとのすべての通信にRPCが使用されるが、ペイロードの多くが少量であり、 大抵のメタデータ操作は同期化およびシリアル化される。ファイル検索（LOOKUP）や属性の取得 （GETATTR）などの操作が、平均ワークロード数で最大の割合を占めている（表1参照）。 表 1：SPECsfs2008 における NFSv3 オペレーションの比率10 NFSv4より以前のバージョンでは、代表的なNFSのRPCコール群であっても、各RPCコールを別々のト ランザクションとして転送する必要がある。NFSv4では、単一のRPC要求のコストとそれに伴う遅延問題 が回避され、このようなコールを1つにまとめて、複合RPCコールで処理できる。たとえば、lookup、open、 read、およびcloseを一度に送信したり、サーバで複合RPCコール全体を単一要素として実行したりできる。 9 Linux のミラーマウントの機能は、NFSv4 の特徴ではない。NFSv2 や NFSv3 のマウントでも、同様の動作となるよう設定すること が可能である。 10 http://www.spec.org/sfs2008/docs/usersguide.html#_Toc191888936 に NFSv3 からの代表的な RPC コールの混在に 関する記載が ある。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 9 An Updated Overview of NFSv4 これにより、従来、複数回送受信することで発生していた遅延が大幅に短縮されることになる。 委譲 サーバはかつてないほど多量のRAMおよび、フラッシュメモリのような不揮発RAMを搭載するようにな り、とても巨大な16テラバイトキャッシュも珍しくなくなってきている。NFSv3上で動作するアプリケー ションは、特定のアプリケーションサポートがなければ、このようなキャッシュを利用できない。WAN遅 延の増加に加えて、回線上でのIO実行ごとに膨大な遅延が発生する。 NFSv4では、サーバから特定の責任をクライアントに委譲できる。この機能を使用すれば、データにア クセスするためのキャッシングをローカル上で実現できる。いったん委譲されると、クライアントは、他 のクライアントとファイルに対するニーズが競合しないことが保証され、ローカル上でファイルを操作で きる。これにより、アプリケーションは、NFSサーバとの通信を続けなくても、アプリケーションサーバ 上でロック要求、読み取り要求、および書き込み要求を発行できる。デッドロック状態を回避するために、 サーバは、クライアント間のファイルアクセス要求が競合している場合に、一方のクライアントに対する 非同期コールバックを介して委譲をリコールできる。 移行、複製、および照会 データセンタ内や高可用性アプリケーション（データベースや仮想環境など）で本格的に使用するため には、バックアップや災害復旧のためのデータコピー、つまり、VMを自由に配置するためのデータ移行能 力が必須である。NFSv4はデータの透過的な複製と移行の両方に関する機能を備えており、クライアント はアプリケーションからこれらの動作を意識させないことを保証する責任がある。またNFSv4の照会機能 により、サーバがその名前空間から別のサーバにクライアントをリダイレクトできる。これにより、個々 のサーバ上でデータを維持しながら、グローバルな名前空間を構築できる。 セッション NFSv4.1は2つの主要な機能をもたしてくれている。それはセッションとpNFSである。 セッションは、NFSセマンティクスに正確さとシンプルさというメリットをもたらす。NFSv4の正確さ を向上させるために、NFSv4.1のセッションは「1回限りの」セマンティクスが導入された。これは、べき 等性のない操作をサポートするために重要である。たとえば、RENAMEのオペレーションで、操作が2回 以上実行され、異なる結果が返答されるようなケースである。ファイルシステムやストレージを潜在的に 信頼性のない通信上でNFSとともに使う際、そのような操作のべき等を実現しようとすると、実際には大 きな課題がある。 サーバはクライアントと同意して1つ以上のセッション状態を維持する。セッションはクライアントに属 している接続に関連してサーバの状態を維持する。クライアントは、サーバに対する要求が完了したら、 その要求は2度と実行されないことを前提にできる。セッションは、サーバで開始された非同期コールバッ クを導入するというNFSv4委譲のアイデアを拡張したものである。クライアントはサーバに接続するため のセッション要求を開始できる。WANベースのシステムでは、これにより、ファイアウォール経由の操作 が簡略化される。 Parallel NFS（pNFS）とレイアウト Parallel NFS（pNFS）は、NFSの開発における重要な進歩を意味する。2010年1月に承認され、 RFC-5661 に記載されたpNFSは、クラスタ化されたファイルシステムがデータをどのようにストライプ化して管理し 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 10 An Updated Overview of NFSv4 ているかをNFSクライアントが認識していることを前提とする。これはデータの属性ではなく、サーバと クライアント間の調整であるため、非pNFSやその他のファイルアクセスプロトコル経由でもデータにアク セスできる。 図 3：pNFS のデータフローのコンセプト pNFSは、大量の小さなファイルに伴うワークロード、または、非常に大きなファイル、特に、データに 対する同時並列アクセスが必要なコンピュータクラスタ上で動作するファイルに伴うワークロードに対し て有効である。 クライアントは、データレイアウトに関する情報をメタデータサーバ（MDS）に要求して、データ配置 が記載されたレイアウトを受け取る（MDSはサーバとは違うノードとして示されることが多いが、MDSは ストレージシステム内のスタンドアロンノードにしてもしなくてもよく、ストレージベンダのハードウェ アアーキテクチャにも依存する）。データは、複数のデータサーバ上に存在させることができ、複数の経 路を辿ってクライアントから直接アクセスされる。委譲の場合と同様に、クライアントの要求が競合して いる場合は、サーバがレイアウトをリコールできる。 pNFSは、帯域幅の集約を可能にすることによって、2地点間接続に関連した性能問題を軽減する。pNFS を使用すれば、単一ストレージノードがボトルネックにならないことが保証されるため、複数のクライア ントが同時にデータサーバに直接アクセスできる。また、pNFSは、データがクライアントのニーズを満た すようによりよく負荷分散されることも保証する（図3を参照）。 pNFS仕様は、クライアントとデータサーバ間で使用されるプロトコルが定義された複数のレイアウトの サポートにも対応している。現時点で、次の3つのレイアウトが指定されている。NFSv4でサポートされて いるファイル、2004年に承認されたObject-based Storage Device Commands（OSD）標準（INCITS T10） に基づくオブジェクト、およびブロックレイアウト（FCアクセスと iSCSIアクセスのどちらか）。アーキ テクチャ内でレイアウトを選択することによって、性能と機能性の改善が期待できる。たとえば、pNFSオ ブジェクトベースの実装は、クライアント上のソフトウェアでRAIDパリティ計算を実行することによって、 RAID性能をクライアント数に応じてスケールするようにしたり、ネットワーク経由のデータサーバとのエ ンドツーエンドのデータ整合性を保証したりできる。 pNFSのユーザ経験から、pNFSを使用したデータへの高帯域幅アクセスがかなり有効であることが示さ れている。pNFSの性能は、同様のストレージ、ネットワーク、およびサーバで構成されたNFSv3の性能を 明らかに上回っている。NFSv3オートマウンターマップと手作業による負荷分散スキームが排除されてい るため、管理が大幅に簡素化されている。また、インタフェースが標準化されているため、pNFSでは複数 ベンダのNFSサーバ環境のサポートでほとんど問題が発生しない。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 11 An Updated Overview of NFSv4 図 4：pNFSv4.1 における pNFS レイアウトの関係性 トランキング トランキングとは、クライアントとサーバ間でデータ転送速度を増加させるために、複数のコネクショ ンを使う手法のことである。NFSv4.1は、セッションのトランキングとクライアントIDのトランキングの2 種類のトランキングをサポートしている。 セッションのトランキングは、異なる送信先、送信元のネットワークアドレスと同一のセッションとし て連携させる。クライアントIDのトランキングは、同じクライアントIDの複数のセッションを連携させる。 複数のコネクションを連携させる。これらにより、pNFSやNFSv4.1を使う際、ストレージ高度な並列性の 活用や、ネットワーク帯域リソース消費の最適化が実現される。 セキュリティ 大きな混乱が起きている分野であり、多くの人がNFSv4には強力なセキュリティの使用が不可欠だと信 じている。NFSv4仕様には、強力なRPCセキュリティの使用ではなく、サーバとクライアントによる強力 なRPCセキュリティの実装が必須であるとしか記載されていない。これが、既存のKerberosセキュリティ の実装または変更に追加の作業が必要なためNFSv4に移行しないという誤解につながっている可能性があ る。 NFSv4ではWAN経由でより簡単にデータを入手できるようになるため、セキュリティがますます重要に なる。この機能をIETF NFS作業部会が非常に重要視した結果、Kerberos v511を使用したセキュリティ仕様 がNFSv2とNFSv3に組み込まれ、RFC-2623で規定された。 Kerberosで提供されるような強力なセキュリティを使用しなくてもNFSv2、3、または4ファイルシステ ムにアクセスすることはできるが、WAN経由の場合は、あくまでも一時的手段と見なすべきである。こう した考えから、NFSv4はKerberosセキュリティを実装しなくても使用できることは知っておくべきである 12 。ただし、実行できることが必ずしも望ましいこととは限らない。この問題のより詳しい説明といくつか 11 Kerberos Overview－An Authentication Service for Open Network Systems http://www.cisco.com/application/pdf/paws/16087/1.pdf 12 Kerberos を使用しない NFSv4 の例については、 Ubuntu Linux; https://help.ubuntu.com/community/SettingUpNFSHowTo と、SUSE Linux Enterprise; http://www.novell.com/support/kb/doc.php?id=7005060 を参照のこと 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 12 An Updated Overview of NFSv4 の移行に関する考慮事項がSNIAホワイトペーパーの「Migrating from NFSv3 to NFSv4」に記載されている。 UNIX環境での堅牢なKerberosセキュリティの実装時に直面する実用上の問題の多くは、Windows Active Directory（AD）システムを使用することによって解決される。Windowsでは、RFC-2782で規定されてい る標準のKerberosプロトコルが使用される。ADユーザアカウントがUNIXレルム内のアカウントと同様の 方法でKerberosに提供される。これは混合モード環境における非常に魅力的な解決策になる可能性がある 13 アプリケーションデータホール NFSv4.2のアプリケーションデータホールは、たとえば、VMのイメージやデータベース等の、ファイル やファイルの一部のフォーマットを定義する。この機能は、データストアの初期化、例えば、300GBのデ ータベースやVMイメージをサーバ上に作成する際、300GBの巨大なデータを繰り返し送ることなく、クラ イアントからの単一のオペレーションによりこれを実現する。 I/O アドバイス アプリケーションやクライアントは、サーバに対して、予想されるI/Oの挙動を伝えたいものである。ク ライアントは、NFSv4.2の機能を活用することにより、これから起こりうるI/Oの振る舞いを伝えることが できる。例えば、あるファイルはシーケンシャルアクセスされるのか、それともランダムアクセスされる のか、また近い将来アクセスされるのかどうかなどである。この機能により、サーバはあるファイルに対 して将来起こりうるI/O要求に対する最適化を行うことができる。例えば、キャッシュ上へのデータを先読 みや、キャッシュからのデータの除外、また遅い、もしくは速い外部デバイス間でのデータ入れ替えなど である。 サーバサイドコピー NFSv4.2のサーバサイドコピー（Server Side Copy: SSC）ではコピー操作の1つの工程が削除される。 クライアント経由であるサーバからファイル全体またはファイルのディレクトリを読み込んで別のサーバ に書き込む代わりに、SSCでは、クライアントが介在することなく宛先サーバとソースサーバが直接対話、 認証できるようなる。これにより、クライアント帯域幅に対するサーバ上の制限とそれによって引き起こ される輻輳が排除される。 13 Windows Identity Management for UNIX – https://msdn.microsoft.com/en-us/library/cc772571.aspx. “Identity Management for Unix (IDMU )は、非難を受けており、Windows Server 2016 を含む将来バージョンで提供されない。詳しくは、 http://blogs.technet.com/b/activedirectoryua/archive/2015/01/25/identity-management-for-unix-idmu-is-deprecated-in-windowsserve r.aspx.を参照のこと。しかしながら、Windows Server 2012 R2 は、長いサポート期間を残しており、依然として有用な提案となってい る。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 13 An Updated Overview of NFSv4 図 5：サーバサイドコピー 2種類のタイプのコピーが存在する。単一サーバのファイルシステムにおいては、一般的には、クライアン トは、サーバからデータを読み出し、その後そのデータ同じサーバに戻す。CLONE操作は、このオーバー ヘッドの取り除く最適化操作であり、サーバ上で直接データのコピーを行う。また、COPY操作は、サー バ間で直接行われる操作である。異なるセキュリティ領域にある異なるシステム間での操作の場合は、セ キュリティが主要な関心事となる。NFSv4は、新しいセキュリティモデルを規定しており、この規定のア ップデート（RPC_GSS Version 314）は、これらのタイプのコピーを行う際には必須となっている。詳し くは、NFSv4のセキュリティの項で記載した12ページの内容を見ていただきたい。 保証された領域予約とホールパンチング ストレージ需要が増え続ける中、非常に小規模なストレージシステム上でストレージの大規模仮想プー ルを実現するためのさまざまな効率化技術が利用できるようになってきた。シンプロビジョニング（領域 が利用可能で予約されているように見えるが、コミットされていない）が有名であるが、急成長する環境 の管理において問題が発生することがよくある。NFSv4.2の保証された領域予約機能では、シンプロビジ ョニングポリシーに関係なく、個々のファイルに必ず最大限の領域が割り当てられることが保証される。 このような保証はエンドユーザに安心感を与えるが、使用可能なすべてのストレージをフル活用したい ストレージ管理者の助けにはならない。ストレージの効率性を高めるために、NFSv4.2ではスパースファ イル（使用している領域が疎であるファイル）のサポートが導入される。一般に「ホールパンチング（使 用していない領域（ホール）を切り取る）」と呼ばれ、ファイルの削除部分と未使用部分は、ストレージ システムの空き領域プールに戻される（図6を参照）。これらの技術は、VM用のデータストア、たとえば SSDのようなフラッシュベースの高価なストレージデバイス、その他の不揮発性のストレージクラスメモ リのような価値の高い技術を効果的に管理し、実記憶領域をもれなく提供するための鍵となる。 14 The RPCSEC_GSS Version3 のドラフトは、https://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-12 を参照のこと。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 14 An Updated Overview of NFSv4 図 6：領域予約とホールパンチング サーバとクライアントの入手 2012年6月時点では、分かりやすいリストとして、サポートされているOSやNASシステムを並べること は難しかった。それ以降、実装数は劇的に増加している。NFSv4に関する機能は、サーバ、クライアント の両面においてサポートされ、エンドユーザコミュニティにおいても関心事となっている。多くのNFSv4 の機能はオプションであり、必ずしも実装が要求されるものではなく、サポートされている機能がシステ ムによってまちまちであることに注意が必要である。 多くのNASベンダは現時点においてNFSv4をサポートしており、いくつかは、NFSv4.1やpNFSの機能が サポートされたサーバとなっている。NFSv4.2の機能は、まだ標準化されていないが、多くのソリューシ ョンが使える状況にある。NFSサーバベンダのウェブサイトを参照すれば、最新のアップデート情報を入 手することができるだろう。 OSのサーバ、クライアント機能としては、多くのポテンシャルを持ったソリューションが、RedHat、 Novell SUSE、BSDベースの各種ディストリビューション、Oracle Solaris、VMWare VSphere、Microsoft Windowsから提供されている。この分野においては非常に急激な変更が起こっており、NFSv4のサポート レベルに関する情報や、クライアントやサーバが使えるかどうかを知るには、個々のグループや組織のウ ェブサイトを参照するのが良いだろう。 まとめ NFSv4には、グローバルな広域ネットワーク（WAN）でその使用を可能にするための機能が含まれてい る。これらの機能には次のようなメリットがある。 ・ ・ ・ ・ ・ ファイアウォールと相性のよい単一ポート操作 高度かつ、積極的なキャッシュ管理機能 国際化のサポート 複製機能と移行機能 UNIX®とWindows®上で互換性があるアクセス制御機能を使用した、オプションの暗号化品質セキュ 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 15 An Updated Overview of NFSv4 ・ ・ リティ 並列化とデータストライピングのサポート より洗練されたストレージサーバのデータマネージメント手法のクライアントへの提供 NFSv4の目的は、ストレージの見え方ではなく、ストレージへのアクセス方法を定義することである。こ れは必然的な変化である。以前のバージョンのNFSと違って、NFSv4プロトコルには、高帯域幅ネットワ ーク上のデータ共有アプリケーションに合わせてクライアント性能を向上させる、ファイルロッキング、 強力なセキュリティ、操作の一括処理、および委譲の各機能が内蔵されている。 NFSv4.1サーバとクライアントは、性能を向上させるために、データのワイドストライピングなどのこ れまでにない機能を提供する。NFSv4.2以降では、今日のアプリケーション要件を満たすべく標準に対す るさらなる拡張が約束されている。NFSv4.2は、2015年に承認される予定であり、すでにNFSv4.2機能を 提供するサーバとクライアントは提供されている。 従来のバージョンからNFSv4.1やNFSv4.2への移行は、注意深く計画すれば、アプリケーションを変更 したり、さまざまなアプリケーション（ホームディレクトリ、HPCストレージサーバ、バックアップジョ ブなど）のための運用可能なインフラストラクチャをサポートしたりしなくても実現できる。 Ethernet Storage Forumについて Ethernet Storage Forum（ESF）は、ストレージネットワーキング・インダストリ・アソシエーシ ョン （SNIA）内のマーケティング組織であり、イーサネット接続ストレージネットワーキングソ リューショ ンを専門とする。ベンダ中立の教材の作成を通して、ESFのソートリーダーが、世界中で、SNIAと業界の イベントやエンドユーザ支援プログラムを利用して、イーサネット接続ストレージネットワーキング技術 の知名度の向上と普及に努めている。詳細については、以下のURLを 参照されたい。 www.snia.org/forums/esf SNIAについて ストレージネットワーキング・インダストリ・アソシエーション（SNIA）は、非営利のグローバル組織 で、ほぼストレージ業界全体にわたる約400社の会員企業で構成されている。SNIAの使命 は、企業の情報 管理を促進する標準、技術、および教育サービスの開発と普及においてストレージ業界を地球規模でリー ドすることである。この目的を達成するために、SNIAでは、オープンストレージネットワーキングソリュ ーション市場を拡大するための標準、教育、およびサービスの提供に全力で取り組んでいる。その他の情 報については、SNIAのWebサイト（http://www.snia.org）を参照されたい。 本改版の元となる2012年6月に出版されたSNIAホワイトペーパーは、Alex McDonaldによって書かれた 「NFSv4」というタイトルの記事に基づいている。この記事は、「;login: The Magazine of USENIX」、vol. 37、no. 1（Berkeley、CA: USENIX Association、February 2012）の28～35ページに掲載されている。 ことのドキュメントには商標のついた名称が記載されている。しかし、編集方針により、商標のついた名 前へ商標を表すシンボルを毎回使うことはしていないが、商標侵害を意図したものではない。 2015 STORAGE NETWORKING INDUSTRY ASSOCIATION 16
© Copyright 2024 Paperzz
