etcd適合的存儲速度？ 讓我們問問fio

關於 fio 和 etcd 的小故事

集群性能 等 很大程度上取決於其存儲的性能。 etcd 將一些指標導出到 普羅米修斯提供所需的存儲性能信息。 例如，wal_fsync_duration_seconds 指標。 etcd 的文檔說：要使存儲速度足夠快，該指標的第 99 個百分位數必須小於 10 毫秒。 如果你計劃在 Linux 機器上運行 etcd 集群並想評估你的存儲是否足夠快（例如 SSD），你可以使用 FIO 是用於測試 I/O 操作的流行工具。 運行以下命令，其中test-data為存儲掛載點下的目錄：

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

您只需要查看結果並檢查持續時間的第 99 個百分位數 數據同步 小於 10 毫秒。 如果是這樣，您的存儲速度相當快。 以下是結果示例：

  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]

筆記

• 我們為我們的特定場景定制了 --size 和 --bs 選項。 要從 fio 獲得有用的結果，請提供您自己的值。 從哪裡得到它們？ 讀 我們是如何學會配置 fio 的.
• 測試期間，所有 I/O 負載均來自 fio。 在現實場景中，除了與 wal_fsync_duration_seconds 相關的請求外，可能還會有其他寫入請求進入存儲。 額外的負載會增加 wal_fsync_duration_seconds 的值。 因此，如果第 99 個百分位數接近 10 毫秒，則表明您的存儲速度快用完了。
• 拿版本 FIO 不低於3.5 （以前的不顯示 fdatasync 持續時間百分位數）。
• 以上只是 fio 的一小部分結果。

關於 fio 和 etcd 的長篇大論

etcd中的WAL是什麼

通常數據庫使用 預寫日誌; etcd 也使用它。 我們不會在這裡詳細討論預寫日誌 (WAL)。 我們知道 etcd 集群的每個成員都將其維護在持久存儲中就足夠了。 etcd 在將每個鍵值操作（例如更新）應用於存儲之前將其寫入 WAL。 如果其中一個存儲成員在快照之間崩潰並重新啟動，它可以通過 WAL 內容在本地恢復自上次快照以來的事務。

當客戶端將鍵添加到鍵值存儲或更新現有鍵的值時，etcd 將操作記錄在 WAL 中，WAL 是持久存儲中的常規文件。 etcd 必須完全確定 WAL 條目在繼續處理之前確實發生了。 在 Linux 上，一個系統調用是不夠的。 寫，因為實際寫入物理存儲可能會延遲。 例如，Linux 可能會將 WAL 條目存儲在內核內存中的緩存（例如頁面緩存）中一段時間。 並且為了將數據準確寫入持久化存儲，寫入後需要fdatasync系統調用，etcd只是使用它（工作結果可以看到） 痕跡，其中 8 是 WAL 文件描述符）：

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

不幸的是，寫入持久存儲不會立即發生。 如果 fdatasync 調用很慢，etcd 系統的性能將受到影響。 etcd 的文檔說如果在第 99 個百分位數中，fdatasync 調用寫入 WAL 文件的時間少於 10 毫秒，則認為存儲速度足夠快。 還有其他有用的存儲指標，但在這篇文章中我們只討論這個指標。

使用 fio 估算存儲空間

如果您需要評估您的存儲是否適合 etcd，請使用非常流行的 I/O 負載測試工具 fio。 應該記住，磁盤操作可能非常不同：同步和異步、許多類系統調用等。因此，fio 很難使用。 它有很多參數，它們的值的不同組合會產生非常不同的 I/O 工作負載。 為了獲得足夠的 etcd 數據，您應該確保在寫入 WAL 文件時來自 fio 的測試寫入負載盡可能接近來自 etcd 的實際負載。

因此，fio 至少應該以一系列連續寫入文件的形式創建一個負載，每次寫入都將包含一個系統調用 寫隨後是 fdatasync 系統調用。 順序寫入 fio 需要 --rw=write 選項。 讓fio在寫的時候使用write系統調用，而不是 寫，您應該指定 --ioengine=sync 參數。 最後，為了在每次寫入後調用fdatasync，需要添加--fdatasync=1參數。 此示例中的其他兩個選項（--size 和 -bs）是特定於腳本的。 在下一節中，我們將向您展示如何設置它們。

為什麼是 fio 以及我們如何學會設置它

在這篇文章中，我們描述了一個真實的案例。 我們有一個集群 Kubernetes 我們使用 Prometheus 監控的 v1.13。 etcd v3.2.24 託管在 SSD 上。 Etcd 指標顯示 fdatasync 延遲太高，即使集群什麼都不做也是如此。 這些指標很奇怪，我們並不真正了解它們的含義。 集群由虛擬機組成，有必要了解問題出在哪裡：在物理 SSD 中還是在虛擬化層中。 此外，我們經常更改硬件和軟件配置，我們需要一種方法來評估其結果。 我們可以在每個配置中運行 etcd 並查看 Prometheus 指標，但這太麻煩了。 我們正在尋找一種相當簡單的方法來評估特定配置。 我們想檢查我們是否正確理解來自 etcd 的 Prometheus 指標。

但是為此，必須解決兩個問題。 首先，etcd 在寫入 WAL 時創建的 I/O 負載是什麼樣的？ 使用了哪些系統調用？ 記錄的大小是多少？ 其次，如果我們回答這些問題，我們如何用 fio 重現類似的工作負載？ 不要忘記 fio 是一個非常靈活的工具，有很多選項。 我們用一種方法解決了這兩個問題——使用命令 的 и 痕跡. lsof 列出進程使用的所有文件描述符及其關聯文件。 使用 strace，您可以檢查一個已經在運行的進程，或者啟動一個進程並檢查它。 strace 打印來自正在檢查的進程（及其子進程）的所有系統調用。 後者非常重要，因為 etcd 只是採用了類似的方法。

當集群沒有負載時，我們首先使用 strace 探索 Kubernetes 的 etcd 服務器。 我們看到幾乎所有 WAL 記錄的大小都差不多：2200-2400 字節。 因此，在帖子開頭的命令中，我們指定了參數 -bs=2300（bs 表示每個 fio 條目的字節大小）。 請注意，etcd 條目的大小取決於 etcd 版本、分佈、參數值等，並影響 fdatasync 持續時間。 如果您有類似的情況，請使用 strace 檢查您的 etcd 進程以找出確切的數字。

然後，為了更好地了解 etcd 文件系統在做什麼，我們使用 strace 和 -ffttT 選項啟動它。 因此，我們嘗試檢查子進程並將每個子進程的輸出記錄在單獨的文件中，並獲得有關每個系統調用的開始和持續時間的詳細報告。 我們使用 lsof 來確認我們對 strace 輸出的分析，並查看哪個文件描述符被用於哪個目的。 於是在strace的幫助下，得到瞭如上圖所示的結果。 同步時間統計確認來自 etcd 的 wal_fsync_duration_seconds 與使用 WAL 文件描述符的 fdatasync 調用一致。

我們瀏覽了 fio 的文檔並為我們的腳本選擇了選項，以便 fio 生成類似於 etcd 的負載。 我們還通過從 strace 運行 fio 來檢查系統調用及其持續時間，類似於 etcd。

我們仔細選擇了 --size 參數的值來表示來自 fio 的整個 I/O 負載。 在我們的例子中，這是寫入存儲的總字節數。 事實證明它與寫入（和 fdatasync）系統調用的數量成正比。 對於一定的bs值，fdatasync的調用次數=size/bs。 由於我們對百分位數感興趣，因此我們必須有足夠的樣本才能確定，並且我們計算出 10^4 對我們來說就足夠了（即 22 兆字節）。 如果 --size 較小，則可能會出現異常值（例如，幾次 fdatasync 調用花費的時間比平時長，並且會影響第 99 個百分位）。

自己嘗試一下

我們向您展示瞭如何使用 fio 並查看存儲速度是否足以讓 etcd 正常運行。 現在您可以自己嘗試使用，例如，帶有 SSD 存儲的虛擬機 IBM Cloud.

來源： www.habr.com