NFSv4の概要 NFSv4の概要 NFSv4.0、NFSv4.1、pNFS、および提案中のNFSv4.2の機能 June 2012 1 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION An Overview of NFSv4 Table of Contents はじめに・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 3 NFSv4.1の背景 ………………………………………………………………………………… 3 NFSv4の採用 …………………………………………………………………………………… 4 NFSv3に伴う問題とは何か・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 4 NFSv4.1の利点・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 5 疑似ファイルシステム ………………………………………………………………………… 5 転送用のTCP …………………………………………………………………………………… 6 ネットワークポート …………………………………………………………………………… 7 マウントとオートマウンター ………………………………………………………………… 7 国際化サポート、UTF-8 ……………………………………………………………………… 8 複合RPC ………………………………………………………………………………………… 8 委譲 ……………………………………………………………………………………………… 8 移行、複製、および照会 ……………………………………………………………………… 9 セッション ……………………………………………………………………………………… 9 セキュリティ …………………………………………………………………………………… 9 パラレルNFS（pNFS）とレイアウト …………………………………………………………10 提案中のNFSv4.2の機能・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 11 サーバ側コピー …………………………………………………………………………………11 アプリケーションデータブロック（ADB） …………………………………………………12 保証された領域予約とホールパンチング ……………………………………………………12 サーバとクライアントの取得・・・・・・・・・・・・・・・・・・・・・・・・・・・・12 まとめ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・13 図 図1：NFSバージョン間の関係 ……………………………………………………………………… 3 図2：疑似ファイルシステム ……………………………………………………………………… 5 図3：pNFS概念データフロー ……………………………………………………………………10 図4：予約とホールパンチング …………………………………………………………………… 12 表 表1：NFSv3操作に関するSPECsfs2008の割合 …………………………………………………… 8 2 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 はじめに NFSv4は、2003年から標準ファイル共有プロトコルになっているが、あまり広く普及していな い。しかし、NFSv4にはNFSv3に対する数多くの重要な改良が施されている。このホワイトペー パーでは、NFSv4が従来のNFSv3と比べて、さまざまなデータセンタやHPCにおける使用にいか に適しているかを説明するとともに、v3からv4に移行した場合の利点を紹介する。また、最も 重要な論点は、新規プロジェクトを立ち上げる際には、少なくともNFSv4.1に対する評価を行い、 NFSv4.1を利用してファイルシステムを配備する検討を行うべきであり、理想的には既存の環境 内で大規模に使用すべきだということである。 NFSv4.1の背景 NFSv2（1984年）および広く使われている後継版のNFSv3（1995年。RFC-18131で規定されてい るが、インターネット標準にはなっていない）はSunによって初めて発表された。NFSv3は17年 間使用され続けており、使いやすい堅牢なプロトコルとして実績がある。また、幅広く採用され たことで、DFSやAFSなどの初期の競合するいくつかのUNIXベースのファイルシステムプロトコ ルを短い期間で圧倒した。 ᅗ㸸1)6ࣂ࣮ࢪࣙࣥ㛫ࡢ㛵ಀ NFSv3は、SunのSolarisよりも多くのストレ ージベンダとOSメーカで採用され、IBMの AIX、HPのHP-UX、Linux、およびFreeBSD を含むさまざまなシステム上で使用できた。 さらに、Mac OS、OpenVMS、Microsoft Windows、Novell NetWare、およびIBMの AS/400システムなどの非UNIXシステムでも NFSv3が採用された。相互運用性と標準化 の利点を認識したSunは、将来のNFS標準化 作業を自社の管理下に置くことをあきらめ、 NFSv4に至る作業は、Sunとインターネット 協会（ISOC）の間で合意されたように、イ ンターネットエンジニアリングタスクフォ ース（IETF）主導で実施されている。 2003年4月、RFC-3530で規定されたネットワークファイルシステム（NFS）バージョン4プロト コルがインターネット標準として承認され、NFSv3の後継となった。これがIETFから発行された 最初のオープンファイルシステムおよびネットワーキングプロトコルである。NFSv4には、NFS v3に含まれる一部のあまり望ましくない機能を改善するために状態の概念が導入され、使いや すさ、管理、および性能を向上させるためのその他の拡張が施されている。 しかし、その発表後間もなく、Garth GibsonとPeter Corbettによって書かれたインターネットド ラフトでNFSv4に伴ういくつかの問題が指摘された2。具体的には、NFSv3と同様にNFSv4はアク セス先をシングルサーバにする必要があるため、帯域幅とスケーラビリティが制限される。こう した制約をなくすためにNFSv4.1（RFC-5661で規定、2010年1月に承認）が開発され、これらの 問題に対応するためにパラレルNFS（pNFS）などの新しい機能が標準化された。 NFSv3仕様：KWWSWRROVLHWIRUJKWPOUIF テキスト内で言及されているその他のIETF RFCは同サイトで入手できる。 「pNFS Problem Statement」：KWWSWRROVLHWIRUJKWPOGUDIWJLEVRQSQIVSUREOHPVWDWHPHQW 3 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 現在、NFSv4.2は承認待ちの段階にある3。改訂のたびに開発と承認に膨大な時間がかかっていた 初期のIETF NFSv4開発作業を変更するに当たって、開発に何年もかかるRFC-5661のような大規模 標準化文書をなくし、毎年の作業プロセスを通じて標準への追加ができるようにワークグループ 設立趣意書が修正された。これらの標準化に至るプロセスの変更によって、今では、NFSv4.2で 承認される予定（2012年）の機能が多くのベンダとサプライヤから入手できる。これらの関係を 図1に示す。 FedFS4（フェデレーテッドファイルシステム）は、現時点で未承認の標準化案であるが、NFSv4 クライアントを変更せずにアクセスできる拡張可能な統合ファイルシステム名前空間の構築を可 能にする一連のオープンなプロトコルを提供する。標準化作業は進行中であるが、やはり、FedFS で予定されている機能の一部がすでに入手できる。 NFSv4の採用 NFSに対して数々の改良や改善がなされたにもかかわらず、多数のユーザがNFSv3を使用し続けて いる。NFSv4は、従来のNFSv3やNFSv2よりもそれ自体に多くの利点がある成熟して安定したプロ トコルであるが、普及はあまり進んでいない。NFSv3は使い慣れた、よく理解されているプロト コルであり、用途によってはこれで十分であるが、データ量と計算量が飛躍的に増加してストレ ージに対する要求が高まる中で、NFSv3の導入と管理は困難の度合いを増してきている。 NFSv3に伴う問題とは何か 本質的に、NFSv3はステートレス性に関連した問題を抱えている。ステートレス性（サーバの状 態をトランザクションと関連付けないこと）は、クライアント・サーバ間のトランザクションが 別のトランザクションに依存していなければ、アプリケーションの開発がかなり容易になるとい うメリットがあるため、HTTPや他のRESTful APIでも採用されている。これに対し、NFSの場合は ステートレス性が性能とロック管理の問題を引き起こしてしまうというデメリットが存在する。 NFSv4.1とパラレルNFS（pNFS）は、高帯域幅アクセスを獲得するために使用されるよく知られた NFSv3の「対策」をすでに含んでいる。NFSv3オートマウンターマップを採用（多くの場合、非常 に面倒な作業）し、それらを負荷分散の管理用に変更して使用しているユーザは、はるかに管理 が容易なpNFSで同等の性能が得られることに気付くはずである。 NFSv3では、WAN全体にNFSの使用を拡張するのは困難である。ファイアウォールの多くは既知 のポート番号に基づいてトラフィックをフィルタリングするが、NFSv3クライアントがファイア ウォールで保護されたネットワークの内部に配置され、サーバがそのネットワークの外部に配置 されている場合は、ファイアウォールでportmapper、mountd、およびnfsdの各サーバが要求を 待ち受けているポートを認識する必要がある。この一貫性のないポートの使用、「不確定要素」 の多さ、およびファイアウォールにランダムに穴を開けなければならないというネットワーク管 理者の立場としては当然の懸念があるため、NFSv3をWAN環境で使用するのは実際的ではない。 対照的に、NFSv4はこれらの機能の多くを内蔵し、すべてのトラフィック（現在はTCPのみ）が 既知のポート2049のみを使用するように義務付けている。 3 4 提案中のNFSv4.2の仕様：KWWSZZZLHWIRUJLGGUDIWLHWIQIVYPLQRUYHUVLRQW[W（2011年11月時点のドラフト） FedFSの概要：KWWSSHRSOHUHGKDWFRPVWHYHG%DNHDWKRQIHGIVBIDVWBERISGI RI 6725$*(1(7:25.,1*,1'8675<$662&,$7,21 NFSv4の概要 最も厄介なNFSv3の「機能」の1つがロックの処理である。NFSv3はステートレスであるが、クラ イアントの競合によるファイル破損を避けるために不可欠なロック管理（NLM）を追加すると、 NFSv3アプリケーションのリカバリが大幅に遅くなる。古くなったロックを手動で解除する必要 が頻繁にあり、ロック管理はプロトコルの外で処理される。NFSv4に組み込まれたロック解除、 ロックタイムアウト、およびリカバリ時のクライアント／サーバネゴシエーションにより、管理 が大幅に簡略化される。 NFSv3からの移行時には、これらのロック機能と委譲機能によってNFSv4がステートフルになる。 しかし、クライアントやサーバの故障や、ネットワーク分割時の明確なリカバリセマンティクス により、本来の設計の単純さは維持される。これらは、近代的なデータセンタにおいてストレー ジを提供するプロトコルとして、またHPCやデータベース、高度に仮想化されたアプリケーショ ンが使用するストレージとして、NFSv4.1が望ましいとするメリットの一部にすぎない。 NFSv4.1の利点 GibsonとCorbettの論文でNFSv4に伴ういくつかの問題が指摘されたが、NFSv4.1で解決された。 NFSv4.1はエンドユーザが評価と実装の焦点にすべきものである。 NFSv3からNFSv4への移行とは異なり、NFSv4.1はNFSv4.0のマイナーバージョンアップであり、 NFSv4.0の機能に関する説明はそのままNFSv4.1に適用される。 疑似ファイルシステム 図2：疑似ファイルシステム ; ほとんどのオペレーティングシステムの場合、名前空間に一連の使用可能なファイル名が階層的 に並べられて記述されている。システムがファイルを共有するためのサーバとして機能している 場合は、ローカル管理ディレクトリと一時ディレクトリを除く、名前空間の一部しかエクスポー ト（または「共有」）されないのが普通である。以下のディレクトリをエクスポートするファイ ルサーバを考える。 5 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 /vol/vol0 /vol/vol1 /backup/archive 図2に示すように、サーバはクライアントにエクスポートされたファイルシステムの単一ビューを 提供する。 NFSv4では、サーバの共有名前空間が単一階層になっている。図2に示す例では、エクスポートリ ストとサーバ階層が分離され、関連付けられていない。サーバは、その名前空間の分離部分のエ クスポートを選択するときに、エクスポートされない名前空間の部分をブリッジしてクライアン トが唯一の共通ルートからエクスポートポイントに到達できるようにするための疑似ファイルシ ステム（グレーで示されたエリア）を作成する。疑似ファイルシステムは、ディレクトリのみを 含む構造で、サーバによって作成され、エクスポートされたファイルシステムの階層をクライア ントから参照できるようにする一意のファイルシステムID（fsid）を持っている。 サーバによって提供される疑似ファイルシステムの柔軟性は、クライアントに見せる名前空間の 部分を制限するために使用でき、大きなメリットとして利用可能な強力な機能である。たとえば、 NFSv3とNFSv4の名前空間の違いを対比するために、図1のルートファイルシステム/のマウント について考える。NFSv3上での/のマウントでは、/と/vol/vol2のfsidが同じであるため、クライア ントで/vol/vol2の内容を列挙できる。NFSv4上での/のNFSv4マウントでは疑似fsidが生成される。 /vol/vol2はエクスポートされないうえ、疑似ファイルシステムに保存されないため、確認できな くなる。vol/vol2の明示的なマウントが必要になる。 また、疑似ファイルシステムの柔軟性によって、サーバのディレクトリ階層とレイアウトをあま り意識せずに、NFSv3ディレクトリ構造をNFSv4へ容易に移行できる。ただし、ファイルシステム 構造を横断するアプリケーションや、ファイルシステム全体が見えることを前提としているアプ リケーションが存在する場合は、NFSv4に移行する前、特に、/のNFSv3マウントをNFSv4に変換す るときに、疑似ファイルシステムに与える影響を慎重に分析する必要がある。 転送用のTCP NFSv3はTCPとUDPの両方をサポートしているが、UDPはTCPよりも軽量で高速であるとされてい るため、それをサポートするアプリケーションに使用されている。UDPの欠点は信頼性の低いプ ロトコルだということである。データグラムが指定された順序で宛先ホストに配信される保証は なく、そもそも配信されるかどうかさえ保証されていないため、アプリケーションは、消失した データ、重複したデータ、または間違った順序のデータを処理するように特別に設計する必要が ある。UDPは善良なネットワーク市民でもない。輻輳制御やフロー制御といった概念がないばか りか、サービス品質（QoS）基準を適用する能力もない。 NFSv4.0仕様では、使用されるすべての転送で輻輳制御を提供する必要がある。これを実現する 最も簡単な方法はTCPを経由することである。TCPを使用することにより、NFSv4クライアントと NFSv4サーバがインターネット上で頻繁に見られる信頼性の急激な低下に対応できる。再送はア プリケーション層ではなく、トランスポート層で管理されるため、アプリケーションと共有ネッ トワーク上でのそれらの管理が大幅に簡素化される。 NFSv4.0にはTCP経由の再試行に関する厳密なルールも導入されているが、NFSv3の場合はTCP経 由の再試行に関するルールが完全に欠如している。そのため、NFSv3クライアントのタイムアウ トが短すぎると、NFSv3サーバで要求がドロップされることがある。NFSv4.0は接続指向の転送 に組み込まれたタイマーに依存している。 RI 6725$*(1(7:25.,1*,1'8675<$662&,$7,21 NFSv4の概要 ネットワークポート NFSサーバにアクセスするために、NFSv3クライアントはサーバのポートマッパーに問い合わせて mountdサーバのポートを見つける必要がある。その後で、mountサーバに問い合わせて初期ファ イルハンドルを取得し、再度ポートマッパーに問い合わせてNFSサーバのポートを取得する。これ により、クライアントがNFSサーバにアクセスできる。 この方法では、ファイアウォール経由でNFSを使用している場合に問題が発生する。これは、通常、 ファイアウォールが既知のポート番号に基づいてトラフィックをフィルタリングするためである。 クライアントがファイアウォールで保護されたネットワークの内側に配置され、サーバがネットワ ークの外側に配置されている場合は、ファイアウォールがportmapperサーバ、mountdサーバ、 およびnfsdサーバがリッスンしているポートを認識する必要がある。mountサーバはどのポート上 でもリッスンできるため、ファイアウォールにどのポートを許可するかを通知するのは実用的では ない。大抵の場合、NFSサーバはポート2049上でリッスンするが、そうでない場合もある。ポート マッパーは常に同じポート（111）上でリッスンするが、ファイアウォール管理者が、慎重なあま り、ファイアウォールで保護されたネットワークの内側からネットワークの外側にあるサーバへの ポート111への要求をブロックしていることが多い。結果的に、NFSv3はファイアウォールを通し た使用に向いていない。 NFSv4では、サーバにポート2049のリッスンを強制することにより、単一のポート番号が使用さ れる。マウンティングプロトコルとロッキングプロトコルがNFSv4プロトコルに組み込まれたた め、statd、lockd、mountdなどの「補助的な」プロトコルが不要になった。これは、NFSv4クラ イアントがポートマッパーへの問い合わせも、フローティングポート上のサービスへのアクセス も必要としないことを意味する。 NFSv4では明確に定義された宛先TCPポートを介した単一のTCP接続が使用されるため、ファイア ウォールとネットワークアドレス変換（NAT）デバイスを簡単に通過して、ファイアウォール構 成をHTTP用の構成と同じくらい単純にできる。 マウントとオートマウンター UNIXとLinuxのさまざまなフレーバー上のオートマウンターデーモンとユーティリティは、さまざ まなNFSバージョンを識別できる。ただし、オートマウンターを使用するには、サーバとクライア ント間のファイアウォールの通過を少なくともポート111に許可する必要がある。これは、オート マウンターがポートマッパーを使用するためである。従来のNFSv3環境を越えてNFSv4の使用を拡 張している場合はこの方法が望ましくないため、代わりに、広く利用されている「ミラーマウント 」機能を使用できる。この機能は、ディレクトリのfsidがその親のfsidと異なっていることを検出し た場合はいつでも新しいマウントポイントを作成してNFSv4クライアントの動作を拡張し、NFSv4 サーバでファイルシステムが検出されると自動的にそれらをマウントする5。 この拡張では、オートマウンターを使用する必要がないため、オートマウンターマップの内容ま たは伝播、mountdなどのNFSv3サービスの可用性、またはNFSv4に必須の単一ポート2049の向こ う側で開いているファイアウォールポートに依存しない。 5 この拡張では、オートマウンターを使用する必要がないため、オートマウンターマップの内容または伝播、mountd などのNFSv3サービスの可用性、またはNFSv4に必須の単一ポート2049の向こう側で開いているファイアウォール ポートに依存しない。 7 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 国際化サポート、UTF-8 ASCII文字セットでは、より多くの文字を含むアルファベットを使用する言語や多数の非Roman グリフを使用する言語に必要な記述性を提供できないという認識から、NFSv4では、ファイル名、 ディレクトリ、シンボリックリンク、ユーザ識別子、およびグループ識別子にUTF-8が使用され ている。UTF-8は、7ビットでエンコードされたASCIIと下位互換性があるため、7ビットASCIIから なる名前は引き続き機能する。 複合RPC WAN上の遅延は長年の問題であり、多くの場合、10分の1秒単位あるいは秒単位で測定されてい る。NFSでは、サーバとのすべての通信にRPCが使用されるが、ペイロードの多くが少量であり、 大抵のメタデータ操作は同期化およびシリアル化される。ファイル検索（LOOKUP）や属性の取 得（GETATTR）などの操作が、平均ワークロード数で最大の割合を占めている（表1参照）。 NFSv3 ᧯స SPECsfs2008 GETATTR 26% LOOKUP 24% READ 18% ACCESS 11% WRITE 10% SETATTR 4% READDIRPLUS 2% READLINK 1% READDIR 1% CREATE 1% REMOVE 1% FSSTAT 1% 表1：NFSv3操作に関するSPECsfs2008の割合6 NFSv4より以前のバージョンで代表的なRPCコールのNFSセットが混在する場合は、回線上で 各RPCコールを別々のトランザクションにする必要がある。NFSv4では、単一RPC要求のコストと それに伴う遅延問題が回避され、このようなコールをまとめて処理できる。たとえば、lookup、 open、read、およびcloseを一度に回線上に送信したり、サーバで複合コール全体を単一要素と して実行したりできる。これには、複数操作の遅延が大幅に短縮されるという効果がある。 委譲 サーバはかつてないほど多量のRAMおよびフラッシュメモリを採用しており、テラバイト単位の 巨大なキャッシュが珍しくない。NFSv3上で動作するアプリケーションは、特定のアプリケーシ ョンサポートがなければ、このようなキャッシュを利用できない。WAN遅延の増加に加えて、 回線上でのIO実行ごとに膨大な遅延が発生する。 6 KWWSZZZVSHFRUJVIVGRFVXVHUVJXLGHKWPOB7RF にNFSv3からの代表的なRPCコールの混在に 関する記載がある。KWWSZZZVSHFRUJVIVGRFVXVHUVJXLGHKWPOB7RF 8 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 NFSv4では、サーバから特定の責任をクライアントに委譲できる。この機能を使用すれば、デー タにアクセスするためのキャッシングをローカルに実現できる。委譲されたクライアントは、他 のクライアントとファイルに対するニーズが競合しないことを保証され、ローカルにファイルを 操作できる。これにより、アプリケーションは、NFSサーバとの通信を続けなくても、アプリケ ーションサーバ上でロック要求、読み取り要求、および書き込み要求を発行できる。デッドロッ ク状態を回避するために、サーバは、クライアント間のファイルアクセス要求が競合している場 合に、一方のクライアントに対する非同期コールバックを介して委譲をリコールできる。 移行、複製、および照会 データセンタ内や高可用性アプリケーション（データベースや仮想環境など）のサポートで本格 的に使用するためには、バックアップや災害復旧のためのデータコピー、つまり、VMを自由に配 置するためのデータ移行能力が必須である。NFSv4はデータの透過的な複製と移行の両方に関す る機能を備えており、クライアントはアプリケーションからこれらの活動が認識できないことを 保証する責任がある。NFSv4照会では、サーバがその名前空間から別のサーバにクライアントを リダイレクトできる。これにより、個々のサーバ上でデータを維持しながら、グローバルな名前 空間を構築できる。 セッション セッションは、NFSセマンティクスに正確さとシンプルさというメリットをもたらす。NFSv4の 正確さを向上させるために、NFSv4.1セッションで「1回限りの」セマンティクスが導入された。 サーバはクライアントと同意して1つ以上のセッション状態を維持する。セッションはクライア ントに属している接続に関連してサーバの状態を維持する。クライアントは、サーバに対する要 求が完了したら、その要求は2度と実行されないことを前提にできる。セッションは、サーバで 開始された非同期コールバックを導入するというNFSv4委譲のアイデアを拡張したものである。 クライアントはサーバに接続するためのセッション要求を開始できる。WANベースのシステム では、これにより、ファイアウォール経由の操作が簡略化される。 セキュリティ 大きな混乱が起きている分野であり、多くの人がNFSv4には強力なセキュリティの使用が不可欠 だと信じている。NFSv4仕様には、強力なRPCセキュリティの使用ではなく、サーバとクライア ントによる強力なRPCセキュリティの実装が必須であるとしか記載されていない。これが、既存 のKerberosセキュリティの実装または変更に追加の作業が必要なためNFSv4に移行しないという 誤解につながっている可能性がある。 NFSv4ではWAN経由でより簡単にデータを入手できるようになるため、セキュリティがますます 重要になる。この機能をIETF NFS作業部会が非常に重要視した結果、Kerberos v57を使用したセ キュリティ仕様がNFSv2とNFSv3に組み込まれ、RFC-2623で規定された。 7 Kerberos Overview−An Authentication Service for Open Network Systems http://www.cisco.com/application/pdf/paws/16087/1.pdf 9 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 Kerberosで提供されるような強力なセキュリティを使用しなくてもNFSv2、3、または4ファイル システムにアクセスすることはできるが、WAN経由の場合は、あくまでも一時的手段と見なすべ きである。こうした考えから、NFSv4はKerberosセキュリティを実装しなくても使用できること は知っておくべきである8。ただし、実行できることが必ずしも望ましいこととは限らない。この 問題のより詳しい説明といくつかの移行に関する考慮事項がSNIAホワイトペーパーの「NFSv3か らNFSv4への移行」に記載されている。 UNIX環境での堅牢なKerberosセキュリティの実装時に直面する実用上の問題の多くは、Windows Active Directory（AD）システムを使用することによって解決される。Windowsでは、RFC 1510 で規定されている標準のKerberosプロトコルが使用される。ADユーザアカウントがUNIXレルム内 のアカウントと同様の方法でKerberosに提供される。これは混合モード環境における非常に魅力的 な解決策になる可能性がある9。 パラレルNFS（pNFS）とレイアウト パラレルNFS（pNFS）は、NFSの開発における重要な進歩を意味する。2010年1月に承認され、 RFC-5661に記載されたpNFSは、クラスタ化されたファイルシステムがデータをどのようにストラ イプ化して管理しているかをNFSクライアントが認識していることを前提とする。これはデータの 属性ではなく、サーバとクライアント間の調整であるため、非pNFSやその他のファイルアクセス プロトコル経由でもデータにアクセスできる。 図3：pNFS概念データフロー pNFSは、大量の小さなファイルに伴うワークロード、または、非常に大きなファイル、特に、 データに対する同時並列アクセスが必要なコンピュータクラスタ上で動作するファイルに伴う ワークロードに対して有効である。 8 Kerberosを使用しないNFSv4の例については、Ubuntu Linux（https://help.ubuntu.com/community/NFSv4Howto）とSUSE Linux Enterprise（http://www.novell.com/support/dynamickc.do?cmd=show&forward=nonthreadedKC&docType=kc&externalId =7005060&sliceId=1）を参照のこと。 9 「Windows Security and Directory Services for UNIX Guide v1.0」：http://technet.microsoft.com/en-us/library/bb496504.aspx 10 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 クライアントは、データレイアウトに関する情報をメタデータサーバ（MDS）に要求して、デー タ配置が記載されたレイアウトを受け取る（MDSはサーバとは違うノードとして示されることが 多いが、MDSはストレージシステム内のスタンドアロンノードにしてもしなくてもよく、ストレ ージベンダのハードウェアアーキテクチャにも依存する）。データは、複数のデータサーバ上に 存在させることができ、複数の経路を辿ってクライアントから直接アクセスされる。委譲の場合 と同様に、クライアントの要求が競合している場合は、サーバがレイアウトをリコールできる。 pNFSは、帯域幅の集約を可能にすることによって、2地点間接続に関連した性能問題を軽減する。 pNFSを使用すれば、単一ストレージノードがボトルネックにならないことが保証されるため、 複数のクライアントが同時にデータサーバに直接アクセスできる。また、pNFSは、データがクラ イアントのニーズを満たすようによりよく負荷分散されることも保証する（図2を参照）。 pNFS仕様は、クライアントとデータサーバ間で使用されるプロトコルが定義された複数のレイア ウトのサポートにも対応している。現時点で、次の3つのレイアウトが指定されている。NFSv4で サポートされているファイル、2004年に承認されたObject-based Storage Device Commands （OSD）標準（INCITS T10）に基づくオブジェクト、およびブロックレイアウト（FCアクセスと iSCSIアクセスのどちらか）。アーキテクチャ内でレイアウトを選択することによって、性能と 機能性の改善が期待される。たとえば、pNFSオブジェクトベースの実装は、クライアント上の ソフトウェアでRAIDパリティ計算を実行することによって、RAID性能をクライアント数に応じて スケールするようにしたり、ネットワーク経由のデータサーバとのエンドツーエンドのデータ整 合性を保証したりできる。 そのため、pNFSはNFS標準になったばかりだが、pNFS以前の独自のプロトコルを使用している ユーザの経験から、pNFSを使用したデータへの高帯域幅アクセスがかなり有効であることが示さ れている。 pNFSの潜在的性能は、ストレージ、ネットワーク、およびサーバの構成が同様のNFSv3の性能を 明らかに上回っている。NFSv3オートマウンターマップと手作業による負荷分散スキームが排除 されているため、管理が大幅に簡素化されている。また、インタフェースが標準化されているた め、pNFSでは複数ベンダNFSサーバ環境のサポートでほとんど問題が発生しない。 提案中のNFSv4.2の機能 NFSv4.2ではエンドユーザから要求されていた多くの機能が実現され、それによってエンドユー ザーが日常的に使用するプロトコルとしてだけでなく、データセンタ越しのアプリケーションの プロトコルとしても使いやすいものになっている サーバ側コピー サーバ側コピー（SSC）ではコピー操作の1つの工程が削除される。クライアント経由であるサー バからファイル全体またはファイルのディレクトリを読み込んで別のサーバに書き込む代わりに、 SSCでは、クライアントが介在することなく宛先サーバとソースサーバが直接対話できるように することによって、クライアント帯域幅に対するサーバ上の制限とそれによって引き起こされる 輻輳が排除される。 11 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 アプリケーションデータブロック（ADB） ADBを使用すれば、ファイル（VMイメージやデータベースなど）のフォーマットの定義が可能 になる。この機能では、データストアの初期化が可能になるため、クライアントからの単一操作 でサーバ上に300 GBのデータベースやVMイメージを作成できる。 保証された領域予約とホールパンチング ストレージ需要が増え続ける中、非常に小規模なストレージシステム上でストレージの大規模仮 想プールを実現するためのさまざまな効率化技術が利用できるようになってきた。シンプロビジ ョニング（領域が利用可能で予約されているように見えるが、コミットされていない）が有名で あるが、急成長環境の管理で問題が発生することがよくある。NFSv4.2の保証された領域予約機 能では、シンプロビジョニングポリシーに関係なく、個々のファイルに必ず最大限の領域が割り 当てられることが保証される。 このような保証はエンドユーザに安心感を与えるが、使用可能なすべてのストレージをフル活用 したいストレージ管理者の助けにはならない。ストレージの効率性を高めるために、NFSv4.2で はスパースファイル（使用している領域が疎であるファイル）のサポートが導入される。一般に 「ホールパンチング（使用していない領域（ホール）を切り取る）」と呼ばれ、ファイルの削除 部分と未使用部分は、ストレージシステムの空き領域プールに戻される（図4を参照）。 図4：予約とホールパンチング サーバとクライアントの取得 NFSの機能に関するこうした背景を考慮して、サーバとクライアントの両方からNFSv4.1をサポ ートするためのエンドユーザコミュニティに大きな関心が寄せられている。現在、多くのネット ワーク接続ストレージ（NAS）ベンダがNFSv4をサポートしており、ここ数カ月の間に、NFSv4.1 とpNFSのサーバサポートに関するさまざまな活動が行われ、大きな進展が見られた。NFSサーバ ベンダについては、各社のWebサイトで最新情報を参照されたい。 12 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 クライアント側では、NFSv4.1 Technical Preview10を含むRedHat Enterprise Linux 6.2、Novell SUSE Linux Enterprise Server 11 SP2（3.0 Linuxカーネルに基づくNFSv4.1とpNFSの使用）、お よびfedoraproject.orgで入手可能なFedora 15と16がある。どちらのディストリビューションで もNFSv4.1とファイルベースのpNFSがサポートされている。独自のカーネルを構築して最新の ブロックアクセスまたはオブジェクトアクセスを検証したいと思っている冒険好きな人のため に、アップストリーム3.0 LinuxカーネルでのフルファイルpNFSサポート、3.1 Linuxカーネルで のブロックサポート、および3.3 LinuxカーネルでのオブジェクトベースのpNFSサポートが用意 されている。 Windowsに関しては、MicrosoftがWindows 8でNFSv4.1をサポートすることを発表している。 ミシガン大学のCenter for Information Technology Integration（CITI）からオープンソースクラ イアント実装プレビューを入手できる11。 まとめ NFSv4.1には、グローバルな広域ネットワーク（WAN）でその使用を可能にするための機能が 含まれている。これらの機能には次のようなメリットがある。 • ファイアウォールと相性のよい単一ポート操作 • 高度で積極的なキャッシュ管理機能 • 国際化のサポート • 複製機能と移行機能 • UNIX®とWindows®上で互換性があるアクセス制御機能を使用した、オプションの暗 号化品質セキュリティ • 並列化とデータストライピングのサポート NFSv4.1以降の目的は、ストレージの見え方ではなく、ストレージへのアクセス方法を定義する ことである。これは必然的な変化である。以前のバージョンのNFSと違って、NFSv4プロトコル には、高帯域幅ネットワーク上のデータ共有アプリケーションに合わせてクライアント性能を向 上させる、ファイルロッキング、強力なセキュリティ、操作の一括処理、および委譲の各機能が 内蔵されている。 NFSv4.1サーバとNFSv4.1クライアントは、性能を向上させるために、データのワイドストライ ピングなどのこれまでにない機能を提供する。NFSv4.2以降では、今日のアプリケーション要件 を満たすべく標準に対するさらなる拡張が約束されている。NFSv4.2は2012年8月に承認される 予定であり、その直後にNFSv4.2機能を提供するサーバとクライアントの実装が見られることが 期待されている。この機能がベンダ固有の拡張としてすでに出荷されている場合がある。 従来のバージョンからNFSv4.1やNFSv4.2への移行は、注意深く計画すれば、アプリケーション を変更したり、さまざまなアプリケーション（ホームディレクトリ、HPCストレージサーバ、 バックアップジョブなど）のための運用可能なインフラストラクチャをサポートしたりしなく ても実現できる。 10 RedHat 6.2 NFSv4.1 Technical Preview：http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html/ Storage_Administration_Guide/ch12s02.html 11 NFSv4 Client for Windows（CITI）：http://www.citi.umich.edu/projects/nfsv4/windows/ 13 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION NFSv4の概要 Ethernet Storage Forumについて Ethernet Storage Forum（ESF）は、ストレージネットワーキング・インダストリ・アソシエーシ ョン（SNIA）内のマーケティング組織であり、イーサネット接続ストレージネットワーキングソ リューションを専門とする。ベンダ中立の教材の作成を通して、ESFのソートリーダーが、世界中 で、SNIAと業界のイベントやエンドユーザ支援プログラムを利用して、イーサネット接続ストレ ージネットワーキング技術の知名度の向上と普及に努めている。詳細については、以下のURLを 参照されたい。 ZZZVQLDRUJIRUXPVHVI SNIAについて ストレージネットワーキング・インダストリ・アソシエーション（SNIA）は、非営利のグローバ ル組織で、ほぼストレージ業界全体にわたる約400社の会員企業で構成されている。SNIAの使命 は、企業の情報管理を促進する標準、技術、および教育サービスの開発と普及においてストレー ジ業界を地球規模でリードすることである。この目的を達成するために、SNIAでは、オープンス トレージネットワーキングソリューション市場を拡大するための標準、教育、およびサービスの 提供に全力で取り組んでいる。その他の情報については、 SNIAのWebサイト（KWWSZZZVQLDRUJ）を参照されたい。 このSNIAホワイトペーパーは、Alex McDonaldによって書かれた「NFSv4」というタイトルの記 事に基づいている。この記事は、「;login: The Magazine of USENIX」、vol. 37、no. 1（Berkeley、 CA: USENIX Association、February 2012）の28∼35ページに掲載されている。 14 of 14 2012 STORAGE NETWORKING INDUSTRY ASSOCIATION
© Copyright 2024 Paperzz
