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