このページでは、NFS クライアントを接続する方法について説明します。
始める前に
Linux ディストリビューションのタイプに基づいて NFS クライアント ツールをインストールし、クライアントを準備します。
Red Hat
次のコマンドを実行します。
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 0 は 0 のままになります。ベスト プラクティスとして、信頼できる管理者ホストの root アクセスを有効にし、他のすべてのクライアントの root アクセスを無効にする専用のエクスポート ルールを作成します。
Kerberos を使用した NFSv4.1
Kerberos を使用する NFSv4.1 は、エクスポート ポリシーと Kerberos を使用した追加の認証を使用してボリュームにアクセスします。次の対象に適用するエクスポート ルールを構成できます。
Kerberos のみ（
krb5）Kerberos 署名（
krb5i）Kerberos プライバシー（
krb5p）
エクスポート ポリシーのベスト プラクティス
エクスポート ポリシーには、次のベスト プラクティスをおすすめします。
エクスポート ルールを最も具体的なものから最も具体的でないものまで順に並べます。
信頼できるクライアント（特定のクライアントや、信頼できるクライアントを含む CIDR など）にのみエクスポートします。
ルートアクセスを信頼できる少数の管理クライアントに制限します。
| ルール | 許可されたクライアント | アクセス | ルートアクセス権 | 説明 |
|---|---|---|---|---|
| 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 ファイルレベルのアクセス制御をご覧ください。
NFS クライアントのマウント手順
Google Cloud コンソールまたは Google Cloud CLI を使用して NFS クライアントのマウント手順を取得するには、次の操作を行います。
コンソール
Google Cloud コンソールで、[NetApp Volumes] ページに移動します。
[ボリューム] をクリックします。
[さらに表示] をクリックします。
[取り付け手順] を選択します。
Google Cloud コンソールに表示されるマウント手順に沿って操作します。
ワークロードに特定のマウント オプションの要件がない限り、マウント コマンドを特定してマウント オプションを使用します。
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 のドキュメントをご覧ください。
NFSv4.1 の追加の手順
NFSv4.1 を有効にすると、サービスレベルが Standard、Premium、Extreme のボリュームでも NFSv4.2 が自動的に有効になります。マウントするバージョンを指定しない限り、Linux のマウント コマンドは常に使用可能な最新の NFS バージョンをマウントします。NFSv4.1 でマウントする場合は、マウント コマンドで -o vers=4.1 パラメータを使用します。
NFSv3 では、ユーザーとグループは NFSv3 プロトコルで送信されるユーザー ID（UID）とグループ ID（GID）で識別されます。同じ UID と GID が、ボリュームにアクセスするすべてのクライアントで同じユーザーとグループを表すようにすることが重要です。NFSv4 では、セキュリティ識別子を使用することで、UID と GID の明示的なマッピングが不要になりました。セキュリティ識別子は <username|groupname>@<full_qualified_domain> という形式の文字列です。セキュリティ ID の例は bob@example.com です。クライアントは、内部で使用される UID と GID をセキュリティ ID に変換してから、NFSv4 リクエストをサーバーに送信する必要があります。サーバーは、受信リクエストのセキュリティ ID を UID と GID に変換し、レスポンスではその逆の変換を行う必要があります。変換を使用する利点は、すべてのクライアントとサーバーが異なる内部 UID と GID を使用できることです。ただし、すべてのクライアントとサーバーで UID と GID、ユーザー名とグループ名のマッピング リストを維持する必要があるというデメリットがあります。クライアントのマッピング情報は、/etc/passwd や /etc/groups などのローカル ファイル、または LDAP ディレクトリから取得できます。このマッピングの構成は rpc.idmapd によって管理されます。rpc.idmapd はクライアントで実行する必要があります。
NetApp ボリュームでは、LDAP はマッピング情報を提供する必要があります。Active Directory は、唯一サポートされている RFC2307bis 互換 LDAP サーバーです。NFSv4 で Kerberos を使用する場合、セキュリティ ID は Kerberos プリンシパルを username@DOMAINNAME 形式で保存します。ここで、DOMAINNAME（大文字）はレルム名になります。
数値 ID
名前マッピングを構成せずに NFSv3 の代替として NFSv4 を使用するユーザー向けに、NFSv4 では numeric ID というオプションが導入されました。このオプションは、UID と GID のエンコードされたテキスト文字列をセキュリティ 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 を構成します。
クライアントで
/etc/idmapd.confファイルを開き、ドメイン パラメータを次のいずれかに変更します。ボリュームで LDAP が有効になっていない場合、
domain = defaultv4iddomain.com。LDAP でボリュームが有効になっている場合、
domain = <FDQN_of_Windows_Domain>。
次のコマンドを実行して、
rpc.idmapdの変更を有効にします。nfsidmap -c
NFSv4.2 のサポート
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 の使用と制限事項も適用されます。
Linux を LDAP に接続する
NFSv3 拡張グループまたは NFSv4.1 をセキュリティ ID とともに使用している場合は、ストレージ プールに接続された Active Directory を使用して、Active Directory を LDAP サーバーとして使用するように NetApp Volumes を構成しました。
NFS クライアントとサーバー間でユーザー情報を一貫して維持するには、ユーザーとグループの情報に Active Directory を LDAP ネーム サービスとして使用するようにクライアントを構成する必要があります。
次のリソースを使用して LDAP を構成します。
Kerberized NFS を使用する場合は、このセクションで説明したデプロイガイドを使用して LDAP を構成し、クライアントとサーバー間の整合性を確保する必要があります。
次のステップ
複数のストレージ エンドポイントを使用して大容量ボリュームを接続します。