Azure Blob Storage でのネットワーク ファイル システム (NFS) 3.0 プロトコル サポート
Blob Storage では、ネットワーク ファイル システム (NFS) 3.0 プロトコルがサポートされるようになりました。 このサポートにより、オブジェクト ストレージのスケールと価格で Linux ファイル システムの互換性が得られます。また、Linux クライアントは、Azure 仮想マシン (VM) またはオンプレミスのコンピューターから Blob Storage にコンテナーをマウントできます。
ハイ パフォーマンス コンピューティング (HPC) などの大規模なレガシ ワークロードをクラウドで実行することは、常に難しい課題でした。 その理由の 1 つは、アプリケーションがデータへのアクセスに NFS やサーバー メッセージ ブロック (SMB) などの従来のファイル プロトコルを使用することが多いためです。 また、ネイティブ クラウド ストレージ サービスでは、階層型名前空間と効率的なメタデータ操作を提供するファイル システムではなく、フラット型名前空間と広範なメタデータを持つオブジェクト ストレージに重点が置かれていました。
Blob Storage では、階層型名前空間がサポートされるようになりました。また、NFS 3.0 プロトコル サポートと組み合わせることで、Azure によって、大規模なクラウド オブジェクト ストレージ上でレガシ アプリケーションを実行することがはるかに容易になります。
この機能に適したアプリケーションとワークロード
NFS 3.0 プロトコル機能は、高スループット、高スケール、読み取り負荷の高いワークロード (メディア処理、リスク シミュレーション、ゲノミクス シーケンスなど) の処理に最適です。 この機能は、高帯域幅を必要とする、複数のリーダーと多くのスレッドを使用するその他の種類のワークロードに使用することを検討してください。
NFS 3.0 と階層型名前空間
NFS 3.0 プロトコルのサポートでは、BLOB を階層型名前空間に編成する必要があります。 ストレージ アカウントを作成するときに、階層型名前空間を有効にできます。 階層型名前空間を使用する機能は、Azure Data Lake Storage Gen2 によって導入されました。 これにより、コンピューター上のファイル システムを編成するのと同じ方法で、オブジェクト (ファイル) がディレクトリとサブディレクトリの階層に編成されます。 階層型名前空間は、スケールが線形で、データ容量もパフォーマンスも低下しません。 階層型名前空間からさまざまなプロトコルが拡張されます。 NFS 3.0 プロトコルは、これらの使用可能なプロトコルの 1 つです。
ブロック BLOB として格納されるデータ
アプリケーションが NFS 3.0 プロトコルを使用して要求を行うと、その要求はブロック BLOB 操作の組み合わせに変換されます。 たとえば、NFS 3.0 読み取りリモート プロシージャ コール (RPC) 要求は、Get Blob 操作に変換されます。 NFS 3.0 書き込み RPC 要求は、Get Block List、Put Block、Put Block List の組み合わせに変換されます。
ブロック BLOB は、読み取り負荷の高い大量のデータを効率的に処理するように最適化されています。 ブロック BLOB は複数のブロックで構成されています。 各ブロックは、ブロック ID によって識別されます。 ブロック BLOB には、最大 50,000 個のブロックを含めることができます。 ブロック BLOB 内の各ブロックのサイズは、お客様のアカウントで使用されているサービスのバージョンで許可される最大サイズまで変更できます。
一般的なワークフロー:ストレージ アカウント コンテナーのマウント
Linux クライアントは、Azure 仮想マシン (VM) またはオンプレミスのコンピューターから Blob Storage にコンテナーをマウントできます。 ストレージ アカウント コンテナーをマウントするには、次の操作を行う必要があります。
Azure 仮想ネットワーク (VNet) を作成します。
ネットワーク セキュリティを構成します。
VNet からのトラフィックのみを受け入れるストレージ アカウントを作成および構成します。
ストレージ アカウントにコンテナーを作成します。
コンテナーをマウントします。
詳細な手順については、「ネットワーク ファイル システム (NFS) 3.0 プロトコルを使用して Blob Storage をマウントする」を参照してください。
ネットワークのセキュリティ
トラフィックは VNet から発信される必要があります。 VNet を使用すると、クライアントはストレージ アカウントに安全に接続できます。 アカウント内のデータをセキュリティで保護する唯一の方法は、VNet とその他のネットワーク セキュリティ設定を使用することです。 アカウント キーの承認、Microsoft Entra セキュリティ、アクセス制御リスト (ACL) など、データのセキュリティ保護に使用されるその他のツールは、NFS 3.0 要求の承認には使用できません。
詳細については、BLOB ストレージのネットワーク セキュリティに関する推奨事項に関するページを参照してください。
サポートされているネットワーク接続
クライアントは、パブリックまたはプライベート エンドポイント経由で接続でき、次のいずれかのネットワークの場所から接続できます。
ストレージ アカウント用に構成した VNet。
この記事では、その VNet を "プライマリ VNet" と呼びます。 詳細については、「仮想ネットワークからアクセスの許可」を参照してください。
プライマリ VNet と同じリージョンにあるピアリングされた VNet。
このピアリングされた VNet へのアクセスを許可するようにストレージ アカウントを構成する必要があります。 詳細については、「仮想ネットワークからアクセスの許可」を参照してください。
VPN Gatewayまたは ExpressRoute ゲートウェイを使用して、プライマリ VNet に接続されているオンプレミス ネットワーク。
詳細については、「オンプレミスのネットワークからのアクセスの構成」を参照してください。
ピアリングされたネットワークに接続されているオンプレミス ネットワーク。
これを行うには、VPN Gatewayまたは ExpressRoute ゲートウェイをゲートウェイ転送と共に使用します。
重要
NFS 3.0 プロトコルでは、ポート 111 および 2049 が使用されます。 オンプレミスのネットワークから接続している場合は、クライアントがこれらのポートを介した発信を許可していることを確認します。 特定の VNet へのアクセスを許可している場合は、それらの VNet に関連付けられているネットワーク セキュリティ グループに、それらのポートを介した受信通信をブロックするセキュリティ規則が含まれていないことを確認します。
既知の問題と制限事項
NFS 3.0 サポートの現在のリリースにおける問題と制限事項の一覧については、既知の問題に関する記事をご覧ください。
価格
データ ストレージとトランザクションのコストについては、「Azure Blob Storage の価格」のページを参照してください。