提高 EBS 快照支持卷的 I/O 速率
我正在使用一個系統，該系統會為其眾多 (40) 個卷中的每個卷拍攝一組 42 個輪換的每日 EBS 快照，以用於災難恢復目的。EBS 卷被聚合到一個 RAID 卷中。通過在拍攝快照期間凍結文件系統來拍攝一組一致的快照。每個單獨的捲只有 2 TiB。
在 DR 測試期間發現，將 20 多 TiB 的應用程序數據（PostgreSQL 數據庫、許多大表）從快照創建的 EBS 快照支持卷複製到新的非快照卷上需要 24 小時以上。支持的捲。由於 8 個 rsync 同時在不同的子樹上工作，因此在副本中具有相當大的並行性。
如果數據沒有復製到新的 EBS 卷，那麼基於 PostgreSQL 的應用程序會像蜂蜜一樣執行很多天，大概直到 EBS 卷的塊被弄髒，所以它們現在直接在 EBS 卷上，而不是來自快照。
相比之下，將相同數據從一組非快照支持的 EBS 卷複製到另一個卷只需要幾個小時，而使用類似規模的“真實”硬體再次需要的時間要少得多。
為什麼我會看到快照支持的捲和普通卷之間存在如此巨大的性能差異？
我的假設是它正在執行寫時複製，因此由於必須單獨獲取快照，因此乾淨的塊不會改變。如果有 40 個快照堆棧支持該卷，那麼它可能很難在它出現的最新快照中快速定位塊並獲取它。
有什麼方法可以強制 AWS 從快照中高效且線性地預填充整個新的 EBS 卷，而不是像實際看起來那樣進行懶惰的寫時複製？
解決此問題的任何其他想法？如果恢復時間超過一天，則一組 DR 快照的用處會大大降低。
從恢復的捲中讀取應該足夠了。
當您從現有快照創建卷時，它會在後台延遲載入，以便您可以立即開始使用它們。如果您訪問尚未載入的數據，卷會立即從 Amazon S3 下載請求的數據，然後在後台繼續載入卷的其餘數據。
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
有趣的是，使用順序“強制讀取”似乎
dd比從文件系統讀取產生的更多隨機讀取性能更好，但您當然可以同時執行這兩項操作——繼續安裝它並開始做任何事情您需要這樣做，但還需要從塊設備中讀取和丟棄dd.這種明顯的差異是有意義的，特別是如果 EBS 快照基礎設施實際上並未將快照塊儲存在“塊”大小（4096 字節）的塊中。這似乎是一個非常低效的設計，每兆字節需要數千次操作。
如果您從不同的偏移量開始進行多次順序讀取，它可能會進一步改善恢復。未經測試，但gnu
dd顯然可以“跳過”塊並開始閱讀，而不是從頭開始。但是，您絕對不需要創建“新”卷。一旦塊被讀取載入，它們就“在”EBS 中，而不是來自快照。
如果有 40 個快照堆棧支持該卷，那麼它可能很難在它出現的最新快照中快速定位塊並獲取它。
有多少快照支持它並不重要。數據不儲存在快照“中”。每個快照都包含我隨便稱為“指針”的所有數據塊的完整記錄，這些數據塊指向包含它的所有數據塊（不僅僅是更改的數據塊），並且可能儲存在快照基礎設施使用的備份儲存 (S3) 中的位置。
如果您從同一卷中按順序拍攝快照 A、B 和 C，然後刪除快照 B，則所有從 A 更改為 B 但未從 B 更改為 C 的塊仍可用於恢復快照 C，但當您刪除快照 B 時，它們並沒有真正從 B 移動到 C。
當您刪除快照時，EBS 會使用引用計數清除不再需要的塊的備份儲存。沒有被任何快照引用的塊在後台通過一個多步驟過程進行處理，該過程首先將它們標記為不需要，然後停止為它們計費，然後在幾天后真正刪除它們在 refcount = 0 時已確認。 來源。
因此，最初為還原卷貢獻塊的快照數量不應影響性能。
其他可能有用的資訊：以下內容不會改變上述答案的準確性，但在某些情況下可能有價值。
2019 年末，EBS 宣布了一項名為“快速快照還原”的新功能，該功能允許從指定快照在指定可用區創建的捲立即變熱，無需預熱。
使用信用桶並基於指定快照的大小（即，從中獲取它的磁碟捲的大小）——而不是目標卷的大小（可以大於快照的大小）——這功能允許您每小時創建 1024G/大小的捲，因此 128 GiB 快照可以每小時創建 8 個預熱捲。隨著快照變小，每個可用區每個快照每小時可以創建的捲數上限為 10。
該服務也非常昂貴——每個快照、每個可用區（！？）每小時 0.75 美元——但是，這可能不是您需要持續執行的東西，從這個角度來看，它似乎具有一些潛在價值.
當您啟動該功能時，服務API 可以告訴您它何時真正可以使用，並且每 TiB 60 分鐘是“優化快照”的規定時間表（從字裡行間看，這意味著建構和預熱隱藏的主快照中的 EBS 中的捲，隨後將由服務複製以創建額外的 EBS 卷；該功能似乎僅在此階段完成後才真正可用，並且在此之前從同一快照創建的捲只是普通卷）。
只要您有時間等待“優化”階段，並且當您不再需要它時終止快速恢復行為（以避免非常大的意外計費），這似乎確實適用於有限的案例。