NetApp Tech OnTap
NFSバージョン4の新機能

Network File System(NFS)は1984年の発表以来、特にUNIX®およびLinux®コミュニティでネットワークファイル共有のための標準になっています。NFSプロトコルは過去20年にわたってゆっくりと進化し、新しいニーズや市場の変化に順応してきました。

NetAppは、ユーザのニーズを満たすことができるよう、NFSの革新に積極的に取り組んできました。NetAppのチーフテクノロジオフィサーBrian Pawlowskiは、現在最も普及しているバージョンであるNFSバージョン3の仕様開発に参加し、NFSバージョン4(NFSv4)ワーキンググループの共同議長も務めています。NetAppのMike EislerおよびDave Nioveckは、現在利用できる最新のバージョンであるNFSバージョン4の仕様開発に参加しており、現在開発中のNFSバージョン4.1仕様の編集者でもあります。

 
NFSv3
NFSv4
パーソナリティ ステートレス ステートフル
セマンティクス UNIXのみ UNIXおよびWindowsをサポート
認証 弱(AUTH_SYS) 強(Kerberos)
識別 32ビットUID/GID ストリングベース(xyz@netapp.com)
権限 UNIXベース Windows様式のアクセス
トランスポート UDPおよびTCP TCP
キャッシング アドホック 委譲

表1)NFSv3とNFSv4の比較

NFSはサーバソフトウェア(NetApp®ストレージ上で動作するソフトウェアなど)と、ネットワークストレージにアクセスする必要のあるホスト上で動作するクライアントソフトウェアで構成されています。正常に動作するには、接続の両サイド(クライアントとサーバ)が成熟し、正しく実装されている必要があります。NetAppではコードベースであるData ONTAP® 6.4以来NFSバージョン4を出荷していますが、度重なる変更を経て成熟した今、NFSv4は業務に使用できるレベルに達したと確信しています。
現在、クライアント実装は安定しつつあります。また、Data ONTAP 7.3では、NFSv4をサポートするための大幅な変更と機能拡張を行っています。今回は、NFSv4で注目を集めた、次の3つの重要な機能について検証します。

  • Access Control List(ACL;アクセス制御リスト)によるセキュリティとWindows®互換性
  • Kerberosによる必須セキュリティ
  • 委譲によるクライアント側キャッシング
以下の記述は、大筋においてすべてのNFSv4実装に当てはまりますが、NetApp独自の情報もある程度詳しく説明し、必要に応じてベストプラクティスを紹介します。.

  AIX
クライアント/サーバ
BSD/OSXクライアント/サーバ(appleによってサポートされない) EMC
サーバ
Humingbirdクライアント Linuxクライアント/サーバ(RHEL5) NetApp
サーバ
Solaris 10クライアント/サーバ
委譲    
ACL    
Kerberos V5
ファイルストリーム          
I18n  
グローバル
ネームスペース/参照
      将来に
予定
 

表2)NFSv4クライアント/サーバ実装のステータス

ACL
ACLは、Windowsクライアントとの高度な互換性を希望するNetAppユーザから最も強く望まれている機能の1つです。NFSv4 ACLは、NFSセキュリティおよびCIFSとの相互接続性を大幅に改善します。
どのファイルオブジェクトについても、ACLを使用してユーザ単位でアクセス権限を許可または拒否することで、従来のUNIXモード権限ビットよりも、きめ細かいアクセス制御と高度な選択性を提供できます。NFSv4 ACLはNTモデルをベースとしていますが、オーナー/グループ情報は含んでいません。NFSv4 ACLは、アクセスの許可/拒否、権限ビット、ユーザ名/グループ名、およびフラグに関する情報を含む一連のAccess Control Entry(ACE;アクセス制御エントリ)で構成されています。
NetAppはすでにCIFSクライアント用のACLサポートを提供しているため、NFSv4でACLを追加する際、固有の考慮事項がいくつかあります。NetAppでは3タイプのqtree(UNIX、NTFS、および混在型)を提供し、さまざまなクライアントで使用できるようにしています。qtreeのタイプによって、NFSv4 ACLの処理が異なります。

UNIX qtree
  • NFSv4 ACLおよびモードビットが有効
  • Windowsクライアントは属性を設定できない
  • UNIXのセマンティクスが優位

NTFS qtree

  • NT ACLおよびモードビットが有効、UNIXクライアントは属性を設定できない
  • NT ACLを使用するファイルにアクセスするNFSクライアント用のモードビットから、NFSv4 ACLが生成される
  • NTのセマンティクスが優位

混在型qtree

  • NFSv4 ACL、NT ACL、およびモードビットが有効
  • WindowsおよびUNIXクライアントが属性を設定できる
  • NT ACLを使用するファイル用のモードビットからNFSv4 ACLが生成される

期待する結果を得るには、使用するqtreeのタイプを慎重に選ぶ必要があります。

  • NFSアクセスのみ:UNIX qtree
  • 混在型アクセス:混在型qtree
  • 大部分がCIFSアクセス:NTFS qtree
  • CIFSのみ:NTFS qtree

ACLに関するその他のベストプラクティスは、ACLごとのACE数が192を超えないようにすることだけです。現在、ACLごとに最大400個までACEを増やせるようになっていますが、実際にそうすると、Data ONTAPの旧バージョンに戻す必要が生じたり、SnapMirror®を使用して旧バージョンに戻したりする場合に、問題が発生する可能性があります。

必須セキュリティ

NFSv4ではACLに加えて、次の方法で従来のNFSバージョンのセキュリティを強化しています。

  • 暗号化に依存する強力なRPCセキュリティを必須とする
  • セキュアな帯域内システムを通じて、サーバとクライアント間で使用するセキュリティのタイプをネゴシエートする
  • ユーザおよびグループの識別子を、整数ではなく文字列で表す

RPCSEC_GSS [RFC2203]と呼ばれる、Generic Security Services API(GSS-API)をベースとするセキュリティの追加により、NFSセキュリティが強化されています。NFSの全バージョンがRPCSEC_GSSを使用可能です。ただし、適正なNFSバージョン4実装では、RPCSEC_GSSの実装が必須です。RPCSEC_GSSは、従来のNFSバージョンで標準の認証方式として広く使用されていたAUTH_SYSセキュリティと同様に配置します。
RPCSEC_GSSは、AUTH_SYSなど従来のNFSセキュリティメカニズムと、次の2つの点で異なります。

  • RPCSEC_GSSには、認証以外の機能もあります。RPC要求/応答のボディ全体の完全性チェックサムと暗号化を実行できます。このように、RPCSEC_GSSは単なる認証を超えるセキュリティを提供します。
  • RPCSEC_GSSはGSS-APIメッセージトークンをカプセル化し、Kerberosなどのセキュリティメカニズムに対応するメカニズム固有トークンのトランスポートとして動作するだけなので、(GSS-APIに準拠するメカニズムであるかぎり)新しいセキュリティメカニズムを追加してもNFSの大幅な書き換えは不要です。

NFS AUTH System















図1)NFSでのAUTH_SYSおよびRPCSEC-GSSセキュリティの使用比較

NFSv3およびNFSv4は、どちらもRPCSEC-GSSを使用できます。ただし、NFSv3ではAUTH_SYSがデフォルトです。
NetAppをはじめ大部分のNFSv4クライアントが現在RPCSEC_GSSで提供している唯一のセキュリティメカニズムがKerberos 5です。Kerberosは、対称鍵暗号を使用する認証メカニズムです。ネットワーク上でクリアテキストまたは暗号化形式でパスワードを送信することは一切なく、暗号化チケットおよびセッションキーに依存して、ネットワークリソースの使用に先立ってユーザを認証します。Kerberosシステムでは、ユーザ名およびパスワードの集中データベースを含むKey Distribution Center(KDC)を使用します。NetAppは、2タイプのKDC(UNIXおよびWindows Active Directory)をサポートしています。
必要であれば、従来のNFSバージョンで使用されていた認証方式(AUTH_SYS)を使用することも依然として可能です。それには、exportfsコマンドラインまたは/etc/exportsファイルで、sec=sysと指定します。AUTH_SYSを使用する場合、Data ONTAPでは1つのクレデンシャルで最大16の補足グループIDと1つのプライマリグループIDのみがサポートされます。Kerberosを使用する場合は、最大32の補足グループIDがサポートされます。

委譲によるクライアント側キャッシング

NFSv3では、クライアントは通常、(実際に競合する場合はほとんどありませんが)オープンファイルをめぐって競合があるかのごとく動作します。他のユーザによるオープンファイルの書き換えを検出するために、クライアントからサーバへの頻繁な要求が行われている間、弱いキャッシュ一貫性が維持されます。他のユーザによる書き換えは、不要なネットワークトラフィックと遅延環境を引き起こす可能性があります。クライアントがファイルをロックしている状況では、すべての書き込みI/Oが同期的でなければならないため、多くの状況でクライアント側のパフォーマンスがさらに悪化することになります。
NFSv4は従来のNFSバージョンとは異なり、サーバがファイルに対するある種のアクションをクライアントに委譲できるようにすることで、よりアグレッシブなデータのクライアントキャッシングと、ロッキング状態のキャッシングを可能にしています。サーバはファイルの更新とロッキング状態に関する制御をクライアントに委譲します。その結果、クライアントがローカルでさまざまな動作とデータキャッシングを実行できるようになり、遅延が短縮されます。現在、2つのタイプの委譲(読み取りと書き込み)があります。ファイルへの競合が発生した場合、サーバはクライアントから委譲をコールバックすることができます。
委譲されたクライアントは、ファイルのデータをローカルでキャッシングし、ファイルの処理を実行することで、ネットワークの遅延を防ぎI/Oを最適化できます。委譲によるアグレシッブなキャッシングは、次のような環境で大きく役立ちます。

  • 頻繁なオープンとクローズ
  • 頻繁なGETATTR
  • ファイルロッキング
  • 読み取り専用の共有
  • 高遅延
  • 高速クライアント
  • 多数のクライアントによる高負荷のサーバ

Data ONTAPは、読み取りと書き込みの両方の委譲をサポートしています。また、ユーザがNFSv4サーバを個別にチューニングし、これらの委譲タイプの一方または両方を有効/無効にすることができます。委譲をオンに設定すると、Data ONTAPは読み取り用にファイルをオープンしたクライアントに対して読み取り委譲を、または書き込み用にファイルをオープンしたクライアントに対して書き込み委譲を自動的に与えます。
読み取り/書き込み委譲を有効または無効にするためのオプションが提供され、委譲による影響を一定レベルまで制御できます。概念的には、クライアントに委譲を与えるかどうかをサーバが判断します。読み取りが集中的に実行される環境では、読み取り委譲をオンに設定すると有利です。技術開発における構築環境で、各ユーザが個別のビルドファイルに書き込みを行い、競合が発生しない場合には、書き込み委譲を使用するとパフォーマンスが向上します。これに対し、複数のユーザが同じファイルへの書き込みを行う状況では、書き込み委譲は効果的ではないと考えられます。

詳細情報

データセキュリティに(当然のことながら)懸念を感じている場合には、ACLサポートや必須セキュリティなど、NFSv4の新機能によって、不正データアクセスのリスクを大幅に削減できる可能性があります。NFSv4では、インターネットでのパフォーマンスの向上も、重要な設計目標とされました。委譲によるクライアントキャッシング動作の改善は、この目標に合致するものです。
この記事で説明した顕著な変更に加えて、NFSv4ではその他にも次のような重要な変更が行われています。

  • 余分なオープンポートを必要とする、独立型マウントデーモンおよびその他のアクセサリサービスの排除
  • 応答時間を短縮し、ネットワークトラフィックを削減する目的で、一般的なタスクを1つの動作にグループ化した複合要求

以上のようなNFSv4の機能について詳しく知るには、概略を記したTR-3085(PDF:英語)を参照してください。

vmworld-2008 Bikash R. Choudhury
ソリューションアーキテクト
NetApp

Bikashは現在、NFS/テクニカルアプリケーションソリューションアーキテクトとして、NFSを使用するテクニカルアプリケーションソリューションのアーキテクチャ設計、機能テスト/認定、およびNFSベストプラクティスに関するGlobal Partner Allianceのサポートを担当しています。Bikashはテクニカルサポートエンジニアとして8年前にNetAppに入社し、その後、NetAppの最大のお客様の1つを担当するテクニカルグローバルアドバイザー(TGA)になりました。

関連情報