SMB（CIFS）、拡張グループを使用した NFSv3、セキュリティ プリンシパルを使用する NFSv4 などのファイル共有プロトコルは、外部ディレクトリ サービスを使用してユーザー ID 情報を提供します。NetApp Volumes は、ディレクトリ サービスに Microsoft Active Directory を使用します。Active Directory は、オブジェクト（ユーザー、グループ、マシン アカウントなど）の検索用の LDAP サーバー、ホスト名を解決する DNS サーバー、認証用の Kerberos サーバーなどのサービスを提供します。
詳細については、Google Cloud で Active Directory を実行するためのベスト プラクティスをご覧ください。
Google Cloud のマネージド Microsoft Active Directory は、NetApp Volumes ではサポートされていません。
ユースケース
NetApp Volumes は、以降のセクションのケースで Active Directory を使用します。
SMB ドメイン サービス
Active Directory は SMB の中央ドメイン サービスです。SMB は、ユーザーとグループの認証と ID 検索に使用されます。NetApp Volumes はメンバーとしてドメインに参加します。また、ワークグループ モードの SMB はサポートしていません。
NFSv3 拡張グループのサポート
拡張グループをサポートする NFSv3 の場合、Active Directory は、ユーザー、グループ、マシン アカウントなどのオブジェクトの検索に必要な LDAP サーバーを用意します。具体的には、ユーザー ID とグループ ID の検索には RFC2307bis 準拠の LDAP サーバーが必要です。LDAP サポートは、プールの作成時にストレージ プールで有効になります。
拡張グループのサポートでは、NFS 呼び出しで NFS クライアントから送信されたすべてのグループ ID が無視されます。代わりに、リクエストのユーザー ID を取得し、LDAP サーバーから指定されたユーザー ID のすべてのグループ ID を検索して、ファイル権限チェックを行います。
詳細については、LDAP RFC2307bis POSIX 属性を管理するをご覧ください。
NFSv4.x セキュリティ プリンシパルとユーザー ID およびグループ ID のマッピング
NFSv4.x では、Active Directory を使用してセキュリティ プリンシパルをユーザー ID とグループ ID にマッピングします。NFSv4 はプリンシパルベースの認証モデルを使用します。プリンシパルベースの認証では、ユーザーはユーザー ID とグループ ID ではなく、user@dns_domain 形式のセキュリティ プリンシパルによって識別されます（https://www.rfc-editor.org/rfc/rfc7530.html#section-19 をご覧ください）。NFSv4.x プロトコルを使用してボリュームにアクセスするときにセキュリティ プリンシパルをユーザー ID とグループ ID にマッピングするには、NetApp Volumes に RFC2307bis 準拠の LDAP サーバーが必要な場合があります。サポートされている LDAP サーバーは Active Directory のみです。LDAP サポートは、プールの作成時にストレージ プールで有効になります。
セキュリティ プリンシパルを使用するには、NFS クライアントとサーバーが同じ LDAP ソースに接続し、クライアントで idmapd.conf ファイルを構成する必要があります。idmapd.conf ファイルの構成の詳細については、Ubuntu マニュアルページ: idmapd.conf - libnfsidmap の構成ファイルをご覧ください。
Active Directory ドメイン名は dns_domain に使用されます。user は、Active Directory ユーザーの名前です。これらの値は、LDAP POSIX 属性を設定するときに使用します。
ID マッピングを設定せずに NFSv4.1 を使用し、NFSv3 と同様にユーザー ID とグループ ID のみを使用するには、数値 ID を使用してセキュリティ プリンシパルを無視できます。NetApp Volumes は数値 ID をサポートしています。ID マッピングが構成されていない場合、現在の NFS クライアントはデフォルトで数値 ID を使用します。
Kerberos を使用した NFSv4.x
Kerberos を使用する場合は、セキュリティ プリンシパルの検索に Active Directory を LDAP サーバーとして使用する必要があります。Kerberos プリンシパルはセキュリティ ID として使用されます。Active Directory は、Kerberos Key Distribution Center（KDC）としても使用されます。これを実現するには、Kerberos 設定を含む Active Directory ポリシーをプールに接続し、プールの作成時にストレージ プールで LDAP サポートを有効にする必要があります。
詳細については、ストレージ プールを作成するをご覧ください。
Active Directory LDAP アクセス
NFS のユースケースでは、Active Directory が LDAP サーバーとして使用されます。NetApp Volumes は、RFC2307bis スキーマを使用する ID データを想定しています。Active Directory にはすでにこのスキーマが用意されていますが、ユーザーとグループに必要な属性を必ず入力する必要があります。
NetApp Volumes は、Active Directory ポリシーから提供された認証情報を使用して、LDAP 署名を使用して LDAP にバインドします。
ユーザーまたはグループが見つからない場合は、アクセスが拒否されます。
属性のキャッシュ保存
NetApp Volumes は、LDAP クエリの結果をキャッシュに保存します。次の表に、LDAP キャッシュの有効期間（TTL）の設定を示します。修正しようとしている構成ミスによりキャッシュに無効なデータが保持されている場合は、キャッシュが更新されるまで待ってから、Active Directory の変更が検出されるようにする必要があります。更新しなかった場合、NFS サーバーは引き続き古いデータを使用してアクセスを検証するため、クライアントで権限が拒否されたというメッセージが表示される可能性があります。TTL 期間が経過すると、エントリは期限切れになり、古いエントリが残留しないようにします。見つからなかったルックアップ リクエストは、パフォーマンスの問題を回避するために 1 分間の TTL で保持されます。
| キャッシュ | デフォルトのタイムアウト |
|---|---|
| グループ メンバーシップ リスト | 24 時間の TTL |
| Unix グループ（GID） | 24 時間の TTL、1 分間のネガティブ TTL |
| Unix ユーザー（UID） | 24 時間の TTL、1 分間のネガティブ TTL |
Active Directory ドメイン コントローラのトポロジ
Active Directory ドメイン コントローラに正常に接続すると、次のファイル共有プロトコルを使用できます。
- SMB
- 拡張グループを使用した NFSv3
- NFSv4
以降のセクションでは、考えられるさまざまなトポロジについて説明します。図には、NetApp Volumes で使用されるドメイン コントローラのみが表示されています。同じドメインの他のドメイン コントローラは、必要な場合にのみ表示されます。
冗長性と可用性を確保するため、少なくとも 2 つのドメイン コントローラ（DC）をデプロイすることをおすすめします。
NetApp Volumes ボリュームと同じリージョンにある Active Directory ドメイン コントローラ
次の図は、最も単純なデプロイモード（NetApp Volumes ボリュームと同じリージョンにあるドメイン コントローラ）を示しています。
AD サイトを使用する複数のリージョンの Active Directory ドメイン コントローラ
複数のリージョンで NetApp Volumes ボリュームを使用している場合は、各リージョンに少なくとも 1 つのドメイン コントローラを配置することをおすすめします。このサービスは、使用する最適な DC を自動的に選択しようとしますが、AD サイトを使用して DC の選択を管理することをおすすめします。
オンプレミス ネットワーク内の Active Directory ドメイン コントローラ
VPN を介したオンプレミス ドメイン コントローラの使用はサポートされていますが、エンドユーザーの認証とファイル アクセスのパフォーマンスに悪影響を及ぼす可能性があります。ネットワーク パスに VPC ピアリング ホップを追加しないようにしてください。
オンプレミス DC に関する考慮事項
オンプレミス DC への接続には TCP と IP が使用されます。これらの接続は、次の制限により失敗することがよくあります。
VPC ピアリング: NetApp ボリュームは、ストレージ プールの VPC 上にある DC または VPN で VPC に接続されている DC にのみ到達できます。NetApp ボリュームは、ストレージ プールに接続する VPC にピアリングされている VPC を含む、他の VPC 内の DC に到達できません。
ファイアウォール: NetApp Volumes が DC に接続できるようにする必要があります。Active Directory アクセスのファイアウォール ルールをご覧ください。
別の VPC ネットワーク内の Active Directory ドメイン コントローラ
Google Cloud VPC ピアリングでは推移的ルーティングが許可されていないため、ドメイン コントローラを別の VPC に配置することはできません。または、Active Directory ドメイン コントローラをホストする共有 VPC ネットワークに NetApp ボリュームをアタッチすることもできます。NetApp ボリュームを共有 VPC ネットワークに接続する場合、アーキテクチャ的には、このシナリオは前のセクションのシナリオの 1 つになります。
AD サイトを使用して DC の選択を管理する
実際のデータセンターのロケーション、オフィス、ネットワーク トポロジをできるだけ正確に表すには、ドメイン コントローラをボリュームと同じリージョンに配置し、そのリージョンの Active Directory サイトを定義します。
NetApp Volumes がドメインに接続されている場合、このサービスは DNS ベースの検出を使用して、通信する適切なドメイン コントローラを見つけます。検出結果を使用して、サービスは接続する有効な DC のリストを維持し、レイテンシが最も低い DC を使用します。
NetApp Volumes の Active Directory 設定でサイトを指定すると、DC のリストを AD サイトで指定されたものに制限できます。
DC の自動選択に失敗した場合は、AD サイトを使用して問題を解決できます。
NetApp Volumes リージョンにドメイン コントローラを 1 つ以上デプロイし、既存の Active Directory に接続します。
Google Cloud リージョンの Active Directory サイトを作成し、適切なドメイン コントローラをそのサイトに配置します。
Active Directory 接続を設定する場合は、Active Directory サイトを使用します。
サービスで使用できる可能性のある DC のリストを手動で確認するには、NetApp Volumes で使用される Active Directory ドメイン コントローラを特定する方法をご覧ください。
詳細については、Active Directory: 設計上の考慮事項とベスト プラクティスをご覧ください。