Azure NetApp Files での NAS プロトコルを理解する
NAS プロトコルは、クライアントとサーバーの間で行われる会話の方法です。 NFS と SMB は、Azure NetApp Files で使用される NAS プロトコルです。 それぞれ異なる独自の通信方法を提供しますが、その根本では、ほとんど同じように動します。
- どちらも、ネットワークに接続された多数の異種クライアントに 1 つのデータセットを提供します。
- どちらも、データを共有するための暗号化された認証方法を使用できます。
- どちらも、共有とファイルのアクセス許可を使用してゲートできます。
- どちらも、転送中のデータを暗号化できます。
- どちらも、パフォーマンスの並列化に役立てるために複数の接続を使用できます。
Network File System (NFS)
NFS は主に、Red Hat、SUSE、Ubuntu、AIX、Solaris、Apple OS などの Linux/UNIX ベースのクライアントで使用されます。 Azure NetApp Files は、RFC 標準で動作するすべての NFS クライアントをサポートしています。 Windows でもアクセスのために NFS を使用できますが、それはコメント要求 (RFC) 標準を使用して動作しません。
NFS プロトコル用の RFC 標準については、次を参照してください。
NFSv3
NFSv3 は、このプロトコルの基本的なオファリングであり、次の主要な属性があります。
- NFSv3 はステートレスです。つまり、NFS サーバーは、接続の状態 (ロックを含む) を追跡しません。
- ロックは、ネットワーク ロック マネージャー (NLM) を使用して NFS プロトコルの外部で処理されます。 このプロトコルにはロックが統合されていないため、古いロックが発生する場合があります。
- NFSv3 はステートレスであるため、一部のワークロード、特に OPEN、CLOSE、SETATTR、GETATTR などのメタデータ操作の多いワークロードでは NFSv3 でのパフォーマンスが大幅に向上する場合があります。 これは、サーバーやクライアントで要求を処理するために実行する必要のある一般的な作業が少ないためです。
- NFSv3 では、ファイルの所有者、グループ、その他のすべてのユーザーにのみ読み取り/書き込み/実行アクセス許可の組み合わせを割り当てることができる基本的なファイル アクセス許可モデルを使用します。
- NFSv3 では NFSv4.x ACL を使用できますが、ACL を構成して管理するには NFSv4.x 管理クライアントが必要になります。 Azure NetApp Files は、非標準の POSIX ドラフト ACL の使用をサポートしていません。
- NFSv3 ではまた、ポートの検出、マウント、ロック、状態の監視、クォータなどの通常の操作のために、他の補助的なプロトコルの使用も必要です。 補助的なプロトコルでは、それぞれ固有のネットワーク ポートを使用します。つまり、NFSv3 操作には、既知のポート番号を使用したファイアウォールによるより多くの露出が必要になります。
- Azure NetApp Files では、NFSv3 操作のために次のポート番号を使用します。 これらのポート番号を変更することはできません。
- ポートマッパー (111)
- マウント (635)
- NFS (2049)
- NLM (4045)
- NSM (4046)
- Rquota (4049)
- NFSv3 では Kerberos などのセキュリティ強化を使用できますが、Kerberos は、パケットの NFS の部分にのみ影響を与えます。補助的なプロトコル (NLM、ポートマッパー、マウントなど) は Kerberos の会話に含まれません。
- Azure NetApp Files は、NFSv4.1 Kerberos 暗号化のみをサポートしています。
- NFSv3 では、そのユーザーとグループの認証に数値 ID を使用します。 通信またはアクセス許可にはユーザー名とグループ名が必要ありません。これにより、ユーザーのスプーフィングが容易になる可能性がありますが、構成と管理は簡単になります。
- NFSv3 では、ユーザーとグループの検索に LDAP を使用できます。
NFSv3 サービス バージョンのサポート
NFSv3 では現在、Azure NetApp Files の各補助プロトコルの次のバージョンがサポートされています。
サービス | サポートされているバージョン |
---|---|
ポートマッパー | 4, 3, 2 |
NFS | 4, 3* |
Mountd | 3, 2, 1 |
Nlockmgr | 4 |
Status | 1 |
Rquotas | 1 |
* NFS でサポートされているバージョンは、Azure NetApp Files ボリュームに対して選択されたバージョンに基づいて表示されます。
この情報は、次のコマンドを使用して Azure NetApp Files ボリュームから収集できます。
# rpcinfo -s <Azure NetApp Files IP address>
NFSv4.x
NFSv4.x は、NFSv4 に属するすべての NFS バージョンまたはマイナー バージョン (NFSv4.0、NFSv4.1、NFSv4.2 を含む) を指します。 Azure NetApp Files では現在、NFSv4.1 のみをサポートしています。
NFSv4.x には、次の特性があります。
- NFSv4.x はステートフル プロトコルです。つまり、クライアントとサーバーは、NFS 接続の状態 (ロックの状態を含む) を追跡します。 NFS マウントでは、状態 ID” と呼ばれる概念を“使用して接続を追跡します。
- NFS プロトコルにロックが統合されているため、NFS のロックを追跡するために補助的なロック プロトコルは必要ありません。 代わりに、ロックがリースごとに許可されます。 これらのロックは、クライアントまたはサーバーの接続が失われると一定期間の後に有効期限が切れるため、他の NFS クライアントでの使用のためにシステムに返されます。
- NFSv4.x のステートフル性には、ネットワークの停止またはストレージ フェールオーバー中の中断の可能性や、特定のワークロードの種類での (高いメタデータ ワークロードなどの) パフォーマンスのオーバーヘッドなど、いくつかの欠点が含まれています。
- NFSv4.x には、NFSv3 に比べて、次のような多くの大きな利点があります。
- ロックの概念の向上 (リース ベースのロック)
- セキュリティの強化 (必要なファイアウォール ポートの減少、Kerberos との標準統合、きめ細かなアクセス制御)
- その他の機能
- 複合した NFS 操作 (ネットワーク トラフィックを削減するための 1 つのパケット要求での複数のコマンド)
- TCP のみ
- NFSv4.x では、Windows の NTFS アクセス許可と同様の、より堅牢なファイル アクセス許可モデルを使用できます。 これらのきめ細かな ACL はユーザーまたはグループに適用でき、基本的な読み取り/書き込み/実行操作より広範囲の操作に対してアクセス許可を設定できるようになります。 NFSv4.x ではまた、NFSv3 で採用されている標準の POSIX モード ビットも使用できます。
- NFSv4.x では補助的なプロトコルを使用しないため、使用中の NFS の会話全体に Kerberos が適用されます。
- NFSv4.x では、ユーザーまたはグループ名とドメイン文字列の組み合わせを使用してユーザーとグループの情報を確認します。 ユーザーとグループの適切な認証が実行されるようにするには、クライアントとサーバーがドメイン文字列に同意する必要があります。 ドメイン文字列が一致しない場合、NFS ユーザーまたはグループは、NFS クライアントの /etc/idmapd.conf ファイル内の指定されたユーザー (nobody など) にスカッシュされます。
- NFSv4.x は既定でドメイン文字列を使用するように設定されていますが、AUTH_SYS が使用中のときに、NFSv3 に見られる数値 ID にフォールバックするようにクライアントとサーバーを構成することもできます。
- NFSv4.x はユーザー名とグループ名の文字列と深く統合されており、サーバーとクライアントは、これらのユーザーとグループに同意する必要があります。 そのため、ユーザー認証には NFS クライアントおよびサーバーでの LDAP などのネーム サービス サーバーを使用することを検討してください。
Azure NetApp Files の NFS に関してよく寄せられる質問については、「Azure NetApp Files の NFS に関するよくあるご質問」を参照してください。
サーバー メッセージ ブロック (SMB)
SMB は主に、NAS 機能のために Windows クライアントで使用されます。 ただし、Linux ベースのオペレーティング システム (AppleOS や RedHat など) でも使用できます。このデプロイは、Samba という名前のアプリケーションを使用して実現されます。 Azure NetApp Files には、Windows と macOS を使用した SMB に対する公式サポートがあります。 Linux オペレーティング システム上の SMB/Samba は Azure NetApp Files で動作できますが、公式サポートはありません。
Azure NetApp Files は、SMB 2.1 と SMB 3.1 のバージョンのみをサポートしています。
SMB には、次の特性があります。
- SMB はステートフル プロトコルです。クライアントとサーバーは、セキュリティとロックの強化のために SMB 共有接続の "状態" を維持します。
- SMB でのロックは必須と見なされます。 ファイルがロックされている場合は、そのロックが解放されるまで、他のどのクライアントもそのファイルに書き込めません。
- SMBv2.x 以降では、複合呼び出しを使用して操作を実行します。
- SMB は、完全な Kerberos 統合をサポートしています。 Windows クライアントが構成される方法により、Kerberos は多くの場合、エンド ユーザーが知ることさえなく使用されています。
- Kerberos を認証に使用できない場合は、Windows NT LAN Manager (NTLM) をフォールバックとして使用できます。 Active Directory 環境で NTLM が無効になっている場合、Kerberos を使用できない認証要求は失敗します。
- SMBv3.0 以降では、SMB 共有に対してエンド ツー エンド暗号化がサポートされています。
- SMBv3.x では、特定のワークロードでのパフォーマンス向上のためにマルチチャンネルがサポートされています。
- SMB では、認証にユーザー名とグループ名を (SID 変換経由で) 使用します。 ユーザーとグループの情報は、Active Directory ドメイン コントローラーによって提供されます。
- Azure NetApp Files の SMB では、ファイルとフォルダーのアクセス許可に標準の Windows New Technology File System (NTFS) ACL を使用します。
Azure NetApp Files の SMB に関してよく寄せられる質問については、「Azure NetApp Files の SMB に関するよくあるご質問」を参照してください。
デュアル プロトコル
一部の組織には、すべてのデータが次のいずれかのアプローチのみを使用してアクセスされる純粋な Windows または純粋な UNIX 環境 (同種) があります。
- SMB および NTFS ファイル セキュリティ
- NFS および UNIX ファイル セキュリティ - モード ビットまたは NFSv4.x アクセス制御リスト (ACL)
ただし、多くのサイトでは、データ セットを Windows クライアントと UNIX クライアント (異種) の両方からアクセスできるようにする必要があります。 これらの要件を持つ環境のために、Azure NetApp Files には、ネイティブなデュアル プロトコル NAS サポートがあります。 ユーザーがネットワーク上で認証された後、適切な共有またはエクスポートのアクセス許可と必要なファイル レベルのアクセス許可の両方を持っている場合、そのユーザーは NFS を使用して UNIX ホストから、または SMB を使用して Windows ホストからデータにアクセスできます。
デュアル プロトコル ボリュームを使用する理由
Azure NetApp Files でデュアル プロトコル ボリュームを使用すると、いくつかの異なる利点が得られます。 クライアントが異なる NAS プロトコルを使用してデータ セットにシームレスかつ同時にアクセスできる場合は、次の利点を実現できます。
- ストレージ管理者の全体的な管理タスクが削減されます。
- 複数のクライアントの種類からの NAS アクセスのために格納する必要のあるデータのコピーは 1 つだけです。
- プロトコルに依存しない NAS により、ストレージ管理者は、エンド ユーザーに提供される ACL とアクセス制御のスタイルを制御できます。
- NAS 環境内の ID 管理操作が一元化されます。
デュアル プロトコル環境に関する一般的な考慮事項
デュアル プロトコル NAS アクセスは、その柔軟性のために、多くの組織にとって望ましいものです。 ただし、プロトコルにまたがる共有の概念に固有の一連の考慮事項が生み出される難しさが認識されています。 これらの考慮事項には次のものが含まれますが、これに限定されるわけではありません。
- 複数のプロトコル、オペレーティング システム、ストレージ システムにまたがる知識の要件。
- ネーム サービス サーバー (DNS や LDAP など) の実用的な知識。
さらに、次のような外部要因にも影響を受ける場合があります。
- 複数の部門や IT グループ (Windows グループと UNIX グループなど) の扱い
- 会社の買収
- ドメインの統合
- 再構成
これらの考慮事項にもかかわらず、デュアル プロトコル NAS の設定、構成、アクセスは簡単であり、あらゆる環境にシームレスに統合できます。
Azure NetApp Files でデュアル プロトコルの使用を簡略化する方法
Azure NetApp Files では、デュアル プロトコル NAS 環境の成功に必要なインフラストラクチャが、ストレージと ID の管理サービスを含む 1 つの管理プレーンに統合されます。
デュアル プロトコル構成は単純であり、クラウド オペレーターの操作を簡略化するために、ほとんどのタスクは Azure NetApp Files リソース管理フレームワークによってシールドされています。
Azure NetApp Files で Active Directory 接続が確立されたら、デュアル プロトコル ボリュームではその接続を使用して、Active Directory または LDAP サービス内で、通常のユーザーとグループの管理外で追加の構成手順を実行することなく、Azure NetApp Files ボリュームでのユーザーとグループの適切な認証に必要な Windows と UNIX の両方の ID 管理を処理できます。
Azure NetApp Files では、デュアル プロトコル構成のためのストレージ中心の追加の手順を削除することにより、Azure への移行を検討している組織のためにデュアル プロトコルのデプロイ全体を効率化します。
Azure NetApp Files デュアル プロトコル ボリュームのしくみ
大まかに言うと、Azure NetApp Files デュアル プロトコル ボリュームでは、名前のマッピングとアクセス許可のスタイルの組み合わせを使用して、使用されているプロトコルには関係なく一貫性のあるデータ アクセスを提供します。 つまり、NFS と SMB のどちらからファイルにアクセスしている場合でも、これらのファイルにアクセスできるユーザーがアクセスできることと、これらのファイルにアクセスできないユーザーがアクセスできないことが保証されます。
NAS クライアントが Azure NetApp Files のデュアル プロトコル ボリュームへのアクセスを要求した場合は、エンド ユーザーに透過的なエクスペリエンスを提供するために、次の操作が行われます。
- NAS クライアントでは、Azure NetApp Files デュアル プロトコル ボリュームへの NAS 接続を作成します。
- NAS クライアントは、Azure NetApp Files にユーザー ID 情報を渡します。
- Azure NetApp Files では、NAS クライアントまたはユーザーが NAS 共有にアクセスできることを確認します。
- Azure NetApp Files では、そのユーザーを受取り、それをネーム サービスで見つかった有効なユーザーにマップします。
- Azure NetApp Files では、そのユーザーをシステム内のファイル レベルのアクセス許可と比較します。
- ファイルのアクセス許可によって、ユーザーが可能なアクセスのレベルが制御されます。
次の図では、user1
は、SMB または NFS 経由でデュアル プロトコル ボリュームにアクセスするために Azure NetApp Files に対して認証します。 Azure NetApp Files では、Microsoft Entra ID でそのユーザーの Windows と UNIX の情報を見つけ、ユーザーの Windows と UNIX の ID を 1 対 1 でマップします。 このユーザーは user1
として検証され、user1
のアクセス資格情報を取得します。
この例では、user1
は自分のフォルダー (user1-dir
) でのフル コントロールを取得し、HR
フォルダーにはアクセスできません。 この設定はファイル システムで指定されているセキュリティ ACL に基づいており、どのプロトコルからボリュームにアクセスしているかには関係なく、user1
は予測されたアクセス権を取得します。
Azure NetApp Files デュアル プロトコル ボリュームに関する考慮事項
Azure NetApp Files ボリュームを SMB と NFS の両方へのアクセスに使用する場合は、次のいくつかの考慮事項が適用されます。
- Active Directory 接続が必要です。 そのため、Active Directory 接続の要件を満たす必要があります。
- デュアル プロトコル ボリュームの作成エラーを防止するために、デュアル プロトコル ボリュームには、AD ホスト マシンのポインター (PTR) レコードが関連付けられている DNS 内の逆引き参照ゾーンが必要です。
- 最高のセキュリティ、信頼性、機能サポートのために、NFS クライアントとそれに関連するパッケージ (
nfs-utils
など) を最新の状態にする必要があります。 - デュアルプロトコル ボリュームでは、Active Directory Domain Services (AD DS) と Azure Active Directory Domain Services (AADDS) の両方がサポートされています。
- デュアル プロトコル ボリュームでは、Microsoft Entra Domain Services を使用した TLS 経由の LDAP の使用はサポートされていません。 TLS 経由の LDAP に関する考慮事項に関するセクションを参照してください。
- サポートされている NFS バージョンには、NFSv3 と NFSv4.1 が含まれます。
- 並列ネットワーク ファイル システム (pNFS)、セッション トランキング、紹介などの NFSv4.1 機能は現在、Azure NetApp Files ボリュームではサポートされていません。
- Windows 拡張属性
set
/get
は、デュアル プロトコル ボリュームではサポートされていません。 - Azure NetApp Files のデュアル プロトコル ボリュームを作成するための追加の考慮事項を参照してください。
次のステップ
- Azure NetApp Files のデュアルプロトコル セキュリティ スタイルとアクセス許可の動作について
- Azure NetApp Files での LDAP の使用について
- NFS グループメンバーシップと補足グループについて
- Azure NetApp Files のファイル ロックとロックの種類について理解する
- Azure NetApp Files の NFS ボリュームを作成する
- Azure NetApp Files の SMB ボリュームを作成する
- Azure NetApp Files のデュアルプロトコル ボリュームを作成する
- Azure NetApp Files の NFS に関するよくあるご質問
- Azure NetApp Files の SMB に関する FAQ