如何使用 fio 檢查磁盤以獲得足夠的 etcd 性能

筆記。 翻譯。：本文是 IBM Cloud 工程師為尋找與 etcd 數據庫操作相關的實際問題的解決方案而進行的小型研究的結果。 類似的任務與我們相關，但是，在更廣泛的背景下，作者的思考和行動過程可能很有趣。

全文小結：fio和etcd

etcd 集群的性能高度依賴於底層存儲的速度。 etcd 導出各種 Prometheus 指標來監控性能。 其中之一是 wal_fsync_duration_seconds. 在 etcd 的文檔中 它說如果該指標的第 99 個百分位數不超過 10 毫秒，則可以認為存儲速度足夠快……

如果您正在考慮在 Linux 機器上設置 etcd 集群並想要檢查驅動器（例如 SSD）是否足夠快，我們建議使用名為 FIO. 運行以下命令就足夠了（目錄 test-data 必須位於測試驅動器的已安裝分區中）：

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

它仍然只是查看輸出並檢查第 99 個百分位數是否適合 fdatasync 在 10 毫秒內如果是這樣，那麼您的驅動器運行速度足夠快。 這是一個示例輸出：

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

一些注意事項：

1. 在上面的例子中，我們調整了參數 --size и --bs 對於特定情況。 從中獲得有意義的結果 fio，指定適合您的用例的值。 下面將討論如何選擇它們。
2. 僅在測試期間 fio 加載磁盤子系統。 在現實生活中，其他進程很可能會寫入磁盤（除了那些與 wal_fsync_duration_seconds). 這種額外的負載可以增加 wal_fsync_duration_seconds. 換句話說，如果來自測試的第 99 個百分位數 fio, 僅略小於 10 毫秒，很可能是存儲性能不足。
3. 對於測試，您將需要版本 fio 不低於3.5，因為舊版本不匯總結果 fdatasync 以百分位數的形式。
4. 以上結論只是一般結論的一小部分 fio.

更多關於 fio 和 etcd

關於 WAL etcd 的幾句話

通常，數據庫使用 主動記錄 （預寫日誌記錄，WAL）。 etcd 也受到影響。 WAL 的討論超出了本文的範圍，但出於我們的目的，您需要知道每個 etcd 集群成員都將 WAL 存儲在持久存儲中。 etcd 在執行之前將一些鍵值存儲操作（例如更新）寫入 WAL。 如果節點在快照之間崩潰並重新啟動，etcd 可以根據 WAL 的內容恢復自上一個快照以來的事務。

因此，每次客戶端將鍵添加到 KV 存儲或更新現有鍵的值時，etcd 都會將操作的描述添加到 WAL，WAL 是持久存儲中的常規文件。 etcd 必須 100% 確定 WAL 條目在繼續之前已實際保存。 要在 Linux 上實現這一點，僅使用系統調用是不夠的 write，因為對物理介質的寫操作本身可能會延遲。 例如，Linux 可能會在內存中的內核緩存（例如，頁面緩存）中保留 WAL 條目一段時間。 為確保數據寫入介質，必須在寫入後調用系統調用 fdatasync - 這正是 etcd 所做的（正如您在以下輸出中看到的那樣） strace; 這裡 8 - WAL 文件描述符）：

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

不幸的是，寫入持久存儲需要一些時間。 長時間執行 fdatasync 調用會影響 etcd 的性能。 在存儲庫文檔中 表明的，為了獲得足夠的性能，所有調用持續時間的第 99 個百分位數是必要的 fdatasync 寫入 WAL 文件時少於 10 毫秒。 還有其他與存儲相關的指標，但本文將重點關注該指標。

使用 fio 評估存儲

您可以使用該實用程序評估某個存儲是否適合與 etcd 一起使用 FIO — 流行的 I/O 測試儀。 請記住，磁盤 I/O 可以以許多不同的方式發生：同步/異步、許多不同的系統調用類，等等。 硬幣的另一面是 fio 極難使用。 該實用程序有很多參數，它們的值的不同組合會導致完全不同的結果。 為了得到對etcd的合理預估，需要保證fio產生的寫負載盡可能接近etcd的WAL文件寫負載：

• 這意味著生成的 fio 負載至少應該是對文件的一系列連續寫入，其中每次寫入都包含一個系統調用 write其次是 fdatasync.
• 要啟用順序寫入，您必須指定標誌 --rw=write.
• 該 fio 使用電話寫 write （而不是其他系統調用——例如， pwrite), 使用標誌 --ioengine=sync.
• 最後是國旗 --fdatasync=1 確保每一個 write 必須 fdatasync.
• 我們示例中的其他兩個參數是： --size и --bs - 可能因具體用例而異。 下一節將描述它們的配置。

為什麼我們選擇 fio 以及我們如何學習如何設置它

這個筆記來自我們遇到的一個真實案例。 我們在 Kubernetes v1.13 上有一個集群，並在 Prometheus 上進行監控。 SSD 被用作 etcd v3.2.24 的存儲。 etcd 指標顯示延遲太高 fdatasync，即使集群處於空閒狀態。 對我們來說，這些指標似乎非常可疑，我們不確定它們到底代表什麼。 此外，集群由虛擬機組成，因此無法判斷延遲是由於虛擬化還是 SSD 造成的。

此外，我們考慮了硬件和軟件配置的各種變化，因此我們需要一種方法來評估它們。 當然，可以在每個配置中運行 etcd 並查看相應的 Prometheus 指標，但這需要大量工作。 我們需要的是一種評估特定配置的簡單方法。 我們想測試我們對來自 etcd 的 Prometheus 指標的理解。

這需要解決兩個問題：

• 首先，etcd 在寫入 WAL 文件時產生的 I/O 負載是什麼樣的？ 使用了哪些系統調用？ 記錄塊的大小是多少？
• 其次，假設我們有上述問題的答案。 如何重現相應的負載 fio？ 畢竟 fio - 具有豐富參數的極其靈活的實用程序 （這很容易驗證，例如， 這裡 - 約。 譯）.

我們使用相同的基於命令的方法解決了這兩個問題 lsof и strace:

• 同 lsof 您可以查看進程使用的所有文件描述符，以及它們引用的文件。
• 同 strace 您可以分析已經運行的進程或運行進程並觀察它。 該命令顯示此進程進行的所有系統調用，如有必要，還顯示其後代。 後者對於分叉的進程很重要，etcd 就是這樣一個進程。

我們做的第一件事是使用 strace 在空閒時檢查 Kubernetes 集群中的 etcd 服務器。

於是發現WAL記錄塊非常密集，大部分大小在2200-2400字節之間。 這就是為什麼本文開頭的命令使用標誌 --bs=2300 (bs 是每個寫入塊的字節大小 fio).

請注意，etcd 寫入塊的大小可能因版本、部署、參數值等而異。 - 它影響持續時間 fdatasync. 如果您有類似的用例，請分析 strace 您的 etcd 進程獲取最新值。

然後，為了更清晰全面地了解etcd是如何與文件系統一起工作的，我們從下開始 strace 有旗幟 -ffttT. 這使得捕獲子進程並將每個子進程的輸出寫入單獨的文件成為可能。 此外，還獲取了有關每個系統調用的開始時間和持續時間的詳細信息。

我們還使用了命令 lsof確認您對輸出的理解 strace 就哪個文件描述符用於哪個目的而言。 我得到了結論 strace，類似於上面的那個。 同步時間的統計操作證實了指標 wal_fsync_duration_seconds 來自 etcd 匹配調用 fdatasync 使用 WAL 文件描述符。

生成與 fio 一個類似於 etcd 的工作負載，研究了該實用程序的文檔並選擇了適合我們任務的參數。 我們已經驗證了正確的系統調用正在進行中，並通過運行確認了它們的持續時間 fio 的 strace （就像在 etcd 的情況下所做的那樣）。

特別注意確定參數的值 --size. 它表示 fio 實用程序生成的總 I/O 負載。 在我們的例子中，這是寫入媒體的總字節數。 與調用次數成正比 write （и fdatasync). 對於特定的 bs 通話次數 fdatasync 是 size / bs.

由於我們對百分位數感興趣，因此我們希望樣本數量足夠大以具有統計顯著性。 並決定 10^4 （對應於 22 MB 的大小）就足夠了。 較小的參數值 --size 發出更明顯的噪音（例如，電話 fdatasync，這比平時花費的時間長得多，並且會影響第 99 個百分位）。

由你決定

文章展示瞭如何使用 fio 可以判斷用於 etcd 的媒體是否足夠快。 現在由你決定！ 您可以在服務中探索具有基於 SSD 存儲的虛擬機 IBM Cloud.

譯者PS

有現成的用例 fio 有關其他任務，請參閱 文件 或直接到 項目庫 （它們比文檔中提到的要多得多）。

來自譯者的PPS

另請閱讀我們的博客：

• «etcd 3.4.3：存儲可靠性和安全性研究“;
• «我們直接在 etcd Kubernetes 集群中處理數據的經驗（沒有 K8s API）“;
• «Kubernetes 運行中的 6 個有趣的系統錯誤 [及其解決方案]“。

來源： www.habr.com