NFS クライアントを接続する

このページでは、NFS クライアントを接続する方法について説明します。

始める前に

ファイアウォールを使用してネットワーク トラフィックを制御し、NFS トラフィックを許可する場合は、 NFS ボリューム アクセス用のファイアウォール ルールをご覧ください。

Linux ディストリビューションのタイプに基づいて NFS クライアント ツールをインストールし、クライアントを準備します。

RedHat

次のコマンドを実行します。

sudo yum install -y nfs-utils

SuSe

次のコマンドを実行します。

sudo yum install -y nfs-utils

Debian

次のコマンドを実行します。

sudo apt-get install nfs-common

Ubuntu

次のコマンドを実行します。

sudo apt-get install nfs-common

エクスポート ポリシーを使用したボリューム アクセス制御

NFSv3 と NFSv4.1 のボリューム アクセス制御は、クライアントの IP アドレスに基づいています。ボリュームのエクスポート ポリシーには、最大 20 個のエクスポート ルールが含まれています。各ルールは、ボリュームのマウントを有効にする許可されたクライアント を定義する IP またはネットワーク CIDR のカンマ区切りのリストです。ルールでは、クライアントが持つアクセスの種類（読み取り / 書き込み または読み取り専用 など）も定義します。

次のタブを使用して、NFS バージョンに基づくポリシーを確認します。

Kerberos を使用しない NFS

Kerberos を使用しないすべての NFS バージョンでは、AUTH_SYS セキュリティ フレーバーが使用されます。このモードでは、信頼できるクライアントのみを許可し、ユーザー ID とグループ ID の整合性を確保できるように、エクスポート ルールを厳密に管理する必要があります。

セキュリティ対策として、NFS サーバーは UID=0（root）の NFS 呼び出しを UID=65534（匿名）に自動的にマッピングします。これにより、ファイル システムに対する権限が制限されます。詳細については、ユーザー ID のスカッシュをご覧ください。

Kerberos を使用する NFSv4.1

Kerberos を使用する NFSv4.1 では、エクスポート ポリシーと Kerberos を使用した追加の認証を使用してボリュームにアクセスします。エクスポート ルールを構成して、次のものに適用できます。

• Kerberos のみ（krb5）

• Kerberos 署名（krb5i）

• Kerberos プライバシー（krb5p）

エクスポート ポリシーのベスト プラクティス

エクスポート ポリシーには、次のようなベスト プラクティスがあります。

• エクスポート ルールを、最も具体的なものから最も具体的でないものに並べます。

• 信頼できるクライアント（特定のクライアントや、信頼できるクライアントを含む CIDR など）にのみエクスポートします。

• root アクセスを、信頼できる管理クライアントの小さなグループに制限します。

ルール	許可されたクライアント	アクセス	ルートアクセス権	説明
1	10.10.5.3、 10.10.5.9	読み取り / 書き込み	オン	管理クライアント。root ユーザーは root のままで、 すべてのファイル権限を管理できます。
2	10.10.5.0/24	読み取り / 書き込み	オフ	10.10.5.0/24 ネットワークの他のすべてのクライアントはマウントできますが、 root アクセスは nobody にマッピングされます。
3	10.10.6.0/24	読み取り専用	オフ	別のネットワークはボリュームからデータを読み取ることができますが、 書き込みはできません。

クライアントがボリュームをマウントすると、ファイルレベルのアクセスによってユーザーが実行できる操作が 決まります。詳細については、UNIX スタイルのボリュームの NFS ファイルレベルのアクセス制御をご覧ください。

エクスポート ポリシーを管理する

Google Cloud CLI を使用してボリュームのエクスポート ポリシーを更新する手順は次のとおりです。

gcloud

1 つのエクスポート ポリシーでボリュームを更新する

1 つのエクスポート ポリシールールでボリュームを更新します。

gcloud netapp volumes update VOLUME_ID \
  --project=PROJECT_ID \
  --location=LOCATION \
  --export-policy=access-type=ACCESS_TYPE,allowed-clients=ALLOWED_CLIENTS_IP_ADDRESSES,has-root-access=TRUE_OR_FALSE,nfsv3=NFSV3,nfsv4=NFSV4

次の情報を置き換えます。

• VOLUME_ID: ボリュームの ID。

• PROJECT_ID: ボリュームが存在するプロジェクトの名前。

• LOCATION: ボリュームのロケーション。

• ACCESS_TYPE: アクセスタイプは、READ_WRITE、READ_ONLY、READ_NONE のいずれかである必要があります。

• ALLOWED_CLIENTS_IP_ADDRESSES: 許可されたクライアントの IP アドレスまたは範囲のカンマ区切りリスト。

• NFSV3: このルールを NFSv3 に適用する場合は true、適用しない場合は false に設定します。

• NFSV4: このルールを NFSv4 に適用する場合は true、適用しない場合は false に設定します。

複数のエクスポート ポリシールールを追加する

複数のエクスポート ルールを追加するには、export-policy パラメータ ブロックを繰り返します。 各 export-policy パラメータ ブロックは、次の形式の複数の Key-Value ペアで構成されます。

--export-policy=KEY1=VALUE1,KEY2=VALUE2,KEY3=VALUE3...

例: コロンとカンマを区切り文字として使用する

allowed-clients に複数の IP アドレスまたは CIDR を指定すると、--export-policy フラグは access-type や nfsv3 などの異なるキーのデフォルトの区切り文字としてカンマを使用するため、Google Cloud CLI が値を正しく解析できないことがあります。allowed-clients などの値にカンマが含まれている場合、パーサーは新しい Key-Value ペアと allowed-clients リスト内の追加の IP アドレスを区別できません。これらのカンマを区別するには、Google Cloud CLI エスケープを使用して、別のパラメータ区切り文字を使用するように Google Cloud CLI を構成します。

次のコマンドは、 エクスポート ポリシーのベスト プラクティスの例を示しています。 最初のルールでは、パラメータ区切り文字としてコロンを使用して、カンマ区切りの allowed-clients リストを正しく解析します。2 番目と 3 番目のルールでは、デフォルトのカンマを区切り文字として使用します。

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^access-type=READ_WRITE:allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:nfsv4=true:has-root-access=true \
--export-policy=access-type=READ_WRITE,allowed-clients=10.0.5.0/24,nfsv3=true,has-root-access=false \
--export-policy=access-type=READ_ONLY,allowed-clients=10.0.6.0/24,nfsv3=true,has-root-access=false

例: squash-mode をパラメータとして使用する

次の例では、代替の squash-mode パラメータを使用して、管理者ホストの NO_ROOT_SQUASH ルールと CIDR の範囲の ALL_SQUASH ルールを作成します。

gcloud netapp volumes update my_volume --location=us-east4 \
--export-policy=^:^allowed-clients="10.10.5.3,10.10.5.9":nfsv3=true:access-type=READ_WRITE:squash-mode=NO_ROOT_SQUASH \
--export-policy=allowed-clients=10.0.2.0/24,nfsv3=true,access-type=READ_WRITE,squash-mode=ALL_SQUASH,anon-uid=2000

その他のオプション フラグの詳細については、 ボリューム エクスポート ポリシーの Google Cloud SDK をご覧ください。

ユーザー ID のスカッシュ

NFS エクスポート ポリシーには、ユーザー ID とグループ ID のスカッシュを制御する機能があります。これにより、セキュリティ上の理由から、ユーザー ID と グループ ID を匿名ユーザー ID に再マッピングできます。

ルート スカッシュ

NFS サーバーは、root ユーザー（UID=0）を nobody（UID=65534）に再マッピングすることでセキュリティを強化します。これにより、root はボリューム上のファイル アクセスに対する権限のないユーザーになります。この機能は、 ルート スカッシュと呼ばれます。この機能を無効にして root の権限を保持するオプションは、NFS サーバーでは no_root_squash と呼ばれます。

デフォルトでは、エクスポート ポリシーが定義されていないボリュームには、クライアント IP アドレスからアクセスできません。コンソールでエクスポート ポリシールールを作成すると、デフォルトの設定には読み取り / 書き込み アクセスとルート スカッシュ が含まれます。 Google Cloud 以前は、 Google Cloud API、Google Cloud CLI、Terraform で パラメータを使用してルート スカッシュを制御できました。has-root-accesshas-root-access は引き続き使用できますが、squash-mode パラメータに置き換えられました。

効果的な手法として、信頼できる管理者ホストの root アクセスを有効にし、他のクライアントの root アクセスを無効にする専用のエクスポート ルールを作成します。このルールは、より一般的なルールの前に配置します。

ユーザー ID とグループ ID のスカッシュ

squash-mode パラメータを使用すると、ユーザー ID とグループ ID の両方を匿名 UID にスカッシュできます。これは、公開 SFTP ドロップボックス ディレクトリに便利です。このパラメータは has-root-access パラメータも置き換え、API、Google Cloud CLI、Terraform でサポートされています。

squash-mode パラメータは次の値を受け入れます。

• no-root-squash: このモードでは、root ユーザーは root のままで、nobody（UID=65534）に再マッピングされません。

• root-squash: この設定では、root ユーザーが nobody に再マッピングされます。

• all-squash: このオプションを使用すると、root を含むすべてのユーザーが匿名でアクセスできます。すべてのユーザーは、anon-uid パラメータで指定された UID と GID に再マッピングされます。all-squash を使用する場合は、anon-uid も指定し、access-type を READ_WRITE に設定する必要があります。

考慮事項

squash mode を使用したエクスポート ポリシールールについては、次の点を考慮してください。

• エクスポート ポリシーでサポートされる all-squash ルールは 1 つのみです。

• all-squash が有効になっている場合、root ユーザーは匿名にスカッシュされます。これは、no-root-squash を使用する優先度の高いルールでオーバーライドできます。

• ボリュームのレプリケーションは、squash-mode スタイルのエクスポート ポリシールールを持つボリュームではサポートされていません。

• Flex File サービスレベルの場合、all-squash はボリュームの root inode の所有権を自動的に変更しません。これを行うには、no-root-squash エクスポート ルールを追加して、root ユーザーが chown を使用して root inode の所有権を必要な UID に変更できるようにします。

• has-root-access パラメータがサポートされています。has-root-access または squash-mode のいずれかを使用します。両方のパラメータを同時に使用しないでください。

• Flex Unified サービスレベルでは、all-squash はサポートされていません。

NFS クライアントのマウント手順

コンソール、Google Cloud CLI、ONTAP モードのいずれかを使用して、NFS クライアントのマウント手順を取得する手順は次のとおりです。 Google Cloud

コンソール

1. コンソールの [NetApp Volumes] ページに移動します。 Google Cloud

   [NetApp Volumes] に移動

2. [ボリューム] をクリックします。

3. [**詳細を表示**] をクリックします。

4. [マウント手順] を選択します。

5. コンソールに表示されるマウント手順に沿って操作します。 Google Cloud

6. ワークロードに特定のマウント オプション要件がない限り、マウント コマンドを特定してマウント オプションを使用します。

   NFSv3 のみ: アプリケーションでロックを使用しない場合や、NSM 通信を有効にするようにクライアントを構成していない場合は、nolock マウント オプションを追加することをおすすめします。

gcloud

ボリュームのマウント手順を調べます。

 gcloud netapp volumes describe VOLUME_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --format="value(mountOptions.instructions)"

次の情報を置き換えます。

• VOLUME_NAME: ボリュームの名前。

• PROJECT_ID: ボリュームが存在するプロジェクトの名前。

• LOCATION: ボリュームのロケーション。

その他のオプション フラグの詳細については、 ボリュームに関する Google Cloud SDK のドキュメントをご覧ください。

ONTAP モード

ボリュームのホスト名または IP アドレスとエクスポート パスを特定する手順は次のとおりです。

1. すべてのネットワーク インターフェースを調べます data_cifs サービスの。

2. ボリュームに指定した ジャンクション パス に対応するエクスポート パスを特定します。

3. マウント パスを <var>IP</var>:<var>junction-path</var> の形式で作成します。必要なマウント オプションを追加します。

必要なコマンドを特定したら、ONTAP モード で ONTAP コマンドをストレージ プールに送信する方法をご覧ください。

NFSv4.1 の追加手順

Flex Unified、Standard、Premium、Extreme サービスレベルのボリュームで NFSv4.1 を有効にすると、これらのボリュームで NFSv4.2 が自動的に有効になります。マウントするバージョンを指定しない限り、Linux mount コマンドは常に使用可能な最新の NFS バージョンをマウントします。NFSv4.1 でマウントする場合は、mount コマンドで -o vers=4.1 パラメータを使用します。

NFSv3 では、ユーザーとグループは NFSv3 プロトコルで送信されるユーザー ID（UID）とグループ ID（GID）で識別されます。ボリュームにアクセスするすべてのクライアントで、同じ UID と GID が同じユーザーとグループを表していることを確認することが重要です。NFSv4 では、セキュリティ識別子を使用することで、明示的な UID と GID のマッピングが不要になりました。 セキュリティ識別子は、<username|groupname>@<full_qualified_domain>. の形式の文字列です。セキュリティ識別子の例は [e-mail] です。 クライアントは、NFSv4 リクエストをサーバーに送信する前に、内部で使用される UID と GID をセキュリティ 識別子に変換する必要があります。サーバーは、受信リクエストのセキュリティ識別子を UID と GID に変換し、レスポンスの場合はその逆を行う必要があります。変換を使用する利点は、すべてのクライアントとサーバーが異なる内部 UID と GID を使用できることです。 ただし、すべてのクライアントとサーバーで、UID と GID、ユーザー名とグループ名のマッピング リストを維持する必要があります。クライアントのマッピング情報は、/etc/passwd や /etc/groups などのローカル ファイルまたは LDAP ディレクトリから取得できます。このマッピングの構成は rpc.idmapd によって管理されます。これはクライアントで実行する必要があります。

NetApp Volumes では、LDAP はマッピング情報を提供する必要があります。Active Directory は、RFC2307bis 互換の LDAP サーバーとして唯一サポートされています。 NFSv4 で Kerberos を使用する場合、セキュリティ識別子は Kerberos プリンシパルを username@DOMAINNAME の形式で保存します。ここで、DOMAINNAME（大文字）はレルム名になります。

数値 ID

名前マッピングを構成せずに NFSv3 の代わりに NFSv4 を使用するユーザー向けに、NFSv4 では numeric ID というオプションが導入されました。このオプションでは、UID と GID でエンコードされたテキスト文字列がセキュリティ識別子として送信されます。これにより、ユーザーの構成プロセスが簡素化されます。

**注:** 最新の Linux ディストリビューションでは、numeric ID オプションがデフォルトで有効になっています。

次のコマンドを使用して、クライアントの設定を確認できます。

     cat /sys/module/nfs/parameters/nfs4_disable_idmapping
   

デフォルト値は Y で、数値 ID が有効になります。NetApp Volumes は数値 ID の使用をサポートしています。

NFS クライアントで rpc.idmapd を構成する

使用する ID またはセキュリティ識別子の種類に関係なく、NFS クライアントで rpc.idmapd を構成する必要があります。始める前にセクションのクライアント ユーティリティのインストール手順に沿って操作した場合は、すでにインストールされているはずですが、実行されていない可能性があります。一部のディストリビューションでは、最初の NFS ボリュームをマウントするときに systemd を使用して自動的に起動します。rpc.idmapd に必要な最小限の構成は、ドメイン設定を行うことです。そうしないと、ユーザー root は UID=65534 or 4294967295 の nobody として表示されます。

次の手順で、NFS クライアントで rpc.idmapd を構成します。

1. クライアントでファイル /etc/idmapd.conf を開き、ドメイン パラメータを次のいずれかに変更します。

   • ボリュームで LDAP が有効になっていない場合は、domain = defaultv4iddomain.com。

   • ボリュームで LDAP が有効になっている場合は、domain = <FDQN_of_Windows_Domain>。

2. 次のコマンドを実行して、rpc.idmapd の変更を有効にします。

    nfsidmap -c

NFSv4.2 のサポート

Flex Unified、Standard、Premium、Extreme サービスレベルでは、NFSv4.1 がすでに有効になっているボリュームで、NFSv4.1 に加えて NFSv4.2 プロトコルがサポートされるようになりました。

NFS ボリュームをマウントすると、Linux mount コマンドは使用可能な最新の NFS バージョンを自動的に選択します。vers=4.1 マウント オプションが明示的に指定されていない限り、NFSv4.1 が有効なボリュームをマウントすると、デフォルトで NFSv4.2 になります。

NetApp Volumes は、NFSv4.2 で NFS 拡張属性 xattrs をサポートしています。 TR-4962 で説明されている xattrs の使用方法と制限事項も適用されます。

NFS ボリューム アクセス用のファイアウォール ルール

NFS は、クライアントとサーバー間の通信に複数のポートを使用します。Google Compute Engine と NetApp Volumes 間の通信では、これらのポートはデフォルトでブロックされません。ファイアウォールを使用する場合は、 NetApp Volume PSA CIDR 全体または個々のボリューム IP アドレスに対して、次のポートへのアクセスを有効にする必要があります。

• 111 TCP/UDP portmapper

• 635 TCP/UDP mountd

• 2049 TCP/UDP nfsd

• 4045 TCP/UDP nlockmgr（NFSv3 のみ）

• 4046 TCP/UDP status（NFSv3 のみ）

NetApp Volumes の IP アドレスは、ネットワーク ピアリング時にサービスに割り当てた CIDR の範囲から自動的に割り当てられます。詳細については、プライベート サービス アクセスを構成するをご覧ください。

NFSv3 でのアドバイザリ ロックの使用

NFSv3 でアドバイザリ ロックを使用する場合は、クライアントで rpc.statd デーモンを実行して Network Lock Manager をサポートする必要があります。Network Lock Manager は NFS と連携して、ネットワーク経由で System V スタイルのアドバイザリ ファイルとレコード ロックを提供します。NFS クライアントは、Network Lock Manager コールバックを受信するために、rpc.statd の受信ポートを開く必要があります。ほとんどの Linux ディストリビューションでは、最初の NFS 共有をマウントすると rpc.statd が起動します。rpcinfo -p コマンドを使用して特定できるランダムなポートを使用します。rpc.statd をファイアウォールと互換性を持たせるには、静的ポートを使用するように構成します。

rpc.statd の静的ポートを設定するには、次のリソースをご覧ください。

• Debian/Ubuntu

• SuSE

• RedHat

NFSv3 アドバイザリ ロックまたは Network Lock Manager を使用しない場合は、nolock マウント オプションを使用して NFSv3 共有をマウントできます。

NFSv4.1 は、NFSv4.1 プロトコル内でロック機能を実装します。このプロトコルは、ポート 2049 の NFSv4.1 サーバーへのクライアント開始 TCP 接続で実行されます。 クライアントは、受信トラフィック用にファイアウォール ポートを開く必要はありません。

Linux を LDAP に接続する

NFSv3 拡張グループまたはセキュリティ識別子を使用する NFSv4.1 を使用している場合は、ストレージ プールに接続された Active Directory を使用して、Active Directory を LDAP サーバーとして使用するように NetApp Volumes を構成します。

NFS クライアントとサーバー間でユーザー情報を一貫して維持するには、ユーザーとグループの情報に Active Directory を LDAP ネームサービスとして使用するようにクライアントを構成する必要があります。

LDAP を構成するには、次のリソースを使用します。

• Red Hat デプロイガイド

• Ubuntu デプロイガイド

• SUSE デプロイガイド

Kerberos 化された NFS を使用する場合は、このセクションで説明されているデプロイガイドを使用して LDAP を構成し、クライアントとサーバー間の一貫性を確保する必要があります。

次のステップ

複数のストレージ エンドポイントを使用して大容量ボリュームを接続する。