ギガビット接続を使用して、数台の Xen VM から同じネットワーク内の専用サーバーで使用可能なストレージに数百ギガバイトのオンサイト バックアップを実行する必要があります。データのほとんどは MySQL データ (Percona XtraDB Cluster を使用) で、Xtrabackup を使用してサーバーにローカルにバックアップされているため、このデータは高度に圧縮できるはずです。
現時点では、duplicity 0.6.08b をパスフレーズによる暗号化 (キーは使用していません) で使用しています。これは、duplicity で作成したバックアップ ボリュームをオフサイト ストレージに rsync するためです。圧縮レベルは現在 6、ボリューム サイズは 250 です。バックアップには 1 日以上かかるため、あまり多くのスペースを取らずにローカル ネットワーク共有ストレージに高速バックアップできる推奨の duplicity 設定を探しています。
何か案が？
答え1
コメントでは、これらのバックアップのスループットは約 50 MB/秒であると述べられています。
50MB/秒は程度単一の回転ディスクを使用した場合の半ランダム ディスク スループットに期待できる値です (つまり、読み取りをディスク全体に分散してスループットを向上させるミラーリングまたはストライプ化 RAID ではありません)。一部の RAID 構成では、最高スループットでも最も遅いドライブのスループットに制限されることに注意してください。確かに、多くの HDD の定格は最大約 200 MB/秒ですが、これらの数値はシーケンシャル アクセスの最高値であることに注意してください。50 MB/秒は約 400 Mbit/秒でもあり、IP オーバーヘッドなどを多少調整すると、ネットワーク ワイヤ上では 500～600 Mbit/秒になります。そのため、これだけではギガビット リンクが飽和状態になることはありませんが、衝突が発生する可能性がかなり高くなります。
バックアップ実行中の CPU 使用率については、「3 つのハイパーバイザーがあり、それぞれに多数の VM があり、多かれ少なかれビジー状態」と述べている以外、数値は示されていません。ただし、データのコピーと圧縮は CPU をそれほど集中的に使用するものではなく、バックアップ実行中に CPU 時間に余裕がある場合は、CPU 制限はありません。この質問に答える唯一の方法は、スループットを制限している要因が何であるかを把握することです。そしてそこに努力を集中してください。
私の推測読み取りまたは書き込みのいずれかでI/Oバウンドになり、かもしれないネットワークに縛られる。ギガビット イーサネット接続を備えた専用のバックアップ ストレージ サーバーについて触れていますが、その接続の性質については何も述べていません。物理ホスト間のバックアップ用ネットワーク接続は共有ですか、それとも専用ですか? (一度に 1 つの VM または HV のみがバックアップ データをプッシュする場合は、各 HV をバックアップ サーバーに接続する個別の物理ネットワークでも問題ありません。)
バックアップサーバーへの物理ネットワーク接続が他のネットワークトラフィックと共有されている場合は、専用の接続アーキテクチャに移行できます。これにより得られるメリットは、データが圧縮されている場所と現在実際に発生している衝突の数に大きく依存しますが、これを実行し、他に何もしない場合は、かもしれないネットワーク スループットを 2 倍にすることができるため、ネットワークに制限がある場合はバックアップ時間を半分に短縮できます。
読み取りや書き込みでI/Oバウンドになっている場合は、ディスクI/Oを複数のディスクに分散できるミラーリングまたはストライプ化設定に移行すると、スループットが向上する可能性があります。これにより、ディスクバスのスループット全体が向上します。もちろん、これには独自の欠点があります。一度にプッシュするデータの量に応じて、速いバックアップストレージサーバーへのディスクキャッシュかもしれないも役立ちますが、I/O バウンドの場合は、書き込みが多かれ少なかれ順次的であるため読み取り側で問題が発生するのではないかと思います。その場合、キャッシュを追加してもあまり役に立ちません。
また、VMやHV、バックアップストレージサーバー上のファイルシステムに移行して、ディスクに書き込まれたデータをオンザフライで圧縮するか、サポートされている場合はそのような圧縮を有効にすることも検討できます。CPU時間はかかりますが、効果的ディスクデータ転送速度は、同じ量のユーザー空間データを保存するのに物理プラッターとの間で移動するデータが少なくなるため、向上します。それが特定の状況で純利益になるかどうかは、基本的にコイントスであり、ケースバイケースで評価する必要がありますが、確かに1つの利点です。可能性I/Oバウンドの状況では特に、データが最初から高度に圧縮可能である場合。たとえデータが20%しか圧縮できない場合でも（圧縮率1.25:1に相当し、たとえば自然言語テキストでは確実に達成できます。比較のために、GZIP-9圧縮のZFSでは、インターネットのWebサイトのサンプルで1.20:1の圧縮率が得られます）、画像を含む)、ホスト CPU が圧縮と解凍に対応できると仮定すると、同じ 50 MB/秒のプラッタ転送速度で、突然 60 MB/秒を超える有効なデータ転送が可能になります。暗号化されたデータは想定圧縮率が非常に低く、ランダム ノイズに似たものになります。データを暗号化する予定の場合は、通常、暗号化の前に圧縮しますが、その場合、暗号化側でのファイル システム レベルの圧縮は役に立ちません。