NFS Azure ファイル共有

対象: ✔️ Microsoft.Storage または Microsoft.FileShares で作成された NFS ファイル共有

Azure Filesでは、ファイル共有をマウントするための 2 つの業界標準プロトコル (サーバー メッセージ ブロック (SMB) プロトコルとネットワーク ファイル システム (NFS) プロトコル) がサポートされています。 ワークロードに最適なプロトコルを選択します。 Azure ファイル共有では、1 つの Azure ファイル共有に SMB プロトコルと NFS プロトコルの両方でアクセスすることはサポートされていません。 クラシックなファイル共有の場合、同じFileStorageストレージアカウント内でSMBとNFSのファイル共有を別々に作成できます。 Microsoft.FileSharesは現在、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 Files の機能向け NFS Azure ファイル共有サポート

次の表に、NFS Azure ファイル共有の現在の機能サポートレベルを示します。 特に記載がない限り、サポートはクラシック ファイル共有 (Microsoft.Storage) と Microsoft.FileShares で作成されたファイル共有の両方に適用されます。

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

管理モデル

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

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

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

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

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

Encryption

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

クラシック ファイル共有と Microsoft.FileShares ファイル共有の両方が、AZNFS マウント ヘルパー を介した転送中の TLS 暗号化をサポートします。 暗号化要件は異なる範囲で設定します:

• Microsoft.FileShares:トランジット時の暗号化はデフォルトで必須です。 この要件は個々のファイル共有で設定します。 ファイル共有を作成する際の詳細設定を参照してください。
• クラシック ファイル共有: ストレージ アカウントで [NFS における転送時の暗号化を必須とする] を構成します。 Azureポータルを通じて作成された新しいストレージアカウントでは、この設定はデフォルトで有効になっています。 設定が 「未選択」 の場合、「安全な転送が必要」 が NFS 暗号化の動作を制御します。 作成のデフォルト設定や設定手順については、「転送中の暗号化を強制する」を参照してください。

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

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

NFS Azureファイル共有はユーザーベースの認証をサポートしていないため、クライアントの認証にはネットワークアクセスルールに依存しています。 したがって、クライアントはプライベートエンドポイントまたは仮想ネットワーク制限のあるサービスエンドポイントを通じて接続する必要があります。

クラシック ファイル共有と Microsoft.FileShares ファイル共有の両方で、これらの接続オプションがサポートされています。 従来のファイル共有の場合は、ストレージアカウントでネットワーク設定を行います。 Microsoft.FileShares では、個々のファイル共有でネットワークを構成します。

プライベート エンドポイント

プライベートエンドポイントは、仮想ネットワーク内でファイル共有へのアクセスのためのプライベートIPアドレスを提供します。 プライベートエンドポイントのみを通じたアクセスを許可するには、パブリックネットワークアクセスを無効にしてください。 Private Link料金が発生します。

クライアントは仮想ネットワークから接続することも、ピア接続された仮想ネットワークから接続することも可能です。 オンプレミスアクセスの場合は、 VPN または ExpressRouteを使って仮想ネットワークに接続してください。

サービス エンドポイント

サービスエンドポイントは、サブネット内のクライアントがAzureバックボーン経由でファイル共有のパブリックエンドポイントにアクセスできるようにします。 クライアントサブネット上のサービスエンドポイントを有効にしてください。 ファイル共有のネットワーク ルールを設定して、そのサブネットからのアクセスを許可してください。 許可されるサブネットは、同じサブスクリプション内でも異なるサブスクリプションでも、異なるMicrosoft Entraテナントでも構いません。 サービスエンドポイントに追加料金はありません。

サービスエンドポイントはファイル共有にプライベートIPアドレスを割り当てません。 ゾーン障害のような稀な事象でパブリックエンドポイントのIPアドレスが変更された場合、クライアントはシェアを再マウントする必要があるかもしれません。

オプションのアウトバウンドフィルタリング

ファイル共有のネットワークルールが、どのクライアントがアクセスできるかを制御します。 それらは、クライアントがアクセスできる他のストレージ リソースを制限しません。 例えば、ファイル共有を読み取れるクライアントが、書き込み権限を持つ別のリソースにデータをコピーすることができます。

クラシックなファイル共有では、サブネット内のクライアントがサービスエンドポイント経由でアクセスできるストレージアカウントを制限するために、オプションでサービスエンドポイントポリシーを使うことができます。 サービスエンドポイントのトラフィックはAzure Firewallやネットワーク仮想アプライアンスをバイパスします。 ポリシーはこのパス上の宛先をフィルタリングします。 他のアウトバウンドパスを制限したり、宛先のネットワークルールや認可要件を置き換えたりするわけではありません。

サービス エンドポイント ポリシーは現在、Microsoft.FileShares のファイル共有ではサポートされていません。 クライアントサブネットにポリシーがある場合、クライアントはプライベートエンドポイントを使ってファイル共有にアクセスしなければなりません。 詳細については、「 サービスエンドポイントポリシーでアウトバウンドアクセスを制限する」をご覧ください。

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

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

地域ごとの利用可能性は、リソース提供者と冗長性のオプションによって異なります。

• Microsoft.FileShares: LRSリージョンおよびZRSリージョンを参照してください。
• クラシックファイル共有: LRSリージョン および ZRSリージョンを参照してください。

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

NFS Azure ファイル共有は、SSD ファイル共有でのみ使用できます。 両リソースプロバイダーはプロビジョニング済みv2請求モデルをサポートしており、プロビジョニング容量、IOPS、スループットを個別に設定できます。 クラシックファイルシェアは、プロビジョニングされたv1請求モデルもサポートしており、これによりIOPSとスループットはプロビジョニング容量に伴い自動的にスケールします。 両方のモデルの詳細については、「Azure Files課金について」を参照してください。

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

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

次のステップ

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