NFS Azure ファイル共有

適用対象: ✔️ NFS ファイル共有

Azure Filesでは、ファイル共有をマウントするための 2 つの業界標準プロトコル (サーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコル) がサポートされています。 ワークロードに最適なプロトコルを選択します。 ファイル共有Azure、SMB プロトコルと NFS プロトコルの両方を使用した個々のAzure ファイル共有へのアクセスはサポートされていませんが、同じ FileStorage ストレージ アカウント内に SMB ファイル共有と NFS ファイル共有を作成することはできます。 Azure Filesは、ストレージのニーズに合わせてスケールアップでき、数千のクライアントが同時にアクセスできるエンタープライズ レベルのファイル共有を提供します。

この記事では、NFS Azure ファイル共有について説明します。 SMB Azure ファイル共有の詳細については、「Azure Files の SMB ファイル共有」を参照してください。

NFS Azure ファイル共有の一般的なユース ケース

NFS ファイル共有は、SAP アプリケーション層、データベース バックアップ、データベース レプリケーション、メッセージング キュー、汎用ファイル サーバー用のホーム ディレクトリ、アプリケーション ワークロード用のコンテンツ リポジトリなどのワークロードと連携します。

NFS ファイル共有は、多くの場合、次のシナリオで使用されます。

• Linux または POSIX ファイル システム API を使用して記述された基幹業務アプリケーションなど、Linux/UNIX ベースのアプリケーション用のバッキング ストレージ
• POSIX に準拠したファイル共有、大文字と小文字の区別、または Unix スタイルのアクセス許可 (UID/GID) を必要とするワークロード
• ランダム I/O と階層型ストレージを必要とする新しいアプリケーションとサービスの開発

NFS Azure ファイル共有機能

NFS Azure ファイル共有は、POSIX に準拠した完全なファイル システムを提供します。 ハード リンクとシンボリック リンクはサポートされていますが、既存のシンボリック リンクからハード リンクを作成することはできません。

NFS Azure ファイル共有は現在、NFSv4.1 プロトコル仕様のほとんどの機能をサポートしています。 すべての種類の委任やコールバック、Kerberos 認証、ACL などの一部の機能はサポートされていません。

NFS Azure ファイル共有では、ローカル冗長ストレージ (LRS) とゾーン冗長ストレージ (ZRS) がサポートされています。 NFS には geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) は使用できません。NFS には、geo 冗長性をサポートしない SSD ストレージが必要であるためです。

AZURE ストレージ機能に対する NFS Azure ファイル共有のサポート

次の表に、NFS Azure ファイル共有の現在の機能サポートレベルを示します。

サポートは継続的に拡張されるため、この表に示されている項目の状態は時間の経過と共に変化する可能性があります。

管理モデル

NFS Azure ファイル共有では、次の 2 つの最上位リソース プロバイダーがサポートされています。

• Microsoft。FileShares (新しい NFS デプロイに推奨): ストレージ アカウントのないスタンドアロン ファイル共有を作成します。 プロビジョニングされた v2 課金モデルのみをサポートします。
• Microsoft。ストレージ (クラシック): ストレージ アカウント内にクラシック ファイル共有を作成します。 プロビジョニングされた v1 および v2 課金モデルと完全なAzure Files機能セットをサポートします。

機能の完全な比較については、リソース プロバイダーの比較: Microsoft.Storage vs Microsoft.FileShares を参照してください。

NFS Azure ファイル共有のセキュリティとネットワーク

NFS Azure ファイル共有は、保存時および転送中の暗号化によってデータを保護し、ユーザー ベースの認証の代わりにネットワーク レベルのアクセス制御を必要とします。

Encryption

Azure Filesは、Azure ストレージ サービス暗号化 (SSE) を使用して、保存されているすべてのデータを暗号化します。 ストレージ サービスの暗号化は、Windows上の BitLocker と同様に機能します。ファイル システム レベルの下のデータを暗号化します。 暗号化はAzureファイル共有のファイル システムの下で行われるため、データがディスクにエンコードされるため、Azure ファイル共有の読み取りまたは書き込みにクライアントの基になるキーにアクセスする必要はありません。 保存時の暗号化は、SMB と NFS の両方のプロトコルに適用されます。

転送中の暗号化では、NFSv4.1 ボリュームAzure Files、サーバーとクライアント間のセキュリティで保護された TLS 接続を有効にして、転送中のデータをインターセプトから保護することで、ネットワーク セキュリティを強化します。 Azure Filesでは、NFS アクセスに暗号化が必要かどうかを個別に制御するために、専用の Require Encryption in Transit for NFS 設定が提供されます。 Azure ポータルを使用して作成された新しいストレージ アカウントの場合、この設定は既定で有効になっています。 Azure PowerShell、Azure CLI、または FileREST API を使用して作成されたストレージ アカウントは、下位互換性を確保するために、この値を [選択されていません に設定します。 既存のストレージ アカウントの場合、プロトコルごとの設定を明示的に構成するまで、 セキュリティで保護された転送が必要な 設定は引き続き NFS 暗号化動作を管理します。

Azureは、MACSec を使用して、Azure データセンター間で転送されているすべてのデータに対して暗号化レイヤーを提供します。 このテクノロジにより、データがAzureデータセンター間で転送されるときに暗号化が存在します。

認証とネットワーク アクセス

SMB プロトコルを使用するAzure Filesとは異なり、NFS プロトコルを使用するファイル共有では、ユーザー ベースの認証は提供されません。 NFS 共有の認証は、構成されているネットワーク セキュリティ規則に基づいています。 このため、NFS 共有がセキュリティで保護された接続のみを受け入れるようにするには、ストレージ アカウントのプライベート エンドポイントまたはサービス エンドポイントを設定する必要があります。

プライベート エンドポイント (プライベート リンクとも呼ばれます) は、仮想ネットワーク内のプライベートな静的 IP アドレスをストレージ アカウントに提供し、動的 IP アドレスの変化による接続の中断を防ぎます。 ストレージ アカウントへのトラフィックは、他のリージョンやオンプレミスの仮想ネットワークを含め、ピアリングされた仮想ネットワーク内に留まります。 標準のデータ処理料金が適用されます。

静的 IP アドレスが不要な場合は、仮想ネットワーク内のAzure Filesに対して サービス エンドポイントを有効にすることができます。 サービス エンドポイントは、特定のサブネットからのアクセスのみを許可するようにストレージ アカウントを構成します。 許可されるサブネットは、同じサブスクリプション内の仮想ネットワークまたは別のサブスクリプション (別のMicrosoft Entra テナントに属するものも含む) に属することができます。 サービス エンドポイントの使用に追加料金はかかりません。 ただし、ゾーンの停止などのまれなイベントによって、ストレージ アカウントの基になる IP アドレスが変更される可能性があります。 データはファイル共有で引き続き使用できますが、共有を再マウントする必要があります。

オンプレミスから共有にアクセスする場合は、プライベート エンドポイントに加えて VPN または ExpressRoute を設定します。 次のソースから送信されていない要求は拒否されます。

• プライベート エンドポイント
• Azure VPN ゲートウェイ
  • ポイント対サイト VPN
  • サイト間 VPN
• ExpressRoute
• 制限付きパブリック エンドポイント

ネットワーク オプションの詳細については、Azure Files のネットワークに関する考慮事項を参照してください。

Azure Files の NFS ファイル共有のリージョン別提供状況

NFS Azure ファイル共有は、SSD ファイル共有をサポートするすべてのリージョンでサポートされます。 リージョン別Azure製品を参照してください。

NFS Azure ファイル共有のパフォーマンス

NFS Azure ファイル共有は、SSD ファイル共有でのみ使用できます。 プロビジョニングされた v2 課金モデルでは、プロビジョニングされた容量、IOPS、スループットを個別に設定できるため、予測可能な I/O パターンを使用して NFS ワークロードの正確なコスト制御を実現できます。 プロビジョニングされた v1 課金モデルでは、プロビジョニングされた容量で IOPS とスループットが自動的にスケーリングされます。 両方のモデルの詳細については、「Azure Files課金について」を参照してください。

SSD Azure ファイル共有の一般的な I/O 待機時間は、小さな I/O 操作では 1 桁ミリ秒未満の範囲です。 untar などのメタデータ負荷の高いワークロードでは、大量のオープン操作とクローズ操作が原因で待機時間が長くなる可能性があります。

大規模な NFS パフォーマンスの向上に関するガイダンスについては、「NFS Azure ファイル共有のパフォーマンスの向上」を参照してください。

次のステップ

• Microsoftを使用してファイル共有を作成します。FileShares
• クラシック ファイル共有を作成する
• Azure ストレージ サービス間で NFS オプションを比較する