NFS にマウントされた BLOB コンテナーは、Azure HPC Cache で使用できます。 Blob Storage ドキュメント サイトの Azure Blob Storage での NFS 3.0 プロトコルのサポート の詳細を確認します。
Azure HPC Cache では、ADLS-NFS ストレージ ターゲットの種類で NFS 対応 BLOB ストレージが使用されます。 これらのストレージ ターゲットは、通常の NFS ストレージ ターゲットに似ていますが、通常の Azure BLOB ターゲットと一部の重複もあります。
この記事では、ADLS-NFS ストレージ ターゲットを使用する場合に理解する必要がある戦略と制限事項について説明します。
また、NFS BLOB のドキュメント、特に互換性のあるシナリオと互換性のないシナリオについて説明するこれらのセクションを読み、トラブルシューティングのヒントを提供する必要があります。
整合性の要件を理解する
HPC Cache には、ADLS-NFS ストレージ ターゲットに対して強力な一貫性が必要です。 既定では、NFS 対応 BLOB ストレージはファイル メタデータを厳密に更新しないため、HPC Cache でファイルのバージョンが正確に比較されなくなります。
この違いを回避するために、Azure HPC Cache は、ストレージ ターゲットとして使用される NFS 対応 BLOB コンテナーで NFS 属性キャッシュを自動的に無効にします。
この設定は、キャッシュから削除した場合でも、コンテナーの有効期間中保持されます。
NFS プロトコルを使用してデータを事前に読み込む
NFS 対応 BLOB コンテナーでは、ファイルは 作成時に使用されたのと同じプロトコルでのみ編集できます。 つまり、Azure REST API を使用してコンテナーを設定する場合、NFS を使用してこれらのファイルを更新することはできません。 Azure HPC Cache は NFS のみを使用するため、Azure REST API で作成されたファイルを編集することはできません。 ( BLOB ストレージ API に関する既知の問題の詳細)
コンテナーが空の場合や、NFS を使用してファイルが作成された場合は、キャッシュの問題ではありません。
コンテナー内のファイルが NFS ではなく Azure Blob REST API で作成された場合、Azure HPC Cache は元のファイルに対する次のアクションに制限されます。
- ディレクトリ内のファイルを一覧表示します。
- ファイルを読み取ります (その後の読み取りのためにキャッシュに保持します)。
- ファイルを削除する。
- ファイルを切り詰めて（長さを0にします）。
- ファイルのコピーを保存します。 コピーは NFS で作成されたファイルとしてマークされ、NFS を使用して編集できます。
Azure HPC Cache では、REST を使用して作成されたファイルの内容を編集できません。 つまり、キャッシュは、変更されたファイルをクライアントからストレージ ターゲットに保存することはできません。
NFS で作成されていないファイルで読み取り/書き込みキャッシュ使用モデルを使用すると、データ整合性の問題が発生する可能性があるため、この制限を理解しておくことが重要です。
Tip
読み取りと書き込みのキャッシュの詳細については、「 キャッシュの使用モデルについて」を参照してください。
キャッシュの書き込みシナリオ
これらのキャッシュ使用モデルには、書き込みキャッシュが含まれます。
- 15% を超える書き込み
- 15% を超える書き込み、バッキング サーバーで 30 秒ごとに変更が確認される
- 15%を超える書き込みがある場合、バッキングサーバーで60秒ごとに変更が確認される
- 15% を超える書き込み、30 秒ごとにサーバーに書き戻す
書き込みキャッシュの使用モデルは、NFS で作成されたファイルでのみ使用する必要があります。
REST で作成されたファイルで書き込みキャッシュを使用しようとすると、ファイルの変更が失われる可能性があります。 これは、キャッシュがファイル編集をストレージ コンテナーにすぐに保存しようとしないためです。
REST で作成されたファイルへの書き込みをキャッシュしようとすると、データが危険にさらされる方法を次に示します。
キャッシュはクライアントからの編集を受け入れ、変更ごとに成功メッセージを返します。
キャッシュは、変更されたファイルをストレージに保持し、追加の変更を待機します。
しばらくすると、キャッシュは変更されたファイルをバックエンド コンテナーに保存しようとします。 この時点で、NFS を使用して REST で作成されたファイルに書き込もうとしているため、エラー メッセージが表示されます。
変更が受け入れられなかったことをクライアント コンピューターに伝えるのが遅すぎます。また、キャッシュには元のファイルを更新する方法がありません。 そのため、クライアントからの変更は失われます。
キャッシュの読み取りシナリオ
読み取りキャッシュのシナリオは、NFS または Azure Blob REST API を使用して作成されたファイルに適しています。
これらの使用モデルでは、読み取りキャッシュのみが使用されます。
- 読み取り負荷が高く、書き込み頻度が低い
- クライアントが NFS ターゲットに書き込み、キャッシュをバイパスする
- 読み取り負荷が高く、バッキング サーバーを 3 時間ごとに確認する
これらの使用モデルは、REST API または NFS によって作成されたファイルで使用できます。 クライアントからバックエンド コンテナーに送信された NFS 書き込みはすべて失敗しますが、すぐに失敗し、エラー メッセージがクライアントに返されます。
読み取りキャッシュ ワークフローでは、キャッシュされていない限り、ファイルの変更を伴う可能性があります。 たとえば、クライアントはコンテナーからファイルにアクセスし、変更を新しいファイルとして書き戻したり、変更したファイルを別の場所に保存したりできます。
ネットワーク ロック マネージャー (NLM) の制限事項を認識する
NFS 対応 BLOB コンテナーでは、ネットワーク ロック マネージャー (NLM) はサポートされていません。これは、ファイルを競合から保護するために一般的に使用される NFS プロトコルです。
NFS ワークフローが最初にハードウェア ストレージ システム用に作成された場合、クライアント アプリケーションに NLM 要求が含まれている可能性があります。 プロセスを NFS 対応 BLOB ストレージに移行するときにこの制限を回避するには、クライアントがキャッシュをマウントするときに NLM を無効にしてください。
NLM を無効にするには、クライアントの -o nolock コマンドでオプション mountを使用します。 このオプションにより、クライアントは NLM ロックを要求し、応答でエラーを受信できなくなります。
nolockオプションは、オペレーティング システムによって実装方法が異なります。詳細については、クライアント OS のドキュメント (man 5 nfs) を確認してください。
HPC Cache を使用して NFS 対応コンテナーへの書き込みを効率化する
Azure HPC Cache は、ADLS-NFS ストレージ ターゲットへの変更の書き込みを含むワークロードのパフォーマンス向上に役立ちます。
Note
Azure HPC Cache を使用してファイルを変更する場合は、NFS を使用して ADLS-NFS ストレージ コンテナーを設定する必要があります。
NFS 対応 BLOB のパフォーマンスに関する考慮事項に関する記事 で説明されている制限事項の 1 つは、ストレージ ADLS-NFS 既存のファイルの上書きがあまり効率的でないことを示しています。 NFS マウント BLOB ストレージで Azure HPC Cache を使用する場合、クライアントがアクティブ なファイルを変更するときに、キャッシュによって断続的な書き換えが処理されます。 バックエンド コンテナーへのファイルの書き込みの待機時間は、クライアントには表示されません。
上記の NFS プロトコルを使用した データの事前読み込みで説明した制限事項に注意してください。