Skip to main content
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

ONTAP FlexCache 回寫式使用案例

貢獻者
PDF

這些寫入設定檔最適合啟用回寫的 FlexCache 。您應該測試工作負載、以瞭解回寫或繞過寫入是否能提供最佳效能。

註 回寫並不取代回寫功能。雖然回寫是針對大量寫入工作負載所設計、但回寫仍是許多工作負載的最佳選擇。

目標工作負載

檔案大小

檔案大小比與呼叫檔案之間所發出的寫入次數來得小 OPEN CLOSE 。小型檔案本來就有較少的 WRITE 通話、因此不太適合回寫。大型檔案在與通話之間可能有更多寫入 OPEN CLOSE 、但這並不保證。

請參閱"FlexCache 回寫準則"頁面，以取得最新的檔案大小建議。

寫入大小

從用戶端寫入時，除了寫入呼叫之外，還會涉及其他修改 NAS 呼叫。其中包括但不限於：

  • CREATE

  • OPEN

  • CLOSE

  • SETATTR

  • SET_INFO

SETATTR`以及 `SET_INFO owner`在快取中處理的設定， `atime， ctime， group`或 `size`呼叫 `mtime。其餘的通話必須在原始伺服器處理，並觸發寫入已啟用回寫快取的任何髒資料的回寫。檔案的 IO 將會停止、直到回寫完成為止。

知道這些通話必須經過 WAN 、有助於識別適合回寫的工作負載。一般而言、在 OPEN `CLOSE`不發出上述其中一個通話的情況下、在與通話之間所能完成的寫入次數越多、效能回寫所提供的效能就越高。

寫入後讀取

寫入後讀取工作負載在 FlexCache 的執行效能一向不佳。這是由於 9.15.1 之前的繞過寫入操作模式所致。 WRITE`對檔案的呼叫必須在原始伺服器上進行、後續的 `READ 通話則必須將資料拉回快取。這會導致這兩種作業都會受到 WAN 的影響。因此、 FlexCache 在寫入模式中不建議使用寫入後讀取工作負載。在 9.15.1 中引入回寫功能後、資料現在會在快取中提交、並可立即從快取中讀取、免除 WAN 的麻煩。如果您的工作負載在 FlexCache 磁碟區中包含讀取後寫入、則應將快取設定為以回寫模式運作。

提示 如果寫入後讀取是工作負載的關鍵部分、您應該將快取設定為以回寫模式運作。
寫入後寫入

當檔案在快取中累積髒資料時、快取會以非同步方式將資料重新寫入來源。這自然會導致用戶端關閉檔案、但仍有髒資料等待重新排清來源。如果剛關閉且仍有髒資料的檔案有其他開啟或寫入資料、寫入作業將會暫停、直到所有髒資料都已排清至來源。

延遲考量

當 FlexCache 以回寫模式運作時、延遲增加對 NAS 用戶端更有幫助。不過、回寫的成本、有一點比低延遲環境中所獲得的優勢還要高。在某些 NetApp 測試中，回寫效益是從快取與原始伺服器之間的最低延遲開始，時間為 8 毫秒。這種延遲會因工作負載而異，因此請務必測試以瞭解工作負載的報酬點。

下圖顯示 NetApp 實驗室測試中回寫的退回點。 x`軸為檔案大小、 `y 軸為經過時間。此測試使用 NFSv3 、以 256 KB 和 64 毫秒的 WAN 延遲進行掛載 rsize wsize 。此測試是使用小型 ONTAP Select 執行個體來執行快取和原始伺服器、以及單一執行緒寫入作業。您的結果可能有所不同。

返回點

重要 回寫不應用於叢集快取。當原始伺服器和快取位於同一個叢集中時、就會發生叢集內快取。