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

Transcription

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 ( ( 英語 )) からダウンロードするか Ethereal の Web サイト ( 英語 ) からダウンロードしてください ( 無償 ) Ethereal は ネットワークを介して NFSv4 要求が送信されると 要求の内容とそれに対する応答を出力します 出力にはプロトコルが指定したすべてのフィールドが表示されますが 出力が非常に長くなる場合は出力の一部分が削除され そのかわりに省略記号が表示されます 図 1 は NFSv4 でファイルシステムを実装することにより生成された Ethereal 追跡情報の例です 2

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 についての詳細は ( 英語 ) から入手できる IETF (Internet Engineering Task Force) の RFC (Request For Comment) 3530 を参照してください 図 2 は 図 1 の COMPOUND RPC に対するサーバの応答を示しています 3

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 サーバは適切なディレクトリまたはファイルハンドルを返していました また 読み込みなどのファイル操作は 特定のファイルハンドルから一連 4

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 の実行状況を示しています 5

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 を返します このファイルオープンに関連付けられたステートはサーバに保持されます 6

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 に対するサーバの応答を示しています 7

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) に加え ロックマ 8

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 要求 LOCK opcode 要求に対するサーバの応答は図 9 のようになります 9

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 をマウントしようとすると 次のようなエラーメッセージが出力されます 10

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 サーバが使用できる NFS プロトコルのバージョンの種類を指定する構成パラメータです たとえば NFSv3 および NFSv4 のみ 11

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 はそれぞれ user1@cup.hp.com および users@cup.hp.com です HP-UX システム上の基本となるファイルシステムは整数ベースの UID および GID を使用しているので NFSv4 は文字列の UID および GID を整数へ置き換える必要があります たとえばファイルを作成する場合 NFS サーバは user1@cup.hp.com という文字列と システム上で 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 クライアントを再起動します 12

13 HP-UX 11i v3 クライアントで NFSv4 のみを使用するように設定するには 構成変数 NFS_CLIENT_VERSMIN および NFS_CLIENT_VERSMAX の値を両方とも 4 に設定します 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 コマンドを実行します mount server:/server_mount /client_mountpoint クライアントおよびサーバの両方が NFSv4 をサポートするよう設定されている場合 リモートファイルシステムは NFSv4 を使用してマウントされます 両方とも NFSv4 をサポートしていない場合 クライアントとサーバはネゴシエーション機能を使用し 両方がサポートするプロトコルの中で最も高い番号のバージョンを採用します 使用可能な NFS プロトコルを確認するには オプションを指定せずに nfsstat m コマンドを実行します このコマンドを実行するとマウントオプションが表示され 使用中のプロトコルバージョンを確認できます ( 図 14) 図 14. バージョンを指定せずに NFSv4 でマウントする 上記の方法とは別に 次の構文を使用して マウントする NFS プロトコルのバージョンをコマンドラインで明示的に指定することも可能です mount overs=4 server:/server_mount /client_mountpoint プロトコルのバージョンを直接指定したものの クライアントまたはサーバが NFSv4 をサポートしていない場合は 図 10 のようなエラーメッセージが出力されます 使用中の NFS プロトコルバージョンを表示するには nfsstat m コマンドを実行します 2 番目の方法で NFSv4 マウントをした場合の出力は 図 15 のようになります 図 15. バージョンを指定して NFSv4 でマウントする 本書の例では いずれの方法を使用しても NFSv4 が nfsstat m コマンドの出力に表示されています 13

14 まとめ NFS (Network File System: ネットワークファイルシステム ) は 1985 年に実装されて以来 複数のバージョンがリリースされてきました 最新バージョンである NFSv4 では NFS プロトコルへのステートの導入や ACL ロック マウントなどの補助的な機能をプロトコルへ組み込むなど 従来の NFS プロトコルに大きな変更が加えられています さらに 属性機能 共有ロック ACL サポートなどの機能拡張や セキュリティの強化が行われているため Microsoft Windows との相互運用性が向上しました この最新バージョンである NFS プロトコルを使用することにより 高い信頼性の確保や性能の向上を実現できるだけでなく 旧バージョンの NFS プロトコルのみを実装しているシステムとも完全に相互運用できるようになりました 最新版の HP-UX 11i リリースでは 機能が大幅に拡張されたこの NFSv4 を使用できます 詳細情報 HP-UX について ( 英語 ) ( 日本語 ) HP Integrity サーバについて ( 英語 ) ( 日本語 ) お問い合わせはカスタマインフォメーションセンタへ 月 ~ 金 9:00~19:00 土 10:00~18:00 ( 日 祝祭日 年末年始および 5/1 を除く ) HP-UX 製品に関する情報は HP-UX に関する技術情報は 記載されている会社名および商品名は 各社の商標または登録商標です 記載事項は 2007 年 5 月現在のものです 本書に記載された内容は 予告なく変更されることがあります 本書中の技術的あるいは校正上の誤り 省略に対して いかなる責任も負いかねますのでご了承ください 本書は Introducing Network File System Version 4 on HP-UX 11i v3 (4AA0-7689ENW, 09/2006) ( 英語 ) をもとに加筆 修正して日本語で提供するものです Copyright 2007 Hewlett-Packard Development Company,L.P. 日本ヒューレット パッカード株式会社 東京都千代田区五番町七番地 PDFHS