分享方式：

搭配使用掛接 NFS 的 Blob 儲存體與 Azure HPC Cache

  • 文章

您可以搭配 Azure HPC Cache 使用 NFS 掛接的 Blob 容器。 在 Blob 儲存體文件網站上深入閱讀 Azure Blob 儲存體中的 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 建立的，則快取並無問題。

如果您容器中的檔案是使用 Azure Blob REST API 而非 NFS 所建立，則 Azure HPC Cache 僅限於原始檔案上的這些動作：

  • 列出目錄中的檔案。
  • 讀取檔案 (並將其保留在快取中，以供後續讀取)。
  • 刪除 檔案。
  • 清空檔案 (將其截斷為 0)。
  • 儲存檔案的複本。 複本會標示為 NFS 建立的檔案，而且可以使用 NFS 進行編輯。

Azure HPC Cache 無法編輯已使用 REST 建立的檔案內容。 這表示，快取無法將已變更的檔案從用戶端儲存回儲存體目標。

務必了解這項限制，因為在未使用 NFS 建立的檔案上使用讀取/寫入快取使用量模型時，其可能會造成資料完整性問題。

提示

在了解快取使用量模型中深入了解讀取與寫入快取。

寫入快取案例

這些快取使用量模型包括寫入快取：

  • 大於 15% 的寫入
  • 大於 15% 的寫入，每隔 30 秒檢查一次備份伺服器的變更
  • 大於 15% 的寫入，每隔 60 秒檢查一次備份伺服器的變更
  • 大於 15% 的寫入，每隔 30 秒寫回伺服器

寫入快取使用量模型只能用於已使用 NFS 建立的檔案上。

如果您嘗試在 REST 建立的檔案上使用寫入快取，您的檔案變更可能會遺失。 這是因為快取不會嘗試立即將檔案編輯儲存至儲存體容器。

以下是嘗試快取寫入至 REST 建立的檔案如何讓資料面臨風險：

  1. 快取會接受來自用戶端的編輯，並在每次變更時傳回成功訊息。

  2. 快取會將變更的檔案保留在其儲存體中，並等候其他變更。

  3. 經過一段時間之後，快取會嘗試將變更的檔案儲存到後端容器。 此時，其會收到錯誤訊息，因為其嘗試使用 NFS 寫入至 REST 建立的檔案。

    太晚無法告知用戶端電腦，未接受其變更，而且快取無法更新原始檔案。 因此，來自用戶端的變更將會遺失。

讀取快取案例

讀取快取案例適用於使用 NFS 或 Azure Blob REST API 建立的檔案。

這些使用量模型只會使用讀取快取：

  • 大量讀取，不常寫入
  • 用戶端繞過快取直接寫入 NFS 目標
  • 大量讀取，每 3 小時檢查備份伺服器

您可以使用這些使用量模型搭配 REST API 或 NFS 所建立的檔案。 從用戶端傳送至後端容器的任何 NFS 寫入仍會失敗，但其會立即失敗，並將錯誤訊息傳回給用戶端。

只要未快取檔案變更，讀取快取工作流程仍可能涉及這些檔案變更。 例如，用戶端可能會從容器存取檔案，但寫回其變更作為新檔案，或者其可以將修改過的檔案儲存在不同的位置中。

辨識網路鎖定管理員 (NLM) 限制

已啟用 NFS 的 Blob 容器不支援網路鎖定管理員 (NLM)，這是常用的 NFS 通訊協定，以保護檔案避免衝突。

如果您的 NFS 工作流程原本是針對硬體儲存系統所撰寫，您的用戶端應用程式可能會包含 NLM 要求。 若要在將您的流程移至已啟用 NFS 的 Blob 儲存體時解決這項限制，請確定您的用戶端在掛接快取時停用 NLM。

若要停用 NLM，請在用戶端 mount 命令中使用選項 -o nolock。 此選項可防範用戶端要求 NLM 鎖定，並接收回應中的錯誤。 nolock 選項在不同的作業系統中以不同的方式實作；如需詳細資料，請參閱您的用戶端作業系統文件 (man 5 nfs)。

使用 HPC Cache 簡化寫入至已啟用的 NFS 容器

Azure HPC Cache 可協助改善工作負載中的效能，包括將變更寫入至 ADLS-NFS 儲存體目標。

注意

如果您想要透過 Azure HPC Cache 修改其檔案，則必須使用 NFS 填入 ADLS-NFS 儲存體容器。

已啟用 NFS 的 Blob 效能考量一文中所述的其中一項限制，就是 ADLS-NFS 儲存體在覆寫現有檔案方面不是很有效率。 如果您使用 Azure HPC Cache 搭配 NFS 掛接的 Blob 儲存體，快取會處理間歇性重寫，因為用戶端會修改使用中的檔案。 用戶端會隱藏將檔案寫入後端容器的延遲。

請記住，上面使用 NFS 通訊協定預先載入資料中所述的限制。

下一步