19 NFS共有ファイルシステム #

YaSTを使用して、ネットワーク上のホストをNFSサーバにすることができます。NFSサーバとは、アクセスを許可されたすべてのホスト、またはグループのすべてのメンバーに、ディレクトリやファイルをエクスポートするサーバのことです。これにより、サーバは、ホストごとにアプリケーションをローカルインストールせずにアプリケーションを提供することもできます。

そのようなサーバをセットアップするには、次の手順に従います。

NFSエクスポートサービスの環境設定ファイルは、/etc/exportsと/etc/sysconfig/nfsです。Kerberized NFSを使用したNFSv4サーバ設定に必要な場合、またはクライアントが数字のユーザ名を処理できない場合は、これらのファイル以外に/etc/idmapd.confも必要です。

サービスを起動または再起動するには、systemctl restart nfsserverコマンドを実行します。これにより、NFSサーバで必要なRPCポートマッパも再起動されます。

NFSサーバがブート時に常に起動するようにするには、sudo systemctl enable nfsserverを実行します。

注記: NFSv4

NFSv4は、SUSE Linux Enterprise Serverで利用できる最新版のNFSプロトコルです。NFSv3と同じ方法で、NFSv4でのエクスポート用にディレクトリを設定できるようになりました。

SUSE Linux Enterprise Server 11では、/etc/exportsのバインドマウントが必須でした。これは引き続きサポートされていますが、非推奨になりました。

NFSでKerberos認証を使用するには、Generic Security Services (GSS)を有効にする必要があります。最初のYaST NFSサーバのダイアログで、GSSセキュリティを有効にするを選択します。ただし、この機能を使用するには、機能するKerberosサーバが必要です。YaSTはKerberosサーバの設定は行いません。その提供機能を使用するだけです。YaST環境設定に加えて、Kerberos認証も使用するには、NFS設定を実行する前に、少なくとも次の手順を完了してください。

Kerberos認証でも、サーバでidmapdデーモンが実行されている必要があります。詳細については、/etc/idmapd.confを参照してください。

Kerberos化されたNFSの設定の詳細については、19.6項 「詳細情報」のリンクを参照してください。

認証されたユーザは、YaST NFSクライアントモジュールを使用して、NFSディレクトリをNFSサーバからローカルファイルツリーにマウントできます。以下に手順を示します。

設定は/etc/fstabに書かれ、指定されたファイルシステムがマウントされます。後でYaST設定クライアントを起動した時に、このファイルから既存の設定が取得されます。

ヒント: ルートファイルシステムとしてのNFS

ルートパーティションがネットワーク経由でNFS共有としてマウントされている(ディスクレス)システムでは、NFS共有にアクセス可能なネットワークデバイスの設定を慎重に行う必要があります。

システムの停止、システムの再起動時のデフォルトの処理順序は、ネットワーク接続を切断してから、ルートパーティションをアンマウントするという順序になります。NFSルートの場合、この順序では問題が発生します。NFS共有とのネットワーク接続が先に無効にされているため、ルートパーティションを正常にアンマウントできないためです。システムが該当するネットワークデバイスを無効にしないようにするには、[network device configuration(ネットワークデバイスの設定)]タブ(19.4.1.2.5項 「ネットワークデバイスの有効化」を参照)を開いて、デバイスの起動ペインのNFSrootオンを選択します。

NFSサーバからファイルシステムを手動でインポートするには、RPCポートマッパーが実行していることが前提条件です。RPCポートマッパーを適切に起動するのはnfsサービスです。そのため、rootユーザとして「systemctl start nfs」を入力し、RPCポートマッパーを起動します。次に、mountを使用して、ローカルパーティションと同様に、リモートファイルシステムをファイルシステムにマウントできます。

tux > sudo mount HOST:REMOTE-PATHLOCAL-PATH

たとえば、nfs.example.comマシンからユーザディレクトリをインポートするには、次の構文を使用します。

tux > sudo mount nfs.example.com:/home /home

クライアントがNFSサーバに対して行うTCP接続の数を定義するには、mountコマンドのnconnectオプションを使用できます。1～16の間の任意の数を指定できます。ここで、1はマウントオプションが指定されていない場合のデフォルト値です。

nconnect設定は、特定のNFSサーバへの最初のマウントプロセス中にのみ適用されます。同じクライアントが同じNFSサーバにmountコマンドを実行する場合、すべてのすでに確立されている接続が共有されます。新しい接続は確立されません。nconnect設定を変更するには、特定のNFSサーバへの「すべての」クライアント接続をアンマウントする必要があります。次にnconnectオプションの新しい値を定義できます。

現在有効なnconnectの値は、mountの出力または/proc/mountsファイルで確認できます。マウントオプションに値がない場合は、マウント中にそのオプションは使用されず、デフォルト値の「1」が使用されます。

注記: nconnectによって定義されているものとは異なる接続数

最初のマウント後に接続を閉じたり開いたりすることができるため、実際の接続数は必ずしもnconnectの値と同じである必要はありません。

/nfsmounts /etc/auto.nfs

localdata -fstype=nfs server1:/data
nfs4mount -fstype=nfs4 server2:/

19.4.2.2 /etc/fstabの手動編集 #

 

/etc/fstab内の典型的なNFSv3マウントエントリは、次のようになります:。

nfs.example.com:/data /local/path nfs rw,noauto 0 0

NFSv4マウントの場合は、3番目の列でnfsの代わりにnfs4を使用します。

nfs.example.com:/data /local/pathv4 nfs4 rw,noauto 0 0

noautoオプションを使用すると、起動時にファイルシステムが自動マウントされません。対応するファイルシステムを手動でマウントする場合は、マウントポイントのみを指定してmountコマンドを短くできます。

tux > sudo mount /local/path

注記: 起動時にマウント

ただし、noautoオプションを入力しないと、起動時に、システムのinitスクリプトによって、それらのファイルシステムがマウントされます。

NFSは、1980年代に開発された、もっとも古いプロトコルの1つです。そのため、小さなファイルを共有したい場合は、通常、NFSで十分です。しかし、大きなファイルを送信したい場合や多数のクライアントがデータにアクセスしたい場合は、NFSサーバがボトルネックとなり、システムのパフォーマンスに重大な影響を及ぼします。これはファイルのサイズが急速に大きくなっているのに対し、Ethernetの相対速度が追い付いていないためです。

通常のNFSサーバにファイルを要求すると、サーバはファイルのメタデータを検索し、すべてのデータを収集して、ネットワークを介してクライアントに送信します。しかし、ファイルが小さくても大きくてもパフォーマンスのボトルネックが問題になります。

pNFS(パラレルNFS)は、ファイルシステムメタデータをデータの場所から分離することによって、この制限を克服します。このため、pNFSには2種類のサーバが必要です。

メタデータサーバとストレージサーバによって、単一の論理NFSサーバが構成されます。クライアントが読み込みまたは書き出しを行う場合、メタデータサーバがNFSv4クライアントに対して、ファイルのチャンクにアクセスするにはどのストレージサーバを使用すればよいかを指示します。クライアントはサーバのデータに直接アクセスできます。

SUSE Linux Enterprise Serverはクライアント側でのみpNFSをサポートします。

tux > sudo mount -t nfs4 -o minorversion=1 MDS_SERVER MOUNTPOINT

tux > sudo echo 32767 > /proc/sys/sunrpc/nfsd_debug
tux > sudo echo 32767 > /proc/sys/sunrpc/nfs_debug

場合によっては、生成されたエラーメッセージを読み、/var/log/messagesファイルを調べることでNFSの問題を理解することができます。ただし、多くの場合、エラーメッセージや/var/log/messagesで提供される情報は十分に詳しいものではありません。このような場合、NFSのほとんどの問題は、問題の再現中にネットワークパケットをキャプチャすることでよく理解することができます。

問題を明確に定義します。さまざまな方法でシステムをテストし、問題の発生時期を特定して問題を調べます。問題につながる最も簡単なステップを特定します。その後、次の手順で示すように、問題を再現してみます。

重要: 高度なデバッグは専門家向けです

次のセクションは、NFSコードを理解している熟練したNFS管理者のみを対象としていることを念頭に置いてください。したがって、19.7.1項 「一般的なトラブルシューティング」に記載されている最初のステップを実行して問題絞り込み、詳細を理解するために必要なデバッグコード(ある場合)の領域を専門家に知らせます。

追加のNFS関連の情報を収集するために有効にすることが可能なデバッグコードのさまざまな領域があります。ただし、デバッグメッセージは非常にわかりにくく、これらのボリュームは非常に大きいため、デバッグコードを使用するとシステムパフォーマンスに影響を及ぼす可能性があります。問題が発生しないようにするためにシステムに大きな影響を及ぼす場合もあります。ほとんどの場合、デバッグコードの出力は必要ありません。また、NFSコードに精通していないユーザにとっては通常は役に立ちません。

rpcdebug -m module -s flags

rpcdebug -m module -c flags

man 8 rpcdebug

MOUNTD_OPTIONS=""

MOUNTD_OPTIONS="-d all"

man 8 rpc.mountd

systemctl restart nfsserver  # for nfs server related changes
systemctl restart nfs  # for nfs client related changes