今年春天我們已經討論了一些介紹性的話題，例如， и . 在其中的第二個中，我們甚至承諾繼續研究 ZFS 中各種多磁盤拓撲的性能。 這是現在到處都在實施的下一代文件系統：來自 對 .
好吧，今天是熟悉 ZFS 的最佳日子，好奇的讀者們。 只知道在 OpenZFS 開發人員 Matt Ahrens 的拙見中，“這真的很難。”
但是在我們得出數字之前——我保證他們會的——對於八磁盤 ZFS 配置的所有選項，我們需要談談 作為 一般來說，ZFS 將數據存儲在磁盤上。
Zpool、vdev 和設備
這個完整的池圖包括三個輔助 vdev，每個類一個，四個用於 RAIDz2
通常沒有理由創建一個不匹配的 vdev 類型和大小的池——但如果您願意，沒有什麼能阻止您這樣做。
要真正了解 ZFS 文件系統，您需要仔細查看其實際結構。 首先，ZFS 統一了傳統級別的捲和文件系統管理。 其次，它使用事務性寫時復制機制。 這些特性意味著該系統在結構上與傳統的文件系統和 RAID 陣列有很大不同。 要了解的第一組基本構建塊是存儲池 (zpool)、虛擬設備 (vdev) 和真實設備 (device)。
使用zpool
zpool 存儲池是最頂層的 ZFS 結構。 每個池包含一個或多個虛擬設備。 反過來，它們中的每一個都包含一個或多個真實設備（device）。 虛擬池是獨立的塊。 一台物理計算機可以包含兩個或多個獨立的池，但每個池都完全獨立於其他池。 池不能共享虛擬設備。
ZFS 的冗餘是在虛擬設備級別，而不是池級別。 池級別絕對沒有冗餘 - 如果任何驅動器 vdev 或特殊 vdev 丟失，那麼整個池也會隨之丟失。
現代存儲池可以在緩存或虛擬設備日誌丟失後倖存下來——儘管如果它們在斷電或系統崩潰期間丟失 vdev 日誌，它們可能會丟失少量臟數據。
有一種常見的誤解，認為 ZFS“數據條帶”是跨整個池寫入的。 這不是真的。 Zpool 一點也不好笑 RAID0，它很有趣 具有復雜的變量分配機制。
大多數情況下，記錄會根據可用的可用空間分佈在可用的虛擬設備中，因此理論上它們會同時被填充。 在更高版本的 ZFS 中，當前的 vdev 使用情況（利用率）被考慮在內——如果一個虛擬設備比另一個虛擬設備忙得多（例如，由於讀取負載），它將暫時跳過寫入，儘管它有最高的空閒空間比。
現代 ZFS 寫入分配方法中內置的利用率檢測機制可以在異常高負載期間減少延遲並增加吞吐量 - 但它不會 全權委託 關於在一個池中非自願混合慢速 HDD 和快速 SSD。 這樣一個不相等的池仍然會以最慢設備的速度運行，也就是說，就好像它完全由這樣的設備組成一樣。
虛擬設備
每個存儲池由一個或多個虛擬設備（virtual device，vdev）組成。 反過來，每個 vdev 包含一個或多個真實設備。 大多數虛擬設備用於簡單的數據存儲，但有幾個 vdev 輔助類，包括 CACHE、LOG 和 SPECIAL。 這些 vdev 類型中的每一種都可以具有五種拓撲結構中的一種：單一設備（single-device）、RAIDz1、RAIDz2、RAIDz3 或鏡像（mirror）。
RAIDz1、RAIDz2 和 RAIDz3 是老人們所說的雙（對角線）奇偶校驗 RAID 的特殊變體。 1、2、3是指每個data strip分配了多少個parity block。 RAIDz 虛擬設備不是用於奇偶校驗的單獨磁盤，而是在磁盤之間半均勻地分佈此奇偶校驗。 一個 RAIDz 陣列可以丟失與奇偶校驗塊一樣多的磁盤； 如果它丟失另一個，它將崩潰並帶走存儲池。
在鏡像虛擬設備（mirror vdev）中，每個塊都存儲在vdev中的每個設備上。 雖然雙寬鏡像是最常見的，但任意數量的設備都可以在一個鏡像中 - 三重鏡像通常用於大型安裝以提高讀取性能和容錯能力。 只要 vdev 中至少有一個設備繼續運行，vdev 鏡像就可以在任何故障中倖存下來。
單個 vdev 本質上是危險的。 這樣的虛擬設備不會在單一故障中倖存下來 - 如果用作存儲或特殊 vdev，那麼它的故障將導致整個池的破壞。 在這裡要非常非常小心。
CACHE、LOG 和 SPECIAL VA 可以使用上述任何拓撲創建 - 但請記住，SPECIAL VA 的丟失意味著池的丟失，因此強烈建議使用冗餘拓撲。
設備
這可能是 ZFS 中最容易理解的術語 - 它實際上是塊隨機訪問設備。 請記住，虛擬設備由單個設備組成，而池由虛擬設備組成。
磁盤——無論是磁性的還是固態的——是最常見的塊設備，用作 vdev 的構建塊。 但是，任何在 /dev 中具有描述符的設備都可以，因此整個硬件 RAID 陣列可以用作單獨的設備。
一個簡單的原始文件是可以構建 vdev 的最重要的替代塊設備之一。 測試池來自 是檢查池命令和查看給定拓撲的池或虛擬設備中有多少可用空間的一種非常方便的方法。
您可以在幾秒鐘內從稀疏文件創建一個測試池 - 但不要忘記之後刪除整個池及其組件
假設您要將服務器放在八個磁盤上併計劃使用 10 TB 磁盤（~9300 GiB）——但您不確定哪種拓撲最適合您的需求。 在上面的例子中，我們在幾秒鐘內從稀疏文件構建了一個測試池——現在我們知道一個 2 個 10 TB 磁盤的 RAIDz50 vdev 提供 XNUMX TiB 的可用容量。
另一類特殊的設備是SPARE（備用）。 與常規設備不同，熱插拔設備屬於整個池，而不屬於單個虛擬設備。 如果池中的 vdev 發生故障並且備用設備連接到池並且可用，那麼它會自動加入受影響的 vdev。
連接到受影響的 vdev 後，備用設備開始接收應該位於丟失設備上的數據的副本或重建。 在傳統 RAID 中，這稱為重建，而在 ZFS 中，這稱為重新同步。
請務必注意，備用設備不會永久替換故障設備。 這只是一個臨時替換，以減少 vdev 降級的時間。 管理員更換故障 vdev 後，冗餘將恢復到該永久設備，SPARE 將與 vdev 斷開連接並返回作為整個池的備用設備。
數據集、塊和扇區
在我們的 ZFS 之旅中要了解的下一組構建塊不是關於硬件，而是更多關於數據本身的組織和存儲方式。 我們在這裡跳過了幾個級別 - 例如 metaslab - 以免在保持對整體結構的理解的同時混淆細節。
數據集（dataset）
當我們第一次創建數據集時，它會顯示所有可用的池空間。 然後我們設置配額 - 並更改掛載點。 魔法！
Zvol 在很大程度上只是一個剝離了文件系統層的數據集，我們在這裡用一個完全正常的 ext4 文件系統替換它。
ZFS 數據集與標準掛載文件系統大致相同。 與常規文件系統一樣，乍一看它就像“只是另一個文件夾”。 但就像常規的可掛載文件系統一樣，每個 ZFS 數據集都有自己的一組基本屬性。
首先，一個數據集可以有一個分配的配額。 如果設置 zfs set quota=100G poolname/datasetname，那麼您將無法寫入已安裝的文件夾 /poolname/datasetname 超過 100 GiB。
請注意每行開頭是否存在斜線？ 每個數據集在 ZFS 層次結構和系統安裝層次結構中都有自己的位置。 ZFS 層次結構中沒有前導斜杠 - 您從池名稱開始，然後是從一個數據集到下一個數據集的路徑。 例如， pool/parent/child 對於名為 child 在父數據集下 parent 在一個有創意的名字池中 pool.
默認情況下，數據集的掛載點將等同於其在 ZFS 層次結構中的名稱，帶有前導斜杠 - 名為的池 pool 安裝為 /pool, 數據集 parent 安裝在 /pool/parent, 和子數據集 child 安裝在 /pool/parent/child. 但是，可以更改數據集的系統掛載點。
如果我們指定 zfs set mountpoint=/lol pool/parent/child, 那麼數據集 pool/parent/child 安裝在系統上作為 /lol.
除了數據集，我們還應該提到卷 (zvols)。 卷與數據集大致相同，只是它實際上沒有文件系統——它只是一個塊設備。 例如，您可以創建 zvol 有名字 mypool/myzvol，然後使用 ext4 文件系統對其進行格式化，然後掛載該文件系統 - 您現在擁有一個 ext4 文件系統，但具有 ZFS 的所有安全功能！ 這在一台機器上可能看起來很愚蠢，但在導出 iSCSI 設備時作為後端更有意義。
塊
文件由一個或多個塊表示。 每個塊都存儲在一個虛擬設備上。 塊大小通常等於參數 記錄大小, 但可以簡化為 2^班次如果它包含元數據或小文件。
我們真的 真 不要開玩笑說如果你設置太小的 ashift 會帶來巨大的性能損失
在 ZFS 池中，所有數據（包括元數據）都存儲在塊中。 每個數據集的最大塊大小在屬性中定義 recordsize （記錄大小）。 記錄大小可以更改，但這不會更改已寫入數據集的任何塊的大小或位置——它只會影響寫入的新塊。
除非另有說明，否則當前默認記錄大小為 128 KiB。 在性能不完美的情況下，這是一種棘手的權衡，但在大多數情況下也並不糟糕。 Recordsize 可以設置為從 4K 到 1M 的任何值（使用高級設置 recordsize 您可以安裝更多，但這不是一個好主意）。
任何塊都只引用一個文件的數據——你不能將兩個不同的文件塞到一個塊中。 每個文件由一個或多個塊組成，具體取決於大小。 如果文件大小小於記錄大小，它將存儲在一個較小的塊中——例如，一個包含 2 KiB 文件的塊將只佔用磁盤上一個 4 KiB 的扇區。
如果文件足夠大並且需要幾個塊，那麼這個文件的所有記錄都將是大小 recordsize - 包括最後一個條目，其主要部分可能是 .
zvols 沒有屬性 recordsize — 相反，它們具有等效的屬性 volblocksize.
部門
最後一個也是最基本的構建塊是扇區。 它是可以寫入底層設備或從底層設備讀取的最小物理單元。 幾十年來，大多數磁盤都使用 512 字節的扇區。 最近，大多數磁盤都設置為 4 KiB 扇區，有些 - 特別是 SSD - 有 8 KiB 扇區甚至更多。
ZFS 系統具有允許您手動設置扇區大小的屬性。 這個性質 ashift. 有點令人困惑的是，ashift 是 XNUMX 的冪。 例如， ashift=9 表示扇區大小為 2^9，即 512 字節。
ZFS 在將每個塊設備添加到新的 vdev 時向操作系統查詢有關每個塊設備的詳細信息，並且理論上會根據該信息自動正確安裝 ashift。 不幸的是，許多驅動器都謊稱其扇區大小以保持與 Windows XP 的兼容性（Windows XP 無法理解具有其他扇區大小的驅動器）。
這意味著強烈建議 ZFS 管理員了解其設備的實際扇區大小並手動設置 ashift. 如果 ashift 設置得太低，那麼讀/寫操作的數量會以天文數字的形式增加。 因此，將 512 字節“扇區”寫入真正的 4 KiB 扇區意味著必須寫入第一個“扇區”，然後讀取 4 KiB 扇區，用第二個 512 字節“扇區”修改它，將其寫回新的每個條目有 4 KiB 扇區，依此類推。
在現實世界中，這樣的懲罰會影響三星 EVO SSD，為此 ashift=13, 但這些 SSD 謊報其扇區大小，因此默認設置為 ashift=9. 如果有經驗的系統管理員不更改此設置，則此 SSD 可以正常工作 慢點 傳統的磁性硬盤驅動器。
為了比較，尺寸太大 ashift 幾乎沒有懲罰。 沒有真正的性能損失，未使用空間的增加是無窮小的（或啟用壓縮時為零）。 因此，我們強烈建議即使是那些確實使用 512 字節扇區的驅動器也安裝 ashift=12 甚至 ashift=13充滿信心地面對未來。
物業資料 ashift 為每個 vdev 虛擬設備設置，並且 不適合游泳池，正如許多人錯誤地認為的那樣 - 安裝後不會改變。 如果不小心碰到 ashift 當您將新的 vdev 添加到池中時，您已經用低性能設備無可挽回地污染了該池，通常別無選擇，只能銷毀該池並重新開始。 即使刪除 vdev 也無法將您從損壞的配置中解救出來 ashift!
寫時復制機制
如果常規文件系統需要覆蓋數據，它會更改它所在的每個塊
寫時復製文件系統寫入新的塊版本，然後解鎖舊版本
抽像地說，如果我們忽略塊的實際物理位置，那麼我們的“數據彗星”將簡化為“數據蠕蟲”，從左到右穿過可用空間圖
現在我們可以很好地了解寫時復制快照的工作原理——每個塊可以屬於多個快照，並且會一直存在，直到所有關聯的快照都被銷毀
寫時復制 (CoW) 機制是使 ZFS 成為如此出色的系統的基礎。 基本概念很簡單——如果您要求傳統文件系統更改文件，它會完全按照您的要求執行。 如果你要求寫時復製文件系統做同樣的事情，它會說“好的”但對你撒謊。
相反，寫時復製文件系統寫入修改後的塊的新版本，然後更新文件的元數據以取消鏈接舊塊並將您剛剛寫入的新塊關聯到它。
分離舊塊和鏈接新塊是在一個操作中完成的，因此它不能被中斷——如果你在這發生之後斷電，你有一個新版本的文件，如果你提前斷電，你有舊版本. 在任何情況下，文件系統都不會發生衝突。
ZFS 中的寫時復制不僅發生在文件系統級別，還發生在磁盤管理級別。 這意味著 ZFS 不受空格的影響（) - 在系統崩潰之前條帶只有部分記錄的現象，重啟後陣列損壞。 這裡的條帶是原子寫入的，vdev 總是順序的，並且 .
ZIL：ZFS 意圖日誌
ZFS 系統以一種特殊的方式處理同步寫入——它暫時但立即將它們存儲在 ZIL 中，然後再將它們與異步寫入一起永久寫入。
通常，寫入 ZIL 的數據永遠不會被再次讀取。 但是在系統崩潰後是可能的
SLOG，或輔助 LOG 設備，只是一個特殊的 - 最好是非常快的 - vdev，ZIL 可以與主存儲分開存儲
崩潰後，重放 ZIL 中的所有臟數據 - 在這種情況下，ZIL 在 SLOG 上，因此從那裡重放
寫操作主要分為兩類——同步（sync）和異步（async）。 對於大多數工作負載，絕大多數寫入都是異步的——文件系統允許它們聚合併分批發出，從而減少碎片並大大提高吞吐量。
同步錄音是完全不同的事情。 當應用程序請求同步寫入時，它會告訴文件系統：“您需要將此提交到非易失性內存 現在在那之前，我無能為力。” 因此，同步寫入應該立即提交到磁盤——如果這會增加碎片或降低吞吐量，那就這樣吧。
ZFS 處理同步寫入的方式與常規文件系統不同——ZFS 不是立即將它們提交到常規存儲，而是將它們提交到一個稱為 ZFS Intent Log 或 ZIL 的特殊存儲區域。 訣竅是這些記錄 還 保留在內存中，與正常的異步寫入請求一起聚合，稍後作為完全正常的 TXG（事務組）刷新到存儲中。
在正常操作中，ZIL 被寫入並且再也不會被讀取。 片刻之後，當來自 ZIL 的記錄從 RAM 提交到普通 TXG 中的主存儲時，它們與 ZIL 分離。 唯一一次從 ZIL 中讀取內容是在導入池時。
如果 ZFS 失敗——操作系統崩潰或斷電——而 ZIL 中有數據，則在下一次池導入期間（例如，當緊急系統重新啟動時）將讀取該數據。 ZIL 中的任何內容都將被讀取、分組到 TXG、提交到主存儲，然後在導入過程中與 ZIL 分離。
vdev helper 類之一稱為 LOG 或 SLOG，LOG 的輔助設備。 它有一個目的——為池提供一個單獨的、最好更快、非常耐寫的 vdev 來存儲 ZIL，而不是將 ZIL 存儲在主 vdev 存儲上。 ZIL 本身無論存儲在何處都表現相同，但如果 LOG vdev 具有非常高的寫入性能，則同步寫入會更快。
將帶有 LOG 的 vdev 添加到池中不起作用 不能 提高異步寫入性能 - 即使您強制所有寫入 ZIL zfs set sync=always，它們仍將以與沒有日誌相同的方式和速度鏈接到 TXG 中的主存儲。 唯一直接的性能改進是同步寫入的延遲（因為更快的日誌可以加快操作速度）。 sync).
然而，在已經需要大量同步寫入的環境中，vdev LOG 可以間接加速異步寫入和非緩存讀取。 將 ZIL 條目卸載到單獨的 vdev LOG 意味著主存儲上 IOPS 的爭用更少，這在一定程度上提高了所有讀寫的性能。
快照
寫時復制機制也是ZFS原子快照和增量異步複製的必要基礎。 活動文件系統有一個指針樹，用當前數據標記所有記錄——當你拍攝快照時，你只需複制這個指針樹。
當活動文件系統上的記錄被覆蓋時，ZFS 首先將新的塊版本寫入未使用的空間。 然後它將舊版本的塊從當前文件系統中分離出來。 但是如果某個快照引用了舊塊，它仍然保持不變。 在銷毀引用該塊的所有快照之前，舊塊實際上不會恢復為可用空間！
複寫
我的 Steam 庫在 2015 年是 158 GiB，包含 126 個文件。 這非常接近 rsync 的最佳情況——網絡上的 ZFS 複製“僅”快 927%。
在同一個網絡上，複製單個 40GB 的 Windows 7 虛擬機映像文件是完全不同的事情。 ZFS 複製比 rsync 快 289 倍——如果您足夠聰明，可以使用 --inplace 調用 rsync，則“僅”快 161 倍。
縮放 VM 映像時，rsync 問題會隨之縮放。 1,9 TiB 對於現代 VM 映像來說並不算大——但它足以使 ZFS 複製比 rsync 快 1148 倍，即使使用 rsync 的 --inplace 參數也是如此
一旦了解了快照的工作原理，就應該很容易掌握複製的本質。 由於快照只是一棵指向記錄的指針樹，因此如果我們這樣做 zfs send 快照，然後我們發送這棵樹和所有與之相關的記錄。 當我們發送這個 zfs send в zfs receive 在目標上，它將塊的實際內容和引用塊的指針樹寫入目標數據集。
事情在第二個變得更加有趣 zfs send. 我們現在有兩個系統，每個系統都包含 poolname/datasetname@1，然後你拍了一張新快照 poolname/datasetname@2. 因此，在原來的池中你有 datasetname@1 и datasetname@2，並且到目前為止在目標池中只有第一個快照 datasetname@1.
由於我們在源和目標之間有一個公共快照 datasetname@1， 我們可以做到這一點 增加的 zfs send 超過它。 當我們對系統說 zfs send -i poolname/datasetname@1 poolname/datasetname@2，它比較兩個指針樹。 任何只存在於 @2, 顯然是指新塊 - 所以我們需要這些塊的內容。
在遠程系統上，處理增量 send 就這麼簡單。 首先，我們寫入流中包含的所有新條目 send，然後添加指向這些塊的指針。 瞧，我們有 @2 在新系統！
ZFS 異步增量複製是對早期非基於快照的方法（如 rsync）的巨大改進。 在這兩種情況下，僅傳輸更改的數據 - 但 rsync 必須首先 閱讀 從磁盤兩邊的所有數據檢查總和並進行比較。 相比之下，ZFS 複製只讀取指針樹 - 以及共享快照中不存在的任何塊。
內置壓縮
寫時復制機制還簡化了內聯壓縮系統。 在傳統的文件系統中，壓縮是有問題的——修改數據的舊版本和新版本都駐留在同一個空間中。
如果我們考慮文件中間的一段數據，它從 0x00000000 開始以 256 兆字節的零開始，依此類推，很容易將其壓縮到磁盤上的一個扇區。 但是，如果我們用 4 兆字節的不可壓縮數據（如 JPEG 或偽隨機噪聲）替換該兆字節的零，會發生什麼情況？ 出乎意料的是，這一兆字節的數據需要的不是一個，而是XNUMX個XNUMX KiB扇區，而磁盤上的這個地方只保留了一個扇區。
ZFS 沒有這個問題，因為修改的記錄總是寫入未使用的空間 - 原始塊只佔用一個 4 KiB 扇區，新記錄將佔用 256，但這不是問題 - 最近修改的片段來自“ middle" 的文件將被寫入未使用的空間，無論其大小是否發生變化，因此對於 ZFS，這是很常見的情況。
默認情況下，本機 ZFS 壓縮是禁用的，系統提供可插入算法——目前是 LZ4、gzip (1-9)、LZJB 和 ZLE。
- LZ4 是一種流式算法，可為大多數用例提供極快的壓縮和解壓縮以及性能優勢 - 即使在相當慢的 CPU 上也是如此。
- GZIP 是所有 Unix 用戶都知道並喜愛的古老算法。 它可以用壓縮級別 1-9 來實現，壓縮率和 CPU 使用率隨著接近級別 9 的增加而增加。該算法非常適合所有文本（或其他高度可壓縮的）用例，但通常會導致 CPU 問題 - 使用它小心，尤其是在更高級別。
- 陸ZJB 是 ZFS 中的原始算法。 它已經過時，不應再使用，LZ4 在各個方面都超越了它。
- 糟糕 - 零級編碼，零級編碼。 它根本不接觸普通數據，而是壓縮大量的零序列。 對於完全不可壓縮的數據集（例如 JPEG、MP4 或其他已經壓縮的格式）很有用，因為它會忽略不可壓縮的數據，但會壓縮結果記錄中未使用的空間。
我們建議幾乎所有用例都使用 LZ4 壓縮； 遇到不可壓縮數據時的性能損失非常小，並且 生長 典型數據的性能很重要。 為新安裝的 Windows 操作系統（新安裝的操作系統，內部還沒有數據）複製虛擬機映像 compression=lz4 通過比用快 27% compression=none在 .
ARC - 自適應替換緩存
ZFS 是我們所知道的唯一使用自己的讀取緩存機制的現代文件系統，而不是依賴操作系統的頁面緩存將最近讀取的塊的副本存儲在 RAM 中。
儘管本機緩存並非沒有問題——ZFS 無法像內核一樣快速響應新的內存分配請求，因此新的挑戰 malloc() 如果需要 ARC 當前佔用的 RAM，則內存分配可能會失敗。 但是有充分的理由使用您自己的緩存，至少現在是這樣。
所有已知的現代操作系統，包括 MacOS、Windows、Linux 和 BSD，都使用 LRU（最近最少使用）算法來實現頁面緩存。 這是一種原始算法，在每次讀取後將緩存塊“向上推送”，並根據需要將塊“向下推送”以添加新的緩存未命中（應該從磁盤讀取的塊，而不是從緩存中讀取的塊）向上。
該算法通常運行良好，但在具有大型工作數據集的系統上，LRU 很容易導致抖動 - 驅逐經常需要的塊以為永遠不會再次從緩存中讀取的塊騰出空間。
是一種更簡單的算法，可以將其視為“加權”緩存。 每次讀取緩存塊時，它都會變得“更重”一點並且更難逐出 - 即使在逐出塊之後也是如此 跟踪 在一定時間內。 已被逐出但隨後需要讀回緩存的塊也將變得“更重”。
所有這一切的最終結果是緩存具有更高的命中率，即緩存命中（從緩存執行的讀取）和緩存未命中（從磁盤讀取）之間的比率。 這是一個非常重要的統計數據——不僅緩存命中本身的服務速度提高了幾個數量級，緩存未命中的服務也可以更快，因為緩存命中越多，並發磁盤請求越少，剩餘未命中的延遲也越低必須用磁盤提供。
結論
在學習了 ZFS 的基本語義之後——寫時復制如何工作，以及存儲池、虛擬設備、塊、扇區和文件之間的關係——我們準備好用實數討論真實世界的性能。
在下一部分中，我們將查看具有鏡像 vdev 和 RAIDz 的池的實際性能，相互比較，以及與我們探索過的傳統 Linux 內核 RAID 拓撲結構的比較。 .
起初，我們只想介紹基礎知識——ZFS 拓撲本身——但之後 此 讓我們準備好討論 ZFS 的更高級設置和調整，包括使用輔助 vdev 類型，如 L2ARC、SLOG 和特殊分配。
來源： www.habr.com