我需要透過千兆位元連接，從幾個 Xen VM 到同一網路中的專用伺服器上的某些可用儲存執行數百 GB 的現場備份。資料主要是 MySQL 資料 - 我使用 Percona XtraDB Cluster - 使用 Xtrabackup 在伺服器上本地備份，所以我想這些資料應該是高度可壓縮的。
目前，我正在使用口是心非 0.6.08b 和密碼加密（我沒有使用密鑰），因為我還將使用口是心非創建的備份卷同步到某些異地存儲。壓縮等級目前為 6，磁碟區大小為 250。
任何想法？
答案1
您在評論中說您看到這些備份的吞吐量約為 50 MB/s。
50MB/秒是按順序單一旋轉 rust 磁碟的半隨機磁碟吞吐量（即非鏡像或條帶 RAID，允許跨磁碟讀取以增加吞吐量）的預期。請注意，某些 RAID 配置甚至會有效地將最佳情況下的吞吐量限制為最慢驅動器的吞吐量。是的，許多 HDD 的額定速度高達 ~200 MB/s，但請記住，這些數字是最佳情況下的順序存取數。 50 MB/s 也大約是400 Mbit/s，加上一些IP 開銷等因素，網路線路上的速度可達500-600 Mbit/s，因此，雖然您沒有僅用此來使千兆位元鏈路飽和，但正在相當接近可能發生碰撞的區域。
您沒有提供備份運行時 CPU 利用率的任何數字，只是說您「有三個管理程序，每個管理程序上有一堆虛擬機，或多或少忙碌」。但是複製資料並壓縮它並不是非常消耗 CPU 資源，如果在備份運行時您有空閒的 CPU 時間，那麼您就不會受到 CPU 的限制。真正回答這個問題的唯一方法是找出限制吞吐量的因素然後集中精力在那裡。
我猜就是你受 I/O 限制，無論是讀或寫，而你可能受網路限制。您談論了具有千兆位元乙太網路連接的專用備份儲存伺服器，但您沒有提及該連線的性質。實體主機之間的備份網路連線是共用的還是專用的？ （如果任一時間只有一台虛擬機器或 HV 推送備份數據，則可以使用單獨的實體網路將每個 HV 連接到備份伺服器。）
如果到備份伺服器的實體網路連線與其他網路流量共用，您可以轉向專用連線架構。您從中獲得的好處在很大程度上取決於資料的壓縮位置以及您目前實際看到的衝突數量，但如果您這樣做而不做其他事情，您就會發現可能能夠使網路吞吐量加倍，因此，如果您受網路限制，則可以將備份時間減少一半。
如果您在讀取和/或寫入方面受到 I/O 限制，那麼遷移到允許磁碟 I/O 分佈到多個磁碟的鏡像或條帶設定可能有助於提高吞吐量；它將增加磁碟總線的總吞吐量。當然，這也有其自身的缺點。根據您一次推送的數據量，添加更多數據快速地磁碟緩存到備份儲存伺服器可能也有幫助，但我懷疑，如果您受 I/O 限制，則它位於讀取端，因為寫入可能或多或少是順序的，在這種情況下添加快取不會對您有太大幫助。
您也可以考慮遷移到 VM 或 HV 和/或備份儲存伺服器上的檔案系統，該檔案系統在寫入磁碟時對資料進行動態壓縮，或啟用此類壓縮（如果支援） 。它會消耗CPU時間，但會增加有效的磁碟數據傳輸速率，因為對於儲存的相同數量的用戶空間數據，需要從實體盤片移入和移出的數據較少。在任何一種情況下這是否會成為淨收益基本上都是拋硬幣的問題，需要根據具體情況進行評估，但它肯定是一個可能性對於受 I/O 限制的情況，尤其是資料一開始就高度可壓縮的情況。即使資料只能壓縮20%（相當於1.25:1 的壓縮比，並且對於自然語言文字等來說絕對可以實現；作為比較，採用gzip-9 壓縮的ZFS 在採樣時提供了1.20:1 的壓縮率）互聯網網站，包括影像），假設主機 CPU 能夠跟上壓縮和解壓縮的速度，那些相同的 50 MB/s 磁碟片傳輸速率會突然為您提供超過 60 MB/s 的有用資料傳輸。請注意，加密資料是應該壓縮效果極差，因為它應該類似於隨機雜訊；如果您打算加密數據，通常會在加密之前進行壓縮，在這種情況下，加密端的檔案系統級壓縮不會有任何好處。