導言：FDP 和延遲監控是高復原能力 SSD 架構的附加組成部分。
在我近期的兩篇部落格中，我側重於看似不相關但在近期與業界同事交談後，我認定比我原先意識到的更相關的話題，本部落格將進一步探討該關連性；探討延遲緩解和 NVM Express 的靈活資料放置（FDP）及 OCP Storage Workgroup 的延遲監控（LM）等策略，如何被視為垂直整合且具高復原能力的要件。
回顧：垂直整合的復原能力
在我的部落格「以『左移概念』方法致力革新 SSD 復原能力」中，我概述了與建立高復原能力相關的所有主機和儲存裝置組成部分。從第 1 版 OCP SSD 規格開始到如今的第三個版本（第 2.5 版），復原能力的組成部分已逐步遞增。討論了崩潰偵測、崩潰復原和標準化遙測。但有兩個問題我想更深入的探討，1) 靈活資料放置；及 2) 延遲監控
圖 1 - 垂直整合的復原能力特點摘要
NVM Express™ 靈活資料放置（FDP）透過緩解尾延遲來增強垂直整合的復原能力
隨著減輕寫入放大令主機應用程式更加持久耐用，增強 SSD 復原能力的 FDP 看似合理又顯而易見。這在業內和我同事發佈的其他美光部落格中已詳盡討論過。如之前所討論的，這也顯示出可使用 FDP 來提高效能的多個場所。這不是什麼新鮮事。像減少垃圾收集一樣，在業內觀察到的現實工作負載可以得到改進。
但延遲異常值減少可被視為垂直整合復原能力的特點嗎？FDP 能幫上忙嗎？ 我之前的部落格「為什麼資料中心 SSD 的延遲很重要以及美光如何成為同類佼佼者」探討了延遲異常值為何在向外擴充解決方案中如此令人頭痛的理論，以及美光為一個世界級解決方案實施的技術。但其中未做關於垂直整合以及垂直整合的 FDP 解決方案會如何進一步改進延遲的假設。
若 FDP 的作用是減少垃圾收集（GC）的數量，則很明顯，FDP 亦會減少延遲異常值。當然，由於不同的通道晶粒、平面，以及主機啟動的讀取、程式設計和清除，即使沒有 GC 和 WAF=1，仍將出現延遲變化。然而，當寫入放大達到 2-3 或更多時，衝突可能性和由此導致的更大延遲異常值便會產生影響。但 FDP 可在多大程度上增強延遲異常值呢？
圖 2 - 主機和內部作業影響 NAND 作業的高階摘要。是這些內部作業增加了流量，並通常以「寫入放大」來衡量。
使用業內常用且在我的延遲部落格中詳細討論過的方法，我們來看一下在全壓下 70% 讀取，30% 寫入 4KiB 隨機工作負載和繪圖讀取延遲的分佈情況。涵蓋非 FDP 案例會簡單易懂，並符合業界慣例。為衡量為 1 的 WA 作為 FDP 最佳案例的代表，建立了一個新的命名空間，在執行 70/30 工作負載前僅預先設定總容量的一部分。在該案例中，8TB 美光 7500 SSD 預先設定為 1TB，IO 被限制在 1TB 內（以防讀取未對應的 LBA），直至填滿實體介質及開始 GC。
下列圖 3 顯示讀取延遲分佈，先是沒有寫入壓力，隨後伴隨持續的寫入壓力。許多之前的結果顯示 FDP WA 約為 1，因此，可以預計尾延遲變化最高減少 30%。
圖 3 - 透過 FDP 降低垃圾收集壓力可以大幅縮小尾延遲分佈
OCP Storage Workgroup 的延遲監控提升 SSD 復原能力
在我之前有關延遲緩解的部落格中，我解釋過，當資料庫查詢分為平行執行的多個子查詢時，尾延遲有很小可能性會對總延遲產生高強度影響。該部落格討論了查找和確定延遲異常值的原因有多難。其中未曾討論如何證明延遲異常值如所預期的那樣。FIO 這樣的工具可以在系統級別為每次交易打上時間戳記，並計算所需的延遲長條圖。但有了如今速度達數百萬 IOPS 的磁碟，建立系統級即時區塊追蹤和尋找異常值在實際應用中的計算成本未免過高。即使我們可以這樣做，在主機偵測到異常值並發送含所需糾錯資料的遙測主機啟動請求前，SSD 糾錯資訊可能就已經消失了。
我個人在撰寫 FMS 2017 論文過程中時遇過該問題；SSD 控制器顯示有足夠的運算能力記錄每個命令抵達和發出的時間，衡量延遲，建立詳細的長條圖，並在值過高時，觸發判斷提示。在此情況下，資料會在內部收集，以供稍後提取和分析。呈現的資料全部由 SSD 本身在內部生成。
在這項工作的基礎上，再加上 Meta 將 SSD 延遲監控的概念形式化的部分關鍵需求，它首先被納入 OCP 資料中心 NVMe SSD 規格的第 2 版中。在高層次上，每個向外發出的命令均會打上時間戳記，並與相關收到命令的時間戳記相比較，進而計算得出延遲。使用時間戳記建立了四個主機可配置的長條圖桶。為在命令發出時立即應對與索要糾錯記錄檔的主機相關的延遲，如超出命令延遲閾值，則保存內部糾錯記錄檔，以供供應商稍後分析。隨著 OCP Storage 的標準化遙測得到部署，甚至可能提供延遲異常值的進一步糾錯資訊。
在 2022 年儲存裝置開發人員大會上，Meta 的 Vineet Parekh 和 Venkat Ramesh 討論了將延遲監控部署到其機群的情況，並舉例說明了他們發現的一個關鍵問題。他們假設性指出，如果其整個機群的速度為 1000 IOPS，1 秒有 9 個 9 的異常值，則每天會產生逾 5000 個延遲事件！Parekh 和 Ramesh 展示了一個有問題的 SSD 磁碟，在部署延遲監控後，能夠有效糾錯此前數月未得到解決的延遲異常值問題。下列圖 4 概述了延遲監控架構和從其艱辛的異常值糾錯成功中獲得的結果。
延遲監控的額外好處是能夠發現之前錯怪到儲存裝置上的主機延遲問題。有兩個近期範例。一個範例與 Linux 的問題有關，由於一個延遲異常值，導致 NVMe 規格增強延期。另一個範例在我的美光同事 Sayali Shirode 的一篇部落格中討論過，她使用延遲監控來證明測到的延遲異常值並非由有關 SSD 造成。
圖 4 - Meta 在 2022 年儲存裝置開發人員大會上分享的延遲異常值糾錯範例
結論 – 美光正在採納高復原能力 SSD 架構和設計
在我 2023 年 11 月的部落格中，我談到復原能力革新有多需要「左移概念」。該生態系統需要測量和偵測，以及垂直整合，以涵蓋主機和供應商交互。我已經提到部分要素，如崩潰報告、崩潰恢復和大幅減少尾延遲。我想強調結合這兩個理念的兩個要素。
- OCP 中的延遲監控功能對消除延遲異常值至關重要，不僅在 SSD 裝置中如此，在軟體生態系統中亦是如此。
- 資料放置，特別是 FDP 有助於提高持久性和效能，並將延遲異常值減少多達 30%。
另外兩點最後的總結
- 在 FMS，我將主持一場有關超大型運算應用程式的會議，會間 Meta 將補充有關他們大規模部署延遲監控的經歷的進一步細節。請加入我們。我期待在今年秋天的各個會議中與各位就 FDP 主題進行美好的交流。
- OCP Storage 針對 NVMe-CLI 的外掛程式是配置及報告 FDP 和延遲監控以及解碼標準化遙測等其他關鍵輸入值的「供應商獨立」無縫方式。
致謝
- 我要感謝美光的 Chandra Guda 做出的 FDP 實驗設計，以及 John Mazie 提供的測試執行支援。
延伸閱讀
以「左移概念」方法致力革新 SSD 復原能力 | Micron Technology Inc.
為什麼資料中心 SSD 的延遲很重要以及美光如何成為同類佼佼者 | Micron Technology Inc.
批量糾錯超大規模環境中觀察到的快閃問題 - SNIA SDC 2022（sniadeveloper.org）
在工作負載測試中找出延遲異常值 | Micron Technology Inc.
透過 I/O 確定性避免 SSD 中代價高昂的讀取延遲變化（flashmemorysummit.com）
