Network File System バージョン 4 の HP-UX 11i v3 への導入

(1)

Network File System バージョン 4 の

HP-UX 11i v3 への導入

White paper

Tはじめに...2 TNFSv4 の新機能 ...2 NFSv4 における変更点...2 COMPOUND RPC ...2 マウント_{プロトコルおよびロックプロトコルは使用しない ...4} ステートフル_{プロトコルとしての NFSv4 ...4} ファイルのオープンおよびクローズ_...6 デリゲーション...8 プロトコルの一部としてのロック...8 セキュリティ...10 NFSv4 を HP-UX 11i v3 サーバにマウントする方法...10 nfsmapid:名前ベースのユーザ ID およびグループ ID ...12 NFSv4 を HP-UX 11i v3 クライアントにマウントする方法 ...12 まとめ_...14 詳細情報_...14

(2)

はじめに

HP-UX の最新リリース HP-UX 11i v3 より、Microsoft® Windows® との相互運用性が高まり、セキュリティや性能が向上した_{NFSv4 (Network File System バージョン 4) を使用できるようになりました。本書では、最新} の_{HP-UX 11i v3 および今後リリースされるバージョンで利用できる NFSv4 の主な機能や、HP-UX システム} 管理者が_{NFSv4 を実装したクライアントやサーバを使用するにあたり理解しておく必要のある情報について} 説明します。

NFSv4 の新機能

NFSv4 では、次のような新しい機能が多数追加されました。 • ステートの導入 • ファイルデリゲーション (権限委譲) の導入 ― NFSv4 サーバを使用すると、NFSv4 クライアントはネットワークを介してサーバに要求を送信することなく、キャッシュにあるファイルへのアクセスや編集ができるようになります。

• RPC (Remote Procedure Call: リモートプロシージャコール) である複合リモートプロシージャを使用したネットワーク_{トラフィックの削減 ― 複合リモートプロシージャを使用することにより、従来より実行されている} 各_{NFS 操作 (LOOKUP、OPEN、READ) を 1 つの複合 RPC 要求にまとめることができるため、複雑な操作} でもネットワークを_{1 度往復するだけで実行できます。}

• Kerberos 5 や ACL (Access Control List) など多種にわたる高度なセキュリティメカニズムの中から、採用するセキュリティ機能を選択 • NFSv3 や NFSv 2 を実装したクライアントおよびサーバとのシームレスな共存

NFSv4 における変更点

NFSv4 と従来の NFS プロトコルには、次のような 5 つの大きな違いがあります。 • 複合ステートメント (現在対応している RPC は、NULL プロシージャと COMPOUND プロシージャの 2 種類のみ) • 独立していたマウントプロトコルおよびロックプロトコルを統合 • プロトコルへのステートの導入 • セキュリティ • デリゲーション

COMPOUND RPC

従来の_{NFS プロトコルでは、NFS の要求に対する応答が非効率であることが問題となっていました。つまり、} すでに操作した要求に対する結果によって次の要求が変わる場合、クライアントは新たな要求を送信する前にサーバからの応答を待たなければなりませんでした。そのため、従来のプロトコルを使用すると、必ず不要なレイテンシが発生していたのです。_{COMPOUND (複合) 要求を使用することにより、クライアントは複数の NFS} 要求を_{1 つの要求にまとめてネットワーク送信することができます。} 本書では、_{NFS 要求および応答を Ethereal の追跡機能を用いて表示する方法について説明します。Ethereal} は_{Wireshark とも呼ばれるマルチプロトコルネットワーク分析ツールです。Ethereal を入手するには、HP} Internet Express バンドルとして HP Software Depot (http://software.hp.com (英語)) からダウンロードするか、_{Ethereal の Web サイト http://www.ethereal.com (英語) からダウンロードしてください (無償)。Ethereal} は、ネットワークを介して_{NFSv4 要求が送信されると、要求の内容とそれに対する応答を出力します。出力に} はプロトコルが指定したすべてのフィールドが表示されますが、出力が非常に長くなる場合は出力の一部分が削除され、そのかわりに省略記号が表示されます。

(3)

図 1. COMPOUND RPC 要求

1 行目および 2 行目は、この出力が NFS 追跡情報であり、プロトコルのバージョンが 4 であることを示しています。3 行目はクライアントが作成した NFSv4 RPC の種類を表示しています。NFSv4 が対応している RPC は COMPOUND RPC および NULL RPC の 2 種類のみであるため、ほとんどの場合、COMPOUND プロシージャが作成されます。4 行目から 8 行目は RPC の内容を記述したヘッダー情報です。たとえば、4 行目はこの RPC がマウント要求であることを示すタグです。COMPOUND プロシージャは、複数の opcode と呼ばれるサブ要求で構成されています。図 1 の 8 行目を見ると、この要求は 5 つの opcode で構成されていることがわかります。

他の行は NFSv4 要求をテキストで表示したものであり、データの階層に応じてインデントされています。たとえば、attrmask は GETATTR opcode 内のフィールドであるため、16 行目は 15 行目よりインデントされています。また、17 行目および 18 行目は attrmask フィールド内にあることを示しています。attrmask にはインデントされている行があと 2 行 (19 行目と 20 行目) がありますが、出力を短くするために省略記号で表示されています。

この COMPOUND 要求には、PUTROOTFH、GETFH、LOOKUP、2 回目の GETFH、GETATTR の各 opcode 要求が含まれており、それぞれ 9 行目、10 行目、11 行目、14 行目および 15 行目に出力されています。この例で使用されている opcodeや他の opcode についての詳細は http://www.ietf.org/rfc/rfc3530.txt (英語) から入手できる IETF (Internet Engineering Task Force) の RFC (Request For Comment) 3530 を参照してください。

(4)

図 2. COMPOUND RPC 応答

サーバは、障害が発生しない限り、各 opcode に対してそれぞれステータスおよび戻り値を返します。たとえば、 PUTROOTFH opcode を実行した結果、ステータス NFS4_OK が返されており (9 行目および 10 行目)、 GETATTR opcode の実行結果には、ステータス (22 行目の NFS4_OK) に加えて GETATTR opcode が要求したさまざまな属性値が返されています。ある opcode の実行中に障害が発生した場合、以降の opcode は実行されず、サーバに蓄積されていた実行済みの結果はクライアントに返されます。 FTTR4_SUPPORTED_ATTRS 要求 (図 1 の 17 行目) とそれに対する応答 (図 2 の 25 行目から 28 行目) に注目してください。NFSv4 から、NFS がサポートする属性の種類が拡張されました。たとえば、NFSv4 仕様への準拠に必要な必須属性、NFS 相互運用性をサポートする推奨属性、およびサーバが値/ペア割り当てを維持できるようにする名前指定属性などを使用できるようになりました。ただし HP-UX 11i v3 では現在、名前指定属性をサポートしていません。 GETATTR 操作を実行すると、NFSv4 クライアントから、特定ファイルにどのような NFSv4 属性がサポートされているかをサーバに照会できます。この機能により、Windows クライアントアプリケーションや NFSv4 インプリメンテーションが、NFSv4 サーバがサポートするファイルの属性をサーバに照会でき、それに応じて機能を適用または除外できるようになるため、Windows と UNIX® の相互運用性が高まります。

マウント

プロトコルおよびロックプロトコルは使用しない

図_{1 にはマウントプロトコルのメッセージが一切ありません。これは、NFSv4 の一部である PUTROOTFH} opcode がマウントの処理を行っているためです。同様に、独立したロックプロトコルもありません。ロックは NFSv4 opcode である LOCK、LOCKU、LOCKT が処理しています。これらの opcode については、「プロトコルの一部としてのロック」項目で説明します。

ステートフル

プロトコルとしての NFSv4

従来の_{NFS プロトコルは、NFS サーバがそのクライアントの情報や状況を一切保持しないことから、ステート} レスでした。たとえば、従来の_{NFS プロトコルではオープンまたはクローズ操作が定義されておらず、NFS ク} ライアントがディレクトリおよびファイル上で_{LOOKUP 操作を実行し、NFS サーバは適切なディレクトリまたは} ファイル_{ハンドルを返していました。また、読み込みなどのファイル操作は、特定のファイルハンドルから一連}

(5)

のバイト範囲を読み込む NFS 要求として実行されていました。このファイルハンドルは、NFS クライアントからは認識できないものの、多くの場合、ファイルに関連付けられたディスクベースのデータを示しています。これに対し、NFSv4 はステートフルプロトコルです。したがって、NFSv4 サーバはクライアント、クライアントが開いているファイル、およびロックに関する情報を保持しています。たとえば図 3 のような 2 回目の COMPOUND プロシージャは mount コマンドの一部として作成されたものであり、SETCLIENTID opcode のみで構成されています。図 3. SETCLIENTID opcode 要求 SETCLIENTID opcode は、このクライアントに関連付けられたステートを管理するハンドルを作成する際に使用され、_{client、callback、callback_ident フィールドで構成されています。図 3 の 12 行目から 14 行目に出力} されている_{callback フィールドは、このクライアント ID に関連付けられており、16 行目の callback_ident とと} もに、デリゲーション管理に使用されます。デリゲーションについては、以降の項目で説明します。

SETCLIENTID opcode を受信すると、サーバはクライアントに固有 ID を割り当て、SETCLIENTID opcode に対する応答の中でその固有_{ID をクライアントに通知します。図 4 はこの応答を示したものです。}

図_{4. SETCLIENTID opcode に対する応答}

サーバがこのクライアントに割り当てたクライアント ID は、図 4 の 11 行目に出力されています。

NFSv4 はステートフルプロトコルであるため、opcode によっては、サーバがクライアントを識別できるようにクライアントからこのクライアント ID をサーバに送信しなければならないものもあります。たとえば、ロックは 1 つのクライアント (つまりクライアント ID) と関連付けられているため、ロック opcode である LOCK、LOCKU、 LOCKT ではすべて、クライアントからの送信時に各 opcode にクライアント ID を組み込まなければなりません。 NFSv4 の一部として定義されている opcode の一覧を見るには、nfsstat コマンドを実行します。nfsstat コマンドは拡張されて、NFSv4 の統計値を表示できるようになりました。たとえば図 5 は、NFSv4 を実装した後の NFSv4 opcode の実行状況を示しています。

(6)

図_{5. nfsstat コマンドによる NFSv4 出力}

この出力には_{NFSv4 の NULL プロシージャおよび COMPOUND プロシージャだけではなく、COMPOUND} プロシージャの一部として送信されるすべての_{opcode が表示されています。この一覧には、GETFH (8 行目)、} PUTROOTFH (18 行目)、SETCLIENTID (24 行目) が含まれていますが、これらは最初のマウント要求 (図 1)、およびクライアントの識別_{(図 3) で使用された opcode です。SETCLIENTID_CONFIRM の詳細については} RFC を参照してください。また図_{5 には、ファイルオープンに関連する opcode、OPEN (14 行目) および CLOSE (4 行目) と、ロックに} 関連する_{opcode、LOCK、LOCKU、LOCKT (10 行目) も含まれています。}

ファイルのオープンおよびクローズ

図 6 は open() システムコールが実行された後に生成された Ethereal 追跡情報を示しています。サーバがクライアントに返信したクライアント ID は、NFSv4 の各操作で使用できます。ファイルオープンの際、サーバはこのクライアントによるファイルオープンのインスタンスを特定するステート ID を返します。このファイルオープンに関連付けられたステートはサーバに保持されます。

(7)

図 6. OPEN opcode 要求

OPEN opcode は 12 行目に出力されており、OPEN opcode のパラメータの 1 つはクライアント ID です (16 行目_{)。前述したように、クライアント ID はファイルをオープンしているクライアントの確認に必要です。16 行目} のクライアント_{ID が、SETCLIENTID opcode の一部としてクライアントに返された ID (図 4 の 11 行目) と一} 致していることに注意してください。

次に、_{14 行目および 15 行目にある OPEN opcode の share_access および share_deny フィールドに注目} します。これらのフィールドは共有ロック方式をサポートするために使用されます。この共有ロック機能は Windows 環境ではよく使用されていますが、NFSv4 でも使用できるようになりました。共有ロックがサポートされることにより、_{HP-UX 11i v3 サーバでも共有ロックを多用する Windows アプリケーションを使用できるよう} になるため、_{Windows と UNIX の相互運用性が高まります。} 共有ロックを使用すると、クライアントはファイルに対してオープン_{アクセスできますが、以降別のクライアント} によるオープン_{アクセスは拒否されます。ただし、共有ロックを使用できない場合、または以降のアクセスロッ} ク要求を拒否できない場合は、オープンに失敗します。たとえば、クライアントがファイルを読み込んでいる間はファイルが更新されないようにしたい場合、クライアントは共有読み込みロックおよび共有書き込み拒否ロックをかけた状態でファイルを開きます。その際、他のクライアントが書き込み中でなければ、そのファイルをオープンできます。なお、共有ロックはクライアントがファイルをクローズするまで保持されます。したがって、あるクライアントがファイルをオープンした後に、他のクライアントが共有書き込みアクセスを使用してそのファイルをオープンしようとしても、最初にオープンしたクライアントがクローズするまで、次のクライアントはオープンできません。図_{7 は OPEN opcode に対するサーバの応答を示しています。}

(8)

図 7. OPEN opcode に対する応答 13 行目のステート ID は、OPEN opcode に対する応答の一部としてサーバが返したものであり、このクライアントがファイルをオープンしている状態を示しています。この_{ID を使用して、ステートとこのファイルオープン} のインスタンスとが関連付けられます。

デリゲーション

通常、ネットワークにあるファイルロックおよびファイルデータの管理は NFS サーバが行います。複数のクライアントがリモートから複数の管理ファイルにアクセスする場合には、集中して管理を担当するマシンが必要です。しかし、あるファイルに対して書き込みを行っているクライアントが 1 台のみの場合、また、複数のクライアントがあるファイルに対して読み込みのみを行っている場合、ファイルのロックおよびデータの管理をそのクライアントに委譲することが可能です (つまり、ファイルのロックおよびデータは書き込み中の 1 つのクライアントまたは読み込み中の複数のクライアントがローカルで管理します)。ファイルを管理する際は NFS サーバおよび NFS クライアント間でネットワークトラフィックを転送する必要がありますが、管理を委譲することによりこのやりとりが不要となるため、性能が向上します。管理を委譲すると、クライアントがファイルロックおよびデータ管理の責任を負うので、サーバはクライアントが起動し、アクセスできる状態であることを確認する必要があります。NFSv4 サーバはクライアントが利用可能な状態であることを確認するために、NFSv4 クライアントのコールバックデーモン (nfs4cbd) に RPC 要求を送信します。サーバは、SETCLIENTID 要求 (図 3 参照) で送信される callback および callback_ident フィールドを使用して、クライアントの nfs4cbd がリスンしている場所を特定します。

デリゲーションを無効にする必要がある場合、nfs4cbd はそのクライアントが管理しているすべてのロック権限やファイルデータをサーバに返す必要があります。

NFSv4 クライアントは、HP-UX 11i v3 でのデリゲーションをサポートしています。ただし、HP-UX 11i v3 上の NFSv4 サーバがクライアントへファイル管理の権限を委譲できるのは、ローカルからそのファイルにアクセスされることがない場合に限られます。たとえば、サーバがディレクトリ “dir” をエクスポートすると、サーバ上のローカルプロセスは “dir” ディレクトリ内のファイルにアクセスできないはずです。この制限は次の HP-UX 11i v3 リリースで解消される予定です。

プロトコルの一部としてのロック

従来の_{NFS プロトコルはステートレスですが、ロックやノードの状態 (起動、再起動中、終了などの状態) など} を管理するために付属のプロトコルやデーモンが作成されていました。ただし、これらのプロトコルおよびデーモンは_{NFS と関連付けられているものの、NFS プロトコルには含まれていません。作成されたプロトコルやデ} ーモンには、ロックおよびノード_{ステータスデーモン (それぞれ rpc.lockd および rpc.statd) に加え、ロックマ}

(9)

ネージャプロトコルなどがあります。これらの各デーモンは NFSv2 および NFSv3 が稼動している HP-UX 11i v3 にも存在しています。

NFSv4 がサポートするすべての opcode リストを出力した図 5 を見ると、LOCK、LOCKT、LOCKU (10 行目) などロック関連の opcode も表示されています。LOCK、LOCKT、LOCKU opcode は、それぞれファイルロックの作成、試行、解除の操作に対応しています。従来の NFS ではロックの操作を NFS の外側で行っていましたが、NFSv4 ではこれらの opcode を追加してプロトコル内からロックの操作を行うようになりました。

図 8 の Ethereal の追跡情報は C プログラムにより生成された出力です。ファイルをオープンした後、最初の 3 バイトに読み込みロックを適用するよう要求しています。この要求にはファイルと関連付けられたステート ID (18 行目) とクライアント ID (23 行目) が含まれており、それぞれ図 7 の 15 行目にある OPEN opcode が付与したステート ID、および、図 4 の 11 行目にある SETCLIENTID opcode が付与したクライアント ID と一致しています。ロック要求はこのクライアントとファイルオープンのインスタンスとの両方に関連付けられているため、両方の ID が必要になります。

図 8. LOCK opcode 要求

(10)

図 9. LOCK opcode に対する応答この特定のロックを指すステート_{ID (17～19 行目) をサーバがクライアントにどのように返すかに注目してくだ} さい。また、サーバはクライアントのステートを保持しているため、クライアントにクライアント_{ID も返しています。} この例では、サーバはこのクライアントの特定のロックについてステートを維持しています。クライアントが_{LOCKU opcode を使用してロックを解除しようとした場合、サーバがこのロック要求を処理でき} るよう、ロックに関連付けられたステート_{ID がサーバに通知されます。}

セキュリティ

従来の NFS プロトコルでは、高度なセキュリティの使用を推奨していませんでした。そのため NFS クライアントでは、通常、高度なセキュリティのかわりに、整数ベースの標準的な UNIX 認証 (AUTH_SYS) または無認証 (AUTH_NONE) を使用していました。しかし、NFSv4 仕様に準拠するには GSS-API や Kerberos、LIPKEY などの高度なセキュリティ機能を実装する必要があるため、NFSv4 のセキュリティは確実に向上しています。 NFSv4 仕様では、クライアントおよびサーバのネゴシエーション機能を使用して、使用するセキュリティのタイプを決定するよう規定しています。ネゴシエーションでは、まずクライアントが SECINFO opcode をサーバに送信します。サーバは利用できるセキュリティタイプの優先順位を記載したリストを返信します。リストの一番上には、サーバにとって一番好ましいセキュリティタイプが記述されています。クライアントはそのリストの中から任意にセキュリティタイプを選択します。クライアントが選択したそのセキュリティタイプはクライアントとサーバの両方で採用されます。 NFSv4 でも AUTH_SYS または AUTH_NONE セキュリティを使用したい場合は、引き続き利用することも可能です。

また、NFSv4 ではアクセスコントロールリスト (ACL) もサポートしています。NFSv4 ACL の仕様は Windows 環境にある ACL をベースに作成されたため、Windows 環境で利用できる ACL と類似しています。

NFSv4 を HP-UX 11i v3 サーバにマウントする方法

デフォルトでは、_{HP-UX 11i v3 サーバで NFSv4 を使用できないように設定されています。NFSv4 を使用でき} ない状態のサーバに_{NFSv4 をマウントしようとすると、次のようなエラーメッセージが出力されます。}

(11)

図 10. mount コマンドのエラー NFSv4 をマウントするには、サーバ上の NFS 構成ファイル /etc/default/nfs を修正します。または以下で説明するように_{setoncenv(1M) コマンドを使用します。なお、この構成ファイルには、NFS クライアント、NFS サ} ーバ、およびロック_{マネージャに関するあらゆる構成変数が含まれています。} クライアントで_{NFSv4 ファイルシステムをマウントするには、図 11 のように setoncenv(1M) コマンドを実} 行し、_{/etc/default/nfs ファイルの NFS_SERVER_VERSMAX 値を 4 に変更します。} 図_{11. サーバ上で NFSv4 を使用する}

図_{12 のように、起動/シャットダウンスクリプトである /sbin/init.d/nfs.server を stop および start パラメ} ータとあわせて実行し、_{NFS サーバのサービスをサーバ上で再起動します。} 図_{12. NFSv4 サーバサービスの再起動} デフォルトでは、ネゴシエーション機能を使用して、_{NFS クライアントとサーバが使用するプロトコルのバージョ} ンを決定します。クライアントとサーバは両方がサポートするプロトコルの中で、バージョン番号が最も高いプロトコルを採用します。たとえば、クライアントが_{NFSv2、NFSv3 および NFSv4 をサポートしており、サーバが} NFSv2 および NFSv3 のみをサポートする場合、クライアントとサーバは NFSv3 を使用します。この方法により、_{NFSv4 をマウントしたクライアントおよびサーバは、NFSv4 をサポートしていない他のクライアントおよびサ} ーバともシームレスに動作します。 NFSv4 のみを使用するには、構成パラメータ NFS_SERVER_VERSMIN および NFS_SERVER_VERSMAX の値を_{4 に設定します。NFS_SERVER_VERSMIN および NFS_SERVER_VERSMAX は、NFS サーバが使用でき}

(12)

を使用するには、構成ファイル NFS_SERVER_VERSMIN および NFS_SERVER_VERSMAX の値をそれぞれ 3 と 4 に設定します。 NFS サーバを再起動した後、/var/adm/syslog/syslog.log ファイルにエラーメッセージがないことを確認します。最後に share コマンドを実行し、マウントできるように変更したディレクトリを共有します。詳細については share(1M) のマンページを参照してください。

nfsmapid:名前ベースのユーザ ID およびグループ ID

従来の NFS プロトコルではユーザ ID (UID) およびグループ ID (GID) を 32 ビットの整数で表示していたのに対し、NFSv4 サーバおよびクライアントは、ファイルの所有者およびグループの属性を文字列で表示します。たとえば、図 13 は close() システムコールの一部として送信された GETATTR opcode 要求に対する応答を示しています。

図 13. GETATTR opcode に対する応答

GETATTR opcode に対する応答は 11 行目以降に表示されており、ファイルの所有者およびグループの値は 19 行目から 26 行目にかけて出力されています。この例の場合、 UID および GID はそれぞれ “[email protected]” および “[email protected]” です。

HP-UX システム上の基本となるファイルシステムは整数ベースの UID および GID を使用しているので、 NFSv4 は文字列の UID および GID を整数へ置き換える必要があります。たとえばファイルを作成する場合、 NFS サーバは [email protected] という文字列と、システム上で user1 を表す 32 ビットの UID とマッピングさせる必要があります。この変換は nfsmapid デーモンにより実行されます。

NFSv4 を HP-UX 11i v3 クライアントにマウントする方法

デフォルトでは、_{HP-UX 11i v3 を実行するクライアントでは NFSv4 を使用できないように設定されています。} HP-UX 11i v3 クライアントで NFSv4 を使用するには、HP-UX 11i v3 サーバで NFSv4 を使用する際の設定方法と同様に、構成ファイル_{/etc/default/nfs 内の構成変数 NFS_CLIENT_VERSMAX の値を 4 に設定した} 後、起動_{/シャットダウンスクリプト /sbin/init.d/nfs.client を stop および start パラメータとあわせて実行し、} NFS クライアントを再起動します。

(13)

HP-UX 11i v3 クライアントで NFSv4 のみを使用するように設定するには、構成変数 NFS_CLIENT_VERSMIN および NFS_CLIENT_VERSMAX の値を両方とも 4 に設定します。

が使用するプロトコルのバージョンの種類

mount server:/server_mount /client_mountpoint

テートしていない場合、クライアントとサーバ

ジョンを指定せずに NFSv4 でマウントする

NFS_SERVER_VERSMIN および NFS_SERVER_VERSMAX と同様、 NFS_CLIENT_VERSMIN および NFS_CLIENT_VERSMAX を使用すると、HP-UX 11i v3 クライアント

を指定できます。たとえば、HP-UX 11i v3 クライアントで NFSv2、NFSv3 および NFSv4 を有効にする場合、構成変数 NFS_CLIENT_VERSMIN および NFS_CLIENT_VERSMAX の値をそれぞれ 2 と 4 に設定します。クライアントが再起動した後 NFSv4 をマウントするには、次のような簡単な mount コマンドを実行します。クライアントおよびサーバの両方が NFSv4 をサポートするよう設定されている場合、リモートファイルシスムは NFSv4 を使用してマウントされます。両方とも NFSv4 をサポはネゴシエーション機能を使用し、両方がサポートするプロトコルの中で最も高い番号のバージョンを採用します。使用可能な NFS プロトコルを確認するには、オプションを指定せずに nfsstat –m コマンドを実行します。このコマンドを実行するとマウントオプションが表示され、使用中のプロトコルバージョンを確認できます (図 14)。図 14. バー上記の方法とは別に、次の構文を使用して、マウントする NFS プロトコルのバージョンをコマンドラインで明示に指定することも可能です。 NFSv4 をサポートしていない場合バージョンを表示するには、ジョンを指定して NFSv4 でマウントする的

mount –overs=4 server:/server_mount /client_mountpoint プロトコルのバージョンを直接指定したものの、クライアントまたはサーバがは、図 10 のようなエラーメッセージが出力されます。使用中の NFS プロトコル nfsstat –m コマンドを実行します。2 番目の方法で NFSv4 マウントをした場合の出力は、図 15 のようになります。図 15. バー本書の例では、いずれの方法を使用しても NFSv4 が nfsstat –m コマンドの出力に表示されています。

(14)

まとめ

NFS (Network File System: ネットワークファイルシステム) は 1985 年に実装されて以来、複数のバージョンがリリースされてきました。最新バージョンである_{NFSv4 では、NFS プロトコルへのステートの導入や、ACL、} ロック、マウントなどの補助的な機能をプロトコルへ組み込むなど、従来の_{NFS プロトコルに大きな変更が加} えられています。さらに、属性機能、共有ロック、_{ACL サポートなどの機能拡張や、セキュリティの強化が行わ} れているため、_{Microsoft Windows との相互運用性が向上しました。この最新バージョンである NFS プロトコ} ルを使用することにより、高い信頼性の確保や性能の向上を実現できるだけでなく、旧バージョンの_{NFS プロ} トコルのみを実装しているシステムとも完全に相互運用できるようになりました。最新版の_{HP-UX 11i リリースでは、機能が大幅に拡張されたこの NFSv4 を使用できます。}

詳細情報

• HP-UX について http://www.hp.com/go/hpux11i (英語) http://www.jpn.hp.com/products/software/oe/hpux/ (日本語) • HP Integrity サーバについて http://www.hp.com/go/integrity (英語) http://www.hp.com/jp/integrity (日本語) お問い合わせはカスタマインフォメーションセンタへ